chrisbst48/IT-Grundschutz-Compendium_2022_EN huggingface dataset:
SYS.1.2.2.A6 Secure Authentication and Authorisation in Windows Server 2012 (S)
In Windows Server 2012 R2, all users SHOULD be members of the security group “Protected Users”. Accounts for services and computers SHOULD NOT be members of the “Protected Users” group. Service accounts in Windows Server 2012 SHOULD be members of the “Managed Service Account” group. The PPL protection of the local security authority (LSA) SHOULD be activated. The use of dynamic access rules for resources SHOULD be preferred.
SYS.1.2.2.A8 Protection of System Integrity (S)
AppLocker SHOULD be enabled and configured as stringently as possible.
SYS.1.3 Linux and Unix Servers
Target Object: IT system / Order: R2
SYS.1.3.A10 Preventing Further Intrusion When Vulnerabilities Are Exploited (S)
Services and applications SHOULD be protected with individual security architecture (e.g. with AppArmor or SELinux). In addition, chroot environments and LXC or Docker containers SHOULD be taken into account here. It SHOULD be ensured that the standard profiles and rules provided are activated.
SYS.1.3.A14 Preventing Unauthorised Collection of System and User Information (H)
Information output for users regarding the operating system and access to protocol and configuration files SHOULD be limited to the required minimum. Moreover, confidential information SHOULD NOT be provided as parameters when commands are issued.
SYS.1.3.A16 Additional Prevention of Further Intrusion When Vulnerabilities Are Exploited (H)
The use of system calls SHOULD be limited to those absolutely necessary, particularly for exposed services and applications. The standard profiles and/or rules (e.g. of SELinux or AppArmor) SHOULD be checked manually and, if necessary, adapted to an organisation's own security policies. If necessary, new rules and profiles SHOULD be drawn up.
SYS.1.3.A17 Additional Kernel Protection (H)
Specially hardened kernels (e.g. grsecurity, PaX) and appropriate protective safeguards such as memory protection or file system protection SHOULD be implemented to prevent exploitation of vulnerabilities and propagation in operating systems.
SYS.1.3.A2 Careful Allocation of IDs (B)
Each login name, each user ID (UID), and each group ID (GID) MUST ONLY be used once. Every user MUST be a member of at least one group. Every GID mentioned in the /etc/passwd file MUST be defined in the /etc/group file. Every group SHOULD only contain the users that are absolutely necessary. In networked systems, care MUST also be taken to ensure that user and group names (UIDs and GIDs) are assigned consistently in the system network if there is a possibility that the same UIDs or GIDs could be assigned to different user or group names on the systems during cross-system access.
SYS.1.3.A3 No Automatic Integration of Removable Drives (B)
Removable media such as USB pen drives or CDs/DVDs MUST NOT be integrated automatically.
SYS.1.3.A4 Protection from Exploitation of Vulnerabilities in Applications (B)
ASLR and DEP/NX MUST be activated in the kernel and used by applications to make it harder to exploit vulnerabilities in applications. Security functions of the kernel and of the standard libraries (such as heap and stack protection) MUST NOT be disabled.
SYS.1.3.A5 Secure Installation of Software Packages (B)
If software to be installed is to be compiled from source code, it MUST ONLY be unpacked, configured, and compiled using an unprivileged user account. The software to be installed MUST NOT then be installed in the root file system of the server in question in an uncontrolled manner. If the software is compiled from the source text, the selected parameters SHOULD be documented appropriately. Based on this documentation, it SHOULD be possible to compile the software in a transparent and reproducible manner at any time. All further installation steps SHOULD also be documented.
SYS.1.3.A6 Managing Users and Groups (S)
The corresponding management tools SHOULD be used for managing users and groups. The configuration files /etc/passwd, /etc/shadow, /etc/group, and /etc/sudoers SHOULD NOT be edited directly.
SYS.1.3.A8 Encrypted Access via Secure Shell (S)
Only Secure Shell (SSH) SHOULD be used to create an encrypted and authenticated interactive connection between two IT systems. All other protocols whose functions are covered by Secure Shell SHOULD be disabled completely. For authentication, users SHOULD primarily use certificates instead of passwords.
SYS.1.5 Virtualisation
Target Object: IT system / Order: R2
SYS.1.5.A10 Introduction of Management Processes for Virtual IT Systems (S)
For virtualisation servers and virtual IT systems, processes for commissioning, inventory, operation, and decommissioning SHOULD be defined and established. The processes SHOULD be documented and updated at regular intervals. If the use of such virtual IT systems is planned, the virtualisation functions that may be used by the virtual IT systems SHOULD be defined. Test and development environments SHOULD not be operated on the same virtualisation server as virtual IT systems in production use.
SYS.1.5.A11 Administration of the Virtualisation Infrastructure Using a Separate Management Network (S)
A virtualisation infrastructure SHOULD only be administered using a separate management network (see NET.1.1 Network Architecture and Design). The available security mechanisms of the management protocols used for authentication, integrity assurance, and encryption SHOULD be activated. All insecure management protocols SHOULD be disabled (see NET.1.2 Network Management).
SYS.1.5.A12 Rights and Role Concept for Virtual Infrastructure Administration (S)
Based on the tasks and roles defined in the planning phase (see SYS.1.5.A8 Planning a Virtual Infrastructure), a rights and role concept SHOULD be drawn up and implemented for administrating virtual IT systems and networks on virtualisation servers and in the management environment. All components of the virtual infrastructure SHOULD be integrated into a central identity and access management system. Administrators of virtual machines SHOULD be differentiated from administrators of the virtualisation environment at hand. They SHOULD be assigned different access rights. Furthermore, the management environment SHOULD be able to group virtual machines for appropriate structuring. The roles of the administrators SHOULD be assigned accordingly.
SYS.1.5.A13 Selection of Suitable Hardware for Virtualisation Environments (S)
The hardware used SHOULD be compatible with the virtualisation solution used. Here, it SHOULD be ensured that the manufacturer of the virtualisation solution will also offer support for the hardware operated for the scheduled period of deployment.
SYS.1.5.A14 Uniform Configuration Standards for Virtual IT Systems (S)
Uniform configuration standards SHOULD be defined for the virtual IT systems used. The virtual IT systems SHOULD be configured in accordance with these standards. The configuration standards SHOULD be regularly reviewed and amended if required.
SYS.1.5.A15 Operation of Guest Operating Systems with Different Protection Needs (S)
If virtual IT systems with different protection needs are operated jointly on the same virtualisation server, it SHOULD be ensured that the virtual IT systems are encapsulated and isolated sufficiently. The network separation of the virtualisation solution used SHOULD be sufficiently secure, as well. If this is not the case, further security safeguards SHOULD be identified and implemented.
SYS.1.5.A16 Encapsulation of Virtual Machines (S)
The functions for copying and pasting information between virtual machines SHOULD be disabled.
SYS.1.5.A17 Monitoring the Operating Condition and Configuration of the Virtual Infrastructure (S)
The operating condition of the virtual infrastructure in question SHOULD be monitored. Among other things, it SHOULD be checked whether sufficient resources are still available. Whether there are any conflicts with shared resources of a virtualisation server SHOULD also be checked. Furthermore, it SHOULD be ensured that the configuration files of the virtual IT systems are regularly checked for unauthorised modifications. Whether the virtual networks have been assigned properly to the respective virtual IT systems SHOULD also be monitored. If changes are to be made to the configuration of the virtualisation infrastructure, they SHOULD be checked and tested prior to being implemented.
SYS.1.5.A19 Regular Audits of Virtualisation Infrastructure (S)
Regular audits SHOULD be carried out to check whether the actual state of the virtual infrastructure in question corresponds to the state defined in the respective planning. There SHOULD also be regular audits to check whether the configuration of the virtual components complies with the specified standard configuration. The audit results SHOULD be documented in a transparent manner. Deviations SHOULD be eliminated.
SYS.1.5.A2 Secure Use of Virtual IT Systems (B)
Every administrator of virtual IT systems MUST know how virtualisation affects the IT systems and applications in operation. The access rights of administrators regarding virtual IT systems MUST be reduced to those actually required. It MUST be ensured that the network connections necessary for virtual IT systems are available in the respective virtual infrastructure. It MUST also be checked whether the isolation and encapsulation requirements of virtual IT systems and the applications operated on them are being met. Furthermore, the virtual IT systems used MUST meet the requirements at hand regarding availability and data throughput. During live operations, the performance of virtual IT systems MUST be monitored.
SYS.1.5.A20 Using Highly Available Architectures [Planner] (H)
Virtual infrastructures SHOULD be designed for high availability. All virtualisation servers SHOULD be consolidated in clusters.
SYS.1.5.A21 Secure Configuration of Virtual IT Systems for Increased Protection Needs (H)
For virtual IT systems, overbooking features for resources SHOULD be disabled.
SYS.1.5.A22 Hardening of the Virtualisation Server (H)
The virtualisation server in question SHOULD be hardened. In order to further isolate and encapsulate virtual IT systems from each other and from the virtualisation server, mandatory access controls (MACs) SHOULD be used. The IT system on which the management software is installed SHOULD also be hardened.
SYS.1.5.A23 Restriction of Rights of Virtual Machines (H)
All interfaces and communication channels that make it possible for a virtual IT system to request and obtain information about the host system SHOULD be disabled or suppressed. Furthermore, only the virtualisation server SHOULD be able to access its resources. Virtual IT systems SHOULD NOT share pages of the main memory.
SYS.1.5.A24 Disabling Snapshots of Virtual IT Systems (H)
The snapshot feature SHOULD be disabled for all virtual IT systems.
SYS.1.5.A25 Minimal Use of Console Access to Virtual IT Systems (H)
Direct access to the emulated consoles of virtual IT systems SHOULD be reduced to a minimum. The virtual IT systems SHOULD be controlled via the network whenever possible.
SYS.1.5.A26 Use of a PKI [Planner] (H)
A public key infrastructure (PKI) SHOULD be used for certificate-protected communication between the components of a given IT infrastructure.
SYS.1.5.A27 Use of Certified Virtualisation Software (H)
Virtualisation software certified as EAL4 or higher SHOULD be used.
SYS.1.5.A28 Encryption of Virtual IT Systems (H)
All virtual IT systems SHOULD be encrypted.
SYS.1.5.A3 Secure Configuration of Virtual IT Systems (B)
Guest systems MUST NOT access devices and interfaces of a virtualisation server. However, if such a connection is necessary, it MUST be exclusively allocated. It MUST ONLY be established for the necessary duration by the administrator of the host system. Binding rules MUST be specified in this regard. Virtual IT systems SHOULD be configured and protected according to the respective organisation's security policy.
SYS.1.5.A4 Secure Configuration of a Network for Virtual Infrastructures (B)
It MUST be ensured that existing security mechanisms (e.g. firewalls) and monitoring systems cannot be bypassed by virtual networks. It MUST also be ensured that virtual IT systems connected to several networks cannot be used to establish undesired network connections. Network connections between virtual IT systems and physical IT systems and for virtual firewalls SHOULD be configured in accordance with the security policies of the organisation in question.
SYS.1.5.A5 Protection of Administration Interfaces (B)
All administration and management access to management systems and host systems MUST be restricted. It MUST be ensured that it is not possible to access administration interfaces from untrustworthy networks. In order to administer and monitor virtualisation servers or management systems, protocols that are considered secure SHOULD be used. If insecure protocols are nevertheless used, a separate administration network MUST be used.
SYS.1.5.A6 Logging in the Virtual Infrastructure (B)
The operating condition, usage, and network connections of virtual infrastructures MUST be logged continuously. If capacity limits are reached, virtual machines SHOULD be moved. In addition, the corresponding hardware SHOULD be expanded, if applicable. Whether virtual networks have been assigned properly to the respective virtual IT systems MUST also be monitored.
SYS.1.5.A7 Time Synchronisation in Virtual IT Systems (B)
The system time of all virtual IT systems in production use MUST always be synchronous.
SYS.1.5.A8 Planning a Virtual Infrastructure [Planner] (S)
The structure of virtual infrastructure SHOULD be planned in detail. In this process, the applicable rules and policies for operating IT systems, applications, and networks (including storage networks) SHOULD be taken into consideration. If several virtual IT systems are operated on a virtualisation server, conflicts regarding the protection requirements of the IT systems SHOULD be ruled out. Moreover, the tasks of the individual administrator groups SHOULD be defined and clearly separated. The employees responsible for operating specific components SHOULD also be defined.
SYS.1.5.A9 Network Planning for Virtual Infrastructure [Planner] (S)
The structure of networks for virtual infrastructures SHOULD be planned in detail. It SHOULD also be checked whether a separate network must be established and used for certain virtualisation functions (such as live migration). The network segments that need to be set up (e.g. management networks, storage networks) SHOULD be planned. It SHOULD be determined how the network segments can be safely separated and protected from each other. Here, it SHOULD be ensured that the production network is separated from the management network (see SYS.1.5.A11 Administration of the Virtualisation Infrastructure Using a Separate Management Network). The availability requirements for the network in question SHOULD also be met.
SYS.1.6 Containerisation
Target Object: IT system / Order: R2
SYS.1.6.A1 Planning Container Use (B)
Before containers are deployed, the goal of such a deployment (e.g. scaling, availability, disposable containers for safety or CI/CD) SHOULD be determined so that all the securityrelated aspects of installation, operation, and decommissioning can be planned. The planning SHOULD also take into account the operational overhead resulting from container deployment or mixed operation. The planning MUST be adequately documented.
SYS.1.6.A10 Policy for Images and Container Operation (S)
A policy SHOULD be established and applied that specifies the requirements for container operation and permitted images. The policy SHOULD also include requirements for the operation and deployment of images.
SYS.1.6.A11 Only One Service per Container (S)
Each container SHOULD only provide one service at a time.
SYS.1.6.A12 Distribution of Secure Images (S)
The sources of images that have been classified as trusted and SHOULD be adequately documented along with the corresponding reasons. In addition, the process of how images or the software components contained in an image are obtained from trusted sources and eventually deployed to a productive environment SHOULD be adequately documented. 
Images used SHOULD have metadata that makes their function and history traceable. Digital signatures SHOULD secure each image against modification.
SYS.1.6.A13 Release of Images (S)
All images for productive operation SHOULD undergo a test and release process in the same way as software products in accordance with module OPS.1.1.6 Software Tests and Approvals.
SYS.1.6.A14 Updating Images (S)
When establishing a concept for patch and change management according to OPS.1.1.3 Patch and Change Management, it SHOULD be decided when and how the updates of images or the software or service operated are to be rolled out. For persistent containers, checks SHOULD be made as to whether an update of a container is more appropriate than completely reprovisioning the container in exceptional cases.
SYS.1.6.A15 Limitation of Resources per Container (S)
Resources on the host system such as CPU, volatile and persistent memory, and network bandwidth SHOULD be appropriately reserved and limited for each container. How the system should react if these limits are exceeded SHOULD be defined and documented.
SYS.1.6.A16 Administrative Remote Access to Containers (S)
In principle, administrative access from a container to the container host and vice versa 
SHOULD be considered as administrative remote access. Remote administrative access 
SHOULD NOT be established from a container to the container host. Application containers SHOULD NOT contain remote maintenance access points. Administrative access to application containers SHOULD always be carried out via the container runtime.
SYS.1.6.A17 Running Containers Without Privileges (S)
A container runtime and any instantiated containers SHOULD only be executed by a nonprivileged system account that does not have (and cannot gain) elevated rights to the container service or host operating system. The container runtime SHOULD be encapsulated by additional measures, such as using the virtualisation extensions of CPUs. 
If containers are to take over tasks of the host system in exceptional cases, privileges on the host system SHOULD be limited to the minimum necessary. Exceptions SHOULD be adequately documented.
SYS.1.6.A18 Application Services Accounts (S)
System accounts within a container SHOULD have no permissions on the host system. If such authorisation is required for operational reasons, it SHOULD only apply to the data and system access that is absolutely necessary. The account in the container that is necessary to exchange data SHOULD be known in the host system.
SYS.1.6.A19 Including Data Stores in Containers (S)
Containers SHOULD ONLY be able to access the mass storage and directories necessary for operation. Permissions SHOULD only be explicitly assigned where needed. If the container runtime for a container includes local storage, the access rights in the file system SHOULD be restricted to the service account of the container. If network storage is used, the permissions SHOULD be set on the network storage itself.
SYS.1.6.A2 Container Management Planning (B)
The management of containers MUST ONLY be carried out in line with appropriate planning. This planning MUST cover the entire lifecycle from commissioning to decommissioning, including operation and updates. When planning container management, it MUST be taken into account that the creator of a container is to be considered like an administrator due to the effects they have on parts of the operation. 
Containers MUST be started, stopped, and monitored via the management software used.
SYS.1.6.A20 Protection of Configuration Data (S)
Descriptions of container configuration data SHOULD be versioned. Changes SHOULD be documented in a comprehensible manner.
SYS.1.6.A21 Extended Security Policies (H)
Extended policies SHOULD restrict the permissions of containers. Mandatory Access Control (MAC) or a comparable technology SHOULD enforce these policies. At minimum, policies SHOULD restrict the following types of access: 
•	Incoming and outgoing network connections 
•	File system access attempts 
•	Kernel requests (syscalls) 
A runtime SHOULD start containers in such a way that the kernel of the host system prevents all activities of the containers that are not allowed by the relevant policy (e.g. by setting up local packet filters or revoking permissions), or at least reports violations appropriately.
SYS.1.6.A22 Provision for Investigations (H)
In order to have containers available for later investigation in case they are needed, an image of each container's state SHOULD be created according to specified rules.
SYS.1.6.A23 Container Immutability (H)
Containers SHOULD not be able to change their file system during runtime. File systems SHOULD not be integrated with write permissions.
SYS.1.6.A24 Host-Based Attack Detection (H)
The behaviour of containers and the applications or services running in them SHOULD be monitored. Deviations from normal behaviour SHOULD be noticed and reported. The reports SHOULD be handled appropriately in a centralised process for security incident handling. 
At minimum, the behaviour to be monitored SHOULD cover: 
•	Network connections 
•	Created processes 
•	File system access attempts 
•	Kernel requests (syscalls)
SYS.1.6.A25 High Availability of Containerised Applications (H)
In cases involving containerised applications with high availability requirements, the necessary level of availability SHOULD be defined (e.g. redundant at the host level).
SYS.1.6.A26 Advanced Isolation and Encapsulation of Containers (H)
If further isolation and encapsulation of containers is required, the following measures SHOULD be considered for increased effectiveness: 
•	Fixed assignment of containers to container hosts 
•	Execution of the individual containers and/or the container host by means of hypervisors 
•	Fixed assignment of a single container to a single container host
SYS.1.6.A3 Secure Use of Containerised IT Systems (B)
In the case of containerised IT systems, consideration MUST be given to how containerisation affects the IT systems and applications operated, in particular the management and suitability of the applications. 
Based on the protection needs of the applications, it MUST be checked whether the requirements for isolation and encapsulation of the containerised IT systems, virtual networks, and operated applications are sufficiently fulfilled. The mechanisms of the operating system in question SHOULD be included in this check. Since the host performs the function of a network component for virtual networks, the modules of the sub-layers NET.1 Networks and NET.3 Network Components MUST be considered accordingly. Logical and overlay networks MUST also be considered and modelled. Furthermore, the containerised IT systems used MUST meet the requirements at hand regarding availability and data throughput. 
During operation, the performance and the state of the containerised IT systems SHOULD be monitored (health checks).
SYS.1.6.A4 Planning the Provision and Distribution of Images (B)
The process for the provision and distribution of images MUST be planned and appropriately documented.
SYS.1.6.A5 Separation of Administration and Access Networks for Containers (B)
Networks for the administration of the host, the administration of the containers, and their access networks MUST be separated according to the protection needs at hand. In principle, at least the administration of the host SHOULD only be possible from the administration network. 
Only the communication relationships necessary for operation SHOULD be allowed.