chrisbst48/IT-Grundschutz-Compendium_2022_EN huggingface dataset:
APP.4.2.A6 Creation and Implementation of a User and Access Control Policy [Department, Developer] (B)
A user and access control policy MUST be developed and implemented for SAP ERP systems. The following points MUST be considered: • The identity principle, minimum principle, job principle, document principle of accounting, document principle of authorisation administration, segregation of duties principle (SoD), approval principle, standard principle, written form principle, and control principle MUST be taken into account. • User, authorisation, and profile administrators MUST have separate responsibilities and authorisations. • Procedures MUST be defined within authorisation administration for creating, changing, deleting, and transporting roles, as well as for transporting SU24 default values. Authorisation roles SHOULD be created and maintained in the development system. They SHOULD be transported using the Transport Management System (TMS). Authorisations SHOULD be created, saved, and assigned to the users in authorisation roles (PFCG roles) in a role-based access control policy. Since individual critical actions in the roles cannot always be avoided, they SHOULD be covered by mitigation controls. • Within the framework of the access control policy, procedures MUST be defined for the request, approval, modification, and deletion of users and authorisations. • Naming conventions MUST be defined for user IDs and technical role names. • Default values and check indicators SHOULD be maintained in transaction SU24. The corresponding procedure SHOULD be described in the user and access control policy. • Legal and internal framework conditions such as the German Generally Accepted Accounting Principles (German GAAP), the German Commercial Code (HGB), and the organisation's internal specifications MUST be taken into account. The user and access control policy SHOULD also cover the operation of technical accounts, including the authorisation of background and interface users. Appropriate control mechanisms SHOULD be applied to check for SoD conflicts in roles and monitor the assignment of critical authorisations to users. If components such as SAP HANA and SAP NetWeaver Gateway (for Fiori applications) are used in addition to the ABAP back end, the design of the authorisations among the components MUST be coordinated and synchronised
APP.4.2.A7 Protection of SAP Databases (B)
Access to SAP databases MUST be secured. Whenever feasible, administrators SHOULD only be able to access the databases with SAP tools. If third-party software is used for this purpose, additional security safeguards MUST be implemented. The users SAPR3 or SAP MUST NOT be used to connect to databases. In addition, the default passwords (e.g. for SAPR3 or SAP) MUST be changed and certain database tables (such as USR* tables) placed under special protection.
APP.4.2.A8 Protection of the SAP RFC Interface (B)
To protect the Remote Function Call (RFC) interface, RFC connections, RFC authorisations, and RFC gateways MUST be configured securely. Uniform administrative guidelines MUST be created and implemented for all RFC connections. For this purpose, the required RFC connections SHOULD be defined and documented. Connections with a stored password SHOULD not be configured from lower- to higher-privileged systems (e.g. from Dev to Prod). RFC connections that are no longer usedMUST be deleted. All RFC gateways MUST be securely administered and suitable profile parameters MUST be set (e.g. gw/monitor, gw/reg_no_conn_info and snc/permit_insecure_start). All connections that are established via a gateway MUST be analysed and evaluated in terms of their security. Furthermore, logging MUST be enabled. Access control lists (ACLs) MUST be defined.
APP.4.2.A9 Protecting and Monitoring the Message Server (B)
The message server MUST be secured by appropriate settings in the profile parameters. Among other things, it MUST be decided whether ACLs are to be set up for the internal message server. The message server MUST be monitored using appropriate mechanisms so that system failures on the message server are detected quickly (for example).
APP.4.3 Relational Database Systems
Target Object: Application / Order: R2
APP.4.3.A1 Creation of a Security Policy for Database Systems (B)
Based on its general security policy, an organisation MUST draw up a security policy specific to database systems. This MUST comprehensibly describe requirements and specifications for the secure operation of database systems. The guideline MUST be familiar to all employees responsible for database systems. It MUST be integral to their work. If the policy is changed or deviations from the requirements are allowed, this MUST be coordinated with the CISO and documented. The correct implementation of the policy MUST be regularly reviewed. The results MUST be documented in an appropriate manner.
APP.4.3.A11 Sufficient Hardware Capacity [Process Owner] (S)
Database management systems SHOULD be installed on hardware with sufficient capacity. The hardware SHOULD have sufficient reserves in order to meet potentially increasing requirements. If resource bottlenecks become apparent during operations, these SHOULD be eliminated at an early stage. When sizing hardware, the growth expected for the scheduled deployment period SHOULD be taken into account.
APP.4.3.A12 Uniform Configuration Standard for Database Management Systems (S)
A uniform configuration standard SHOULD be defined for all the database management systems deployed. All database management systems SHOULD be configured and operated in the same manner according to this standard. If an installation requires a deviation from the configuration standard, all steps SHOULD be approved by the CISO and documented transparently. The configuration standard SHOULD be reviewed and adapted as required at regular intervals.
APP.4.3.A13 Restrictive Utilisation of Database Links (S)
It SHOULD be ensured that only persons in charge are authorised to create database links (DB links). If such links are created, private DB links MUST be preferred to public DB links. All DB links created by the persons in charge SHOULD be documented and reviewed at regular intervals. Additionally, DB links SHOULD be taken into account when the database system is backed up (see APP.4.3.A9 Backing Up a Database System).
APP.4.3.A16 Encryption of Database Connections (S)
A database management system SHOULD be configured in such a way that database communications are always encrypted. The cryptographic methods and protocols used to this end SHOULD comply with the internal specifications of the respective organisation (see CON.1 Crypto Concept).
APP.4.3.A17 Data Transfer or Migration [Process Owner] (S)
The manner in which data should be transferred to a database initially or regularly SHOULD be defined in advance. After data is transferred, checks SHOULD be performed to ensure that it is complete and has not been changed.
APP.4.3.A18 Database Management System Monitoring (S)
The parameters, events, and operating states of a database management system that are critical to secure operations SHOULD be defined. These SHOULD be monitored using a corresponding system. Threshold values SHOULD be defined for all critical parameters, events, and operating states. If these values are exceeded, appropriate action MUST be taken. The responsible staff members SHOULD be alerted. Application-specific parameters, events, operating states, and their threshold values SHOULD be coordinated with the persons responsible for the specialised applications in use.
APP.4.3.A19 Protection Against Malicious Database Scripts [Developer] (S)
If database scripts are developed, binding quality criteria SHOULD be defined for them (see CON.8 Software Development). Database scripts SHOULD be subjected to extensive functional tests on separate test systems before they are used in production environments. The results SHOULD be documented.
APP.4.3.A20 Regular Audits (S)
All the components of a database system SHOULD be checked regularly in terms of whether all the specified security safeguards have been implemented and are configured correctly. This SHOULD include checks of whether the documented status corresponds to the actual status and whether the configuration of the database management system corresponds to the documented standard configuration. In addition, it SHOULD be determined whether all the database scripts at hand are actually needed. Whether they meet the quality standard of the respective organisation SHOULD also be checked. Furthermore, the log files of the database system and the operating system SHOULD be checked for irregularities (see DER.1 Detecting Security-Relevant Events). The audit results SHOULD be documented in a transparent manner. They SHOULD be compared against the target status. Deviations SHOULD be investigated.
APP.4.3.A21 Use of Database Security Tools (H)
Information security products SHOULD be used for databases. The products used SHOULD provide the following functions: • Creation of an overview of all database systems • Extended configuration options and rights management for databases • Detection and prevention of possible attacks (e.g. brute force attacks on a user account or SQL injections) • Audit functions (e.g. checking configuration requirements)
APP.4.3.A22 Contingency Planning (H)
A business continuity plan that includes information on how emergency operations can be carried out SHOULD be prepared for the database management system in use. The resources required for the business continuity plan SHOULD be identified. Additionally, the business continuity plan SHOULD define how the respective organisation can return from emergency operations to regular operations. The business continuity plan SHOULD define the necessary reporting channels, response routes, resources, and response times for the process owners. Based on a coordination plan for the restoration of service, all IT systems that depend on the database in question SHOULD be identified in advance and taken into consideration.
APP.4.3.A23 Archiving (H)
If the data of a database system needs to be archived, a corresponding archiving concept SHOULD be drawn up. It SHOULD be ensured that the existing data will be available at a later point in time in a complete and consistent manner. The archiving concept SHOULD define both archiving intervals and the storage period of the archived data. Additionally, the technology used to archive the database SHOULD be documented. The archived data SHOULD be used for regular recovery tests. The results SHOULD be documented.
APP.4.3.A24 Data Encryption in Databases (H)
The data stored in databases SHOULD be encrypted. In so doing, the following factors (among others) SHOULD be considered beforehand: • Effects on performance • Key management processes and methods, including separate key storage and security • Effects on backup recovery concepts • Functional impact on the database (regarding sorting options, for example)
APP.4.3.A25 Security Vetting of Database Systems (H)
Security vetting SHOULD be carried out on database systems at regular intervals. The systemic and manufacturer-specific aspects of the database infrastructure (e.g. directory services) used and the database management system deployed SHOULD be considered within the framework of security vetting.
APP.4.3.A3 Basic Hardening of Database Management Systems (B)
Database management systems MUST be hardened. To this end, a checklist of the steps to be performed MUST be compiled and completed. Passwords MUST NOT be stored in plain text. Basic hardening MUST be reviewed and adapted as required at regular intervals.
APP.4.3.A4 Controlled Creation of New Databases (B)
New databases MUST be created in accordance with a defined process. When a new database is created, basic information on the database MUST be documented in a comprehensible manner.
APP.4.3.A9 Backing Up a Database System (B)
System backups of a DBMS and its data MUST be performed at regular intervals. The database system MUST also be backed up before a new database is created. The service programs permitted for this purpose SHOULD be used. All transactions SHOULD be backed up in such a way that they can be recovered at any time. If the backup exceeds the available capacity, an extended concept SHOULD be created to back up the database (e.g. incremental backups). The recovery parameters SHOULD be specified based on the protection needs of the data (see CON.3 Backup Concept).
APP.4.4 Kubernetes
Target Object: Application / Order: R2
APP.4.4.A1 Planning the Separation of the Applications (B)
Before going live, the manner in which the applications running in the pods in question and their different test and production operating environments will be separated MUST be planned. Based on the protection needs of the applications, the planning MUST determine which architecture of namespaces, meta tags, clusters, and networks adequately addresses the risks at hand and whether virtualised servers and networks should also be used.
APP.4.4.A10 Securing Automation Processes (S)
All automation software processes, such as CI/CD and their pipelines, SHOULD only operate with the rights that are strictly necessary. If different user groups can change configurations or start pods via automation software, this SHOULD be done for each group through separate processes that only have the rights necessary for the respective user group.
APP.4.4.A11 Container Monitoring (S)
In pods, each container SHOULD define a health check for start-up and operation (readiness and liveness). These checks SHOULD provide information about the availability of the software running in a pod. The checks SHOULD fail if the monitored software cannot perform its tasks properly. For each of these checks, a time period SHOULD be defined that is appropriate for the service running in the pod. Based on these checks, Kubernetes SHOULD delete or restart the pods.
APP.4.4.A12 Securing Infrastructure Applications (S)
If a separate registry for images or automation software, persistent volume management, configuration file storage, or similar is in use, its protection SHOULD at least consider: 
•	Use of personal and service accounts for access 
•	Encrypted communication on all network ports 
•	Restrictive assignment of permissions to user and service accounts 
•	Logging of changes 
•	Regular data backups
APP.4.4.A13 Automated Configuration Auditing (H)
There SHOULD be an automated audit that checks the settings of nodes, of Kubernetes, and of the pods of applications against a defined list of allowed settings and standardised benchmarks. 
Kubernetes SHOULD enforce these established rules in each cluster by connecting appropriate tools.
APP.4.4.A14 Use of Dedicated Nodes (H)
In a Kubernetes cluster, nodes SHOULD be assigned dedicated tasks and only run pods that are assigned to each task. 
Bastion nodes SHOULD handle all incoming and outgoing data connections of between applications and other networks. 
Management nodes SHOULD operate control plane pods and only handle control plane data connections. 
If deployed, storage nodes SHOULD only operate the fixed persistent volume services pods in a cluster.
APP.4.4.A15 Separation of Applications at Node and Cluster Level (H)
Applications with very high protection needs SHOULD each use their own Kubernetes clusters or dedicated nodes that are not available for other applications.
APP.4.4.A16 Use of Operators (H)
The automation of operational tasks in operators SHOULD be used for particularly critical applications and control plane programs.
APP.4.4.A18 Use of Micro-Segmentation (H)
Pods SHOULD ONLY be able to communicate with each other through the necessary network ports, even within a Kubernetes namespace. There SHOULD be rules within the CNI that disallow all but the necessary network connections within the Kubernetes namespace. These rules SHOULD precisely define the source and destination of the allowed connections using at least one of the following criteria: service name, metadata (“labels”), Kubernetes service accounts, or certificate-based authentication. 
All the criteria used as labels for a connection SHOULD be secured in such a way that they can only be changed by authorised persons and management services.
APP.4.4.A19 High Availability of Kubernetes (H)
A Kubernetes operation SHOULD be set up in such a way that if a site fails, the clusters (and thus the applications in the pods) either continue to run without interruption or can be restarted in a short time at another site. 
Should a restart be required, all the necessary configuration files, images, user data, network connections, and other resources required for operation (including the necessary hardware) SHOULD already be available at the alternative site. 
For the uninterrupted operation of clusters, the control plane of Kubernetes, the infrastructure applications of the clusters, and the pods of the applications SHOULD be distributed across several fire zones based on the location data of the corresponding nodes so that the failure of a fire zone will not lead to the failure of an application.
APP.4.4.A2 Planning Automation with CI/CD (B)
Automating the operation of applications in Kubernetes using CI/CD MUST ONLY take place after appropriate planning. The planning MUST cover the entire lifecycle from commissioning to decommissioning, including development, testing, operation, monitoring, and updates. A roles and rights concept and the securing of Kubernetes Secrets MUST be part of the planning.
APP.4.4.A20 Encrypted Data Storage for Pods (H)
The file systems containing the persistent data of the control plane (etcd in particular in this context) and the application services SHOULD be encrypted.
APP.4.4.A21 Regular Restart of Pods (H)
Pods SHOULD be stopped and restarted regularly if there is an increased risk of external interference and a very high need for protection. No pod SHOULD run for more than 24 hours. The availability of the applications in a pod SHOULD be ensured.
APP.4.4.A3 Identity and Access Management for Kubernetes (B)
Kubernetes and all other control plane applications MUST authenticate and authorise each action taken by a user or, in automated mode, corresponding software. This applies whether the actions are taken via a client, a web interface, or a corresponding API. Administrative actions MUST NOT be performed anonymously. 
Each user MUST ONLY be granted the permissions they absolutely require. Unlimited access rights MUST be granted in a very restrictive manner. 
Only a small group of people SHOULD be authorised to define automation processes. Only selected administrators SHOULD be given the right to create or change shares for persistent volumes in Kubernetes.
APP.4.4.A4 Separation of Pods (B)
The operating system kernel of nodes MUST have isolation mechanisms to restrict visibility and resource usage among the corresponding pods (cf. Linux namespaces and cgroups). At minimum, this isolation MUST include process IDs, inter-process communication, user IDs, the file system, and the network (including the hostname).
APP.4.4.A5 Backup in the Cluster (B)
A cluster MUST have a backup. The backup MUST include: 
•	Persistent volumes 
•	Configuration files for Kubernetes and the other programs of the control plane 
•	The current state of the Kubernetes cluster, including extensions 
•	Databases of the configuration (namely etcd in this case) 
•	All infrastructure applications required to operate the cluster and the services within it 
•	The data storage of the code and image registries 
Snapshots for the operation of the applications SHOULD also be considered. Snapshots MUST NOT be considered a substitute for backups.
APP.4.4.A6 Initialisation of Pods (S)
If an initialisation (e.g. of an application) takes place in a pod at start-up, this SHOULD take place in a separate Init container. It SHOULD be ensured that the initialisation terminates all processes that are already running. Kubernetes SHOULD ONLY start the other containers if the initialisation is successful.
APP.4.4.A7 Separation of Networks for Kubernetes (S)
Networks for the administration of nodes, the control plane, and the individual networks of application services SHOULD be separated. 
Only the network ports of the pods necessary for operation SHOULD be released into the designated networks. If a Kubernetes cluster contains multiple applications, all the network connections between the Kubernetes namespaces SHOULD first be prohibited and only required network connections permitted (whitelisting). The network ports necessary for the administration of the nodes, the runtime, and Kubernetes (including its extensions) SHOULD ONLY be accessible from the corresponding administration network and from pods that need them. 
Only selected administrators SHOULD be authorised in Kubernetes to manage the CNI and create or change rules for the network.
APP.4.4.A8 Securing Configuration Files on Kubernetes (S)
The configuration files of a Kubernetes cluster, including all its extensions and applications, SHOULD be versioned and annotated. 
Access rights to configuration file management software SHOULD be granted in a restrictive manner. Read and write access rights to the configuration files of the control plane SHOULD be assigned and restricted with particular care.
APP.4.4.A9 Use of Kubernetes Service Accounts (S)
Pods SHOULD NOT use the default service account. Rights SHOULD NOT be granted to the default service account. Pods for different applications SHOULD run under their own service accounts. Access rights for the service accounts of the applications'' pods SHOULD be limited to those that are strictly necessary. 
Pods that do not require a service account SHOULD not be able to view it or have access to corresponding tokens. 
Only control plane pods and pods that absolutely need them SHOULD use privileged service accounts. 
Automation programs SHOULD each receive their own tokens, even if they share a common service account due to similar tasks.
APP.4.6 SAP ABAP Programming
Target Object: Application / Order: R2
APP.4.6.A1 Protecting Reports with Authorisation Checks (B)
It MUST be ensured that only authorised users can start self-programmed evaluations (reports). Therefore, each report MUST perform explicit authorisation checks appropriate to the context at hand.
APP.4.6.A10 Execution of Operating System Commands (S)
Each call of a permitted operating system command SHOULD be preceded by a corresponding authorisation check (authorisation object S_LOG_COM). User input SHOULD NOT be part of a command. For this reason, operating system calls SHOULD only be executed using standard SAP function modules intended for this purpose.
APP.4.6.A11 Avoiding Planted Malicious Code (S)
The ABAP commands INSERT REPORT and GENERATE SUBROUTINE POOL SHOULD NOT be used.
APP.4.6.A12 Avoiding Generic Module Execution (S)
Transactions, programs, function modules, and methods SHOULD NOT be generically executable. If there are important reasons for a generic execution, where and why this is happening SHOULD be documented in detail. In addition, a whitelist SHOULD be defined that contains all the permitted modules. Before a module is called, the user's input SHOULD be compared against the whitelist.
APP.4.6.A13 Avoiding Generic Access to Table Contents (S)
Table contents SHOULD NOT be read generically. If there are important reasons for doing this, where and why this is happening SHOULD be documented in detail. It SHOULD also be ensured that the dynamic table name is restricted to a controllable list of values.
APP.4.6.A14 Avoiding Native SQL Statements (S)
The ABAP Database Connectivity (ADBC) interface SHOULD NOT be used. User input SHOULD NOT be part of ADBC commands.
APP.4.6.A15 Avoiding Data Leaks (S)
A sufficiently secure authorisation check SHOULD be performed before business-critical data is displayed, transmitted, or exported. Planned (intended) export options SHOULD be documented.
APP.4.6.A16 No System-Dependent Execution of Functions (S)
ABAP programs SHOULD NOT be programmed in a system-dependent manner—that is, so that they can only be executed on a particular SAP system. Should this be absolutely necessary, however, it SHOULD be documented in detail. In addition, the code SHOULD then be checked manually.