chrisbst48/IT-Grundschutz-Compendium_2022_EN huggingface dataset:
SYS.1.6.A6 Use of Secure Images (B)
It MUST be ensured that all images used originate from trusted sources. The creator of each image MUST be clearly identifiable. 
Sources MUST be selected on the basis of whether the creator of a given image regularly checks the included software for security problems, fixes and documents them, and provides corresponding guarantees to customers. 
The utilised version of base images MUST NOT be deprecated. Unique version numbers MUST be provided. If an image with a newer version number is available, a patch and change management process MUST check whether and how it can be rolled out.
SYS.1.6.A7 Persistence of Container Logging Data (B)
Container logging data MUST be stored outside of the respective container (on the container host at minimum).
SYS.1.6.A8 Secure Storage of Container Access Data (B)
Access data MUST be stored and managed in such a way that only authorised persons and containers can access it. In particular, it MUST be ensured that access data is only stored in specially protected locations and not in images. The access data management mechanisms provided by container service management software SHOULD be used. 
At minimum, the following credentials MUST be stored securely: 
•	Passwords of any accounts 
•	API keys for services used by the application 
•	Keys for symmetric encryption 
•	Private keys for public key authentication
SYS.1.6.A9 Suitability for Container Operation (S)
An application or service to be operated in a container SHOULD be suitable for such operation. It SHOULD be considered that containers can often be terminated unexpectedly, with corresponding consequences for the application run therein. The results of the checking described under SYS.1.6.A3 Secure Use of Containerised IT Systems SHOULD be documented in a comprehensible manner.
SYS.1.7 IBM Z System
Target Object: IT system / Order: R2
SYS.1.7.A1 Use of Restrictive z/OS IDs (B)
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.
SYS.1.7.A11 Protection of Session Data (B)
Session data for the connections of RACF administrators and other employees MUST be transferred in encrypted form.
SYS.1.7.A14 Reporting on the Secure Operation of z/OS (S)
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.
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 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.
SYS.1.7.A17 Synchronisation of z/OS Passwords and RACF Commands (S)
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.
SYS.1.7.A18 Role Concept for z/OS Systems (S)
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).
SYS.1.7.A19 Protection of z/OS Transaction Monitors (S)
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 MVS 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.
SYS.1.7.A2 Protection of Security-Critical z/OS Utilities (B)
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).
SYS.1.7.A20 Decommissioning z/OS Systems (S)
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.
SYS.1.7.A21 Protection of the Startup Process of z/OS Systems (S)
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. An MVS 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.
SYS.1.7.A22 Protection of the Operating Functions of z/OS (S)
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. 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.
SYS.1.7.A23 Protection of z/VM (S)
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. 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.
SYS.1.7.A24 Administration of Storage Media in z/OS Systems (S)
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 how backups are to be carried out SHOULD be specified when using the HSM (Hierarchical Storage Manager). Tapes that are managed by the HSM SHOULD NOT be edited elsewhere.
SYS.1.7.A25 Stipulation of z/OS System Capacity (S)
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 magnetic tape 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.
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 by RACF. It SHOULD be ensured that the authorisations required to change the WLM via MVS commands and via the SDSF interface are the same.
SYS.1.7.A27 Character Set Conversion in z/OS Systems (S)
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.
SYS.1.7.A28 Licence Key Management for z/OS Software (S)
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.
SYS.1.7.A29 Protection of Unix System Services on z/OS Systems (S)
The parameters of Unix System Services (USS) SHOULD be set according to the functional and security specifications at hand while also 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 MVS 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.
SYS.1.7.A3 Maintenance of Z Systems (B)
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 control of the operator, and either locally via SE (Support Elements) or HMC (Hardware Management Console) or remotely via the RSF (Remote Support Facility).
SYS.1.7.A30 Protection of the z/OS Trace Functions (S)
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.
SYS.1.7.A31 Contingency Planning for z/OS Systems (S)
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 in a manner independent from the production system.
SYS.1.7.A32 Determining 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 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.
SYS.1.7.A33 Separation of Test and Production Systems in z/OS (H)
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.
SYS.1.7.A34 Batch Job Planning for z/OS Systems (H)
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.
SYS.1.7.A35 Use of RACF Exits (H)
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.
SYS.1.7.A36 Internal Communication Between Operating Systems (H)
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).
SYS.1.7.A37 Parallel Sysplex in z/OS (H)
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.
SYS.1.7.A38 Use of the VTAM Session Management Exit in z/OS (H)
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
SYS.1.7.A4 Training z/OS Operators [Supervisor] (B)
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.
SYS.1.7.A5 Use and Protection of System-Related z/OS Terminals (B)
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. Web servers and other forms of remote access MUST be disabled when not in use.
SYS.1.7.A6 Use and Protection of the Remote Support Facility (B)
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 secure connections (such as TLS).
SYS.1.7.A7 Restrictive Authorisation in z/OS (B)
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.
SYS.1.7.A8 Use of the z/OS Security System RACF (B)
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. 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.
SYS.1.7.A9 Multi-Client Capability in z/OS (B)
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 through 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 co-ordinated with all the clients working on the system concerned.
SYS.1.8 Storage Solutions
Target Object: IT system / Order: R2
SYS.1.8.A1 Appropriate Installation of Storage Systems [Building Services] (B)
The IT components of storage solutions MUST be installed in closed rooms. Access to these rooms MUST be restricted to authorised persons. In addition, a secure power supply MUST be ensured. Manufacturer recommendations on ambient temperature and humidity MUST be observed.
SYS.1.8.A10 Drawing Up and Maintaining an Operating Manual (S)
An operating manual SHOULD be drawn up. It SHOULD document all the rules, requirements, and settings for operating storage solutions. The operating manual SHOULD be updated at regular intervals.
SYS.1.8.A11 Secure Operation of a Storage Solution (S)
Storage systems SHOULD be monitored in terms of the availability of internal applications, system load, and critical events. Furthermore, fixed maintenance windows in which changes may be implemented SHOULD be defined for storage solutions. In particular, firmware or operating system updates to storage systems or the network components of a storage solution SHOULD only be performed within a maintenance window.
SYS.1.8.A13 Monitoring and Administration of Storage Solutions (S)
Storage solutions SHOULD be monitored. All collected data (messages) SHOULD be checked, in particular to see if the specifications of the respective operating manual are being followed. Essential messages SHOULD be highlighted using message filters. Individual components of storage solutions and the respective overall systems SHOULD be managed in a centralised manner.
SYS.1.8.A14 Protection of an SAN Through Segmentation (S)
An SAN SHOULD be segmented. A concept SHOULD be drawn up that assigns SAN resources to the respective servers. To this end, a decision SHOULD be taken as to which segmentation should be used in each implementation (e.g. FC SANs or iSCSI storage networks) based on the security requirements at hand and the administration effort required. The current resource allocation SHOULD be easily and clearly identifiable with the help of the administration tools. Furthermore, the current zoning configuration SHOULD be documented. The documentation SHOULD also be available in case of emergency.
SYS.1.8.A15 Secure Separation of Clients in Storage Solutions (S)
An organisation's requirements regarding the multi-client capability of a storage solution SHOULD be defined and documented in a transparent manner. The storage solutions used SHOULD meet these documented requirements. In block storage environments, LUN masking SHOULD be used in order to separate clients. In file service environments, it SHOULD be possible to use virtual file servers. Here, every client SHOULD be assigned its own file service. When using IP or iSCSI, clients SHOULD be separated via segmentation within the network. If fibre channel is being used, VSANs and soft zoning SHOULD be used for segmentation purposes.
SYS.1.8.A16 Secure Deletion in SAN Environments (S)
In multi-client-capable storage systems, it SHOULD be ensured that the logical unit numbers (LUNs) assigned to a certain client are deleted.
SYS.1.8.A17 Documenting Storage System Settings (S)
All storage system settings SHOULD be documented. The documentation SHOULD include the technical and organisational specifications in question, as well as any specific configurations of an organisation's storage systems. If the documentation of system settings includes confidential information, this information SHOULD be protected against unauthorised access. The documentation SHOULD be regularly reviewed. It SHOULD always be up to date.
SYS.1.8.A18 Security Audits and Reporting Storage Systems (S)
All storage systems used SHOULD be audited at regular intervals. A corresponding process SHOULD be established. It SHOULD be specified what security reports are to be drawn up at regular intervals and what they are to contain. Furthermore, it SHOULD also be specified how deviations from specifications must be handled and how often and to what extent audits are to be performed.
SYS.1.8.A19 Decommissioning Storage Solutions (S)
If entire storage solutions or individual components thereof are no longer required, any data they contain SHOULD be transferred to other storage solutions. A transitional phase SHOULD be scheduled for this. Afterwards, all payload and configuration data SHOULD be securely deleted. All references to the decommissioned storage solution SHOULD be removed from all relevant documents.
SYS.1.8.A2 Secure Basic Configuration of Storage Solutions (B)
Prior to production use of a storage solution, it MUST be ensured that all the software components and firmware in use are up to date. Afterwards, a secure basic configuration MUST be established. Unused interfaces of the storage system MUST be disabled. The files for the default configuration, the basic configuration performed, and the current configuration SHOULD be stored in a secure and redundant manner.