S 4.207 Use and protection of system-related z/OS terminals

Initiation responsibility: IT Security Officer, Head of IT

Implementation responsibility: Head of IT, Administrator

A z/OS operating system is controlled by the HMC console (Hardware Management Console), by different MCS consoles (Multiple ConsoleSupport), possibly by Extended MCS consoles, and furthermore by monitor consoles, if required. More detailed information about the consoles can be found in safeguard S 3.39 Introduction to the zSeries platform.

HMC consoles

HMC consoles are connected to the Support Elements (SEs) of the zSeries system via a LAN. They allow for security-critical interventions in the hardware, the microcode, and the configuration of the entire z/OS system. The following information must be taken into account:

Preset IBM IDs

The delivered passwords of the preset IBM IDs must be replaced by new passwords (this is also applicable to all IDs of non-IBM products). In this connection, S 2.11 Provisions governing the use of passwords must be taken into consideration.

Protecting the HMC console

The HMC console should be operated in a room protected against unauthorised access.

Access to the HMC console must be protected logically. For logical protection, the login function should be secured by personal IDs with passwords.

The IBM Product Engineering access must be disabled during normal production.

Connection to the Support Elements

The HMC console should be connected to the Support Elements using a dedicated LAN. If another LAN is also used, a fix assignment between Support Element and HMC console should be defined, e.g. by performing the corresponding settings in the Domain Security function.

Remote connection

If the HMC consoles are to be operated using a remote connection, corresponding safeguards must be designed for the remote access. In this case, module S 4.4 VPN is applicable.

Authorisation modes

The personnel should be assigned to different authorisation modes. These modes should be used as follows:

Web servers

The HMC console has its own web server offering a limited scope of functions of the HMC console for access using a web browser. On a network level, all unauthorised accesses to the web server of the HMC console should be blocked. The web server of the HMC console should be disabled if the web interface to the HMC console is not used.

Default settings

The default settings of the HMC console provided by the manufacturer should be changed so that users are only assigned the roles they actually require for their work (Customize User Control Process in the HMC console).

Maintenance work

An approach for the use of the HMC console and/or the Support Elements by the technician for maintenance purposes must be established. It must be ensured that, upon completion of the maintenance work, the HMC console is activated with an operator ID and is no longer operated with the high-authorisation technician ID.

Training

The personnel deployed for operation of the HMC consoles must be trained regarding the use of the console, particularly in terms of the more complex functions. This should avoid severe incorrect operations.

It should be considered whether exercises on the HMC console increase the security, since the console is only rarely used during operations.

Support Elements (SEs)

The Support Elements (two IBM laptops) are located in the casing of the zSeries hardware and are fixedly connected to the resources of the hardware. From these Support Elements, the same commands can be executed as from the HMC console.

Access (system access)

Access to the Support Elements must be protected physically. Normally, this is guaranteed by the fact that the zSeries systems are operated in a computer centre protected against unauthorised access. The hardware lock of the zSeries hardware does not offer sufficient protection.

Maintenance

The Support Elements are also used by the manufacturer's hardware technicians for maintenance purposes. Upon completion of the maintenance work, the doors of the zSeries hardware should be locked and further security mechanisms should be reactivated, if required.

MCS consoles (Multiple Console Support)

The MCS consoles (for historical reasons also still referred to as MVS consoles) offer direct access to the operating system (MCS with proprietary input/output protocol, SMCS via VTAM in z/OS V1R1 and higher). The following security mechanisms must be provided for MCS and SMCS consoles:

Login

It must be checked whether the protection by AUTH definition in the CONSOL00 member is sufficient or whether MCS consoles are defined in such a way that login with ID and password is required before the console can be used. For SMCS consoles that are also used remotely, a login procedure is absolutely necessary.

Physical protection

If no login with ID and password has been configured for the MCS console, it must be operated in a room protected against unauthorised access. This does not include consoles defined in such a way that only uncritical Display functions are possible.

Since the MCS master console cannot be protected by ID and password, this console must be operated in a room protected against unauthorised access.

The z/OS operating system makes the first available console the master console, unless there are other definitions. The assignment of the master console must be performed in the CONSOL00 member in such a way that a physically protected console becomes the master console. A second MCS console that becomes the Master if the primary MCS master console is switched automatically in case of an error must be protected similarly to the primary MCS master console.

Logical protection

Corresponding definitions must be established in order to ensure that MCS consoles not operated in rooms protected against unauthorised access may only be used by authorised users. This may be performed using the configuration parameters AUTH=xxx or LOGON=REQUIRED in the CONSOL00 member.

If the MCS consoles are protected differently to a sufficient extent and if an operator audit is not required, LOGON=REQUIRED may be substituted by the definition LOGON=OPTIONAL in the CONSOL00 member.

Individual authorisations

For MCS consoles with Login process, assigning individual authorisations to each ID should be considered. This allows for a division into different operator groups (see S 4.211 Use of the z/OS security system RACF), which is not possible when selecting the approach without authentication. Otherwise, the functions of the console are available to everyone with physical access to the MCS console.

Extended MCS consoles

For example, the Extended MCS console can be used to provide MCS consoles in TSO (Time Sharing Option) via System Display and Search Facility (for JES2) or Flasher (for JES3). The following information should be taken into account for these consoles:

RACF definitions

In order to protect the MVS commands, corresponding RACF definitions (class OPERCMDS) must be used. Whether the Extended MCS console may be used, which ID the Extended MCS console is allowed to use, and which commands are available must be defined separately in RACF (see S 4.211 Use of the z/OS security system RACF). In any case, it must be ensured that the console services and the z/OS commands used may only be used by users disposing of the corresponding authorisation in RACF. This is applicable to all applications working with Extended MCS consoles.

RSF console (Remote Support Facility)

By means of RSF (Remote Support Facility), the zSeries system can automatically establish a connection to the manufacturer and report errors of the running system to the technicians working with the manufacturer (hardware and software). Moreover, the manufacturer is generally able to load microcode modifications to the system using the RSF function. RSF is an additional function of the HMC console (Host Management Console) and is connected to the telephone network using a dial-up connection.

The following information must be taken into account for the RSF function:

Basic RSF consideration

It must be considered whether a function such as RSF is actually desired and which of its sub-functions are required. The use of the functions must be coordinated with the hardware support responsible for the systems based on the service agreement. RSF (and similar functions of hard disks of other manufacturers) is normally used for troubleshooting hardware and firmware and significantly increases the ability to react to occurring errors. Whether remote maintenance by RSF is to be enabled must be decided by the operator of the computer centre.

Dial-up connection to the manufacturer

Error messages are initiated on part of the HMC and a dial-up connection to the manufacturer is established in so doing. Within the framework of adapting the HMC definitions, it must be ensured that the entered phone number is correct and must only be changed by authorised personnel.

Microcode adaptation

If the manufacturer requests a microcode adaptation (or any other modification to the firmware), the IBM Product Engineering access must be enabled for a stipulated period of time. The connection is established via Dial-In. Upon completion of the maintenance work, the access must be disabled in order to minimise the risk of misuse.

Documentation

The RSF installation and its use must be documented comprehensibly.

Review questions:

© Federal Office for Information Security. All rights reserved.