SYS.2.2.3 Clients Running Windows

Description

Introduction

With Windows 10, Microsoft adapted its Windows client operating system to a new corporate strategy. In particular, the fundamental philosophy changed away from the previous principle of the “local operating system” toward a service (“Windows as a Service”). This means that the operating system contains, in addition to its previous functions, further capabilities — in particular cloud-based applications — and therefore relies on close integration with Microsoft’s server infrastructure. Important new aspects compared to previous Windows versions are above all the deeply embedded and partly uncontrollable data exchange between clients and the manufacturer’s infrastructure, as well as the increasing outsourcing of security-critical core components of a Windows infrastructure (e.g., authentication) to the cloud.

With Windows 11, a successor version was released in October 2021. This version contains new functions, has a revised user interface, and significantly higher system requirements compared to Windows 10. In particular, Windows 11 officially requires a 64-bit-capable CPU, UEFI SecureBoot, and a TPM 2.0. Despite the version jump, Windows 11 is not a completely new development but is based on Windows 10. This building block is therefore applicable to both Windows 10 and Windows 11.

Objective

The objective of this building block is to protect information that is processed by and on Windows clients running Windows 10 or 11.

Scope and Modeling

The building block SYS.2.2.3 Clients Running Windows is to be applied to all clients on which the operating system Microsoft Windows 10 or 11 is used.

This building block contains specific requirements that must be observed and fulfilled for the secure operation of clients under the Windows operating system, in addition to the requirements from building block SYS.2.1 General Client. For application programs used on Windows clients, the requirements of the corresponding building blocks must be fulfilled — for example, APP.1.1 Office Products or APP.1.2 Web Browser. When used in a Windows domain, the requirements of the corresponding building blocks such as APP.2.2 Active Directory Domain Services must be fulfilled.

Threat Landscape

Since IT-Grundschutz building blocks cannot address individual information domains, typical scenarios are used to describe the threat landscape. The following specific threats and vulnerabilities are of particular significance for building block SYS.2.2.3 Clients Running Windows.

Malicious Programs on Windows Clients

Due to the widespread use of Windows operating systems and the backward compatibility with older versions that often exists between system generations, the threat posed by malicious programs and unauthorized intrusion into IT systems is comparatively high for Windows.

Integrated Cloud Functions

Windows contains numerous functions that store and synchronize data using Microsoft’s services (“cloud services”). This creates the risk of using these features — unconsciously or at least carelessly — also for potentially institution-critical or personal data. Additionally, users may violate data protection laws when data is stored with third parties, typically abroad. When a person signs in to a new device with an already activated Microsoft account, Microsoft cloud services that the person uses are automatically set up. As a result, institutional data can be unintentionally synchronized to employees’ private devices. As another example, Windows offers by default the option of backing up the BitLocker recovery key directly via the Microsoft account in the cloud, thereby placing sensitive cryptographic secrets in the hands of third parties.

Impairment of Software Functions Due to Compatibility Issues

Software that could be successfully operated on previous versions of an operating system is not necessarily compatible with the current version of Windows. Possible causes include new security features or operating system properties as well as the removal of functions or services. As a result, the software cannot be used at all or only to a limited extent. Examples of activated security features that can cause potential compatibility problems with new Windows versions include User Account Control (UAC) or, in 64-bit versions of the operating system, Kernel Patch Guard. Additionally, signed drivers may be required that may no longer be available for older devices.

Telemetry Functions of Windows

Windows by default sends so-called diagnostic data to the manufacturer Microsoft. In addition, Microsoft can use the telemetry service integrated into Windows to query specific information from a client. At the telemetry level “Full” or “Complete” — which is the default level in Windows Home and Pro editions — this includes, for example, access to the client’s registry and the execution of certain diagnostic tools on the client. There is a risk that the diagnostic or telemetry data may contain sensitive information that can reach third parties in this way.

Limited Forensic Analysis When Using the Virtual Secure Mode (VSM)

The use of the Virtual Secure Mode (VSM) restricts or complicates forensic investigations — for example, for handling security incidents. Processes protected by the Secure Kernel or the Isolated User Mode (IUM) are no longer accessible. For example, memory dumps of these processes cannot be evaluated due to cryptographic measures.

Requirements

The following are the specific requirements of building block SYS.2.2.3 Clients Running Windows. The Information Security Officer (ISO) is responsible for ensuring that all requirements are fulfilled and verified in accordance with the established security concept. The ISO must always be involved in strategic decisions.

Additional roles are defined in the IT-Grundschutz Compendium. They should be filled insofar as this is sensible and appropriate.

Exactly one role should be Primarily responsible. In addition, there may be Additional responsibilities. If one of these additional roles is primarily responsible for fulfilling a requirement, that role is listed in square brackets after the heading of the requirement. The use of singular or plural says nothing about how many persons should fill these roles.

