Security Evaluation of the OpenVMS Operating System
By: Mitchell H. Levine, CISA
Audit Serve, Inc.
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.
ASSEC provides ratings which are used to evaluate the level of security afforded by an operating environment. Security levels should be assigned according to the installation provided controls and the verification of discretionary controls that have been installed. Security controls assigned to each level should also include the security controls required at the previous level. You may see variations of the same control assigned to different levels, differences being based upon that which is mandated by each level.
Commencing with the current issue of Audit Vision, assessments will be provided of alternative solutions that operating environments provide for the control requirements specified within ASSEC. The evaluation provided in this article is based upon DECs OpenVMS VAX operating which runs version 6.0. Other products that are offered separate by DEC and other third party vendors which provide additional security features are not included in this evaluation.
The format used within an evaluation using ASSEC consists of defining how an operating environment provides an ASSEC required control. Since the adequacy of a control provided by an operating environment varies, it is not intended that this evaluation provide a score card for an operating environment contrary to what is found in other industry standards.
When reviewing this evaluation, one should have ASSEC available to refer to the control requirements and their explanations.
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.
Open VMS provides the following system access controls, which are mandatory settings:
o an account and password combination is used to identify the user
o passwords are not displayed on terminal in clear text
Normal accounts are established with a password. However, Open, Restricted and Captive accounts can be established without requiring the use of a password. In addition, proxy accounts which are used to access resources on a remote node are also not established with passwords.
OpenVMS uses an encryption algorithm to conceal user passwords which are stored in the system user authorization file (SYSUAF.DAT). OpenVMS uses a one way encryption scheme (i.e., Purdy). Therefore, when a password is entered, OpenVMS encrypts the password and compares it to the encrypted value stored in the system user authorization file. An installation can utilize their own encryption algorithm which can beset for use on an individual user basis. It is not possible to set an unencrypted password. However, an installation can specify in the system parameters that it will use its own encryption method, which can be defined to be set for all passwords or for individual passwords.
Users are associated with a group based on the their UIC number. When an account is removed from the system, all of their entries to resources protected by an UIC, owner, or ACL basis protection is not automatically removed. Therefore, it is possible for a future user who is assigned the same account to have access to resources that are not required for their job function.
Open VMS does not suspend accounts after an installation specified number of unauthorized access attempts to a resource.
The default minimum password length is 6 characters which can be extended at the individual account level through the use of the /PWDMINIMUM qualifier of the AUTHORIZE command.
OpenVMS prevents users from reusing their passwords for 365 days. Assuming that the default password change frequency of 90 days is used, then at a minimum the last four passwords could not be reused. The search of the reuse of passwords can be disabled on a user level using the DISPWDHIS option of the /FLAGS qualifier of the AUTHORIZE command.
OpenVMS provides the ability for an installation to suspend users after an installation specified number of invalid logon attempts. This is accomplished by using the LGI_BRK_LIM SYSGEN parameter which specifies the number of failures that is allowed before the attempted session is deactivated for an installation specified period of time (i.e., deactivation controlled by LGI_HID_TIM and LGI_BRK_TMO SYSGEN parameters). When the number of invalid logon attempts has been exceeded, the user’s terminal is not disabled.
OpenVMS can prevent passwords which are easily guessed from being used by comparing all new passwords against a system dictionary that is stored in the SYS$LIBRARY. Installations can add their own commonly used passwords to the system dictionary by creating a file and merging it with the system dictionary. The search of the system dictionary can be disabled using the DISPWDDIC option of the /FLAGS qualifier when issuing the AUTHORIZE command.
OpenVMS does not provide a terminal timeout facility after a period of inactivity.
The user’s account is automatically part of the job record based on being logged into a process. Therefore, there is no need to propagate the user’s account and password to a job each time it is submitted for execution.
Only users with the DETACH privilege can submit a job using another user’s account.
A user can be restricted from accessing the system through a particular class (e.g., network, remote) which represents a point of entry into the system. A user can also be forced to only access the system through a particular class.
User are notified of their last logon when they log onto the system.
OpenVMS provides support for the use physical authentication devices (i.e., smart cards, tokens, secure-ids) using the LOGIN_CALL installation exit.
Security System Integrity
OpenVMS provides two approaches which can be used to selectively protect volumes, directories and files (i.e., Access Control List, UIC Protection Code).
When a user creates a directory the protection code security approach (U IC) automatically can be defined using system parameters to have predefined access settings for the OWNER, SYSTEM, GROUP, and WORLD.
The RMS_FILEPROT system parameter defines the default protection for files. This default protection can be overridden by a user who creates a file of which they are the owners by specifying the SET PROTECTION/DEFAULT command. An installation can enforce directory default protection which cannot be overridden by specifying an ACL for a specific directory. However, the ACL cannot be written to provide default protection for all directories.
OpenVMS provides tape volume security but does not provide tape file level security. The tape volume is identified by the header record which can be secured by an ACL or UIC protection code security.
All security changes take effect immediately except for changes to system parameters. However, a process is also available to make system parameters active immediately without having to bring the system down.
OpenVMS security is always active and is not a separate process that is started. Therefore, the control which prevents users from accessing the system when security is not available is not applicable for this environment.
OpenVMS security is not a layered product. Therefore, there are no security calls to external processes that can be disabled. In addition, there are no exits available which take control before or after security validation which could be disabled.
Tape volumes can be set to be protected by default.
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.
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.
For a free proposal to perform an audit of your organization or provide SOX support & testing services, contact Mitchell Levine of Audit Serve at (203) 972-3567 or via e-mail at Levinemh@auditserve.com.
Copyright 2006, Audit Serve, Inc. All rights reserved. Reproduction, which includes links from other Web sites, is prohibited except by permission in writing.
Join 3,500 other subscribers
Advertise with Us