chrisbst48/IT-Grundschutz-Compendium_2022_EN huggingface dataset:
ORP.4.A20 Contingency Planning for the Identity and Access Management System [IT Operation Department] (H)
The extent to which a failed identity and access management system is critical to the security of business processes SHOULD be determined. Provisions SHOULD be made to maintain operations in the event of a failed identity and access management system. In particular, the access control policy specified in the contingency concept at hand SHOULD still be applicable if the identity and access management system has failed.
ORP.4.A21 Multi-Factor Authentication [IT Operation Department] (H)
Secure multi-factor authentication (e.g. using cryptographic certificates, chip cards, or tokens) SHOULD be used for authentication.
ORP.4.A22 Regulating Password Quality [IT Operation Department] (B)
Secure passwords of suitable quality MUST be chosen in line with their intended use and protection requirements. Passwords MUST be sufficiently complex so that they are difficult to guess. Passwords MUST NOT be so complex that users cannot utilise them regularly with a reasonable amount of effort.
ORP.4.A23 Regulating Password-Processing Applications and IT Systems [IT Operation Department] (B)
IT systems or applications SHOULD ONLY prompt users to change their password with a valid reason. Changes based on the passage of time alone SHOULD be avoided. Safeguards MUST be taken to detect compromised passwords. If this is not possible, consideration SHOULD be given to whether passwords can be changed at certain intervals in spite of the related disadvantages. Default passwords MUST be replaced by sufficiently strong passwords, and pre-defined IDs MUST be changed. It SHOULD be ensured that IT systems fully check the possible password length. After a password is changed, the old password MUST NOT be used again. Passwords MUST be stored as securely as possible. In cases involving IDs for technical users, service accounts, interfaces, or similar elements, a password change SHOULD be carefully planned and, if necessary, coordinated with the persons in charge of the application in question. When providing authentication in networked systems, passwords MUST NOT be transmitted unencrypted over insecure networks. When passwords are transmitted on an intranet, they SHOULD be encrypted. In case of unsuccessful login attempts, the system in question SHOULD not indicate that the password or user ID is wrong.
ORP.4.A24 Dual Control for Administrative Activities [IT Operation Department] (H)
Administrative activities SHOULD require the involvement of two persons. If multi-factor authentication is required, the factors SHOULD be distributed between the two persons. Passwords SHOULD be split into two parts and issued to each of the two persons.
ORP.4.A3 Documentation of User IDs and Rights Profiles [IT Operation Department] (B)
The user IDs, user groups, and rights profiles that have been approved and created MUST be documented. The documentation of authorised users, user groups, and rights profiles MUST be examined regularly to see if it reflects the rights actually assigned to the users and profiles, and if the rights granted still meet the security requirements and are appropriate for the current tasks of the corresponding users. The documentation MUST be protected against unauthorised access. If the documentation is made available in electronic form, it SHOULD be integrated into a backup procedure.
ORP.4.A4 Distribution of Tasks and Separation of Roles [IT Operation Department] (B)
The tasks and functions defined as incompatible by an organisation (see module ORP.1 Organisation) MUST be separated by its identity and access management system.
ORP.4.A5 Assignment of Site Access Rights [IT Operation Department] (B)
The site access rights that are to be granted to or withdrawn from certain people in certain roles MUST be defined. The issue and withdrawal of means of access such as chip cards MUST be documented. If site access resources have been compromised, they MUST be replaced. Persons with site access rights SHOULD be trained in the proper use of site access resources. Authorised persons SHOULD be blocked temporarily if they are to be absent for a longer period of time.
ORP.4.A6 Assignment of System Access Rights [IT Operation Department] (B)
The system access rights that are to be granted to or withdrawn from certain people in certain roles MUST be defined. If system access resources like chip cards are used, their issue and withdrawal MUST be documented. If system access resources have been compromised, they MUST be replaced. Persons with system access rights SHOULD be trained in the proper use of system access resources. Authorised persons SHOULD be blocked temporarily if they are to be absent for a longer period of time.
ORP.4.A7 Assignment of Data Access Rights [IT Operation Department] (B)
The data access rights that are to be granted to or withdrawn from certain people in certain roles MUST be defined. If data access resources like chip cards or tokens are used, their issue and withdrawal MUST be documented. Users SHOULD be trained in the proper use of chip cards or tokens. Authorised persons SHOULD be blocked temporarily if they are to be absent for a longer period of time.
ORP.4.A8 Provisions Governing the Use of Passwords [User, IT Operation Department] (B)
Organisations MUST regulate the use of passwords in a binding manner (see also ORP.4.A22 Regulating Password Quality and ORP.4.A23 Regulating Password-Processing Applications and IT Systems). In doing so, they MUST consider whether passwords are to be used as the sole authentication method, or whether other authentication features or methods may be used in addition to or instead of passwords. Passwords MUST NOT be used for multiple purposes. A separate password MUST be used for each IT system or application. Passwords that are easy to guess or are kept in common password lists MUST NOT be used. Passwords MUST be kept secret. They MUST ONLY be known by the respective users. When entering their passwords, users MUST ensure that no one else is watching. Passwords MUST NOT be stored on programmable function keys on keyboards or mice. Passwords MUST ONLY be written down in case of an emergency. They MUST then be stored securely. The use of a password manager SHOULD be considered. If password managers have features or plug-ins that synchronise passwords via third-party online services or otherwise transmit passwords to third parties, these features or plug-ins MUST be disabled. Passwords MUST be changed if it is suspected or discovered that they have become known to unauthorised persons.
ORP.4.A9 Identification and Authentication [IT Operation Department] (B)
Access to all IT systems and services MUST be protected by appropriate identification and authentication of users, services, and IT systems. Pre-configured authentication resources MUST be changed before being put into production use.
ORP.5 Compliance Management
Target Object: Information domain/generic aspects / Order: R3
ORP.5.A1 Identification of Framework Conditions [Central Administration, Top Management] (B)
All statutory, contractual, and additional provisions that affect information security management MUST be identified and documented. The statutory, contractual, and additional provisions that are relevant to an organisation's individual departments SHOULD be presented in detail in a structured overview. This documentation MUST be kept up to date.
ORP.5.A2 Compliance with Framework Conditions [Supervisor, Central Administration, Top Management] (B)
Requirements identified as security-relevant MUST be incorporated when planning and designing business processes, applications, and IT systems, and when acquiring new components. Managers who have a statutory responsibility for their organisation MUST ensure its compliance with statutory, contractual, and additional requirements. The responsibilities and authorities regarding compliance with these provisions MUST be defined. Suitable safeguards MUST be identified and implemented in order to prevent violations of relevant requirements. If violations are identified, appropriate corrective measures MUST be taken in order to ensure compliance.
ORP.5.A4 Design and Organisation of Compliance Management [Top Management] (S)
A process for identifying all relevant statutory, contractual, and additional provisions that impact information security management MUST be established within organisations. Suitable processes and organisational structures SHOULD be established to ensure an overview of the various statutory requirements for the individual areas of a given organisation based on its identification of and compliance with the legal framework at hand. Persons responsible for compliance management SHOULD be appointed for this purpose. An organisation's Compliance Manager and Chief Information Security Officer (CISO) SHOULD exchange information on a regular basis. They SHOULD integrate security requirements into compliance management, translate security-related requirements into security safeguards, and monitor their implementation together.
ORP.5.A5 Granting Exceptions [Supervisor, Chief Information Security Officer (CISO)] (S)
If it is necessary to deviate from regulations in a particular case, the exception SHOULD be justified and approved by an authorised body after a risk assessment. There SHOULD be an approval procedure for granting exceptions. An overview of all exemptions granted SHOULD be established and maintained. An appropriate procedure for documentation and a corresponding review process SHOULD be established. All exceptions SHOULD be granted for a limited period.
ORP.5.A8 Regular Reviews of Compliance Management (S)
A procedure SHOULD be established for regular checking of the efficiency and effectiveness of compliance management and the resulting requirements and safeguards (see also DER.3.1 Audits and Revisions). Regular examination of whether a given organisational structure and processes for compliance management are appropriate SHOULD be carried out.
SYS.1.1 General Server
Target Object: IT system / Order: R2
SYS.1.1.A1 Appropriate Installation (B)
Servers MUST be operated in locations that may only be accessed by authorised persons. Servers MUST therefore be set up and installed in data centres, computer rooms, or lockable server rooms (see the corresponding modules in the INF Infrastructure layer). Servers MUST NOT be used as personal computers. IT systems used as workstations MUST NOT be used as servers.
SYS.1.1.A10 Logging (B)
In general, all security-relevant system events MUST be logged, including the following at minimum: • System starts and reboots • Successful and failed login attempts (operating system and application software) • Failed authorisation checks • Blocked data flows (violations of ACLs or firewall rules) • Creation of or changes to users, groups, and authorisations • Security-relevant error messages (e.g. hardware defects, exceeded capacity limits) • Warnings from security systems (e.g. virus protection)
SYS.1.1.A11 Defining a Security Policy for Servers (S)
On the basis of an organisation's general security policy, the requirements for servers SHOULD be specified in a separate security policy. This policy SHOULD be known to all administrators and other persons involved in the procurement and operation of servers and be integral to their work. The implementation of the policy's requirements SHOULD be checked at regular intervals. The results SHOULD be appropriately documented.
SYS.1.1.A12 Planning the Use of Servers (S)
Each server system SHOULD be suitably planned. In doing so, the following points SHOULD be taken into account at minimum: • Selection of the hardware platform, operating system, and application software • Hardware capacity (performance, memory, bandwidth, etc) • Type and number of communication interfaces • Power consumption, thermal load, space requirements, and structural shape • Realisation of administrative access (see SYS.1.1.A5 Protection of Administration Interfaces) • User access • Realisation of logging (see SYS.1.1.A10 Logging) • Realisation of system updates (see SYS.1.1.A7 Updates and Patches for Operating Systems and Applications) • Integration into system and network management, backups, and protection systems (virus protection, IDS, etc) All decisions taken in the planning phase SHOULD be documented in such a way that they can be understood at any given future point in time.
SYS.1.1.A13 Procurement of Servers (S)
Prior to procuring one or more servers, a requirements list SHOULD be drawn up that can be used to evaluate the products available on the market.
SYS.1.1.A15 Stable and Uninterruptible Power Supply [Building Services] (S)
Every server SHOULD be connected to an uninterruptible power supply (UPS).
SYS.1.1.A16 Secure Basic Configuration of Servers (S)
The basic settings of servers SHOULD be checked and, where necessary, adapted to the specifications of the security policy at hand. Clients SHOULD only be connected to the Internet after the installation and configuration have been completed.
SYS.1.1.A19 Configuring Local Packet Filters (S)
Based on a set of rules, existing local packet filters SHOULD be designed to limit incoming and outgoing communications to the necessary communication partners, communication protocols, ports, and interfaces. The identity of remote systems and the integrity of corresponding connections SHOULD be protected cryptographically.
SYS.1.1.A2 User Authentication on Servers (B)
Authentication methods adequate for the protection needs at hand MUST be used when users and services log into servers. This SHOULD be taken into account for administrative access in particular. Whenever possible, centralised, network-based authentication services SHOULD be used.
SYS.1.1.A21 Operational Documentation for Servers (S)
Operational tasks that are carried out on a server SHOULD be clearly documented in terms of what has been done, when, and by whom. In particular, the documentation SHOULD make configuration changes transparent. Security-relevant responsibilities, such as who is authorised to install new hard disks, SHOULD be documented. Everything that can be documented automatically SHOULD be documented automatically. The documentation SHOULD be protected against unauthorised access and loss.
SYS.1.1.A22 Integration into Contingency Planning (S)
Servers SHOULD be taken into account in a business continuity management process. To this end, the contingency requirements for the system in question SHOULD be determined and appropriate contingency procedures implemented—for example, by drawing up recovery plans or securely storing passwords and cryptographic keys.
SYS.1.1.A23 Monitoring Systems and Servers (S)
Server systems SHOULD be integrated into an appropriate system monitoring concept. The status and functionality of these systems and the services operated on them SHOULD be continuously monitored. Error conditions and defined thresholds that are exceeded SHOULD be reported to the operating personnel.
SYS.1.1.A24 Security Checks for Servers (S)
Servers SHOULD be subjected to regular security tests to check their compliance with the applicable security requirements and identify possible vulnerabilities. In particular, these security tests SHOULD be performed on servers with external interfaces. To prevent indirect attacks via infected systems in an organisation’s own network, internal server systems SHOULD also be checked accordingly in defined cycles. Whether the security checks can be realised automatically—by means of suitable scripts, for example—SHOULD be examined.
SYS.1.1.A25 Controlled Decommissioning of a Server (S)
When decommissioning a server, it SHOULD be ensured that no important data that might still be present on the storage media is lost and that no sensitive data remains. There SHOULD be an overview of the data stored in each location on the server. Furthermore, it SHOULD be ensured that services offered by the server will be taken over by another server when necessary. A checklist SHOULD be created that is to be completed when decommissioning a server. This checklist SHOULD at least include aspects related to backing up data, migrating services, and subsequently deleting all data in a secure manner.
SYS.1.1.A27 Host-Based Attack Detection (H)
Host-based attack detection systems (also referred to as host-based intrusion detection systems, IDS, or intrusion prevention systems, IPS) SHOULD be used to monitor system behaviour for abnormalities and misuse. The IDS/IPS mechanisms used SHOULD be appropriately selected, configured, and thoroughly tested. If an attack has been detected, the operating personnel SHOULD be alerted in an appropriate manner. Using operating system mechanisms or suitable additional products, changes made to system files and configuration settings SHOULD be checked, restricted, and reported.
SYS.1.1.A28 Increasing Availability Through Redundancy (H)
Server systems with high availability requirements SHOULD be protected adequately against failures. At minimum, suitable redundancies SHOULD be available and maintenance contracts concluded with the suppliers. Whether high-availability architectures with automatic failover (across various sites, if necessary) are required in the case of very high requirements SHOULD be checked.
SYS.1.1.A30 One Service per Server (H)
Depending on the threat landscape at hand and the protection needs of services, only one service SHOULD be operated on each server.
SYS.1.1.A31 Application Whitelisting (H)
In case of high protection needs, it SHOULD be ensured by means of application whitelisting that only the programs allowed are executed. Complete paths and directories SHOULD be defined from which these programs can be executed. At the same time, individual applications SHOULD explicitly be allowed to be executed as an alternative.
SYS.1.1.A33 Active Administration of Root Certificates (H)
As part of the procurement and installation of a server, the root certificates that are required for operation of the server SHOULD be documented. Only the previously documented root certificates required for operation SHOULD be present on the server. Regular checks SHOULD be performed as to whether the existing root certificates still comply with the respective organisation’s requirements. All certificate stores on the IT system SHOULD be included in these checks.
SYS.1.1.A34 Hard Disk Encryption (H)
If there is a need for increased protection, a server's storage media should be encrypted using a product or procedure that is considered secure. This SHOULD also apply to virtual machines containing production data. A TPM SHOULD not be the only key protection. The recovery password SHOULD be stored in an appropriate and secure location. In case of very high requirements (e.g. regarding confidentiality), full volume or full disk encryption SHOULD be used.
SYS.1.1.A35 Drawing Up and Maintaining an Operating Manual (S)
An operating manual SHOULD be drawn up. It SHOULD document all the rules, requirements, and settings that are necessary in operating servers. There SHOULD be a specific operating manual for every type of server. These operating manuals SHOULD be updated at regular intervals. Operating manuals SHOULD be protected against unauthorised access. Operating manuals SHOULD be available in emergencies.
SYS.1.1.A36 Protecting the Boot Process (H)
A server's boot loader and operating system kernel SHOULD be checked by self-controlled key material signed upon system start in a trusted chain (secure boot). Unnecessary key material SHOULD be removed.
SYS.1.1.A5 Protection of Interfaces (B)
It MUST be ensured that only specified removable storage media and other devices can be connected to servers. All interfaces that are no longer needed must be disabled.
SYS.1.1.A6 Disabling Unnecessary Services (B)
All unnecessary services and applications—particularly network services—MUST be disabled or uninstalled. All unused functions in firmware MUST also be disabled. On servers, the disk space allotted to both individual users and applications SHOULD be restricted appropriately. The decisions taken in this regard SHOULD be documented in a way that makes it clear which configuration and software equipment was chosen for servers.
SYS.1.1.A9 Using Anti-Virus Programs on Servers (B)
Whether virus protection programs can and should be used MUST be checked depending on the operating system installed, the services provided, and other existing protection mechanisms of the server in question. Where available, concrete statements from the relevant operating system modules of the IT-Grundschutz Compendium on whether virus protection is necessary MUST be considered.
SYS.1.2.2 Windows Server 2012
Target Object: IT system / Order: R2
SYS.1.2.2.A1 Planning of Windows Server 2012 (B)
The use of Windows Server 2012 MUST be planned carefully prior to installation. The hardware requirements MUST be checked prior to procurement. A justified and documented decision MUST be taken for a suitable edition of Windows Server 2012. The purpose of the server and its integration into Active Directory MUST be specified. The use of cloud services integrated into the operating system MUST be considered and planned as a matter of principle. If they are not required, the configuration of Microsoft accounts on the server MUST be blocked.
SYS.1.2.2.A11 Attack Detection in Windows Server 2012 (H)
Security-relevant events in Windows Server 2012 SHOULD be collected and analysed in a central location. Encrypted partitions SHOULD be blocked after a defined number of decryption attempts.
SYS.1.2.2.A12 Redundancy and High Availability in Windows Server 2012 (H)
The availability requirements that can be met or supported with the help of operating system functions such as Distributed File System (DFS), ReFS, failover clusters, network load balancing, or NIC teaming (LBFO) SHOULD be reviewed. For branch locations, BranchCache SHOULD be enabled.
SYS.1.2.2.A14 Shutting Down Encrypted Servers and Virtual Machines (H)
To protect encrypted data, servers that are not required (including virtual machines) SHOULD always be shut down. This SHOULD occur automatically whenever possible. Data encryption SHOULD require an interactive step or at least be documented in the security log.
SYS.1.2.2.A2 Secure Installation of Windows Server 2012 (B)
Server roles, features, and functions beyond those required MUST NOT be installed. If it is sufficient from a functional scope perspective, the server core variant MUST be installed. Otherwise, reasons why the server core variant is not sufficient MUST be cited. Servers MUST already be updated to a current patch status during the installation.
SYS.1.2.2.A3 Secure Administration of Windows Server 2012 (B)
All administrators responsible for a server system MUST have training in the security-relevant aspects of administering Windows Server 2012. Web browsers on the server MUST NOT be used for surfing the Internet.
SYS.1.2.2.A4 Secure Configuration of Windows Server 2012 (S)
A single server SHOULD NOT fulfil several essential functions or roles; they should be suitably divided. Prior to commissioning, a system SHOULD be fundamentally hardened. To this end, function-specific security templates for the entire organisation in question SHOULD be created, maintained, and rolled out to the servers. Internet Explorer SHOULD only be used in its enhanced security configuration and enhanced protected mode on a server.
SYS.1.2.2.A5 Protection Against Malware on Windows Server 2012 (S)
Except for IT systems running Windows Server 2012 that are operated as stand-alone devices without any network connection or removable media, an anti-virus protection program SHOULD be installed prior to establishing an initial connection to the Internet or removable media. The applicable malware protection concept SHOULD call for full scans of all hard drives on a regular basis. Alarms SHOULD be configured that will alert the responsible administrators when viruses are found.