HP OpenVMS Systems Documentation

A volume name can be the volume label, the name of the device on which the volume is mounted, or a user-specified logical name. Volume label names can be from 0--12 characters in length.

5.10.2 Types of Access

The volume class supports the following types of access:

The class provides the following template profile and assigns the values during initialization. Although the template assigns an owner UIC of [0,0], this value is only temporary. As soon as the object is created, the operating system replaces a 0 value with the value in the corresponding field of the creating process's UIC.

Users with the VOLPRO privilege always have control access to a volume. Mounting a file-structured volume as foreign requires VOLPRO privilege or control access.

5.10.5 Kinds of Auditing Performed

All volume access can be audited, provided the security administrator enables auditing for the Access event class.

The security profile for a volume object is saved in the master file directory (MFD) of the disk as [000000]SECURITY.SYS.

• Role of a security administrator (Chapter 6)
• Securing the system (Chapter 7)
• Securing data and resources (Chapter 8)
• Security auditing (Chapter 9)
• Responding to security breaches (Chapter 10)
• Creating a secure cluster (Chapter 11)
• Considerations for systems using networking (Chapter 12)
• Setup and management of protected subsystems (Chapter 13)

This part of the manual also includes information on the following topics:

• User privileges and who may need them (Appendix A)
• Default UIC-based protection of critical system files (Appendix B)
• Guidelines for operating in a C2 security environment (Appendix C)
• Examples of security alarm messages (Appendix D)

This chapter explains how you, as security administrator, implement security features of the OpenVMS operating system. It provides an overview of security management, based on the security needs of a commercial installation with average security needs. It discusses the following topics:

• Your role as security administrator
• Site security policies
• Tools for security administrators
• Account requirements for a security administrator
• Suggestions for training users
• Logging the activities of a new user
• Tasks to include in your weekly routine

Compaq recommends that you read the entire chapter and the three chapters that follow before establishing any security measures. After reading the chapters, you will better be able to decide which security measures are appropriate for your site, and you will have the tools to implement them.

6.1 Role of a Security Administrator

Your role as security adminstrator is to implement and maintain the organization's security policy. Some organizations include security administrators in the development of the security policy; other organizations charter security administrators to implement and maintain an established policy. For an example of a company security policy, see Section 6.2.

As security administrator (or officer), your job is to see that the security policy is implemented and maintained. Regularly monitoring the system for possible security violations and vulnerabilities is absolutely necessary. Whenever you detect problems, you should see that they are corrected.

Many times organizations divide the duties of computer administrators. The security administrator monitors the system and reports problems, and the system manager implements policy and manages the system. In this management structure, the security administrator works in tandem with the system manager. Some system managers choose to employ an accounts clerk to set up user accounts and process the required paperwork justifying the need for an account. This is always a highly trusted individual who essentially acts as a co-system manager. With a division of labor, it is critical for the system manager and security administrator to communicate regularly. The security administrator should report security problems to users or, if necessary, to system managers or the accounts clerk so problems are corrected.

Another division of duties, common to many OpenVMS installations, combines the roles of security administrator and system manager. One person implements the security policy and maintains the system to meet its requirements.

Secure system management, however it is organized, involves training users, setting up accounts and passwords, protecting sensitive system files and resources, and auditing and analyzing security-relevant events. Learning how systems are used and recognizing "normal" system activity are critical to secure management.

6.2 Site Security Policies

An organization's management usually establishes a brief security policy for its employees to emphasize the behavior it expects of them. For example, such a policy may state that employees should not give away company data or share passwords.

The managers of divisions or computer sites develop the detailed security policy. It is a written set of guidelines on the use of passwords and system accounts, physical access to the computer systems, communication devices, and computer terminals, and the types of security-relevant events to audit. These security guidelines might be followed by more specific statements applying to particular operating system enviroments.

The complexity of a security policy eventually depends on whether the division has high, medium, or low security requirements. Chapter 1 provides a set of questions that can help an organization determine its needs.

As an example, a site security policy often defines which company employees have access to certain systems and the type of access available to the personnel performing nonroutine tasks and development. Sometimes a policy can provide an intricate set of rules for determining system access. Table 6-1 presents the policy developed by one division.

