HP OpenVMS Systems Documentation

Content starts here

OpenVMS Guide to System Security

Previous Contents Index

5.10.1 Naming Rules

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:

Read Gives you the right to examine file names and print and copy files on a volume.
Write Gives you the right to modify or write to existing files on a volume. Whether the subject may perform the operation on a specific file is determined by the file's protection. To be meaningful, write access requires read access.
Create Gives you the right to create files on a disk volume and to subsequently modify them. Create access also requires read and write access.
Delete Gives you the right to delete files on a disk volume, provided the user has proper access rights at the directory and file level. Delete access requires read access.
Control Gives you the right to change the protection and ownership elements of the volume.

5.10.3 Template Profile

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.

Template Name Owner UIC Protection Code

5.10.4 Privilege Requirements

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.

Event Audited When Audit Occurs
Access During any file system operation

5.10.6 Permanence of the Object

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

Part III
Security for the System Administrator

The chapters in this part discuss the following topics:

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)

Chapter 6
Managing the System and Its Data

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.

Table 6-1 Example of a Site Security Policy
Security Area Site Requirements
Passwords Schedule for password changes.
  Process for controlling minimum password length and expiration periods.
  Schedule for system password changes.
Accounts Procedure to grant accounts on computer systems, for example, statement of need, signature of requester, requester's manager, system manager, or person setting up the account. (Accounts can never be shared.)
  Procedure to deactivate accounts due to organizational changes, for example, employee transfers or terminations.
  Timetable for reauthorizing accounts, usually once every 6 to 12 months.
  Directive to deactivate accounts that are not used on a regular basis.
  Time periods for access.
  Timetable for expiring accounts.
  Procedure for requesting privileges that rigorously controls allocation.
  Requirement to use nonprivileged accounts for privileged users performing normal system activity.
  Schedule for verifying inactive accounts.
  List of approved security tools.
Security events to audit Logins from selected or all sources.
  Changes to authorization file records.
  Other uses of privilege and system management actions.
  Modifications to the known file list through the Install utility.
  Modification to the network configuration database, using the network control program (NCP).
Physical access to the computer room A written list of authorized personnel with the reason for access included. Typically, one person would be responsible for keeping this list current.
  Storage of a visitor log in a secure area.
  Locked access doors and a documented procedure for assigning keys, key cards, and combinations. (These access controls change periodically and on transfer or termination of employees.)
Physical access to terminals and personal computers located outside the computer room Use of programs to log out terminals that have not been used for a given period of time.
  Security awareness programs for the organization (beyond computer personnel); topics may include:
  • Maintaining a list of approved software.
  • Keeping desktops clear of hardcopy information relating to the computer system, network passwords, and other system account information.
  • Locking disks and file cabinets.
  • Keeping diskettes inaccessible in or near workstations.
  • Keeping keys out of open view.
Dialup numbers List of authorized users.
  Schedule for changing numbers periodically and procedures for notifying users of number changes.
  A policy to minimize publishing dialup numbers.
  Policy about changing passwords periodically and when employees with access are terminated.
  Password protection, either in the modems or terminal servers, or system passwords on host dialup ports.
  Documentation available about:
  • A dial-back system
  • Details about the network
  • Terminal equipment installed
  • Terminal switching systems
  • Details about all terminal devices connected to the network
  • Details about all dialup equipment
Communications Denial of access into privileged accounts if using passwords over TCP/IP, LAT, or Ethernet links.
  Use of authentication cards for network logins into privileged accounts.

6.3 Tools for Setting Up a Secure System

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.

Example 6-1 Sample Security Administrator's Account

identifier for value:[000001,000100] added to RIGHTSLIST.DAT

6.5 Training the New User

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?

6.6 Logging a User's Session

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> /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."
    $ !
    $ ! 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.
    $ !
    $ PID = F$GETJPI (0, "PID")
    $ LOGOUT
  3. Set up each account for which session auditing is to be enforced. The following command sets up the account for user Smith:


    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:

  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.
    $ !
    $ !
    $ ! Verify that the connection originated from the local node and
    $ ! from the USER_LOG account.
    $ !
    $ 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:
    $ @LOGIN

Previous Next Contents Index