chrisbst48/IT-Grundschutz-Compendium_2022_EN huggingface dataset:
APP.1.1 Office Products
Target Object: Application / Order: R2
APP.1.1.A10 Regulations for Software Development by End Users (S)
For software development based on Office applications (e.g. with macros), binding regulations SHOULD be established (see also APP.1.1.A2 Limiting Active Content). First, every organisation SHOULD make a policy decision as to whether or not it wants to allow in-house development of this kind by end users at all. The decision SHOULD be documented in the corresponding security policies. If in-house development is permitted, a process for handling the corresponding features of Office products SHOULD be developed for end users. Responsibilities SHOULD be clearly defined. All information pertaining to the applications created SHOULD be documented. Current versions of the regulations SHOULD be made available to and observed by all affected users in a timely manner.
APP.1.1.A11 Controlled Use of Extensions for Office Products (S)
All add-ons and extensions for Office products SHOULD be tested in the same way as new versions prior to productive use. This testing SHOULD only be carried out on isolated test systems. The tests SHOULD check if the extensions have any adverse effects on the Office products and IT systems in operation. The tests of the extensions in use SHOULD follow a defined test plan. This test plan SHOULD be designed in such a way that third parties can understand the procedure.
APP.1.1.A12 No Cloud Storage [User] (S)
The cloud storage features integrated into some Office products SHOULD be disabled as a matter of principle. All cloud drives SHOULD be disabled. All documents SHOULD be stored by users on file servers centrally managed by the organisation. Specialised applications SHOULD be used to share documents with third parties. These applications SHOULD at least encrypt the storage and transmission of data and have a suitable system for user and rights management.
APP.1.1.A13 Use of Viewer Features [User] (S)
Data from potentially unsafe sources SHOULD be automatically opened in a protected mode. Users SHOULD NOT be allowed to disable this feature. A list of trustworthy places from which content can be opened and edited directly SHOULD be defined. In the protected mode, it SHOULD NOT be possible to edit data directly. Active content such as macros and scripts SHOULD NOT be executed automatically in the protected mode. Only general navigation SHOULD be allowed. When documents are only to be viewed, appropriate viewer applications SHOULD be used if available.
APP.1.1.A14 Protection Against Subsequent Changes to Documents [User] (S)
Depending on their intended use, documents SHOULD be suitably protected against subsequent modification.
APP.1.1.A15 Use of Encryption and Digital Signatures (H)
Data that requires increased protection SHOULD only be stored and transmitted in encrypted form. Before using an encryption method integrated into an Office product, it SHOULD be checked to ensure that it offers sufficient protection. In addition, a process SHOULD be used that supports the digital signing of macros and documents.
APP.1.1.A16 Checking Document Integrity (H)
When storing or transmitting data that requires increased protection, appropriate integrity checks SHOULD be used. Cryptographic procedures SHOULD also be used for data that requires protection against manipulation.
APP.1.1.A17 Awareness of Specific Office Properties (B)
Appropriate efforts MUST be taken to make all users aware of the threat posed by active content. Appropriate efforts MUST also be taken to make all users aware of how documents from external sources are to be handled. Users SHOULD be informed about the capabilities and limits of the security functions of the software employed and the storage formats used. Users SHOULD be trained on the features they can use to protect documents from subsequent modification and editing. Users SHOULD be made aware of how to the encryption functions in Office products are to be handled.
APP.1.1.A2 Limiting Active Content (B)
The automatic execution of embedded active content MUST be deactivated. If it is nevertheless necessary to run active content, care MUST be taken to ensure that active content is only run when it comes from trusted sources. All users MUST be instructed about features that restrict active content.
APP.1.1.A3 Secure Opening of Documents from External Sources [User] (B)
All documents obtained from external sources MUST be scanned for malware before they are opened. All file formats considered problematic and those not required within an organisation MUST be prohibited. They SHOULD be blocked if possible. Technical safeguards SHOULD be implemented to enforce the scanning of documents from external sources.
APP.1.1.A6 Testing New Versions of Office Products (S)
New versions of Office products SHOULD be tested for compatibility with established tools such as macros, document templates, or organisation forms prior to productive use (see OPS.1.1.6 Software Testing and Approval). It SHOULD be ensured that important tools will continue to function as they should with each new software version. If compatibility issues are detected, appropriate solutions SHOULD be found for the tools affected.
APP.1.2 Web Browsers
Target Object: Application / Order: R2
APP.1.2.A1 Use of Basic Security Mechanisms (B)
The web browser used MUST ensure that every instance and process can only access its own resources (sandboxing). Web pages MUST be isolated from each other in independent processes, or at least in their own threads. Plug-ins and extensions MUST also be executed in isolated areas. The web browser used MUST implement the Content Security Policy (CSP). The current highest level of the CSP SHOULD be met. The browser MUST support same-origin policy and subresource integrity safeguards.
APP.1.2.A10 Using the Private Mode [User] (H)
In case of increased requirements regarding confidentiality, a web browser SHOULD be run in private mode so that no information or content will be stored permanently on the user's IT system. The browser SHOULD be configured so that local content will be deleted once the browser is closed.
APP.1.2.A11 Checking for Malicious Content (H)
The web browser SHOULD check the Internet addresses accessed by the user for potentially malicious content. The web browser SHOULD warn the user if information on malicious content is present. It SHOULD NOT be possible to establish a connection that is classified as malicious. The procedure used for checking MUST NOT infringe on provisions of data protection or the protection of classified information.
APP.1.2.A12 Two-Browser Strategy (H)
If the web browser in use has unresolved security problems, an alternative browser with a different platform SHOULD be installed as a fallback option for the user.
APP.1.2.A13 Use of DNS over HTTPS (B)
An organisation MUST check whether the browsers in use employ DNS-over-HTTPS (DoH). Whether or not the function should be used MUST be specified. If the organisation uses DNS servers as resolvers that are accessed over untrusted networks, DoH SHOULD be used. If DoH is used, the organisation MUST specify a trusted DoH server.
APP.1.2.A2 Support for Secure Communication Encryption (B)
The web browser MUST support a secure version of Transport Layer Security (TLS). Connections to web servers MUST be encrypted with TLS whenever this is supported by the web server in question. Insecure versions of TLS SHOULD be deactivated. The web browser MUST support and implement the HTTP Strict Transport Security (HSTS) security mechanism according to RFC 6797.
APP.1.2.A3 Use of Trusted Certificates (B)
If a web browser provides its own list of trusted root certificates, it MUST be ensured that only administrators can change them. If this is not possible through technical safeguards, users MUST be prohibited from changing this list. It MUST also be ensured that the web browser can revoke certificates locally. The web browser MUST comprehensively check the validity of server certificates using the public key while taking the respective validity periods into account. The web browser MUST also verify the lock status of server certificates. The certificate chain, including the root certificate, MUST be verified. The web browser MUST indicate to the user in a clear and visible manner whether communication is taking place in plain text or in an encrypted manner. The web browser SHOULD be able to show the user the server certificate in use upon request. The web browser MUST alert the user when certificates are missing, invalid, or revoked. In this case, the web browser MUST terminate the connection until the user explicitly confirms it.
APP.1.2.A6 Password Management in Web Browsers (B)
If a password manager is used in a web browser, it MUST create a direct and unique relationship between each web page and the password stored for it. The stored passwords MUST be encrypted. It MUST be ensured that the passwords stored in the password manager can only be accessed after entering a master password. Furthermore, it MUST be ensured that the authentication for password-protected access is only valid only for the current session. The IT Operation Department MUST ensure that the browser allows users to delete stored passwords.
APP.1.2.A7 Data Economy in Web Browsers [User] (S)
Cookies from third parties SHOULD be refused in web browsers. It SHOULD be possible for users to delete stored cookies. The auto-complete function for data SHOULD be deactivated. If this function is nevertheless used, the user SHOULD be able to delete the corresponding data. The user SHOULD also be able to delete the web browser's history data. If available, the web browser's synchronisation with cloud services SHOULD be deactivated. Telemetry functions and the automatic sending of crash reports, URL entries, and search entries to the browser's provider or other external parties SHOULD be disabled whenever possible. Location sharing and peripheral devices such as microphones or webcams SHOULD only be enabled for websites on which they are absolutely necessary. The browser SHOULD offer the option to configure and deactivate WebRTC, HSTS, and JavaScript.
APP.1.2.A9 Using an Isolated Web Browser Environment (H)
In case of increased protection needs, web browsers SHOULD be used that run in an isolated environment such as ReCoBS or on dedicated IT systems.
APP.1.4 Mobile Applications (Apps)
Target Object: Application / Order: R2
APP.1.4.A1 Requirements Analysis for the Use of Apps [Process Owner] (B)
During requirements analysis, risks arising from mobile use in particular MUST be considered. The organisation MUST verify that its ability to check and influence the operating system environment of mobile devices is sufficient to facilitate their secure use.
APP.1.4.A12 Secure App Removal (S)
When an app is uninstalled, the data it has stored on external systems (such as those operated by the app provider) SHOULD also be deleted.
APP.1.4.A14 Support for Additional Authentication Features for Apps (H)
Whenever possible, a second factor SHOULD be employed for user authentication in apps. Here, it SHOULD be ensured that any required sensors or interfaces are present in all the devices used. In addition, biometric procedures SHOULD take into account how resistant the corresponding authentication is to possible forgery attempts.
APP.1.4.A15 Performing Penetration Tests for Apps (H)
Before an app is approved for use, a penetration test SHOULD be performed. All communication interfaces to back-end systems, as well as the local storage of data, SHOULD be examined for possible vulnerabilities. The penetration tests SHOULD be repeated regularly and when major changes are made to the app.
APP.1.4.A16 Mobile Application Management (H)
Whenever possible, a mobile application management solution SHOULD be used for the central configuration of business apps.
APP.1.4.A3 Distributing Sensitive Apps (S)
Apps developed within an organisation and apps that process sensitive information SHOULD be distributed through the organisation's own app store or MDM solution.
APP.1.4.A5 Minimising and Checking App Authorisations [Process Owner] (B)
Security-relevant authorisation settings MUST be established so that they cannot be changed by users or apps. If this is not technically possible, the authorisation settings MUST be regularly checked and reset. Before an app is introduced in an organisation, it MUST be ensured that it only has the minimum app authorisations required for its function. Authorisations that are not absolutely necessary MUST be scrutinised and, if necessary, disabled.
APP.1.4.A7 Secure Storage of Local App Data (B)
If apps can access an organisation's internal documents, it MUST be ensured that the local data storage of the app is adequately secured. In particular, access keys MUST be stored in an encrypted form. In addition, a mobile device's operating system MUST NOT be allowed to cache confidential data in other locations.
APP.1.4.A8 Preventing Data Leaks (B)
To prevent unintended instances of apps transmitting confidential data or this data being used to create profiles of users, app communication MUST be appropriately restricted. To this end, communication SHOULD be analysed as part of the testing and approval procedure. Checks SHOULD also be carried out to determine whether an app is writing unwanted log or auxiliary files that may contain confidential information.
APP.2.1 General Directory Service
Target Object: Application / Order: R2
APP.2.1.A1 Creation of a Security Policy for Directory Services (B)
A security policy for the directory service MUST be drawn up. This policy SHOULD be in agreement with the organisation’s overall security concept.
APP.2.1.A11 Setting Up Access to Directory Services (S)
Access to a directory service SHOULD be configured according to the security policy at hand. If the directory service is used as a server on the Internet, it SHOULD be protected accordingly by a security gateway. If anonymous users are to be granted extended access rights to individual sub-areas of the directory tree, a separate user account (known as a proxy user) SHOULD be created for anonymous access. The access rights for this proxy user SHOULD be assigned in a sufficiently restrictive manner. They SHOULD also be removed completely if the account is no longer needed. To avoid inadvertently releasing sensitive information, the search function of the directory service SHOULD be appropriately limited in accordance with its intended purpose.
APP.2.1.A12 Monitoring Directory Services (S)
Directory services SHOULD be monitored and logged together with the server on which they are running.
APP.2.1.A13 Protection of Communications with Directory Services (S)
All communications with a directory service SHOULD be encrypted using SSL/TLS. The communication endpoint of the directory service server SHOULD NOT be reachable from the Internet. Exchanges of data between clients and the directory service server SHOULD be secured. The data that may be accessed SHOULD be defined. To protect the service entries in a service registry in the case of a service-oriented architecture (SOA), all requests sent to the registry SHOULD be checked to see if the user is valid.
APP.2.1.A14 Orderly Decommissioning of a Directory Service [Process Owner] (S)
When decommissioning a directory service, it SHOULD be ensured that the required rights and information continue to be sufficiently available. All other rights and information SHOULD be deleted. Furthermore, the users affected SHOULD be informed when a directory service is being decommissioned. When decommissioning individual partitions of a directory service, it SHOULD be ensured that no other partitions will be affected.
APP.2.1.A15 Migration of Directory Services (S)
In the event of a scheduled migration of directory services, a migration concept SHOULD be drawn up beforehand. The changes that have been made to a directory service scheme SHOULD be documented. Any extensive authorisations that were used to perform the directory service migration SHOULD be reset. The access rights for directory service objects on the systems that were updated to a new version or were obtained from other directory systems SHOULD be updated.
APP.2.1.A16 Creation of a Business Continuity Plan for Directory Service Failure (H)
Within the framework of contingency planning, there SHOULD be a need-based business continuity plan for directory services. Business continuity plans SHOULD be in place in case important directory service systems fail. All contingency procedures for the overall system configuration of directory service components SHOULD be documented.
APP.2.1.A2 Planning the Use of Directory Services [Data Protection Officer, Process Owner] (B)
The use of directory services MUST be planned carefully. The specific use of the directory service MUST be defined. It MUST be ensured that the directory service and all applications using it are compatible. In addition, a model consisting of object classes and attribute types MUST be developed that meets the requirements of the intended types of use. When planning the directory service, Employee Representatives and the Data Protection Officer MUST be involved. A needs-based access control policy MUST be designed for the directory service. In general, the planned directory service structure SHOULD be fully documented. Safeguards SHOULD be planned to prevent the unauthorised collection of data from the directory service.
APP.2.1.A3 Setting Up Access Authorisations for Directory Services [Process Owner] (B)
The tasks pertaining to the administration of the directory service itself and to the actual data administration MUST be clearly separated. The administrative tasks SHOULD be delegated such that overlap is avoided whenever possible. All administrative task areas and authorisations SHOULD be sufficiently documented. The data access rights of the user and administrator groups MUST be configured and implemented based on the established security policy. Should several directory service trees be merged, the resulting effective rights MUST be verified.
APP.2.1.A4 Secure Installation of Directory Services (B)
An installation concept MUST be drawn up in which administration and access authorisations will already be configured when installing the directory service.
APP.2.1.A5 Secure Configuration and Configuration Changes in Directory Services (B)
The directory service MUST be configured securely. In addition to the server, the clients (IT systems and programs) MUST be included in the secure configuration of a directory service infrastructure. If the configuration of the connected IT systems is to be changed, users SHOULD be informed in good time about the corresponding maintenance work. Backups SHOULD be performed for all affected files and directories prior to any changes to the configuration.
APP.2.1.A6 Secure Operation of Directory Services (B)
The security of the directory service MUST be maintained constantly during operation. All policies, regulations, and processes related to the operation of a directory service system SHOULD be documented. The workstations of directory service administrators MUST be sufficiently secured. Normal users MUST be prohibited from accessing any administration tools.
APP.2.1.A7 Drawing Up a Security Concept for the Use of Directory Services (S)
The directory service security concept SHOULD specify rules for all the relevant topic areas. The security policies developed on this basis SHOULD be documented in writing and communicated to directory service users.
APP.2.1.A8 Planning of Partitioning and Replication in the Directory Service (S)
The availability and protection needs of the directory service SHOULD be taken into account during partitioning. The partitioning of the directory service SHOULD be documented in writing so that it can be reconstructed manually. In order to perform replication in a timely fashion, sufficient bandwidth SHOULD be made available.
APP.2.1.A9 Selection of Suitable Components for Directory Services [Process Owner] (S)
Suitable components SHOULD be selected for the use of a directory service. A catalogue of criteria SHOULD be drawn up and used as a basis for selecting and acquiring components for the directory service. As part of the planning and design of the directory service, requirements for its security SHOULD be formulated in accordance with its intended use.
APP.2.2 Active Directory
Target Object: Application / Order: R2
APP.2.2.A1 Planning Active Directory [Process Owner] (B)
The domain functional level selected MUST be appropriate and as high as possible. The justification for this choice SHOULD be documented appropriately. An access control policy for Active Directory MUST be developed in accordance with the requirements at hand. Administrative delegations MUST be assigned restrictive, needs-based authorisations. The planned Active Directory structure, including possible scheme changes, SHOULD be documented in a comprehensible manner.
APP.2.2.A10 Secure Use of DNS for Active Directory (S)
Integrated DNS zones or the secure dynamic updating of DNS data SHOULD be used. Access to the configuration data of the DNS server SHOULD only be permitted from administrative accounts. The DNS cache on DNS servers SHOULD be protected against unauthorised changes. Access to the DNS service of the domain controllers SHOULD be restricted to the necessary minimum. Network activities related to DNS requests SHOULD be monitored. Access to the DNS data in Active Directory SHOULD be restricted to administrators using ACLs. Secondary DNS zones SHOULD be avoided. At minimum, the zone file SHOULD be protected against unauthorised access. If IPsec is being used in order to protect DNS communications, sufficient data throughput SHOULD be ensured within the network.
APP.2.2.A11 Monitoring Active Directory Infrastructure (S)
Changes at the domain level and in the overall structure of Active Directory SHOULD be monitored, logged, and evaluated.
APP.2.2.A12 Backups for Domain Controllers (S)
There SHOULD be a backup and recovery policy for domain controllers. The backup software used SHOULD be explicitly approved by the provider for use in backing up the data of domain controllers. A separate backup account with service administrator rights SHOULD be set up for the domain controllers. The number of members of the “Backup Operators” group SHOULD be restricted to the required minimum. Access to the AdminSDHolder object SHOULD be placed under special protection in order to protect the authorisations. The data of the domain controllers SHOULD be backed up at regular intervals. Here, a method that avoids legacy objects whenever possible SHOULD be used.
APP.2.2.A14 Use of Dedicated Privileged Administration Systems (H)
The administration of Active Directory SHOULD be limited to dedicated administration systems. These SHOULD be subject to particularly strong hardening based on their limited tasks.
APP.2.2.A15 Separation of Administration and Production Environments (H)
Particularly critical systems such as domain controllers and domain administration systems SHOULD be placed in a separate forest with a unilateral trust relationship towards the production forest.
APP.2.2.A2 Planning of Active Directory Administration [Process Owner] (B)
In large domains, the administrative users MUST be divided in terms of the service and data administration pertaining to Active Directory. Here, the administrative tasks MUST also be distributed in Active Directory according to a delegation model so that there is no overlap.
APP.2.2.A3 Planning of Group Policy in Windows (B)
There MUST be a concept for configuring group policies. Multiple overlaps MUST be avoided whenever possible in the group policy concept. It MUST be possible to recognise exceptions to the group policy concept in the documentation. All group policy objects MUST be protected by restrictive access rights. Secure specifications MUST be defined for the parameters in all group policy objects.