mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-06-16 02:43:43 +00:00
Still trying to fix broken formatting
This commit is contained in:
LizRoss
@ -18,8 +18,6 @@ author: brianlic-msft
|
||||
Microsoft Device Guard is a feature set that consists of both hardware and software system integrity hardening features that revolutionize the Windows operating system’s security. Windows 10 employs Device Guard as well as code integrity and advanced hardware features such as CPU virtualization extensions, Trusted Platform Module, and second-level address translation to offer comprehensive modern security to its users. This guide explores the individual features in Device Guard as well as how to plan for, configure, and deploy them.
|
||||
|
||||
## Introduction to Device Guard
|
||||
|
||||
|
||||
Today’s security threat landscape is more aggressive than ever before. Modern malicious attacks are focused on revenue generation, intellectual property theft, and targeted system degradation, which results in financial loss. Many of these modern attackers are sponsored by nation states with unknown motives and large cyber terrorism budgets. These threats can enter a company through something as simple as an email message and can permanently damage its reputation for securing its software assets, as well as having significant financial impact. Windows 10 introduces several new security features that help mitigate a large percentage of today’s known threats.
|
||||
|
||||
It is estimated that more than 300,000 new malware variants are discovered daily. Unfortunately, companies currently use an ancient method to discover this infectious software and prevent its use. In fact, current PCs trust everything that runs until malware signatures determine whether a threat exists; then, the antimalware software attempts to clean the PC, often after the malicious software’s effect has already been noticed. This signature-based system focuses on reacting to an infection and ensuring that the particular infection does not happen again. In this model, the system that drives malware detection relies on the discovery of malicious software; only then can a signature be provided to the client to remediate it, which implies that a computer must be infected first. The time between the detection of the malware and a client being issued a signature could mean the difference between losing data and staying safe.
|
||||
@ -31,8 +29,6 @@ Device Guard breaks the current model of detection first-block later, and allows
|
||||
Device Guard's features revolutionize the Windows operating system’s security by taking advantage of new virtualization-based security (VBS) options and the trust-nothing mobile device operating system model, which makes its defenses much more difficult for malware to penetrate. By using configurable code integrity policies, organizations are able to choose exactly which applications are allowed to run in their environment. Configurable code integrity is not limited to Windows Store applications and can be used with existing unsigned or signed Win32 applications, without the requirement that the application be repackaged. In addition, configurable code integrity can be deployed as an individual feature if organizations don’t possess the required hardware for Device Guard. Along with code integrity, Windows 10 leverages advanced hardware features such as CPU virtualization extensions, input/output memory management units (IOMMUs), Trusted Platform Module (TPM), and second-level address translation (SLAT) to offer comprehensive modern security to its users. Device Guard deployed with configurable code integrity and Credential Guard will be among the most impactful client-side security deployments an organization can implement today. In this guide, you learn about the individual features found within Device Guard as well as how to plan for, configure, and deploy them. Device Guard with configurable code integrity is intended for deployment alongside additional threat-mitigating Windows features such as Credential Guard and AppLocker.
|
||||
|
||||
## Device Guard overview
|
||||
|
||||
|
||||
Device Guard is a feature set that consists of both hardware and software system integrity hardening features. These features revolutionize the Windows operating system’s security by taking advantage of 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—exactly what has made mobile phone security so successful. In addition, 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 provides organizations with a way to trust individual third-party applications. Device Guard—with configurable code integrity, Credential Guard, and AppLocker—is the most complete security defense that any Microsoft product has ever been able to offer a Windows client.
|
||||
|
||||
Advanced hardware features such as CPU virtualization extensions, IOMMUs, and SLAT, drive these new client security offerings. By integrating these hardware features further into the core operating system, Windows 10 leverages them in new ways. For example, the same type 1 hypervisor technology that is used to run virtual machines in Microsoft Hyper-V is used to isolate core Windows services into a virtualization-based, protected container. This is just one example of how Windows 10 integrates advanced hardware features deeper into the operating system to offer comprehensive modern security to its users. These hardware features are now available in consumer and enterprise PC markets and are discussed in detail in the [Hardware considerations](#hardware) section.
|
||||
@ -63,8 +59,6 @@ Although AppLocker is not considered a new Device Guard feature, it complements
|
||||
|
||||
**Note** One example in which Device Guard functionality needs AppLocker supplementation is when your organization would like to limit universal applications. Universal applications have already been validated by Microsoft to be trustworthy to run, but an organization may not want to allow specific universal applications to run in their environment. You can accomplish this enforcement by using an AppLocker rule.
|
||||
|
||||
|
||||
|
||||
AppLocker and Device Guard should run side-by-side in your organization, which offers the best of both security features at the same time and provides the most comprehensive security to as many devices as possible. In addition to these features, Microsoft recommends that you continue to maintain an enterprise antivirus solution for a well-rounded enterprise security portfolio.
|
||||
|
||||
### <a href="" id="dg-with-cg"></a>
|
||||
@ -86,9 +80,8 @@ You can easily manage Device Guard features by using the familiar enterprise and
|
||||
- **Windows PowerShell**. Windows PowerShell is primarily used to create and service code integrity policies. These policies represent the most powerful component of Device Guard. For a step-by-step walkthrough of how to create, audit, service, enforce, and deploy code integrity policies, see the [Code integrity policies](#code-integrity-policies) section.
|
||||
|
||||
These options provide the same experience you are used to in order to manage your existing enterprise management solutions. For more information about how to manage and deploy Device Guard hardware and code integrity features in your organization, see the [Device Guard deployment](#dg-deployment) section.
|
||||
|
||||
## Plan for Device Guard
|
||||
|
||||
|
||||
In this section, you will learn about the following topics:
|
||||
|
||||
- [Approach enterprise code integrity deployment](#approach-enterprise). Device Guard deployment in your organization requires a planned approach. In this section, you get high-level recommendations for how to approach enterprise code integrity deployment in your organization.
|
||||
@ -101,12 +94,9 @@ In this section, you will learn about the following topics:
|
||||
|
||||
## <a href="" id="approach-enterprise"></a>Approach enterprise code integrity deployment
|
||||
|
||||
|
||||
Enterprises that want to consider Device Guard should not expect deployment to their entire organization overnight. Device Guard implementation requires that you plan for both end-user and IT pro impact. In addition, the deployment of Device Guard features to your enterprise requires a planned, phased approach to ensure that end-user systems are fully capable and ready to enforce these new security restrictions. Perform the following high-level tasks to approach the deployment of Device Guard to your enterprise:
|
||||
|
||||
1. **Group devices into similar functions**. Categorize machines into the groups described in the [Device Guard deployment scenarios](#device-guard-deployment) section. This begins the roadmap for your Device Guard deployment and provides groups of easier and more difficult implementations. From there, assess the quantity of necessary Device Guard policies. The easiest solution is to lock down your entire enterprise, but it might not fit your individual departments’ needs.
|
||||
|
||||
To discover an appropriate number of policies for your organization, try to separate the defined groups into departments or roles. Then ask some questions: What software does each department or role need to do their job? Should they be able to install and run other departments’ software? Do we need to create a base code integrity policy that aligns with our application catalog? Should users be able to install any application or only choose from an “allowed” list? Do we allow users to use their own peripheral devices? These questions will help you discover the number of necessary policies for your organization. Finally, try to focus on which people or departments would require an additional level of privileges. For example, should department x be able to install and run application xyz, even though no other department does? If the answer is yes and justifiable, you will need a secondary code integrity policy for that group. If not, you will likely be able to merge several policies to simplify management. For more information about configurable code integrity policies, see the [Code integrity policies](#code-integrity-policies) section.
|
||||
1. **Group devices into similar functions**. Categorize machines into the groups described in the [Device Guard deployment scenarios](#device-guard-deployment) section. This begins the roadmap for your Device Guard deployment and provides groups of easier and more difficult implementations. From there, assess the quantity of necessary Device Guard policies. The easiest solution is to lock down your entire enterprise, but it might not fit your individual departments’ needs.<p>To discover an appropriate number of policies for your organization, try to separate the defined groups into departments or roles. Then ask some questions: What software does each department or role need to do their job? Should they be able to install and run other departments’ software? Do we need to create a base code integrity policy that aligns with our application catalog? Should users be able to install any application or only choose from an “allowed” list? Do we allow users to use their own peripheral devices? These questions will help you discover the number of necessary policies for your organization. Finally, try to focus on which people or departments would require an additional level of privileges. For example, should department x be able to install and run application xyz, even though no other department does? If the answer is yes and justifiable, you will need a secondary code integrity policy for that group. If not, you will likely be able to merge several policies to simplify management. For more information about configurable code integrity policies, see the [Code integrity policies](#code-integrity-policies) section.
|
||||
|
||||
2. **Create code integrity policies from “golden” PCs**. After you create the groups of devices, you can create code integrity policies to align with those groups, similar to the way you would manage corporate images. When you have separated these groups and set up golden PCs that mimic the software and hardware those individual groups require, create code integrity policies from each of them. After you create these, you can merge these code integrity policies to create a master policy, or you can manage and deploy them individually. For step-by-step instructions about how to create code integrity policies, see the [Create code integrity policies from golden PCs](#create-code-golden) section.
|
||||
|
||||
@ -120,7 +110,6 @@ Enterprises that want to consider Device Guard should not expect deployment to t
|
||||
|
||||
## <a href="" id="device-guard-deployment"></a>Device Guard deployment scenarios
|
||||
|
||||
|
||||
To help simplify the deployment of Device Guard to your organization, Microsoft recommends that you group devices into the deployment scenarios described in this section. Device Guard is not a feature that organizations will just simply “turn on”; rather, it typically requires a phased implementation approach. To see where these scenarios fit into an overall Device Guard deployment approach, see the [Approach to enterprise code integrity deployment](#approach-enterprise) section.
|
||||
|
||||
**Fixed-workload devices**
|
||||
@ -131,8 +120,6 @@ Device Guard components that are applicable to fixed-workload devices include:
|
||||
|
||||
- KMCI VBS protection
|
||||
|
||||
<!-- -->
|
||||
|
||||
- Enforced UMCI policy
|
||||
|
||||
**Fully managed devices**
|
||||
@ -163,7 +150,6 @@ Device Guard is not a good way to manage devices in a Bring Your Own Device (BYO
|
||||
|
||||
## Code signing adoption
|
||||
|
||||
|
||||
Code signing is crucial to the successful implementation of configurable code integrity policies. These policies can trust the signing certificates from both independent software vendors and customers. In Windows 10, all Windows Store applications are signed. Also, you can easily trust any other signed application by adding the signing certificate to the code integrity policy.
|
||||
|
||||
For unsigned applications, customers have multiple options for signing them so that code integrity policies can trust them. The first option is traditional embedded code signing. Organizations that have in-house development teams can incorporate binary code signing into their application development process, and then simply add the signing certificate to their code integrity policies. The second option for signing unsigned applications is to use catalog files. In Windows 10, customers have the ability to create catalog files as they monitor the installation and initial run of an application. For more information about signing existing unsigned LOB applications or third-party applications, see the [Existing line-of-business applications](#existing-lob) section.
|
||||
@ -177,8 +163,6 @@ Until now, existing LOB applications were difficult to trust if they were signed
|
||||
**Note**
|
||||
Catalog files are lists of individual binaries’ hash values. If the scanned application is updated, you will need to create a new catalog file. That said, binary signing is still highly recommended for any future applications so that no catalog files are needed.
|
||||
|
||||
|
||||
|
||||
When you create a catalog file, you must sign it by using enterprise public key infrastructure (PKI), or a purchased code signing certificate. When signed, code integrity policies can trust the signer or signing certificate of those files. For information about catalog file signing, see the [Catalog files](#catalog-files) section.
|
||||
|
||||
**Application development**
|
||||
@ -255,7 +239,6 @@ Different hardware features are required to implement the various features of De
|
||||
|
||||
## <a href="" id="dg-deployment"></a>Device Guard deployment
|
||||
|
||||
|
||||
In this section, you learn about the following topics:
|
||||
|
||||
- [Configure hardware-based security features](#configure-hardware). This section explains how to enable the hardware-based security features in Device Guard. Also, you verify that the features are enabled by using both Windows Management Infrastructure (WMI) and Msinfo32.exe.
|
||||
@ -266,7 +249,6 @@ In this section, you learn about the following topics:
|
||||
|
||||
## <a href="" id="configure-hardware"></a>Configure hardware-based security features
|
||||
|
||||
|
||||
Hardware-based security features make up a large part of Device Guard security offerings. VBS reinforces the most important feature of Device Guard: configurable code integrity. There are three steps to configure hardware-based security features in Device Guard:
|
||||
|
||||
1. **Verify that hardware requirements are met and enabled**. Verify that your client machines possess the necessary hardware to run these features. A list of hardware requirements for the hardware-based security features is available in the [Hardware considerations](#hardware) section.
|
||||
@ -284,8 +266,6 @@ In addition to the hardware requirements found in the [Hardware considerations](
|
||||
**Note**
|
||||
You can configure these features manually by using Windows PowerShell or Deployment Image Servicing and Management. For specific information about these methods, refer to the [Credential Guard documentation](http://go.microsoft.com/fwlink/p/?LinkId=624529).
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Figure 1. Enable operating system features for VBS
|
||||
@ -301,8 +281,6 @@ Before you begin this process, verify that the target device meets the hardware
|
||||
**Note**
|
||||
There are two platform security levels for Secure Boot: stand-alone Secure Boot and Secure Boot with DMA protection. DMA protection provides additional memory protection but will be enabled only on systems whose processors include DMA protection (IOMMU) technologies. Without the presence of IOMMUs and with DMA protection disabled, customers will lose protection from driver-based attacks.
|
||||
|
||||
|
||||
|
||||
1. Navigate to the **HKEY\_LOCAL\_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\DeviceGuard** registry subkey.
|
||||
|
||||
2. Set the **EnableVirtualizationBasedSecurity DWORD** value to **1**.
|
||||
@ -320,37 +298,24 @@ Unfortunately, it would be time consuming to perform these steps manually on eve
|
||||
**Note**
|
||||
Microsoft recommends that you test-enable this feature on a group of test machines before you deploy it to machines that are currently deployed to users.
|
||||
|
||||
|
||||
|
||||
**Use Group Policy to deploy Secure Boot**
|
||||
|
||||
<a href="" id="bkmk-depsecureboot"></a>
|
||||
1. To create a new GPO, right-click the OU to which you want to link the GPO, and then click **Create a GPO in this domain, and Link it here**.
|
||||
|
||||
|
||||
|
||||
Figure 2. Create a new OU-linked GPO
|
||||
1. To create a new GPO, right-click the OU to which you want to link the GPO, and then click **Create a GPO in this domain, and Link it here**.<p>
|
||||
<br>Figure 2. Create a new OU-linked GPO
|
||||
|
||||
2. Name the new GPO **Contoso Secure Boot GPO Test**. This example uses *Contoso Secure Boot GPO Test* as the name of the GPO. You can choose any name for this example. Ideally, the name would align with your existing GPO naming convention.
|
||||
|
||||
3. To open the Group Policy Management Editor, right-click the new GPO, and then click **Edit**.
|
||||
|
||||
4. Within the selected GPO, navigate to Computer Configuration\\Administrative Templates\\System\\Device Guard. Then, right-click **Turn On Virtualization Based Security**, and then click **Edit**.
|
||||
4. Within the selected GPO, navigate to Computer Configuration\\Administrative Templates\\System\\Device Guard. Then, right-click **Turn On Virtualization Based Security**, and then click **Edit**.<p>
|
||||
<br>Figure 3. Enable VBS
|
||||
|
||||
|
||||
5. Select the **Enabled** option, and then select **Secure Boot and DMA Protection** from the **Select Platform Security Level** list.<p>
|
||||
<br>Figure 4. Enable Secure Boot
|
||||
|
||||
Figure 3. Enable VBS
|
||||
|
||||
5. Select the **Enabled** option, and then select **Secure Boot and DMA Protection** from the **Select Platform Security Level** list.
|
||||
|
||||
|
||||
|
||||
Figure 4. Enable Secure Boot
|
||||
|
||||
**Note**
|
||||
Device Guard Secure Boot is maximized when combined with DMA protection. If your hardware contains the IOMMUs required for DMA protection, be sure to select the **Secure Boot and DMA Protection** platform security level. If your hardware does not contain IOMMU, there are several mitigations provided by leveraging Secure Boot without DMA Protection.
|
||||
|
||||
|
||||
**Note**<br>Device Guard Secure Boot is maximized when combined with DMA protection. If your hardware contains the IOMMUs required for DMA protection, be sure to select the **Secure Boot and DMA Protection** platform security level. If your hardware does not contain IOMMU, there are several mitigations provided by leveraging Secure Boot without DMA Protection.
|
||||
|
||||
6. Close the Group Policy Management Editor, and then restart the Windows 10 test computer. After you configure this setting, UEFI Secure Boot will be enabled upon restart.
|
||||
|
||||
@ -367,8 +332,6 @@ Before you begin this process, verify that the desired computer meets the hardwa
|
||||
**Note**
|
||||
All drivers on the system must be compatible with virtualization-based protection of code integrity; otherwise, your system may fail. Microsoft recommends that you enable this feature on a group of test machines before you enable it on deployed machines.
|
||||
|
||||
|
||||
|
||||
To configure virtualization-based protection of KMCI manually:
|
||||
|
||||
1. Navigate to the **HKEY\_LOCAL\_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\DeviceGuard** registry subkey.
|
||||
@ -382,15 +345,9 @@ It would be time consuming to perform these steps manually on every protected ma
|
||||
**Note**
|
||||
Microsoft recommends that you test-enable this feature on a group of test computers before you deploy it to machines that are currently deployed to users. If untested, there is a possibility that this feature can cause system instability and ultimately cause the client operating system to fail.
|
||||
|
||||
|
||||
|
||||
To use Group Policy to configure VBS of KMCI:
|
||||
|
||||
1. Create a new GPO: Right-click the OU to which you want to link the GPO, and then click **Create a GPO in this domain, and Link it here**.
|
||||
|
||||
|
||||
|
||||
Figure 5. Create a new OU-linked GPO
|
||||
1. Create a new GPO: Right-click the OU to which you want to link the GPO, and then click **Create a GPO in this domain, and Link it here**.<p><br>Figure 5. Create a new OU-linked GPO
|
||||
|
||||
2. Name the new GPO **Contoso VBS CI Protection GPO Test**.
|
||||
|
||||
@ -398,17 +355,9 @@ To use Group Policy to configure VBS of KMCI:
|
||||
|
||||
3. Open the Group Policy Management Editor: Right-click the new GPO, and then click **Edit**.
|
||||
|
||||
4. Within the selected GPO, navigate to Computer Configuration\\Administrative Templates\\System\\Device Guard. Then, right-click **Turn On Virtualization Based Security**, and then click **Edit**.
|
||||
4. Within the selected GPO, navigate to Computer Configuration\\Administrative Templates\\System\\Device Guard. Then, right-click **Turn On Virtualization Based Security**, and then click **Edit**.<p><br>Figure 6. Enable VBS
|
||||
|
||||
|
||||
|
||||
Figure 6. Enable VBS
|
||||
|
||||
5. Select the **Enabled** option, and then select the **Enable Virtualization Based Protection of Code Integrity** check box.
|
||||
|
||||
|
||||
|
||||
Figure 7. Enable VBS of KMCI
|
||||
5. Select the **Enabled** option, and then select the **Enable Virtualization Based Protection of Code Integrity** check box.<p><br>Figure 7. Enable VBS of KMCI
|
||||
|
||||
6. Close the Group Policy Management Editor, and then restart the Windows 10 test computer. With this setting configured, the VBS of the KMCI will take effect upon restart.
|
||||
|
||||
@ -437,15 +386,9 @@ To avoid spending an unnecessary amount of time in manual deployments, use Group
|
||||
**Note**
|
||||
Microsoft recommends that you enable Credential Guard before you join a machine to the domain to ensure that all credentials are properly protected. Setting the appropriate registry subkeys during your imaging process would be ideal to achieve this protection.
|
||||
|
||||
|
||||
|
||||
To use Group Policy to enable Credential Guard:
|
||||
|
||||
1. Create a new GPO: right-click the OU to which you want to link the GPO, and then click **Create a GPO in this domain, and Link it here** .
|
||||
|
||||
|
||||
|
||||
Figure 8. Create a new OU-linked GPO
|
||||
1. Create a new GPO: right-click the OU to which you want to link the GPO, and then click **Create a GPO in this domain, and Link it here**.<p><br>Figure 8. Create a new OU-linked GPO
|
||||
|
||||
2. Name the new GPO **Contoso Credential Guard GPO Test**.
|
||||
|
||||
@ -453,32 +396,20 @@ To use Group Policy to enable Credential Guard:
|
||||
|
||||
3. Open the Group Policy Management Editor: right-click the new GPO, and then click **Edit**.
|
||||
|
||||
4. Within the selected GPO, navigate to Computer Configuration\\Administrative Templates\\System\\Device Guard. Right-click **Turn On Virtualization Based Security**, and then click **Edit**.
|
||||
4. Within the selected GPO, navigate to Computer Configuration\\Administrative Templates\\System\\Device Guard. Right-click **Turn On Virtualization Based Security**, and then click **Edit**.<p><br>Figure 9. Enable VBS
|
||||
|
||||
|
||||
|
||||
Figure 9. Enable VBS
|
||||
|
||||
5. Select the **Enabled** option, and then select the **Enable Credential Guard** check box.
|
||||
|
||||
|
||||
|
||||
Figure 10. Enable Credential Guard
|
||||
5. Select the **Enabled** option, and then select the **Enable Credential Guard** check box.<p><br>Figure 10. Enable Credential Guard
|
||||
|
||||
6. Close Group Policy Management Editor, and then restart the Windows 10 test computer.
|
||||
|
||||
**Note**
|
||||
The default platform security level is **Secure Boot**. If IOMMUs are available within the protected machines, it is recommended that you select **Secure Boot and DMA Protection** to maximize the mitigations that are available through Credential Guard.
|
||||
|
||||
|
||||
|
||||
**Note**<br>
|
||||
The default platform security level is **Secure Boot**. If IOMMUs are available within the protected machines, it is recommended that you select **Secure Boot and DMA Protection** to maximize the mitigations that are available through Credential Guard.
|
||||
|
||||
7. Check the test client event log for Device Guard GPOs.
|
||||
|
||||
**Note**
|
||||
All processed Device Guard policies are logged in event viewer under Application and Services Logs\\Microsoft\\Windows\\DeviceGuard-GPEXT\\Operational.
|
||||
|
||||
|
||||
|
||||
For additional information about how Credential Guard works as well as additional configuration options, please refer to the [Credential Guard documentation](http://go.microsoft.com/fwlink/p/?LinkId=624529).
|
||||
|
||||
**Validate enabled Device Guard hardware-based security features**
|
||||
@ -492,8 +423,6 @@ The *Win32\_DeviceGuard* WMI class is only available on the Enterprise edition o
|
||||
|
||||
The output of this command provides details of the available hardware-based security features as well as those features that are currently enabled. For detailed information about what each property means, refer to Table 1.
|
||||
|
||||
|
||||
|
||||
Table 1. Win32\_DeviceGuard properties
|
||||
|
||||
<table>
|
||||
@ -575,24 +504,14 @@ Table 1. Win32\_DeviceGuard properties
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
Another method to determine the available and enabled Device Guard features is to run msinfo32.exe from an elevated PowerShell session. When you run this program, the Device Guard properties are displayed at the bottom of the **System Summary** section, as shown in Figure 11.
|
||||
|
||||
|
||||
|
||||
Figure 11. Device Guard properties in the System Summary
|
||||
Another method to determine the available and enabled Device Guard features is to run msinfo32.exe from an elevated PowerShell session. When you run this program, the Device Guard properties are displayed at the bottom of the **System Summary** section, as shown in Figure 11.<p><br>Figure 11. Device Guard properties in the System Summary
|
||||
|
||||
## Catalog files
|
||||
|
||||
|
||||
Enforcement of Device Guard on a system requires that every trusted application have a signature or its binary hashes added to the code integrity policy. For many organizations, this can be an issue when considering unsigned LOB applications. To avoid the requirement that organizations repackage and sign these applications, Windows 10 includes a tool called Package Inspector that monitors an installation process for any deployed and executed binary files. If the tool discovers such files, it itemizes them in a catalog file. These catalog files offer you a way to trust your existing unsigned applications, whether developed in house or by a third party, as well as trust signed applications for which you do not want to trust the signer but rather the specific application. When created, these files can be signed, the signing certificates added to your existing code integrity policies, and the catalog files themselves distributed to the clients.
|
||||
|
||||
**Note**
|
||||
The Enterprise edition of Windows 10 or Windows Server 2016 is required to create and use catalog files.
|
||||
|
||||
|
||||
|
||||
### <a href="" id="create-catalog-files"></a>
|
||||
|
||||
**Create catalog files**
|
||||
@ -602,16 +521,12 @@ The creation of catalog files is the first step to add an unsigned application t
|
||||
**Note**
|
||||
When you establish a naming convention it makes it easier to detect deployed catalog files in the future. In this guide, you will use *\*-Contoso.cat* as the naming convention. For more information about why this practice is helpful to inventory or detect catalog files, see the [Inventory catalog files with System Center Configuration Manager](#inventory-cat-sccm) section.
|
||||
|
||||
|
||||
|
||||
1. Be sure that a code integrity policy is currently running in audit mode.
|
||||
|
||||
Package Inspector does not always detect installation files that have been removed from the machine during the installation process. To ensure that these binaries are also trusted, the code integrity policy that you created and audited in the [Create code integrity policies from golden PCs](#create-code-golden) and [Audit code integrity policies](#audit-code-integrity) sections should be deployed, in audit mode, to the system on which you are running Package Inspector.
|
||||
|
||||
**Note**
|
||||
This process should **not** be performed on a system running an enforced Device Guard policy, only with a policy running in audit mode. If a policy is currently being enforced, you will not be able to install and run the application.
|
||||
|
||||
|
||||
This process should **not** be performed on a system running an enforced Device Guard policy, only with a policy running in audit mode. If a policy is currently being enforced, you will not be able to install and run the application.
|
||||
|
||||
2. Start Package Inspector, and then scan drive C:
|
||||
|
||||
@ -620,8 +535,6 @@ When you establish a naming convention it makes it easier to detect deployed cat
|
||||
**Note**
|
||||
Package inspector can monitor installations on any local drive. In this example, we install the application on drive C, but any other drive can be used.
|
||||
|
||||
|
||||
|
||||
3. Copy the installation media to drive C.
|
||||
|
||||
By copying the installation media to drive C, you ensure that Package Inspector detects and catalogs the actual installer. If you skip this step, the future code integrity policy may trust the application to run but not be installed.
|
||||
@ -633,8 +546,6 @@ When you establish a naming convention it makes it easier to detect deployed cat
|
||||
**Note**
|
||||
Every binary that is run while Package Inspector is running will be captured in the catalog. Therefore, be sure not to run additional installations or updates during the scan to minimize the risk of trusting the incorrect binaries. Alternatively, if you want to add multiple applications to a single catalog file, simply repeat the installation and run process while the current scan is running.
|
||||
|
||||
|
||||
|
||||
5. Stop the scan, and then generate definition and catalog files. When application installation and initial setup are finished, stop the Package Inspector scan and generate the catalog and definition files on your desktop by using the following commands:
|
||||
|
||||
`$ExamplePath=$env:userprofile+"\Desktop"`
|
||||
@ -645,10 +556,8 @@ When you establish a naming convention it makes it easier to detect deployed cat
|
||||
|
||||
`PackageInspector.exe Stop C: -Name $CatFileName -cdfpath $CatDefName`
|
||||
|
||||
**Note**
|
||||
This scan catalogs the hash values for each discovered binary file. If the applications that were scanned are updated, complete this process again to trust the new binaries’ hash values.
|
||||
|
||||
|
||||
**Note**
|
||||
This scan catalogs the hash values for each discovered binary file. If the applications that were scanned are updated, complete this process again to trust the new binaries’ hash values.
|
||||
|
||||
When finished, the files will be saved to your desktop. To trust this catalog file within a code integrity policy, the catalog must first be signed. Then, the signing certificate can be included in the code integrity policy, and the catalog file can be distributed to the individual client machines. Catalog files can be signed by using a certificate and SignTool.exe, a free tool available in the Windows SDK. For more information about signing catalog files with SignTool.exe, see the [Catalog signing with SignTool.exe](#catsign-signtool) section.
|
||||
|
||||
@ -695,8 +604,6 @@ If you do not have a code signing certificate, please see the [Create a Device G
|
||||
**Note**
|
||||
In this example, you use the catalog file you created in the [Create catalog files](#create-catalog-files) section. If you are signing another catalog file, be sure to update the *$ExamplePath* and *$CatFileName* variables with the correct information.
|
||||
|
||||
|
||||
|
||||
2. Import the code signing certificate. Import the code signing certificate that will be used to sign the catalog file to the signing user’s personal store. In this example, you use the certificate that you created in the [Create a Device Guard code signing certificate](#create-dg-code) section.
|
||||
|
||||
3. Sign the catalog file with Signtool.exe:
|
||||
@ -716,18 +623,10 @@ If you do not have a code signing certificate, please see the [Create a Device G
|
||||
**Note**
|
||||
The *<Path to signtool.exe>* variable should be the full path to the Signtool.exe utility. *ContosoDGSigningCert* is the subject name of the certificate that you will use to sign the catalog file. This certificate should be imported to your personal certificate store on the machine on which you are attempting to sign the catalog file.
|
||||
|
||||
|
||||
|
||||
**Note**
|
||||
For additional information about Signtool.exe and all additional switches, visit [MSDN Sign Tool page](http://go.microsoft.com/fwlink/p/?LinkId=624163).
|
||||
|
||||
|
||||
|
||||
4. Verify the catalog file digital signature. Right-click the catalog file, and then click **Properties**. On the **Digital Signatures** tab, verify that your signing certificate exists with a **sha256** algorithm, as shown in Figure 12.
|
||||
|
||||
|
||||
|
||||
Figure 12. Verify that the signing certificate exists
|
||||
4. Verify the catalog file digital signature. Right-click the catalog file, and then click **Properties**. On the **Digital Signatures** tab, verify that your signing certificate exists with a **sha256** algorithm, as shown in Figure 12.<p><br>Figure 12. Verify that the signing certificate exists
|
||||
|
||||
5. Copy the catalog file to C:\\Windows\\System32\\catroot\\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}.
|
||||
|
||||
@ -742,17 +641,22 @@ To simplify the management of catalog files, you can use Group Policy preference
|
||||
**Note**
|
||||
This walkthrough requires that you have previously created a signed catalog file and have a Windows 10 client PC on which to test a Group Policy deployment. For more information about how to create and sign a catalog file, see the [Catalog files](#catalog-files) section.
|
||||
|
||||
|
||||
|
||||
To deploy a catalog file with Group Policy:
|
||||
|
||||
1. From either a domain controller or a client PC that has Remote Server Administration Tools (RSAT) installed, open the Group Policy Management Console (GPMC) by running **GPMC.MSC** or by searching for Group Policy Management.
|
||||
|
||||
2. Create a new GPO: Right-click the DG Enabled PCs OU, and then click **Create a GPO in this domain, and Link it here**, as shown in Figure 13.<p>**Note**<br>The DG Enabled PCs OU is just an example of where to link the test GPO that you created in this section. You can use any OU name. Also, security group filtering is an option when you consider policy partitioning options based on the strategy discussed in the [Approach enterprise code integrity deployment](#approach-enterprise) section.<p>
|
||||
<br>Figure 13. Create a new GPO
|
||||
2. Create a new GPO: Right-click the DG Enabled PCs OU, and then click **Create a GPO in this domain, and Link it here**, as shown in Figure 13.
|
||||
|
||||
**Note**<br>
|
||||
The DG Enabled PCs OU is just an example of where to link the test GPO that you created in this section. You can use any OU name. Also, security group filtering is an option when you consider policy partitioning options based on the strategy discussed in the [Approach enterprise code integrity deployment](#approach-enterprise) section.
|
||||
|
||||
|
||||
|
||||
Figure 13. Create a new GPO
|
||||
|
||||
3. Name the new GPO **Contoso DG Catalog File GPO Test**.<p>
|
||||
This example uses *Contoso DG Catalog File GPO Test* as the name of the GPO. You can choose any name you prefer for this example.
|
||||
3. Name the new GPO **Contoso DG Catalog File GPO Test**.
|
||||
|
||||
This example uses *Contoso DG Catalog File GPO Test* as the name of the GPO. You can choose any name you prefer for this example.
|
||||
|
||||
4. Open the Group Policy Management Editor: right-click the new GPO, and then click **Edit**.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user