1 Understanding System Security

Effective operating system security measures help prevent unauthorized access and theft of computer time and any kind of sensitive information, such as marketing plans, formulas, or proprietary software. These measures can also protect equipment, software, and files from damage caused by tampering.

This chapter provides security administrators with an overview of security measures available with the operating system. Part III provides more specific information regarding site security policies, the tasks of security administrators, and methods of protecting site computer systems and resources.

1.1 Types of Computer Security Problems

On any system there can be two types of users: authorized and unauthorized. Any person authorized to use the computer system has the right to access the system and its resources according to the authorization criteria set up by the site security administrator. Usage criteria may include the time of day, types of logins, use of different resources like printers and terminals, and so on. Unauthorized users have no right to use the system at all or only at a given time of day, or they have no right to use certain system resources.

On a computer system, security breaches usually result from one of four types of actions:

• User irresponsibility refers to situations where the user purposely or accidentally causes some noticeable damage. One example would be a user who is authorized to access certain files making a copy of a key file to sell.

There is little that an operating system can do to protect sites from this source of security failure. The problem frequently lies in application design deficiencies or inconsistent use of available controls by users and the security administrator. Sometimes the failure to enforce adequate environmental security unwittingly encourages this type of security problem.

Even the best security system will fail if implemented inconsistently. This, along with the failure to motivate your users to observe good security practices, will make your system vulnerable to security failures caused by user irresponsibility. Chapter 3, Using the System Responsibly discusses what users can do to help maintain system security.

• User probing refers to situations where a user exploits insufficiently protected parts of the system. Some users consider gaining access to a forbidden system area as an intellectual challenge, playing a game of user versus system. Although intentions may be harmless, theft of services is a crime. Users with more serious intent may seek confidential information, attempt embezzlement, or even destroy data by probing. Always treat user probing seriously.

The system provides many security features to combat user probing. Based on security needs, the security administrator implements features on either a temporary or permanent basis. See Chapter 4, Protecting Data for information on protecting data and resources with protection codes and access control lists.

• User penetration refers to situations where the user breaks through security controls to gain access to the system. While the system has security features that make penetration extremely difficult, it is impossible to make any operating system completely impenetrable.

A user who succeeds in penetrating a system is both skilled and malicious. Thus, penetration is the most serious and potentially dangerous type of security breach. With proper implementation of the OpenVMS security features, however, it is also the rarest security breach, requiring unusual skills and perseverance.

• Social engineering refers to situations in which an intruder gains access to a system not by technical means, but by deceiving users, operators, or administrators. Potential intruders may impersonate authorized users over the phone. Potential intruders may request information that gains them access to the system, such as telephone numbers or passwords, or they may request an unwitting operator to perform some action that compromises the security of the system.

As the technical security features of operating systems have strengthened in recent years, social engineering has been a factor in a growing percentage of security incidents. Operator training, administrative procedures, and user awareness are all critical factors to ensure that access is not inadvertently granted to unauthorized persons.

The following chapters explain how to avoid these problems:

• Chapter 7, Managing System Access describes the intrusion detection system and how to set its parameters.

• Chapter 8, Controlling Access to System Data and Resources explains how to augment the protection of system files and resources.

• Chapter 9, Security Auditing explains how to monitor system activity and be notified of malicious activity.

• Chapter 10, System Security Breaches suggests how to handle system intrusions.

• Chapter 3, Using the System Responsibly and Chapter 6, Managing the System and Its Data list topics to include in your site training programs.

1.2 Levels of Security Requirements

Each site has unique security requirements. Some sites require only limited measures because they are able to tolerate some forms of unauthorized access with little adverse effect. At the other extreme are those sites that cannot tolerate even the slightest probing, such as strategic military defense centers. In between are many commercial sites, such as banks.

While there are many considerations in determining your security needs, the questions in Table 1 –1 can get you started. Your answers can help determine the levels of your security needs. Also refer to Section 6.2 for a more specific example of site security requirements.

Table 1–1 Event Tolerance as a Measure of Security Requirements

Question: Could you tolerate the following event?	Level of Security Requirements Based on Toleration Responses
	Low	Medium	High
A user knowing the images being executed on your system	Y	Y	N
A user knowing the names of another user’s files	Y	Y	N
A user accessing the file of another user in the group	Y	Y	N
An outsider knowing the name of the system just dialed into	Y	Y	N
A user copying files of other users	Y	N	N
A user reading another user’s electronic mail	Y	N	N
A user writing data into another user’s file	Y	N	N
A user deleting another user’s file	Y	N	N
A user being able to read sections of a disk that might contain various old files	Y	N	N
A user consuming machine time and resources to perform unrelated or unauthorized work, possibly even playing games	Y	N	N

If you can tolerate most of the events listed, your security requirements are quite low. If your answers are mixed, your requirements are in the medium to high range. Generally, those sites that are most intolerant to the listed events have very high levels of security requirements.

When you review your site’s security needs, do not confuse a weakness in site operations or recovery procedures as a security problem. Ensure that your operations policies are effective and consistent before evaluating your system security requirements.

1.3 Building a Secure System Environment

There are two sources of security problems outside the operating system domain: employee carelessness and facility vulnerability. If you have a careless or malicious employee or your facility is insecure, none of the security measures discussed in this guide will protect you from security breaches.

Most system penetration occurs through these environmental weaknesses. It is much easier to physically remove a small reel of tape than it is to break access protection codes or change file protection.

Compaq strongly encourages you to stress environmental considerations as well as operating system protection when reviewing site security.

This book discusses operating system security measures. When deciding which of these measures to implement, it is important for you to assess site security needs realistically. While instituting adequate security for your site is essential, instituting more security than actually necessary is costly and time-consuming.

When deciding which security measures to apply to your system, remember the following:

• The most secure system is also the most difficult to use.

• Increasing security can increase costs in terms of slower access to data, slower machine operations, and slower system performance.

• More security measures require more personnel time.

The operating system provides the basic mechanisms to control access to the system and its data. It also provides monitoring tools to ensure that access is restricted to authorized users. However, many computer crimes are committed by authorized users with no violation of the operating system’s security controls.

Therefore, the security of your operation depends on how you apply these security features and how you control your employees and your site. By first building appropriate supervisory controls into your application and designing your application with the goal of minimizing opportunities for abuse, you can then implement operating system and site security features and produce a less vulnerable environment. For an example of one organization’s security plan, see Chapter 6, Managing the System and Its Data.

If you require your system to meet the United States government rating of a C2 secure operating system, please refer to Appendix C in this manual.

If you need a higher level of computer security for your OpenVMS secure system, Compaq offers SEVMS, which is the security enhanced version of OpenVMS that provides mandatory access controls to enforce a systemwide security policy.

SEVMS is a U.S. Department of Defense B1-rated secure operating system.

2 OpenVMS Security Model

This chapter presents the concepts that guided the design and implementation of the security features and mechanisms incorporated into the operating system. The intent is to provide a framework for thinking about your total system security picture. Subsequent chapters present details about the security features and their use.

2.1 Structure of a Secure Operating System

In the late 1960s, a great deal of research and development was dedicated to the problem of achieving security in multiuser computer systems. Much of the development work involved attempts to find all the things that could go wrong with a system’s security and then to correct those flaws one by one. It became apparent to the researchers that this process was ineffective; effective system security could result only from a basic model of the structure of a secure computer system. The reference monitor concept was proposed as such a model and gained wide acceptance.

2.1.1 Reference Monitor Concept

According to the reference monitor concept, a computer system can be depicted in terms of subjects, objects, an authorization database, an audit trail, and a reference monitor, as shown in Figure 2 –1. The reference monitor is the control center that authenticates subjects and implements and enforces the security policy for every access to an object by a subject.

