Security Evaluation of the MVS Operating System Using RACF
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 written in this article is based upon IBM’s MVS operating which runs version 4.2, using RACF version 1.9 and greater as its security system. It should be noted that there are no changes from MVS version 3.1.3, which altered the control requirements within ASSEC.

The format used within an evaluation using ASS EC 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.

 

Security Administration

Compliance With Minimal Protection Requirements

The access levels used by RACF to permit a user access to a data file or program library distinguishes between no access, read, update, execute, and delete access (i.e., RACF provides NONE, ALTER, CONTROL, UPDATE, READ, and EXECUTE access authorities).

Userids can be established with a password change frequency and users have the ability to change their own passwords, which is a mandatory control.

Compliance With Standard Protection Requirements

The process of defining users on the system and specifying their corresponding access entitlements is restricted to those individuals who are provided with the Special attribute. This security administration function is performed with RACF provided panels using ISO or issuing RACF commands that are executed at the TSO READY prompt. The RACF commands and panels are accessible to non-security administrators but only those users provided with Special or Group-Special attribute (i.e., allows users to administer user profiles for users and resources that are within the scope of their group’s authority). Owners of resources (i.e., users can be assigned as owners of individual user profiles, dataset or generic profiles) can issue the RACF commands or access the RACF panels that allow security changes to be made. In addition, a user who is assigned the CLAUTH attribute for the USER class allows that individual to define new users to RACF, provided the user is the owner of or has JOIN authority in the new user’s default group.

A complete audit trail is maintained via SMF records which identifies all security changes made. However, the activation of this audit trail is a discretionary control which is activated by the specifying SAUDIT in the RACF Global Options which is the default value. This can be verified by reviewing the SETROPTS listing (i.e., listing identifies RACF Global Options) and ensuring that SAUDIT is specified within the ATTRIBUTES parameter.

The Special attribute, which is used to administer access entitlements, does not provide the security administrator with the ability to access system resources unless the security administrator grants their own userid this access.

RACF does not provide the ability to restrict update access or provide an audit trail of updates that are made to specific modules within a library (i.e., partitioned dataset). Programs can be restricted using the PROGRAM RACF Resource Class which can optionally restrict the ability to execute programs that reside in an installation specified library. However, this method of security will not restrict a user from updating the program unless the user has been restricted at a dataset level. In addition, individual modules of a dataset which are not programs (e.g., parameter files) cannot be restricted using the PROGRAM RACF Resource Class. An alternative to protecting an individual module within a dataset is to place the module in its own dataset. However, this may not always be possible especially with modules that are required to be in specific datasets.

RACF provides the ability to restrict access to a dataset through a specific program residing in a specific library, which would prevent a user from performing unauthorized updates outside of the installation authorized program. This is done by specifying the program in the PROGRAM RACF Resource Class.

The password change frequency can be set at a global level within the RACF Global Options which is overridden by a lesser value that is set on the user’s individual userid profile.

The system automatically sets a user’s password to expire after it is changed by the security administrator. Userids can be set by the security administrator with passwords that do not expire by issuing the PASSWORD RACF command along with the NOINTERVAL operand. This capability could be used for userids that are established by processes that require a userid for validation purposes but does not allow any users to logon to the userid. Since all userids require a password, regardless if they are not used by an individual user, this NOINTERVAL option can be used for these types of userids.

RACF does not provide any facilities that allow a security administrator to a view a user’s password. RACF provides facilities to control the use of userids which are utilized at an installation’s discretion including:

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

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

o access entitlements can be granted on a temporary basis

A decentralized security administration function can be defined so that individuals can administer users and assign access entitlements for resources that are defined as being within their scope of responsibility. This is performed by assigning these decentralized security administrators the Group-Special authority. When a user is assigned Group-Special they are not able to alter RACF Global Options whose settings impacts all users.

There is no available method for users who are non-security administrators to assign their personal access entitlements to other users. The exception are users who are assigned as owners of user profiles and data set profiles. This allows them to assign other users the authorities that they themselves have been granted to by the resource that they have ownership authorities. In addition, those users who are assigned the ALTER authority to a dataset profile can assign their access entitlements to the dataset to other users.

Userids are suspended after a period of non-use by setting the INACTIVE RACF Global Option to an installation specified number of days.

 

Compliance With Above-Standard Protection Requirements

