chrisbst48/IT-Grundschutz-Compendium_2022_EN huggingface dataset:
SYS.2.2.2.A12 Secure Central Authentication of Windows Networks (S)
In Windows-only networks, only Kerberos SHOULD be used for central authentication for Single Sign On (SSO). A group policy SHOULD prevent the use of older protocols. The protection of the Local Credential Store (LSA) SHOULD be activated (PPL, Protected Mode Light). The storage of LAN Manager hash values when changing passwords SHOULD be disabled based on a group policy. The monitoring settings SHOULD be aligned carefully with the requirements of the information domain in question together with the server components of DirectAccess. Client-side logging SHOULD be ensured.
SYS.2.2.2.A13 Connection of Windows 8.1 to the Microsoft Store (S)
The ability to install apps from the Microsoft Store SHOULD be disabled if it is not needed.
SYS.2.2.2.A14 Application Control Using Software Restriction Policies and AppLocker (H)
Applications in paths for which users have write privileges SHOULD be prevented from being executed by software restriction policies (SRP) or AppLocker. In a domain-based network, AppLocker and SRP GPO SHOULD ONLY be managed centrally by means of Group Policy Objects for each user and user group. AppLocker SHOULD be used in a whitelist approach, meaning that all applications that are not explicitly allowed SHOULD be prohibited. Preference SHOULD be given to rules based on the application signatures of defined publishers. Attempted violations of the rules SHOULD be logged and evaluated appropriately. For clients with particularly high security requirements, AppLocker SHOULD prevent the execution of any unapproved applications (instead of merely logging them). The SRP and AppLocker rules SHOULD be tested on a test system or by means of operation in monitoring mode before being used on a production system.
SYS.2.2.2.A15 File System Encryption Using EFS (H)
In case of increased protection needs, file systems SHOULD be encrypted. If the Encrypting File System (EFS) is used in this regard, a complex password SHOULD be used to protect the data encrypted using EFS. Files encrypted with EFS SHOULD also be protected by restrictive access rights. The recovery agent SHOULD be a dedicated account and not the administrator account. The private key of this account SHOULD be outsourced to an external storage medium, stored securely, and removed from the corresponding system. In this context, backups of all private keys SHOULD be created. When using EFS with local user accounts, the registry SHOULD be encrypted using syskey. Users SHOULD be trained in the correct use of EFS.
SYS.2.2.2.A16 Use of Windows PowerShell (H)
If Windows PowerShell (WPS) is not required, it SHOULD be uninstalled. It SHOULD be considered that in Windows 8.1, the PowerShell script environment may only be removed by uninstalling the .NET framework along with it. Alternatively, only administrators (local and domain) SHOULD be permitted to execute WPS files. The process of logging write-only and read-only access to the Windows PowerShell profile SHOULD be activated and the logs checked regularly. The execution of Windows PowerShell scripts SHOULD be restricted with the command “Set-Execution Policy AllSigned” in order to at least prevent any accidental execution of scripts without a signature.
SYS.2.2.2.A17 Secure Use of the Maintenance Centre (H)
A security policy SHOULD define how the users utilise the Maintenance Centre. The settings for “Call up latest troubleshooting from the Windows Online Service for troubleshooting”, “Send error reports”, “Send data on computer configuration at regular intervals to Microsoft”, “Windows backup”, “Program for user-friendliness” and “Troubleshooting – other settings” SHOULD be disabled in Windows 8.1.
SYS.2.2.2.A18 Activation of the Last Access Time Stamp (H)
If a security concept is created for an IT system running Windows 8.1, it SHOULD be checked whether the last access time stamp in the file system can be activated to facilitate analysis of misuse of the system. The analysis SHOULD take into account possible effects of this setting, such as performance aspects or resulting limitations in incremental backups.
SYS.2.2.2.A19 Use of Login Information Management (H)
A policy SHOULD define whether or not storing access data in the vault is permitted. If it is not, doing so SHOULD be technically impossible.
SYS.2.2.2.A2 Defining a Login Procedure for Windows 8.1 (B)
Depending on the security requirements at hand, it MUST be decided whether other mechanisms such as PINs are to be allowed in addition to the conventional login process using a password.
SYS.2.2.2.A20 Security During Remote Access Using RDP (H)
The effects on the configuration of the local firewall SHOULD be taken into account when planning remote assistance procedures. The group of users authorised for remote desktop access SHOULD be specified in a corresponding policy and be assigned the corresponding user rights. Remote assistance SHOULD only be provided after explicit invitation via EasyConnect or on the basis of an invitation file. If an invitation is stored in a file, the file SHOULD be password-protected. In every case, the user currently logged in SHOULD have to agree explicitly to starting a session. The maximum validity of an invitation SHOULD be of an appropriate duration. Strong encryption SHOULD also be used (128-bit, “highest level” setting). Furthermore, automatic password logins SHOULD be disabled. It SHOULD be checked whether diversions of the cache, printers, file repository, and smartcard connections are necessary. If they are not, they SHOULD be disabled. Unless remote control mechanisms are used, they SHOULD be completely disabled.
SYS.2.2.2.A21 Use of File and Registry Virtualisation (H)
It SHOULD be checked whether the operation of legacy applications that require write privileges for critical system folders or registry keys or have to be executed with administrator rights is still required. If this is the case, a strategy SHOULD be developed to replace the legacy applications that are still needed with secure alternatives. Until the legacy applications are replaced, it SHOULD be examined whether the Windows techniques “File Virtualisation” and “Registry Virtualisation” can be used to secure these applications. Registry virtualisation SHOULD only be able to access the necessary registry keys.
SYS.2.2.2.A3 Use of Virus Protection Programs with Windows 8.1 (B)
Unless equivalent or higher-order safeguards have been implemented to protect an IT system from malware, an anti-virus program must be used on Windows 8.1 clients.
SYS.2.2.2.A4 Procurement of Windows 8.1 (S)
When procuring Windows 8.1 or corresponding hardware for a Windows 8.1 system, the applicable Windows Hardware Certification requirements SHOULD be taken into account. Furthermore, the systems to be procured SHOULD have a firmware configuration interface for UEFI SecureBoot and, if available, for the TPM, which enables control by the owner. In addition, an appropriate licensing model SHOULD be selected.
SYS.2.2.2.A5 Local Security Policy for Windows 8.1 (S)
All security-relevant settings SHOULD be configured, tested, and checked regularly as needed using appropriate security policies. The distribution of security settings to several Windows 8.1 clients SHOULD be performed in accordance with the specific circumstances of the organisation in question.
SYS.2.2.2.A7 Use of Windows User Account Control (S)
In order to support restrictive rights assignment, User Account Control (UAC) SHOULD be enabled. For standard users, it SHOULD be defined that password prompts will be rejected automatically for higher rights. For administrator accounts, a balance between user-friendliness and security SHOULD be achieved when configuring UAC. This decision SHOULD be documented and the corresponding settings SHOULD be configured. It SHOULD be checked regularly whether the corresponding rights are still required and whether they should be adapted or withdrawn accordingly.
SYS.2.2.2.A8 No Use of the Homegroup Feature [User] (S)
Clients SHOULD NOT offer services such as file or printer sharing. A security policy or Group Policy Object (GPO) with the setting “Prevent the computer from joining a homegroup” SHOULD apply to all clients. If the feature is being used for internal reasons, the users SHOULD be trained in handling the approvals the homegroup.
SYS.2.2.2.A9 Data Protection and Data Economy in Windows 8.1 Clients [User] (S)
If Microsoft accounts are created for users, only the personal information absolutely required SHOULD be entered. The SmartScreen feature, which checks files and web content downloaded from the Internet and transmits personal data to Microsoft in the process under certain circumstances, SHOULD be disabled. Before an application or app is approved for use within an organisation, the data it automatically sends to the Microsoft cloud SHOULD be checked carefully. Applications SHOULD be configured in such a way that no sensitive data is transmitted. Apps that transmit data to third parties in an unwanted or unnecessarily extensive way SHOULD NOT be used.
SYS.2.2.3 Windows 10 Clients
Target Object: IT system / Order: R2
SYS.2.2.3.A1 Planning the Use of Cloud Services for Windows 10 (B)
Since Windows 10-based devices are closely intertwined with the cloud services of Microsoft, it MUST be strategically determined before their use which included cloud services should or may be used and to what extent.
SYS.2.2.3.A11 Protection of Login Information in Windows 10 (S)
If the enterprise version of Windows 10 is installed directly (natively) on a hardware system, Virtual Secure Mode (VSM) SHOULD be enabled. In addition, Windows Defender Credential Guard SHOULD be enabled to thwart attacks on the authentication tokens and hashes stored in the system. If this is not possible, the local security authority (LSA) credential protection SHOULD be activated (Protected Process Light, PPL). Network logins from local accounts SHOULD be prohibited.
SYS.2.2.3.A12 File and Share Authorisation in Windows 10 (S)
Access to files and folders on a local system and to network shares SHOULD be configured in accordance with an authorisation and access concept. The standard administrative approvals on the system SHOULD also be taken into account. Users' write privileges SHOULD be restricted to a defined area in the file system. In particular, users SHOULD not be granted write privileges to folders of the operating system or of installed applications.
SYS.2.2.3.A13 Using the SmartScreen Function (S)
The SmartScreen feature, which checks files and web content downloaded from the Internet and transmits personal data to Microsoft in the process under certain circumstances, SHOULD be disabled.
SYS.2.2.3.A14 Use of the Voice Assistant Cortana [User] (S)
Cortana SHOULD be disabled.
SYS.2.2.3.A15 Use of Synchronisation Mechanisms in Windows 10 (S)
The synchronisation of user data with Microsoft cloud services and the process of sharing WLAN passwords SHOULD be disabled completely.
SYS.2.2.3.A16 Connection of Windows 10 to the Microsoft Store (S)
The use of the Microsoft Store SHOULD be checked and evaluated with respect to its compatibility with organisations' data protection and security regulations. The general installation of apps in Windows 10 is not dependent on a connection to the Microsoft Store, so it SHOULD be disabled if it is not needed.
SYS.2.2.3.A17 No Storage of Data for Automatic Login (S)
Storing passwords, certificates, and other information for automatic logins to websites and IT systems SHOULD NOT be allowed.
SYS.2.2.3.A18 Use of Windows Remote Support (S)
The effects on the configuration of the local firewall SHOULD be taken into account when planning Windows remote support procedures (this does not refer to RDP). Remote support SHOULD only be performed following an explicit invitation. When storing an invitation in a file, the file SHOULD be protected by a password. In every case, the user currently logged in SHOULD have to agree explicitly to starting a session. An invitation for remote support SHOULD have an appropriate maximum duration. If this service is not used, it SHOULD be disabled completely.
SYS.2.2.3.A19 Security During Remote Access Using RDP [User] (S)
The effects on the configuration of the local firewall SHOULD be taken into account when planning remote access. The group of users authorised for remote desktop access (RDP) SHOULD be specified by assigning the corresponding user rights. In complex infrastructures, it SHOULD only be possible to reach an RDP target system via an intermediate RDP gateway. In order to use RDP, a check SHOULD ensure that the following convenience functions are in accordance with the protection needs of the target system: • The use of the cache • The integration of printers • The integration of removable media and network drives • The use of file repositories and smartcard connections If the use of remote desktop access is not planned, it SHOULD be disabled completely. The cryptographic protocols and algorithms deployed SHOULD comply with an organisation's internal specifications.
SYS.2.2.3.A2 Selecting and Procuring a Suitable Windows 10 Version (B)
The functional scope and functional changes included in a given Windows 10 version MUST be selected based on the identified protection needs and the purpose of use at hand. The feasibility of the required safeguards MUST be considered in the selection process. Based on the results of this review, the established procurement process MUST be extended to include the selection of a corresponding licence model and “service branches” (CB, CBB, or LTSC).
SYS.2.2.3.A20 Use of User Account Control (UAC) for Privileged Accounts (S)
For privileged accounts, the configuration parameters of User Account Control (UAC) SHOULD be set with an appropriate balance between user-friendliness and level of security. The decisions regarding the configuration parameters to be used SHOULD be documented. In addition, the related documentation SHOULD include all accounts with administrator rights. Regular checks SHOULD be carried out to determine whether the ability to extend rights is necessary.
SYS.2.2.3.A21 Use of the Encrypting File System (H)
Since the Encrypting File System (EFS) protects the keys used with the passwords of user accounts, secure passwords SHOULD be used. In addition, restrictive access rights SHOULD protect files that are encrypted using EFS. The recovery agent SHOULD be a dedicated account and not the administrator. In this context, the private key of this account SHOULD be secured and removed from the system. Backups of all private keys SHOULD be created. When using EFS with local user accounts, the local password memories SHOULD be encrypted by means of syskey. Windows Defender Credential Guard can also be used as an alternative. Users SHOULD be trained in the correct use of EFS.
SYS.2.2.3.A22 Use of Windows PowerShell (H)
PowerShell and WPS files SHOULD ONLY be executed by administrators. The execution of PowerShell SHOULD be logged centrally and the logs SHOULD be monitored. The execution of PowerShell scripts SHOULD be restricted using the command Set-Execution Policy AllSigned to prevent any accidental execution of unsigned scripts.
SYS.2.2.3.A23 Advanced Protection of Login Information in Windows 10 (H)
SecureBoot SHOULD be used on UEFI-based systems, and the status of the protected mode for the LSA credential store SHOULD be monitored during system startup (see also SYS.2.2.3.A11 Protection of Login Information in Windows 10). If remote maintenance of clients is intended using RDP, the “restrictedAdmin” option for RDP SHOULD be used for deployments of Windows 10 in domains with the functional level 2012 R2 or higher.
SYS.2.2.3.A24 Activation of the Last Access Time Stamp (H)
If a security concept is created for an IT system using Windows 10, it SHOULD be checked whether the last access time stamp can be activated in the file system to facilitate analysis of system misuse. The analysis SHOULD take into account possible effects of this setting, such as performance aspects or resulting limitations in incremental backups.
SYS.2.2.3.A25 Handling Remote Access Features of Connected User Experience and Telemetry (H)
It SHOULD be taken into account that the Connected User Experience and Telemetry (CUET) component in Windows 10 is an integral part of the operating system that, in addition to the telemetry feature, provides Microsoft with a way to access local systems remotely. This type of remote access to Windows 10 clients SHOULD be logged on the network side and blocked if required.
SYS.2.2.3.A4 Telemetry and Privacy Settings in Windows 10 (B)
Telemetry services transmit diagnostic and usage data that the manufacturer links to unique characteristics for the purposes of troubleshooting, improvement of services and products, and identification. These can only be greatly reduced by setting the telemetry level to 0 (Security). If this setting is not effectively implemented, appropriate safeguards (such as at the network level) MUST be taken to ensure that this data is not transmitted to the manufacturer.
SYS.2.2.3.A5 Protection Against Malware in Windows 10 (B)
Unless equivalent or higher safeguards (such as application whitelisting) have been implemented to protect an IT system from malware infection, a specialised malware protection component MUST be deployed on Windows 10 clients.
SYS.2.2.3.A6 Integration of Online Accounts into the Operating System [User] (B)
Logging into the system and domain MUST ONLY be possible using an account of a self-operated directory service. The ability to log in using local accounts SHOULD be reserved for administrators. Online login accounts (e.g. Microsoft accounts or accounts from other providers of identity management systems) MUST NOT be used because doing so transmits personal data to the systems of the manufacturer.
SYS.2.2.3.A9 Secure Central Authentication of Windows Networks (S)
Only Kerberos SHOULD be used for central authentication. A group policy SHOULD prevent the use of older protocols. If this is not possible, NTLMv2 MUST be implemented as an alternative. Authentication by means of LAN Manager and NTLMv1 MUST NOT be allowed within an organisation or production operating environments. The cryptographic mechanisms used SHOULD be configured and documented according to the identified protection needs and based on the applicable internal guidelines. Deviating settings SHOULD be justified and coordinated with the respective security management personnel.
SYS.2.3 Unix Clients
Target Object: IT system / Order: R2
SYS.2.3.A1 Authentication of Administrators and Users [User] (B)
Administrators MUST NOT log in as “root” during normal operations. For system administration tasks, “sudo” or an appropriate alternative with appropriate logging SHOULD be used. Multiple users SHOULD be prevented from logging into a client simultaneously.
SYS.2.3.A11 Preventing the Local Hard Drive From Becoming Overloaded (S)
Quotas for users or services SHOULD be set that leave enough capacity for the operating system. In general, different partitions SHOULD be used for the operating system and data. Alternatively, mechanisms of the file system in use SHOULD also be used that only grant write privileges to the “root” user once an appropriate level of capacity has been reached.
SYS.2.3.A12 Secure Use of Appliances (S)
It SHOULD be ensured that appliances are characterised by a level of security similar to that of clients on standard IT systems. It SHOULD be documented how the corresponding security requirements are met when using an appliance. If it is not possible to unequivocally comply with the requirements, a declaration of conformity SHOULD be requested from the respective manufacturer.
SYS.2.3.A14 Protection Against the Use of Unauthorised Peripheral Devices (H)
It SHOULD only be possible to use peripheral devices if they are included in a centrally managed whitelist. Kernel modules for peripheral devices SHOULD only be loaded and enabled if the devices can be found on the applicable whitelist.
SYS.2.3.A15 Additional Protection Prior to Executing Undesired Files (H)
Partitions and directories for which users have write privileges SHOULD be mounted in such a way that no files can be executed (mount option “noexec”).
SYS.2.3.A17 Additional Prevention of Further Intrusion When Vulnerabilities Are Exploited (H)
The use of system calls SHOULD be restricted to the necessary minimum (e.g. by means of “seccomp”), particularly for exposed services and applications. The existing standard profiles and rules of SELinux and AppArmor, as well as of alternative extensions, SHOULD be checked manually and adapted as required to the security policy at hand. If necessary, new rules and profiles SHOULD be drawn up.
SYS.2.3.A18 Additional Kernel Protection (H)
Appropriate protective safeguards such as memory protection, file system protection, and role-based access control SHOULD be implemented with specially hardened kernels (e.g. grsecurity, PaX) to prevent exploitation of vulnerabilities and propagation in operating systems.
SYS.2.3.A19 Hard Disk or File Encryption (H)
Hard disks or the files stored on them SHOULD be encrypted. The related keys SHOULD NOT be stored on the same IT system. AEAD (Authenticated Encryption with Associated Data) procedures SHOULD be used for hard disk and file encryption. Alternatively, “dm-crypt” SHOULD be used in combination with “dm-verity”.
SYS.2.3.A2 Selection of an Appropriate Distribution (B)
An appropriate Unix derivative or Linux distribution MUST be selected based on the security requirements and intended purpose at hand. Support MUST be available for the operating system for the planned period of use. All the required application programs SHOULD be directly available as part of the distribution chosen. They SHOULD ONLY be obtained from third-party sources in exceptional cases. Distributions in which the operating system is compiled independently SHOULD NOT be used in production environments.
SYS.2.3.A20 Disabling Critical SysRq Features (H)
The SysRq functions that users may execute SHOULD be specified. In general, it SHOULD NOT be possible for users to trigger any critical SysRq functions.
SYS.2.3.A4 Kernel Updates on Unix-Like Systems (B)
Clients MUST be rebooted promptly after the kernel of their operating system has been updated. If this is not possible, live kernel patching MUST be enabled as an alternative.
SYS.2.3.A5 Secure Installation of Software Packages (B)
If software requiring installation is to be compiled from source code, the software MUST ONLY be unpacked, configured, and compiled using an unprivileged user account. The software to be installed MUST NOT be installed in the root file system of an operating system in an uncontrolled manner. If the software is compiled from source text, the selected parameters SHOULD be documented appropriately. Based on this documentation, it SHOULD be possible to compile the software in a transparent and reproducible manner at any time. All further installation steps SHOULD also be documented so that the configuration can be reproduced quickly in emergencies.
SYS.2.3.A6 No Automatic Integration of Removable Drives [User] (S)
Removable drives SHOULD NOT be integrated automatically. The integration of removable drives SHOULD be configured in such a way that all files are marked as non-executable (mount option “noexec”).
SYS.2.3.A7 Restrictive Granting of Access Rights for Files and Directories (S)
It SHOULD be ensured that services and applications are only allowed to create, change, or delete the files assigned to them. In directories in which all users have write privileges (e.g. /tmp), the sticky bit SHOULD be set.
SYS.2.3.A8 Use of Techniques to Restrict the Rights of Applications (S)
In order to restrict the access rights of applications to files, devices, and networks, AppArmor or SELinux SHOULD be used. The solutions with the best protection provided by the respective Unix derivative or Linux distribution SHOULD be selected. The necessary applications SHOULD be regulated through whitelisting instead of blacklisting. Extensions regarding the restriction of rights SHOULD be used in enforcing mode or by means of appropriate alternatives.