Figure 2–1 Reference Monitor

$Q:\ati-artlib\gif\vm-0994a.gif$

The following table describes the elements shown in Figure 2 –1:

Item	Element	Description
1	Subjects	Active entities, such as user processes, that gain access to information on behalf of people.
2	Objects	Passive repositories of information to be protected, such as files.
3	Authorization database	Repository for the security attributes of subjects and objects. From these attributes, the reference monitor determines what kind of access (if any) is authorized.
4	Audit trail	Record of all security-relevant events, such as access attempts, successful or not.

2.1.2 How the Reference Monitor Enforces Security Rules

The reference monitor enforces the security policy by authorizing the creation of subjects, by granting subjects access to objects based on the information in a dynamic authorization database, and by recording events, as necessary, in the audit trail. In an ideal system, the reference monitor must meet the following three requirements:

• Mediate every attempt by a subject to gain access to an object

• Provide a tamperproof database and audit trail that are thoroughly protected from unauthorized observation and modification

• Remain a small, simple, and well-structured piece of software so that it is effective in enforcing security requirements

These are the requirements proposed for systems that are secure even against penetration. In such systems, the reference monitor is implemented by a security-related subset, or security kernel, of the operating system.

2.2 Implementation of the Reference Monitor

While the OpenVMS operating system does not implement the reference monitor as a security-related subset, or security kernel, its interface to users and system managers does mirror the basic structure dictated by the reference monitor concept. Experience shows that incorporating such a structure is the best way to build a system resistant to probing and to most attempts at penetration.

The following sections describe the OpenVMS operating system’s implementation of the reference monitor model.

2.2.1 Subjects

Subjects are the users or user agents (the user processes) that access information and, in some cases, may be prevented from accessing information. Subjects can be interactive processes, network processes, or batch jobs, and:

• Must pass security controls

During process creation

During information access

• Require identification

User names

Passwords

User identification codes

Rights identifiers

When a user logs in to use the operating system interactively or when a batch or network job starts, the operating system creates a process that includes the identity of the user. That process gains access to information as the agent for the user, as described in Chapter 4, Protecting Data.

Processes are vulnerable to security breaches while they are being created and while they are accessing information. The system manages process access to information by using its authorization data and internal mechanisms, such as hardware controls. Because process creation has many areas of security vulnerability, many operating security features concentrate on the area of process (or subject) creation.

When a user attempts to log in to a system, the user provides a user name (a name that will be given to the resulting process) and a password. The password serves as an authenticator that should be known only to the user and to the operating system.

Because a short or obvious password is likely to fail this requirement, the system incorporates many password protection mechanisms that can be invoked by the user or required by the security administrator (see Chapter 7, Managing System Access). The operating system is also capable of limiting the number of attempts that an intruder can make to guess a password.

The file of users’ passwords is part of the security database that must be protected from unauthorized observation and modification. The system meets this requirement by storing the passwords in a file protected from general access, the system user authorization file (SYSUAF.DAT). The system takes the additional precaution of storing passwords in an encoded form that is hard to use if stolen.

Once the operating system creates a process for a user, it assigns a user identification code or UIC from the user authorization record to that process. The UIC corresponds to the name of the user who created the process (as authenticated by the user’s password). In addition, the UIC indicates the user’s membership in a group that can correspond to the user’s department, project, or function. The system can also attach additional information to the process regarding the creation of the process and the affiliation of the process owner with other groups. This additional information plays a part in the application of the authorization database. (Both Chapter 4, Protecting Data and Chapter 8, Controlling Access to System Data and Resources discuss UICs.)

2.2.2 Objects

In the reference monitor concept, objects are passive repositories of information. In the OpenVMS system, there are many objects, such as files and devices, that are subject to protection, as described in Table 2 –2. The operating system protects objects from unauthorized access and provides a variety of mechanisms (described in Chapter 4, Protecting Data and Chapter 5, Descriptions of Object Classes ) for sharing them in a controlled manner. These mechanisms are also used to control access to system resources.

Table 2–2 Objects Protected by Security Controls

Class Name	Definition
Capability	A resource to which the system controls access; currently, the only defined capability is the vector processor.
Common event flag cluster	A set of 32 event flags that enable cooperating processes to post event notifications to each other.
Device	A class of peripherals connected to a processor that are capable of receiving, storing, or transmitting data.
File	Files-11 On-Disk Structure Level 2 (ODS-2) files and directories.
Group global section	A shareable memory section potentially available to all processes in the same group.
Logical name table	A shareable table of logical names and their equivalence names for the system or a particular group.
Queue	A set of jobs to be processed in a batch, terminal, server, or print job queue.
Resource domain	A namespace controlling access to the lock manager’s resources.
Security class	A data structure containing the elements and management routines for all members of the security class.
System global section	A shareable memory section potentially available to all processes in the system.
Volume	A mass storage medium, such as a disk or tape, that is in ODS-2 format. Volumes contain files and may be mounted on devices.

2.2.3 Authorization Database

According to the reference monitor model, each subject’s authorization to gain access to an object is based on an abstract authorization database. This database is a set of dynamic security attributes that govern a subject’s access to an object at any given time. In the OpenVMS system, the database is distributed and stored in association with the objects that must be protected. For example, the authorization data for a file or directory is stored in the file header for that file or directory. summarizes the information stored in the authorization database.

File	Contents	Data Used to Interpret
#SYSUAF.DAT	User names	Logins
	Passwords	Logins
	UICs	Access control checks
#NETPROXY.DAT	User names	Logins
#NET$PROXY.DAT	User names	Logins
#RIGHTSLIST.DAT	Rights identifiers	Access control checks
#VMS$OBJECTS.DAT	UICs	Access control checks
	Protection codes	Access control checks
	Access control lists	Access control checks
#VMS$AUDIT_ #SERVER.DAT	Auditable events	Reporting of events

As Section 2.2.2 suggests, different objects in the OpenVMS system can be shared with differing levels of flexibility. Protected objects are subject to a protection code. This code specifies whether access is allowed or denied to processes run on behalf of system users, the user who is owner of the object, other members of the UIC group of the owner, and all other users.

In addition to the protection code, objects can be shared under control of access control lists (ACLs). ACLs provide a finer granularity of access control than UIC-based protection, especially for user groups or subsets of groups. ACLs list individual users or groups of users who are to be allowed or denied particular types of access to the object. ACLs specify sharing on the basis of UIC identification as well as other groupings or identifiers that can be associated with a process. For example, it is possible to specify that a file should never be read by a process connected to a terminal on a dialup line. Section 2.2.6 uses an access matrix to explain the concept of an ACL. Section 4.4 gives a general discussion of ACLs and identifiers, and Chapter 8, Controlling Access to System Data and Resources explains how you, as security administrators, can create identifiers and construct ACLs for system resources.

2.2.4 Audit Trail

All security-relevant events can be recorded in an audit log file, sent to an operator terminal, or both. A terminal can be designated as a security operator terminal where all auditable events can be displayed. An audit log file provides a permanent record of security events. Many times a security administrator can find a pattern of activity, called an audit trail, by studying the log file.

The operating system audits the classes of security events shown in Table 2 –4 by default. You can select other events for auditing, such as volume mounts or changes to system time.

Table 2–4 Security Auditing Overview

Destination	Events Audited by Default
Log file or terminal display	Authorization database changes
	Intrusion attempts
	Login failures
	Use of DCL command SET AUDIT
	Events triggered by Audit or Alarm ACEs

The audit log allows users and security administrators to record many events. Because it is time-consuming to examine every event, it is most efficient to audit events that will contribute the most information to your security picture. See Chapter 9, Security Auditing for a description of security auditing.

