S 4.211 Use of the z/OS security system RACF

Initiation responsibility: IT Security Officer, Head of IT

Implementation responsibility: Administrator

The secure configuration of a z/OS system is achieved by means of definitions of operating system components and centrally by means of the security system RACF (Resource Access Control Facility). This safeguard presents recommendations for the use of RACF. Information on the security of the z/OS definitions can be found in safeguard S 4.209 Secure basic configuration of z/OS systems.

In RACF the IDs of the users and the various ways of accessing different resources are managed by means of profiles. These are available as dataset profiles, general resource profiles, group profiles and their combinations, and also as user profiles.

The following rules are to be considered in the administration of RACF:

Important RACF settings

SETROPTS definitions

RACF is centrally configured in the SETROPTS settings. Universally applicable system-wide settings are undertaken here for RACF. Many of the parameters can be changed and, in some cases, interact with each other, therefore the settings must be well conceived and thought-out. Below is a list of the most important parameters which have to be set via the SETROPTS command.

Resource access policies for general resource classes  
CLASSACT Access authorization checking
AUDIT Enables logging function for classes
RACLIST Defines which profiles are loaded into the memory
GENERIC Activates Generic Profile Checking
NOADSP Prevents discrete profiles
PROTECTALL Ensures that RACF profiles are created
WHEN Allows conditional protection for programs
CMDVIOL Logs all RACF violations
OPERAUDIT Monitors IDs with the attribute OPERATIONS
ERASE Deletes file content after deletion of a file
etc.  

Table: Resource access policies for general resource classes

Password Policies for handling passwords  
INTERVAL Period of validity of the current password
REVOKE Number of invalid attempts at login allowed before blocking
RULE Defines password rules
etc.  

Table: Password Policies for handling passwords

The basic RACF setting is essential to the security of the z/OS operating system and is relatively complex. In some cases, more than 30 parameters may have to be defined or activated, therefore detailed planning is necessary. This ensures that the parameters are set correctly, thus avoiding potential security gaps. In order to aid the planning process, the vendor offers a RACF Security Planner (also available on the Internet). The RACF Security Planner also gives recommendations for the basic RACF setting.

Preset RVARY password

The preset password for the RVARY command, e.g for the RACF database SWITCH, must be changed and must not be set to the default value.

Use of RACF exits

It is necessary to examine whether RACF exits are required. The result of some exits is that RACF omits some security checks or conducts additional ones. Changed and user-defined exits must be documented, stating the function and reason for using the exit. If exits are used, they must be monitored (see S 2.291 Security reporting and security audits under z/OS).

RACF IDs

Limiting the number of login attempts

An ID created in RACF allows users to be authenticated to the z/OS system. In order to protect against brute force attacks, it is necessary to limit the number of possible login attempts so that the ID can be automatically blocked after a maximum of three to five attempts.

Creating an ID

There must be a procedure for creating an ID. The procedure must ensure that only persons who require access to the relevant system for their work and their substitutes are given an ID. The procedure may, for example, be automated or entail filling in a form. Whatever the case, the system administrator must approve the application.

Segments of an ID

Only those segments of an ID required by users for their work should be activated in the RACF (e.g. TSO, Netview, DCE or OMVS).

Unblocking an ID

A procedure must be in place for enabling a blocked ID. Users must provide unambiguous identification and evidence of their entitlement to the body unblocking the ID, e.g. the call centre or user helpdesk. Only then may the user's ID be unblocked.

TSO segment data

The data from the TSO segment (Time Sharing Option), e.g. name of logon procedure, account number or memory location, should be protected by RACF profiles from being overwritten by the user. This will mean that the user can only work with the stipulated environment. Any exceptions must be justified and documented.

Blocking due to inactivity

For security reasons, a user's ID should be blocked after it has been inactive for a predefined period, e.g. after 90 days. Procedure IDs, such as emergency IDs and STC IDs, should be exempt from this policy. Consideration should be given to checking the blocked IDs as to whether they might be deleted after an even longer period, e.g. 180 days. If such a delete process is performed, steps must be taken to ensure that the results of the delete process are logged and that the RACF administration is informed about it. The logs must be saved securely and serve the interests of traceability by the RACF administration.

