Audit Serve, Inc.

The Worldwide Connection for Audit, Security, Control and SOX Professionals

Security Evaluation of the
OpenVMS Operating System

By: Mitchell H. Levine, CISA
Audit Serve, Inc.

                                                             

Low Cost & Highly Skilled 
IT Audit and SOX Consulting Resources Available Immediately
Call Mitch Levine at (203) 972-3567 or 
email levinemh@auditserve.com for additional information

Previously, we introduced our method called Audit Serve Security Evaluation Criteria (ASSEC) for evaluating the adequacy of security within a system. Assessing the security available within an environment is the basis for determining other mechanisms that must be established to provide an acceptable level of control desired by an installation.

Security Administration

Compliance With Minimal Protection Requirements

Regardless of the approach that is used (i.e., Access Control List, UIC Protection Code) to permit access to a resource (i.e., object), OpenVMS distinguishes between the basic types of accesses (e.g., no access, read, update, execute, and delete access). Based on the type of object (e.g., file, directory, volume, device), the access level available will vary. Regardless of the approach that is used to permit access to a resource, the information is stored in a security profile which can be displayed by executing the $SHOW SECURITY <object>.

The password change frequency is set individually for each userid by the security administrator using the /PWDLIFETIME qualifier of the AUTHORIZE command. In addition, login flags are provided to distinguish between primary and secondary passwords. If the /PWDLIFETIME is not specifically set for an account the default setting is 90 days.

Users have the ability to change their own password unless the account is established with the LOCKPWD flag, which only allows the security administrator to change the password. The setting of the LOCKPWD is controlled by the security administrator.

Compliance With Standard Protection Requirements

OpenVMS provides DCL commands for security administration and other user and system functions. The DCL commands that administer access entitlements are restricted to those users who have been assigned the SYSPRV privilege. The SYSPRV privilege permits all entries in the system authorization file (SYSUAF.DAT) to be changed. The Security privilege is also assigned to security administrators to allow them to perform other security related functions, such as to: modify system alarms, audit settings, modify the system password, and perform security display functions.

The SYSPRV and SECURITY privileges assigned to security administrators to perform security entitlement changes which will have an audit trail of all changes. However, the SYSPRV privilege would also allow the security administrator to receive the access accorded to users in the system category for resources that are secured using UIC protection codes. In addition, the system programmer may require access to SYSPRV privilege to perform system software installs. The frequency of this access is dependant on whether a separate system is available to install, customize, and test system software upgrades. If system programmers require routine access to the SYSPRV privilege, then there is a lack of separation between the privileges that are required to support the system programming and security administration functions.

Individual files within a directory are objects that can be protected using either an Access Control List or a UIC Protection Code.

As of OpenVMS version 6.0, programs can be defined as a protected subsystem which can be provided with conditional access to resources. Identifiers are granted to users which allows them to run the programs under the control of the system. Protected subsystems is an effective means to establish a program/library pathing control function for access to resources (i.e., limits users access to files using specific programs which they cannot alter and prevents them from accessing these files outside this predefined process).

The system does automatically set a user’s password to expire after it is changed by the security administrator. Accounts can be set by the security administrator with passwords which expire by using the /PWDEXPIRED qualifier when issuing the AUTHORIZE command which establishes a new user or change a user’s password.

OpenVMS does not provide any facilities that allows a security administrator to a view a user’s password.

OpenVMS provides the following facilities to control the use of accounts:

o accounts may be restricted from being used at a specific time period

o accounts can be suspended after an installation specified date and time

o access to use an account can be granted on a temporary basis but not on an access entitlement basis

Users who are responsible for decentralized security administration are assigned the GROUP privilege which allows them to administer access entitlements for those within their UIC group and the resources that are owned by their group. OpenVMS does not provide the ability to create userids or assign privileges as part of this decentralized administration function.

OpenVMS does not provide an automated method for suspending accounts after a period of non-use. A manual process would be required to be established for which a list of inactive accounts are obtained and are then disabled using DISUSER (i.e., requires SYSPRV privilege to perform this function).

The owner of a resource (i.e., object), who has full access to the resource, has the ability to assign access entitlements to the resource to other users.

Compliance With Above-Standard Protection Requirements