An installation can delegate the authority of resetting suspended (i.e., revoked) userids to non-security administrators (e.g., help desk function) without granting them the ability to perform most sensitive security administration functions. This is done by establishing these users as the owners of the userids for the users to whom you want to reset suspended userids. Setting the ownership for a user is defined within the user profile which requires the Special attribute. However, by defining these users as owners of userids, they are able to assign any authorities for which they have ownership authorities. Therefore, when using this approach of delegating responsibility for resetting suspended userids, the user profile assigned with this function should not be granted ownership authorities to any sensitive resources. In addition, defining these users as owners of userids allows them to delete these userids and change their passwords.

RACF provides a mechanism to separate some of the security administration functions. Independent individuals can be assigned authorities (i.e., Group-Special or CLAUTH) which allows them to define userids and assign access entitlements which also prevents them from setting RACF Global Options. However, a user requires the Special attribute to set RACF Global Options which also allows them to establish userids and assign access entitlements. In addition, auditing options are separated into the Auditor attribute which can not be set with the Special attribute.

Users are required to change their own passwords, which is a mandatory control. The exceptions are userids which are not used by individual users and which are set so as to not require a password change.

System Access

Compliance With Minimal Protection Requirements

RACF provides the following system access controls, which are not optionally set:

o a userid and password combination is used to identify the user

o passwords are not displayed on terminal in clear text

o all userids are required to be established with a password

Compliance With Standard Protection Requirements

RACF provides a hashing algorithm or DES encryption algorithm to conceal the password. The DES encryption algorithm is used by default. If the RACF supplied version of the ICHDEXO1 exit routine is installed (i.e., can be identified by reviewing the DSMON report), then the masking algorithm is used. RACF uses a one way encryption scheme. Therefore, when a password is entered, RACF encrypts/masks the password and compares it to the encrypted/masked value stored on the RACF database.

Profiles are used to permit users access to various types of resources. When a userid is removed from the system (i.e., referred to as a user profile), the entry in the resource profiles for the user is not automatically deleted. Therefore, it is possible for a future user who is assigned the same userid will have access to resources that are not required for their job function. Although, RACF provides the ICHUT1 00 utility that can be used by an installation to identify this type of occurrence, there is no preventive control available.

RACF provides the ability for an installation to suspend users after an installation specified number of invalid logon attempts. It is a discretionary setting which is set by the installation within RACF Global Options. However, RACF does not provide the ability to suspend a user after an installation specified number of unauthorized access attempts to a resource. In order to perform this function, an installation would have to insert user written code within the RACF exit that gains control after an access attempt is made.

Password controls are established by settings within the RACF Global Options which:

o require a password to be a site specified minimum number of characters

o prevent previous passwords from being used

o prevent passwords which are easily guessed from being used

o require all userids to be established with a password