Deleting an ID

User IDs are either deleted on request or as a result of internal checks. When an ID is deleted, it is important that all the relevant assignments are deleted along with the ID in RACF, as well as the ALIAS entry for this ID in the master catalogue. The files for this ID must either be likewise deleted or assigned to another ID.

Limiting restrictive IDs

IDs with a high level of rights should only be assigned to employees who actually need these authorisations for their work. Further information on this subject can be found in safeguard S 2.289 Use of restrictive z/OS IDs.

RACF groups and group structure

Authorisations should not be assigned directly to an ID. Users who perform the same work should be combined into groups and receive their authorisations via their group memberships. It is advisable to subdivide the group structure, e.g. as shown below:

Breakdown of group structure  
Organisational groups Assignment of IDs to organisational units of the government agency or company, e.g. ORGA
Functional groups Users receive their rights through these groups on the basis of tasks (functions) in the system, e.g. FUNKT.
Resource groups Used to administrate file resources. A group or an ID must exist for each file profile created in RACF. Groups are recommended, as they cannot be misused on entry to the system, e.g. RES.

Table: Breakdown of group structure

The following diagram illustrates one possible group structure:

Basic layout of the recommended group structure in RACF
Figure: Basic layout of the recommended group structure in RACF

The name of the SYS1 group is predefined. It must always be the top group. This group only contains the IBMUSER which is needed for a new installation. Further information on the IBMUSER can be found in safeguard S 2.289 Use of restrictive z/OS IDs.

The owner structure of the groups in RACF must be consistent. In this example, SYS1 is the owner of the ORGA, FUNKT, and RES groups. For further subgroups, the relevant group name of the parent group should be chosen as the owner. The hierarchical structure simplifies overview when using the authorisations Group-Special, Group-Operations and Group-Auditor.

Protection through RACF definitions

Protecting started tasks

Started asks must be created in RACF with an ID which possesses the PROTECTED attribute. The PROTECTED attribute prevents the ID from being misused for normal login. Started tasks must be defined and protected in the RACF class STARTED. Further information about started tasks can be found in safeguard S 4.209 Secure basic configuration of z/OS systems.

Protecting security-critical programs

Security-critical programs must be protected with the RACF class PROGRAM. Access to these programs should only be granted to users who need them for their work and to their substitutes. Further information on security-critical programs can be found in S 4.215 Protection of z/OS utilities that are critical to security.

Protecting files

Files are protected in RACF by means of file profiles. This applies to all system files and to all files relating to productive applications. The following procedures are relevant as regards the protection of files:

HFS files

The HFS files (Hierarchical File System) of the USS subsystem (Unix System Services) must be protected in z/OS through RACF like normal MVS datasets. Information on the protection of files in USS is contained in S 4.220 Protection of Unix System Services on z/OS systems.

Multi-client capability under z/OS

In many installations it is common practice for multiple customers (clients) to share one z/OS system. This means they are working on the same system; therefore it is necessary for the z/OS system to have multi-client capability. This means, among other things, that one customer cannot access the data of another customer and hence cannot compromise their confidentiality, integrity or availability.

The following information is of relevance regarding multi-client capability:

Segregation through RACF profiles

The data and applications of the clients must be segregated through RACF profiles. A RACF concept on client segregation should be drawn up to this end.

Protection of the operating systems

None of the clients may have write access to files of the z/OS operating system. Such changes may only be effected by the operator of the z/OS system.

IDs with high authorisation levels

High levels of authorisation in RACF (SPECIAL, OPERATIONS, AUDITOR) must be restricted to employees of the system operator. Consideration should be given to making the authorisations Group-Special, Group-Operations and Group-Auditor available to the customer on request. If this is the case, a group concept (owner concept) needs to be created specifically for any given customer.

Use of RACF security labels

Consideration should be given to using RACF security labels as a means of segregating customer environments more precisely.

Co-ordination of time slots provided for maintenance

The maintenance time slots, in which the z/OS system is not available, must be co-ordinated with all the customers working on the systems concerned.

Review questions:

© Federal Office for Information Security. All rights reserved.