The following chapters describe how to set up a secure system according to your security policy. The Authorize utility (AUTHORIZE) is the primary tool for implementing system security. AUTHORIZE is described fully in the OpenVMS System Management Utilities Reference Manual. The AUTOGEN command procedure, which you use to modify the system parameters file, is described in the OpenVMS System Manager's Manual and the OpenVMS System Management Utilities Reference Manual. Many DCL commands are also important security tools. DCL commands are described in the OpenVMS DCL Dictionary.

6.4 Account Requirements for a Security Administrator

You need an account with privileges to perform the tasks of a security administrator.

An administrator who reviews security violations and possible vulnerabilities requires at least three privileges:

• SECURITY and AUDIT privileges to enable security auditing and to set up security operator terminals
• READALL privilege to review the protection of files and resources

In many cases, a security administrator serves as both the security administrator and the system manager. This person requires a full set of privileges. The OpenVMS System Manager's Manual describes the necessary characteristics of a system management account.

Example 6-1 illustrates a number of AUTHORIZE qualifiers appropriate for a security administrator's account. Notice the following:

1. The requirement that the automatic password generator be used to change passwords.
2. The use of a short password lifetime.
   Measures 1 and 2 are important to protect the account because it affords many valuable privileges and access rights.
3. SECURITY, AUDIT, and READALL privileges allow monitoring of the system but no modification. If you perform the tasks of a system manager, then you would need an account with SYSPRV. With SYSPRV, you can access protected objects by the system protection field and change the owner UIC and protection. You can change an object's protection to gain access to it.

In Example 6-1, any value not specified defaults to the value provided by the default record in SYSUAF.DAT.

$ SET DEFAULT SYS$SYSTEM
$ RUN AUTHORIZE
UAF> ADD RIRONWOOD/PASSWORD=VALTERSY/UIC=[001,100] -
_UAF> /DEVICE=SYS$SYSDEVICE/DIRECTORY=[RIRONWOOD] -
_UAF> /OWNER="Russ Ironwood"/ACCOUNT=SECURITY/FLAGS=GENPWD - (1)
_UAF> /PWDLIFETIME=30-/PWDMINIMUM=8 - (2)
_UAF> /PRIVILEGES=(AUDIT,SECURITY,READALL)(3)
identifier for value:[000001,000100] added to RIGHTSLIST.DAT
UAF>

Teaching new users about system security is an important security tool. It is important to involve users in security methods and goals; the more they know about the system and how break-ins occur, the better equipped they are to guard against them.

Include the following topics in your user training:

• What is the location of the user's account? Specifically, which system, where is it located, what is the proper node name if on a network, and, if the system is part of a cluster, what other nodes are available?
• Which terminals can be used for logging in, and where are they located?
• Is the account restricted with regard to local, dialup, remote, interactive, network, or batch operations? If so, describe both permitted use and restrictions.
• Can the account be accessed by dialing in? If so, provide the access telephone number, and describe the procedure. Specify how many retries are allowed and the maximum number of seconds allowed between each retry before the connection is lost.
• Are system passwords implemented for any terminals that the user may be using? If so, describe which terminals, how often the system password is changed, and how the user can learn the new system password.
• What is the account duration? When will it expire? From whom should the user request an extension?
• What is the user name? What identifiers are held by the user, if any? What are the group and member numbers associated with the user?
• What password information is required? Specifically, what is the initial password? Is the password locked? If the password is not locked, how often must the password be changed? What is the minimum length for the password? Is there a secondary password for this account, and who will know it? Is the user free to select passwords, or must they be automatically generated? See Section 3.12 for a checklist of good practices for users.
• What is the default device and directory?
• What is the default protection?
• Are there quotas on disk usage? If so, what are the values?
• Are there restrictions on use? For example, are there certain days or hours of the day that are suggested or enforced? Explain primary and secondary days if applicable.
• Are there files or directories that are shared? If so, provide the details.
• Are there ACLs that affect the user? What identifiers does the user need to know?
• Which privileges does the user hold and what do they mean?
• What is the command language interpreter?
• Which type of account is this: open, captive, restricted, or interactive?
• Which nodes permit proxy logins for this user, if any?
• What are the names of the queues the user may need to use?
• What actions should the user take to ensure physical site security, such as locking up materials?

