A Quick Overview
Look back over the history of computing, and you will see that users have typically been rather too trusting when running applications. If an application causes damage or allows a security breach, system administrators typically find out about it after the fact.
To help us regain control of exactly which applications our users can run, we can use the Windows Defender Device Guard feature (referred to as Device Guard from hereon), introduced in Windows 10.
What can Device Guard do?
Device Guard allows us to limit users from only being able to run those applications we know about and explicitly trust to run. If a user attempts to run anything else, it will be blocked.
Is it just a software solution?
No. Device Guard is far than just a simple reference list of applications that is checked every time a user tries to run something. It is actually a Windows 10 hardening feature that uses a combination of software and hardware that utilizes the new virtualization-based security (VBS) environment introduced in Windows 10, and which we go into far more detail in the “The Whys and Where’s of Windows Credential Guard” blog post.
From a hardware perspective, Device Guard integrates with advanced hardware features such as CPU virtualization extensions, Input–Output Memory Management Units (IOMMUs), and 64-bit processors with Second Level Address Translation (SLAT), to leverage these hardware features inside Windows 10 itself.
How much is this going to cost?
Probably one of the first questions you are going to have to answer from management is how much is all of this going to cost? Well, like most IT-related projects there are both material and resource-related costs when it comes to implementing Device Guard.
From the material side, any machines on which you want to be able to configure and enforce Device Guard will need to be running Windows 10 as Device Guard is only supported on this operating system (OS). If you do want to implement Device Guard on machines running an earlier OS, these will need to be upgraded to Windows 10.
From the resource side, you need to perform compatibility testing to ensure all the devices and applications in scope for Device Guard will actually work.
Then, of course, there are the ongoing costs associated with future testing as new hardware models are released, new applications brought in scope, others upgraded, etc.
The Devil is in the Detail
Of course, implementing any new technology has some degree of risk. In the case of Device Guard, the biggest thing you can do to reduce this risk is to make sure you perform your compatibility testing. Not all devices and applications are compatible with Device Guard’s virtualization-based protection of code integrity, worst case being your end user gets a blue screen (STOP errors) or suffer data loss.
Next, make sure you deploy the Device Guard policies to your machines as soon as possible once they have been successfully tested and piloted. Doing it this way means if you are using System Center Configuration Manager (ConfigMgr), ConfigMgr gets configured as a trusted Managed Installer on any machines where Device Guard policies have been successfully run. In this way, any new software deployed through ConfigMgr is automatically trusted.
If you don’t do it this way, all software deployed by ConfigMgr is not automatically trusted until a Device Guard policy has been successfully run on a ConfigMgr client.
The final potential “gotcha” is any computers that are going to be running Device Guard need to be able to connect to a Domain Controller in order to be able to retrieve any Device Guard policies. This, of course, poses problems in those environments with computers that infrequently connect to an Active Directory (AD) Domain, or machines that are disconnected from AD.
Gently does it
As well as ensuring all of the all of machines on which you want to use Device Guard meet the hardware and software requirements, Microsoft recommends avoiding adopting a “big bang” approach to deploying Device Guard.
Instead, Microsoft’s (and my personal) recommendation, is you should deploy Device Guard in a phased approach. As the types of devices can range so vastly between organizations, start by reviewing the “Windows Defender Device Guard deployment in different scenarios: types of devices” table in the “Requirements and deployment planning guidelines for Windows Defender Device Guard” (a link to which you can find in the Useful Resources table at the end of this post). This will help you understand the types of devices in your organization and how Device Guard relates to them.
Next, you need to analyze who has what hardware and software, who uses it, what are they using it for, etc. You can then start grouping your machines together into appropriate categories.
You might be lucky and be able to get away with defining a single category. There again, you might need different categories, sometimes even for the same hardware and software if it used differently in different parts of your organization.
Next, consider creating a catalog file for any unsigned line of business (LOB) applications. This will allow you to sign these.
Deployment Tips
As with most things in life, it’s usually better to learn from someone who has already done something and hopefully learned from their mistakes, rather than going into the unknown and hoping for the best.
Device Guard is no exception. One of the first decisions you need to make is which tool are you going to use to enable and manage Device Guard?
As the following table shows, Device Guard can be enabled and managed using the following four management tools:
Management Tool
Capabilities
After identifying the groups of users that use the same software/hardware combinations, you should then create what Microsoft refers to as a “golden” computer for this configuration.
You can then create, test and finalize code integrity policies (which are known as “Windows Defender Application Control” from Windows 10 version 1709 and later), which you know will work consistently for that specific combination.
Next, after creating a new Code Integrity Policy, or if you modify an existing one, you should seriously consider running it in Audit only mode. What Audit only mode means, is if an exception occurs due to an application either having been missed by an initial scan, or because it has been added since the original policy was created, rather than blocking that application (and potentially causing the user and yourself some headaches), the application is allowed to run and an exception is logged in the Event log. Contrast this with configuring the policy in Enforcement enabled mode which simply attempts to block the application and could cause some unwanted side effects.
Any exception events logged in the Event log can be reviewed, allowing you to update your policies accordingly before the code integrity policy is enforced.
Finally, if you are using ConfigMgr 1706 or later, you can use ConfigMgr to deploy and monitor your Device Guard policies in either Audit only mode or Enforcement enabled mode. The only requirement is that the computer where the policy is being run is running the ConfigMgr 1706 (or later) client.
Summary
As we’ve already identified, one of the biggest potential risks to your users, their devices, your network, and ultimately your organization is the risk of users potentially being able to run any applications, not just those known and trusted by the organization as safe to run.
Why take this risk when you have Device Guard in your defense arsenal to help you bring order, control and protection?
I’ve created in-depth material on AppLocker and other Windows 10 Security Features for Adaptiva as part of a new program. The Adaptiva Windows 10 Accelerator Program is an end-to-end ecosystem which assembles the products, tools, and training you need to speed zero-touch Windows 10 deployments at scale. You can learn more about it here:
Useful Resources
The following table contains a list of useful resources that contain more information on Windows Defender Device Guard:
