OpenVMS Guide to System Security

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

Digital 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:

• 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

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

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

• Use the MONITOR IO report to develop a familiarity with the normal amounts of I/O on your system at various times. Watch for abnormal changes.
• Keep informed of the images installed on your system. Use the Install utility (INSTALL) to look for unexpected additions. When monitoring the known file list, compare the current list with a valid hardcopy listing.
• Use the AUTHORIZE command SHOW on a regular basis to check for unauthorized user names.
• Use the AUTHORIZE command SHOW/PROXY regularly to quickly recognize all proxy access that you have authorized. Watch for unexpected additions. Remove any remote users who no longer require access. Institute regular communications with system managers at remote nodes.
• Apply the Accounting utility (ACCOUNTING) on a regular basis to give you a basis of normal amounts of processing time. Watch for unexplained changes.
• Regularly check the accounting report produced by ACCOUNTING for known user names, unknown user names, and appropriate hours of system use.
• Develop sufficient familiarity with your system's workload so that you notice normal (as well as abnormal) processing activity occurring at unusual hours.
• Monitor device allocations routinely with the DCL command SHOW DEVICE so that you immediately notice any that are unexpected.
• Become familiar with the recurring types of batch jobs that run on the batch queues and what times they are most likely to run.
• Monitor the protection and ownership of critical files with the DIRECTORY/SECURITY command. Watch for unexplained changes in each.
• Maintain familiarity with the rights list. Keep current listings so that you can recognize identifiers that have been added or new holders of the current identifiers.
• Remove identifiers that are not in use. Keep the rights list current.
• Regularly review the templates that you use to set up UAF records. Make any necessary changes.
• Use the security-auditing features described in Chapter 9.
• Apply the Audit Analysis utility (ANALYZE/AUDIT) regularly to detect abnormal auditing activity.
• When you allow new users to change their initial passwords, assign passwords that users will want to change or use the password generator. Check back to see if you can log in with the password you originally assigned. Where necessary, follow up with the user to determine why the change did not occur as requested.
• Try searching unprotected user files for passwords embedded in network access control strings. The password will precede the 3-character terminator ("::). Also search for the noun password, and see if any passwords are revealed nearby.
• Check that your users are logging out properly. Make physical checks at the end of normal business hours.
• Check that your users have appropriate default protections in place.
• Keep informed about your inventory of magnetic tapes, disks, and program listings. Routinely check that inventory for possible indications that physical security has degraded.
• Keep your office and all important listings locked up.

This chapter explains how you give users access to a system by assigning user accounts and passwords. Descriptions are based on the security needs of a commercial installation with average security needs, where accounts require protection. Descriptions of above-average security needs are also noted. Refer to Chapter 8 for information on controlling access to system data and resources. See Chapter 6 and Chapter 9 for information on auditing user actions.

The Authorize utility (AUTHORIZE) is the primary tool for establishing accounts and passwords. See the OpenVMS System Management Utilities Reference Manual: A--L for a description of the utility.

7.1 Defining Times and Conditions for System Access

The level of system access a user enjoys depends on your site requirements, that user's role in the organization, and your management of his or her account. A site with low security requirements and plenty of system resources may allow access at any time of day whereas a site with moderate security requirements may limit logins to daytime hours and permit dialup or network connections only to a subset of users.

Using the Authorize utility, you control when and how users can access the system. Table 7-1 identifies the applicable qualifiers.

Table 7-1 Authorize Qualifiers Controlling Login Times and Conditions

Categories	Qaulifier	Description
Time of day	/ACCESS	By default, a user has full access every day. By specifying an access time, you prevent access at all other times. Identify hours on primary days with the keyword PRIMARY; identify hours on secondary days with the keyword SECONDARY.
	/DIALUP	Specifies hours of access permitted for dialup logins.
	/LOCAL	Specifies hours of access for interactive logins from local terminals.
Days of week	/PRIMEDAYS	Defines the primary and secondary days of the week for logging in.
Mode of operation	/BATCH	Specifies the hours of access permitted for batch jobs.
	/INTERACTIVE	Specifies the hours of access for interactive logins.
	/NETWORK	Specifies the hours of access permitted for network batch jobs.
	/REMOTE	Specifies hours during which access is permitted for interactive logins from network remote terminals (with the DCL command SET HOST).
Allocation of resources	/DEVICE	Specifies the name of the user's default device at login.
	/DIRECTORY	Specifies the name of the user's default directory at login.
Validity of account	/EXPIRATION	Specifies the expiration date and time of the account.
	/FLAGS=DISUSER	Disables the account so the user cannot log in.
External authentication	/FLAGS=EXTAUTH	Specifies that the user is externally authenticated.

7.1.1 Restricting Work Times

AUTHORIZE qualifiers let you restrict system use to certain days of the week and certain periods of the day. Restricting work times is useful to better balance the workload on your system. Restricting access to accounts is also an effective way of preventing unauthorized use of the system outside of normal working hours.

Define primary and secondary days of the week with the /PRIMEDAYS qualifier, or conform to the default where primary days are Monday through Friday and secondary days are Saturday and Sunday. For example, to modify the defaults for a user who works Tuesday through Saturday, you would specify the /PRIMEDAYS qualifier as follows:

/PRIMEDAYS=(NOMONDAY,TUESDAY,WEDNESDAY,THURSDAY,FRIDAY,SATURDAY,NOSUNDAY) 

Occasionally an operational change occurs that conflicts with the normal day assignments at your site, such as a holiday falling on a primary day. To override the normal day assignment, use the DCL command SET DAY, and specify the day-type interpretation you want for the current day. This requires OPER privilege. Note that this change applies to all logged-in users, as well as those who will log in during the day. If users who are currently logged in are unauthorized for the day-type once it changes, they are logged out of the system at the next hour. (The job controller enforces time restrictions on an hourly basis.)

Decide which types of login access should be restricted to certain hours. The login access qualifiers are: /LOCAL, /REMOTE, /DIALUP, /INTERACTIVE, /BATCH, and /NETWORK. However, if your site applies one set of primary and secondary hours for all types of logins, you can specify the /ACCESS qualifier, which applies to all modes of access.

The following example shows how to apply the /BATCH qualifier to a user's account to disable the user from running batch jobs during normal working hours:

/NOBATCH=(PRIMARY, 9-17) 

  6346P009.HTM
  OSSG Documentation
  22-NOV-1996 13:05:03.30

Copyright © Digital Equipment Corporation 1996. All Rights Reserved.

Legal