SYS.1.7 IBM Z

High-level authorisations MUST ONLY be assigned to users who need these rights for their activities. In particular, the RACF attributes SPECIAL, OPERATIONS, AUDITOR, and the corresponding GROUP attributes, as well as the user ID 0, MUST be handled restrictively under Unix System Services (USS). The assignment and use of these authorisations MUST be documented transparently. The special ID IBMUSER MUST ONLY be used during reinstallation to create IDs with SPECIAL attributes. Once this is complete, this ID MUST be permanently disabled. To prevent administrators from permanently locking themselves out, an emergency user procedure MUST be set up.

Security-critical (service) programs and commands and their alias names MUST be protected with rights to corresponding RACF profiles in such a way that they can only be used by the designated and authorised employees. It MUST be ensured that (third-party) programs cannot be installed without authorisation. In addition, programs MUST ONLY be installed from secured sources using transparent methods (e.g. SMP/E).

Z hardware and firmware, the operating system in question, and the various programs used MUST be maintained regularly and on the basis of need. The maintenance activities required for this MUST be planned and integrated into change management (see OPS.1.1.3 Patch and Change Management). In particular, updates MUST ONLY be performed by the manufacturer under the supervision of the operator and either locally via SE (Support Elements) or HMC (Hardware Management Console) or remotely via the RSF (Remote Support Facility).

Administrators, operators, and auditors with tasks related to z/OS MUST be trained accordingly. In particular, RACF administrators MUST be familiar with the security system itself and any other functions relevant to it.

System-adjacent z/OS terminals MUST be physically and logically protected against unauthorised access. The Support Elements in particular MUST be considered, along with the HMC, MCS, SMCS, Extended MCS, and monitor consoles. Default passwords MUST be changed. Access via web servers and other remote access MUST be protected by encryption. Web servers and other forms of remote access MUST be disabled when not in use.

The head of the IT Operation Department MUST decide whether and how RSF is to be used. Such use MUST be governed by a corresponding maintenance contract and coordinated with hardware support staff. It MUST be ensured that the RSF configuration can only be changed by authorised persons. Maintenance access for firmware modifications by the manufacturer MUST be explicitly approved by the operator and disabled again after these modifications are completed. RSF communication MUST take place via a proxy server and also using secure connections (such as TLS).

In the basic configuration of z/OS, the authorisation mechanisms MUST be configured so that all persons (defined user IDs in groups according to the respective roles) only have the access options they need for their respective activities. For this purpose, APF (authorised program facility) authorisations, supervisor calls (SVCs), resources of the z/OS operating system, IPL parameters, Parmlib definitions, started tasks, and JES2/3 definitions MUST be considered.

The use of the RACF for z/OS MUST be planned carefully. This includes the selection of a character set, the definition of rules for user IDs and passwords, and the activation of KDFAES encryption. If RACF PassTickets are used, the Enhanced PassTicket algorithm MUST be enabled. Default passwords for the RVARY command and for newly created user IDs MUST be changed. If RACF exits are to be used, their use MUST be justified, documented, and regularly monitored.

Suitable procedures MUST be defined for creating, locking, releasing, and deleting RACF IDs. After a specified number of failed login attempts, an RACF ID MUST be locked (exception: emergency user procedures). User IDs MUST also be blocked after a prolonged period of inactivity, but process IDs must not.

Files, started tasks, and security-critical programs MUST be protected with RACF profiles. Users MUST ONLY receive the data access they need in accordance with their roles. It MUST also be ensured that users are not able to extend their access options without permission.

If a z/OS system is to be used by clients, an RACF concept for client separation MUST be created. The data and applications of the clients MUST be segregated by means of RACF profiles. High-level authorisations in RACF (SPECIAL, OPERATIONS, AUDITOR) and change access to files of the z/OS operating system MUST ONLY be granted to employees of the operator. The maintenance time slots in which the z/OS system will not be available MUST be coordinated with all the clients working on the system concerned.

Session data for the connections of RACF administrators and other employees MUST be transferred in encrypted form.

A process SHOULD be set up to monitor all security-relevant operations in z/OS. This SHOULD specify the security reports to be produced regularly, the tools and data sources to be used (e.g. the system management facility), and how deviations from specifications are to be dealt with. The security reports SHOULD be used as information during checks.

