SYS.1.7 IBM Z

Description

Introduction

Systems of the “IBM Z” type belong to the server systems generally referred to as mainframes. Mainframes have evolved from classic standalone batch-processing systems to modern client-server systems. The Z architecture is the successor to the S/360 architecture introduced in 1964 and is frequently used in today’s mainframe installations.

Objective

The objective of this building block is to protect information that is processed, offered, or transmitted on Z systems.

Scope and Modeling

The building block SYS.1.7 IBM Z is to be applied to every server based on IBM’s Z architecture.

The building block SYS.1.1 General Server forms the foundation for server hardening. For Z systems, both the general requirements listed there and the specific requirements in the present building block must be fulfilled.

Various operating systems are available for Z hardware (e.g., z/OS, z/VM, KVM, or Linux on Z). The selection is generally made based on the parameters of machine size and intended purpose. The recommendations in this building block are essentially limited to the z/OS operating system. Selected security aspects of z/VM are also addressed. For the Linux on Z operating system, reference is made to building block SYS.1.3 Servers Running Linux and Unix.

Further requirements particularly relevant for IBM Z can be found in building block ORP.4 Identity and Authorization Management and in OPS.1.2.5 Remote Maintenance.

An important component of the technical security concept for Z systems is the security system in use, for example TopSecret, ACF2 (Access Control Facility), or RACF (Resource Access Control Facility). For simplicity, only RACF is referenced below. The recommendations should be adapted accordingly if a different security system is used.

The specific services offered by the Z system are not part of this building block. For these services, additional building blocks must also be implemented, in accordance with the results of the IT-Grundschutz modeling.

Threat Landscape

Since IT-Grundschutz building blocks cannot address individual information domains, typical scenarios are used to describe the threat landscape. The following specific threats and vulnerabilities are of particular significance for building block SYS.1.7 IBM Z.

Inadequate or Incorrect Configuration of Hardware or the z/OS Operating System

The configuration of a z/OS operating system is very complex and requires system administrator intervention in many areas. Incorrect or inadequate configuration can give rise to vulnerabilities that can lead to corresponding security problems. SuperVisor Calls (SVCs) are, for example, calls to special z/OS utility programs that run in the highly authorized kernel mode. Insecure SVC programs can potentially be used to bypass z/OS security mechanisms.

Incorrect Configuration of the z/OS Security System RACF

In a z/OS operating system, a special security system is responsible for the authentication of users and their authorization to resources. RACF is frequently used for this purpose. The default configuration of RACF typically does not meet the security requirements of the respective deployment scenario. Resources and z/OS system commands are, for example, protected via special classes in RACF. Inadequate definitions of these classes can allow users to issue system commands that may impair stable system operation.

Operating Errors of z/OS System Functions

Due to the complexity of a z/OS operating system and its components, operating errors cannot be entirely ruled out. Depending on the type of error, individual components or the entire system may fail as a result. For example, if resources mutually lock (contention), certain functions may be unavailable until the lock is released. A series of system queries (displays) and extensive operational experience are often necessary to resolve mutual locks using the correct z/OS commands.

Manipulation of z/OS System Control

z/OS systems can be influenced via a variety of interfaces, for example via the Hardware Management Console, local and remote MCS consoles, automation procedures, and remote maintenance access. If, for example, physical or logical access to remote MCS consoles is inadequately protected, z/OS systems can potentially be manipulated without authorization from those locations.

Attacks via TCP/IP on z/OS Systems

Attacking a z/OS system via the network connection often requires no specialist knowledge of the network architecture or of z/OS. Due to the TCP/IP connection to (potentially public) networks and the Unix System Services, many z/OS systems are reachable for internal and external attacks via standard protocols and services such as HTTP or FTP. In external attacks, denial-of-service attacks against offered services can potentially be carried out via the TCP/IP connection to public networks, or transmitted data can be read or manipulated without authorization. Internal attackers can use the TCP/IP connection to internal networks to attempt to escalate their privileges — for example by spying on the username and password of users with SPECIAL rights.

Incorrect Character Set Conversion When Using z/OS

