Device Guard is a new feature for Windows 10 and Server 2016. It’s actually a combination of several other components, including Credential Guard, that when implemented, will only allow trusted applications that are defined in your code integrity policies. We’re going to look at how it’s implemented, and look at Credential Guard by itself.
In Part 1, we will enable Device Guard and Credential Guard. In part 2, we will publish Device Guard rules.
Device Guard (and its components) are only available in the Enterprise and Education SKUs of Windows 10. It is available on all SKUs on Server 2016.
Hardware
First, to fully deploy Device Guard, you need to have a certain standard of hardware. Because Device Guard relies on a hypervisor (in this case, Hyper-V), you need hardware that is capable of running virtualization. Requirements are a 64-bit CPU, CPU virtualization extensions (such as VT-x for Intel and AMD-V for AMD processors) when extended page tables, UEFI firmware version 2.3.1.c or higher, HVCI compatible drivers, and Secure Boot enabled. A full list of requirements broken down by version of Windows 10 is available here: https://technet.microsoft.com/en-us/itpro/windows/keep-secure/requirements-and-deployment-planning-guidelines-for-device-guard.
Device Guard can also be deployed in Hyper-V virtual machines, as long as the physical host is running Server 2016 or Windows 10 v1607. The VM itself must be a generation 2 VM.
With compatible hardware, the code integrity service will run alongside the Windows kernel in a hypervisor-protected container, making it nearly impossible for a bad actor to execute malicious code, even if they have control of the Windows kernel.
If you are on Windows 10 v1607, Server 2016, or higher, Hyper-V will automatically be enabled when you turn on Device Guard. If you’re not on at least Windows 10 v1607, you will be enable the Hyper-V and Isolated User Mode Windows Features.
Activating Device Guard and Credential Guard
Turning on Device Guard is really simple – it’s one Group Policy. I recommend making a separate Group Policy for this, as you will likely be linking it several OUs in your environment. Do NOT add it to Default Domain Policy, as you do not want code integrity applied to your domain controllers (more on that in Credential Guard section).
In your new GPO, navigate to Computer Configuration > Administrative Templates > System > Device Guard. Edit the policy “Turn On Virtualization Based Security”. To turn on Device Guard, I recommend these settings:
To only turn on Credential Guard, use these settings:
You can read about the various settings in the Help box. To summarize, the first box has two options – Secure Boot and Secure Boot with DMA. Keeping this at Secure Boot ensures that this policy will apply to all machines. If you set it Secure Boot with DMA, this policy will only apply to computers that can handle DMA, so you’ll likely miss some things. If you leave it at Secure Boot, machines that support DMA will use Secure Boot with DMA.
If you want Device Guard, set the next two boxes to Enabled without lock. The different between “without lock” and “UEFI lock” is that if you lock this, you cannot modify it remotely. You will only be able to disable it going forward with a GPO. This could create support issues, so outside highly secure environments, it’s probably best to keep it “without lock”.
If you only want Credential Guard, set the “Credential Guard Configuration” box to “Enabled without Lock”.
After a restart, you can check that Device Guard or Credential Guard is enabled by running msinfo32.exe and looking at the bottom of the System Summary page. You should see these six entries:
If all you want is Credential Guard, stop here and do not proceed to Part 2. This is enough to enable Credential Guard by itself. To get all of Device Guard, look for Part 2 soon.
Disclaimer
All content provided on this blog is for information purposes only. Windows Management Experts, Inc makes no representation as to accuracy or completeness of any information on this site. Windows Management Experts, Inc will not be liable for any errors or omission in this information nor for the availability of this information. It is highly recommended that you consult one of our technical consultants, should you need any further assistance.
