[OpenVMS documentation]
[Site home] [Send comments] [Help with this site] [How to order documentation] [OpenVMS site] [Compaq site]
Updated: 11 December 1998

OpenVMS Guide to System Security


Previous Contents Index

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
DEFAULT [0,0] S:RWCD,O:RWCD,G:RWCD,W:RWCD

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:


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:

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).
Controlling 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.)
Controlling 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.
Controlling 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:

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

$ 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>

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:

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, it is advisable to 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 
    

6.7 Ongoing Tasks to Maintain a Secure System

Maintaining a secure system requires continuous surveillance. The following ongoing tasks are important to you in your role as security administrator:


Previous Next Contents Index

[Site home] [Send comments] [Help with this site] [How to order documentation] [OpenVMS site] [Compaq site]
[OpenVMS documentation]

Copyright © Compaq Computer Corporation 1998. All rights reserved.

Legal
6346PRO_012.HTML