HP OpenVMS Systems Documentation

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.

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)

This specification permits the user to run batch jobs only during the hours of 6:00 p.m. through 8:59 a.m. on primary days but all day on secondary days.

7.1.2 Restricting Modes of Operation

The following concerns might cause you to prohibit network access for some of your users:

• The user has data that should be accessed only through the local node.
• Penetration attempts are more likely to occur over a network because of the increased anonymity of the connection. (This concern is also relevant to dialup connections.)

Use the AUTHORIZE qualifier /NONETWORK to prevent specific users from having network access, as shown in the following example:

UAF> ADD JSMITH /NONETWORK, ...

Any of the AUTHORIZE access mode qualifiers (/LOCAL, /REMOTE, /DIALUP, /INTERACTIVE, /BATCH, or /NETWORK) can be negated in this manner to restrict access to the system.

7.1.3 Restricting Account Duration

It is good practice to set an account expiration time that matches the maximum length of time you expect the user to require access. When the expiration time arrives, the system automatically prohibits access to the account. You must still remove the UAF record and delete the user's files.

Use of the /EXPIRATION qualifier also forces you to periodically review accounts and reauthorize only those that are necessary.

To set the account expiration time, use the AUTHORIZE qualifier /EXPIRATION in the user's UAF record. For example, the following qualifier specifies that the user's account will expire on the 30th of December 1995:

/EXPIRATION=30-DEC-1995

You may want to severely restrict the use of certain accounts. For example, you may want to disable specific accounts used only periodically, such as the SYSTEST and FIELD accounts, to limit possible misuse of these accounts. Disable the accounts with the /FLAGS=DISUSER qualifier. Temporarily enable the accounts with the /FLAGS=NODISUSER qualifier when needed.

7.1.5 Restricting Disk Volumes

Identify the user's default device and directory in the UAF record with the AUTHORIZE qualifiers /DEVICE and /DIRECTORY. You can limit the number of blocks available to the user on that disk (and any other disk) through the disk quota feature of the System Management utility (SYSMAN), as described in the OpenVMS System Management Utilities Reference Manual: A--L.

The volume protection in place on other disks controls how much access a user can obtain to the disks. The user's privileges, which can be extended or limited through the AUTHORIZE qualifier /PRIVILEGES, also influence the access available (see Section 8.7).

7.1.6 Marking Accounts for External Authentication

Mark a user's account in the UAF record with the AUTHORIZE qualifier /FLAGS=EXTAUTH to allow the user to be externally authenticated.

See Section 7.4 for more information.

7.2 Assigning Appropriate Accounts to Users

The type of system access a user holds largely depends on his or her need for system resources and your site's security requirements. This section describes the types of user accounts that are available on OpenVMS systems and explains why one type of account may be preferable to another. For a step-by-step description of adding user accounts, refer to the OpenVMS System Manager's Manual.

7.2.1 Types of System Accounts

There are two major types of accounts:

• Interactive accounts have access to system software. Usually, such an account is considered an individual account.
• Limited-access accounts provide controlled login to the system and, in some cases, controlled access to user software. Limited-access accounts ensure that the system and process login command procedures, as well as any command procedures they call, are executed. There are two types of limited accounts: captive and restricted. Guest, proxy, and automatic login accounts are forms of captive and restricted accounts. DECwindows software does not currently support captive or restricted logins in the traditional sense. Once a user is logged in and creates a DECterm window, however, the traditional environment of a captive or restricted account applies.

Both interactive and limited-access accounts can be privileged accounts, and can be externally authenticated, as Section 7.2.2 describes.

The following table shows the kind of account to create based on the task a user performs:

You may develop one or more templates that work for many of your users. However, do not oversimplify the process of account creation to the point that you simply apply a template. The danger in relying solely on templates is that you might overlook special considerations that apply to individual users, thereby forfeiting important controls that only you can exercise.

Examine templates regularly to be sure they are valid and reflect the way you want your operations to proceed. Templates become obsolete rapidly.

7.2.1.1 Interactive Account Example

Example 7-1 shows how to create an interactive user account with moderate restrictions, typical of an account at a commercial site where security is a concern and the average user has limited access. Notice the following:

1. Only one password is required.
2. The password has a minimum length of 6 characters.
3. The user's password is valid for 90 days, a much longer lifetime than the manager's password shown in Example 6-1.
4. The user is allowed access during the week and on Saturdays.
5. During those six days, the user has access during a 15-hour period.