While users are learning the system, you may choose to monitor terminal sessions if the user performs an especially sensitive function, such as accessing sensitive data or controlling a system operation. (Sometimes users may choose to log their own sessions so they have a record of their actions. If this is the case, they can use the command SET HOST 0/LOG interactively after their initial login.) This section describes one method of logging users' sessions by setting up a restricted account. Many third-party products provide other ways of monitoring sessions that are more efficient. Regardless of the method you select, you should check with your legal department to make sure this is acceptable practice.

By using a special restricted account and appropriate command procedures, you can enforce the logging of terminal sessions for selected users. These users would need to log in to the restricted account first and then log in to their own account. The restricted account ensures that the session is logged.

The following example provides guidelines on how to set up the restricted account (named USER_LOG in this example) and includes samples of appropriate command procedures:

1. Set up the restricted account USER_LOG as follows:

   UAF> ADD USER_LOG /FLAGS=(RESTRICTED,DISMAIL,DISNEWMAIL)- _UAF> /LGICMD=SYS$SYSROOT:[USER_LOG]SESSIONLOG- _UAF> DEV=SYS$SYSROOT: /DIR=[USER_LOG]- _UAF> /NONETWORK /NOBATCH /UIC=[200,256]

2. The SESSIONLOG.COM command procedure enables logging of the terminal session:

   $ ! SESSIONLOG.COM - log in to specified account with terminal session $ ! logging enabled. $ ! $ WRITE SYS$OUTPUT "Please log in to the account of your choice." $ WRITE SYS$OUTPUT "Your terminal session will be recorded." $ WRITE SYS$OUTPUT "" $ ! $ ! Acquire the intended user name and save it in a temporary file. Use $ ! it to name the log file, and pass it as the first line of input to $ ! LOGIN. $ ! $ READ/PROMPT="Username: " SYS$COMMAND USERNAME $ PID = F$GETJPI (0, "PID") $ OPEN/WRITE OUTPUT USERNAME'PID'.TMP $ WRITE OUTPUT USERNAME $ CLOSE OUTPUT $ DEFINE/USER SYS$INPUT USERNAME'PID'.TMP $ SET HOST 0 /LOG='USERNAME'.LOG $ DELETE USERNAME'PID'.TMP;0 $ LOGOUT

3. Set up each account for which session auditing is to be enforced. The following command sets up the account for user Smith:

   UAF> MODIFY SMITH /FLAGS=RESTRICTED /NOLOCAL /NODIALUP - _UAF> /LGICMD=SYS$SYSROOT:[USER_LOG]CHECKLOG

   
   Because the restricted login command procedure ensures that the login is coming from the USER_LOG account using a SET HOST command, the session is logged.
4. You may also want to disable batch and network access for each user account to allow only local logins from the USER_LOG account. For example:

   UAF> MODIFY SMITH/FLAGS=RESTRICTED/NOLOCAL/NODIALUP/NOBATCH - /NONETWORK/LGICMD=SYS$SYSROOT:[USER_LOG]CHECKLOG

5. The following CHECKLOG.COM command procedure verifies that the user is logging in to the USER_LOG account. For this procedure to work correctly, you must have enabled DECnet proxy accounts as described in Section 12.3.2.

   $ ! CHECKLOG.COM - ensure that the account is being logged in to $ ! the USER_LOG account. $ ! $ IF F$MODE () .NES. "INTERACTIVE" THEN EXIT $ ! $ ! Verify that the connection originated from the local node and $ ! from the USER_LOG account. $ ! $ IF F$LOGICAL ("SYS$NODE") .EQS. F$LOGICAL ("SYS$REM_NODE")- _$ .AND. F$LOGICAL ("SYS$REM_ID") .EQS. "USER_LOG"- _$ THEN GOTO OK $ WRITE SYS$OUTPUT "You may log in to this account only with ",- _$ "the USER_LOG account." $ LOGOUT

   $ ! $ ! When the login has been verified, enable Ctrl/Y to $ ! release the account, invoke the user's LOGIN.COM, and turn $ ! control over to the user. $ ! $ OK: $ SET CONTROL_Y $ IF F$SEARCH ("LOGIN.COM") .EQS. "" THEN EXIT $ @LOGIN