2.2.5 Reference Monitor

In the OpenVMS operating system, the executive performs the role of the reference monitor. All system programs that run in kernel and executive mode help implement the reference monitor, as do the command line interpreter and certain user-mode images that run with privilege. While the volume of code comprising the executive is large, Compaq attempts to ensure that none of the code can be used to bypass system security.

Some privileges can grant a user the authority to modify or subvert the reference monitor. For example, a process with the CMKRNL privilege can execute code of its own within the system kernel, gaining access to the reference monitor’s internal data and the internal representation of protected objects. Clearly, granting such critical privileges should be severely limited.

Similarly, give privileges such as SYSPRV and SECURITY only to users whose processes help maintain the reference monitor and authorization database.

2.2.6 Authorization Database Represented as an Access Matrix

The reference monitor model specifies an authorization database, which describes all access authorizations in the system for all subjects and all objects. This database is often represented as an access matrix, which lists subjects on one axis and objects on the other (see Figure 2 –2). Each crosspoint in the matrix thus represents the access that one subject has to one object.

Figure 2–2 Authorization Access Matrix

$Q:\ati-artlib\gif\vm-0995a.gif$

In this access matrix, an asterisk (*) denotes that the subject has access to that object. (Different types of access, such as read and write, are omitted from this example for simplicity.) Thus, subjects B, C, and D all have access to objects W, X, and Y. In addition, subject A has access to objects W and Z, subject D to object V, and subject E to object V.

Breaking up the access matrix by rows yields a capability-based model, in which each subject carries a list of the objects that it can access. Thus, a capability representation of this access matrix would appear as follows:

A: W, Z
B: W, X, Y
C: W, X, Y
D: V, W, X, Y
E: V

It is also possible to break up the access matrix by columns, listing for each object the subjects that have access to it. This results in an authority-based model, implemented in the OpenVMS system by ACLs (see Chapter 4, Protecting Data). The ACL representation appears as follows:

V: D, E
W: A, B, C, D
X: B, C, D
Y: B, C, D
Z: A

The ACL and identifier controls used by the operating system combine the properties of both the capability- and authority-based systems. In OpenVMS systems, both subjects and objects carry identifiers. Subjects can access objects if they have matching identifiers and if the objects’ access statements grant the requested access.

The result of combining properties of the capability- and authority-based systems is an extremely powerful and flexible system capable of representing complex access matrixes in a compact and convenient manner. Consider what happens to the previous example of an access matrix when some of the cross-points have labels, as shown in Figure 2 –3 .

Figure 2–3 Authorization Access Matrix with Labeled Cross-Points

$Q:\ati-artlib\gif\vm-0996a.gif$

Some labeled cross-points can be grouped and treated as a single entity. Thus, the points that are labeled Q in Figure 2 –3 represent the access that subjects B, C, and D have to objects W, X, and Y. All the Q points can be considered as a single area of interest. The system provides the concept of identifiers to take practical advantage of this grouping of areas of interest.

You can define identifiers to represent the two groups of access, P and Q, in Figure 2 –3. Note that two of the cross-points in the matrix remain unlabeled. Identifiers can also represent individual subjects and thus allow the traditional ACL facility.

To represent the access matrix, the OpenVMS operating system uses two structures, one for each dimension:

• The rights list (RIGHTSLIST.DAT) represents the rows of the access matrix and thus corresponds to the capability-based model. For the matrix in Figure 2 –3, you would need the following rights list:

B: Q
C: Q
D: P, Q
E: P

• ACLs for the protected objects represent the columns of the access matrix. For this example, you would need the following ACLs:

V: P
W: A, Q
X: Q
Y: Q
Z: A

Note that the system structures required to represent the access matrix are simpler than either the traditional capability- or authority-based model and require fewer terms in total. In the example, the difference is slight. However, complexity of the access matrix increases with the square of its size.

2.3 Summary: System Security Design

When designing an overall system security plan, ask yourself the following questions:

• How are users associated with subjects? What is the reliability of the authentication mechanism?

• What objects contain sensitive information in this system or application? Is access to those objects controlled?

• Does the authorization database reflect the site’s security policy? Who is authorized to gain access to sensitive objects? Are adequate restrictions in place?

• Is the audit trail recording enough or too much information? Who will monitor it? How often will it be examined?

• What programs are functioning as part of the reference monitor? Which users can modify the security policy and the authorization database? Is this the desired configuration?

These considerations, as well as the underlying reference monitor design, apply equally to a timesharing system, a widespread network, or a single application on a system that grants access to records in a file or database. The operating system provides general mechanisms that users and security administrators must apply to achieve system security. See Chapter 6, Managing the System and Its Data for more information on designing and implementing a security policy.

3 Using the System Responsibly

This chapter provides basic information on how to use the system securely. If you apply this knowledge consistently and accurately, while observing your site’s specific security policies, you can make the difference between a secure system and one that is vulnerable to unauthorized users.

3.1 Choosing a Password for Your Account

To choose a secure password, use the following guidelines:

• Include both numbers and letters in the password. Although a 6-character password that contains only letters is secure, a 6-character password with both letters and numbers is much more secure.

• Choose passwords that contain 6 to 10 characters. Adequate length makes passwords more secure. You can choose a password as long as 32 characters.

• Do not select passwords from a dictionary or from your native language.

• Avoid choosing words readily associated with your computer site or yourself, such as the name of a product or the model of your car.

• Choose new passwords each time. Do not reuse old ones.

Your security administrator may set up additional restrictions, for example, not allowing passwords with fewer than 10 characters.

Table 3 –1 provides examples of secure as opposed to risky passwords.

Table 3–1 Secure and Insecure Passwords

Secure Passwords	Insecure Passwords
Nonsense syllables: aladaskgam eojfuvcue joxtyois	Words with a strong personal association: your name the name of a loved one the name of your pet the name of your town the name of your automobile
A mixed string: 492_weid $924spa zu_$rags	A work-related term: your company name a special project your work group name

3.1.1 Obtaining Your Initial Password

Typically, when you learn that an account has been created for you on the system, you are told whether a user password is required. If user passwords are in effect, you are told to use a specific password for your first login. This password has been placed in the system user authorization file (SYSUAF.DAT) with other information about how your account can be used.

It is inadvisable to have passwords that can be easily guessed. Ask the person creating an account for you to specify a password that is difficult to guess. If you have no control over the password you are given, you might be given a password that is the same as your first name. If so, change it immediately after you log in. (The use of first or last names as passwords is a practice so well known that it is undesirable from a security standpoint.)

Log in to your account soon after it is created to change your password. If there is a time lapse from the moment when your account is created until your first login, other users might log in to your account successfully, gaining a chance to damage the system. Similarly, if you neglect to change the password or are unable to do so, the system remains vulnerable. Possible damage depends largely on what other security measures are in effect.

At the time your account is created, you should also be told a minimum length for your password and whether you can choose your new password or let the system generate the password for you.

3.1.2 Observing System Restrictions on Passwords

The system screens passwords for acceptability, as follows:

• It automatically compares new passwords to a system dictionary. This helps to ensure that a password is not a native language word.

• It maintains a history list of your old passwords and compares each new password to this list to be sure that you do not reuse an old password.

• It enforces a minimum password length, which the system manager specifies in your UAF record.

3.2 Knowing What Type of Password to Use

There are several types of passwords recognized by the OpenVMS operating system. In general, you need to provide a user password when you log in. In some cases, you might also need to provide a system password to gain access to a particular terminal before logging in with your user password. If you are using a system with high security requirements, you might need to provide a primary password and a secondary password.

If you are an externally authenticated user with external authentication enabled on your system, you enter your LAN Manager password at the OpenVMS password prompt. See Section 7.4 for more information. Table 3 –2 describes each type of password.

