Device Guard: The Practice

Introduction

Welcome to the third and final blog in the series on Device Guard!!
In part two of the blog series Device Guard: The Theory, the key points were:

• Device Guard hardens various attack surfaces on an endpoint creating a “chain of trust” from the hardware through to the Windows OS kernel and to software running in Windows.
• Device Guard components run in isolation from the Windows kernel and is secured by a Windows Hyper-V container called Virtual Secure Mode (VSM).
• Device Guard uses a policy-based system which defines various attributes to identify code that is trusted during the endpoint’s boot process, loading of the Windows OS kernel and applications running when the full OS loads.
• Various risks in the organization caused by the failures of other security systems and inadequate processes exacerbate endpoint security when Device Guard is not used or not implemented in the most secure manner.

Microsoft has written a comprehensive Device Guard Deployment Guide, which provides detailed step-by-step instructions to get you going. However, it is a rather long read. In this blog, I’ve distilled the information in the guide, leaving you with a high-level understanding, as well as the steps and tasks to execute and deploy Device Guard in the enterprise.
It is evident that Device Guard provides revolutionary endpoint security in Windows 10; a formidable opponent and offense against viruses, malware, bad actors and other modern day threats. Time to start taking advantage of it and securing the enterprise!!

What are the prerequisites?

Device Guard has a number of prerequisites, the core of which are Windows 10 64-bit (Enterprise, Enterprise LTSB and Education editions) with Hyper-V and Configurable Code Integrity features enabled to provide Virtualization-Based Security (VBS).
The endpoint must also meet the following firmware, hardware and processor capabilities:

• UEFI firmware with GUID Partition Table (GPT) disk and Secure Boot enabled
• Processor virtualization extensions (Intel VT-x / AMD-V)
• Second Level Address Translation (SLAT), fast-forward to 0:13:06
• Input-Output Memory Management Units (IOMMU) (Intel VT-d / AMD-Vi), fast-forward to 0:12:55
• Trusted Platform Module (TPM) 1.2 or 2.0

Active Directory is required and Public Key Infrastructure (PKI) may be required as well:

• Group Policy – centrally enable and configure virtualization based security settings on endpoints, deploy Catalog files and Code Integrity policies.

Note: Remember to import the Administrative Templates for Windows 10 with the recommendation of creating a Group Policy Central Store. The templates will be available from all domain controllers where the Group Policy Management Console is run.

• File-share – a UNC-path stored in the Group Policy to where Catalog files are located. The UNC-path should be accessible by all Device Guard enabled computers so that new Catalog files can be downloaded locally.
• Code signing certificate – digitally sign custom developed/in-house applications when they are developed, and Code Integrity policies and catalog files before they are deployed.

For more details on prerequisites refer to Hardware considerations.

How to best implement Device Guard

A secure implementation of Device Guard should be top priority. Giving consideration for the following processes and tasks will help to ensure its success.

Deploying Windows 10 (but of course!)

• Device Guard is exclusive to Windows 10, and its implementation can only be as successful as the Windows 10 deployment. Take a look at the Windows 10 Now solution offering to get an overview of how 1E can help.

Assess the status of and enable endpoint support for secure hardware configurations in Windows 10

• Microsoft System Center Configuration Manager (ConfigMgr) and management tools from the PC manufacturers will be instrumental in determining Device Guard readiness in the enterprise. 1E Technology Architect Mike Terrill, has provided a wealth of information in several blogs he’s written on the topic:
  • Getting Ready for Windows 10 Using Configuration Manager Inventory
  • What is UEFI and Why Do I Need It?
  • Automating Dell BIOS-UEFI Standards for Windows 10
  • Inventory Secure Boot State and UEFI with ConfigMgr
  • How to Inventory HP BIOS and UEFI Settings with ConfigMgr
  • How to Inventory Lenovo BIOS and UEFI Settings with ConfigMgr
• Intelligence is a free and light-weight tool from 1E that includes a Windows 10 Readiness Dashboard. The dashboard provides visibility into the progress of the organization’s Windows 10 deployment and shows the percentage of endpoints that have the proper hardware components and OS configurations to support advance security features in Windows 10 like Device Guard, Credential Guard and UEFI & Secure Boot.

Learning the application footprint of the organization

A successful Device Guard implementation relies on having accurate information about the application footprint of the organization, answering questions like – What applications are installed? Are the applications being used? Who is using the applications and what roles, and business units and/or departments are they associated with?

• 1E AppClarity establishes visibility into an organization’s application footprint through analysis of inventoried data from ConfigMgr. AppClarity normalizes inventoried data so that application titles are accurately identified and counted, while providing historical usage information over a period of time. Having this information is beneficial because the Device Guard Code Integrity policies can be reconciled against the AppClarity analysis data to know what endpoints the policies should be targeted for.

Note: Similar information can be derived from Asset Intelligence reporting and Software Inventory in ConfigMgr and Microsoft’s Application Compatibility Toolkit (ACT). However, consideration should be given to the additional effort required to normalize and rationalize the inventoried data.