EBCDIC, ASCII, and Unicode are character sets that define how letters, digits, and other characters are represented using bits. z/OS systems operate with EBCDIC code. Only HFS and zFS file systems used under Unix System Services (USS) support both ASCII and EBCDIC storage. When exchanging data between z/OS systems and IT systems that use ASCII or Unicode (e.g., also from USS to z/OS), there is a risk of information being corrupted if incorrect translation tables (code page translation) are used. Special characters are particularly frequently affected.

Requirements

The following are the specific requirements of building block SYS.1.7 IBM Z. The Information Security Officer (ISO) is responsible for ensuring that all requirements are fulfilled and verified in accordance with the established security concept. The ISO must always be involved in strategic decisions.

Additional roles are defined in the IT-Grundschutz Compendium. They should be filled insofar as this is sensible and appropriate.

Exactly one role should be Primarily responsible. In addition, there may be Additional responsibilities. If one of these additional roles is primarily responsible for fulfilling a requirement, that role is listed in square brackets after the heading of the requirement. The use of singular or plural says nothing about how many persons should fill these roles.

Basic Requirements

The following requirements MUST be fulfilled as a priority for this building block.

SYS.1.7.A1 Use of Restrictive z/OS Identifiers (B)

High-authorization permissions MUST ONLY be granted to users who require these rights for their activities. In particular, the RACF attributes SPECIAL, OPERATIONS, AUDITOR, and the corresponding GROUP attributes, as well as User ID 0 under Unix System Services (USS), MUST be handled restrictively. The assignment and use of these permissions MUST be traceable. The special identifier IBMUSER MUST ONLY be used during new installation to create identifiers with the SPECIAL attribute. This identifier MUST then be permanently locked. To avoid permanently locking out administrators, an emergency user procedure MUST be established.

SYS.1.7.A2 Hardening of Security-Critical z/OS Utility Programs (B)

Security-critical (utility) programs and commands and their aliases MUST be protected with rights to corresponding RACF profiles in such a way that they can only be used by persons authorized for this purpose. It MUST be ensured that (third-party) programs cannot be installed without authorization. Furthermore, programs MUST ONLY be installed from secured sources and via traceable methods (e.g., SMP/E).

SYS.1.7.A3 Maintenance of Z Systems (B)

Z hardware and firmware, the operating system, and the various programs MUST be regularly maintained and updated as needed. 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 by the manufacturer MUST ONLY be performed under the control of the operators, either locally via SE (Support Elements) or HMC (Hardware Management Console), or remotely via RSF (Remote Support Facility).

SYS.1.7.A4 Training of z/OS Operations Personnel (B) [Supervisors]

Administrators, operators, and auditors in the z/OS area MUST be trained according to their tasks. In particular, RACF administrators MUST be familiar with the security system itself and, if applicable, with the other functions relevant to them.

SYS.1.7.A5 Use and Security of System-Adjacent z/OS Terminals (B)

System-adjacent z/OS terminals MUST be protected physically against unauthorized access and logically against unauthorized access. In particular, the support elements as well as the HMC, MCS, SMCS, Extended MCS, and monitor consoles MUST be taken into account. Default passwords MUST be changed. Access via web servers and other remote access MUST be protected by encryption. Unneeded web servers and remote access MUST be deactivated when not needed.

SYS.1.7.A6 Use and Security of the Remote Support Facility (B)

A decision MUST be made as to whether and how RSF is to be used. The use MUST be provided for in the maintenance contract and coordinated with hardware support. It MUST be ensured that the RSF configuration can only be changed by authorized persons. Maintenance access for firmware modifications by the manufacturer MUST be explicitly released by the operators and deactivated again after completion. RSF communication MUST take place via proxy servers and additionally via secured connections (such as TLS).

SYS.1.7.A7 Restrictive Authorization Under z/OS (B)

As part of the basic configuration, the authorization mechanisms MUST be configured such that all persons (defined user IDs in groups according to role) only receive the access options they require for their respective activities. In particular, APF authorizations (Authorized Program Facility), SVCs (SuperVisor Calls), resources of the z/OS operating system, IPL parameters, parmlib definitions, started tasks, and JES2/3 definitions MUST be taken into account.

SYS.1.7.A8 Use of the z/OS Security System RACF (B)

The use of RACF for z/OS MUST be carefully planned; this includes the selection of the 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 activated. 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.