Table 3–2 Types of Passwords

Password	Description
User password	Required for most accounts. After you enter your user name, you are prompted for a password. If the account requires both primary and secondary passwords, you must enter two passwords.
System password	Controls access to particular terminals and is required at the discretion of the security administrator. System passwords are usually necessary to control access to terminals that might be targets for unauthorized use, such as dialup and public terminal lines.
Primary password	The first of two user passwords to be entered for an account requiring both primary and secondary passwords.
Secondary password	The second of two user passwords to be entered for an account requiring both primary and secondary passwords. The secondary password provides an additional level of security on user accounts. Typically, the general user does not know the secondary password; a supervisor or other key person must be present to supply it. For certain applications, the supervisor may also decide to remain present while the account is in use. Thus, secondary passwords facilitate controlled logins and the actions taken after a login. Secondary passwords can be time-consuming and inconvenient. They are justified only at sites with maximum security requirements. An example of an account that justifies dual passwords would be one that bypasses normal access controls to permit emergency repair to a database.

3.2.1 Entering a System Password

Your security administrator will tell you if you must specify a system password to log in to one or more of the terminals designated for your use. Ask your security administrator for the current system password, how often it changes, and how to obtain the new system password when it does change.

To specify a system password, do the following:

1. Press the Return key until the terminal responds with the recognition character, which is normally a bell.

[Return]
<bell>

2. Enter the system password, and press Return.

[Return]

As this example shows, there is no prompt and no echo of the characters you type. If you fail to specify the correct system password, the system does not notify you. (Initially, you might think the system is malfunctioning unless you know that a system password is required at that terminal.) If you do not receive a response from the system, assume that you have entered the wrong password, and try again.

3. When you enter the correct system password, you receive the system announcement message, if there is one, followed by the Username: prompt.

For example:

MAPLE - A member of the Forest Cluster
Unauthorized Access Is Prohibited

Username:

3.2.2 Entering a Secondary Password

Your security administrator decides whether to require the use of secondary passwords for your account at the time your account is created. When your account requires primary and secondary passwords, you need two passwords to log in. Minimum password length, which the security administrator specifies in your UAF record, applies to both passwords.

An example of a login requiring primary and secondary passwords follows:

WILLOW - A member of the Forest Cluster
Welcome to OpenVMS on node WILLOW

Username: RWOODS
Password: [Return]
Password: [Return]

Last interactive login on Friday, 11-DEC-2001 10:22
$

As with a single password login, the system allots a limited amount of time for the entire login. If you do not enter a secondary password in time, the login period expires.

3.3 Password Requirements for Different Types of Accounts

Five types of user accounts are available on OpenVMS systems:

• Accounts secured with passwords that you or the security administrator change periodically. This account type is the most common.

• Accounts secured with authentication cards that have your password programmed onto the device. Many third-party products support this type of authentication mechanism.

• Accounts that always require passwords but prohibit you from changing the password. By locking the password (setting the LOCKPWD flag in the UAF record), the security administrator controls all changes made to the password.

• Restricted accounts limit your use of the system and sometimes require a password.

• Open accounts require no password; the password is null. When you log in to an open account, the system does not prompt you for a password, and you do not need to enter one. You can begin entering commands immediately. Because open accounts allow anyone to gain access to the system, they are used only at sites with minimal security requirements and should normally be set up as restricted accounts.

3.4 Types of Logins and Login Classes

Logins can be either interactive or noninteractive. When you log in interactively, you enter an OpenVMS user name and a password. In noninteractive logins, the system performs the identification and authentication for you; you are not prompted for a user name and password. (The term interactive, as used here, differs from an interactive mode process defined by the DCL lexical function F$MODE(). For a description of the F$MODE function, see the OpenVMS DCL Dictionary.)

In addition to interactive and noninteractive logins, the OpenVMS operating system recognizes different classes of logins. How you log in to the system determines the login class to which you belong. Based on your login class, as well as the time of day or day of the week, the system manager controls your access to the system.

3.4.1 Logging In Interactively: Local, Dialup, and Remote Logins

Interactive logins include the following login classes:

• Local

You log in from a terminal connected directly to the central processor or from a terminal server that communicates directly with the central processor.

• Dialup

You log in to a terminal that uses a modem and a telephone line to make a connection to the computer system. Depending on the terminal that your system uses, you might need to execute a few additional steps. Your site security administrator can give you the necessary details.

• Remote

You log in to a node over the network by entering the DCL command SET HOST. For example, to access the remote node HUBBUB, you enter the following command:

$ SET HOST HUBBUB

If you have access to an account on node HUBBUB, you can log in to that account from your local node. You have access to the facilities on node HUBBUB, but you remain physically connected to your local node.

3.4.2 Logging In Using External Authentication

If you are an externally authenticated user, you log in by entering your LAN Manager user ID and password at the OpenVMS login prompts. Your LAN Manager user ID may or may not be the same as your OpenVMS user name.

See Section 7.4 for more information on logging in with external authentication enabled on your system.

3.4.3 Reading Informational Messages

When you log in from a terminal that is directly connected to a computer, the OpenVMS system displays informational system messages. Local Login Messages illustrates most of these messages.

Example 3–1 Local Login Messages

WILLOW - A member of the Forest Cluster     1

        Unlawful Access is Prohibited

Username:  RWOODS
Password:
    You have the following disconnected process:     2
Terminal   Process name    Image name
VTA52:     RWOODS          (none)
Connect to above listed process [YES]: NO
         Welcome to OpenVMS on node WILLOW     3
    Last interactive login on Wednesday,  1-DEC-2001 10:20     4
    Last non-interactive login on Monday, 30-NOV-2001 17:39    5

        2 failures since last successful login     6

          You have 1 new mail message.     7

$

1 . The announcement message identifies the node (and, if relevant, the cluster). It may also warn unauthorized users that unlawful access is prohibited. The system manager or security administrator can control both the appearance and the content of this message.

2 . A disconnected job message informs you that your process was disconnected at some time after your last successful login but is still available. You have the option of reconnecting to the old process and returning your process to its state before you were disconnected.

. The system displays the disconnected job message only when the following conditions exist:

• The terminal where the interruption occurred is set up as a virtual terminal.

• Your terminal is set up as one that can be disconnected.

• During a recent session, your connection to the central processing unit (CPU) through that terminal was broken before you logged out.

. In general, the security administrator should allow you to reconnect to a disconnected job because this ability poses no special problems for system security. However, the security administrator can disable this function by changing the setup on terminals and by disabling virtual terminals on the system.

3 . A welcome message indicates the version number of the OpenVMS operating system that is running and the name of the node on which you are logged in. The system manager can choose a different message or can suppress the message entirely.

4 . The last successful interactive login message provides the time of the last completed login for a local, dialup, or remote login. (The system does not count logins from a subprocess whose parent was one of these types.)

5 . The last successful noninteractive login message provides the time the last noninteractive (batch or network) login finished.

6 . The number of login failures message indicates the number of failed attempts at login. (An incorrect password is the only source of login failure that is counted.) To attract your attention, a bell rings after the message appears.

7 . The new mail message indicates if you have any new mail messages.

A security administrator can suppress the announcement and welcome messages, which include node names and operating system identification. Because login procedures differ from system to system, it is more difficult to log in without this information.

The last login success and failure messages are optional. Your security administrator can enable or disable them as a group. Sites with medium-level or high-level security needs display these messages because they can indicate break-in attempts. In addition, by showing that the system is monitoring logins, these messages can be a deterrent to potential illegal users.

Each time you log in, the system resets the values for the last successful login and the number of login failures. If you access your account interactively and do not specify an incorrect password in your login attempts, you may not see the last successful noninteractive login and login failure messages.