During operation, the z/OS system SHOULD be monitored for important messages, events, and compliance with thresholds. In particular, error messages on the HMC console, WTOR and important WTO messages (write to operator/with reply), system tasks, security breaches, capacity limits, and system utilisation SHOULD be considered. At minimum, the MCS console, the system management facility, the SYSLOG, and the relevant log data of applications SHOULD also be used for monitoring. It SHOULD be ensured that all important messages are recognised promptly and responded to in an appropriate manner when required. System messages SHOULD be filtered in such a way that only those messages that are actually important are displayed.

If z/OS passwords or RACF commands are to be automatically synchronised across several z/OS systems, the respective systems SHOULD be standardised to the greatest extent possible. The blocking of user IDs due to incorrect password entries SHOULD NOT be synchronised. The risk of synchronising security-critical RACF commands SHOULD be taken into account. The management function of the synchronisation program used SHOULD only be available to authorised employees within the scope of their activities.

For z/OS systems, a role concept SHOULD be introduced for system administration at minimum. Arrangements for deputies SHOULD also be in place for all important system administration roles. The RACF attributes SPECIAL, OPERATIONS, and AUDITOR SHOULD be assigned to different people (role separation).

If transaction monitors or databases such as IMS, CICS, or Db2 are used in z/OS, they SHOULD be backed up using RACF. This also applies to the associated system commands and files. Internal security mechanisms for transaction monitors and databases, on the other hand, SHOULD only be used where there are no corresponding RACF functions. Users and administrators SHOULD only receive the access rights they need for their respective tasks.

When decommissioning a z/OS system, other z/OS systems, groupings, and management systems SHOULD be adapted so that they no longer refer to the decommissioned system. The impact on software licences SHOULD also be considered.

Hard disks containing confidential data SHOULD be deleted in such a way that their content cannot be reproduced. In the event that defective hard disks are replaced by the manufacturer, it SHOULD be contractually agreed that these hard disks will be securely destroyed or deleted in such a way that their contents can no longer be reproduced.

The parameters necessary for the startup procedure of a z/OS system SHOULD be documented and known to the operating personnel. The required hardware configurations, such as the IOCDS file (Input/Output Configuration Data Set) and the LPARs (logical partitions), SHOULD also be available. A z/OS master console and a backup console SHOULD be defined to control messages. After the startup procedure, a checklist SHOULD be used to monitor whether the system status corresponds to the target specifications. In addition, a fallback configuration with which the system was successfully started before the last change SHOULD be maintained.

All maintenance work affecting production, as well as dynamic changes and other modifications, SHOULD only be carried out within the framework of change management (see OPS.1.1.3 Patch and Change Management). SDSF (System Display and Search Facility) and similar functions, as well as priority control for jobs, SHOULD be protected against unauthorised access using RACF. z/OS system commands—in particular, security-relevant commands for dynamic changes—SHOULD be protected via RACF. When defining hardware dynamically, it SHOULD be ensured that a resource is not assigned to several individual systems outside a Parallel Sysplex during actual operations.

If z/VM is used, it SHOULD be integrated into patch management. All default passwords SHOULD be changed. The role of z/VM system administrator SHOULD only be assigned to persons who require the corresponding authorisations. RACF for z/VM SHOULD be used for z/VM security administration. Passwords for real users and guest users SHOULD be encrypted using RACF for z/VM. z/VM system commands that are critical to security SHOULD be protected using RACF. The virtual machines defined in z/VM SHOULD only be provided with the resources necessary to perform their particular tasks and strictly separated from each other. Only the services needed SHOULD be started in z/VM. When checks are performed, the journalling function of z/VM and the audit functions of RACF SHOULD be used.

Files, programs, and functions for the administration of storage media—as well as storage media themselves (hard disks and tapes), including the master catalogue—SHOULD be protected using RACF profiles. Backup copies of all important files SHOULD be available that can be installed in case of an emergency. The assignment of storage media to Z systems SHOULD be documented transparently. It SHOULD be ensured that sufficient tape stations are available for the volume and time frame at hand. The hard disks that are to be backed up and the backup procedure itself SHOULD be specified when using the HSM (Hierarchical Storage Manager). Tapes that are managed by the HSM SHOULD NOT be modified elsewhere.

