The external security systems used within an MVS environment (i.e., ACF2, RACF, and Top Secret) all provide methods to allow global access to system resources. The various methods used are well documented but the circumstances in which they should be used may not be clearly understood. This article will attempt to explain these circumstances. All security approaches discussed in this article are solely the opinion of the author and do not represent the approaches recommended by the vendors of the external security systems.
Operation Functions Requiring Access to Resources
Certain operation functions are required to have global access to volumes and datasets. These functions along with the access required are described in the following paragraphs.
ALLOCATE ADDITIONAL SPACE FOR AN EXISTING DATASET
The MVS environment requires installations to specify the amount of space which a dataset requires. Therefore, the allocation of space must be constantly adjusted. In order to allocate additional space for a dataset, the dataset must be copied to a temporary dataset, allocated additional space for the dataset, and then copied back to its original dataset name. This requires the user performing this function to have update and other access to the dataset. Since the datasets which will require additional space cannot be predicted, the user responsible for this function may require access to all datasets.
RESTORE AN ENTIRE VOLUME
FDR (Innovations Data Processing) and DF/DSS (IBM) are the most common products used to restore an entire volume in the event of a DASD failure. Update access to each dataset at the dataset level is not required since datasets are not opened for output to perform this function. However, volume level access would be required to restore an entire volume. Although volume level access alone would not permit a person to update individual datasets, the user can still restore an unauthorized dataset from tape by applying the dataset at a track level, overlaying the datasets.
RESTORE AN INDIVIDUAL DATASET
Individual datasets need to be restored in the event a dataset is corrupted or lost and the previous version must be restored. FDR, DS/DSS or the equivalent product used by an installation is typically used to perform this function. In order to restore the dataset, update access to the dataset is required. Since the dataset required to be restored cannot be predicted, access to all datasets would be required for this function.
DASD management is a function of system performance monitoring that requires datasets to be moved to and from any volume in order to obtain the best level of load balancing. Update access to datasets is required to move datasets across volumes. Since the datasets required to be moved cannot be predicted, access to all datasets may be required for this function.
Access Requirements for Operation Functions
The operation functions discussed above provide partial justification for operations personnel to be given would require complete access to any resource at a dataset level and at the volume level. The determination of whether one's installation should allow this global access is dependant on the frequency that these operation functions are performed. If they are performed infrequently then an emergency ID process can be utilized. This prevents the use of sensitive access unless approved by management and provides a closer review process for all functions that are performed.
Other approaches may consist of allowing access to a specific set of datasets and volumes based on the sensitivity of the resource. This approach would require a detailed naming convention for datasets and DASD volumes whereby the sensitivity level of these resources is identified. When using this approach, the global privileges within the external security systems can be reduced by explicitly preventing the users access to resources. For instance, in RACF the OPERATIONS attribute allows the user to bypass dataset security unless they have been specifically prevented.
The most effective method of controlling the operations personnel access to sensitive resources is to utilize program/library pathing or to perform the work through the Job Scheduling system. These methods are discussed later in the article.
The methods used by the external security systems to provide the access required to perform the operation functions discussed above are as follows:
Within Top Secret there are two methods available to allow access to every dataset: (1) assigning the user the NODSNCHK attribute, which allows the user to bypass dataset security checking and (2) assigning the user global update access to all datasets. The NODSNCHK is the author's preferred approach since it automatically audits each access performed using the NODSNCHK attribute.
There are two methods which can be used within Top Secret to provide the access capabilities required to restore an entire volume. The first approach would allow users to have global update access to all DASD volumes. This approach would require the user or profiles to which they are attached to be permitted access to the volumes to which they are responsible for restoring. Another approach is to assign the appropriate users the NOVOLCHK attribute. The NOVOLCHK will bypass all security checking for volumes, but dataset checking would still continue.
Within ACF2 there are two methods available to allow a user access to every dataset: (1) assigning the user the NON-CNCL privilege, which allows the user to bypass dataset security checking and (2) assigning the user global update access to all datasets by writing an access rule with masking characters (e.g., $KEY(*****.)).
Within ACF2 a user would require volume level access to a volume in order to restore an entire volume. ACF2 protected volumes are defined in the SECVOL GSO option. ACF2 rules for volume level access can be written to have one rule set for all secured volumes (i.e., VOLERULE specified in GSO record) or a set of rules for more than one volume (i.e., NOVOLERULE specified in GSO record).
Within RACF there are two methods available to allow a user access to every dataset: (1) assigning the user the OPERATIONS attribute which allows the user to bypass dataset security checking, unless they have been specifically prevented from having access and (2) assigning the user global update access to all datasets by including masking characters as the dataset within a generic dataset profile.
Within RACF a user would require access to the DASDVOL and GDASDVOL resource classes (i.e., defines resource profiles for DASD volumes) in order to restore an entire volume.
Methods to Control the Access Required for Operations Functions
One of the most effective tools used to prevent unauthorized updates from occurring when it is necessary to assign individual users update access to sensitive resources is to program/library path the users' access to the resource.
The concept of program/library pathing a user's access to a resource is based on allowing a user conditional access to the resource if the resource is accessed by a specific program fetched from a specific library. This approach only allows the user to access sensitive resources through an approved process and prevents unauthorized updates from occurring. However, the user must also be restricted from having update access to the library from where the program is fetched.
Program/library pathing is an effective method when there are specific programs used to perform an operation function. Therefore, program/library pathing would be effective for system software products used to perform these operation functions. Products like FDR and DF/DSS (i.e., used to dump and restore datasets and volumes), have a series of programs that they use which could be program/library pathed.
In a Top Secret environment, which is in FAIL mode, program/library pathing a user's access to a resource is established using the LIBRARY and PROGRAM keywords when specifying the PERMIT command to a resource.
Within ACF2, there are two methods used to perform program/library pathing. Prior to ACF2 release 6.0, the ACF99@RB module was used to specify the details of the program and library validation. Within ACF2 release 6.0, the PGM and LIB parameters in the rule entry can be used for program/library pathing. The specification of the method to be used is controlled through the PATHTRAN/NOPATHTRAN option of the RULEOPTS record of the GSO options. PATHTRAN specifies that the ACF99@RB module is to be used and NOPATHTRAN indicates that the ACF99@RB module is not to be used.
The MAINT GSO option in ACF2 provides the same effect as program/library pathing. Installations specify all of their maintenance programs and the library in which they reside within the MAINT record, along with the logonid that will be responsible for this function. This will allow the person executing these programs to bypass rule validation and SMF logging when they execute these maintenance programs. The person performing the maintenance function must be assigned either the NON-CNCL or MAINT privilege in order to perform this function. It is advisable not to assign the NON-CNCL privilege since this would enable the user to update the library which contains the maintenance program, unless they have been explicitly prevented from having access to the library.
RACF does not provide the ability to program/library path a user's access to a resource.
Submitting Jobs Through the Job Scheduling System
An alternative to granting individual users access to resources to perform sensitive operations functions is to submit the jobs which access the resources through the job scheduling system. The job scheduling system is already defined with update access to most of the production application resources since it performs the batch processing function. Using the job scheduling system to perform the sensitive operations functions (e.g., restore a dataset) provides the ability to remove the access from individual users. It should be noted that in an emergency, this approach may not feasible because of the time required to schedule a job and update the JCL for the specific requirements of the operation.
This article was written more than three years ago. Events may have
changed since this article was written.
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