S 2.286 Planning and use of zSeries systems

Initiation responsibility: IT Security Officer, Head of IT

Implementation responsibility: Administrator, Head of IT

Planning

Before purchasing and installing zSeries systems, a variety of planning tasks must be performed. The following security-related recommendations regarding the process of planning the use of zSeries systems must be taken into account:

Infrastructure

The location of the zSeries hardware must be planned in an access protected computer centre. Recommendations for the infrastructure security of computer centres can be found in module S 2.9 Computer centre.

Hardware

The hardware resources required for operation must be planned and their capacity dimensioned according to the requirements. This applies to the entire hardware equipment, from the number of processors, via channels, hard disks, and tape stations, up to network components (including network connections).

Operating systems

It must be clarified which of the possible operating systems (z/OS, zLinux without carrier system, zLinux under the carrier system z/VM, etc.) must be used for the requirements of the application.

Requirements of the applications

The requirements of the applications regarding hardware and operating system must be taken into consideration during the planning phase:

Processes

It must be checked how the new system can be integrated into the existing processes. For example, this refers to change management, escalation and reporting procedures, security audits, and further management disciplines.

Compliance with the security regulations and policies of the government agency or company must be taken into consideration during the planning phase.

Personnel

It must be determined how many employees with what qualifications are needed for operation of the zSeries system. If not enough trained employees with mainframe know-how are available, the training measures must be initiated in due time.

Operational scenarios

In the following, some typical operational scenarios of zSeries systems are introduced generically and recommendations for separating systems with different security requirements are described.

Batch systems

Batch systems focus on batch processing. Batch processing means that specified programs (batch jobs) process - normally large - databases based on procedures defined by JCL (job control language) without any interaction with the users. Batch systems may be operated both as single systems and within the framework of parallel Sysplex clusters. For batch system, it must be considered whether a scheduling function is to be used for controlling batch processing (see S 2.287 Batch job planning for z/OS systems). The access rights should be administered by RACF (Resource AccessControl Facility). Based on the requirements for scalability, it must furthermore the checked whether a parallel Sysplex cluster should be used.

Online systems

Online systems process transactions triggered by interactive work of the users on the screen. In this connection, so-called transaction monitors such as CICS (Customer Information Control System) or IMS (Information Management System) are frequently used. As with batch systems, RACF should be used for administering and enforcing the access rights. In the event of high requirements regarding the online system's availability, it should be checked whether these requirements can be taken into account by using a parallel Sysplex cluster. More detailed information can be found in safeguard S 2.296 Basic factors to consider with z/OS-transaction monitors.

Web servers

zSeries systems are also used as web servers for internet or intranet offers. Here, z/OS or also zLinux (separately or as guest under z/VM) are the operating systems used. Security recommendations for operating Linux on zSeries systems can be found in safeguard S 4.212 Protection of Linux for zSeries.

Database servers

z/OS systems may also be used as database servers. For this, the system frequently uses the DB2 database software in order to provide services allowing querying of database information or changing of its contents. Database servers are often used in connection with transaction monitors (e.g. CICS) or web servers and provide these with the required database access. The focus on the pure database service reduces the complexity and improves the performance of the system, specifically for very large databases. As with the scenarios described above, RACF should also be used for administering and enforcing the access rights of database servers. More detailed recommendations regarding the use of DB2 can be found in safeguard S 2.296 Basic factors to consider with z/OS-transaction monitors.

Universal systems

Universal systems include mainframes providing several of the services described above. They process both batch jobs and online transactions and contain one (or several) database server(s). If required, they are additionally also used as web servers on the internet or intranet. RACF should be used as security system in all areas.

System separation

Since production systems under z/OS are normally subject to higher security requirements than test and development systems, the two system environments must be separated. In order to implement this separation, the following recommendations must be taken into consideration:

Shared hard disk accesses

The hard disks must be assigned to the test and production systems in such a way that unauthorised accesses to production data can be prevented. In doing so, the addresses are defined in HCD (Host ConfigurationDefinition). Technical and organisational safeguards must be taken to ensure that the hard disks from test systems cannot be set online on production systems (and vice versa) and that the same hard disks cannot be simultaneously accessed from test and production systems (Shared DASD).

Use of FTP

Data between production and test systems should be exchanged using FTP (File Transfer Program).

Shared Sysplex

Production and test systems should not be operated in the same parallel Sysplex system. If such a constellation is necessary, a logical separation using the corresponding standards and RACF definitions (Resource Access ControlFacility) must ensure that any misuse of file accesses is ruled out.

Shared RACF databases

It should be considered to not to use any Shared-RACF databases for production and test systems.

Review questions:

© Federal Office for Information Security. All rights reserved.