S 3.107 S/390 and zSeries mainframes
Description
The IBM S/390 and zSeries systems belong to the server systems generally referred to as mainframes. Mainframes developed from classic stand-alone systems with batch processing to state-of-the-art client/server systems. Today, they form the top end of the range of offered server systems.
This module only considers type IBM zSeries and/or IBM S/390 mainframes. zSeries systems with the z/OS operating system constitute a logical further development of the OS/390 architecture. With the zSeries, the additional 64-bit support is added, for example. Both system types coexist, whereby the OS/390 may be deemed a "discontinued" operating system, since IBM discontinued its service in autumn 2004. For reasons of clarity, only the term "zSeries" is used for the hardware and "z/OS" for the operating system in this context.
History
The S/360 architecture introduced in 1964 constitutes the basis for all following further developments and can still be found today in essential parts on current zSeries systems. The changing names from "S/360", through "S/370" and "S/390", up to today's "zSeries" reflect the continuous development of the underlying architecture. Due to its backwards compatibility, the architecture also supports programs in the older 24- or 31-bit mode, along with newer 64-bit applications.
Despite increasing performance capability, the physical dimensions of mainframe systems have been reduced significantly. Today, mainframe systems have similar dimensions to other systems typically operated in computer centres.
Overview
For zSeries systems, there are mechanisms that can be used to achieve high availability and scalability. High availability is achieved by the redundant design of the components. In order to increase performance and availability, currently up to 16 processors can be operated in a zSeries system in parallel and up to 32 zSeries systems can be compiled to form a cluster. This is referred to as parallel Sysplex cluster.
Different operating systems are available for the zSeries hardware (e.g. z/OS, VSE, z/VM, or TPF). These are normally selected based on the parameters computer size and purpose. However, the z/OS operating system is used most frequently. In order to not go beyond the scope of this module, the recommendations in this module are mainly limited to the z/OS operating system.
Based on the enhancement of the z/OS operating system formerly also known as "MVS" by the subsystem Unix System Services, it is possible to also operate Unix-based applications in parallel to the classic mainframe applications. Additionally, a Linux operating system is also available for the zSeries hardware.
Fields of application for state-of-the-art z/OS systems include:
- classic batch processing for large "batch chains",
- batch processing, including transaction-oriented processing (e.g. IMS or CICS),
- database servers (e.g. DB2, IMS DB, or Oracle), or
- web servers and their applications.
The software components described in this module mainly refer to products of the manufacturer IBM. Moreover, there are many products from third party manufacturers frequently used in mainframe environments. These products may be addressed in exceptional cases only, since otherwise that would go beyond the scope of the module.
The z/OS operating system consists of the actual operating system (kernel), including the interfaces to the user processes. Different subsystems control and support communications. The most important subsystems include
- the Job Entry subsystem (JES) for background operations (batch processing or referred to as batch),
- the Time Sharing Option (TSO) for foreground operations (interactive), and
- the Unix System Services (Posix-compatible Unix subsystem).
Further subsystems include, for example
- the IMS transaction manager and the related database for transaction-oriented data processing,
- the CICS transaction manager for transaction-oriented data processing,
- the DB2 database for relational databases, and
- the Communications Server (SNA, TCP/IP) for network connections.
The security interface System Authorization Facility (SAF) enables protection of the system and the files against unauthorised accesses. The actual security functions are provided by the RACF security software. Top Secret and ACF2 must also be mentioned at this point as alternatives.
The following figure shows the connections of the operating system design in a simplified manner:
Figure: Basic design of the z/OS operating system
On overview of the zSeries and z/OS architectures and explanations regarding the terminology can be found in the following safeguards:
- S 3.39 Introduction to the ZSeries platform
- S 3.40 Introduction to the z/OS operating system
- S 3.41 Introduction to Linux and z/VM for zSeries systems
Threat scenario
In general, the threat scenario depends on the operational scenario. For example, a z/OS system with SNA connection to an isolated network in a government agency or company is normally less endangered than a z/OS system connected to the internet and offering web services. Furthermore, it is important whether data access must be read-only (e.g. for an information system) or whether the data can be edited. Specifically by using web servers or web applications connected to the internet, the threat scenario of the mainframe systems formerly deemed "very secure" significantly increased.
The public network connection of mainframe systems results in significantly higher threats as a result of improper or incorrect configuration of the system or based on missing processes or processes established incompletely when compared to the past.
This is applicable both to external connections and attacks in this context and to the internal area. Today, mainframe systems are exposed to similar threats when compared to Unix or Windows systems.
Organisational Shortcomings
| T 2.4 | Insufficient monitoring of security safeguards |
| T 2.27 | Lack of or insufficient documentation |
| T 2.54 | Loss of confidentiality through hidden pieces of data |
| T 2.99 | Inadequate or incorrect configuration of the zSeries system environment |
Human Error
| T 3.2 | Negligent destruction of equipment or data |
| T 3.3 | Non-compliance with IT security measures |
| T 3.9 | Improper IT system administration |
| T 3.38 | Errors in configuration and operation |
| T 3.66 | Incorrect character conversion on the use of z/OS |
| T 3.67 | Inadequate or incorrect configuration of the z/OS operating system |
| T 3.68 | Inadequate or incorrect configuration of the z/OS web server |
| T 3.69 | Incorrect configuration of Unix System Services in z/OS |
| T 3.70 | Insufficient z/OS system file protection |
| T 3.71 | Incorrect system time on z/OS systems |
| T 3.72 | Incorrect configuration of the z/OS security system, RACF |
| T 3.73 | Incorrect use of the z/OS system functions |
| T 3.74 | Inadequate protection of the z/OS system settings against dynamic changes |
| T 3.75 | Inadequate control of the batch jobs in z/OS |
Technical Failure
| T 4.10 | Complexity of access possibilities to networked IT systems |
| T 4.22 | Software vulnerabilities or errors |
| T 4.50 | z/OS operating system overload |
Deliberate Acts
| T 5.2 | Manipulation of information or software |
| T 5.10 | Abuse of remote maintenance ports |
| T 5.18 | Systematic trying-out of passwords |
| T 5.19 | Abuse of user rights |
| T 5.21 | Trojan horses |
| T 5.28 | Denial of services |
| T 5.57 | Network analysis tools |
| T 5.116 | Tampering with the z/OS system configuration |
| T 5.117 | Covering up tampering in z/OS |
| T 5.118 | Obtaining high level rights in the RACF by unauthorised means |
| T 5.119 | Use of other IDs in z/OS systems |
| T 5.120 | Tampering with the Linux/zSeries system configuration |
| T 5.121 | Attacks on z/OS systems using TCP/IP |
| T 5.122 | Misuse of RACF attributes in z/OS |
Method recommendation
To secure the information system examined, other modules must be implemented in addition to this module, with these modules being selected based on the results of the IT-Grundschutz modelling process.
A series of safeguards must be implemented to successfully design and implement a z/OS mainframe system, starting with the strategic decision and continuing through the design phase, the installation phase, and up to the operation phase. In addition, it must be noted that a system needs to be disposed of properly once it has reached the end of its operation phase.
Parallel to the operation phase, the contingency planning phase must ensure that operation of the system is also maintained in an emergency. The IT Security Management and Audit departments must make sure that these rules are also followed.
The steps to take to accomplish this as well as the safeguards to implement in each phase are listed in the following.
Strategy
Before starting any planning operations, the strategic orientation phase takes place based largely on the requirements of the application owners. Here, it must be checked whether the z/OS platform is suitable regarding the solution of the respective task.
Furthermore, the general orientation of the computer centre's IT landscape is important. If there is no z/OS platform operating yet, the build-up of the required know-how with the operating personnel must be prepared accordingly. The following safeguards provide support during strategic planning:
- S 3.39 Introduction to the ZSeries platform,
- S 3.40 Introduction to the z/OS operating system, and
- S 3.41 Introduction to Linux and z/VM for zSeries systems.
They provide an overview of the individual hardware and software functions and thereby support the understanding of the z/OS platform.
Conception
If the strategic decision was made in favour of using a z/OS mainframe system, the aforementioned phase must be followed by a detailed planning phase regarding the use of this system. In this, the following safeguards must be taken into consideration:
- Before procuring and commissioning zSeries systems, different planning operations must be performed (see S 2.286 Planning and use of zSeries systems).
- In the event of higher requirements regarding availability or scalability, using a parallel Sysplex cluster is recommendable (see S 4.221 Parallel Sysplex under z/OS).
- Security policies must be planned and specified for the z/OS system and specifically for the RACF (Resource Access Control Facility) security system (see S 2.288 Drawing up a security policy for z/OS systems).
- Standards for the z/OS system definitions must be defined (see S 2.285 Determining standards for z/OS system definitions).
- A role concept for system administration of z/OS systems should be implemented (see S 2.295 System administration of z/OS systems).
Implementation
Once the preparatory organisational and planning tasks have been completed, the zSeries hardware and the z/OS operating system can be installed. The following safeguards must be taken into account during installation and commissioning:
- A secure basic configuration of the authorisation mechanisms of the z/OS operating system is necessary (see S 4.209 Secure basic configuration of z/OS systems).
- The corresponding configuration of the security system plays an essential role for protecting the z/OS environment (see S 4.211 Use of the z/OS security system RACF).
- Regarding the implementation of the z/OS control, including the remote control console RSF (Remote Support Facility), the recommendations in safeguard S 4.207 Use and protection of system-related z/OS terminals must be taken into account.
Operation
After the initial installation and a test operation phase, regular operations can be initiated. The following security aspects must be taken into account in this phase:
- The provision of the z/OS operating system's functionalities requires secure operation of the z/OS operating system (see S 4.210 Secure operation of the z/OS operating system).
- The utility programs used to support the operating functions of the z/OS operating system and requiring a high level of authorisation must be secured (see S 4.215 Protection of z/OS utilities that are critical to security).
- The required maintenance work regarding a z/OS system are described in safeguard S 2.293 Maintenance of z/OS systems.
- z/OS systems or parallel Sysplex clusters must be monitored during live operations (see S 2.292 Monitoring of z/OS systems).
Disposal
Recommendations for uninstalling z/OS systems, for example when regular operation is terminated, can be found in safeguard S 2.297 Deinstallation of z/OS systems.
Contingency Planning
Recommendations for contingency planning can be found in safeguard S 6.93 Contingency planning for z/OS systems.
Security Management and Auditing
The Security Management Department should support the entire lifecycle of a z/OS system. In doing so, the following items should be taken into account specifically:
- When assigning and auditing authorisations, it must be checked whether the corresponding employees need these for their work. This is particularly applicable to high authorisations (see safeguard S 2.289 Use of restrictive z/OS IDs).
- During z/OS system operation, it must be checked regularly whether the security policies are complied with (see safeguard S 2.291 Security reporting and security audits under z/OS).
In the following, the bundle of security measures for the "S/390 and zSeries mainframe" module are presented.
Planning and design
| S 2.285 | (Z) | Determining standards for z/OS system definitions |
| S 2.286 | (Z) | Planning and use of zSeries systems |
| S 2.287 | (Z) | Batch job planning for z/OS systems |
| S 2.288 | (B) | Drawing up a security policy for z/OS systems |
| S 2.295 | (A) | System administration of z/OS systems |
| S 2.296 | (Z) | Basic factors to consider with z/OS-transaction monitors |
| S 3.39 | (W) | Introduction to the zSeries platform |
| S 3.40 | (W) | Introduction to the z/OS operating system |
| S 3.41 | (W) | Introduction to Linux and z/VM for zSeries systems |
| S 4.221 | (C) | Parallel Sysplex under z/OS |
Implementation
| S 2.289 | (A) | Use of restrictive z/OS IDs |
| S 2.290 | (Z) | Use of RACF exits |
| S 3.42 | (A) | Training z/OS operators |
| S 4.207 | (A) | Use and protection of system-related z/OS terminals |
| S 4.208 | (B) | Protecting the start process of z/OS systems |
| S 4.209 | (A) | Secure basic configuration of z/OS systems |
| S 4.211 | (A) | Use of the z/OS security system RACF |
| S 4.212 | (Z) | Protection of Linux for zSeries |
| S 4.213 | (A) | Protecting the login process under z/OS |
| S 4.216 | (C) | Stipulation of the system limits of z/OS |
| S 4.217 | (C) | Workload management for z/OS systems |
| S 4.219 | (C) | Licence key management for z/OS software |
| S 4.220 | (B) | Protection of Unix System Services on z/OS systems |
| S 5.113 | (Z) | Use of the VTAM Session Management Exit under z/OS |
| S 5.114 | (B) | Protection of the z/OS trace functions |
Operation
| S 2.291 | (C) | Security reporting and security audits under z/OS |
| S 2.292 | (B) | Monitoring of z/OS systems |
| S 2.293 | (C) | Maintenance of zSeries systems |
| S 2.294 | (Z) | Synchronisation of z/OS passwords and RACF commands |
| S 4.210 | (B) | Secure operation of the z/OS operating system |
| S 4.214 | (B) | Administration of data media under z/OS systems |
| S 4.215 | (B) | Protection of z/OS utilities that are critical to security |
| S 4.218 | (Z) | Information on character set conversion in z/OS systems |
Disposal
| S 2.297 | (B) | Deinstallation of z/OS systems |
Contingency Planning
| S 6.93 | (A) | Contingency planning for z/OS systems |