3.4.4 When the System Logs In for You: Network and Batch Logins

Noninteractive logins include network logins and batch logins.

The system performs a network login when you start a network task on a remote node, such as displaying the contents of a directory or copying files stored in a directory on another node. Both your current system and the remote system must be nodes in the same network. In the file specification, you identify the target node and provide an access control string, which includes your user name and password for the remote node.

For example, a network login occurs when user Greg, who has an account on remote node PARIS, enters the following command:

$ DIRECTORY PARIS"GREG 8G4FR93A"::WORK2:[PUBLIC]*.*;*

This command displays a listing of all the files in the public directory on disk WORK2. It also reveals the password 8G4FR93A. A more secure way to perform the same task would be to use a proxy account on node PARIS. For an example of a proxy login, see Section 3.9.2.

The system performs a batch login when a batch job that you submitted runs. Authorization to build the job is determined at the time the job is submitted. When the system prepares to execute the job, the job controller creates a noninteractive process that logs in to your account. No password is required when the job logs in.

3.5 Login Failures: When You Are Unable to Log In

Logins can fail for any number of reasons. One of your passwords might have changed, or your account might have expired. You might be attempting to log in over the network or from a modem but be unauthorized to do so. Table 3 –3 summarizes common reasons for login failure.

Table 3–3 Reasons for Login Failure

Failure Indicator	Reason
No response from the terminal.	A defective terminal, a terminal that requires a system password, a terminal that is not powered on, or a communications problem caused by defective wiring or by a misconfigured or malfunctioning modem.
No response from any terminal.	The system is down or overloaded.
No response from the terminal when you enter the system password.	The system password changed.
System messages:
“User authorization failure”	A typing error in your user name or password. The account or password expired.
“Not authorized to log in from this source”	Your particular class of login (local, dialup, remote, interactive, batch, or network) is prohibited.
“Not authorized to log in at this time”	You do not have access to log in during this hour or this day of the week.
“User authorization failure” (and no known user failure occurred)	An apparent break-in has been attempted at the terminal using your user name, and the system has temporarily disabled all logins at that terminal by your user name.

The following sections describe the reasons for login failure in more detail.

3.5.1 Using a Terminal That Requires a System Password

You cannot log in if the terminal you attempt to use requires a system password and you are unaware of the requirement. All attempts at logging in fail until you enter the system password.

If you know the system password, perform the steps described in Section 3.2.1. If your attempts fail, it is possible that the system password has been changed. Move to a different terminal that does not require a system password, or request the new system password.

If you do not know the system password and you suspect that this is the problem, try logging in at another terminal.

3.5.2 Observing Your Login Class Restrictions

If you attempt a class of login that is prohibited in your UAF record, your login fails. For example, your security administrator can restrict you from logging in over the network. If you attempt a network login, you receive a message stating that you are not authorized to log in from this source.

Network jobs are not terminated when the allocated work shift for network jobs is exceeded. This restriction applies only to new network connections, not to existing ones.

Your security administrator can restrict your logins to include or exclude any of the following classes: local, remote, dialup, batch, or network. (For a description of these classes, see Section 3.4.1 and Section 3.4.4.)

3.5.3 Using an Account Restricted to Certain Days and Times

Another cause of login difficulty is failure to observe your shift restrictions. A system manager or security administrator can control access to the system based on the time of day or the day of the week. These restrictions are imposed on classes of logins. The security administrator can apply the same work-time restrictions to all classes of logins or choose to place different restrictions on different login classes. If you attempt a login during a time prohibited for that login class, your login fails. The system notifies you that you are not authorized to log in at this time.

When shift restrictions apply to batch jobs, jobs you submit that are scheduled to run outside your permitted work times are not run. The system does not automatically resubmit such jobs during your next available permitted work time. Similarly, if you have initiated any kind of job and attempt to run it beyond your permitted time periods, the job controller aborts the uncompleted job when the end of your allocated work shift is reached. This job termination behavior applies to all jobs.

3.5.4 Failing to Enter the Correct Password During a Dialup Login

Your security administrator can control the number of chances you are given to enter a correct password during a dialup login before the connection is automatically broken.

If your login fails and you have attempts remaining, press the Return key and try again. You can do this until you succeed or reach the limit. If the connection is lost, you can redial the access line and start again.

The typical reason for limiting the number of dialup login failures is to discourage unauthorized users attempting to learn passwords by trial and error. They already have the advantage of anonymity because of the dialup line. Of course, limiting the number of tries for each dialup does not necessarily stop this kind of intrusion. It only requires the would-be perpetrator to redial and start another login.

3.5.5 Knowing When Break-In Evasion Procedures Are in Effect

If anyone has made a number of failed attempts to log in at the same terminal with your user name, the system concludes that an intruder is attempting to gain illegal access to the system by using your user name.

At the discretion of your security administrator, break-in evasion measures can be in effect for all users of the system. The security administrator controls how many password attempts are allowed over what period of time. Once break-in evasion tactics are triggered, you cannot log in to the terminal---even with your correct password---during a defined interval. Your security administrator can tell you how long you must wait before reattempting the login, or you can move to another terminal to attempt a login.

If you suspect that break-in evasion is preventing your login and you have not personally experienced any login failures, you should contact your security administrator immediately. Together, you should attempt another login and check the message that reveals the number of login failures since the last login to confirm or deny your suspicion of intrusion attempts. (If your system does not normally display the login message, your security administrator can use the Authorize utility (AUTHORIZE) to examine the data in your UAF record.) With prompt action, your security administrator can locate someone attempting logins at another terminal.

3.6 Changing Your Password

Changing passwords on a regular basis promotes system security. To change your password, enter the DCL command SET PASSWORD.

The system manager can allow you to select a password on your own or can require that you use the automatic password generator when you change your password. If you select your own password, note that the password must follow system restrictions on length and acceptability (see Section 3.1.2). For example, if your password choice is too short, the system displays the following message:

%SET-E-INVPWDLEN, invalid password length - password not changed

Section 3.1 provides guidelines and examples for specifying secure passwords.

There is no restriction on how many times you can change your password in a given period of time.

3.6.1 Selecting Your Own Password

If your system manager does not require use of the automatic password generator, the SET PASSWORD command prompts you to enter the new password. It then prompts you to reenter the new password for verification, as follows:

$ SET PASSWORD
[Return]
New password:
Verification:

If you fail to enter the same password twice, the password is not changed. If you succeed in these two steps, there is no notification. The command changes your password and returns you to the DCL prompt.

Even though your security administrator may not require the password generator, you are strongly encouraged to use it to promote the security of your system. Section 3.6.2 describes how to use generated passwords.

3.6.2 Using Generated Passwords

If your system security administrator decides that you must let the system generate the password for you automatically, the system provides you with a list of password choices when you enter the DCL command SET PASSWORD. (When the system does not require generated passwords, add the /GENERATE qualifier to SET PASSWORD for a list of password choices.) The character sequence resembles native language words to make it easy to remember, but it is unusual enough to be difficult for outsiders to guess. Because system-generated passwords vary in length, they become even more difficult to guess.

$Q:\adept8\entities\note.eps$ Note

The password generator uses basic syllabic rules to generate words but has no real knowledge of any language. As a result, it can unintentionally produce words that are offensive.

In the following OpenVMS VAX example, the system automatically generates a list of passwords made up of random sequences of characters. The minimum password length for the user in the following example has been set to 8 in the UAF record.

$ SET PASSWORD
Old password:
[Return]   1
reankuna      rean-ku-na    2
cigtawdpau    cig-tawd-pau
adehecun      a-de-he-cun
ceebatorai    cee-ba-to-rai
arhoajabad    ar-hoa-ja-bad
Choose a password from this list, or press Return to get a new list 3
New password:
[Return]    4
Verification:
[Return]    5
$     6

