chrisbst48/IT-Grundschutz-Compendium_2022_EN huggingface dataset:
SYS.1.8.A20 Contingency Planning and Emergency Response for Storage Solutions (S)
A business continuity plan for the storage solution deployed SHOULD be drawn up. The business continuity plan SHOULD include an accurate description of the steps to take in certain emergency situations. Instructions in the form of safeguards and commands that support error analysis and error correction SHOULD be included, as well. In order to remedy errors, appropriate tools SHOULD be used. Regular drills and tests SHOULD be conducted using the business continuity plan. The data generated during the drills and tests and after an actual emergency SHOULD be deleted securely afterwards.
SYS.1.8.A21 Use of Storage Pools in Client Separation (H)
Clients SHOULD be assigned storage resources from different storage pools. In this process, a storage medium SHOULD only be assigned to one pool at a time. The logical hard disks (LUNs) generated from such a pool SHOULD only be assigned to a single client.
SYS.1.8.A22 Use of a High Availability SAN Solution (H)
A highly available SAN solution SHOULD be used. The replication mechanisms used SHOULD meet the availability requirements of the organisation in question regarding its storage solution. The configuration of the storage solution SHOULD also meet the availability requirements. Furthermore, there SHOULD be a test and consolidation system.
SYS.1.8.A23 Use of Encryption for Storage Solutions (H)
All data stored in storage solutions SHOULD be encrypted. The levels at which encryption is to be performed SHOULD be defined (regarding data in motion and data at rest). In this process, it SHOULD be ensured that the encryption along the transport channel is also relevant for replications and backup traffic.
SYS.1.8.A24 Ensuring the Integrity of the SAN Fabric (H)
In order to ensure the integrity of the SAN fabric, protocols with additional security features SHOULD be used. The security features of the following protocols SHOULD be taken into consideration and corresponding configurations SHOULD be used: • Diffie Hellman Challenge Handshake Authentication Protocol (DH-CHAP) • Fibre Channel Authentication Protocol (FCAP) • Fibre Channel Password Authentication Protocol (FCPAP)
SYS.1.8.A25 Multiple Overwrites of LUN Data (H)
In SAN environments, data SHOULD be deleted by overwriting the related storage segments of a LUN several times.
SYS.1.8.A26 Securing a SAN with Hard Zoning (H)
In order to segment SANs, hard zoning SHOULD be used.
SYS.1.8.A4 Protection of Administration Interfaces (B)
All administration and management access to storage systems MUST be restricted. It MUST be ensured that it is not possible to access administration interfaces from untrustworthy networks. Protocols that are considered secure SHOULD be used. If insecure protocols are nonetheless utilised, a separate administration network MUST be used (see NET.1.1 Network Architecture and Design).
SYS.1.8.A6 Creation of a Security Policy for Storage Solutions (S)
Based on an organisation's general security policy, a specific policy SHOULD be drawn up for storage solutions. This policy SHOULD transparently describe specifications as to how storage solutions may be planned, administered, installed, configured, and operated securely. The policy SHOULD be known to all administrators in charge of storage solutions and be integral to their work. If the policy is changed or deviations from its specifications are allowed, this SHOULD be coordinated with the CISO and documented. It SHOULD be checked regularly whether the policy is still being properly implemented. It SHOULD be updated as required. The results SHOULD be appropriately documented.
SYS.1.8.A7 Planning of Storage Solutions (S)
Before storage solutions are implemented in an organisation, a requirements analysis SHOULD be carried out. The requirements analysis SHOULD consider, among other things, the topics of performance and capacity. Based on the requirements identified, a detailed plan for storage solutions SHOULD then be drawn up. The following items SHOULD be taken into account: • Selection of manufacturers and suppliers • Decision for or against central administration systems (management systems) • Planning of the network connection • Planning of the infrastructure • Integration into existing processes
SYS.1.8.A8 Selecting an Appropriate Storage Solution (S)
The technical fundamentals of different storage solutions SHOULD be examined in detail. The impact of these technical principles on an organisation's potential use of the solutions SHOULD be examined. The options and limits of the different storage system types SHOULD be illustrated in a transparent manner for the persons in charge in the organisation. The criteria for choosing a storage solution SHOULD be documented in a transparent manner. The decision regarding the selection of a storage solution SHOULD also be documented in a transparent manner.
SYS.1.8.A9 Selection of Suppliers for a Storage Solution (S)
Based on the specified requirements an organisation's storage solution needs to meet, an appropriate supplier SHOULD be selected. The selection criteria and the decision in favour of a supplier SHOULD be documented in a transparent manner. Furthermore, maintenance and repair aspects SHOULD be documented in writing in service level agreements (SLAs). The SLAs SHOULD be unambiguous and quantifiable. The exact scheduled end of the contract with the supplier SHOULD be established in writing.
SYS.2.1 General Client
Target Object: IT system / Order: R2
SYS.2.1.A1 Secure User Authorisation (B)
In order to use a client, users MUST be authenticated by the corresponding IT system. Users MUST use a screen lock when leaving their clients running without supervision. The screen lock SHOULD be activated automatically if no action has been taken by the user for a set period of time. Successful user authentication MUST be the only way to disable a screen lock. Users SHOULD be required to log out of IT systems and applications after completing their tasks.
SYS.2.1.A10 Planning the Use of Clients (S)
Where and how clients are to be used SHOULD be planned in advance. This planning SHOULD not only address aspects typically associated directly with information security, but also operational aspects that entail requirements in the area of security. 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.2.1.A11 Procurement of Clients (S)
Before clients are procured, a requirements list SHOULD be drawn up that can be used to evaluate the products available on the market. The manufacturers of IT and operating systems SHOULD be expected to promptly provide patches for vulnerabilities throughout the planned duration of use. The systems to be procured SHOULD have a firmware configuration interface for UEFI SecureBoot and for the TPM (if available), which allows for control by the owner (organisation) and thereby facilitates self-managed operation of SecureBoot and the TPM.
SYS.2.1.A13 Access to Runtime Environments with Unmonitored Code Execution (S)
Access to runtime environments with unmonitored code execution (storage areas specifically secured by the operating system, firmware areas, etc) SHOULD only be granted to users with administrative rights. The corresponding settings in the BIOS or the UEFI firmware SHOULD be protected against unauthorised changes by a password. If control over the functions in question is delegated to the operating system, the ability to access the functions there SHOULD be restricted to users with administrative authorisations.
SYS.2.1.A14 Updates and Patches for Firmware, Operating Systems, and Applications (S)
Operating systems that are updated via a rolling release model SHOULD be avoided. Only application programs for which support is offered SHOULD be selected and installed. Operating systems, application programs, and firmware for which regular security updates are not offered MUST NOT be used.
SYS.2.1.A15 Secure Installation and Configuration of Clients (S)
Operating system components, specialised applications, and other tools to be installed SHOULD be specified. The installation and configuration of IT systems SHOULD only be performed by authorised persons (administrators or service providers bound by contract) according to a defined installation process in an installation environment. After installation and configuration have been completed, the basic settings SHOULD be checked. Provided that the installation and configuration meet the requirements of the security policy at hand, the clients SHOULD then be put into operation in the respective production environment. All installation and configuration steps SHOULD be documented in such a way that they can be understood and repeated by a competent third party.
SYS.2.1.A16 Disabling and Removing Unnecessary Components and IDs (S)
Firmware and operating system components, applications, and other tools that are installed and activated on clients SHOULD be checked after installation. Unnecessary modules, programs, services, tasks, and firmware functions (like remote maintenance) SHOULD be disabled or removed. Unnecessary runtime environments, interpreter languages, and compilers should be removed. Unnecessary user IDs SHOULD be disabled or deleted. Unnecessary interfaces and IT system hardware (like webcams) SHOULD be disabled. The reactivation of these components SHOULD be prevented. The decisions taken in this regard SHOULD be documented in a comprehensible manner.
SYS.2.1.A18 Using Encrypted Communication (S)
Communication SHOULD be protected by encryption whenever possible. Clients SHOULD use cryptographic algorithms and key lengths that conform to the current state of the art and meet the security requirements of the organisation in question. New certificates from certificate issuers SHOULD only be used after their fingerprints are checked.
SYS.2.1.A20 Protecting the Administration Process for Clients (S)
Adequate security precautions SHOULD be taken based on whether clients are administrated locally or via a network. The procedures used for administration SHOULD conform to the specifications of the applicable security policy.
SYS.2.1.A21 Preventing Unauthorised Use of Computer Microphones and Cameras (S)
Access to the microphone and camera of a client SHOULD only be available to the users themselves while they are working locally on the corresponding IT system. If a microphone or camera is not used and its misuse is to be prevented, it SHOULD be switched off, covered (camera only), disabled, or physically disconnected from the respective device whenever possible. Rules SHOULD be specified on how the cameras and microphones of clients are to be used and how corresponding rights are to be assigned.
SYS.2.1.A23 Preferences for Client-Server Services (S)
If possible, dedicated server services for exchanging information SHOULD be used and direct connections between clients avoided. If this is not possible, it SHOULD be specified which client-to-client services (often also referred to as peer-to-peer services) may be used and which information may be exchanged through them. If necessary, users SHOULD be trained in the use of such services. Direct connections between clients SHOULD be restricted to the respective LAN. Auto-discovery protocols SHOULD be restricted to those required.
SYS.2.1.A24 Dealing with External and Removable Media (S)
Interfaces to external networks SHOULD ONLY be accessible in a restricted manner. Connecting unauthorised devices or removable media to clients SHOULD be prohibited. Clients SHOULD generally be prevented from accessing removable media from untrusted sources. The unauthorised execution of programs on or from external storage media SHOULD be technically prevented. Copying unauthorised data from clients via removable drives or external interfaces SHOULD be prevented.
SYS.2.1.A26 Protection Against Exploitation of Vulnerabilities in Applications (S)
To make it more difficult to exploit vulnerabilities, ASLR and DEP/NX SHOULD be activated in operating systems and used by applications. Security functions of kernels and standard libraries, such as heap and stack protection, SHOULD be activated.
SYS.2.1.A27 Orderly Decommissioning of Clients (S)
When decommissioning a client, it SHOULD be ensured that no data is lost and no sensitive data remains. There SHOULD be an overview of the data stored on IT systems, along with the respective locations. A checklist which can be completed when decommissioning an IT system SHOULD be created. This checklist SHOULD, at minimum, include aspects of backing up data that is still needed and the subsequent secure deletion of all data.
SYS.2.1.A28 Encryption of Clients (H)
If confidential information is stored on clients, at least the sensitive files and select areas of the file system—or better yet, all storage media—SHOULD be encrypted. A separate concept SHOULD be developed for this and special care should be taken when documenting the details of the configuration. In this context, authentication (by means of passwords, PINs, tokens, etc), the storage of recovery information, the drives to be encrypted, and the write permissions to unencrypted media SHOULD be regulated. Access to the key material used MUST be adequately protected. Users SHOULD be informed of the steps they should take if they lose authentication resources.
SYS.2.1.A29 System and Client Monitoring (S)
Clients SHOULD be integrated into a suitable system monitoring concept that continuously monitors their system status and functionality while also reporting error conditions and any threshold violations to the respective operating personnel.
SYS.2.1.A3 Activation of Automatic Update Mechanisms (B)
Automatic update mechanisms MUST be activated unless other mechanisms (such as regular manual maintenance or a central software distribution system) are used for updates. If a time interval can be specified for auto-update mechanisms, there SHOULD be an automatic search for updates at least daily and they SHOULD be installed when found.
SYS.2.1.A30 Setting Up a Reference Environment for Clients (H)
A reference installation SHOULD be set up for clients in which basic configurations and all configuration changes, updates, and patches can be tested before installing them on clients. Checklists SHOULD be created for various typical and frequently recurring test cases which should be processed as automatically as possible during test runs. The test cases SHOULD take into account both the user and the operational perspective. In addition, all tests SHOULD be documented in such a way that they can be reconstructed at a later point in time.
SYS.2.1.A31 Configuring Local Packet Filters (H)
In addition to the central security gateways used, local packet filters SHOULD be used on all clients. A whitelist strategy SHOULD be chosen as the packet filter implementation strategy based on the network communication required.
SYS.2.1.A32 Use of Additional Safeguards to Protect Against Exploits (H)
Additional safeguards SHOULD be implemented on clients as explicit protection against exploits of system vulnerabilities. If necessary security safeguards cannot be implemented via operating system functions, additional suitable security safeguards SHOULD be implemented. If it is not possible to implement sustainable safeguards, other suitable (generally organisational) security safeguards SHOULD be implemented.
SYS.2.1.A33 Application Whitelisting (H)
Application whitelisting SHOULD be used to ensure that only explicitly authorised programs and scripts can be executed. The rules SHOULD be set as restrictively as possible. If explicit specification of paths and hashes is not possible, certificate-based or path rules SHOULD be used as an alternative.
SYS.2.1.A34 Encapsulation of Security-Critical Applications and Operating System Components (H)
Applications and operating system components (such as authentication or certificate verification) SHOULD be specially encapsulated or isolated from other applications and operating system components in order to prevent an attacker from accessing the operating system or other applications, as well as to prevent access from the operating system to particularly sensitive files. Particular attention SHOULD be paid to security-critical applications that work with data from insecure sources (e.g. web browsers and office communication applications).
SYS.2.1.A35 Active Administration of Root Certificates (H)
As part of the procurement and installation of clients, the root certificates required for their operation SHOULD be documented. Only the previously documented root certificates required for operation SHOULD be present on clients. Regular checks SHOULD be performed as to whether existing root certificates still comply with the respective organisation’s requirements. All certificate stores available on an IT system (e.g. UEFI certificate stores, certificate stores of web browsers) SHOULD be included in these checks.
SYS.2.1.A36 Self-Managed Use of SecureBoot and TPM (H)
On UEFI-compatible systems, the bootloader, kernel, and all required firmware components SHOULD be signed by self-controlling key material, and any key material that is not required SHOULD be removed. If the Trusted Platform Module (TPM) is not required, it SHOULD be disabled.
SYS.2.1.A37 Use of Multi-Factor Authentication (H)
Secure authentication involving multiple different factors (knowledge, possession, property) SHOULD be established for logging onto clients locally (e.g. using a password with a chip card or token).
SYS.2.1.A38 Integration into Contingency Planning (H)
Clients SHOULD be taken into account in the business continuity management process. Clients SHOULD be prioritised for restoration of service in terms of the business processes for which they are needed. At minimum, suitable business continuity safeguards SHOULD be implemented by drawing up recovery plans, generating boot media for system recovery, and securely storing passwords and cryptographic keys.
SYS.2.1.A39 Stable and Uninterruptible Power Supply [Building Services] (H)
Clients SHOULD be connected to an uninterruptible power supply (UPS). The UPS SHOULD have sufficient capacity in terms of its output power and backup time. Clients SHOULD be protected against overvoltage.
SYS.2.1.A40 Operational Documentation (H)
The performance of operational tasks on clients or groups of clients SHOULD be documented in a transparent manner with regard to who has done what and when. In particular, the documentation SHOULD make configuration changes transparent. Security-relevant responsibilities (e.g. who is authorised to install new hard disks) SHOULD also be documented. Everything that can be documented automatically SHOULD be documented automatically. The documentation SHOULD be protected from unauthorised access and loss. Security-relevant aspects SHOULD be explained and highlighted in a transparent way
SYS.2.1.A41 Use of Quotas for Local Media (H)
Consideration SHOULD be given to setting up quotas that limit the space used on local disks. As an alternative, mechanisms of the file or operating system in question should be used that warn users if the hard drive capacity reaches a specific level or only grant write privileges to the system administrator.
SYS.2.1.A42 Use of Cloud and Online Functions [User] (B)
The use of cloud and online functions of client operating systems MUST be restricted to those absolutely required. Necessary cloud and online functions SHOULD be documented. The corresponding settings of the operating system at hand MUST be checked for conformity with organisational data protection and security specifications and be configured restrictively; otherwise, such functions MUST be disabled.
SYS.2.1.A43 Local Security Policy for Clients (S)
All security-relevant settings SHOULD be configured, tested, and regularly checked as needed. To this end, security policies SHOULD be configured that take into account the recommendations of the respective operating system manufacturer and the client's default behaviour, provided that this behaviour does not contradict other requirements of IT-Grundschutz or the organisation in question. The decisions taken in this regard SHOULD be documented and justified. Security policies SHOULD be defined in any case, even if the client's default behaviour is not changed.
SYS.2.1.A44 Client Security Policy Management (S)
All client settings SHOULD be administered using a management system and configured according to the identified protection needs and the internal policies at hand. Configuration changes SHOULD be documented, justified, and coordinated with the relevant security management personnel so that they can be carried out quickly and distributed in a centralised manner. It SHOULD also be possible to trace the status of security configurations at any time.
SYS.2.1.A45 Extended Logging (H)
Client behaviour that is not directly related to security SHOULD also be logged and analysed immediately (automatically) in order to detect covert attacker activities.
SYS.2.1.A6 Using Malware Protection Programs (B)
Depending on the operating system installed and other protection mechanisms of a given client, it MUST be checked whether malware protection programs should be used. Where available, concrete statements from the operating system modules of the IT-Grundschutz Compendium on whether such virus protection is necessary MUST be considered. Protection programs on clients MUST be configured so that users cannot disable such programs or make any security-relevant changes to their settings. Protection programs MUST search for malware when files are exchanged or transmitted. All the data on clients MUST be checked regularly for malware. If a client is infected, it MUST be examined in offline mode to determine whether the detected malware has already collected confidential data, disabled any protective functions, or downloaded any code from the Internet, for example.
SYS.2.1.A8 Protecting the Boot Process (B)
The start-up procedure (boot process) of IT systems MUST be protected against manipulation. The media that may be used to boot IT systems MUST be defined. A decision SHOULD be taken as to whether and how the boot process is to be protected cryptographically. It MUST be ensured that only administrators can boot clients from anything other than the default drive, or from an external storage medium. The ability to boot IT systems from removable or external storage media MUST be restricted to administrators. The ability to change the configuration settings of boot processes MUST also be restricted to administrators. All unused functions in firmware MUST be disabled.
SYS.2.1.A9 Defining a Security Policy for Clients (S)
On the basis of an organisation's general security policy, requirements for general clients SHOULD be specified. The policy SHOULD be known to all users and all persons involved in the procurement and operation of clients and be integral to their work. The implementation of the policy's requirements SHOULD be checked at regular intervals. The results SHOULD be documented in a transparent manner.
SYS.2.2.2 Windows 8.1 Clients
Target Object: IT system / Order: R2
SYS.2.2.2.A1 Selecting a Suitable Windows 8.1 Version (B)
Before proceeding with procurement, a suitable version of Windows 8.1 MUST be selected that has all the necessary features for future use. Priority SHOULD be given to 64-bit versions that include advanced security features.
SYS.2.2.2.A10 Integration of Online Accounts into the Operating System [User] (S)
Logging into an IT system and domain SHOULD only be possible using an account of a self-operated directory service (e.g. Active Directory). The ability to log in locally SHOULD be reserved for administrators. If online accounts such as a Microsoft account or accounts from other identity management service providers are used to log in, care SHOULD be taken to ensure that the respective provider is trustworthy and that data protection is respected.
SYS.2.2.2.A11 Configuration of Synchronisation Mechanisms in Windows 8.1 (S)
The synchronisation of user data with Microsoft cloud services SHOULD be disabled completely.