chrisbst48/IT-Grundschutz-Compendium_2022_EN huggingface dataset:
APP.3.4.A1 Planning the Use of a Samba Server (B)
The IT Operation Department MUST carefully plan and regulate the introduction of a Samba server. Depending on the operational scenario, it MUST define the operating mode of the Samba server and the tasks it will perform. It MUST also define which Samba components and other components are required for these purposes. If the CTDB (Clustered Trivial Database) solution is to be used, the IT Operation Department MUST design it with care. If Samba is also meant to provide Active Directory (AD) services for Linux and Unix systems, these services MUST be planned carefully and tested. Furthermore, the authentication procedure for AD MUST be designed and implemented carefully. The implementation and the order in which stackable Virtual File System (VFS) modules are executed MUST be designed carefully. This implementation SHOULD be documented. If IPv6 is to be used under Samba, this MUST also be carefully planned. In addition, whether the integration works without errors MUST be checked in a near-operational test environment.
APP.3.4.A10 Secure Use of External Programs on a Samba Server (S)
The IT Operation Department SHOULD ensure that Samba only calls trustworthy external programs that have been checked for malicious functions.
APP.3.4.A12 Training Samba Server Administrators (S)
Administrators SHOULD be trained on the specific areas of Samba that are in use—user authentication and rights models for Windows and Unix, for example, but also on ACLs and ADS for NTFS.
APP.3.4.A13 Regular Backups of Important Samba Server Components (S)
All the system components required to recover a Samba server SHOULD be included in the organisation-wide backup concept. The account information of all the back ends in use SHOULD also be considered. In addition, all TDB files should be backed up. Furthermore, the Samba registry SHOULD be backed up if it has been used for shares.
APP.3.4.A15 Encryption of Data Packets in Samba (H)
To ensure their security while in transit, data packets SHOULD be encrypted using the methods integrated from SMB version 3.
APP.3.4.A2 Secure Basic Configuration of a Samba Server (B)
The IT Operation Department MUST configure the Samba server securely. Among other things, the access control settings MUST be adjusted. The same SHOULD apply to settings that affect the performance of the server. The IT Operation Department MUST configure Samba to only accept connections from secure hosts and networks. Changes to the configuration SHOULD be documented carefully so that it is possible at any time to determine who made which changes and for what reasons. In such cases, the syntax of the configuration file MUST be checked for correctness after every change. Additional software modules such as SWAT MUST NOT be installed.
APP.3.4.A3 Secure Configuration of a Samba Server (S)
Databases in the Trivial Database (TDB) format SHOULD NOT be stored on a partition that uses ReiserFS as its file system. If a netlogon share is configured, unauthorised users SHOULD NOT be able to modify any files on the share. The operating system of a Samba server SHOULD support access control lists (ACLs) in connection with the file system used. In addition, it SHOULD be ensured that the file system is integrated with the appropriate parameters. The default settings of SMB Message Signing SHOULD be maintained unless they are contrary to the existing security policies in the information domain in question.
APP.3.4.A4 Avoiding NTFS File Properties on a Samba Server (S)
If a version of Samba is used that cannot map ADS in the New Technology File System (NTFS) and file system objects are to be copied or moved across system boundaries, file system objects SHOULD NOT contain ADS with important information.
APP.3.4.A5 Secure Configuration of a Samba Server's Access Controls (S)
The default parameters used by Samba to map DOS attributes to the Unix file system SHOULD NOT be used. Instead, Samba should be configured to save DOS attributes and inheritance flags in extended attributes. Shares SHOULD only be managed via the Samba registry. In addition, the effective access authorisations for the shares of a Samba server SHOULD be checked regularly.
APP.3.4.A6 Secure Configuration of Winbind in Samba (S)
The operating system of the server SHOULD include a user account with all necessary group memberships for each Windows domain user. If this is not possible, Winbind SHOULD be used to convert domain user names into unique Unix user names. When using Winbind, it SHOULD be ensured that conflicts between local Unix users and domain users are prevented. Furthermore, the pluggable authentication modules (PAMs) SHOULD be integrated.
APP.3.4.A7 Secure DNS Configuration in Samba (S)
If Samba is to be used as a DNS server, this implementation SHOULD be planned carefully and tested in advance. Since Samba supports various AD integration modes, the IT Operation Department SHOULD set the DNS settings in accordance with the Samba application scenario at hand.
APP.3.4.A8 Secure LDAP Configuration in Samba (S)
If users are managed with LDAP in Samba, the IT Operation Department SHOULD plan and document this configuration carefully. The access authorisations for LDAP SHOULD be controlled by means of ACLs.
APP.3.4.A9 Secure Configuration of Kerberos in Samba (S)
The Heimdal Kerberos Key Distribution Center (KDC) implemented by Samba SHOULD be used for authentication. It SHOULD be ensured that the Kerberos configuration file specified by Samba is used. Only secure encryption methods SHOULD be used for Kerberos tickets. If Kerberos is used for authentication, the central time server SHOULD be installed locally on the Samba server. The NTP service SHOULD be configured so that only authorised clients can request the time.
APP.3.6 DNS Servers
Target Object: Application / Order: R2
APP.3.6.A1 Planning the Use of DNS (B)
The use of DNS servers MUST be planned carefully. The manner in which the DNS network service should be set up MUST be determined first. Sensitive domain information MUST also be identified. The manner in which DNS servers are to be incorporated into the network of the information domain in question MUST be planned. All decisions MUST be documented appropriately.
APP.3.6.A10 Selection of a Suitable DNS Server Product (S)
If a DNS server product is procured, care SHOULD be taken to ensure that it has proven itself sufficiently in practice. The DNS server product SHOULD support the current RFC standards. Furthermore, the DNS server product SHOULD support the person in charge in creating syntactically correct master files.
APP.3.6.A11 Sufficient Capacity of DNS Servers (S)
The hardware of a DNS server SHOULD have sufficient capacity. A DNS server's hardware SHOULD be used exclusively to operate the server. The network connections of all the DNS servers in the information domain under consideration SHOULD be dimensioned sufficiently.
APP.3.6.A13 Limited Visibility of Domain Information (S)
An information domain's name space should be divided into a public and an organisation-internal area. The public part SHOULD only include the domain information required by services that are to be accessible from external sources. IT systems in the internal network SHOULD not be assigned any DNS names that may be resolved from external sources if they have a public IP address.
APP.3.6.A14 Location of Name Servers (S)
Primary and secondary advertising DNS servers SHOULD be located in different network segments.
APP.3.6.A15 Analysis of Log Data (S)
DNS server log data SHOULD be checkedand analysed on a regular basis. At minimum, the following security-relevant events SHOULD be evaluated: • Number of DNS requests • Number of errors in DNS requests • Errors in extension mechanisms for DNS (EDNS) • Expiring zones • Failed zone transfers • Changes in the ratio of errors to DNS requests
APP.3.6.A16 Integrating a DNS Server into a “P-A-P” Structure (S)
DNS servers SHOULD be integrated into a “packet filter – application level gateway – packet filter” (P-A-P) structure (see also NET.1.1 Network Architecture and Design). In the process, the advertising DNS server SHOULD be placed in a demilitarised zone (DMZ) of the outer packet filter. The resolving DNS server SHOULD be installed in a DMZ of the internal packet filter.
APP.3.6.A17 Use of DNSSEC (S)
The DNS protocol extension DNSSEC SHOULD be enabled on both resolving DNS servers and advertising DNS servers. The key signing keys (KSK) and zone signing keys (ZSK) used for this SHOULD be changed at regular intervals.
APP.3.6.A18 Advanced Securing of Zone Transfers (S)
Transaction signatures (TSIG) SHOULD be used additionally to achieve stronger security of zone transfers.
APP.3.6.A19 Disposal of DNS Servers (S)
A DNS server SHOULD be deleted from both the domain name space and the network system.
APP.3.6.A2 Deployment of Redundant DNS Servers (B)
Advertising DNS servers MUST be designed for redundancy. There MUST be at least one additional secondary DNS server for every advertising DNS server.
APP.3.6.A20 Feasibility Reviews of Business Continuity Plans (H)
An organisation SHOULD check the feasibility of its business continuity plan for DNS servers on a regular basis.
APP.3.6.A21 Hidden Master (H)
In order to make attacks on a primary advertising DNS server more difficult, a hidden master configuration SHOULD be established.
APP.3.6.A22 Connecting DNS Servers via Different Providers (H)
Externally available DNS servers SHOULD be connected using different providers.
APP.3.6.A3 Use of Separate DNS Servers for Internal and External Requests (B)
Advertising DNS servers and resolving DNS servers MUST be separated on the server side. The resolvers of internal IT systems MUST ONLY use internal resolving DNS servers.
APP.3.6.A4 Secure Basic Configuration of a DNS Server (B)
A resolving DNS server MUST be configured to only accept requests from the internal network. If a resolving DNS server sends requests, it MUST use random source ports. If DNS servers delivering forged domain information are known, the resolving DNS server MUST be prevented from sending requests to these DNS servers. An advertising DNS server MUST be configured to always handle requests from the Internet iteratively. It MUST be ensured that DNS zone transfers between primary and secondary DNS servers function appropriately. Zone transfers MUST be configured so that they are only possible between primary and secondary DNS servers. Zone transfers MUST be limited to certain IP addresses. The version of the DNS server product used MUST be hidden.
APP.3.6.A6 Securing Dynamic DNS Updates (B)
It MUST be ensured that only legitimate IT systems are allowed to modify domain information. The domain information that can be changed by the IT systems MUST be specified.
APP.3.6.A7 Monitoring of DNS Servers (B)
DNS servers must be monitored continuously. In particular, DNS server load MUST be monitored in order adapt the performance capacity of the hardware in good time. DNS servers MUST be configured in such a way that at least the following security-relevant events are logged: • Number of DNS requests • Number of errors in DNS requests • Errors in extension mechanisms for DNS (EDNS) • Expiring zones • Failed zone transfers
APP.3.6.A8 Administration of Domain Names [Central Administration] (B)
It MUST be ensured that the registrations for all of the domains that an organisation uses are extended regularly and in good time. An employee MUST be assigned responsibility for the administration of Internet domain names. If an organisation commissions an Internet service provider to handle domain administration, it MUST be ensured that the organisation retains control of the domains.
APP.3.6.A9 Creation of a Business Continuity Plan for DNS Servers (B)
A business continuity plan MUST be drawn up for DNS servers. This business continuity plan MUST be integrated into the existing business continuity plans of the organisation in question. The DNS server business continuity plan MUST describe a data backup concept for the zone and configuration files. The business continuity plan for the zone and configuration files MUST be integrated into the organisation's existing backup plan. The contingency plan for DNS servers MUST include a plan to restore all the DNS servers in the information domain under consideration.
APP.4.2 SAP ERP Systems
Target Object: Application / Order: R2
APP.4.2.A1 Secure Configuration of the SAP ABAP Stack (B)
The SAP ABAP stack MUST be configured securely. For this purpose, the respective profile parameters MUST be set (e.g. for password security, authentication, and encryption). The system change option and the clients MUST also be configured, IMG customising carried out, and the operating system commands saved.
APP.4.2.A11 Secure Installation of an SAP ERP System (S)
When installing an SAP ERP system, current SAP security guides and documentation SHOULD be taken into account. In addition, the security policy of the organisation at hand SHOULD be observed. It SHOULD also be ensured that the SAP ERP system is to be installed on a secure operating system.
APP.4.2.A12 SAP Authorisation Development [Department, Developer] (S)
Technical authorisations SHOULD be developed on the basis of technical specifications. Furthermore, SAP authorisations SHOULD be adapted or created anew on the development system of the SAP landscape under consideration. In cases involving S/4HANA, this SHOULD also include authorisation development on HANA databases. Repository roles SHOULD be set up and transported, as well. Database privileges SHOULD NOT be assigned directly to users. For software developed in-house (e.g. for transactions or authorisation objects), transaction SU24 SHOULD be maintained (assignments of authorisation objects to transactions). Full authorisation (*) or intervals in object values SHOULD be avoided. Authorisation development SHOULD be carried out as part of change management. It SHOULD be ensured that the production system in question is adequately protected against authorisation changes and that no developer keys are assigned. The respective quality assurance system SHOULD be operated in the same way as the production system when assigning authorisations and adding settings.
APP.4.2.A13 SAP Password Security (S)
To ensure secure logins to an SAP ERP system, profile parameters, customising switches, or a security policy SHOULD be configured appropriately. The hash algorithms used for the stored hash values of the passwords in an SAP ERP system SHOULD comply with the current security standards. Access to tables with hash values SHOULD be restricted.
APP.4.2.A14 Identification of Critical SAP Authorisations [Department] (S)
The handling of critical authorisations SHOULD be strictly controlled. These authorisations, roles, and profiles SHOULD be assigned restrictively. This SHOULD also be ensured for critical role combinations and additive effects such as cross authorisations. Critical authorisations SHOULD be regularly identified, reviewed, and evaluated. The SAP profiles SAP_ALL and SAP_NEW* and the SAP authorisation object S_DEVELOP (with change authorisations ACTVT 01 and 02) SHOULD not be assigned in a production system. Emergency users SHOULD be excluded from this requirement.
APP.4.2.A15 Secure Configuration of the SAP Router (S)
The SAP router SHOULD regulate access to the network and complement the existing firewall architecture appropriately. It SHOULD also control access to the SAP ERP system.
APP.4.2.A16 Implementation of Security Requirements for the Windows Operating System (S)
The SAP ERP system SHOULD NOT be installed on a Windows domain controller. The SAP-specific users, such as adm or SAPService , SHOULD be secured. After installation, the user SHOULD be locked. The user SAPService SHOULD NOT have any interactive login rights. With respect to these authorisations, the system resources associated with the SAP ERP system (such as files, processes, and shared memory) SHOULD be protected. Appropriate settings SHOULD be used to secure the specific authorisations of the users Guest, System, SAP system users = adm, SAPService and Database users = , as well as user groups created by the SAP ERP system.
APP.4.2.A17 Implementation of Security Requirements for the Unix Operating System (S)
Access authorisations SHOULD be defined for the SAP ERP system directories in Unix. The passwords of the system-specific users adm and SHOULD also be changed. After installation, the user SHOULD be locked.
APP.4.2.A18 Disabling Insecure Communications (S)
Communications with and among SAP ERP systems SHOULD be secured with SNC. If the database and the SAP application server are operated on different systems, the database connection SHOULD be encrypted appropriately. The internal services of the SAP application server SHOULD ONLY communicate with each other using TLS.
APP.4.2.A19 Definition of Security Policies for Users (S)
Specific security policies for passwords and login restrictions SHOULD be created for specific users and user groups. For example, users with critical authorisations SHOULD be protected by strong password rules (SECPOL transaction). Security policies SHOULD be correctly assigned to users and checked regularly.
APP.4.2.A2 Secure Configuration of the SAP Java Stack (B)
The SAP Java stack MUST be configured securely if it is used. Security mechanisms and concepts that are different from the SAP ABAP stack MUST be created for this. Administrators MUST therefore know the architecture of the Java stack and how it is administered. In addition, unnecessary services MUST be shut down, standard content removed, HTTP services protected, and access to administration interfaces restricted.
APP.4.2.A20 Secure SAP GUI Settings (S)
SAP GUI SHOULD be installed on all clients and updated regularly. SAP GUI ACLs SHOULD also be activated and appropriate administration rules distributed and activated.
APP.4.2.A22 Protection of the Spool in the SAP ERP System [Developer] (S)
It SHOULD be ensured that data from sequential data processing such as spool or print can only be accessed to a limited extent. Unauthorised users SHOULD also be prevented from accessing the TemSe data store used by the SAP spool system. The authorisations granted SHOULD be checked regularly.
APP.4.2.A23 Protection of SAP Background Processing [Developer] (S)
SAP background processing SHOULD be protected against unauthorised access. For batch jobs, various system user IDs SHOULD be defined and created according to their functional areas. Dialogue users SHOULD NEVER be authorised for this purpose.
APP.4.2.A24 Activation and Protection of the Internet Communication Framework (S)
It SHOULD be ensured that only necessary ICF services are activated. All ICF services that are under an ICF object SHOULD only be activated individually. Authorisations SHOULD be assigned restrictively. Communications SHOULD be encrypted.
APP.4.2.A25 Secure Configuration of the SAP Web Dispatcher (S)
The SAP Web Dispatcher SHOULD not be the first entry point from the Internet into an SAP ERP system. The SAP Web Dispatcher SHOULD always be up to date. It SHOULD be configured securely.
APP.4.2.A26 Protection of Customers' Own Code in the SAP ERP System (S)
A custom code management process SHOULD be defined so that a customer’s own code is removed if it can be replaced by standard SAP code or is no longer used. The requirements from the guideline for the development of ABAP programs SHOULD also be taken into account.
APP.4.2.A27 Auditing the SAP ERP System [Department] (S)
To ensure that all internal and external guidelines and requirements are being met, all SAP ERP systems SHOULD be audited regularly. The Security Optimization Service in SAP Solution Manager SHOULD be used for this purpose. The results of audits SHOULD be evaluated and documented.
APP.4.2.A28 Creation of a Contingency Concept [BCM Officer] (S)
A contingency concept SHOULD be created and followed for SAP ERP systems. It SHOULD secure business activities and meet the requirements of crisis management or business continuity management. The following points SHOULD be described and defined in the contingency concept: • Incident detection and response • Data backup and recovery • Business continuity management The contingency concept SHOULD be updated at regular intervals.
APP.4.2.A29 Setting Up Emergency Users (S)
User IDs SHOULD be created for emergency users. The IDs and authorisations that have been set up SHOULD be strictly controlled and precisely documented. In addition, all activities performed by emergency users SHOULD be logged.
APP.4.2.A3 Network Security (B)
To guarantee network security, appropriate concepts MUST be created that factor in the SAP ERP system and the settings made therein. Furthermore, the SAP router and SAP Web Dispatcher SHOULD be used to implement and maintain a secure SAP network. In order to avoid vulnerabilities due to misinterpretations or misunderstandings, the IT Operation Department, firewall operations, portal operations, and SAP operations MUST be coordinated.
APP.4.2.A30 Implementation of Continuous Monitoring of Security Settings (S)
The correctness of all SAP ERP system security settings SHOULD be constantly monitored. The proper application of all patches and updates SHOULD also be monitored. SAP monitoring SHOULD be integrated into an organisation’s general system monitoring.
APP.4.2.A31 Configuration of SAP Single Sign-On (S)
If multiple SAP ERP systems exist, users SHOULD access the systems with SAP Single Sign-On (SAP SSO). A decision SHOULD be made in the planning phase regarding the SAP ERP systems on which the SSO mechanism will be used. SSO SHOULD be configured and operated securely.
APP.4.2.A32 Real-Time Detection and Alerts for Irregular Processes (H)
The most important security recording functions in SAP ERP systems, such as the security audit log or system log, SHOULD be continuously monitored. An employee in charge SHOULD be automatically alerted in the event of suspicious transactions. To analyse SAP-specific security incidents and differentiate false reports from actual security incidents, employees SHOULD either be trained or third-party services should be used.
APP.4.2.A4 Protection of Standard SAP User IDs (B)
Immediately after installing an SAP ERP system, the default passwords for the standard user IDs MUST be changed. Suitable safeguards MUST also be taken to secure the standard SAP user IDs that have been set up. Certain standard user IDs MUST NOT be used (e.g. for RFC connections and background jobs).
APP.4.2.A5 Configuration and Protection of SAP User Administration (B)
SAP user administration for ABAP systems MUST be undertaken in a secure and careful manner. Activities such as creating, changing, and deleting users; resetting and unlocking passwords; and assigning roles and profiles MUST be part of user administration.