SYS.2.2.2 Windows 8.1 Clients

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.

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.

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.

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.

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.

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.

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.

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.

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.

The synchronisation of user data with Microsoft cloud services SHOULD be disabled completely.

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.

The ability to install apps from the Microsoft Store SHOULD be disabled if it is not needed.

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.

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.

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.

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.

If a security concept is created for an IT system using Windows 8.1, 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.

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.

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 protected by a password. 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.

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.