Appropriate procedures MUST be defined for creating, locking, unlocking, and deleting RACF identifiers. After a defined number of failed login attempts, a RACF identifier MUST be locked (exception: emergency user procedure). User identifiers MUST also be locked after prolonged inactivity; identifiers for procedures, however, must not.

Files, started tasks, and security-critical programs MUST be protected via RACF profiles. Users MUST ONLY be granted the access options they require according to their role. It MUST also be ensured that users cannot extend their access options without authorization.

SYS.1.7.A9 Multi-Tenancy Under z/OS (B)

If a z/OS system is to be used by tenants, a RACF concept for tenant separation MUST be created. The data and applications of tenants MUST be separated by RACF profiles. High authorizations in RACF (SPECIAL, OPERATIONS, AUDITOR) and modifying access to files of the z/OS operating system MUST ONLY be held by employees of the operators. Maintenance windows during which the z/OS system is not available MUST be coordinated with all tenants working on the affected system.

SYS.1.7.A10 DISCONTINUED (B)

This requirement has been discontinued.

SYS.1.7.A11 Protection of Session Data (B)

Session data for connections of RACF administrators and, where possible, also of other employees MUST be transmitted in encrypted form.

Standard Requirements

Together with the basic requirements, the following requirements reflect the state of the art for this building block. They SHOULD generally be fulfilled.

SYS.1.7.A12 DISCONTINUED (S)

This requirement has been discontinued.

SYS.1.7.A13 DISCONTINUED (S)

This requirement has been discontinued.

SYS.1.7.A14 Reporting for Secure Operation of z/OS (S)

A process SHOULD be established to monitor all security-relevant activities under z/OS. This SHOULD define which security reports are to be regularly generated, which tools and data sources are used for this purpose (e.g., System Management Facility), and how deviations from requirements are handled. Security reports SHOULD be used as information during reviews.

SYS.1.7.A15 DISCONTINUED (S)

This requirement has been discontinued.

SYS.1.7.A16 Monitoring of z/OS Systems (S)

During operation, the z/OS system SHOULD be monitored for important messages, events, and compliance with threshold values. In particular, error messages on the HMC console, WTOR and important WTO messages (Write To Operator/with Reply), system tasks, security violations, capacity limits, and system utilization SHOULD be taken into account. For monitoring, at a minimum the MCS console, the System Management Facility, the SYSLOG, and the relevant log data of the applications SHOULD also be consulted. It SHOULD be ensured that all important messages are recognized promptly and, if necessary, responded to appropriately. System messages SHOULD be filtered so that only the important messages are displayed.

SYS.1.7.A17 Synchronization of z/OS Passwords and RACF Commands (S)

If z/OS passwords or RACF commands are to be automatically synchronized across multiple z/OS systems, the respective systems SHOULD be standardized as extensively as possible. The locking of identifiers due to incorrect password entries SHOULD NOT be synchronized. The risk from synchronization of security-critical RACF commands SHOULD be taken into account. The administration function of the synchronization program SHOULD only be available to authorized employees within the scope of their activities.

SYS.1.7.A18 Role Concept for z/OS Systems (S)

A role concept SHOULD be introduced at least for the system administration of z/OS systems. Deputy arrangements SHOULD also be in place for all important roles in system administration. The RACF attributes SPECIAL, OPERATIONS, and AUDITOR SHOULD be assigned to different persons (role separation).

SYS.1.7.A19 Hardening of z/OS Transaction Monitors (S)

If transaction monitors or databases are used under z/OS, such as IMS, CICS, or Db2, these SHOULD be secured via RACF. This also applies to the associated system commands and files. Internal security mechanisms of transaction monitors and databases SHOULD, in contrast, only be applied where there are no corresponding RACF functions. Users and administrators SHOULD only receive the access rights they require for their respective activities.

SYS.1.7.A20 Decommissioning of z/OS Systems (S)

When decommissioning z/OS systems, other z/OS systems, networks, and management systems SHOULD be adapted so that they no longer refer to the decommissioned system. The impact on software licenses SHOULD also be taken into account.

Data media containing confidential data SHOULD be erased in such a way that their content can no longer be reproduced. In the event that defective data media are exchanged by the manufacturer, it SHOULD be contractually agreed that these hard drives are securely destroyed or erased in such a way that their content can no longer be reproduced.

