Chapter 24

Section: Part VI:  Platforms and Security

Chapter 24. VAX/VMS


        The History of the VAX


        Security in VMS

        Some Old Vulnerabilities

        Auditing and Monitoring

        Changing Times

Although the world of VMS is a bit dated, VAX/VMS machines are by no means extinct. This chapter goes over some of the security features for VMS, and includes a short catch-up course for those unfamiliar with the platform. Even if you do not administer or maintain VAX/VMS systems, you might find this chapter somewhat useful, if for no other reason than the VAX's relevance in computing history.


Section: Chapter 24.  VAX/VMS

The History of the VAX

To begin the lesson, I will start with a brief overview of the rise of Digital Equipment Corporation (DEC), the company that manufactured the once-popular product, the VAX (virtual address extension).

In one way or another, DEC has always been there at critical moments in computer history. (You might recall that Ken Thompson was first hacking UNIX on a DEC PDP-10.)

To appreciate just how long DEC has been delivering computer products to the industry, take a moment to catch this link:

This link will take you to Lawrence Crowl's wonderful computer history page, which shows photographs of machines that mark milestones in our computer culture (starting with the very first computer ever constructed by Charles Babbage, circa 1823). The first DEC PDP-1 appears on that page.

To get a full-screen view of that machine, catch this link:

The machine looks, quite frankly, like a prop in some terrible B movie from the 1950s something you would expect to see in a mad scientist's laboratory. DEC quickly moved on to produce a wide range of products, including the very first minicomputer the DEC PDP-8.

You can see this machine on Mr. Crowl's page as well, located full size at

In 1978, DEC created the first VAX, the Digital VAX 11/780. This machine offered 32-bit architecture and 1MIPS performance. By standards of the day, the 11/780 was powerful and fast. (It was also backward compatible with the PDP line that preceded it.) The price tag? A mere $200,000.


MIPS stands for so many million instructions per second.


Curiously, the 11/780 became so popular that it would establish itself as the benchmark machine for the MIPS index. In other words, it became the yardstick by which to measure performance of all workstations that followed. (This occurred despite the fact that the IBM 370/158 was reportedly comparable in terms of speed and processing power. The IBM 370/158 never reached the popularity status of the 11/780.)

To reiterate, the 11/780 was a $200,000 machine that could carry out roughly 1 million instructions per second. Fantastic. Today, if you were to advertise this machine for sale on the Internet, you would have to pay the buyer to haul it away. It is considered by today's standards either junk or, perhaps more charitably, a collector's item. However, one thing made the 11/780 a special innovation and still singles it out from other machines in computer history: The 11/780 could support two operating systems. One was a system UNIX that was known reasonably well at the time. The other system was something a little different. It was called VMS (Virtual Memory System). We will be examining VMS in just a moment. First, however, I want to give you an idea of what the VAX is all about.

The VAX is a multiuser system. Many readers might not be old enough to remember the VAXstations, so I'll offer a little description. The MicroVAX stands nearly three feet tall. On the right side of the machine is a panel that, when opened, reveals the cards. These cards are quite large, although not nearly as large as the panels of, say, a SPARCstation 4/330 VME deskside computer (but certainly larger than most modern motherboards for personal computers).

The terminal is a VT220, with a viewing screen of approximately 8 inches. At the back of the terminal are various connectors. These include a data lead connection, a printer connection, and a serial port. The serial port can be set to an amazing 19200 baud and terminal emulations available included VT220 and VT100. If you connect a modem to the terminal, you have to set modem commands by hand. (In other words, you would have to send raw modem commands from a blank screen that sports a blinking cursor. As an example, you would typically dial by issuing the command ATDT5551212.)

