chrisbst48/IT-Grundschutz-Compendium_2022_EN huggingface dataset:
APP.2.2.A5 Hardening Active Directory (B)
Built-in accounts MUST be configured with complex passwords. They MUST ONLY be used as emergency accounts. Privileged accounts MUST be members of the “protected users” group. Managed service accounts (for groups) MUST be used for service accounts. All domain controllers MUST be assigned restrictive access rights at the operating system level. The Active Directory restore mode MUST be protected by an appropriate password. Work in this mode SHOULD only be performed in compliance with the two-person principle. A map of the domain controller SHOULD be created on a regular basis. The authorisations for the “Everyone” group MUST be restricted. The domain controller MUST be protected against unauthorised restarts. The policies for domains and domain controllers MUST include secure settings for passwords, account lockout, Kerberos authentication, user rights, and monitoring. A sufficient size MUST be set for the security log of the domain controller. If external trust relationships exist with other domains, user authorisation data MUST be filtered and anonymised.
APP.2.2.A6 Maintaining the Operational Continuity of Active Directory (B)
All trust relationships in AD MUST be evaluated at regular intervals. The domain administrators group MUST be empty or as small as possible. Accounts that are no longer used MUST be disabled in AD. They SHOULD be deleted after a reasonable retention period has expired. All the necessary parameters of Active Directory SHOULD be kept up to date and documented comprehensibly.
APP.2.2.A7 Implementation of Secure Administration Methods for Active Directory [Process Owner] (B)
It MUST be possible to clearly trace every account to an employee. The number of service administrators and data administrators for Active Directory MUST be limited to the required minimum of trustworthy persons. The default “Administrator” account SHOULD be renamed. An “Administrator” account without privileges SHOULD be created. It MUST be ensured that the service administrator accounts are administered exclusively by members of the Services administrator group. The “Account Operators” group SHOULD be empty. Administrators SHOULD only be assigned to the “Scheme Administrators” group temporarily for the time required to change the scheme. For the groups “Organisational Administrators” and “Domain Administrators”, the two-person principle SHOULD be established for administration of the root domain. It MUST be ensured that the “Administrators” and “Domain Administrators” groups are also owners of the domain root object of the domain in question. The use of domain-local groups for controlling the read privileges of object attributes SHOULD be avoided. The recycle bin of AD SHOULD be enabled. In large organisations, an enterprise identity management solution SHOULD be used in order to ensure that the rights of all users comply with the defined specifications.
APP.2.2.A8 Configuration of Secure Channel in Windows (S)
Secure Channel SHOULD be configured in Windows according to the security requirements and the local conditions at hand. All the relevant group policy parameters SHOULD be taken into account in the process.
APP.2.2.A9 Authentication Protection When Using Active Directory (S)
The Kerberos authentication protocol SHOULD be used consistently in the Active Directory environment. If NTLMv2 is used temporarily for compatibility reasons, the migration to Kerberos SHOULD be planned and scheduled. LM authentication SHOULD be disabled. SMB data traffic SHOULD be signed. Anonymous access to domain controllers SHOULD be prevented.
APP.2.3 OpenLDAP
Target Object: Application / Order: R2
APP.2.3.A1 Planning and Selecting Back Ends and Overlays for OpenLDAP (B)
The use of OpenLDAP in an organisation MUST be carefully planned. If OpenLDAP is to be used together with other applications, the planning, configuration, and installation of applications and OpenLDAP MUST be coordinated. The version of the database used for data storage MUST be checked to ensure it is compatible. Back ends and overlays for OpenLDAP MUST be selected restrictively. It MUST be ensured that the OpenLDAP overlays are used in the correct order for this purpose. When planning OpenLDAP, the client applications to be selected and supported MUST be considered.
APP.2.3.A10 Secure Updating of OpenLDAP (S)
When performing updates, particular attention SHOULD be paid to whether the changes relate to the back ends or overlays used, or to software dependencies. If administrators use their own scripts, they SHOULD be checked to see if they work with the updated version of OpenLDAP without any problems. The configuration and access rights SHOULD be carefully checked after an update.
APP.2.3.A11 Restriction of the OpenLDAP Runtime Environment (S)
The slapd server SHOULD be restricted to a runtime directory. This directory SHOULD contain all configuration files and databases.
APP.2.3.A3 Secure Configuration of OpenLDAP (B)
Secure configuration of OpenLDAP requires a correctly configured slapd server. The client applications used MUST also be securely configured. When configuring OpenLDAP, the permissions MUST be set correctly in the operating system. The default values of all relevant OpenLDAP configuration directives MUST be checked and adapted if necessary. The back ends and overlays of OpenLDAP MUST be included in the configuration. Appropriate time and size restrictions MUST be set for searching within OpenLDAP. The configuration on the slapd server MUST be checked after each change.
APP.2.3.A4 Configuration of the Database Used by OpenLDAP (B)
The access rights for newly created database files MUST be limited to the user ID in whose context the slapd server is being run. The standard settings of the database used by OpenLDAP MUST be adapted.
APP.2.3.A5 Secure Assignment of Access Rights to OpenLDAP (B)
The global and database-specific access control lists maintained in OpenLDAP MUST be factored in correctly when using OpenLDAP. Database directives MUST take precedence over global directives.
APP.2.3.A6 Secure Authentication for OpenLDAP (B)
If the directory service is to distinguish between different users, they MUST authenticate themselves appropriately. The authentication between the slapd server and communication partners MUST be encrypted. If passwords are to be stored on the clients and servers, hashed values only MUST be used. A suitable hashing algorithm MUST be used.
APP.2.3.A8 Restrictions on Attributes in OpenLDAP (S)
The attributes in OpenLDAP SHOULD be restricted using overlays. OpenLDAP SHOULD be modified so that values in the directory service only correspond to a specific regular expression. In addition, it SHOULD be ensured with the help of overlays that selected values only exist once in the directory tree. Such restrictions SHOULD only be applied to user data.
APP.2.3.A9 Partitioning and Replication in OpenLDAP (S)
OpenLDAP SHOULD be partitioned into subtrees on different servers. In such configurations, changes made to data on one server SHOULD be replicated to the other servers. The replication mode SHOULD be selected based on the network connections and availability requirements at hand.
APP.3.1 Web Applications
Target Object: Application / Order: R2
APP.3.1 A20 Use of Web Application Firewalls (H)
Organisations SHOULD use web application firewalls (WAF). The configuration of a given WAF should be adapted to the web application it is meant to protect. The WAF's configuration SHOULD be checked after each web application update.
APP.3.1.A1 Authentication for Web Applications (B)
The IT Operation Department MUST configure web applications in such a way that users have to authenticate themselves to access protected resources. An appropriate authentication method MUST be selected for this. The selection process SHOULD be documented. The IT Operation Department MUST define appropriate thresholds for failed login attempts.
APP.3.1.A11 Secure Integration of Background Systems (S)
Access to background systems to which functions and data are outsourced SHOULD only be possible from defined IT systems via defined interfaces. When communicating across network and site boundaries, data traffic SHOULD be authenticated and encrypted.
APP.3.1.A12 Secure Configuration of Web Applications (S)
A web application SHOULD be configured in such a way that its resources and functions can only be accessed using the secured communication paths specified for this purpose. Access to resources and functions that are not required SHOULD be disabled. If this is not possible, such access SHOULD be restricted as far as possible. The following actions SHOULD be taken when configuring web applications: • Disabling unnecessary HTTP methods • Configuring character encoding • Removing security-related information from error messages and responses • Storing configuration files outside of the web root directory • Defining thresholds for access attempts
APP.3.1.A14 Protection of Confidential Data (B)
The IT Operation Department MUST ensure that access data for the web application is protected from unauthorized access on the server side using secure cryptographic algorithms. Salted hash methods MUST be used for this purpose. The files containing the source code of the web application MUST be protected against unauthorised retrieval.
APP.3.1.A21 Secure HTTP Configuration of Web Applications (S)
To protect against clickjacking, cross-site scripting, and other attacks, the IT Operation Department SHOULD set appropriate HTTP response headers. At minimum, the following HTTP headers SHOULD be used: Content-Security-Policy, Strict-Transport-Security, Content-Type, X-Content-Type-Options, and Cache-Control. The HTTP headers used SHOULD be as restrictive as possible. Cookies SHOULD always be set with the attributes secure, SameSite, and httponly.
APP.3.1.A22 Penetration Testing and Auditing (S)
Web applications SHOULD be checked for security issues at regular intervals. In particular, audits SHOULD be performed regularly. The results SHOULD be documented transparently, protected adequately, and handled confidentially. Deviations SHOULD be investigated. The results SHOULD be presented to the CISO.
APP.3.1.A4 Controlled Integration of Files and Content in Web Applications (B)
If a web application offers an upload function for files, this function MUST be restricted as far as possible by the IT Operation Department. In particular, the allowed file size, allowed file types, and allowed storage locations MUST be defined. The users allowed to use the upload function MUST be defined. Access and execution rights MUST also be set restrictively. Furthermore, it MUST be ensured that a user can save files only in the specified storage location.
APP.3.1.A7 Protection Against Unauthorised Automated Use of Web Applications (B)
The IT Operation Department MUST ensure that the web application is protected against unauthorised automated use. However, these efforts MUST take into account the impact that the protection mechanisms will have on the ability of authorised users to use the application. If the web application contains RSS feeds or other functions explicitly intended for automated use, this MUST also be taken into account when configuring the protection mechanisms.
APP.3.1.A8 System Architecture of a Web Application [Procurement Department] (S)
Security aspects SHOULD be considered early on in the planning stage. It SHOULD also be ensured that the architecture of the web application maps the exact business logic of the organisation and implements it correctly.
APP.3.1.A9 Web Application Procurement (S)
In addition to the general aspects of software procurement, the organisation SHOULD, at minimum, consider the following when procuring web applications: • Secure input validation and output encoding in the web application • Secure session management • Secure cryptographic procedures • Secure authentication procedures • Secure procedures for server-side storage of credentials • Suitable authorisation management within the web application • Sufficient logging capabilities • Regular security updates from the software's developer • Protection mechanisms against widespread attacks on web applications • Access to the source code of the web application
APP.3.2 Web Servers
Target Object: Application / Order: R2
APP.3.2.A1 Secure Web Server Configuration (B)
After the IT Operation Department has installed a web server, it MUST perform a secure basic configuration. To that end, it MUST specifically assign the web server process to a user account with minimal rights. The web server MUST also be executed in an encapsulated environment whenever this is supported by the operating system. If this is not possible, each web server SHOULD run on its own physical or virtual server. The web server service MUST be stripped of all unnecessary write permissions. Modules and functions of the web server that are not required MUST be deactivated.
APP.3.2.A10 Selecting an Appropriate Web Host (S)
If an organisation opts to use an external webhosting provider instead of operating its web server itself, the organisation SHOULD pay attention to the following points when selecting a suitable provider: • The manner in which the services are to be rendered SHOULD be contractually agreed. Security aspects SHOULD be included in writing in a service level agreement (SLA) as part of the contract. • The service provider SHOULD regularly check and service the IT systems used. The service provider SHOULD be obligated to respond promptly in case of technical problems or compromised customer systems. • The service provider SHOULD implement basic technical and organisational safeguards to protect its information domain.
APP.3.2.A11 Encryption via TLS (B)
The web server MUST provide secure encryption via TLS (HTTPS) for all connections that pass through untrusted networks. If it is necessary to use obsolete procedures for compatibility reasons, these SHOULD be limited to as few cases as possible. If an HTTPS connection is used, all content MUST be delivered via HTTPS. Mixed content MUST NOT be used.
APP.3.2.A12 Suitable Handling of Errors and Error Messages (S)
HTTP information and displayed error messages SHOULD NOT show the product name or the version of the web server used. Error messages SHOULD not reveal details regarding system information or configurations. The IT Operation Department SHOULD ensure that the web server only outputs general error messages that inform the user that an error has occurred. Each error message SHOULD contain a unique characteristic that allows administrators to trace the error. In the case of unexpected errors, it SHOULD be ensured that the web server will not remain in a state where it is vulnerable to attack.
APP.3.2.A13 Access Control for Web Crawlers (S)
Web crawler access SHOULD be regulated in accordance with the robots exclusion standard. Content SHOULD be provided with access protection to safeguard it against web crawlers that do not comply with this standard.
APP.3.2.A14 Integrity Checks and Protection Against Malware (S)
The IT Operation Department SHOULD regularly check the integrity of the configurations of the web server and the files it provides and ensure they have not been modified by attackers. The files intended for publication SHOULD be regularly checked for malware.
APP.3.2.A15 Redundancy (H)
Web servers SHOULD be designed to be redundant. The Internet connection of a web server and other IT systems (such as the web application server) SHOULD also be designed with redundancy.
APP.3.2.A16 Penetration Testing and Auditing (S)
Web servers SHOULD be checked for security issues at regular intervals. Audits SHOULD also be performed regularly. The results SHOULD be documented transparently, protected adequately, and handled confidentially. Deviations SHOULD be investigated. The results SHOULD be presented to the CISO.
APP.3.2.A18 Protection Against Denial-of-Service Attacks (H)
A web server SHOULD be monitored continuously. Furthermore, safeguards that prevent or at least mitigate DDoS attacks SHOULD be defined and implemented.
APP.3.2.A2 Protection of Web Server Files (B)
The IT Operation Department MUST protect all files on the web server (including scripts and configuration files in particular) so that they cannot be read or changed without authorisation. It MUST be ensured that web applications can only access a defined directory tree (the WWW root directory). The web server MUST be configured to serve only files located within the WWW root directory. The IT Operation Department MUST disable all unneeded functions that list directories. Confidential data MUST be protected against unauthorised access. In particular, the IT Operation Department MUST ensure that confidential files are not located in public directories of the web server. The IT Operation Department MUST regularly check whether confidential files have been stored in public directories.
APP.3.2.A20 Appointing Contact Persons [Central Administration] (S)
An organisation that maintains extensive websites SHOULD designate a contact person for them. Processes, procedures, and persons responsible for problems or security incidents SHOULD be specified. The organisation SHOULD post a contact option on its website that enables external parties to report security issues to the organisation. The organisation SHOULD define processes for handling external security reports.
APP.3.2.A3 Protecting File Uploads and Downloads (B)
All files published using the web server MUST be checked in advance for malware. A maximum size for file uploads MUST be specified. Sufficient storage space MUST be reserved for uploads.
APP.3.2.A4 Logging of Events (B)
The web server MUST log at least the following events: • Successful attempts to access resources • Failed attempts to access resources due to a lack of authorisations, unavailable resources, or server errors • General error messages The log data SHOULD be analysed regularly.
APP.3.2.A5 Authentication (B)
When clients authenticate themselves to a web server using passwords, these passwords MUST be stored in a way that is cryptographically secured and protected from unauthorised access.
APP.3.2.A7 Legal Framework Conditions for Websites [Process Owner, Central Administration, Compliance Manager] (B)
If web servers publish content or offer services for third parties, the relevant legal framework conditions MUST be observed. The organisation MUST observe the applicable telecommunication, data protection, and copyright laws.
APP.3.2.A8 Planning the Use of a Web Server (S)
The purpose of a web server and the content it provides SHOULD be planned and documented. The documentation SHOULD also describe the information or services included in the web offerings in question, along with the corresponding target groups. Appropriate persons SHOULD be put in charge of technical operations and web content.
APP.3.2.A9 Defining a Web Server Security Policy (S)
A security policy stating the required safeguards and responsibilities SHOULD be drawn up. An approach to obtaining information on current security vulnerabilities SHOULD also be defined. Furthermore, the manner in which security safeguards are to be implemented and the steps to be taken in the event of a security incident SHOULD be defined.
APP.3.3 File Servers
Target Object: Application / Order: R2
APP.3.3.A11 Using Storage Restrictions (S)
The IT Operation Department SHOULD consider setting limits (quotas) on storage space for individual users if there are multiple users on a file server. As an alternative, mechanisms of the file or operating system in question SHOULD be used that warn users or only grant write privileges to the system administrator if the hard drive capacity reaches a specific level.
APP.3.3.A12 Data Encryption (H)
The mass storage devices of a file server SHOULD be encrypted at the file system or hardware level. If hardware encryption is used, products with a certified encryption function SHOULD be used. It SHOULD be ensured that the virus protection program in use can scan encrypted data for malware.
APP.3.3.A13 Replicating Between Locations (H)
For high-availability file servers, data SHOULD be replicated appropriately across several mass storage devices. Data SHOULD also be replicated between independent file servers located at independent sites. To this end, a suitable replication mechanism SHOULD be selected by the IT Operation Department. Sufficiently accurate time services SHOULD be used and operated so that the replication can work as intended.
APP.3.3.A14 Using Error Correction Codes (S)
The IT Operation Department SHOULD use an error-detecting or error-correcting file system. Sufficient storage space SHOULD be provided for this purpose. The IT Operation Department SHOULD take into account that, depending on the method used, errors can only be detected with a certain probability and can only be removed to a limited extent.
APP.3.3.A15 Planning File Servers (B)
Before an organisation introduces one or more file servers, it SHOULD decide what the file servers will be used for and what information will be processed on them. The organisation SHOULD plan each file server function to be used, including its security aspects. Personal computers MUST NOT be used as file servers. File server storage space MUST be adequately sized. Sufficient storage reserves SHOULD also be kept available. Only mass storage designed for continuous operation SHOULD be used. The speed and connections of mass storage MUST be appropriate for its intended use.
APP.3.3.A2 Use of RAID Systems (B)
The IT Operation Department MUST define whether a RAID system should be used on a file server. Any decision against such a system MUST be documented in a transparent manner. If a RAID system is to be used, the IT Operation Department MUST decide: • What RAID level should be used • What length of time will be allowed for a RAID rebuild process • Whether to use a software or a hardware RAID Hot spare hard disks SHOULD be available in a RAID.
APP.3.3.A3 Use of Anti-Virus Programs (B)
All data MUST be scanned for malware by a virus protection program before it is stored on a file server.
APP.3.3.A6 Acquiring a File Server and Selecting a Service (S)
Appropriate file server software SHOULD be selected. The file server service SHOULD support the intended use of the file server—for example, the integration of network drives on clients, streaming of multimedia content, the transfer of boot images from diskless IT systems, or simple file transfers via FTP. Performance, storage capacity, bandwidth, and the number of people who will be using it SHOULD be considered when purchasing a file server.
APP.3.3.A7 Selecting a File System (S)
The IT Operation Department SHOULD create a requirements list and use it as a basis for evaluating the file systems of different file servers. The file system selected SHOULD meet the organisation’s standards. The file system SHOULD also provide a journaling function. Moreover, it SHOULD have a mechanism that prevents several users or applications from accessing a file with write permissions at the same time.
APP.3.3.A8 Structured Data Storage [User] (S)
A structure for storing data SHOULD be specified. Users SHOULD be informed regularly of the requirements of structured data storage. Files SHOULD only be stored on a file server in a structured manner. The types of data that can be stored locally those that can be kept on a file server SHOULD be specified in writing. Program and work files SHOULD be stored in separate directories. The organisation SHOULD regularly check compliance with the requirements for structured data storage.
APP.3.3.A9 Secure Storage Management (S)
The IT Operation Department SHOULD regularly check whether the mass storage of file servers is still working as intended. Suitable backup storage SHOULD be kept available. If a storage hierarchy (primary, secondary and tertiary storage) has been established, (partially) automated storage management SHOULD be used. If data is distributed automatically, the proper functioning of the distribution method used SHOULD be checked manually at regular intervals. At minimum, unauthorised attempts to access files and changes in access rights SHOULD be logged.
APP.3.4 Samba
Target Object: Application / Order: R2