Basic Requirements

The following requirements MUST be fulfilled as a priority for this building block.

SYS.2.2.3.A1 Planning the Use of Cloud Services Under Windows (B)

Since Windows-based devices are closely integrated with the manufacturer Microsoft’s cloud services, it MUST be strategically determined before their use which included cloud services should or may be used to what extent.

SYS.2.2.3.A2 Selection and Procurement of a Suitable Windows Version (B)

The functional scope and the provision of functional changes of a Windows version MUST be selected taking into account the identified protection needs and the intended purpose. The feasibility of the required security measures MUST be taken into account in the selection. Based on the result of the review, the established procurement process MUST be extended to include the selection of the corresponding license model and “Service Branches” (CB, CBB, or LTSC).

SYS.2.2.3.A3 DISCONTINUED (B)

This requirement has been discontinued.

SYS.2.2.3.A4 Telemetry and Data Protection Settings Under Windows (B)

In order to greatly reduce the transmission of diagnostic and usage data to Microsoft, telemetry level 0 (Security) MUST be configured in the Enterprise edition of Windows. If this setting cannot be effectively implemented, or if it cannot be implemented in other Windows editions, it MUST be ensured by appropriate measures — such as at the network level — that the data is not transmitted to the manufacturer.

SYS.2.2.3.A5 Protection Against Malicious Software Under Windows (B)

Unless equivalent or superior measures — such as execution control — have been taken to protect the IT system against infection with malicious software, a specialized component for protection against malicious software MUST be deployed on Windows clients.

SYS.2.2.3.A6 Integration of Online Accounts into the Operating System (B) [Users]

Login to the system and to the domain MUST ONLY be possible with an account from a self-operated directory service. Logins with local accounts SHOULD be reserved for administrators. Online accounts for login — such as a Microsoft account or accounts from other identity management systems — MUST NOT be used, as personal data is transmitted to third-party systems in this process.

Standard Requirements

Together with the basic requirements, the following requirements reflect the state of the art for this building block. They SHOULD generally be fulfilled.

SYS.2.2.3.A7 DISCONTINUED (S)

This requirement has been discontinued.

SYS.2.2.3.A8 DISCONTINUED (S)

This requirement has been discontinued.

SYS.2.2.3.A9 Secure Centralized Authentication in Windows Networks (S)

For centralized authentication, ONLY Kerberos SHOULD be used. A group policy SHOULD prevent the use of older protocols. If this is not possible, NTLMv2 MUST be used as an alternative. Authentication via LAN Manager and NTLMv1 MUST NOT be permitted within the institution and in a production environment. The cryptographic mechanisms used SHOULD be configured and documented in accordance with the identified protection needs and based on internal policies. Deviating settings SHOULD be justified and coordinated with security management.

SYS.2.2.3.A10 DISCONTINUED (S)

This requirement has been discontinued.

SYS.2.2.3.A11 DISCONTINUED (S)

This requirement has been discontinued.

SYS.2.2.3.A12 File and Share Permissions Under Windows (S)

Access to files and folders on the local system and to network shares SHOULD be configured in accordance with an authorization and access concept. The administratively pre-existing administrative shares on the system SHOULD also be taken into account. Write permissions for users SHOULD be restricted to a defined area in the file system. In particular, users SHOULD NOT receive write permissions for folders of the operating system or installed applications.

SYS.2.2.3.A13 Use of the SmartScreen Function (S)

The SmartScreen function, which examines files downloaded from the internet and web content for possible malicious software and in doing so may transmit personal data to Microsoft, SHOULD be deactivated.

SYS.2.2.3.A14 Use of the Cortana Voice Assistant (S) [Users]

Cortana SHOULD be deactivated.

SYS.2.2.3.A15 Use of Synchronization Mechanisms Under Windows (S)

The synchronization of user data with Microsoft cloud services and the sharing of WLAN passwords SHOULD be completely deactivated.

SYS.2.2.3.A16 Connection of Windows to the Microsoft Store (S)

The use of the Microsoft Store SHOULD be reviewed and evaluated for compatibility with the institution’s data protection and security requirements. The general installation of apps on Windows is not dependent on the connection to the Microsoft Store; therefore, if not required, this connection SHOULD be deactivated.

SYS.2.2.3.A17 No Storage of Data for Automatic Login (S)

The storage of passwords, certificates, and other information for automatic login to websites and IT systems SHOULD NOT be permitted.

SYS.2.2.3.A18 Use of Windows Remote Assistance (S)

The effects on the configuration of the local firewall SHOULD be taken into account when planning Windows Remote Assistance (this does not mean RDP). Remote assistance SHOULD only take place following an explicit invitation. If an invitation is saved in a file, it SHOULD be protected by a password. The establishment of a session SHOULD always require explicit consent. The maximum validity period of the invitation for remote support SHOULD be appropriate in duration. If Windows Remote Assistance is not used, it SHOULD be completely deactivated.

SYS.2.2.3.A19 Security for Remote Access via RDP (S) [Users]

The effects on the configuration of the local firewall SHOULD be taken into account when planning remote access. The group of authorized users for Remote Desktop access (RDP) SHOULD be defined by assigning appropriate permissions. In complex infrastructures, the RDP target system SHOULD only be reachable through an intermediary RDP gateway. For the use of RDP, a review and its implementation SHOULD ensure that the following convenience functions listed below are in line with the protection needs of the target system:

• use of the clipboard,
• integration of printers,
• integration of removable media and network drives, as well as
• use of file storage and smartcard ports.

If the use of Remote Desktop access is not intended, these SHOULD be completely deactivated. The cryptographic protocols and algorithms used SHOULD be secure and comply with the institution’s internal requirements.

SYS.2.2.3.A20 Use of User Account Control (UAC) for Privileged Accounts (S)

The configuration parameters of the so-called User Account Control (UAC) SHOULD be used for privileged accounts with a balanced approach between usability and security level. The decisions regarding the configuration parameters to be used SHOULD be documented. In addition, the documentation SHOULD contain all accounts with administrative rights and SHOULD be regularly reviewed to determine whether it is necessary to be able to extend those rights.

Requirements for High Protection Needs

The following are exemplary proposals for requirements for this building block that go beyond the protection level corresponding to the state of the art. The proposals SHOULD be considered in the case of high protection needs. The specific determination is made within the framework of an individual risk analysis.

SYS.2.2.3.A21 Use of the Encrypting File System (EFS) (H)

Since the Encrypting File System (EFS) protects the keys used with the password of the respective account, a secure password SHOULD be used. In addition, restrictive access rights SHOULD protect the files encrypted with EFS. The recovery agent SHOULD be a dedicated account and not an administrative account. In this context, the agent’s private key SHOULD be backed up and removed from the system. Backups SHOULD be created of all private keys. When using EFS with local accounts, local password stores SHOULD be encrypted using Syskey. Alternatively, Windows Defender Credential Guard can be used. 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 executable by administrators. PowerShell execution itself SHOULD be centrally logged and the logs monitored. The execution of PowerShell scripts SHOULD be restricted with the command Set-ExecutionPolicy AllSigned to prevent unsigned scripts from being accidentally executed.

SYS.2.2.3.A23 Extended Protection of Logon Credentials Under Windows (H)

On UEFI-based systems, SecureBoot SHOULD be used and the protected mode status for the Local Credential Store LSA SHOULD be monitored at system startup. If remote maintenance of clients via RDP is planned, the “restrictedAdmin” option for RDP SHOULD be used in Windows deployments in a domain from functional level 2012 R2 onwards.

SYS.2.2.3.A24 Activation of the Last-Access Timestamp (H)

It SHOULD be checked whether the last-access timestamp in the file system can be activated to facilitate the analysis of system misuse. In the review, possible effects of this setting — such as performance aspects or resulting restrictions on incremental backups — SHOULD be taken into account.

SYS.2.2.3.A25 Handling Remote Access Functions of “Connected User Experience and Telemetry” (H)

It SHOULD be noted that the component “Connected User Experience and Telemetry” (CUET) in Windows is an integral part of the operating system and, in addition to the telemetry function, also allows remote access for the manufacturer Microsoft to the local system. Such remote access to the Windows client SHOULD be logged at the network level and, if necessary, blocked.

SYS.2.2.3.A26 Use of the Virtual Secure Mode (VSM) (H)

When using the Virtual Secure Mode (VSM), it SHOULD be noted that forensic investigations — for example, for handling security incidents — are restricted or made more difficult.

Additional Information

Good to Know

The BSI provides an analysis of the security functions of Windows 10 and, based on this, suitable hardening recommendations as part of the project “SiSyPHuS Win10 (Study on System Integrity, Protocol Logging, Hardening and Security Functions in Windows 10)”: https://www.bsi.bund.de/DE/Themen/Cyber-Sicherheit/Empfehlungen/SiSyPHuS_Win10/SiSyPHuS_node.html

The manufacturer Microsoft provides, among other things, the following additional information on Windows:

• Configuring additional LSA protection: https://docs.microsoft.com/de-de/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection
• Credential Guard - Overview: https://docs.microsoft.com/de-de/windows/access-protection/credential-guard/credential-guard-requirements
• Device Guard - Overview: https://technet.microsoft.com/de-de/library/dn986865.aspx