Device Guard in Windows 10

Overview

Device Guard is a group of key features, designed to harden a computer system running Windows 10 against malware. Its focus is preventing malicious code from running by ensuring only known good code can run. In order for Device Guard to be “on” and protecting a system, the following three supporting features must be enabled together.

• • Configurable Code Integrity (CCI) – Ensures that only trusted code runs from the boot loader onwards.
    • This is the heart of Device Guard and is responsible for the core functionality of limiting only known, good code from running on a system. The other two features support and help enforce CCI.
• • Virtual Secure Mode – Moves Kernel Mode Code Integrity (KMCI) and Hypervisor Code Integrity (HVCI) components into VSM, hardening them from attack.
    • Where CCI defines the list of “whitelisted” executables and drivers, it is KMCI and UMCI (User-Mode Code Integrity) that enforce those policies. VSM helps harden KMCI and HVCI against attack.
• • Secure Boot – Ensures the boot binaries and UEFI firmware are signed and have not been tampered with.
    • Prevents CCI policies from being tampered with prior to the boot loader running.

In a nutshell, the way DG is intended to be used is by creating a CCI policy that explicitly defines the executables, scripts, and drivers that are allowed to run on a system, and then deploying that CCI policy to machines in an environment to prevent malicious and unapproved code from running on those machines. The challenge with this is that a CCI policy is a single, static file that is deployed to machines with (hopefully) a full list of vetted executables, scripts, and drivers. Any new executables, drivers, or scripts to be run in the environment require a modification to the CCI policy and then deploying the new policy file to machines.

The particular challenge with this is when a user calls IT requesting that an application needs to be run immediately. The new executable would have to be loaded onto a reference machine where a new CCI policy could be generated. If all of the binaries in the new program are signed, then the CCI policy creation should be able to be done in a semi-automated fashion (when running in audit mode, it is possible to identify signed binaries and load those into the CCI policy). If not, then specific hash rules would need to be created for binaries, which can be challenging with programs that update on a regular basis. The new CCI policy would then need to be deployed to all machines before they could run the new executable.

(Note: In theory, the functionality that allows SCCM-deployed applications to be “trusted” by DG obviates the need to deploy a new CCI policy. However, the application would still need to be packaged and deployed through SCCM, and I’m not sure if this particular technical feature works yet.)

There is no way to temporarily disable the CCI policy locally on a machine, even with administrative rights. The CCI policy must be overwritten by an updated one that has been deployed. If this sounds challenging to work around, that is because it was designed to be. It is intentionally difficult to remove or tamper with CCI policies on a machine, regardless of the rights a user has on that machine. This is why DG is best utilized for environments where the set of applications and drivers are “known” and controlled by administrators.

Because of this constraint, I think it will be challenging for Device Guard to be widely implemented as a security solution at our clients in its current form. VSM and Secure Boot, as standalone security components, are good recommendations for any firm that wishes to reduce the number of attack vectors in its Windows 10 environment. The downsides of these two components are relatively minor and I think most firms can implement them without a significant expenditure of effort. Creating a CCI policy to whitelist executables, scripts, and drivers might more challenging for some firms because of the reactive nature of many IT departments.

FAQ

Q: How does Credential Guard relate to Device Guard?

A: Credential Guard is not part of Device Guard. It aims to protect system and user secrets against compromise. Although, like Device Guard, it also requires Virtual Secure Mode to be enabled, it protects a different aspect of the OS from attack. The two features can be thought of as complementary security components in a more holistic security model for Windows 10.

Q: How does AppLocker fit into working with Device Guard?

A: AppLocker can be deployed in tandem with Device Guard to further lock down access to applications. For example, Device Guard could be deployed with an approved list of executables; AppLocker could then further restrict access to those executables based on Active Directory group membership.

Q: What are the high-level steps for creating and deploying a CCI policy?

A: The high level steps to configure code integrity for your organization are:

1. Group devices into similar roles – some systems might require different policies (or you may wish to enable CCI for only select systems such as Point of Sale systems or Kiosks.

2. Use PowerShell to create integrity policies from “golden” PCs
(use the New-CIPolicy Cmdlet)

3. After auditing, merge code integrity policies using PowerShell (if needed)
(Merge-CIPolicy Cmdlet)

4. Discover unsigned LOB apps and generate security catalogs as needed (Package Inspector & signtool.exe – more info on this in a subsequent post)

5. Deploy code integrity policies and catalog files

a. GP Setting: Computer Configuration \ Administrative Templates \ System \ Device Guard \ Deploy Code Integrity Policy

b. Copying .cat files to catroot – C:\Windows\System32\\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\)

Further Reading

More FAQs
Windows 10 Device Guard and Credential Guard Demystified
Secure Boot Overview