This article is a part of a series. The previous article can be found here:
All the Guards – Part 2 (Virtualization Based Security)
In this article I’m going to focus on the next component:
Device Guard is a group of key features, designed to harden a computer system against malware. Its focus is preventing malicious code from running by ensuring only known good code can run.
It’s worth noting here that these are enterprise features, and as such are included only in the Windows Enterprise client.
Device Guard consists of three primary components:
– Configurable Code Integrity (CCI) – Ensures that only trusted code runs from the boot loader onwards. Requires code integrity policies
– VSM Protected Code Integrity – Moves Kernel Mode Code Integrity (KMCI) and Hypervisor Code Integrity (HVCI) components into VSM, hardening them from attack.
– Platform and UEFI Secure Boot – Ensuring the boot binaries and UEFI firmware are signed and have not been tampered with
When these features are enabled together, the system is protected by Device Guard, providing class leading malware resistance in Windows 10.
But:
Why we no longer use the Device Guard brand
When we originally promoted Device Guard, we did so with a specific security promise in mind. Although there were no direct dependencies between WDAC and HVCI, we intentionally focused our discussion around the lockdown state achieved when using them together. However, since HVCI relies on Windows virtualization-based security, it has hardware, firmware, and kernel driver compatibility requirements that some older systems can’t meet. This misled many people to assume that if systems couldn’t use HVCI, they couldn’t use WDAC either.
WDAC has no specific hardware or software requirements other than running Windows 10, which means customers were denied the benefits of this powerful application control capability due to Device Guard confusion.
But there is this article:
Windows 10 Device Guard and Credential Guard Demystified
that still talks about Device Guard??
also this:
Overview of Device Guard in Windows Server 2016
From what I can determine the major component to focus here is not Device Guard but:
So from:
Device Guard signing is a Device Guard feature that gives admins a single place to sign catalog files and code integrity policies. After admins have created catalog files for unsigned apps and signed the catalog files, they can add the signers to a code integrity policy.
Device Guard is a feature set that consists of both hardware and software system integrity hardening features. These features use new virtualization-based security options and the trust-nothing mobile device operating system model. A key feature in this model is called configurable code integrity, which allows your organization to choose exactly which software or trusted software publishers are allowed to run code on your client machines. Also, Device Guard offers organizations a way to sign existing line-of-business (LOB) applications so that they can trust their own code, without the requirement that the application be repackaged. Also, this same method of signing allows organizations to trust individual third-party applications.
From what I can understand of all this is that part of Device Guard kind of still exists but to implement you would need to implement:
Sign code integrity policy with Device Guard signing
The other part that was Device Guard is now Windows Defender Application Control (WDAC):
Deploying Windows Defender Application Control (WDAC) policies
The confusion about Device Guard is compounded by the way it is referred to in Endpoint Manager, for example here in the Windows 10 security baseline policy:
Here, it seems that Device Guard refers to things like Virtualization Based Security and items yet to be covered in this series, System Guard and Credential Guard.
Device Guard is good example of where all of this gets very confusing. It kind of exists but it doesn’t exist. It also seems to be referenced differently in different places. From what I can determine, unless you want to go down the path of signing your applications so they can all be verified at boot then don’t worry about Device Guard. Where you will need to consider some of the Device Guard feature is if you choose to implement Windows Defender Application Control which I have covered off previously here:
Windows Defender Application Control (WDAC) basics
and here
Basics of deploying Windows Defender Application Control (WDAC) using Intune
WDAC is more focused on software rather than hardware, while Device Guard, in its original form, was more about hardware. Again, very confusing. Unfortunately, the confusion with all these Guards doesn’t end here, so let’s move onto the next component:
CIAOPS 
4 thoughts on “All the Guards–Part 3”