The preceding example illustrates the following:

1 . The user correctly specifies the old password and presses the Return key.

2 . The system responds with a list of five password choices ranging in length from 8 to 10 characters. There are representations of the same word divided into syllables to the right of each password choice. Usually the password that is easiest to pronounce is easiest to remember and, therefore, the best choice.

3 . The system informs the user that it is possible to request a new list by pressing the Return key in response to the prompt for a new password.

4 . The user enters one of the first five possible passwords and presses the Return key.

5 . The system recognizes that this password is one provided by the automatic password generator and responds with the verification prompt. The user enters the new password again and presses Return.

6 . The system changes the password and responds with the DCL prompt.

One disadvantage of automatic password generation is the possibility that you might not remember your password choice. However, if you dislike all the password choices in your list or think none are easy to remember, you can always request another list.

A more serious drawback of automatic password generation is the potential disclosure of password choices from the display the command produces. To protect your account, change your password in private. If you perform the change on a video terminal, clear the display of password choices from the screen after the command finishes. If you perform the change in a DECwindows environment, use the Clear Lines Off Top option from the Commands menu to remove the passwords from the screen recall buffer. If you use a printing terminal, properly dispose of all hardcopy output.

If you later realize that you failed to protect your password in these ways, change your password immediately. Depending on site policy or your own judgment concerning the length of time your account was exposed, you might decide to notify your security administrator that a security breach could have occurred through your account.

3.6.3 Changing a Secondary Password

To change a secondary password, use the DCL command SET PASSWORD/SECONDARY. You are prompted to specify the old secondary password and the new secondary password, just as in the procedure for changing the primary password. To remove a secondary password, press the Return key when you are prompted for a new password and verification.

You can change primary and secondary passwords independently, but both are subject to the same change frequency because they share the same password lifetime. See Section 3.7 for information on password lifetimes.

3.6.4 Changing Your Password As You Log In

Even if your current password has not yet expired, you can change your password when you log in to the system by including the /NEW_PASSWORD qualifier with your user name, as follows:

WILLOW - A member of the Forest Cluster

Username: RWOODS/NEW_PASSWORD
Password:
         Welcome to OpenVMS on node WILLOW
            Last interactive login on Tuesday, 7-NOV-2001 10:20
            Last non-interactive login on Monday, 6-NOV-2001 14:20

Your password has expired; you must set a new password to log in
New password:
Verification:

Entering the /NEW_PASSWORD qualifier after your user name forces you to set a new password immediately after login.

3.7 Password and Account Expiration Times

Your system manager can set up your account so that your password, or the account itself, expires automatically on a particular date and time. Password expiration times promote system security by forcing you to change your password on a regular basis. Account expiration times help to ensure that accounts are available only for as long as they are needed.

3.7.1 Changing an Expired Password

As you approach the expiration time of your password, you receive an advance warning message. The message first appears 5 days before the expiration date and at each subsequent login. The message appears immediately below the new mail message and sounds the bell character on your terminal to attract your attention. The message indicates that your password is expiring, as follows:

WARNING -- Your password expires on Thursday 19-DEC-2001 15:00

If you fail to change your password before it expires, you receive the following message when you log in:

Your password has expired; you must set a new password to log in
New password:

The system prompts you for a new password or, if automatic password generation is enabled, asks you to select a new password from those listed (see Section 3.6.2). You can abort the login by pressing Ctrl/Y. At your next login attempt, the system again prompts you to change your password.

When You Are Using a Secondary Password

If secondary passwords are in effect for your account (see Section 3.2), the secondary password may expire at the same time as the primary one. You are prompted to change both passwords. If you change the primary password and press Ctrl/Y before changing the secondary password, the login fails. The system does not record a password change.

When You Fail to Change Your Password

If the system manager decides not to force you to change your expired password upon logging in, you receive one final warning when you log in after your password expires, as follows:

WARNING -- Your password has expired; update immediately with
SET PASSWORD!

At this point, if you do not change the password or if the system fails before you have the opportunity to do so, you will be unable to log in again. To regain access, see your system manager.

3.7.2 Renewing an Expired Account

If you need your account for a specific purpose for a limited time only, the person who creates your account may specify a period of time after which the account lapses. For example, student accounts at universities are typically authorized for a single semester at a time.

The system automatically denies access to expired accounts. You receive no advance warning message before the account expiration date, so it is important to know in advance your account duration. The account expiration resides in the UAF record, which can be accessed and displayed only through the use of the Authorize utility (AUTHORIZE) by users with the SYSPRV privilege or equivalent---normally, your system manager or security administrator.

When your account expires, you receive an authorization failure message at your next attempted login. If you need an extension, follow the procedures defined at your site.

3.8 Guidelines for Protecting Your Password

Illegal system access through the use of a known password is most often caused by the owner’s disclosing the password. It is vital that you do not reveal your password to anyone.

You can best protect your password by observing the following rules:

• Select reasonably long passwords that cannot be guessed easily. Avoid using words in your native language that appear in a dictionary. Consider including numbers in your password. Alternatively, let the system generate passwords for you automatically.

• Never write down your password.

• Never give your password to another user. If another user obtains your password, change it immediately.

• Do not include your password in any file, including the body of an electronic mail message. (If anyone else reveals a password to you, delete the information promptly.)

