Windows 10 Enhanced Security Features Part Two


For an overview of all enhanced security features in Windows 10 please read our part one of this feature blog post here. This article will detail our guidance on implementing Device Guard/Credential Guard (DG/CG) technologies & features and any known issues you may come across when deploying them.


Bios Changes

Firstly, hardware features need enabling in the BIOS

  • Secure boot
  • VTX-D
  • Disable Microsoft & third party certificates

Some OEMs have a Device Guard enable option in their BIOS which is effectively an umbrella switch that bulk enables the required features.

Device Guard Readiness Script

Once the hardware layer is prepared you now need to understand the available DG/CG capabilities of each of your hardware models:

Once you know which features your hardware can support you are now ready to create Group or Intune policies to manage the required settings. In this article we will focus on managing the settings via Group Policy.

Group Policy Implementation

Within Group policy browse to the following setting:

Computer Configuration | Administrative Templates | System | Device Guard | Turn On Virtualization Based Security

Below is a screenshot of our recommendation for initial testing onlyPlease read on to understand why….

Device Guard/Credential Guard GPO Test Settings

Enable Virtualization Based Security (VBS), then the following settings dependent upon whether your hardware supports it.

Select Platform Security Level

Choose Secure Boot and DMA Protection. While DMA protection requires relatively new hardware it will only be enabled where supported.

Virtualisation Based Protection of Code Integrity

Referred to as HCVI, choose Enabled without Lock then tick the Require UEFI Memory Attributes Table. This ensures your hardware fully supports HVCI and once they group policy has applied you can check under System Information | System Summary in Windows to confirm it is running or with the readiness script.

Device Guard/Credential Guard System Information Values

If it isn’t, you can test your hardware without the Require UEFI Memory Attributes Table option, but this risks BSODs and other issues, so test thoroughly and check your hardware manufacturer’s guidance for compatibility.

Credential Guard Configuration

Choose Enabled without lock as per the reasoning above until application testing is complete.

Secure Launch Configuration

Choose Enabled

A Word on UEFI Lock….

This feature means that even if a user has administrative permissions, they cannot disable these features just by changing registry keys, as they are stored in the EFI configuration and re-enable on the next restart. The only way to disable them is to run the  DG/CG hardware readiness tool commands as an administrator and accept the prompts when the machine is rebooted to disable them (pressing F3 at restart).

This is not very manageable in an enterprise environment, so while you are testing your applications compatibility initially with Windows 10, we recommend you don’t use the UEFI lock, so you can turn the various features off to test incompatibilities and worse case have delta GPOs where issues cannot be resolved.

We detail further down various incompatibilities we have seen and issues you may need to overcome.

Enable UEFI Lock

Once your testing is complete it is worth enabling the UEFI lock features assuming you don’t have applications/scenarios that still need some of these features to be turned off until fully remediated.


Real World Usage & Incompatibilities

During our deployments of Windows 10 we have seen the following issues with the technologies detailed in the previous sections:

  • HVCI Is incompatible with some drivers originally written for older versions of Windows 10 e.g. 1511. We have seen numerous vendors who haven’t realised Windows 10 has been updated twice a year since 2015 and that their original drivers that were Windows 10 compatible, are no longer compatible with all the new features.
  • HVCI when enabled with the “Require UEFI Memory Attributes table” option means it will not run on unsupported hardware. However, HVCI relies on Microsoft Based Execution Code (MBEC) which is supported using software emulation in the hypervisor in 6th Generation Intel CPU’s and supported in hardware from 7th generation CPU’s. There are quite significant performance impacts of the software emulation, therefore, you should thoroughly test any 6th Generation based CPU machines. You may decide to use WMI filtering in your GPOs to disable HVCI on 6th Generation CPUs until the hardware is replaced. (Credit to Brent Arkley for finding the cause of this issue
  • HVCI has also been found to cause some issues with applications, such as affecting the refresh of the waveform timeline in some audio applications and performance issues on other applications.
  • Enabling Credential Guard will mean certain connections that were previously signed onto automatically will now prompt for credentials. Any services using NTLMv1, MS-CHAPv2, Digest, and CredSSP cannot use the signed-in credentials. Thus, single sign-on does not work with these protocols. In-house web applications that use NTLMv1 will no longer be accessible at all with Credential Guard enabled (we recommend upgrading the web application to support more secure protocols).
  • An example of Credential Guard affecting automatic authentication was found with some corporate Wi-Fi solutions. Where the authentication method uses the legacy and insecure MS-CHAPv2 protocol, the user will be prompted for credentials every time they join the Wi-Fi network, or in some cases, no prompt is seen at all, and the connection fails altogether. There is also an issue when a user changes their password, as the old password remains cached on the local machine and the user may not get prompted for the new password.
  • BitLocker standard Group policy configurations include DMA countermeasures which can stop some Thunderbolt related hardware functions from running, but they protect hardware from drive-by DMA attacks, so it is often a decision between function and security. Where your hardware supports Kernel DMA protection these countermeasures should not be set so will need separate policies to be filtered to supported hardware.
  • Any legacy in-house applications that have been written using HTAs (HTML applications) will not run where Windows Defender Application Control is enabled or in audit only mode.
  • When using the UE-V template creation tool from the Microsoft toolkit, secure boot needed to be disabled.
  • VBS has stopped some applications running, especially desktop hypervisor programs e.g. Oracle Virtual Box. This is because VBS needs exclusive control over the hypervisor virtualisation platform on the machine.
  • Disabling the Microsoft UEFI CA key is a requirement for full Device Guard support. However, this can cause issues with some older devices / device drivers i.e. graphics cards. For example, cards that have an embedded Microsoft UEFI CA Cert will prevent HP systems from booting when the UEFI CA key is disabled. In these cases, you need to check and establish if the device in question has an appropriate Firmware upgrade to resolve the issue. Alternatively, the Microsoft UEFI CA key will need to be re-enabled. These scenarios need to be validated in testing.
  • BitLocker Encryption issues on some older LiteOn drives Configured in a RAID configuration. We found that when the encryption started the machines would just lock up and then crash. No newer firmware was available for the Hard drives or the RAID controller.
  • SMB V1 shares with guest access are blocked by Windows 10 completely (obviously SMB V1 shares, guest access and NTLM v1 usage should be remediated immediately as they all represent a huge security risk).
  • Many legacy SMB V1 shares were also found to use NTLM v1 and hence authentication was blocked by Credential Guard.
  • Finally, there is a general performance hit with these technologies, boot up and logon times can be impacted as well as the previously mentioned application performance hit


Final Thoughts

Be aware that the naming convention of some of these technologies has changed over time and therefore some of their underlying documentation, GPO names and Windows setting names do not always align and can cause confusion. Examples of this are:

  • Device Guard Registry keys holding all the VBS based settings, rather than just those for Device Guard. It should also be noted that Device Guard is now the parent term for Windows Defender Exploit Guard (HVCI) and Windows Defender Application Control (WDAC).
  • HVCI if enabled through the windows 10 settings functions is called Core Isolation memory integrity.
  • Kernel DMA protection in the same settings windows is called Memory access protection.

Lastly, as ever it is a fine balance between security and functionality, but these features are a huge step forward to achieve a defence in depth security model to protect against the ever-increasing cyber threats.