SYS.1.7.A21 Hardening of the Startup Process of z/OS Systems (S)

The parameters required for starting a z/OS system SHOULD be documented and known to operations personnel. Furthermore, the required hardware configurations SHOULD be available, such as the IOCDS file (Input/Output Configuration Data Set) and the LPARs (Logical Partitions). A z/OS master console and a backup console SHOULD be defined to enable monitoring of messages. After startup, a checklist SHOULD be used to verify whether the system status corresponds to the target specifications. In addition, a fallback configuration SHOULD be maintained with which the system was successfully started before the last change.

SYS.1.7.A22 Hardening of Operational Functions of z/OS (S)

All maintenance work affecting production, as well as dynamic and other changes, 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 unauthorized access via RACF. z/OS system commands and particularly security-relevant commands for dynamic changes SHOULD be protected via RACF. When dynamically defining hardware, it SHOULD be ensured that a resource in live operation is not assigned to multiple individual systems outside a Parallel Sysplex.

SYS.1.7.A23 Hardening of z/VM (S)

If z/VM is used, the product 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 these authorizations. Security administration of z/VM SHOULD be carried out via RACF for z/VM. Passwords of real users and guest users SHOULD be encrypted via RACF for z/VM. Security-critical system commands of z/VM SHOULD be protected via RACF. Virtual machines defined under z/VM SHOULD only receive the resources necessary for their respective tasks and be strictly separated from one another. Under z/VM, only the services that are required SHOULD be started. When performing reviews, the journaling function of z/VM and the audit functions of RACF SHOULD be used.

SYS.1.7.A24 Data Media Management Under z/OS Systems (S)

Files, programs, and functions for managing data media, as well as the data media themselves (hard drives and tapes), including the master catalog, SHOULD be protected via RACF profiles. Backup copies of all important files SHOULD be available that can be restored in an emergency. The assignment of data media to Z systems SHOULD be traceable. It SHOULD be ensured that, depending on volume and time window, sufficient tape stations are available. When using HSM (Hierarchical Storage Manager), it SHOULD be defined which hard drives are to be backed up and how the backup is to be carried out. Tapes managed by HSM SHOULD NOT be processed in any other way.

SYS.1.7.A25 Determination of System Sizing for z/OS (S)

The limits for maximum resource utilization (number of CPUs, memory, bandwidth, etc.) SHOULD be defined according to hardware requirements and known to the responsible administrators and application owners. The number of available magnetic tape stations, the times when applications access magnetic tape stations, and the required disk capacities SHOULD be coordinated with the application owners. Disk capacities SHOULD also be monitored by space management.

SYS.1.7.A26 WorkLoad Management for z/OS Systems (S)

The programs, files, and commands of the WorkLoad Manager (WLM) as well as the necessary Couple Data Sets SHOULD be protected via RACF. It SHOULD be ensured that the authorizations for modifying WLM via z/OS commands and via the SDSF interface are identical.

SYS.1.7.A27 Character Set Conversion for z/OS Systems (S)

When transferring text files between z/OS systems and other systems, it SHOULD be ensured that a character set conversion may be required. The correct conversion table SHOULD be used. When transferring program source code, it SHOULD be checked whether all characters were correctly converted. When transferring binary data, it SHOULD be ensured that no character set conversion takes place.

SYS.1.7.A28 License Key Management for z/OS Software (S)

For license keys with a limited validity period, a procedure for timely renewal SHOULD be established. The validity periods of license keys SHOULD be documented. The documentation SHOULD be available to all affected administrators.

SYS.1.7.A29 Hardening of Unix System Services for z/OS Systems (S)

The parameters of Unix System Services (USS) SHOULD be set according to the functional and security requirements and taking into account the available resources. HFS and zFS files containing USS file systems SHOULD be secured via RACF profiles and included in the data backup concept. Furthermore, the root file system SHOULD be mounted with the Read-Only option. There SHOULD be NO APF authorization (Authorized Program Facility) via the File Security Packet (FSP) in the USS file system. Instead, the modules SHOULD be loaded from APF files of the z/OS operating system. There SHOULD be a clear mapping between USS user IDs and z/OS user IDs. Permissions under USS SHOULD be granted via the RACF class UNIXPRIV and NOT by assigning UID 0. The same mechanisms used for z/OS SHOULD be used for reviewing and monitoring USS.

