S 4.209 Secure basic configuration of z/OS systems

Initiation responsibility: Head of IT, IT Security Officer

Implementation responsibility: Administrator

The z/OS operating system administers and uses different authorisation mechanisms. If these mechanisms are used improperly or misused, this may affect the integrity of the entire system. The mechanisms must therefore be taken into consideration in the basic configuration. These are mainly the following functions:

• APF-authorised files (Authorized Program Facility),
• SVCs (SuperVisor Calls),
• resource protection,
• Parmlib definitions,
• system procedures (Started Tasks), and
• JES2 definitions.

Recommendations for the security system RACF (Resource Access Control Facility) are described in S 4.211 Use of the z/OS security system RACF. Furthermore, S 4.220 Protection of Unix System Services on z/OS systems must be taken into consideration for the basic configuration.

The following recommendations must be taken into consideration in order to protect the z/OS operating system's integrity:

APF authorisations

APF-authorised files are required in order to gain access to privileged operations (e.g. MODESET SVC). As a consequence, functions can be used which the user normally does not have any authorisation for. In this way, it is possible at any time to gain access to privileged main memory areas and to assign highly privileged attributes (e.g. SPECIAL in the ACEE - Accessor Environment Element) to one's own ID in supervisor mode. The following must be taken into account for APF files:

• All APF files must be protected by means of fully qualified generic RACF profiles (as described in S 4.211 Use of the z/OS security system RACF), i.e. despite the use of generic profiles, the entire file name should be used as profile name.
• all APF files are defined in the Parmlib member PROGnn with volume information (and/or information SMS). There must be no entries for which there is no file, since otherwise there is the risk that another file could be implanted.
• Only those employees responsible for maintaining the system must have access to the APF files. The number of these employees should be restricted to a minimum. A substitution arrangement must be implemented.
• APF files must be checked regularly for changes in order to detect misuse and attempted misuse as early as possible. Changes to these files should only be performed during announced maintenance windows under production conditions.
• It must be considered whether the use of a real-time monitor helps to discover misuse more quickly and therefore contributes to increasing the security (see S 2.291 Security reporting and security audits under z/OS). In any case, at least manual controls of the access to APF files should be performed, e.g. by evaluating SMF records (System Management Facility).
• All APF files should be created without any extents.
• It should be taken into consideration that all files defined in the LINKLIST by default are deemed APF files by the system when using the parameter LNKAUTH=LNKLST in the IEASYSxx member. Therefore, the security mechanisms described above must also be enabled for these files.

User SVCs (SuperVisor Calls)

User SVCs (all SVC numbers over 200) are provided with the control in the SuperVisor status by Key 0 (this corresponds to the kernel mode for some other operating systems), i.e. user SVCs may access all memory areas and all operations of the z/OS operating system. Therefore, the following must be taken into account for user SVCs:

• All files providing SVC programs must be protected by means of fully qualified generic RACF profiles (as described in S 4.211 Use of the z/OS security system RACF).
• All SVCs are defined in the Parmlib member IEASVCxx. Since an SVC may not be very small due to the required internal security mechanisms, a short user SVC module may indicate a security problem. Such user SVCs must be checked by system programming as to whether security-critical gaps are present. SVCs with insufficient security mechanisms used to be used frequently, e.g. so-called authorisation SVCs, in order to be able to execute authorised functions from unauthorised environments. If such SVCs still exist, they should be removed or replaced, if possible.
• If user SVCs are supplied within the framework of products, the manufacturer should be consulted regarding the security mechanisms of the supplied SVCs. This is particularly important if the supplied SVC module is very small, since this may possibly be an indication of a lack of internal checks.
• Only those employees responsible for maintaining the system may have access to SVC files. The number of these employees must be minimised. At the same time however, it must be ensured that at least one substitute is granted access.

Resources

Resources of the z/OS operating system (e.g. files, programs, functions, etc.) must be protected by means of RACF (see S 4.211 Use of the z/OS security system RACF). Furthermore, the following recommendations should be taken into consideration:

• For the Class Descriptor Table (CDT), installation-specific entries should only be performed in the ICHRRCDE module. DFTUACC (NONE is recommended here) and OPER (NO is recommended here) are important parameters to observe. The Dataset Name Table (DSNT) must contain the file names of the RACF databases.
• The Authorized Caller Table (AUT) should be empty according to IBM's recommendation. This is an old function that has been replaced by the Program class today, but still exists. Exceptions must be justified.
• The TSO Authorized command and program table in the Parmlib (IKJTSOxx) must only contain the command and program names required for execution under TSO (Time Sharing Option).
• The Started Procedure Table (ICHRIN03) should only contain a few entries for emergencies; otherwise, the definition of the authorised Started Tasks should be based on the RACF class STARTED. The PRIVILEGED attribute should be avoided and TRUSTED should only be used if required (e.g. for JES2). The table should contain a generic entry for all Started Tasks not defined in order to ensure that these tasks cannot be executed.
• The RACF Router Table must be maintained synchronously to the CDT.
• RACF offers two password encryption algorithms, the Masking Algorithm and the DES encryption (Data Encryption Standard). The RACF passwords should be encrypted using DES, since this provides better protection when compared to Masking. This is controlled by the RACF exit ICHDEX01. RACF-specific recommendations can be found in S 4.211 Use of the z/OS security system RACF.

IPL parameter file

The IPL parameter file (Initial Program Load) contains the essential information required for initialising the z/OS operating system. This file must be protected with the help of RACF and the number of employees authorised for this file must be kept low. However, it must be ensured that substitution arrangements are implemented.

Parmlib definitions

The parameter files of the z/OS operating system (SYSn.PARMLIBs, there may be several) contain essential definitions of the operating system. All Parmlib files must be protected with the help of RACF. Access must only be granted to those employees who edit these files within the framework of their work. It must be considered whether different parameter files with different RACF protection should be used, since the Parmlib contains definitions with different protection requirements. Security-critical members of the Parmlib include, for example (without sorting):

• BPXPRMxx
• CLOCKxx
• COMMNDxx
• CSVLLA00
• IEASYSxx
• IEFSSNxx
• IKJTSOxx
• MSTJCLxx
• PROGxx
• SCHEDxx
• SMFPRMxx

Access to these definitions must be restricted to the required employees. Substitution arrangements must be in force.

System procedures

All important procedures of the Started Tasks can be found in specific libraries announced to the system either using the MSTJCLxx definitions or the JES2/3 definitions. The files, e.g. SYS1.PROCLIB, must be protected with the help of RACF profiles which only grant authorised employees access to the definitions.

The protection of generic login procedures, i.e. login procedures used by all employees, is particularly important, since the risk of misuse is particularly high here (see safeguard S 4.213 Protecting the login process under z/OS). The write/edit access should be restricted to the system administrators; furthermore, only JES2/3 requires read access.

These safeguards are also applicable to all script files used in generic login procedures (TSO CLISTs, or REXX EXECs), since the risk of misuse is particularly high here as well.

JESx definitions (Job Entry Subsystem)

In order to protect the Job Entry subsystems JES2 and JES3, the following resources must mainly be protected by RACF:

• JES-proprietary files,
• input from other sources (e.g. other nodes),
• job names,
• system input/output on the JES spool, and
• output for other nodes or remote workstations.

The following RACF functions should be used in order to increase the security of JES2/3:

• BATCHALLRACF
  
  (forcing the ID for batch jobs)
• EARLYVERIFY
  
  (only Early Verify possible)
• XBMALLRACF
  
  (support of the execution batch monitor)
• NJEUSERID
  
  (assignment of the Default Userid for Network Job Entry functions)
• UNDEFINEDUSER
  
  (assignment of the Undefined Userid for Network Job Entry functions)

Furthermore, RACF provides a host of General Resource Classes for JES2/3 that should be used for protecting JES functions:

• OPERCMDS
• JESSPOOL
• SURROGAT
• NODES
• WRITER

Review questions:

• Has it been ensured that only employees responsible for maintaining the z/OS system may access the APF and SVC files?
• Is there a substitution arrangement for the basic configuration of the z/OS systems?
• Are the APF files in the z/OS system subjected to regular checks for changes?
• Have all APF files been created in the z/OS system without any extents?
• Are the resources of the z/OS operating system protected by RACF?
• Are the IPL parameter file and all Parmlib files protected by RACF in the z/OS system?
• Has the access to the Parmlib files in the z/OS system been restricted to the employees having to regularly edit these files?
• Are all important system procedures protected by RACF profiles in the z/OS system in such a way that only authorised employees may access the definitions?
• Are the Job Entry Subsystems JES2 and/or JES3 protected by RACF?