Note: Device Guard Code Integrity policies running in Audit Mode can also show you what applications are installed in the environment. The challenge in this strategy is that it cannot be used until after Windows 10 and Device Guard has been deployed, whereas 1E AppClarity and the other tools mentioned earlier can be leveraged before, during, and after deploying Windows 10 and Device Guard.

• Understanding the “types” of applications in the organization is important because each application-type has specific ways to make them trustworthy by Device Guard e.g. digitally signed and catalog files for unsigned apps. The following table shows the various applications-types that can be installed on Windows 10 and how they are trusted:

Note: For more information about what it means in Device Guard for an application to be “trustworthy”, in the second blog of the series, read the section “Policy driven. Trustworthy guaranteed.”

• As we learn more about the relationships between applications, users, and their PCs, the applications used by each line-of-business, department, and business unit become clear. In some instances, it may be appropriate to further define the relationships based on the role of the user or the PC itself. Device Guard deployment scenarios give some guidance on organizing PC’s into “work-loads.” Following any one or all of the above options will simplify how Code Integrity policies and Catalog files are created and managed, aligning the process with the organizational and administrative model of the business.

Creating and testing Catalog files and Code Integrity policies in Audit Mode

When you are ready to create and test Catalog files and Code Integrity policies, reference PCs should be built corresponding to the different application usage categories defined earlier. Along with Windows 10 being installed, ensure that the reference PCs have the required Windows features and hardware-based security features installed and configured properly.
The following provides a high-level overview of the steps involved with creating and testing Catalog files and Code Integrity policies from a reference PC:

Catalog files

1. Create a “temporary” Code Integrity policy (not an enforced policy, but running in Audit Mode) to scan for the installed applications. This is required before creating the Catalog files in subsequent steps.
2. Create Catalog files to add unsigned applications to the existing code integrity policy. Start by installing the unsigned applications on the reference PC. After each application is installed, the PackageInspector.exe tool will scan the reference PC to discover the source-files of the application, and the installed binaries created by the application’s installer. When the PackageInspector.exe scan is stopped, it will create a corresponding catalog file for the unsigned application. Optionally, multiple unsigned applications can be added to a single catalog file instead of creating one for each installed application.
3. Download the SignTool.exe Windows 10 Software Development Kit (SDK) utility to digitally sign the Catalog file(s) so that the discovered unsigned applications can be trusted by Device Guard. After installing the SDK on a Windows 10 computer, SignTool.exe can be found in the \Bin folder of the SDK installation-path.

Code Integrity policies

1. Install all trusted and digitally signed applications on the reference PC.

Note: This must be done before creating the new code integrity policy.

2. Create the Code Integrity policy in Audit Mode
3. Scan the reference computer for the installed applications
4. Convert the policy to binary format

For comprehensive description and details of the steps involved, read the following sections of the Device Guard Deployment Guide:

• Catalog files
• Code Integrity policies

Implementing Code Integrity policies in Enforcement Mode

By this time, the Code Integrity policies should be finalized, with both signed and unsigned applications in the environment that are now known and trusted. In following the guidance earlier about learning the application footprint of the organization, a single code integrity policy file for each application usage category defined may have been created. Rather than categorizing application usage by line-of-business, it may have been chosen to create a code integrity policy for each supported corporate image instead. If you end up with multiple policy files, they can be merged into a single Device Guard policy for the entire organization.
It’s now time enforce and implement the code integrity policy to secure the endpoints.
The key steps to implementing the policy in enforcement mode are:

• Ensure that the audit mode rule option is removed from the policy e.g. 3 Enabled:Audit Mode (Default)

  •  Set-RuleOption -Option 3 -FilePath $EnforcedCIPolicy -Delete

• Convert the policy file (.xml) to binary format e.g.

  •  ConvertFrom-CIPolicy $EnforcedCIPolicy $CIPolicyBin

• To further secure the policy – making it difficult to be tampered with – consider signing the policy with a Device Guard signing certificate.

This is not an exhaustive list of the final steps and so it is highly recommended to read and pay close attention to the detailed steps documented in Code Integrity policies.

Tools used to Deploy and Manage Device Guard

General guidance and blog resources were provided earlier to help prepare endpoints for Device Guard. You’re likely to be using ConfigMgr and/or Microsoft Intune to manage Windows 10 PC’s in the environment. The following table shows the roles and relationship of these and other tools, and the tasks they execute towards deploying and managing Device Guard:

Summary

To summarize the key points of the third blog in the series:

• Device Guard requires specific firmware, hardware configured and operating system components enabled.
• Assessing the enterprise’s readiness for Device Guard involves inventorying the secure configuration status of endpoints. 1E Technology Architect Mike Terrill, has written blogs to help assess and prepare endpoints for the Device Guard deployment.
• Code Integrity policies and Catalog files define what signed and unsigned applications are trusted by Device Guard.
• Device Guard can be deployed and managed using various tools, infrastructure and enterprise system management platforms. There is no single way to accomplish the goal.