SYS.1.7.A30 Hardening of z/OS Trace Functions (S)

Trace functions of z/OS such as GTF (Generalized Trace Facility), NetView, or ACF/TAP (Advanced Communication Function/Trace Analysis Program), and the corresponding files, SHOULD be protected such that only the responsible and authorized employees have access to them. The trace function of NetView SHOULD be deactivated and only activated when needed.

SYS.1.7.A31 Emergency Preparedness for z/OS Systems (S)

A procedure for restoring a functional RACF database SHOULD be provided. Furthermore, a copy of the z/OS operating system as a z/OS backup system SHOULD be maintained, as well as a z/OS emergency system independent of the production system.

Requirements for High Protection Needs

The following are exemplary proposals for requirements for this building block that go beyond the protection level corresponding to the state of the art. The proposals SHOULD be considered in the case of high protection needs. The specific determination is made within the framework of an individual risk analysis.

SYS.1.7.A32 Definition of Standards for z/OS System Definitions (H)

Standards and naming conventions for z/OS system definitions SHOULD be defined and documented. The documentation SHOULD be available to administrators. Compliance with the standards SHOULD be regularly reviewed. Standards SHOULD be defined in particular for file, database, job, and volume names, as well as for application, system, and user IDs.

SYS.1.7.A33 Separation of Test and Production Systems Under z/OS (H)

Technical measures SHOULD be taken to separate development and test systems from production systems under z/OS. In doing so, potential access options via shared hard drives and the Parallel Sysplex SHOULD be taken into account.

SYS.1.7.A34 Batch Job Scheduling for z/OS Systems (H)

If a z/OS system processes a larger number of batch jobs, a job scheduler SHOULD be used for controlling batch job execution. The job scheduler as well as the associated files and tools SHOULD be appropriately protected via RACF.

SYS.1.7.A35 Use of RACF Exits (H)

If RACF exits are to be used, the security-related and operational impacts SHOULD be analyzed. The RACF exits SHOULD also be installed and monitored via SMP/E (System Modification Program/Enhanced) as USERMOD.

SYS.1.7.A36 Internal Communication of Operating Systems (H)

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

SYS.1.7.A37 Parallel Sysplex Under z/OS (H)

Based on the availability and scalability requirements, a decision SHOULD be made as to whether a Parallel Sysplex (cluster of z/OS systems) is to be used and, if so, what redundancies are to be provided. Resource sizing SHOULD take into account the requirements of the applications. Software and the definitions of LPARs in the sysplex, including RACF, SHOULD be synchronized or made available as shared files.

It SHOULD be ensured that all LPARs in 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 via RACF. A GRS network (Global Resource Serialization) SHOULD also be established. The hard drives of the sysplex SHOULD be strictly separated from the hard drives of other systems. The System Logger SHOULD be used with a Staging Data Set.

SYS.1.7.A38 Use of the VTAM Session Management Exit Under z/OS (H)

If a VTAM Session Management Exit is to be used, it SHOULD be ensured that this does not impair secure and performant operation. The exit SHOULD at a minimum enable subsequent control of rejected login attempts. Furthermore, the exit SHOULD be dynamically configurable and able to reload the rule set from an external file. Functions, commands, and files related to the exit SHOULD be protected via RACF.

Additional Information

Good to Know

A number of abbreviations common in the Z systems environment are not explained elsewhere in IT-Grundschutz. These include:

• HMC (Hardware Management Console), MCS (Multiple Console Support), SMCS, Extended MCS: consoles for controlling and monitoring a Z system or z/OS operating system
• HFS: Hierarchical File System
• IPL: Initial Program Load, the startup process of an operating system
• RSF: Remote Support Facility
• SE: Support Elements, for configuration and system control
• SMP/E: System Modification Program/Extended, procedure for software installation
• zFS: zSeries File System, a file system used under z/OS and Unix System Services (USS).

The manufacturer IBM provides further information on IBM Z in “ABC of z/OS System Programming Volume 1-13”, IBM Redbooks, https://www.redbooks.ibm.com.