Firmware is contained within the terminal. This is software hard-coded into the board itself. (PC users should think of firmware in exactly the same way as the CMOS. It is a small software module that performs a limited number of tasks, including setting the machine's parameters.) Unfortunately, there is no facility by which to capture a figure of the screen, so I must describe it. When the terminal boots, you are presented with a copyright screen and then a blank screen with a blinking cursor. The terminal is then ready to accept commands. To manipulate the settings in the firmware, you choose the F3 (function 3 or Setup) key. This brings up a menu at the bottom of the screen where you can review and change various settings. These include not only the way that communications are conducted, but also how the screen is laid out and behaves. For example, you have a choice of either an amber background and a black foreground or the reverse. You can specify a typewriter keyboard or data mode, which is more commonly used when interfacing directly with the VAX. You can also manipulate the number of characters per line and lines per screen. (Additionally, the firmware has short help messages embedded within it. These generally appear at the bottom of the screen, in the status area, as do the setting values for each facet of your environment. These can indicate which printer you are using, whether you want local echo, whether you want type-ahead mode, and so forth.) No mouse, hard disk drive, floppy drive, or other components are either present or required.

You have a wide range of choices regarding communication. For example, you can change the bits (typically 7 or 8) and also the parity of these (none, odd, or even). This makes the VT220 terminal valuable not only to interface with VAXen (slang for VAX machines), but also a wide variety of UNIX machines. For example, you can use a VT220 terminal as a "head" for a workstation that otherwise has no monitor. Plugging the terminal into the first serial port of the workstation will generally do this. (For most versions of UNIX, you generally need to strip the eighth bit.)


For Linux hackers: You can also "add" an Internet node to your box using such a terminal. To do so, you plug the terminal into either COM1 or COM2. You then edit inittab to respawn another instance of getty on that port. For this to work, you need to ensure that the cable used is a null modem cable. You also should set the emulation to VT100. When the Linux box reboots, a login prompt will appear on the VT220. From there, log in as any valid user, and you are ready. This is significantly valuable, especially if you are trying to train someone in programming or navigation of the Net via a CLI (command line interface). It is important to note that, if you are using the same COM port that normally supports your mouse, you need to kill gpm (general purpose mouse) support.


These terminals, although intended for use with the VAX, can also be used as the most inexpensive method ever of accessing the Internet. Naturally, you need an old-style dial-up connec tion to do so (perhaps via Delphi), but there is no comparison to the price. Such terminals can now be purchased for $20. Add to this the price of a 19200 baud modem, and you are done.They are also great for connecting to local BBSs.


Such a terminal does not have environment variables per se and therefore reports none. All the environment variables are obtained from whatever shell you happen to acquire on the remote machine.


These terminals are used to connect to the VAX. (Note, too, that I have described only very early implementations of VT terminals. Much later models support various types of colors and graphics not available to the early VT100 and VT220 terminals. These newer models are extremely functional but can run as high as several hundred dollars. Good examples are the VT330 and VT340.)

Finally, you can connect to a VAX without such a terminal. Typically, this is done using PC software that supports VT100 terminal emulation. (Kermit is another popular and compatible emulation.)


Section: Chapter 24.  VAX/VMS


The VMS operating system is unique, but bears similarities to several others. Logging in works much as it does on a UNIX system. You are presented with a login prompt (Username:) and a password prompt. If you enter the correct information, you are dropped to a prompt represented by a dollar sign ($). You are also given a series of values when you log in, including your username, your process ID, and so forth.

Some common VMS commands are listed in Table 24.1.

Table 24.1. Common VMS Commands



HELP [args]

If issued alone (without arguments), this command will bring up the prompt Topic. The HELP command is generally followed by whatever command you want to learn about.

COPY [arg1 arg2]

Will copy an existing file or files to another file or directory.


Works very much like the DOS command dir, giving the contents of a directory and the attributes associated with the files therein.


Invokes the email program interface for VAX. This works (roughly) like standard mail in UNIX. When preparing to compose a message, you are prompted for recipient and subject.


The VAX equivalent to the UNIX command ps,LOOK shows you your current processes.


There is a nice table of command translations from VAX to UNIX. The table has been around for a while and basically offers UNIX users and others a brief reference. It is located at You might want to take a brief look at Table 24.1 because you will see some of these commands throughout the chapter.


VMS has many of the amenities of other operating systems. The commands might be just slightly different. For example, the C shell in UNIX has a facility that will recall commands previously typed at the prompt. This facility is called history. (DOS has a similar command module, usually loaded at boot time, called DOSkey.) In VMS, you can recall commands recently typed by holding down Ctrl+B. There are other control key combinations that will stop a process, list all processes, resume a process, report current user statistics, and edit the current command line.

There are still many VAX servers on the Internet, and VMS is still very much alive. The newest version, called OpenVMS, is available for both VAX and Alpha machines. Alphas are extremely fast workstations (now at speeds exceeding 1000Mhz) that can run OpenVMS, Linux, or Tru64/Digital UNIX.

The majority of VAX servers on the Net are older. Many are machines located at university libraries. These provide users with facilities for searching electronic card catalogs. In all likelihood, most older VAX machines are at least as secure as their UNIX workstation counterparts. One contributing factor to this trend is the fact that the people who administer it generally understand the VMS platform. If there is a hole in a VMS system it is most likely because the system administrator was either lazy and left it unpatched, or botched a configuration option.


Section: Chapter 24.  VAX/VMS

Security in VMS

Security in VMS is well supported. For example, there is a strong model for access control. (Whether the system administrator properly implements that access control is another matter.) Access control on VMS is at least as comprehensive as that on the Novell NetWare platform. Here are some of the values that can be controlled:

        Time. You can control both the days of the week and the hours of the day at which a user can access a given area of the system. (The default setting enables the user access at any time, 24 hours a day, 7 days a week.) The time access feature works similarly to a firewall: That which is not expressly permitted is denied.

        Mode. This is an interesting feature. You can specify the mode in which a user can connect and interact with the system. Therefore, you can restrict remote network logins to certain times or eliminate them completely. Because this can be done incisively by user, this feature makes remote security much stronger than on many other platforms. You can hardly begin to crack if you are restricted from even logging in. (Next, we'll discuss some utilities that also force callback verification on remote dial-up users.)

        Resources. You can control the resources available to the user at login. This is useful for setting directories beyond which the user might not be able to travel.

This is really just scratching the surface of the access control available in VMS. In fact, there are multiple levels of privileges, and these can be applied to groups. Groups can be restricted to certain resources, and so on. In other words, access control is a complex issue with VMS. There are many, many options. It is for this reason that crackers have a halfway decent chance of finding a hole. Sometimes, complexity can be a security risk in itself. Crackers are well aware of this:

The greatest advantage of VMS is its flexibility. The system manager can choose to implement or ignore a wide range of security features, fortunately for the [cracker], they all seem to ignore the important ones. It is possible to protect all, any or none of the files created. It is also possible to provide general or restricted passwords, or no passwords at all. Access codes can be global or limited. The use log can be ignored, used only for record keeping, or be employed as a security control tool.

The previous paragraph is excerpted from Lex Luthor's Advanced Hacking VAX's VMS (Legion of Doom. June 1, 1985). It can be found online at


It should be noted that the use of groups differs between UNIX and VMS. ACLs, in combination with VMS groups, allow for more granular control over files, directories, volumes, and so on.


Advanced Hacking VAX's VMS is one of the definitive texts on cracking the VMS system. It was authored by Lex Luthor (an alias, of course), who in 1984 established a bulletin board called the Legion of Doom. From this (and through other means), Luthor gathered together a loosely knit cracker group that went by the same name. Legion of Doom pulled off some of the most extraordinary cracks ever done. LoD published many electronic journals on the Internet that simplified the art of cracking, including the LoD Technical Journal. The federal government waged a fleetingly successful war against members of the group. The infamous group is long gone, and today, the activities of the former LoD members are a little piece of Internet folklore.

Perhaps one of the best documents available on the Internet for information on how to secure a VMS box was written by neither a cracker nor a hacker. It is A Practical Exercise in Securing an OpenVMS System, written by Rob McMillan of Prentice Centre, the University Of Queensland. It can be found at

Attacking a VAX (or any VMS-based system) is quite different from attacking a UNIX system. First, the concept of the password file is different and so is its structure. UNIX systems maintain /etc/passwd, which defines the username, password, login shell, and group. In contrast, the VMS system uses a file that defines many other variables, not simply these values, as described in the following:

Every DEC running VMS holds the user profiles in a file called SYSUAF (System User Authorization File). For every user on the system, including the System Manager, there is a record which tells the computer when and how a user can log onto the system. It also gives details of password aging, password lengths and all the facilities that a user has when they are logged on.

The Five Minute Guide to VMS Security: Product Review PC-DEC-AUDIT. AudIT Magazine. 1994.

This comprehensive approach to the password file has its pitfalls. If a cracker gains access to the file and cracks it (using the utilities described later in this chapter), the whole system is subject to breach, then and there. However, the likelihood of that happening is poor.

The user, by the way, is identified through the use of a user identification code (UIC). This is very similar in ways to the UID in UNIX. It identifies the user and what groups that user might belong to. As you might have guessed, the UIC comes from the centralized database:

When you log in to a system, the operating system copies your UIC from your user authorization (UAF) record in the system user authorization file (SYSUAF.DAT) and assigns it to your process. It serves as an identification for the life of the process.

The previous paragraph is excerpted from OpenVMS Guide to System Security: Contents of a User's Security Profile. How Your Process Acquires a UIC, which can be found online at

In 1993, a version of VMS called SEVMS was approved as meeting the criteria for a Class B1 secure operating system. Although the version approved (v6.2) is nowhere close to the latest version of VMS, nor do many organizations outside of the government adhere to this rating system, it's worth mentioning because few operating systems meet this criteria.

You can read more about SEVMS at


Section: Chapter 24.  VAX/VMS

Some Old Vulnerabilities

A discussion of some common vulnerabilities, or holes, follows.

The mount d Hole

If two successive mount -d -s commands are sent within seconds of one another (and before another host has issued such a request), the request will be honored. This was originally reported by CERT in March 1994 and applies to VAX machines running any variant of Digital UNIX.

The Monitor Utility Hole

In VMS there is a utility called Monitor, which monitors classes of systemwide performance data (either from a process already running or from a previously compiled monitor file). The following vulnerability was not a critical one, but did bear some concern:

Unauthorized privileges may be expanded to authorized users of a system under certain conditions, via the Monitor utility. Should a system be compromised through unauthorized access, there is a risk of potential damage to a system environment. This problem will not permit unauthorized access entry, as individuals attempting to gain unauthorized access will continue to be denied through the standard VMS security mechanisms.

The above paragraph is excerpted from a CERT advisory titled VMS Monitor Vulnerability. It can be found online at

The monitor problem was a local problem and not a particularly critical one. For specific information on that hole (and the fix), obtain the Defense Data Network Advisory concerning it at DDN Security Bulletin 9223,

Historical Problems: The Wank Worm Incident

Sometime in the fall of 1989, a worm that compromised machines on DecNet was released. On infected machines, the program would print to the terminal a message that the machine had been "Wanked." The message purported to come from Worms Against Nuclear Killers, or WANK. It was reported in the CERT advisory about the Wank Worm:

This worm affects only DEC VMS systems and is propagated via DecNet protocols, not TCP/IP protocols [as at the time DEC didn't support TCP/IP natively]. If a VMS system had other network connections, the worm was not programmed to take advantage of those connections. The worm is very similar to last year's HI.COM (or Father Christmas) worm.

The previous paragraph is paraphrased from a CERT advisory titled "WANK" Worm On SPAN Network. It can be found online at

In that advisory, an analysis of the worm was provided by R. Kevin Oberman of the Engineering Department of Lawrence Livermore National Laboratory. Oberman's report was apparently generated on-the-fly and in haste, but it was quite complete notwithstanding. He reported that the worm was not incredibly complex but could be dangerous if it compromised a privileged account. The worm would enter a system, check to see whether it was already infected, and, if not, perform some or all of these procedures:

        Disable mail to certain accounts

        Change system passwords, using a random-number generator, and, in doing so, lock out the system operator

        Use the instant system as a launching pad to attack new ones

Within his analysis, Oberman included a quickly hacked program that would halt the march of the Wank Worm. The source of that program can still be examined online in the original advisories at

What's really interesting is the degree of seriousness in the tone of the advisory. Think about it for a moment: It was just less than one year before that the Morris Worm incident sent a ripple through the Net. The mere mention of a worm during those months could cause a panic. Oddly, though, because of the curious name of this particular worm, some administrators initially took the warnings for a joke.

In addition, the Wank Worm was irrelevant to a large portion of the Internet. Because the worm only affected those running DEC protocols (and not TCP/IP), only a limited number of potential victims existed. However, although that number was relatively small in proportion to the entire Internet, there were a great many sites using DecNet.

An interesting treatment of the event can be found in Approaching Zero: The Extraordinary Underworld of Hackers, Phreakers, Virus Writers, and Keyboard Criminals:

The arrival of the worm coincided with reports of protesters in Florida attempting to disrupt the launch of a nuclear-powered shuttle payload. It is assumed that the worm was also a protest against the launch. The WANK Worm spread itself at a more leisurely rate than the Internet Worm, sending out fewer alarms and creating less hysteria. A method for combating the worm was developed by Bernard Perrot of the Institut de Physique Nucleaire at Orsay, France. Perrot's scheme was to create a booby-trapped file of the type that `the worm could be expected to attack. If the worm tried to use information from the file, it would itself come under attack and be blown up and killed.

The previous excerpt is from an article by Paul Mungo and Bryan Glough. It can be found online at


Section: Chapter 24.  VAX/VMS

Auditing and Monitoring

Auditing capabilities in the VMS environment are advanced. There are different ways to implement auditing implementation is usually dependent on the applications and the system administrator's personal preferences. However, by default, VMS will log all logins, failures to login, changes in system privileges, and so forth. The default configuration provides a minimum of logging.

That minimum, however, can be quickly surpassed if need be. The system operator can apply special access controls on individual files and directories, a user account, or processes. When undesirable or suspicious activity occurs in relation to these access control policies, an alarm is generated. The system operator defines what form the alarm will take. (For example, it is common for system operators to redirect alarm information to a specific console so that such messages visibly appear and can be quickly perused at any time.) Of course, severe paranoia in this type of environment can add up to sacrificing a fair amount of disk space.

For example, a system operator can configure the system to generate alarms on a mere attempt to access a file for which the user has no privileges. Users attempting to access the protected file could generate a significant amount of log data. It would be analogous to the issuing of an alarm for each time that a shell user attempted to access a root-owned file or directory on a UNIX system. Interestingly, the alarm can be generated in response to a violation of policies set against the user, as opposed to global restrictions placed on the file. I am not sure which model is actually more secure, but I would guess it would be the VMS model.

The logging capabilities of VMS are quite granular. You can monitor a wide range of events, ranging from users accessing a file to users starting a protocol-based process. (You can even log users attempting to change the time.) In addition to this native monitoring, there are several utilities (some of which I mention later in this chapter) that can trap terminal sessions and monitor them for inactivity and perhaps other undesirable behavior.

Various utilities make it easier to crack the VMS platform or, having cracked it, to avoid detection. As with any other system, these utilities are sometimes of significant advantage to both the root operator and the cracker. The following sections describe some popular cracking utilities.

A hacker with the handle Bagpuss wrote The purpose of is simple: It keeps tabs on users logging in and out of the machine. It is an early warning system that can alert you to when the system operator (or other similarly privileged user) logs on. The source code and full explanation of are located at


Bagpuss also wrote Stealth. The purpose of this utility is to evade detection in the event that someone (the system operator, perhaps) issues the SHOW USER command. This command is much like combining the W, WHO, and PS commands in UNIX. It identifies the users currently logged in to the machine and their status. Stealth prevents the user from being visible on such a query. The source code for Stealth is at


GUESS_PASSWORD is designed to crack the password file of the VMS system. The program works quite well, but you have to wonder about its actual value. These days, it is unlikely that a system administrator would leave the SYSUAF.DAT file unprotected (where the passwords are actually located). However, if a cracker could find such an unprotected password file, this utility would assist in cracking it. GUESS_PASSWORD (with source) is available at


WATCHER is a snooping utility, most commonly used by system administrators. Its purpose is to watch terminal sessions. WATCHER is a good resource from a security point of view. It will monitor how long a terminal has been idle. The system administrator (or the user) can set the time period after which idle sessions can be automatically killed. (Idle terminal sessions are in themselves a security risk. Crackers watch accounts that remain idle for long periods of time. These accounts are deemed good targets.) WATCHER is available at


Checkpass is a tool that examines the relative strength or weakness of a given password in the SYSUAF.DAT file. It's good for versions 5.4 and later. Checkpass is available at


As you might guess, Crypt is a DES encryption module for the VMS operating system. Interestingly, it also provides support for UNIX and DOS. M. Edward Nieland, who wrote these tools primarily in C and FORTRAN, developed it (along with the previous utility). The CRYPT utility is located at


A secure dialback module, DIAL is designed to prevent unauthorized remote users from gaining access to your system. It is explained in the DIAL users guide:

Only pre-authorized users and their work location telephone numbers can gain access to the system through DIAL. After access is granted the user is disconnected from the incoming call and dialed back at the authorized telephone number. This provides the user with free access to his accounts over public telephone lines.

The system works through the maintenance of a file that lists all valid users and their telephone numbers. (Read: This could be one method of circumventing this security. Reach that file, and you reach DIAL.) Roger Talkov at Emulex wrote it in C. DIAL is available at


Written by Robert Eden of Texas Utilities, CALLBACK.EXE performs essentially the same functions as DIAL. It was written in FORTRAN. CALLBACK.EXE is available at


TCPFILTER is a utility that restricts outgoing connect requests. As described in the documentation, the utility does the following:

(It) allows the filtering of outgoing UCX TCP/IP calls. Each attempt to open an outgoing call is verified with a table of addresses, and the call is either allowed or forbidden. The validation of the call can be done with two different mechanisms: with ACL, or with image names. The use of ACL allows controlling each user by the means of an identifier.

The previous paragraph is excerpted from a file titled TCPFILTER.DOC ENGLISH by G. Gerard. It can be found online at The program TCPFILTER itself is available at

I should point out that the term call means an outgoing TCP/IP connect request. That is, you can restrict connect requests to specific IP addresses, based on user information in the Access Control List.


Section: Chapter 24.  VAX/VMS

Changing Times

The VAX/VMS combination was once a very popular one, and as I have already related, OpenVMS is alive and well. However, changes in the computer industry and in public demand have altered the Internet's climate with regard to VMS. In addition, Compaq acquired DEC in early 1998, bringing OpenVMS under the same umbrella as Tru64, along with a market-dominating line of Intel x86-based machines.

While the platform is still supported, with Compaq pushing Windows 2000, NetWare, Linux, and Tru64, VMS is likely to take a backseat. This is especially so with regard to Tru64 because it is a 64-bit system. Imagine for a moment a 64-bit system running at gigahertz speeds on the RISC-based Alpha platform. In my opinion, this configuration is the most powerful currently available to the average user. Such a machine (loaded with at least 512MB of RAM) is vastly superior in my opinion to Pentium-based machines. The days of the old VAX/VMS are probably over.

Today's cracker probably knows little about VMS systems. More concentration has been allotted to UNIX and as of late, Windows NT. If I were going to contract someone to crack a VAX, I would look for someone in his mid-30s or older. Certainly, the advent of the PC has contributed to the lack of VMS security knowledge. Young people today work mostly with PC- or Macintosh-based machines. It is therefore rare to come in contact with a VAX anymore, except at larger libraries or universities.

At day's end, VMS is an interesting, durable, and relatively secure platform. However, DEC was always exceptionally close-mouthed about the security weaknesses of VAX/VMS. If you retrieve all the known advisories on VAX/VMS, you will see that DEC has routinely declined to include information that could potentially be used by crackers. (Most often, DEC would advise VAX users to contact their local DEC representative.) Some might view this as a smart move and one that might have contributed to it traditionally being difficult to crack VAX servers. Others will point at this being more along then lines of "security by obscurity." Regardless, if the system administrator of a VAX has been on his toes and the system kept up to date with patching after a cracker has tried all the default passwords, there is little left to do but turn to social engineering.

Stay on top of security and OpenVMS by watching the OpenVMS home page,, and keeping an eye on the patch site,


Section: Chapter 24.  VAX/VMS


The VAX/VMS system is an antiquated one at this stage of the game. However, it is not out of the scene yet. If you are considering a career in Internet security, you might want to take some brief courses in VMS. If you are like me and prefer the more direct approach, buy a used VAX and set yourself to the task of cracking it. These can often be acquired for practically nothing today in the usenet group. Many sellers even have the original installation media.

In closing, it is my opinion that the security of the VAX is advanced and even somewhat elegant. However, as with all OSs, the name of the game is staying on top of security configurations and prompt patching. In this respect, it's just another OS that needs proper attention to remain secure.


Section: Chapter 24.  VAX/VMS


VAX Security: Protecting the System and the Data. Sandler and Badgett. John Wiley & Sons. 0-471-51507-8.

A Retrospective on the VAX VMM Security Kernel. Paul A. Karger, Mary E. Zurko, Douglas W. Bonin, Andrew H. Mason, and Clifford E. Kahn. IEEE Transactions on Software Engineering, 17(11):1147-1163. November 1991.

Database Security.S. Castano, M. G. Fugini, G. Martella, and P. Samarati. Addison-Wesley Publishing Company. 1995. (Good chapter on VAX/VMS.) 0-201-59375-0.

Security Guidance for VAX/VMS Systems. Debra L. Banning. Sparta, Inc. 14th National Computer Security Conference, Washington, D.C. October 1991.

A Practical Exercise in Securing an OpenVMS System. Rob McMillan. Prentice Centre, The University Of Queensland.

How VMS Keeps Out Intruders. Tanya Candia. Computers & Security, 9(6):499-502. October 1990.

ESNET/DECNET Security Policy Procedures and Guidelines.D. T. Caruso and C. E. Bemis, Jr. ESnet/DecNet Security Revised Draft. December 1989.

Approaching Zero. The Extraordinary Underworld of Hackers, Phreakers, Virus Writers, and Keyboard Criminals. Paul Mungo and Bryan Glough.

VMS Monitor Vulnerability. CERT advisory. CA-92:16. September 22, 1992.


Enterprises - Maximum Security
We Only Played Home Games: Wacky, Raunchy, Humorous Stories of Sports and Other Events in Michigans
ISBN: 0000053155
EAN: 2147483647
Year: 2001
Pages: 38 © 2008-2017.
If you may any questions please contact us: