About this guidance
This ALPHA guidance describes how to securely manage Windows 10 Desktop devices using a Mobile Device Management (MDM) solution.
This new way of managing Windows Desktop devices was first introduced in Windows 8.1, and has been improving ever since. It’s now at the point where we believe a variety of organisations might benefit from using this new enterprise management model.
The NCSC has separate guidance on managing Windows 10 deployments using traditional Domain Controllers, Active Directory and Group Policies. Both documents will continue to be maintained.
MDM management gives administrators less control over the EUD configuration than the traditional approach to device management. As a result, there are more risks to be accepted and understood. These additional risks are highlighted in the differences in risk section below.
This guidance was developed following testing performed on a Dell XPS 13 running Windows Enterprise build 1703 (Creators Update), managed using the Microsoft Intune MDM and Azure Active Directory (AAD). It applies only to Windows 10 versions newer than the Creators Update (version 1703). Whilst the configuration policies have only been tested on Intune, all the configuration steps described here are supported by Microsoft’s Configuration Service Providers (CSP) interface. As such they will be applicable to any MDM solution which supports this program.
Note that recommendations here are not automatically compatible with Windows 10 Mobile devices – see the Windows 10 Mobile platform guidance documentation for recommended settings and configurations.
It’s important to remember that this guidance has been conceived as a way to satisfy the 12 End User Device Security Principles. As such, it consists of recommendations and should not be seen as a set of mandatory instructions requiring no further thought.
Risk owners and administrators should agree a configuration which balances business requirements, usability and security.
Risk owners’ summary
We recommend the following architectural choices for Windows 10:
- All data from the device should be routed over a secure enterprise Virtual Private Network (VPN) to ensure the confidentiality and integrity of the traffic, and to allow the devices and data on them to be protected by enterprise protective monitoring solutions.
- Users are not permitted to install arbitrary third-party application on the device. Applications should be authorised by an administrator and deployed via a trusted mechanism.
- Most users should have accounts with no administrative privileges. Users that require administrative privileges should use a separate unprivileged account for email and web browsing. It is recommended that local administrator accounts have a unique strong password per device.
When configured in this way, risk owners should be aware of the following technical risks associated with this platform:
|
Security Principle |
Explanation of risks |
|
Secure boot |
Windows 10 can support secure boot, but this is dependent on supported and correctly configured hardware. |
Administrators’ deployment guide
Overview
To meet the principles outlined in the End User Devices Security Framework, several recommendations are given in the table below.
|
Security Principle |
Explanation |
|
Assured data-in-transit protection |
Use the native Windows 10 Built-In VPN Client configured as per the CPA customisation guide (available via NCSC Enquiries). Use certificates for user or machine credentials. Windows Hello should be used to bind these credential to the device’s hardware. Currently, there is no way to configure the built-in Windows firewall via MDM, therefore you cannot block outbound connections when the VPN is not active. |
|
Assured data-at-rest protection |
Use one of the following configurations to provide full volume encryption: – BitLocker with a TPM and PIN configured in alignment with the Bitlocker Configuration settings. – An independently assured CPA Foundation Grade, Data at Rest encryption product that supports UEFI and Windows Secure Boot, configured in alignment with the security procedures for that product. If using BitLocker, deploy the configuration settings before encryption is started. BitLocker is not Foundation Grade certified. However, the NCSC has determined that the level of protection it provides is equivalent to Foundation Grade when configured as per this guidance. |
|
Authentication |
The user implicitly authenticates to the device by decrypting BitLocker on boot. The user then has a secondary credential to use when authenticating to the platform after boot and when unlocking the device. A good user experience will be achieved by enabling Windows Hello and allowing the user to log in with a PIN code. For both Windows Hello and traditional passwords, the credential derives a key which protects other credentials that give access to corporate services. In an enterprise environment, the user will also be issued with an Azure Active Directory credential which will be required when they use a device for the first time. This credential would then be best protected if Credential Guard is enabled – currently there is no way to configure this using an MDM and the CSP interface. Windows Hello also permits biometric unlock of devices but the strength of its security is difficult to measure. In cases where there is a business requirement to use biometric authentication, and the risks of doing so are understood, biometric authentication can be enabled. Accounts with administrative privileges should only be present on End User Devices used to perform administrative functions. User accounts with administrative privileges should have a strong password and ideally a second factor to authenticate them to the platform at logon and unlock time. |
|
Secure boot |
On Windows 10, this requirement is met on a correctly configured platform deployed on Hardware Compatibility Program. A UEFI password can make it more difficult for an attacker to modify the boot process. With physical access, the boot process can still be compromised. |
|
Platform integrity and application sandboxing |
No configuration is required. |
|
Application whitelisting |
An enterprise configuration can be applied to implement application control using AppLocker. A recommended sample configuration that only allows Administrator-installed applications to run is provided below. Device Guard can also be used to reinforce application control rules. As it is more complex to configure and maintain, it is not currently recommended for most deployments. AppLocker can be used to restrict which pre-installed Windows Apps are available to users. If the public Windows Store is enabled it can control which applications a user can install. |
|
Malicious code detection and prevention |
Windows 10 includes Windows Defender and Windows SmartScreen. These attempt to detect malicious code for the platform. Cloud sample submission can be disabled. Alternatively, third party anti-malware products are available. If using a third-party product, those that implement the Anti-Malware Scan Interface (AMSI) should be preferred to improve compatibility with future Feature Updates. The Early Launch Anti-Malware (ELAM) driver provides signature checking for known bad drivers on ELAM compliant systems that are configured to use Secure Boot. Windows Store for Business or a Company Store can be used to distribute user-installable universal apps. Such stores should only contain vetted apps. If the public Windows Store is enabled, AppLocker can be used to control which applications a user is able to install. Content-based attacks can be filtered by scanning capabilities in the enterprise. |
|
Security policy enforcement |
Disable un-enrolment from the MDM service. Settings applied to the device via the MDM service cannot then be modified or removed by unprivileged users. Restrict non-administrative users from joining devices to Azure Active Directory. |
|
External interface protection |
Interfaces can be configured using MDM policy. USB removable media can be blocked through MDM settings if required. Direct Memory Access (DMA) is possible from peripherals connected to some external interfaces including FireWire and Thunderbolt, unless disabled through MDM settings as detailed below, or in the UEFI/BIOS. With Windows 10 Connected Standby devices, part of the hardware compliance mitigates DMA attacks by disallowing these interfaces. |
|
Device updates |
Windows Update can automatically download and install updates. If the Windows Store is enabled, it should be configured to automatically update Windows Store apps. Some devices will allow the UEFI firmware to be updated automatically via Windows Update. Devices that do not implement this will require updates via another mechanism whenever new firmware is released. |
|
Event collection |
Events such as sign-in information and general audit logs can be found within the AAD portal. More detailed diagnostic information from the device can be achieved via DiagnosticLog CSP. |
|
Incident response |
Windows 10 devices can be wiped remotely by an MDM. In the event that a device is compromised, a full device wipe is recommended. |
Differences in risk between MDM and Traditional management of Windows 10
|
Risk |
Explanation of difference |
|
Enterprise baselines |
Some of the configuration within both the NCSC and MSFT recommended baselines cannot be set using an MDM and the CSP interface. The below configuration utilises the capabilities currently available. You should check available settings and see if these meet your organisation’s requirements. This guidance will be updated when capabilities further increase. |
|
Firewall |
On traditionally managed Windows devices, we recommend using the firewall to block outbound connections when the VPN is not active. This ensures all traffic from the EUD goes via the VPN. Currently, you cannot manage the firewall using an MDM and the CSP interface. Therefore, there is no guarantee all the traffic will go via the VPN. Management of the firewall with an MDM may be possible with future releases of Windows via the Firewall CSP. |
|
Virtualisation-based security |
We recommend the use of virtualisation-based security. Amongst other security benefits, this will help protect Active Directory or Azure AD credentials. Currently, there is no way to configure the use of virtualisation-based security or credential guard with an MDM and the CSP interface. This may be possible with future releases of Windows via DeviceGuard CSP. |
Preparation for deployment
The steps below should be followed to prepare for deployment of these devices:
-
Procure, deploy and configure network components, including an approved IPsec VPN Gateway.
- Configure AAD with the appropriate accounts and licences to meet your organisation’s needs. Set up and approve your MDM solution to be authoritative over the directory.
- Configure AAD to automatically enrol connected devices into the chosen MDM solution.
- Configure users and groups according to the principle of least privilege.
- Create MDM profiles for users in accordance with the settings later in this section.
- Deploy an AppLocker rule set using MDM settings following guidance in Application Whitelisting. A sample configuration which allows only applications installed by an Administrator to run, is outlined in the MDM settings below.
- Deploy your organisation’s standard desktop build using a clean Windows 10 Enterprise image.
Device provisioning steps
The steps below should be followed to provision each end user device onto your organisation’s network, preparing it for distribution to end users:
1. By default, the user who will join the device to AAD and be enrolled into the MDM is placed into the Local Administrators group on that device. As such, users should not be instructed to enrol themselves; all device enrolment should be performed by administrators using administrative accounts.
2. Update the system firmware to the latest version available from the vendor. This may be called a UEFI or BIOS update.
3. Configure the system firmware to boot in UEFI mode, enable TPM, Secure Boot and virtualisation extensions. Disable unused hardware interfaces, check the boot order to prioritise internal storage and set a password to prevent changes. Most of these settings will be pre-configured on a Windows Hardware Compatibility Program device.
4. Install a clean version of Windows Enterprise from a known good source.
5. Join the device to AAD and enrol into your MDM either by:
- Promoting a dedicated provisioning account to become a Device Enrolment Manager. Use this account to join AAD and enrol into your MDM.
- Use the Windows Configuration Designer tool which is part of the Windows Assessment and Deployment Kit (ADK), to create a provisioning package. Apply the provisioning package during the out of box experience.
- Use an MDM-specific enrolment app
Recommended policies and settings
This section details important security policy settings which are recommended for a Windows 10 deployment.
Remember, any guidance points given here are recommendations – they are not mandatory.
Risk owners and administrators should agree a configuration which balances business requirements, usability and the security of the platform.
Settings not listed in this section are either not applicable to this mode, not currently available or should be chosen according to your organisation’s policies and requirements.
Some of the configuration below utilises ADMX-backed CSP polices, you should familiarise yourself with this structure before continuing. To enable these types of polices read the following guide.
Some of these settings are specific to Microsoft Intune. When using other MDM solutions, the equivalent setting should be configured. Organisations using Microsoft Intune can download this configuration as a zipped JSON file. The configuration can then be imported using a Microsoft-provided import script.
User Account Hardening
|
Device Configuration Profile |
Value(s) |
|
Custom configuration CredentialsUI – OMA-URI: ./Device/Vendor/MSFT/Policy/Config/CredentialsUI/DisablePasswordReveal |
Date type: String (XML) Value: <enabled/> |
|
Device Restrictions – Profile General > Cortana |
Block |
|
Device Restrictions – Profile Cloud and Storage > Settings synchronization for Microsoft account |
Block |
|
Device Restrictions – Profile General > OneDrive file sync |
Block |
|
Device Restrictions – Profile App Store > Use private store only |
Allow |
|
Device Restrictions – Profile Password > Maximum minutes of inactivity until screen locks |
Allow 15 |
|
Device Restrictions – Profile General > Manual unenrolment |
Block |
|
Device Restrictions – Profile Lock Screen Experience > Toast notifications on locked screen |
Block |
Authentication Policy
Your organisation should have a consistent authentication policy which applies to all users and devices capable of accessing its data. You can use our published password guidance to help inform any password policy.
An administrator should configure the relevant on-device settings in line with your authentication policy.
For further guidance on authentication policies, see the NCSC EUD Authentication guidance.
Intune, along with other MDMs, implement a number of relevant settings as Fine Grained Password Policies that should be configured.
|
Password Profile |
Value(s) |
|
Device Restrictions – Profile Password |
Minimum password length Number of sign-in failures before wiping device Directly Applies To: AAD Users |
|
Device Restrictions – Profile Password |
Minimum password length Required password type: Alphanumeric Password complexity: Numbers, lowercase, uppercase and special characters required Number of sign-in failures before wiping device Directly Applies To: Administrators |
|
Device Restrictions – Profile Password > Simple passwords |
Block |
Azure Active Directory
A user’s Azure Active Directory password will normally only be used when enrolling against a device for the first time. It is not backed by a second factor or by hardware-backed anti-hammer, even when Credential Guard is deployed. Different requirements can be set for different account types using Fine Grained Password Policies. If the Azure Active Directory password is only used for device enrolment, it needs to be easy to type in but does not need to be memorable.
Windows Hello and Hardware Strengthening
The user should log in to a device or unlock it using Windows Hello or Windows Hello for Business. This is a new type of user credential that is tied to the physical device using a PIN or biometric. When run on Windows 10 Certified devices it provides hardware-backed anti-hammer. Windows Hello should only be enabled on devices that use a hardware security device.
Users can choose to set a PIN after they have logged on to the device for the first time. A number of settings can be used to configure the PIN requirements including:
|
Device enrolment > Windows Enrolment > Windows Hello for Business > Settings |
|
Configure Windows Hello for Business: Enabled |
|
Use a Trusted Platform Module (TPM): Required |
|
Minimum PIN length |
|
Maximum PIN length |
|
Lowercase letters in PIN |
|
Uppercase letters in PIN |
|
Special characters in PIN |
|
Use enhanced anti-spoofing, when available |
Once a PIN is set, if the device has the right sensors, the user can also enrol a biometric to unlock it. The strength of the security of the different types of biometric sensor is difficult to measure. If the risks of enabling biometrics are understood and accepted, biometric authentication can be enabled.
|
Device enrolment > Windows Enrolment > Windows Hello for Business > Settings |
|
Allow biometric authentication |
At the time of writing you cannot configure Credential Guard when using an MDM and the CSP interface. Virtual Secure Mode and Credential Guard provide great security benefits. Biometrics should not be used unless these features are installed and enabled. Biometrics are enabled by default on Windows 10, so MDM settings should be used to disable biometrics if Virtual Secure Mode and Credential Guard are not being used. Microsoft has provided more information on credential guard.
System hardening
|
Device Configuration Profile |
Value(s) |
|
Custom configuration System/AllowTelemetry – OMA-URI: ./User/Vendor/MSFT/Policy/Config/System/AllowTelemetry |
Date type: Integer Value 0 = Security data only |
|
Custom configuration ErrorReporting/DisableWindowsErrorReporting – OMA-URI: ./Device/Vendor/MSFT/Policy/Config/ErrorReporting/DisableWindowsErrorReporting |
Date type: String (XML) Value: <enabled/> |
|
Custom configuration DeviceInstallation/PreventInstallationOfMatchingDeviceIDs – OMA-URI: ./Device/Vendor/MSFT/Policy/Config/DeviceInstallation/PreventInstallationOfMatchingDeviceIDs |
Date type: String (XML) Value: <enabled/> PCI\CC_0C0A |
|
Custom configuration DeviceInstallation/PreventInstallationOfMatchingDeviceSetupClasses – OMA-URI: ./Device/Vendor/MSFT/Policy/Config/DeviceInstallation/PreventInstallationOfMatchingDeviceSetupClasses |
Date type: String (XML) Value: <enabled/> {d48179be-ec20-11d1-b6b8-00c04fa372a7} {7ebefbc0-3200-11d2-b4c2-00a0C9697d07} {c06ff265-ae09-48f0-812c-16753d7cba83} {6bdd1fc1-810f-11d0-bec7-08002be2092f} |
|
Custom configuration DataProtection/AllowDirectMemoryAccess – OMA-URI: ./Device/Vendor/MSFT/Policy/Config/DataProtection/AllowDirectMemoryAccess |
Date type: Integer Value: 0 Not Allowed |
|
Custom configuration NetworkIsolation/EnterpriseProxyServersAreAuthoritative – OMA-URI: ./Device/Vendor/MSFT/Policy/Config/NetworkIsolation/EnterpriseProxyServersAreAuthoritative |
Date type: Boolean Value: True |
|
Custom configuration NetworkIsolation/EnterpriseIPRangesAreAuthoritative – OMA-URI: ./Device/Vendor/MSFT/Policy/Config/NetworkIsolation/EnterpriseIPRangesAreAuthoritative |
Date type: Boolean Value: True |
|
Device Restrictions – Profile General > Device discovery |
Block |
|
Device Restrictions – Profile App Store > Developer unlock |
Block |
|
Custom configuration System/BootStartDriverInitialization – OMA-URI: ./Device/Vendor/MSFT/Policy/Config/System/BootStartDriverInitialization |
Date type: String (XML) Enabled: Good, Unknown and bad but critical |
|
Custom configuration WindowsLogon/DontDisplayNetworkSelectionUI – OMA-URI: ./Device/Vendor/MSFT/Policy/Config/WindowsLogon/DontDisplayNetworkSelectionUI |
Date type: String (XML) Value: <enabled/> |
|
Custom configuration Power/AllowStandbyWhenSleepingPluggedIn – OMA-URI: ./Device/Vendor/MSFT/Policy/Config/Power/AllowStandbyWhenSleepingPluggedIn |
Date type: String Value: <disabled/> |
|
Custom configuration Power/RequirePasswordWhenComputerWakesOnBattery – OMA-URI: ./Device/Vendor/MSFT/Policy/Config/Power/RequirePasswordWhenComputerWakesOnBattery |
Date type: String (XML) Value: <enabled/> |
|
Custom configuration Power/RequirePasswordWhenComputerWakesPluggedIn – OMA-URI: ./Device/Vendor/MSFT/Policy/Config/Power/RequirePasswordWhenComputerWakesPluggedIn |
Date type: String (XML) Value: <enabled/> |
|
Custom configuration RemoteAssistance/SolicitedRemoteAssistance – OMA-URI: ./Device/Vendor/MSFT/Policy/Config/RemoteAssistance/SolicitedRemoteAssistance |
Date type: String (XML) Value: <disabled/> |
|
Custom configuration RemoteProcedureCall/RestrictUnauthenticatedRPCClients – OMA-URI: ./Device/Vendor/MSFT/Policy/RemoteProcedureCall/RestrictUnauthenticatedRPCClients |
Date type: String (XML) Enabled: Authenticated |
|
Custom configuration Autoplay/DisallowAutoplayForNonVolumeDevices – OMA-URI: ./Device/Vendor/MSFT/Policy/AutoPlay/DisallowAutoplayForNonVolumeDevices |
Date type: String (XML) Value: <enabled/> |
|
Custom configuration Autoplay/SetDefaultAutoRunBehavior – OMA-URI: ./Device/Vendor/MSFT/Policy/Autoplay/SetDefaultAutoRunBehavior |
Date type: String (XML) Enabled: Do not execute any autorun commands |
|
Custom configuration Autoplay/TurnOffAutoPlay – OMA-URI: ./Device/Vendor/MSFT/Policy/Autoplay/TurnOffAutoPlay |
Date type: String (XML) Enabled: All Drives |
|
Custom configuration Experience/AllowWindowsConsumerFeatures – OMA-URI: ./Device/Vendor/MSFT/Policy/Config/Experience/AllowWindowsConsumerFeatures |
Data type: Integer Value: 0 Not Allowed |
|
Custom configuration RemoteDesktopServices/DoNotAllowDriveRedirection – OMA-URI: ./Device/Vendor/MSFT/Policy/RemoteDesktopServices/DoNotAllowDriveRedirection |
Date type: String (XML) Value: <enabled/> |
|
Custom configuration RemoteDesktopServices/PromptForPasswordUponConnection – OMA-URI: ./Device/Vendor/MSFT/Policy/RemoteDesktopServices/PromptForPasswordUponConnection |
Date type: String (XML) Value: <enabled/> |
|
Custom configuration RemoteDesktopServices/RequireSecureRPCCommunication – OMA-URI: ./Device/Vendor/MSFT/Policy/RemoteDesktopServices/RequireSecureRPCCommunication |
Date type: String (XML) Value: <enabled/> |
|
Custom configuration RemoteDesktopServices/ClientConnectionEncryptionLevel – OMA-URI: ./Device/Vendor/MSFT/Policy/RemoteDesktopServices/ClientConnectionEncryptionLevel |
Date type: String (XML) Enabled: High |
|
Custom configuration Search/AllowIndexingEncryptedStoresOrItems – OMA-URI: ./Device/Vendor/MSFT/Policy/Search/AllowIndexingEncryptedStoresOrItems |
Data type: Integer Value: 0 Not allowed |
|
Custom configuration WindowsInkWorkspace/AllowWindowsInkWorkspace – OMA-URI: ./Device/Vendor/MSFT/Policy/WindowsInkWorkspace/AllowWindowsInkWorkspace |
Data type: Integer Value: 1 Enabled but the user cannot access it above the lock screen |
|
Custom configuration DeviceLock/PreventLockScreenSlideShow – OMA-URI: ./Device/Vendor/MSFT/Policy/DeviceLock/PreventLockScreenSlideShow |
Date type: String (XML) Value: <enabled/> |
MDM policy can be used to limit user access to removable media such as USB mass storage devices, if required by organisational policy. The settings can be found in Device restrictions > General > Removable storage.
Windows Defender configuration
If using Windows Defender, configure it to match your organisational needs. The configuration below demonstrates some settings that can be applied. Note, you cannot configure Defender’s Cloud-backed protections when using an MDM with the CSP interface. To enable the Block at First Sight feature users will need to set the relevant settings within Windows Defender Security Centre app as seen here.
|
Device Configuration Profile |
Value(s) |
|
Device Restrictions – Profile Defender > Real-time monitoring |
Enabled |
|
Device Restrictions – Profile Defender > Behaviour monitoring |
Enabled |
|
Device Restrictions – Profile Defender > Network Inspection System (NIS) |
Enabled |
|
Device Restrictions – Profile Defender > Scan incoming mail messages |
Enabled |
Windows Defender SmartScreen configuration
Windows Defender SmartScreen can provide organisations with protective measures if a user visits a potentially harmful website or downloads a potentially malicious file, for more information see here.
See below for a set of recommended settings which fall in line with recommendations from Microsoft:
|
Device Configuration Profile |
Value(s) |
|
Custom configuration Browser/AllowSmartScreen – OMA-URI: ./Vendor/MSFT/Policy/Config/Browser/AllowSmartScreen |
Date type: Integer Value: 1 Turns on Windows Defender SmartScreen |
|
Custom configuration Browser/PreventSmartScreenPromptOverride – OMA-URI: ./Vendor/MSFT/Policy/Config/Browser/PreventSmartscreenPromptOverride |
Date type: Integer Value: 1 Employees can’t ignore SmartScreen warnings |
|
Custom configuration Browser/PreventSmartScreenPromptOverrideForFiles – OMA-URI: ./Vendor/MSFT/Policy/Config/Browser/PreventSmartscreenPromptOverrideForFiles |
Date type: Integer Value: 1 Employees can’t ignore SmartScreen warnings for files |
|
Custom configuration SmartScreen/EnableSmartScreenInShell – OMA-URI: ./Vendor/MSFT/Policy/Config/SmartScreen/EnableSmartScreenInShell |
Date type: Integer Value: 1 Turns on SmartScreen in Windows |
|
Custom configuration SmartScreen/PreventOverrideForFilesInShell – OMA-URI: ./Vendor/MSFT/Policy/Config/SmartScreen/PreventOverrideForFilesInShell |
Date type: Integer Value: 1 Employees can’t ignore SmartScreen warnings and run malicious files |
AppLocker configuration
This example set of AppLocker rules implements the principle outlined in Enterprise Considerations below. It can be modified to allow the user to install and run apps from either an enterprise software center or the Windows Store.
All the below configurations require an exported AppLocker XML profile to be uploaded into Intune. We have packaged the configuration for the below settings here.
Scripting languages such as Visual Basic Scripting should be disabled unless they are specifically needed. The Australian Cyber Security Center describe how to secure Powershell in the enterprise if it is to be used.
|
Device Configuration Profile |
Value(s) |
|
EXE Enforcement Mode |
Enabled |
|
Custom configuration OMA-URI: ./Vendor/MSFT/AppLocker/ApplicationLaunchRestrictions/GROUPNAME/EXE/Policy Data type: String (XML file) |
Allow Everyone: All files located in the Program Files folder Allow Everyone: All files located in the Windows folder – with exceptions Exception: %SYSTEM32%\com\dmp\* Exception: %SYSTEM32%\FxsTmp\* Exception: %SYSTEM32%\Spool\drivers\color\* Exception: %SYSTEM32%\Spool\PRINTERS\* Exception: %SYSTEM32%\Spool\SERVERS\* Exception: %SYSTEM32%\Tasks\* Exception: %SYSTEM32%\PresentationHost.exe Exception: %SYSTEM32%\microsoft\crypto\rsa\machinekeys\* Exception: %SYSTEM32%\mshta.exe Exception: %SYSTEM32%\wbem\WMIC.exe Exception: %SYSTEM32%\cipher.exe Exception: %SYSTEM32%\cmstp.exe Exception: %WINDIR%\tasks\* Exception: %WINDIR%\temp\* Exception: %WINDIR%\tracing\* Exception: %WINDIR%\registration\crmlog\* Exception: %WINDIR%\servicing\packages\* Exception: %WINDIR%\servicing\sessions\* Exception: %Microsoft.NET%\Framework64\v2.0.50727\IEExec.exe Exception: %Microsoft.NET%\Framework64\v2.0.50727\InstallUtil.exe Allow Administrators: All files |
|
Windows Installer Enforcement Mode |
Enforced |
|
Custom configuration OMA-URI: ./Vendor/MSFT/AppLocker/ApplicationLaunchRestrictions/GROUPNAME/MSI/Policy Data type: String (XML file) |
Allow Administrators: All Windows Installer files Allow Everyone: %WINDIR%\Installer\* |
|
Script Enforcement Mode |
Enforced |
|
Custom configuration OMA-URI: ./Vendor/MSFT/AppLocker/ApplicationLaunchRestrictions/GROUPNAME/Script/Policy Data type: String (XML file) |
Allow Everyone: All Scripts located in the Program Files folder Allow Everyone: All Scripts located in the Windows folder – with exceptions Exception: %SYSTEM32%\com\dmp\* Exception: %SYSTEM32%\FxsTmp\* Exception: %SYSTEM32%\Spool\drivers\color\* Exception: %SYSTEM32%\Spool\PRINTERS\* Exception: %SYSTEM32%\Spool\SERVERS\* Exception: %SYSTEM32%\Tasks\* Exception: %WINDIR%\registration\crmlog\* Exception: %WINDIR%\tasks\* Exception: %WINDIR%\temp\* Exception: %WINDIR%\tracing\* Exception: %WINDIR%\servicing\packages\* Exception: %WINDIR%\servicing\sessions\* Exception: %SYSTEM32%\microsoft\crypto\rsa\machinekeys\* Allow Administrators: All scripts |
|
DLL Enforcement Mode |
Enforced |
|
Custom configuration OMA-URI: ./Vendor/MSFT/AppLocker/ApplicationLaunchRestrictions/GROUPNAME/DLL/Policy Data type: String (XML file) |
Allow Everyone: All DLLs located in the Program Files folder Allow Everyone: All DLLs located in the Windows folder – with exceptions Exception: %SYSTEM32%\com\dmp\* Exception: %SYSTEM32%\FxsTmp\* Exception: %SYSTEM32%\Spool\drivers\color\* Exception: %SYSTEM32%\Spool\PRINTERS\* Exception: %SYSTEM32%\Spool\SERVERS\* Exception: %SYSTEM32%\Tasks\* Exception: %SYSTEM32%\microsoft\crypto\rsa\machinekeys\* Exception: %WINDIR%\registration\crmlog\* Exception: %WINDIR%\tasks\* Exception: %WINDIR%\temp\* Exception: %WINDIR%\tracing\* Exception: %WINDIR%\servicing\packages\* Exception: %WINDIR%\servicing\sessions\* Allow Administrators: All DLLs |
|
Packaged app Enforcement Mode |
Enforced |
|
Custom configuration OMA-URI: ./Vendor/MSFT/AppLocker/ApplicationLaunchRestrictions/GROUPNAME/StoreApps/Policy Data type: String (XML file) |
Allow Everyone: All signed packaged apps Exception: Microsoft.Getstarted Exception: Microsoft.MicrosoftOfficeHub Exception: Microsoft.SkypeApp Exception: Microsoft.WindowsFeedback |
BitLocker configuration
The following settings should be configured to use full volume encryption in TPM and PIN mode.
|
Device Configuration Profile |
Value(s) |
|
Endpoint protection – Profile Windows Settings Require devices to be encrypted |
Enabled |
|
Endpoint protection – Profile BitLocker OS drive settings Require additional authentication at startup |
Enabled Block BitLocker on devices without a compatible TPM chip: Not configured TPM startup: Do not allow TPM TPM startup PIN: Allow startup PIN with TPM TPM startup key: Do not allow startup key with TPM TPM startup key and PIN: Allow startup key and PIN with TPM |
|
Endpoint protection – Profile BitLocker removable data-drive settings Deny write access to removable data-drive not protected by BitLocker Block write access to devices configured in another organization |
Enable |
The BitLocker PIN should be in line with your organisation’s password policy. NCSC has published password guidance to inform this. Please contact us if you need help devising an appropriate password policy.
Users can change the PIN after they have logged on to the device for the first time. A number of MDM policies can be used to configure the PIN requirements including:
|
Device configuration > Endpoint protection > Settings |
|
Minimum PIN Length > Minimum characters |
VPN configuration
You should deploy VPN infrastructure configured either to support the PRIME or Foundation profiles as detailed in the NCSC’s IPsec Guidance. Customisation guides are available for either the Windows 10 Built-In VPN Client, the legacy IKEv2 IPsec VPN client or the DirectAccess client. Contact NCSC enquiries to obtain a copy. These configurations differ slightly from that of other End User Devices (which follow the PRIME profile) as the profile is not completely supported by Windows 10. A secondary VPN server or configuration may therefore need to be configured to run in parallel if other devices are being deployed.
PRIME is the recommended IPsec cipher suite profile for protecting information, and it requires a PKI infrastructure configured to support Elliptic Curve cryptography. A non-authoritative summary is provided in the table below:
|
IKEv2 |
Selection |
|
Encryption |
AES with 128-bit keys in GCM-128 mode |
|
Pseudo-Random Function |
HMAC-SHA-256 (RFC4868) |
|
Diffie-Hellman Group |
Group 19 256-bit random ECP (RFC5903) |
|
Authentication |
X.509 certificates with ECDSA signatures (256-bit) on the P-256 curve and SHA-256 (RFC4945 and RFC4055) |
|
ESP |
Selection |
|
Encryption |
AES with 128-bit keys in CBC mode (RFC3602) |
|
Integrity |
SHA-256 (RFC4846) |
If you are using a third-party VPN client, you should prefer one that has been built on top of the Windows 10 UWP VPN plug-in platform. These will likely integrate better into the platform and be more reliable, as the Windows platform is regularly updated.
Enterprise considerations
The following points are in addition to the common enterprise considerations, and contain specific issues for Windows 10 MDM deployments.
EMET
Windows 10 now receives regular patches and feature updates. The security features that were initially part of EMET are making their way into Windows 10 by default. You cannot configure EMET with an MDM and the CSP interface. If you wish to deploy EMET on these devices you will need to find an alternative method for configuring. The next Windows feature update will not allow the use of EMET. By then EMET capabilities will be built into the platform.
Windows 10 feature updates
The Windows 10 Semi-Annual Channel receives feature updates twice-per-year. These feature updates will be serviced for 18 months from the date of release and will replace Current Branch (CB) and Current Branch for Business (CBB) concepts.
You should deploy feature updates immediately to a targeted deployment in order to validate that apps, devices and infrastructure work well with the new release. Once validation is complete, begin deploying broadly. You can defer feature updates for up to 365 days from release. To help with this approach organisations using Azure Active Directory may deploy Insider builds to a select group of devices via the Windows Insider Program for Business.
Monthly Quality Updates which include security, critical and driver updates should be downloaded and installed automatically.
If your organisation is using Windows Update for Business you will need to set the Telemetry level from 0 (Security) to 1 (Basic) for update policies to be honoured, as no Windows update information is gathered when set to 0. If you are using Windows Server Update Services (WSUS) or System Center Configuration Manager (SCCM) you will not be affected. For more information on Windows telemetry settings see here and for more information on configuring Windows Update for Business see here.
When choosing third party products that alter the behaviour of the platform (such as VPN clients, anti-malware tools, management agents and auditing tools), it is important to consider that these may also need to be updated to remain compatible with newer versions of Windows 10. Products are more likely to be supported on future versions of Windows 10 if they use legitimate API’s such as the Anti-Malware Scan Interface and the Windows Runtime API for VPN’s.
This guidance may be updated in the future to cover significant new features in Windows 10 if they can improve the usability of the platform, while best addressing each of the security recommendations. The Windows 10 Long-Term Servicing Channel is designed for devices that never change, such as medical equipment and components in industrial control systems. It should not be deployed on End User Devices that are used to browse the web or use enterprise productivity software.
Device Selection
Windows 10 can run on a wide variety of device types with a wide variety of internal hardware. However, many of the newer Windows security mitigations require the device to have specific hardware components and for them to be turned on.
Even if you are not deploying these mitigations at the moment, you should seek to buy a Windows Hardware Compatibility Program device that support TPM 2.0, UEFI v2.3.1 or higher and have a processor with virtualisation extensions.
The NCSC recommends devices that support InstantGo. Devices that are InstantGo certified will not have ports that allow DMA access and will have TPM 2.0 or later. InstantGo will maintain network connectivity when your screen is off in standby mode and will automatically have device encryption enabled.
If you are using Windows Hello with biometric authentication, you will need to buy special hardware, see Microsoft’s blog for more information.
Signature Edition devices can be used if the required hardware is available. If using these devices, you may not need to reinstall Windows.
Device firmware
You should ensure that devices are configured to boot from UEFI with Secure Boot enabled when initially installing Windows 10 – even if you choose to not configure some of the features that require it. This will make future version upgrades and adoption of those features easier at a later date.
The Windows 10 Secure Boot process (on supported and correctly configured hardware) alerts a user when an attempt to subvert the security controls has taken place. It is important that users know how to identify and respond to this alert.
Firmware updates can be automated via Windows Update and you should prefer devices that support this. If your OEM (original equipment manufacturer) is not choosing to use that mechanism, you will need to periodically check with them to see what the most recent version of the firmware is and how to deploy it across an enterprise.
Application whitelisting
When configuring additional application whitelists for a Windows device, it is important that the following conditions are considered:
- Users should not be allowed to run programs from areas where they are permitted to write files.
- Care should be taken to ensure that application updates do not conflict with whitelisting rules.
- Applications should be reviewed before being approved enterprise-wide, to ensure they don’t undermine application whitelisting. This is especially important for scripting languages which have their own execution environment.
The suggested AppLocker configuration in this guidance will implement those rules if using software that adheres to the requirements of Microsoft’s Desktop App Certification Program. If the rules do need to be customised, follow Microsoft’s Design Guide to minimise operational impact.
Universal applications
The configuration given above prevents users from accessing the Windows Store to install applications, but an organisation can still host its own store to distribute in-house applications to their employees if required. This can be implemented either using Windows Store for Business in the cloud, or via a Company Store app deployed to devices.
If the Windows Store is enabled, users should explicitly use their corporate Microsoft ID to sign into the Store app rather than associating their work device with their personal Microsoft ID. AppLocker can be configured to only allow installation of apps that are on an enterprise-configured “allow” list. The Windows Store can be configured to automatically update any installed Universal applications. The same mechanism can also be used to remove Universal Apps that come with Windows – ones that the user is not allowed to run will be disallowed and removed from the Start menu.
Desktop applications
Enterprise software that handles data downloaded from the Internet needs additional protections.
Application sandboxing and content rendering controls should be considered essential. For applications such as Microsoft Office, or Adobe Acrobat, the use of their enterprise security controls should be considered. These security controls aim to help protect the end user when processing these potentially malicious files.
As well as providing a trusted platform to run enterprise web apps, modern web browsers have to process a wide variety of rich content from the Internet – some of which must be considered untrustworthy. You should consider the security controls available when choosing a web browser. If choosing a Microsoft browser, Edge should be preferred, with Internet Explorer only being used for specific website compatibility. If it is feasible, remove Internet Explorer from the installed image.
The update mechanisms built into Windows can be used to deploy and update Microsoft products but cannot keep third party products up to date. Where available, the auto-update mechanism built into third party products should be use to install updates – where this is not available it will be necessary to deploy updates using an enterprise system management service.
Cloud integration
Windows 10 devices do not need to be associated with a Microsoft ID to operate as required within an enterprise. Users should not enable personal, non-enterprise Microsoft ID (Live ID) accounts on the device, as this may allow data to leak through Microsoft cloud services backup and application storage.
However, organisations wishing to use cloud based services such as OneDrive can use the NCSC Cloud Security Guidance to help them understand both the benefits and risks of using online services.
Source: NCSC