OpenVMS does not provide a mechanism to separate the security administration functions of establishing an account and assigning access entitlements.

Users are required to change their own passwords, but it is not a mandatory control since accounts can be established with the LOCKPWD flag which only allows the security administrator to change the password.

System Access

The types of audit trails that are maintained by Open VMS consist of events classes. Some event classes produce audit trails by default (i.e., changes to auditing parameters, break-in attempts, changes to security, and access to any object which has auditing ACL enabled) and other event classes produce audit trails based on specific alarms and audit options that are set by an installation.

OpenVMS maintains audit trails of all unauthorized accesses attempts to resources which identify the resource being accessed, the type of access, and the user who attempted the access. Some security events, which are referred to as event classes are logged automatically, including changes to access entitlements and invalid logon attempts. Other logging for an entire event class is enabled using the DCL command SET AUDIT. A more selective method of auditing is also available using an Access Control List (ACL) for specific objects.

These audited events are written to an audit log file and by default to an operator terminal.

The messages that are enabled by an alarm, are written to the operator terminal are not stored in a file. Therefore, there is no method for performing searches on specific events.

OpenVMS provides the analyze/audit command language which can be used to specify search sequences for customized reports.

All unsuccessful logon attempts are written to the audit lag file by default. An audit trail of all successful logon attempts can be written to the audit log file by installations using the SET AUDIT DCL command.

As mentioned in the minimal-protection section, a complete audit trail of unauthorized access attempts is provided which includes the time/date that the access occurred, the volume in which the dataset resided, the method used to access the resource (i.e., program), and the device used to access the resource.

Audit trails can be obtained for the following types of activities which requires an installation to set ACL or audit options:

- successful and unsuccessful accesses to installation specified resources

- accesses to installation specified resources during an installation specified time and date range

- all resources accessed by an installation specified account

- resources that are accessed by an installation specified device

By default an audit trail is maintained of the following types of security administration changes:

- accounts which have been added, deleted, or suspended

• establishment/changes to a user’s access privileges
• establishment/changes to resource access entitlements changes to installation security settings (i.e., system parameters)

- changes to users’ password by the security administrator

The following security definitions, which provides far the administration of access entitlements, can be extracted without requiring security administration authority (note:

would require SECURITY privilege which allows auditing options to be enabled/disabled):

o access privileges assigned to each userid

o installation level security settings

OpenVMS provides audit trails to identify the modules of a directory that have been updated.

The following security definitions, which provides for the administration of access entitlements, can be extracted without requiring security administration authority (note: would require SECURITY privilege which allows auditing options to be enabled/disabled):

o access privileges assigned to each account

o installation level security settings (i.e., need to run SYSMAN utility which would require OPER privilege)

o accounts assigned with no passwords

o accounts not required to change passwords

For privileges that bypass security there are audit trails of:

o resources being accessed
o files being accessed
o users accessing the resource
o methods used to access resource
o time and date of access
o type of access
o device used to access resource

An ACL can be written to restrict access to the OpenVMS audit trail file but the system will still be able to automatically update the security audit log file without requiring authorization or by being assigned an account.

OpenVMS provides a system parameter which can be used to issue a warning message to the security console when the security audit trail lag file is inactive.

Individuals users are not provided a mechanism for suppressing audit trails within the OpenVMS environment due to the manner in which audit trails are produced. OpenVMS has specific event classes which by default produce an audit trail which cannot be suppressed. In addition, there is no methods are provided far suppressing the audit trails produced for event classes that are enabled by an installation.

OpenVMS provides the Shadow process which can be used to replicate the updates to a file to an alternate file on a separate disk. This provides an effective means far duplicating changes to the security databases.

Compliance With Above-Standard Protection Requirements

OpenVMS provides a system parameter which can be used to stop the system when the security audit trail lag file is inactive.

The security audit trail data contained in the buffers are not recovered during a system failure.

Technical Articles | Conferences | Audit Programs | Audit Serve Seminars | Consulting Services | Audit Vision Newsletter | What's New | Contact US

This website has been optimized for Netscape and Internet Explorer 4.0 and above.  Your comments and suggestions are always welcome, please email webmaster@auditserve.com.
Copyright © 2000  All rights reserved.  27 Pine Street, Suite 700, New Canaan, CT 06840 USA.