$ SET DEFAULT SYS$SYSTEM
$ RUN AUTHORIZE
UAF> ADD RDOGWOOD /PASSWORD=TRALAYAM/UIC=[231,010] -  (1)
_UAF> /DEVICE=BOTANYDEV/DIRECTORY=[RDOGWOOD] -
_UAF> /OWNER="Robert Dogwood"/ACCOUNT=BOTNYDPT -
_UAF> /FLAGS=(GENPWD)/PWDMINIMUM=6 -                  (2)
_UAF> /EXPIRATION=15-JUNE-1994/PWDLIFETIME=90-        (3)
_UAF> /PRIMEDAYS=(MON,TUES,WED,THURS,FRI,SAT,NOSUN) - (4)

_UAF> /NOACCESS=(PRIMARY,23-6,SECONDARY)/NODIALUP     (5)
identifier for value:[000231,000010] added to RIGHTSLIST.DAT
UAF>

Example 7-2 shows how to create an applications production account where the user is highly restricted. This account is designed to perform two functions: list the grades at State University, and produce mailings to each student's home.

In the example, any value not specified defaults to the value provided by the default record in SYSUAF.DAT.

Notice the following:

1. Account users do not see the normal system welcome message. The account may not receive mail. It is restricted to running under control of its login command procedure and the default command interpreter (DCL).
2. The user who initiates the login must specify the password, GROBWACH. (Most likely only the security administrator will change the password.)
3. When the job is run through a local login, it is restricted to the hours of 8 a.m. through 5:59 p.m., Monday through Friday. (Notice that only batch and local logins are allowed, and batch mode does not have time restrictions.)
4. The job may not be run over dialup lines or as a remote job. The account also denies network access.
5. The process runs under the control of a special login command procedure (GRADES.COM), which presumably provides the operator with a menu of functions.
6. The process is restricted to the commands defined in the CLI table GRADES_TABLES.

$ SET DEFAULT SYS$SYSTEM
$ RUN AUTHORIZE
UAF> ADD REPGRADES /DEVICE=ADMINDEV/DIRECTORY=[REPGRADES] -

_UAF> /FLAGS=(CAPTIVE,DISWELCOME,DISNEWMAIL,DISMAIL,DEFCLI) - (1)
_UAF> /PASSWORD=GROBWACH/UIC=[777,031] -      (2)
_UAF> /OWNER="Campus Admin"/ACCOUNT=ADMIN -

_UAF> /LOCAL=(PRIMARY,8-17)/PRIMEDAYS=(MON,TUES,WED,THU, - (3)
_UAF> FRI,NOSAT,NOSUN) -

_UAF> /NONETWORK/NOREMOTE/NODIALUP -          (4)
_UAF> /LGICMD=GRADES (5) /CLITABLES=GRADES_TABLES -   (6)

   .
   .
   .
user record successfully added
identifier for value:[000777,000031] added to RIGHTSLIST.DAT

Privileges determine the functions users are authorized to perform on the system. Any account with privileges beyond TMPMBX and NETMBX is considered privileged. Such an account can be interactive, restricted, or captive.

Because abuse of privileged accounts can result in serious losses, consider imposing special controls on accounts with the most powerful privileges as follows:

• Limit access to the account. For example, you can prohibit dialup or network access with the /NODIALUP or /NONETWORK qualifier to discourage outsiders from attempting break-ins from remote locations.
• Impose security alarms to detect use of the privileges pertaining to file protection: BYPASS, SYSPRV, READALL, and GRPPRV. For information about setting up and monitoring security alarms, see Chapter 9.

For all but the SYSTEM account, also add the following restrictions:

• Use the /PRIMEDAYS and /NOACCESS qualifiers to restrict the time of day or days of the week that logins can be performed. Select periods of time that can be monitored for appropriate use.
• Disable the account when not in use with the AUTHORIZE qualifier /FLAGS=DISUSER.
• Use a captive login command procedure for additional validation. Captive login command procedures are described in Section 7.2.4.

Naturally, you need to set controls on the SYSTEM account. The most secure practice is to disable it for all but batch access and perform system management through individual privileged user accounts, which provide accountability.

Special-Purpose Privileged Captive Accounts

Because the safety of a captive account depends on the integrity of its command procedures, it is unadvisable to set up privileged captive accounts for untrusted users. However, there are some situations that require privilege, and it is safer to perform specific sensitive functions through captive privileged accounts than through general purpose privileged accounts. For example, users who perform backup operations require the READALL privilege. By making the account that performs backups captive, you can ensure that the procedures are carried out according to your system's backup policy.

See Section 7.2.4 for guidelines for setting up captive accounts.