The limits for maximum resource load (number of CPUs, storage, bandwidth, etc) SHOULD be set according to the hardware requirements at hand and made known to the administrators and application owners in charge. The number of magnetic tape stations available, the times during which applications access these stations, and the required disk capacities SHOULD be agreed with the application owners. Hard disk capacities SHOULD also be monitored by a space management solution.

The programs, files, and commands of the Workload Manager (WLM), as well as the necessary couple data sets, SHOULD be protected by RACF. It SHOULD be ensured that the authorisations required to change the WLM via z/OS commands and via the SDSF interface are the same.

When text files are transferred between z/OS systems and other systems, it SHOULD be taken into account that character set conversion may be required. The correct conversion table SHOULD be used for this. When transferring program source code, the correct translation of characters SHOULD be checked. When transmitting binary data, on the other hand, it SHOULD be ensured that no character set conversion takes place.

For licence keys with limited validity, a timely renewal procedure SHOULD be put in place. The contract periods of the licence keys SHOULD be documented. The documentation SHOULD be made available to all the administrators concerned.

The parameters of Unix System Services (USS) SHOULD be set according to the functional and security specifications at hand while taking the available resources into account. HFS and zFS files containing USS file systems SHOULD be backed up via RACF profiles and included in a backup concept. The root file system SHOULD also be mounted with the read-only option. In the USS file system, APF (authorised program facility) authorisations SHOULD NOT be granted using a file security packet (FSP). The modules of APF files of the z/OS operating system SHOULD be loaded instead. The assignment between USS user IDs and z/OS user IDs SHOULD be clear. Authorisations under USS SHOULD be assigned using the RACF class UNIXPRIV and NOT by assigning UID 0. The USS SHOULD be checked and monitored using the same mechanisms used for z/OS.

The trace functions of z/OS, such as GTF (generalised trace facility), NetView, or ACF/TAP (Advanced Communication Function/Trace Analysis Program) and the corresponding files, SHOULD be protected in such a way that only the responsible and authorised employees have access to them. The trace function of NetView SHOULD be disabled and only activated if required.

A procedure SHOULD be established for recovering a functioning RACF database. Furthermore, a copy of the z/OS operating system SHOULD be kept as a z/OS backup system and a z/OS business continuity system maintained separately from the production system.

Standards and naming conventions for z/OS system definitions SHOULD be defined and documented. The documentation SHOULD be made available to all administrators. Regular checks SHOULD be performed to ensure that the standards are being followed. Standards SHOULD be defined for file, database, job, and volume names in particular, as well as for application, system, and user IDs.

Technical measures SHOULD be taken to separate development and test systems from production systems in z/OS. Possible access options via shared hard disks and the Parallel Sysplex SHOULD be taken into account.

If a z/OS system processes a large number of batch jobs, a job scheduler SHOULD be used for batch job flow control. The job scheduler and the associated files and tools SHOULD be suitably protected by RACF.

If RACF exits are used, the ramifications for technical security and operations SHOULD be analysed. RACF exits SHOULD also be installed and monitored via the SMP/E (System Modification Program/Enhanced) as USERMOD.

Communication between operating systems—e.g. between z/OS and Linux, which are either installed in LPAR mode or under z/VM on the same Z hardware—SHOULD take place over internal channels (i.e. HiperSockets or virtual channel-to-channel (CTC) connections).

Based on the availability and scalability requirements at hand, a decision SHOULD be taken as to whether a Parallel Sysplex (a cluster of z/OS systems) is to be used and, if so, what redundancies are planned. The requirements of applications SHOULD be taken into account when planning the capacity of the necessary resources. The software and the definitions of the LPARs of the Sysplex, including RACF, SHOULD be synchronised or provided as shared files.

It SHOULD be ensured that all the LPARs of the Sysplex can access the couple data sets. The couple data sets, as well as all security-critical programs and commands for managing the Sysplex, SHOULD be protected by RACF. A GRS (global resource serialisation) network SHOULD also be set up. The hard disks of the Sysplex SHOULD be strictly separated from the hard disks of other systems. The system logger SHOULD be used with staging data sets.

If a VTAM session management exit is to be used, it SHOULD be ensured that it will not impair secure and efficient operations. At minimum, the exit SHOULD allow a subsequent check of a rejected login attempt. In addition, the exit SHOULD be configured dynamically and the set of rules loaded from an external file. Functions, commands, and files related to the exit SHOULD be protected by RACF.