The character strings that appear with your actual password can make it easy for someone to find your password in a file. For example, a quotation mark followed by two colons ("::) always comes after a user name and password in an access control string. Someone attempting to break into the system could obtain your password by searching inadequately protected files for this string. Another way in which you might reveal your password is by using the word “password” in a text file, for example:

My password is GOBBLEDYGOOK.

• If you submit a batch job on cards, do not leave your password card where others may be able to obtain your password from it.

• Do not use the same password for accounts on different systems.

An unauthorized user can try one password on every system where you have an account. The account that first reveals the password might hold little information of interest, but another account might yield more information or more privileges, ultimately leading to a far greater security breach.

• Before you log in to a terminal that is already on, invoke the secure terminal server feature (if enabled) by pressing the Break key. The secure server ensures that the OpenVMS login program is the only program able to receive your login and thereby eliminates the possibility of revealing a password to a password grabber program. This is particularly relevant when you are working in a public terminal room.

A password grabber program is a special program that displays an empty video screen, a screen that appears to show the system has just been initialized after a crash, or a screen that shows a nonexistent logout. When you attempt to log in, the program runs through the normal login sequence so you think you are entering your user name and password in a normal manner. However, once the program receives this key information and passes it on to the perpetrator, it displays a login failure. You might think you mistyped your password and be unaware that you have just revealed it to someone else.

• Unless you share your password, change it every 3 to 6 months. Compaq warns against sharing passwords. If you do share your password, change it every month.

• Change your password immediately if you have any reason to suspect it might have been discovered. Report such incidents to your security administrator.

• Do not leave your terminal unattended after you log in.

You might think the system failed and came back up again, when actually someone has loaded a password-stealing program. Even a terminal that displays an apparently valid logout message might not reflect a normally logged out process.

• Routinely check your last login messages. A password-stealing program cannot actually increase the login failure count, although it looks like a login failure to you. Be alert for login failure counts that do not appear after you log in incorrectly or that are one less than the number you experienced. If you observe this or any other abnormal failure during a login, change your password immediately, and notify your security administrator.

3.9 Network Security Considerations

This section describes how to use access control strings in file specifications and how to use proxy logins to help make network access more secure.

3.9.1 Protecting Information in Access Control Strings

Network access control strings can be included in the file specifications of DCL commands working across the DECnet for OpenVMS network. They permit a user on a local node to access a file on a remote node.

An access control string consists of the user name for the remote account and the user’s password enclosed within quotation marks, as follows:

NODE"username password"::disk:[directory]file.typ

Because access control strings include sufficient information to allow someone to break in to the remote account, they create serious security exposure. To protect access control string information, do the following:

• Avoid revealing the information on either hardcopy or video terminals. If you use a hardcopy terminal, dispose of the output properly. If you use a video terminal, clear the screen, and empty the recall buffer with the DCL command RECALL/ERASE when the network job is completed. This prevents another user from seeing the password, either by displaying the command line with the Ctrl/B key sequence or with the DCL command RECALL/ALL. DECwindows users can clear the screen with the Clear Lines Off Top option from the Commands menu. Otherwise, a DECwindows user could use the scroll bar to view previously entered text.

• Do not place networking commands that include access control strings in command procedures where they would be likely targets for discovery.

• If you must put access control strings in your command procedures, provide these files with optimum file protection by using the techniques described in Chapter 4, Protecting Data.

• The use of access control strings in not permitted in an evaluated configuration. Please see your system administrator to determine if your system is running in an evaluated configuration.

To avoid the need for access control strings, you might prefer to use proxy login accounts, which are described in Section 3.9.2.

3.9.2 Using Proxy Login Accounts to Protect Passwords

Proxy logins let you access files across a network without specifying a user name or password in an access control string. Thus, proxy logins have the following security benefits:

• Passwords are not echoed on the terminal where the request originates.

• Passwords are not passed between systems where they might be intercepted in unencrypted form.

• Passwords are not needed in command files to perform the remote access steps.

Before you can initiate a proxy login, the system or security administrator at the remote node must create a proxy account for you. Proxy accounts, like regular accounts, are created with the Authorize utility (AUTHORIZE). They are usually nonprivileged accounts. Security administrators can allow you access to one default proxy account and up to 15 other proxy accounts. While proxy logins require more setup effort on the part of system managers, they provide more secure network access and eliminate the need for users to enter access control strings.

The following examples illustrate the differences between a normal network login request and a proxy login request. For each example, the following conditions exist:

• The user KMAHOGANY has two user accounts:

– An account on node BIRCH with the password XYZ123ABC

– An account on node WALNUT with the password A25D3255

• KMAHOGANY has logged in to node BIRCH.

• KMAHOGANY wants to copy the file BIONEWS.MEM from the default device and directory of the account on the node WALNUT.

The following diagram illustrates these conditions:

$Q:\ati-artlib\gif\vm-1064a.gif$

The user KMAHOGANY could use an access control string to copy the file BIONEWS.MEM, as follows:

$ COPY WALNUT"KMAHOGANY A25D3255"::BIONEWS.MEM BIONEWS.MEM

Notice that the password A25D3255 echoes. Anyone who observes the screen can see it. In contrast, if KMAHOGANY has proxy access from node BIRCH to the account on node WALNUT, the command for copying the file BIONEWS.MEM is as follows:

$ COPY WALNUT::BIONEWS.MEM BIONEWS.MEM

KMAHOGANY does not need to specify a password in an access control string. Instead, the system performs a proxy login from the account on node BIRCH into the account on node WALNUT. There is no exchange of passwords.

Using a General Access Proxy Account

Your security administrator can also authorize groups of users from foreign nodes to share in the use of a general access proxy account. For example, the security administrator at node WALNUT can create a general access account with the following conditions:

• The user name GENACCESS.

• Access limited to network logins.

• A password known only to the owner of the account. (None of the remote users need to know it.) This helps to protect the account.

• The default device and directory STAFFDEV:[BIOSTAFF].

If the security administrator grants BIRCH::KMAHOGANY proxy access to the GENACCESS account, the user KMAHOGANY can copy the file BIONEWS.MEM by entering the following command:

$ COPY WALNUT::[KMAHOGANY]BIONEWS.MEM BIONEWS.MEM

Note that KMAHOGANY must specify the directory [KMAHOGANY] because the file BIONEWS.MEM is not in the default device and directory for the GENACCESS account (STAFFDEV:[BIOSTAFF]). In addition, the protection for the file BIONEWS.MEM must permit access to the GENACCESS account. Otherwise, the command fails.

When You Need to Specify the Name of a Proxy Account

If you have access to more than one proxy account on a given node and you do not want to use the default proxy account, specify the name of the proxy account. For example, to use a proxy account called PROXY2 instead of the GENACCESS account (the default), KMAHOGANY enters the following command:

$ COPY WALNUT"PROXY2"::[KMAHOGANY]BIONEWS.MEM BIONEWS.MEM

This command uses the PROXY2 account to copy the file BIONEWS.MEM from the [KMAHOGANY] directory on node WALNUT.

3.10 Auditing Access to Your Account and Files

Although it is the security administrator’s job to monitor the system for possible intrusions, you can help the security administrator to audit access to your account and files.

This section describes how to monitor your last login time for possible intrusions. It also describes how to work with your security administrator to enable certain types of auditing.

3.10.1 Observing Your Last Login Time

The operating system maintains information in your UAF record about the last time you logged in to your account. Your security administrator decides whether the system should display this information at login time. Sites with medium to high security requirements frequently display this information and ask users to check it for unusual or unexplained successful logins and unexplained failed logins.

If there is a report of an interactive or a noninteractive login at a time when you were not logged in, report it promptly to your security administrator. Also change your password. The security administrator can investigate further by using accounting files and audit logs.

If you receive a login failure message and cannot account for the failure, it is likely that someone has been trying to access your account unsuccessfully. Check your password to ensure that it adheres to all recommendations for password security described in Section 3.8. If not, change your password immediately.

If you expect to see a login failure message and it does not appear or if the count of failures is too low, change your password. Report either of these indications of login failure problems to your security administrator.

3.10.2 Adding Access Control Entries to Sensitive Files

If you have key files that may have been accessed improperly, you may want to develop a strategy with your security administrator to audit access to the files.

Once you review the situation and ensure that you have done everything possible to protect your files with standard protection codes and general ACLs (described in Chapter 4, Protecting Data), you may conclude that security auditing is required.

To specify security auditing, you can add special access control entries (ACEs) to files you own or to which you have control access. Keep in mind, however, that the audit log file is a systemwide mechanism, so Compaq recommends that a site security administrator control the use of file auditing. Although you can add auditing ACEs to files over which you have control, the security administrator has to enable auditing of files on a system level.

For example, if user RWOODS and his security administrator agree that they must know when a highly confidential file, CONFIDREVIEW.MEM, is being accessed, RWOODS can add an entry to the existing ACL for the file CONFIDREVIEW.MEM, as follows:

$  SET SECURITY/ACL=(AUDIT=SECURITY,ACCESS=READ+WRITE-
   _$ +DELETE+CONTROL+FAILURE+SUCCESS) CONFIDREVIEW.MEM

After RWOODS adds the security-auditing entry, the security administrator enables file-access auditing so that access attempts are recorded. See Section 3.10.3.1 for more information on file-access auditing.

An access violation of one file frequently indicates access problems with other files. Therefore, the security administrator may need to monitor access to all key files having security-auditing ACEs. When undesired access is gained to key files, the security administrator must take immediate action.

3.10.3 Asking Your Security Administrator to Enable Auditing

A security administrator can direct the operating system to send an audit message to the system security audit log file or an alarm to terminals enabled as security operator terminals whenever security-relevant events occur. For example, the security administrator might identify one or more files for which write access is prohibited. An audit message can be sent to indicate attempted access to these files.

3.10.3.1 Auditing File Access

If you suspect intrusion attempts to your account, the security administrator may temporarily enable auditing for all file access. The security administrator can also enable auditing to monitor read access to your files to catch file browsers.

For example, assume you decide to audit the file CONFIDREVIEW.MEM, which has a security-auditing ACE (see Section 3.10.2). If user ABADGUY accesses CONFIDREVIEW.MEM and has delete access, the following audit record is written to the system security audit log file:

%%%%%%%%%%%  OPCOM  7-DEC-2001 07:21:11.10  %%%%%%%%%%%
Message from user AUDIT$SERVER on BOSTON
Security audit (SECURITY) on BOSTON, system id: 19424
Auditable event:        Attempted file access
Event time:              7-DEC-2001 07:21:10.84
PID:                    23E00231
Username:               ABADGUY
Image name:             BOSTON$DUA0:[SYS0.SYSCOMMON.][SYSEXE]DELETE.EXE
Object name:            _BOSTON$DUA1:[RWOODS]CONFIDREVIEW.MEM;1
Object type:            file
Access requested:       DELETE
Status:                 %SYSTEM-S-NORMAL, normal successful completion
Privileges used:        SYSPRV

The auditing message reveals the name of the perpetrator, the method of access (successful deletion accomplished by using the program [SYSEXE]DELETE.EXE), time of access (7:21 a.m.), and the use of a privilege (SYSPRV) to gain access to the file. With this information, the security administrator can take action.

Note that the security audit message is written to the security audit log file every time any file is accessed and meets the conditions specified in the audit entry of the ACL for that file (see Section 3.10.2). Access to the file CONFIDREVIEW.MEM, as well as access to any file on the system that is protected with security auditing, prompts an audit record to be written to the security audit log file.

After auditing has been introduced, check with your security administrator periodically to see if any additional intrusions have occurred.

3.10.3.2 Additional Events to Audit

In addition to file auditing, the security administrator can select other types of events that warrant special attention when they occur. Events triggering an audit or alarm may include the following:

Events Initiating Security Audits or Alarms
Logins, logouts, login failures, and break-in attempts Volume mounts and dismounts	Modifications to: System and user passwords System time System authorization file Network proxy file Rights database SYSGEN parameters
Connection or termination of logical links	Execution of: SET AUDIT command NCP commands
Creation and deletion of selected protected objects	Installation of images
Selected types of access and deaccess to selected protected objects	Access event requested by an ACL on a protected object
Successful or unsuccessful use of a privilege or an identifier	Use of the process control system services, including $CREPRC and $DELPRC

3.11 Logging Out Without Compromising System Security

Logging out of a session conserves system resources and protects your files. Leaving a terminal on line represents one of the greatest sources of inside intrusions. When you leave your terminal on line and your office open, you have effectively given away your password and your privileges and have left your files and those of the other members of your group unprotected. Any user can easily and quickly transfer all files accessible through your account. A malicious insider could rename and delete your files and any other files to which you have write access. If you have special privileges, especially privileges in the Files or All category, a malicious user can do major damage.

Log out when you leave your office even for a brief period of time. If you have performed remote logins, you must log out of each node. The following sections describe security considerations for logging out of specific types of terminals or sessions.

3.11.1 Clearing Your Terminal Screen

You may want to clear your screen each time you log out from a terminal to ensure that your user name, node name, and operating system are not revealed to anyone else. If you are logging out after a remote login, the name of the node to which you return (the local node) is also revealed. If you access multiple accounts remotely (over the network), the final sequence of logout commands reveals all the nodes and user names that are accessible to you on each node (excluding the name of the furthest node reached). To those who can recognize the operating system from the prompt or a logout message, these displays also reveal the operating system.

At some sites, it may be important to leave nothing but the logout message on your screen, as follows:

• If you are using a VT200- or later series terminal, you can clear the screen by pressing the Set-Up key and selecting the item from the resulting menu that corresponds to the DECwindows Clear Display menu option on the Commands menu.

• If you are using a VT100-series terminal, press the Set-Up key. Then press the key marked for reset (the 0 key) followed by the Return key.

Alternatively, to preserve temporary parameters, press the Set-Up key, and then press the key marked 80/132 columns (the 9 key) twice.

After the screen clears, the cursor is positioned at the top of the screen, next to the DCL prompt. Enter the DCL command LOGOUT at the prompt. The only information remaining after you log out is your logout command and the logout completion message, for example:

$ LOGOUT
RDOGWOOD logged out at 14-AUG-2001 19:39:01.43

3.11.2 Disposing of Hardcopy Output

After you log out from a hardcopy terminal, properly remove, file, or dispose of all hardcopy output that might reveal sensitive information. Your security administrator should provide direction on preferred procedures. Many sites use paper shredders or locked receptacles for this purpose. Handle output that you plan to save just as carefully.

You should also dispose of hardcopy output if the system fails before you log out. In addition, if you will not be present when the system is initialized, turn your terminal off.

3.11.3 Removing Disconnected Processes

The system automatically removes your disconnected processes after a certain interval. You can conserve system resources, however, if you directly log out of any disconnected processes, as follows:

1. Enter the DCL command SHOW USERS to determine if you have other disconnected jobs.

2. Enter the DCL command CONNECT/LOGOUT to log out of the current process. Connect back through each of the associated virtual terminals (as noted by the terminal prefix of VTA) until you reach the last existing process.

3. Enter the DCL command LOGOUT.

3.11.4 Breaking the Connection to a Dialup Line

Your security administrator may ask you to break the connection to a dialup line when you log out. If you anticipate no further immediate use of the line, use the LOGOUT command with the /HANGUP qualifier. The /HANGUP qualifier directs the system to automatically break the connection to the dialup line after you log out.

$Q:\adept8\entities\note.eps$ Note

The effectiveness of the /HANGUP qualifier depends on how your system manager configures your modem line and how the line connects to the computer. It does not work on lines connected to a terminal server.

Breaking the connection to a dialup line prevents someone from taking advantage of an open access line. To access the line, someone must know the access number and must personally redial. Breaking the connection is especially important if the dialup line you use is in a public area or where someone might use the terminal after you.

This practice also saves resources by reducing the required number of dialup lines.

3.11.5 Turning Off a Terminal

If your site has moderate or high security requirements, your security administrator may ask you to turn off your terminal after logging out. This resets terminal characteristics and clears memory buffers. Some Trojan horse attacks use hardware frame buffers and the answerback capabilities that are built into newer terminals.

On VAX systems, users working in a C2 environment must turn off their terminals. (C2 is a United States government rating of the security of an operating system. Appendix C describes its requirements.)

3.12 Checklist for Contributing to System Security

Although security features are implemented by the security administrator as requirements for all users, this chapter has described ways in which you can contribute to system security. The following list reviews voluntary security actions:

• Choose a secure password by following the guidelines in Section 3.1.

• Protect your password, and change it often.

• Check your last login messages each time you log in, and report any unexplained messages to your security administrator (Section 3.4.3).

• Use proxy logins when possible (Section 3.4).

• Log out and lock up when you leave your terminal and area (Section 3.11).

• Use the /HANGUP qualifier with your final LOGOUT command from a dialup line (Section 3.11.4).

• Properly dispose of hardcopy output from your terminal (Section 3.11.2).

• Clear your screen, or turn off your video terminal to erase revealing displays (Section 3.6.2 and Section 3.11.1).

• Lock up backup media. Anyone who has the media in hand can access the information that is stored on the tape or disk.

• Ask your security administrator to enable security auditing for any protected objects, such as files, that you suspect have been accessed improperly (Section 3.10.3.1).

Document revision date: 24 June 2002

Preface

Intended Audience

Document Structure

Related Documents

Reader’s Comments

How to Order Additional Documentation

Conventions

Part I Security Overview