RACF does not provide a terminal timeout facility. However, this can be set within other subsystems and system software products like TSO (i.e., JWT parameter within the SMFPRMxx module of SYS1 .PARMLIB) and CICS (i.e., within TIMEOUT parameter of DFHSNT module contained within //DFHRPL ddname of the CICS region’s start-up JCL).

SAF (i.e., IBM System Authorization Facility) propagates the ID and password of an already verified user to a job when a user submits a job without a userid. RACF also provides surrogate processing (i.e., using the SURROGAT RACF Resource Class) which allows the security administrators to define users who are permitted to submit jobs under the authority of another user without requiring knowledge of their password.

Users can be restricted from accessing the system through a particular point of entry (e.g., RJE) using the JESINPUT RACF resource class.

ISO users are notified of their last logon time and date which should make them aware if their userid has been compromised.

Compliance With Above-Standard Protection Requirements

RACF provides support for the use physical authentication devices (i.e., smart cards, tokens, secure-ids) through the use of RACF exits.

 

Security System Integrity

Compliance With Minimal Protection Requirements

RACF provides a profile concept to protect resources. Dataset profiles are used to define the access entitlements that users are granted to a dataset. Profiles are created for the DASDVOL RACF Resource Class to define the access requirements at the volume level for operational/maintenance purposes.

Compliance With Standard Protection Requirements

All DASD datasets are protected by default by RAGF if the PROTEGTALL in RACF System Resource Options is set to FAILURES.

All DASD volumes are automatically protected by RACF as long as the DASD VOL RACF Resource Glass is set to an ACTIVE status and the generic resource profile for the DASD volume has asterisks specified for the member name.

RACF optionally provides security at the tape dataset and tape volume level. Tapes are protected at the volume level by specifying the TAPEVOL RACF Resource Class with an ACTIVE status. Tape dataset security is provided by TAPEDSN being specified in the RACF Global Options.

Most changes to the RACF security database take affect immediately (i.e., does not require security system to be brought down or user to logoff).

System software products used within MVS that provide an interactive session for users (e.g., SDSF, CA-7) are commonly constructed to allow logon and resource security to be handled by RACF.

Compliance With Above-Standard Protection Requirements

RACF is installed in a manner in which it hooks into the operating system so as to prevent the operating system from functioning without RACF being active.

A RACF user’s profile, which specifies a user’s access entitlements, is stored in a user’s address space, but has storage key protection of zero which would prevent unauthorized updates.

As previously mentioned, the PROTECTALL RACF System Resource Options can be set to protect all datasets by default. All other resources types (e.g., programs, transactions) can also be defined to be protected by default by specifying masking characters in the associated generic profiles that are used to define access entitlements for each resource type.

RACF, like all other security products within the MVS environment, is a layered product which is not part of the direct code of the operating system. Therefore, an interface is constructed to process security calls which must be initiated by the operating system. RACF provides exits that can be used by an installation to perform additional security validation/processing routines, but can also be used to suppress security calls and return codes based on the point that they gain control within the overall security validation process.

MVS provides the Program Properties Table (PPT) which contains entries to allow a program executed from an APF library to bypass RACF security validation. Except for restricting the SYS1 .PARMLIB member SCHEDxx and all of the APF libraries, there is no other method provided for restricting these PPT entries from being used by an unauthorized individual. There are no secured facilities for administering the entries in the PPT table or to restrict which APF library the program must be executed from.

All tape datasets are protected by default by specifying PROTECTALL FAILURES and TAPEDSN in the RACF Global Option.

 

Auditability

Compliance With Minimal Protection Requirements

RACF maintains audit trails of all unauthorized accesses to resources which identify the resource being accessed, the type of access, and the user who attempted the access. The logging of unauthorized access attempts (i.e., violations) can be enabled or disabled within the individual profile or globally at the resource class level.

An audit trail is maintained of successful and unsuccessful logon attempts that is extracted using RACF provided reports.

Compliance With Standard Protection Requirements

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

The RACF Report Writer provides a flexible means to extract information contained in RACF-generated SMF records, which can be defined to perform the following types of searches:

o successful and unsuccessful accesses to installation specified resources

o accesses to installation specified resources during an installation specified day and time range

o all resources accessed by an installation specified userid

The RACF report writer does not allow searches to be performed by resources that are accessed by an installation specified device (e.g., terminal).

An audit trail is maintained of the following types of security administration changes:

o userids that have been added, deleted, or suspended

o establishment/changes to a user’s access privileges

o establishment/changes to resource access entitlements

o changes to installation security settings o changes to users password by the security administrator

 

Audit Trail Integrity

Compliance With Minimal Protection Requirements

The SMF records which are used by RACF to record security audit trail files can be a protected resource and the system is able to update the audit trails automatically without requiring authorization or being assigned a userid.

Compliance With Standard Protection Requirements

SMF sends a message to the console operator when a the SMF dataset becomes full. When there is no other SMF dataset to switch to, SMF discards all future SMF records that are generated. If SMF is inactive, an SMF record is cut to reflect the time in which SMF was rendered inactive and in which it was reactivated.

SMF record types can be suppressed using the SYS parameter within the SMFPRMxx member of SYS1 . PARMLIB. In addition, SMF datasets, which are dumped to tape using a SMF provided program, accept parameters within the JGL to suppress the dumping of specific SMF record types. There is no audit trail for any of these methods used to suppress the recording of SMF records.

RACF optionally duplicates all security changes to an alternate security database which can be switched in the event that the primary database becomes corrupted.

Compliance With Above-Standard Protection Requirements

RACF provides a system fix that can be applied by an installation to shut down the system when SMF records are about to be lost.

As discussed in the standard-protection section, mechanisms (e.g., commands) are provided which suppress the recording of SMF records.

Security audit trail data contained in buffers are not automatically recovered during the recovery process when there is 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.
 

AuditNet - The Global Resource for Auditors

Free
Audit Vision
Newsletter

Since 1991
Join 3,500 other subscribers

General Data Protection Regulation Seminar

Copyright © 2015. All Rights Reserved.