deepblue/windows-itpro-docs
1
0
Fork 0
mirror of https://github.com/MicrosoftDocs/windows-itpro-docs.git synced 2025-05-15 14:57:23 +00:00
Code Issues Actions 3 Packages Projects Releases Wiki Activity

Merge branch 'wdac' of https://cpubwin.visualstudio.com/_git/it-client into wdac

Browse Source
This commit is contained in:
Justin Hall 2018-04-19 09:14:34 -07:00
commit e27d30d633
14 changed files with 12 additions and 878 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

17
windows/security/threat-protection/TOC.md
View File

@ -266,8 +266,8 @@
#### [Customize Exploit protection](windows-defender-exploit-guard/customize-exploit-protection.md) #### [Customize Exploit protection](windows-defender-exploit-guard/customize-exploit-protection.md)
##### [Import, export, and deploy Exploit protection configurations](windows-defender-exploit-guard/import-export-exploit-protection-emet-xml.md) ##### [Import, export, and deploy Exploit protection configurations](windows-defender-exploit-guard/import-export-exploit-protection-emet-xml.md)
#### [Memory integrity](windows-defender-exploit-guard/memory-integrity.md) #### [Memory integrity](windows-defender-exploit-guard/memory-integrity.md)
##### [Requirements and deployment planning guidelines for virtualization-based protection of code integrity](device-guard/requirements-and-deployment-planning-guidelines-for-device-guard.md) ##### [Requirements and deployment planning guidelines for virtualization-based protection of code integrity](windows-defender-exploit-guard/requirements-and-deployment-planning-guidelines-for-virtualization-based-protection-of-code-integrity.md)
##### [Enable virtualization-based protection of code integrity](device-guard/deploy-device-guard-enable-virtualization-based-security.md) ##### [Enable virtualization-based protection of code integrity](windows-defender-exploit-guard/enable-virtualization-based-protection-of-code-integrity.md)
### [Attack surface reduction](windows-defender-exploit-guard/attack-surface-reduction-exploit-guard.md) ### [Attack surface reduction](windows-defender-exploit-guard/attack-surface-reduction-exploit-guard.md)
#### [Evaluate Attack surface reduction](windows-defender-exploit-guard/evaluate-attack-surface-reduction.md) #### [Evaluate Attack surface reduction](windows-defender-exploit-guard/evaluate-attack-surface-reduction.md)
#### [Enable Attack surface reduction](windows-defender-exploit-guard/enable-attack-surface-reduction.md) #### [Enable Attack surface reduction](windows-defender-exploit-guard/enable-attack-surface-reduction.md)
@ -383,18 +383,7 @@
## [Control the health of Windows 10-based devices](protect-high-value-assets-by-controlling-the-health-of-windows-10-based-devices.md) ## [Control the health of Windows 10-based devices](protect-high-value-assets-by-controlling-the-health-of-windows-10-based-devices.md)
## [Device Guard deployment guide](device-guard/device-guard-deployment-guide.md) ## [Windows Defender Device Guard: virtualization-based security and WDAC](device-guard/introduction-to-device-guard-virtualization-based-security-and-windows-defender-application-control.md)
### [Introduction to Device Guard: virtualization-based security and WDAC](device-guard/introduction-to-device-guard-virtualization-based-security-and-windows-defender-application-control.md)
### [Requirements and deployment planning guidelines for Device Guard](device-guard/requirements-and-deployment-planning-guidelines-for-device-guard.md)
### [Planning and getting started on the Device Guard deployment process](device-guard/planning-and-getting-started-on-the-device-guard-deployment-process.md)
### [Deploy WDAC](device-guard/deploy-windows-defender-application-control.md)
#### [Optional: Create a code signing certificate for WDAC](device-guard/optional-create-a-code-signing-certificate-for-windows-defender-application-control.md)
#### [Deploy WDAC: policy rules and file rules](device-guard/deploy-windows-defender-application-control-policy-rules-and-file-rules.md)
#### [Steps to deploy WDAC](device-guard/steps-to-deploy-windows-defender-application-control.md)
#### [Deploy catalog files to support WDAC](device-guard/deploy-catalog-files-to-support-windows-defender-application-control.md)
#### [Deploy Managed Installer for Device Guard](device-guard/deploy-managed-installer-for-device-guard.md)
### [Deploy Device Guard: enable virtualization-based security](device-guard/deploy-device-guard-enable-virtualization-based-security.md)
## [Windows Defender SmartScreen](windows-defender-smartscreen/windows-defender-smartscreen-overview.md) ## [Windows Defender SmartScreen](windows-defender-smartscreen/windows-defender-smartscreen-overview.md)
### [Available Windows Defender SmartScreen Group Policy and mobile device management (MDM) settings](windows-defender-smartscreen/windows-defender-smartscreen-available-settings.md) ### [Available Windows Defender SmartScreen Group Policy and mobile device management (MDM) settings](windows-defender-smartscreen/windows-defender-smartscreen-available-settings.md)

11
windows/security/threat-protection/device-guard/deploy-catalog-files-to-support-windows-defender-application-control.md
View File

@ -1,11 +0,0 @@
---
title: Deploy catalog files to support code integrity policies (Windows 10)
description: This article describes how to deploy catalog files to support Windows Defender Application Control, one of the main features that are part of Windows Defender Device Guard in Windows 10.
keywords: virtualization, security, malware
ms.prod: w10
ms.mktglfcycl: deploy
ms.localizationpriority: high
author: brianlic-msft
ms.date: 10/27/2017
---

294
windows/security/threat-protection/device-guard/deploy-device-guard-enable-virtualization-based-security.md
View File

@ -1,294 +0,0 @@
---
title: Deploy Windows Defender Device Guard - enable virtualization-based security (Windows 10)
description: This article describes how to enable virtualization-based security, one of the main features that are part of Windows Defender Device Guard in Windows 10.
keywords: virtualization, security, malware
ms.prod: w10
ms.mktglfcycl: deploy
ms.localizationpriority: high
author: brianlic-msft
ms.date: 10/20/2017
---
# Enable virtualization-based protection of code integrity
**Applies to**
- Windows 10
- Windows Server 2016
Virtualization-based protection of code integrity (herein referred to as Hypervisor-protected Code Integrity, or HVCI) is a powerful system mitigation that leverages hardware virtualization and the Windows Hyper-V hypervisor to protect Windows kernel-mode processes against the injection and execution of malicious or unverified code. Code integrity validation is performed in a secure environment that is resistant to attack from malicious software, and page permissions for kernel mode are set and maintained by the Hyper-V hypervisor. When used with Windows Defender Application Control (WDAC), HVCI helps achieve a locked down configuration state known as Windows Defender Device Guard that can block many types of malware from running on computers running Windows 10 and Windows Server 2016.
> [!NOTE]
> Some applications, including device drivers, may be incompatible with HVCI. This can cause devices or software to malfunction and in rare cases may result in a Blue Screen. Such issues may occur after HVCI has been turned on or during the enablement process itself. We recommend testing thoroughly before enabling HVCI on production systems.
Use the following procedure to enable virtualization-based protection of code integrity:
1. **Decide whether to use the procedures in this topic, or to use the Windows Defender Device Guard readiness tool**. To enable HVCI, you can use [the Device Guard and Credential Guard hardware readiness tool](https://www.microsoft.com/en-us/download/details.aspx?id=53337) or follow the procedures in this topic.
2. **Verify that hardware and firmware requirements are met**. Verify that your client computers have the hardware and firmware to run HVCI. For a list of requirements, see [Requirements and deployment planning guidelines for virtualization-based protection of code integrity](./windows-defender-exploit-guard/requirements-and-deployment-planning-guidelines-for-virtualization-based-protection-of-code-integrity.md).
3. **Enable the necessary Windows features**. You can use the [hardware readiness tool](https://www.microsoft.com/en-us/download/details.aspx?id=53337) or see [Windows feature requirements for virtualization-based security](#windows-feature-requirements-for-virtualization-based-protection-of-code-integrity).
4. **Enable additional features as desired**. You can use the [hardware readiness tool](https://www.microsoft.com/en-us/download/details.aspx?id=53337) or see [Enable virtualization-based protection of code integrity](#enable-virtualization-based-protection-of-code-integrity).
## Windows feature requirements for virtualization-based protection of code integrity
Make sure these operating system features are enabled before you can enable HVCI:
- Beginning with Windows 10, version 1607 or Windows Server 2016:<br>
Hyper-V Hypervisor, which is enabled automatically. No further action is needed.
- With an earlier version of Windows 10:<br>
Hyper-V Hypervisor and Isolated User Mode (shown in Figure 1).
 
![Turn Windows features on or off](images/dg-fig1-enableos.png)
**Figure 1. Enable operating system features for HVCI, Windows 10, version 1511**
> [!NOTE]
> You can configure these features by using Group Policy or Dism.exe, or manually by using Windows PowerShell or the Windows Features dialog box.
## Enable virtualization-based protection of code integrity
If you don't want to use the [hardware readiness tool](https://www.microsoft.com/en-us/download/details.aspx?id=53337), you can use Group Policy or the Registry to enable HVCI.
### Use Group Policy to enable virtualization-based protection of code integrity
1. To create a new GPO, right-click the OU where you want to link the GPO, and then click **Create a GPO in this domain, and Link it here**.
![Group Policy Management, create a GPO](images/dg-fig2-createou.png)
Figure 2. Create a new OU-linked GPO
2. Give the new GPO a name, then right-click the new GPO, and click **Edit**.
4. Within the selected GPO, navigate to Computer Configuration\\Policies\\Administrative Templates\\System\\Device Guard. Right-click **Turn On Virtualization Based Security**, and then click **Edit**.
![Edit the group policy for Virtualization Based Security](images/dg-fig3-enablevbs.png)
Figure 3. Enable virtualization-based security (VBS)
5. Select the **Enabled** button. For **Select Platform Security Level**:
- **Secure Boot** provides as much protection as a computer’s hardware can support. If the computer does not have input/output memory management units (IOMMUs), enable **Secure Boot**.
- **Secure Boot with DMA** enables Secure Boot—and VBS itself—only on a computer that supports DMA, that is, a computer with IOMMUs. With this setting, any computer without IOMMUs will not have VBS or HVCI protection, although it can have WDAC enabled.
For **Virtualization Based Protection of Code Integrity**:
- Beginning with Windows 10, version 1607 and Windows Server 2016:<br>For an initial deployment or test deployment, we recommend **Enabled without lock**.<br>When your deployment is stable, we recommend changing to **Enabled with UEFI lock**. This option helps protect the registry from tampering, either through malware or by an unauthorized person.
- With earlier versions of Windows 10:<br>Select the **Enable Virtualization Based Protection of Code Integrity** check box.
![Group Policy, Turn On Virtualization Based Security](images/dg-fig7-enablevbsofkmci.png)
Figure 5. Configure HVCI, Lock setting (in Windows 10, version 1607)
7. Close the Group Policy Management Editor, and then restart the Windows 10 test computer. The settings will take effect upon restart.
8. Check Device Guard logs in Event Viewer at **Applications and Services Logs\\Microsoft\\Windows\\DeviceGuard-GPEXT\\Operational** for Event ID 7000, which contains the selected settings within a GPO that has been successfully processed. This event is logged only when Group Policy is used.
### Use registry keys to enable virtualization-based protection of code integrity
Set the following registry keys to enable HVCI. This provides exactly the same set of configuration options provided by Group Policy.
> [!IMPORTANT]
> - Among the commands that follow, you can choose settings for **Secure Boot** and **Secure Boot with DMA**. In most situations, we recommend that you choose **Secure Boot**. This option provides Secure Boot with as much protection as is supported by a given computer’s hardware. A computer with input/output memory management units (IOMMUs) will have Secure Boot with DMA protection. A computer without IOMMUs will simply have Secure Boot enabled.<br>In contrast, with **Secure Boot with DMA**, the setting will enable Secure Boot—and VBS itself—only on a computer that supports DMA, that is, a computer with IOMMUs. With this setting, any computer without IOMMUs will not have VBS or HVCI protection, although it can still have WDAC enabled.<br>
> - All drivers on the system must be compatible with virtualization-based protection of code integrity; otherwise, your system may fail. We recommend that you enable these features on a group of test computers before you enable them on users' computers.
#### For Windows 1607 and above
Recommended settings (to enable virtualization-based protection of Code Integrity policies, without UEFI Lock):
``` commands
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v "EnableVirtualizationBasedSecurity" /t REG_DWORD /d 1 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v "RequirePlatformSecurityFeatures" /t REG_DWORD /d 1 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v "Locked" /t REG_DWORD /d 0 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity" /v "Enabled" /t REG_DWORD /d 1 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity" /v "Locked" /t REG_DWORD /d 0 /f
```
If you want to customize the preceding recommended settings, use the following settings.
**To enable VBS**
``` command
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v "EnableVirtualizationBasedSecurity" /t REG_DWORD /d 1 /f
```
**To enable VBS and require Secure boot only (value 1)**
``` command
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v "RequirePlatformSecurityFeatures" /t REG_DWORD /d 1 /f
```
> To enable **VBS with Secure Boot and DMA (value 3)**, in the preceding command, change **/d 1** to **/d 3**.
**To enable VBS without UEFI lock (value 0)**
``` command
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v "Locked" /t REG_DWORD /d 0 /f
```
> To enable **VBS with UEFI lock (value 1)**, in the preceding command, change **/d 0** to **/d 1**.
**To enable virtualization-based protection of Code Integrity policies**
``` command
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity" /v "Enabled" /t REG_DWORD /d 1 /f
```
**To enable virtualization-based protection of Code Integrity policies without UEFI lock (value 0)**
``` command
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity" /v "Locked" /t REG_DWORD /d 0 /f
```
> To enable **virtualization-based protection of Code Integrity policies with UEFI lock (value 1)**, in the preceding command, change **/d 0** to **/d 1**.
#### For Windows 1511 and below
Recommended settings (to enable virtualization-based protection of Code Integrity policies, without UEFI Lock):
``` command
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v "EnableVirtualizationBasedSecurity" /t REG_DWORD /d 1 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v "RequirePlatformSecurityFeatures" /t REG_DWORD /d 1 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v "HypervisorEnforcedCodeIntegrity" /t REG_DWORD /d 1 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v "Unlocked" /t REG_DWORD /d 1 /f
```
If you want to customize the preceding recommended settings, use the following settings.
**To enable VBS (it is always locked to UEFI)**
``` command
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v "EnableVirtualizationBasedSecurity" /t REG_DWORD /d 1 /f
```
**To enable VBS and require Secure boot only (value 1)**
``` command
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v "RequirePlatformSecurityFeatures" /t REG_DWORD /d 1 /f
```
> To enable **VBS with Secure Boot and DMA (value 3)**, in the preceding command, change **/d 1** to **/d 3**.
**To enable virtualization-based protection of Code Integrity policies (with the default, UEFI lock)**
``` command
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v "HypervisorEnforcedCodeIntegrity" /t REG_DWORD /d 1 /f
```
**To enable virtualization-based protection of Code Integrity policies without UEFI lock**
``` command
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v "Unlocked" /t REG_DWORD /d 1 /f
```
### Validate enabled Windows Defender Device Guard hardware-based security features
Windows 10 and Windows Server 2016 have a WMI class for related properties and features: *Win32\_DeviceGuard*. This class can be queried from an elevated Windows PowerShell session by using the following command:
```powershell
Get-CimInstance –ClassName Win32_DeviceGuard –Namespace root\Microsoft\Windows\DeviceGuard
```
> [!NOTE]
> The *Win32\_DeviceGuard* WMI class is only available on the Enterprise edition of Windows 10.
The output of this command provides details of the available hardware-based security features as well as those features that are currently enabled.
#### AvailableSecurityProperties
This field helps to enumerate and report state on the relevant security properties for Windows Defender Device Guard.
| Value | Description |
|--------|-------------|
| **0.** | If present, no relevant properties exist on the device. |
| **1.** | If present, hypervisor support is available. |
| **2.** | If present, Secure Boot is available. |
| **3.** | If present, DMA protection is available. |
| **4.** | If present, Secure Memory Overwrite is available. |
| **5.** | If present, NX protections are available. |
| **6.** | If present, SMM mitigations are available. |
> [!NOTE]
> 4, 5, and 6 were added as of Windows 10, version 1607.
#### InstanceIdentifier
A string that is unique to a particular device. Valid values are determined by WMI.
#### RequiredSecurityProperties
This field describes the required security properties to enable virtualization-based security.
| Value | Description |
|--------|-------------|
| **0.** | Nothing is required. |
| **1.** | If present, hypervisor support is needed. |
| **2.** | If present, Secure Boot is needed. |
| **3.** | If present, DMA protection is needed. |
| **4.** | If present, Secure Memory Overwrite is needed. |
| **5.** | If present, NX protections are needed. |
| **6.** | If present, SMM mitigations are needed. |
> [!NOTE]
> 4, 5, and 6 were added as of Windows 10, version 1607.
#### SecurityServicesConfigured
This field indicates whether the Windows Defender Credential Guard or HVCI service has been configured.
| Value | Description |
|--------|-------------|
| **0.** | No services configured. |
| **1.** | If present, Windows Defender Credential Guard is configured. |
| **2.** | If present, HVCI is configured. |
#### SecurityServicesRunning
This field indicates whether the Windows Defender Credential Guard or HVCI service is running.
| Value | Description |
|--------|-------------|
| **0.** | No services running. |
| **1.** | If present, Windows Defender Credential Guard is running. |
| **2.** | If present, HVCI is running. |
#### Version
This field lists the version of this WMI class. The only valid value now is **1.0**.
#### VirtualizationBasedSecurityStatus
This field indicates whether VBS is enabled and running.
| Value | Description |
|--------|-------------|
| **0.** | VBS is not enabled. |
| **1.** | VBS is enabled but not running. |
| **2.** | VBS is enabled and running. |
#### PSComputerName
This field lists the computer name. All valid values for computer name.
Another method to determine the available and enabled Windows Defender Device Guard features is to run msinfo32.exe from an elevated PowerShell session. When you run this program, the Windows Defender Device Guard properties are displayed at the bottom of the **System Summary** section, as shown in Figure 6.
![Windows Defender Device Guard properties in the System Summary](images/dg-fig11-dgproperties.png)
Figure 6. Windows Defender Device Guard properties in the System Summary
## Related topics
- [Introduction to Windows Defender Device Guard: virtualization-based security and Windows Defender Application Control](introduction-to-device-guard-virtualization-based-security-and-windows-defender-application-control.md)
- [Deploy Windows Defender Application Control](deploy-windows-defender-application-control.md)

166
windows/security/threat-protection/device-guard/deploy-managed-installer-for-device-guard.md
View File

@ -1,166 +0,0 @@
---
title: Deploy Managed Installer for Windows Defender Device Guard (Windows 10)
description: Explains how you can use a managed installer to automatically authorize applications deployed and installed by a designated software distribution solution, such as System Center Configuration Manager.
keywords: virtualization, security, malware
ms.prod: w10
ms.mktglfcycl: deploy
ms.localizationpriority: high
author: mdsakibMSFT
ms.date: 10/20/2017
---
# Deploy Managed Installer for Windows Defender Application Control
Creating and maintaining application execution control policies has always been challenging, and finding ways to address this issue has been a frequently-cited request for customers of AppLocker and Windows Defender Application Control (WDAC).
This is especially true for enterprises with large, ever changing software catalogs.
Windows 10, version 1703 (also known as the Windows 10 Creators Update) provides a new option, known as a managed installer, that allows IT administrators to automatically authorize applications deployed and installed by a designated software distribution solution, such as System Center Configuration Manager.
A managed installer helps an IT admin balance security and manageability requirements when employing application execution control policies by providing an option that does not require specifying explicit rules for software that is being managed through a software distribution solution.
## How does a managed installer work?
A managed installer uses a new rule collection in AppLocker to specify one or more executables that are trusted by the organization as an authorized source for application deployment.
Specifying an executable as a managed installer will cause Windows to tag files that are written from the executable’s process (or processes it launches) as having originated from a trusted installation authority.
Once the IT administrator adds the Allow: Managed Installer option to a WDAC policy, the WDAC component will subsequently check for the presence of the origin information when evaluating other application execution control rules specified in the policy.
If there are no deny rules present for the file, it will be authorized based on the managed installer origin information.
> [!NOTE]
> Admins needs to ensure that there is a WDAC policy in place to allow the system to boot and run any other authorized applications that may not be deployed through a managed installer.
>
> Examples of WDAC policies available in C:\Windows\schemas\CodeIntegrity\ExamplePolicies help authorize Windows OS components, WHQL signed drivers and all Store apps.
> Admins can reference and customize them as needed for their Windows Defender Application Control deployment or create a custom WDAC policy as described in [Deploy Windows Defender Application Control: steps](steps-to-deploy-windows-defender-application-control.md#create-a-windows-defender-application-control-policy-from-a-reference-computer).
## Configuring a managed installer with AppLocker and Windows Defender Application Control
Setting up managed installer tracking and application execution enforcement requires applying both an AppLocker and WDAC policy with specific rules and options enabled.
There are three primary steps to keep in mind:
- Specify managed installers using the Managed Installer rule collection in AppLocker policy
- Enable service enforcement in AppLocker policy
- Enable the managed installer option in a WDAC policy
### Specify managed installers using the Managed Installer rule collection in AppLocker policy
The identity of the managed installer executable(s) is specified in an AppLocker policy in a Managed Installer rule collection.
Currently the AppLocker policy creation UI and cmdlets do not allow for directly specifying rules for the Managed Installer rule collection, however a text editor can be used to make the simple changes needed to an EXE or DLL rule collection policy to specify Type="ManagedInstaller".
An example of a valid Managed Installer rule collection is shown below.
```code
<RuleCollection Type="ManagedInstaller" EnforcementMode="AuditOnly">
<FilePublisherRule Id="6cc9a840-b0fd-4f86-aca7-8424a22b4b93" Name="CMM - CCMEXEC.EXE, 5.0.0.0+, Microsoft signed" Description="" UserOrGroupSid="S-1-1-0" Action="Allow">
<Conditions>
<FilePublisherCondition PublisherName="O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" ProductName="SYSTEM CENTER CONFIGURATION MANAGER" BinaryName="CCMEXEC.EXE">
<BinaryVersionRange LowSection="5.0.0.0" HighSection="*" />
</FilePublisherCondition>
</Conditions>
</FilePublisherRule>
<FilePublisherRule Id="780ae2d3-5047-4240-8a57-767c251cbb12" Name="CCM - CCMSETUP.EXE, 5.0.0.0+, Microsoft signed" Description="" UserOrGroupSid="S-1-1-0" Action="Allow">
<Conditions>
<FilePublisherCondition PublisherName="O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" ProductName="SYSTEM CENTER CONFIGURATION MANAGER" BinaryName="CCMSETUP.EXE">
<BinaryVersionRange LowSection="5.0.0.0" HighSection="*" />
</FilePublisherCondition>
</Conditions>
</FilePublisherRule>
</RuleCollection>
```
## Enable service enforcement in AppLocker policy
Since many installation processes rely on services, it is typically necessary to enable tracking of services.
Correct tracking of services requires the presence of at least one rule in the rule collection – a simple audit only rule will suffice.
For example:
```code
<RuleCollection Type="Dll" EnforcementMode="AuditOnly" >
<FilePathRule Id="86f235ad-3f7b-4121-bc95-ea8bde3a5db5" Name="Dummy Rule" Description="" UserOrGroupSid="S-1-1-0" Action="Deny">
<Conditions>
<FilePathCondition Path="%OSDRIVE%\ThisWillBeBlocked.dll" />
</Conditions>
</FilePathRule>
<RuleCollectionExtensions>
<ThresholdExtensions>
<Services EnforcementMode="Enabled" />
</ThresholdExtensions>
<RedstoneExtensions>
<SystemApps Allow="Enabled"/>
</RedstoneExtensions>
</RuleCollectionExtensions>
</RuleCollection>
<RuleCollection Type="Exe" EnforcementMode="AuditOnly">
<FilePathRule Id="9420c496-046d-45ab-bd0e-455b2649e41e" Name="Dummy Rule" Description="" UserOrGroupSid="S-1-1-0" Action="Deny">
<Conditions>
<FilePathCondition Path="%OSDRIVE%\ThisWillBeBlocked.exe" />
</Conditions>
</FilePathRule>
<RuleCollectionExtensions>
<ThresholdExtensions>
<Services EnforcementMode="Enabled" />
</ThresholdExtensions>
<RedstoneExtensions>
<SystemApps Allow="Enabled"/>
</RedstoneExtensions>
</RuleCollectionExtensions>
</RuleCollection>
```
### Enable the managed installer option in WDAC policy
In order to enable trust for the binaries laid down by managed installers, the Allow: Managed Installer option must be specified in your WDAC policy.
This can be done by using the [Set-RuleOption cmdlet](https://technet.microsoft.com/itpro/powershell/windows/configci/set-ruleoption).
An example of the managed installer option being set in policy is shown below.
```code
<Rules>
<Rule>
<Option>Enabled:Unsigned System Integrity Policy</Option>
</Rule>
<Rule>
<Option>Enabled:Advanced Boot Options Menu</Option>
</Rule>
<Rule>
<Option>Enabled:UMCI</Option>
</Rule>
<Rule>
<Option>Enabled:Inherit Default Policy</Option>
</Rule>
<Rule>
<Option>Enabled:Managed Installer </Option>
</Rule>
</Rules>
```
## Security considerations with managed installer
Since managed installer is a heuristic-based mechanism, it does not provide the same security guarantees that explicit allow or deny rules do.
It is best suited for deployment to systems where each user is configured as a standard user and where all software is deployed and installed by a software distribution solution, such as System Center Configuration Manager.
Users with administrator privileges or malware running as an administrator user on the system may be able to circumvent the intent of Windows Defender Application Control when the managed installer option is allowed.
If the authorized managed installer process performs installations in the context of a user with standard privileges, then it is possible that standard users or malware running as standard user may be able to circumvent the intent of Windows Defender Application Control.
Some application installers include an option to automatically run the application at the end of the installation process. If this happens when the installer is run by a managed installer, then the managed installer's heuristic tracking and authorization may continue to apply to all files created during the first run of the application. This could result in over-authorization for executables that were not intended.
To avoid this, ensure that the application deployment solution being used as a managed installer limits running applications as part of installation.
## Known limitations with managed installer
- Application execution control based on managed installer does not support applications that self-update.
If an application deployed by a managed installer subsequently updates itself, the updated application files will no longer include the managed installer origin information and will not be authorized to run.
Enterprises should deploy and install all application updates using the managed installer.
In some cases, it may be possible to also designate an application binary that performs the self-updates as a managed installer.
Proper review for functionality and security should be performed for the application before using this method.
- Although WDAC policies can be deployed in both audit and enforced mode, the managed installer option is currently only recommended for use with policies set to enforced except in lab environments.
Using the managed installer option with WDAC policies set to audit only may result in unexpected behavior if the policy is subsequently changed to enforced mode.
- Modern apps deployed through a managed installer will not be tracked by the managed installer heuristic and will need to be separately authorized in your WDAC policy.
- Executables that extract files and then attempt to execute may not be allowed by the managed installer heuristic.
In some cases, it may be possible to also designate an application binary that performs such an operation as a managed installer.
Proper review for functionality and security should be performed for the application before using this method.
- The managed installer heuristic does not authorize drivers.
The WDAC policy must have rules that allow the necessary drivers to run.
- In some cases, the code integrity logs where WDAC errors and warnings are written will contain error events for native images generated for .NET assemblies.
Typically, the error is functionally benign as a blocked native image will result in the corresponding assembly being re-interpreted.
Review for functionality and performance for the related applications using the native images maybe necessary in some cases.

16
windows/security/threat-protection/device-guard/deploy-windows-defender-application-control-policy-rules-and-file-rules.md
View File

@ -1,16 +0,0 @@
---
title: Deploy code integrity policies - policy rules and file rules (Windows 10)
description: This article provides information about two elements in code integrity policies, called policy rules and file rules. Code integrity policies are part of Windows Defender Device Guard in Windows 10.
keywords: virtualization, security, malware
ms.prod: w10
ms.mktglfcycl: deploy
ms.localizationpriority: high
author: brianlic-msft
ms.date: 02/27/2018
---
# Deploy Windows Defender Application Control: policy rules and file rules
**Applies to**
- Windows 10
- Windows Server 2016

33
windows/security/threat-protection/device-guard/deploy-windows-defender-application-control.md
View File

@ -1,33 +0,0 @@
---
title: Deploy Windows Defender Device Guard - deploy code integrity policies (Windows 10)
description: This article, and the articles it links to, describe how to create code integrity policies, one of the main features that are part of Windows Defender Device Guard in Windows 10.
keywords: virtualization, security, malware
ms.prod: w10
ms.mktglfcycl: deploy
ms.localizationpriority: high
author: brianlic-msft
ms.date: 10/20/2017
---
# Deploy Windows Defender Application Control
**Applies to**
- Windows 10
- Windows Server 2016
This section includes the following topics:
- [Optional: Create a code signing certificate for Windows Defender Application Control](optional-create-a-code-signing-certificate-for-windows-defender-application-control.md)
- [Deploy Windows Defender Application Control: policy rules and file rules](deploy-windows-defender-application-control-policy-rules-and-file-rules.md)
- [Deploy Windows Defender Application Control: steps](steps-to-deploy-windows-defender-application-control.md)
- [Deploy catalog files to support Windows Defender Application Control](deploy-catalog-files-to-support-windows-defender-application-control.md)
- [Deploy Managed Installer for Windows Defender Application Control](deploy-managed-installer-for-device-guard.md)
To increase the protection for devices that meet certain hardware requirements, you can use virtualization-based protection of code integrity with your Windows Defender Application Control (WDAC) policies.
- For requirements, see [Hardware, firmware, and software requirements for Windows Defender Device Guard](requirements-and-deployment-planning-guidelines-for-device-guard.md#hardware-firmware-and-software-requirements-for-windows-defender-device-guard) in "Requirements and deployment planning guidelines for Windows Defender Device Guard."
- For steps, see [Enable virtualization-based protection of code integrity](deploy-device-guard-enable-virtualization-based-security.md).
## Related topics
[Introduction to Windows Defender Device Guard: virtualization-based security and Windows Defender Application Control](introduction-to-device-guard-virtualization-based-security-and-windows-defender-application-control.md)

42
windows/security/threat-protection/device-guard/device-guard-deployment-guide.md
View File

@ -1,42 +0,0 @@
---
title: Windows Defender Device Guard deployment guide (Windows 10)
description: Microsoft Windows Defender 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.
ms.assetid: 4BA52AA9-64D3-41F3-94B2-B87EC2717486
keywords: virtualization, security, malware
ms.prod: w10
ms.mktglfcycl: deploy
ms.localizationpriority: high
author: brianlic-msft
ms.date: 10/20/2017
---
# Windows Defender Device Guard deployment guide
**Applies to**
- Windows 10
- Windows Server 2016
With thousands of new malicious files created every day, using traditional methods like antivirus solutions—signature-based detection to fight against malware—provides an inadequate defense against new attacks. Windows Defender Device Guard describes a locked-down device configuration state that uses multiple enterprise-related hardware and software security features that run on Windows 10 Enterprise edition and Windows Server. When these features are configured together, Windows Defender Device Guard changes from a mode where apps are trusted unless blocked by an antivirus or other security solution, to a mode where the operating system trusts only apps authorized by your enterprise. If the app isn’t trusted, it can’t run, period.
Windows Defender Device Guard also uses virtualization-based security to isolate the Code Integrity service and run it alongside the Windows kernel in a hypervisor-protected container. Even if an attacker manages to get control of the Windows kernel itself, the ability to run malicious executable code is much less likely.
This guide explores the individual features in Windows Defender Device Guard as well as how to plan for, configure, and deploy them. It includes:
- [Introduction to Windows Defender Device Guard: virtualization-based security and Windows Defender Application Control](introduction-to-device-guard-virtualization-based-security-and-windows-defender-application-control.md)
- [Requirements and deployment planning guidelines for Windows Defender Device Guard](requirements-and-deployment-planning-guidelines-for-device-guard.md)
- [Planning and getting started on the Windows Defender Device Guard deployment process](planning-and-getting-started-on-the-device-guard-deployment-process.md)
- [Deploy Windows Defender Application Control](deploy-windows-defender-application-control.md)
- [Optional: Create a code signing certificate for Windows Defender Application Control](optional-create-a-code-signing-certificate-for-windows-defender-application-control.md)
- [Deploy Windows Defender Application Control: policy rules and file rules](deploy-windows-defender-application-control-policy-rules-and-file-rules.md)
- [Deploy Windows Defender Application Control: steps](steps-to-deploy-windows-defender-application-control.md)
- [Deploy catalog files to support Windows Defender Application Control](deploy-catalog-files-to-support-windows-defender-application-control.md)
- [Enable virtualization-based protection of code integrity](deploy-device-guard-enable-virtualization-based-security.md)

105
windows/security/threat-protection/device-guard/optional-create-a-code-signing-certificate-for-windows-defender-application-control.md
View File

@ -1,105 +0,0 @@
---
title: Optional - Create a code signing certificate for code integrity policies (Windows 10)
description: This article describes how to create a code signing certificate for code integrity policies, one of the main features that are part of Windows Defender Device Guard in Windows 10.
keywords: virtualization, security, malware
ms.prod: w10
ms.mktglfcycl: deploy
ms.localizationpriority: high
author: brianlic-msft
ms.date: 10/20/2017
---
# Optional: Create a code signing certificate for Windows Defender Application Control
**Applies to**
- Windows 10
- Windows Server 2016
As you deploy Windows Defender Application Control (WDAC) (also part of Windows Defender Device Guard), you might need to sign catalog files or WDAC policies internally. To do this, you will either need a publicly issued code signing certificate or an internal CA. If you have purchased a code signing certificate, you can skip this topic and instead follow other topics listed in [Deploy Windows Defender Application Control](deploy-windows-defender-application-control.md).
If you have an internal CA, complete these steps to create a code signing certificate.
Only RSA algorithm is supported for the code signing certificate, and signatures must be PKCS 1.5 padded.
ECDSA is not supported.
1. Open the Certification Authority Microsoft Management Console (MMC) snap-in, and then select your issuing CA.
2. When connected, right-click **Certificate Templates**, and then click **Manage** to open the Certification Templates Console.
![CA snap-in showing Certificate Templates](images/dg-fig27-managecerttemp.png)
Figure 1. Manage the certificate templates
3. In the navigation pane, right-click the Code Signing certificate, and then click **Duplicate Template**.
4. On the **Compatibility** tab, clear the **Show resulting changes** check box. Select **Windows Server 2012** from the **Certification Authority** list, and then select **Windows 8 / Windows Server 2012** from the **Certificate recipient** list.
5. On the **General** tab, specify the **Template display name** and **Template name**. This example uses the name **WDAC Catalog Signing Certificate**.
6. On the **Request Handling** tab, select the **Allow private key to be exported** check box.
7. On the **Extensions** tab, select the **Basic Constraints** check box, and then click **Edit**.
8. In the **Edit Basic Constraints Extension** dialog box, select **Enable this extension**, as shown in Figure 2.
![Edit Basic Constraints Extension](images/dg-fig29-enableconstraints.png)
Figure 2. Select constraints on the new template
9. If a certificate manager is required to approve any issued certificates, on the **Issuance Requirements** tab, select **CA certificate manager approval**.
10. On the **Subject Name** tab, select **Supply in the request**.
11. On the **Security** tab, verify that whatever account will be used to request the certificate has the right to enroll the certificate.
12. Click **OK** to create the template, and then close the Certificate Template Console.
When this certificate template has been created, you must publish it to the CA published template store. To do so, complete the following steps:
1. In the Certification Authority MMC snap-in, right-click **Certification Templates**, point to **New**, and then click **Certificate Template to Issue**, as shown in Figure 3.
![Select Certificate Template to Issue](images/dg-fig30-selectnewcert.png)
Figure 3. Select the new certificate template to issue
A list of available templates to issue appears, including the template you just created.
2. Select the WDAC Catalog signing certificate, and then click **OK**.
Now that the template is available to be issued, you must request one from the computer running Windows 10 on which you create and sign catalog files. To begin, open the MMC, and then complete the following steps:
1. In MMC, from the **File** menu, click **Add/Remove Snap-in**. Double-click **Certificates**, and then select **My user account**.
2. In the Certificates snap-in, right-click the Personal store folder, point to **All Tasks**, and then click **Request New Certificate**.
3. Click **Next** twice to get to the certificate selection list.
4. In the **Request Certificate** list, select your newly created code signing certificate, and then select the blue text that requests additional information, as shown in Figure 4.
![Request Certificates: more information required](images/dg-fig31-getmoreinfo.png)
Figure 4. Get more information for your code signing certificate
5. In the **Certificate Properties** dialog box, for **Type**, select **Common name**. For **Value**, select **ContosoDGSigningCert**, and then click **Add**. When added, click **OK.**
6. Enroll and finish.
> **Note**&nbsp;&nbsp;If a certificate manager is required to approve any issued certificates and you selected to require management approval on the template, the request will need to be approved in the CA before it will be issued to the client.
This certificate must be installed in the user’s personal store on the computer that will be signing the catalog files and code integrity policies. If the signing is going to be taking place on the computer on which you just requested the certificate, exporting the certificate to a .pfx file will not be required because it already exists in your personal store. If you are signing on another computer, you will need to export the .pfx certificate with the necessary keys and properties. To do so, complete the following steps:
1. Right-click the certificate, point to **All Tasks**, and then click **Export**.
2. Click **Next**, and then select **Yes, export the private key**.
3. Choose the default settings, and then select **Export all extended properties**.
4. Set a password, select an export path, and then select **WDACCatSigningCert.pfx** as the file name.
When the certificate has been exported, import it into the personal store for the user who will be signing the catalog files or code integrity policies on the specific computer that will be signing them.
## Related topics
- [Introduction to Windows Defender Device Guard: virtualization-based security and Windows Defender Application Control](introduction-to-device-guard-virtualization-based-security-and-windows-defender-application-control.md)
- [Deploy Windows Defender Application Control](deploy-windows-defender-application-control.md)

67
windows/security/threat-protection/device-guard/planning-and-getting-started-on-the-device-guard-deployment-process.md
View File

@ -1,67 +0,0 @@
---
title: Planning and getting started on the Windows Defender Device Guard deployment process (Windows 10)
description: To help you plan and begin the initial test stages of a deployment of Microsoft Windows Defender Device Guard, this article outlines how to gather information, create a plan, and begin to create and test initial code integrity policies.
keywords: virtualization, security, malware
ms.prod: w10
ms.mktglfcycl: deploy
ms.localizationpriority: high
author: brianlic-msft
ms.date: 10/20/2017
---
# Planning and getting started on the Windows Defender Device Guard deployment process
**Applies to**
- Windows 10
- Windows Server 2016
This topic provides a roadmap for planning and getting started on the Windows Defender Device Guard deployment process, with links to topics that provide additional detail. Planning for Windows Defender Device Guard deployment involves looking at both the end-user and the IT pro impact of your choices. Use the following steps to guide you.
## Planning
1. **Review requirements, especially hardware requirements for VBS**. Review the virtualization-based security (VBS) features described in [How Windows Defender Device Guard features help protect against threats](introduction-to-device-guard-virtualization-based-security-and-windows-defender-application-control.md#how-windows-defender-device-guard-features-help-protect-against-threats). Then you can assess your end-user systems to see how many support the VBS features you are interested in, as described in [Requirements and deployment planning guidelines for virtualization-based protection of code integrity](requirements-and-deployment-planning-guidelines-for-virtualization-based-protection-of-code-integrity.md).
2. **Group devices by degree of control needed**. Group devices according to the table in [Windows Defender Device Guard deployment in different scenarios: types of devices](requirements-and-deployment-planning-guidelines-for-device-guard.md#windows-defender-device-guard-deployment-in-different-scenarios-types-of-devices). Do most devices fit neatly into a few categories, or are they scattered across all categories? Are users allowed to install any application or must they choose from a list? Are users allowed to use their own peripheral devices?<br>Deployment is simpler if everything is locked down in the same way, but meeting individual departments’ needs, and working with a wide variety of devices, may require a more complicated and flexible deployment.
3. **Review how much variety in software and hardware is needed by roles or departments**. When several departments all use the same hardware and software, you might need to deploy only one Windows Defender Application Control (WDAC) policy for them. More variety across departments might mean you need to create and manage more WDAC policies. The following questions can help you clarify how many WDAC policies to create:
- How standardized is the hardware?<br>This can be relevant because of drivers. You could create a WDAC policy on hardware that uses a particular set of drivers, and if other drivers in your environment use the same signature, they would also be allowed to run. However, you might need to create several WDAC policies on different "reference" hardware, then merge the policies together, to ensure that the resulting policy recognizes all the drivers in your environment.
- What software does each department or role need? Should they be able to install and run other departments’ software?<br>If multiple departments are allowed to run the same list of software, you might be able to merge several WDAC policies to simplify management.
- Are there departments or roles where unique, restricted software is used?<br>If one department needs to run an application that no other department is allowed, it might require a separate WDAC policy. Similarly, if only one department must run an old version of an application (while other departments allow only the newer version), it might require a separate WDAC policy.
- Is there already a list of accepted applications?<br>A list of accepted applications can be used to help create a baseline WDAC policy.<br>As of Windows 10, version 1703, it might also be useful to have a list of plug-ins, add-ins, or modules that you want to allow only in a specific app (such as a line-of-business app). Similarly, it might be useful to have a list of plug-ins, add-ins, or modules that you want to block in a specific app (such as a browser).
- As part of a threat review process, have you reviewed systems for software that can load arbitrary DLLs or run code or scripts?
In day-to-day operations, your organization’s security policy may allow certain applications, code, or scripts to run on your systems depending on their role and the context. However, if your security policy requires that you run only trusted applications, code, and scripts on your systems, you may decide to lock these systems down securely with Windows Defender Application Control policies. You can also fine-tune your control by using Windows Defender Application Control in combination with AppLocker, as described in [Windows Defender Device Guard with AppLocker](./windows-defender-application-control/windows-defender-application-control-and-applocker.md).
Legitimate applications from trusted vendors provide valid functionality. However, an attacker could also potentially use that same functionality to run malicious executable code that could bypass WDAC.
For operational scenarios that require elevated security, certain applications with known Code Integrity bypasses may represent a security risk if you whitelist them in your WDAC policies. Other applications where older versions of the application had vulnerabilities also represent a risk. Therefore, you may want to deny or block such applications from your WDAC policies. For applications with vulnerabilities, once the vulnerabilities are fixed you can create a rule that only allows the fixed or newer versions of that application. The decision to allow or block applications depends on the context and on how the reference system is being used.
Security professionals collaborate with Microsoft continuously to help protect customers. With the help of their valuable reports, Microsoft has identified a list of known applications that an attacker could potentially use to bypass Windows Defender Application Control. Depending on the context, you may want to block these applications. To view this list of applications and for use case examples, such as disabling msbuild.exe, see [Microsoft recommended block list](./windows-defender-application-control/microsoft-recommended-block-rules.md).
4. **Identify LOB applications that are currently unsigned**. Although requiring signed code (through WDAC) protects against many threats, your organization might use unsigned LOB applications, for which the process of signing might be difficult. You might also have applications that are signed, but you want to add a secondary signature to them. If so, identify these applications, because you will need to create a catalog file for them. For more background information about catalog files, see [Deploy catalog files to support WDAC](./windows-defender-application-control/deploy-catalog-files-to-support-windows-defender-application-control.md).
## Getting started on the deployment process
1. **Optionally, create a signing certificate for Windows Defender Application Control**. As you deploy WDAC, you might need to sign catalog files or WDAC policies internally. To do this, you will either need a publicly issued code signing certificate (that you purchase) or an internal CA. If you choose to use an internal CA, you will need to create a code signing certificate. For more information, see [Optional: Create a code signing certificate for Windows Defender Application Control](./windows-defender-application-control/create-code-signing-cert-for-windows-defender-application-control.md).
2. **Create WDAC policies from “golden” reference computers**. When you have identified departments or roles that use distinctive or partly-distinctive sets of hardware and software, you can set up “golden” computers containing that software and hardware. In this respect, creating and managing WDAC policies to align with the needs of roles or departments can be similar to managing corporate images. From each “golden” computer, you can create a WDAC policy, and decide how to manage that policy. You can merge WDAC policies to create a broader policy or a master policy, or you can manage and deploy each policy individually.
3. **Audit the WDAC policy and capture information about applications that are outside the policy**. We recommend that you use “audit mode” to carefully test each WDAC policy before you enforce it. With audit mode, no application is blocked—the policy just logs an event whenever an application outside the policy is started. Later, you can expand the policy to allow these applications, as needed. For more information, see [Audit Windows Defender Application Control policies](./windows-defender-application-control/audit-windows-defender-application-control-policies.md).
4. **Create a “catalog file” for unsigned LOB applications**. Use the Package Inspector tool to create and sign a catalog file for your unsigned LOB applications. For more information, review step 4 **Identify LOB applications that are currently unsigned**, earlier in this list, and see [Deploy catalog files to support Windows Defender Application Control](./windows-defender-application-control/deploy-catalog-files-to-support-windows-defender-application-control.md). In later steps, you can merge the catalog file's signature into your WDAC policy, so that applications in the catalog will be allowed by the policy.
6. **Capture needed policy information from the event log, and merge information into the existing policy as needed**. After a WDAC policy has been running for a time in audit mode, the event log will contain information about applications that are outside the policy. To expand the policy so that it allows for these applications, use Windows PowerShell commands to capture the needed policy information from the event log, and then merge that information into the existing policy. You can merge WDAC policies from other sources also, for flexibility in how you create your final WDAC policies. For more information, see [Merge Windows Defender Application Control policies](./windows-defender-application-control/merge-windows-defender-application-control-policies.md).
7. **Deploy WDAC policies and catalog files**. After you confirm that you have completed all the preceding steps, you can begin deploying catalog files and taking WDAC policies out of auditing mode. We strongly recommend that you begin this process with a test group of users. This provides a final quality-control validation before you deploy the catalog files and WDAC policies more broadly. For more information, see:
- [Enforce Windows Defender Application Control policies](./windows-defender-application-control/enforce-windows-defender-application-control-policies.ms)
- [Deploy and manage Windows Defender Application Control with Group Policy](./windows-defender-application-control/deploy-windows-defender-application-control-policies-using-group-policy)<br>
8. **Enable desired virtualization-based security (VBS) features**. Hardware-based security features—also called virtualization-based security (VBS) features—strengthen the protections offered by Windows Defender Application Control, as described in [How Windows Defender Device Guard features help protect against threats](introduction-to-device-guard-virtualization-based-security-and-windows-defender-application-control.md#how-windows-defender-device-guard-features-help-protect-against-threats).
> [!WARNING]
> Virtualization-based protection of code integrity may be incompatible with some devices and applications. We strongly recommend testing this configuration in your lab before enabling virtualization-based protection of code integrity on production systems. Failure to do so may result in unexpected failures up to and including data loss or a blue screen error (also called a stop error).
<br />

94
windows/security/threat-protection/device-guard/requirements-and-deployment-planning-guidelines-for-device-guard.md
View File

@ -1,94 +0,0 @@
---
title: Requirements and deployment planning guidelines for Windows Defender Device Guard (Windows 10)
description: To help you plan a deployment of Microsoft Windows Defender Device Guard, this article describes hardware requirements for Windows Defender Device Guard, outlines deployment approaches, and describes methods for code signing and the deployment of code integrity policies.
keywords: virtualization, security, malware
ms.prod: w10
ms.mktglfcycl: deploy
ms.localizationpriority: high
author: brianlic-msft
ms.date: 10/20/2017
---
# Planning guidelines for Windows Defender Device Guard
**Applies to**
- Windows 10
- Windows Server 2016
## Windows Defender Device Guard deployment in different scenarios: types of devices
Typically, deployment of Windows Defender Device Guard happens best in phases, rather than being a feature that you simply “turn on.” The choice and sequence of phases depends on the way various computers and other devices are used in your organization, and to what degree IT manages those devices. The following table can help you begin to develop a plan for deploying Windows Defender Device Guard in your organization.
| **Type of device** | **How Windows Defender Device Guard relates to this type of device** | **Windows Defender Device Guard components that you can use to protect this kind of device** |
|------------------------------------|------------------------------------------------------|--------------------------------------------------------------------------------|
| **Fixed-workload devices**: Perform same tasks every day.<br>Lists of approved applications rarely change.<br>Examples: kiosks, point-of-sale systems, call center computers. | Windows Defender Device Guard can be deployed fully, and deployment and ongoing administration are relatively straightforward.<br>After Windows Defender Device Guard deployment, only approved applications can run. This is because of protections offered by WDAC. | - VBS (hardware-based) protections, enabled.<br><br>• WDAC in enforced mode, with UMCI enabled. |
| **Fully managed devices**: Allowed software is restricted by IT department.<br>Users can request additional software, or install from a list of applications provided by IT department.<br>Examples: locked-down, company-owned desktops and laptops. | An initial baseline WDAC policy can be established and enforced. Whenever the IT department approves additional applications, it will update the WDAC policy and (for unsigned LOB applications) the catalog.<br>WDAC policies are supported by the HVCI service. | - VBS (hardware-based) protections, enabled.<br><br>• WDAC in enforced mode, with UMCI enabled. |
| **Lightly managed devices**: Company-owned, but users are free to install software.<br>Devices are required to run organization's antivirus solution and client management tools. | Windows Defender Device Guard can be used to help protect the kernel, and to monitor (audit) for problem applications rather than limiting the applications that can be run. | - VBS (hardware-based) protections, enabled. When enabled with a WDAC policy in audit mode only, VBS means the hypervisor helps enforce the default kernel-mode code integrity policy, which protects against unsigned drivers or system files.<br><br>• WDAC, with UMCI enabled, but running in audit mode only. This means applications are not blocked—the policy just logs an event whenever an application outside the policy is started. |
| **Bring Your Own Device**: Employees are allowed to bring their own devices, and also use those devices away from work. | Windows Defender Device Guard does not apply. Instead, you can explore other hardening and security features with MDM-based conditional access solutions, such as Microsoft Intune. | N/A |
## Windows Defender Device Guard deployment in virtual machines
Windows Defender Device Guard can protect a Hyper-V virtual machine, just as it would a physical machine. The steps to enable Windows Defender Device Guard are the same from within the virtual machine.
Windows Defender Device Guard protects against malware running in the guest virtual machine. It does not provide additional protection from the host administrator. From the host, you can disable Windows Defender Device Guard for a virtual machine:
```powershell
Set-VMSecurity -VMName <VMName> -VirtualizationBasedSecurityOptOut $true
```
### Requirements for running Windows Defender Device Guard in Hyper-V virtual machines
- The Hyper-V host must run at least Windows Server 2016 or Windows 10 version 1607.
- The Hyper-V virtual machine must be Generation 2, and running at least Windows Server 2016 or Windows 10.
- Windows Defender Device Guard and [nested virtualization](https://docs.microsoft.com/virtualization/hyper-v-on-windows/user-guide/nested-virtualization) cannot be enabled at the same time.
- Virtual Fibre Channel adapters are not compatible with Windows Defender Device Guard. Before attaching a virtual Fibre Channel Adapter to a virtual machine, you must first opt out of virtualization-based security using Set-VMSecurity.
- The AllowFullSCSICommandSet option for pass-through disks is not compatible with Windows Defender Device Guard. Before configuring a pass-through disk with AllowFullSCSICommandSet, you must first opt out of virtualization-based security using Set-VMSecurity.
## Reviewing your applications: application signing and catalog files
Typically, WDAC policies are configured to use the application's signing certificate as part or all of what identifies the application as trusted. This means that applications must either use embedded signing—where the signature is part of the binary—or catalog signing, where you generate a “catalog file” from the applications, sign it, and through the signed catalog file, configure the WDAC policy to recognize the applications as signed.
Catalog files can be very useful for unsigned LOB applications that cannot easily be given an embedded signature. However, catalogs need to be updated each time an application is updated. In contrast, with embedded signing, your WDAC policies typically do not have to be updated when an application is updated. For this reason, if code-signing is or can be included in your in-house application development process, it can simplify the management of WDAC (compared to using catalog signing).
To obtain signed applications or embed signatures in your in-house applications, you can choose from a variety of methods:
- Using the Microsoft Store publishing process. All apps that come out of the Microsoft Store are automatically signed with special signatures that can roll-up to our certificate authority (CA) or to your own.
- Using your own digital certificate or public key infrastructure (PKI). ISV's and enterprises can sign their own Classic Windows applications themselves, adding themselves to the trusted list of signers.
- Using a non-Microsoft signing authority. ISV's and enterprises can use a trusted non-Microsoft signing authority to sign all of their own Classic Windows applications.
To use catalog signing, you can choose from the following options:
- Use the Windows Defender Device Guard signing portal available in the Microsoft Store for Business. The portal is a Microsoft web service that you can use to sign your Classic Windows applications. For more information, see [Windows Defender Device Guard signing](https://technet.microsoft.com/itpro/windows/manage/device-guard-signing-portal).
- Create your own catalog files, which are described in the next section. For information about how creating catalog files fits into Windows Defender Device Guard deployment, see [Planning and getting started on the Windows Defender Device Guard deployment process](planning-and-getting-started-on-the-device-guard-deployment-process.md).
### Catalog files
Catalog files (which you can create in Windows 10 with a tool called Package Inspector) contain information about all deployed and executed binary files associated with your trusted but unsigned applications. When you create catalog files, you can also include signed applications for which you do not want to trust the signer but rather the specific application. After creating a catalog, you must sign the catalog file itself by using enterprise public key infrastructure (PKI), or a purchased code signing certificate. Then you can distribute the catalog, so that your trusted applications can be handled by WDAC in the same way as any other signed application.
Catalog files are simply Secure Hash Algorithm 2 (SHA2) hash lists of discovered binaries. These binaries’ hash values are updated each time an application is updated, which requires the catalog file to be updated also.
After you have created and signed your catalog files, you can configure your WDAC policies to trust the signer or signing certificate of those files.
> **Note**&nbsp;&nbsp;Package Inspector only works on operating systems that support Windows Defender Device Guard, such as Windows 10 Enterprise, Windows 10 Education, Windows 2016 Server, or Windows Enterprise IoT.
For information about how creating catalog files fits into Windows Defender Device Guard deployment, see [Planning and getting started on the Windows Defender Device Guard deployment process](planning-and-getting-started-on-the-device-guard-deployment-process.md). For procedures for working with catalog files, see [Deploy catalog files to support Windows Defender Application Control](deploy-catalog-files-to-support-windows-defender-application-control.md).
## Windows Defender Application Control policy formats and signing
When you generate a WDAC policy, you are generating a binary-encoded XML document that includes configuration settings for both the User and Kernel-modes of Windows 10 Enterprise, along with restrictions on Windows 10 script hosts. You can view your original XML document in a text editor, for example if you want to check the rule options that are present in the **&lt;Rules&gt;** section of the file.
We recommend that you keep the original XML file for use when you need to merge the WDAC policy with another policy or update its rule options. For deployment purposes, the file is converted to a binary format, which can be done using a simple Windows PowerShell command.
When the WDAC policy is deployed, it restricts the software that can run on a device. The XML document can be signed, helping to add additional protection against administrative users changing or removing the policy.
## Related topics
- [Planning and getting started on the Windows Defender Device Guard deployment process](planning-and-getting-started-on-the-device-guard-deployment-process.md)
- [Deploy Windows Defender Application Control](deploy-windows-defender-application-control.md)

22
windows/security/threat-protection/device-guard/steps-to-deploy-windows-defender-application-control.md
View File

@ -1,22 +0,0 @@
---
title: Deploy code integrity policies - steps (Windows 10)
description: This article describes how to deploy code integrity policies, one of the main features that are part of Windows Defender Device Guard in Windows 10.
keywords: virtualization, security, malware
ms.prod: w10
ms.mktglfcycl: deploy
ms.localizationpriority: high
author: brianlic-msft
ms.date: 02/13/2018
---
# Steps to Deploy Windows Defender Application Control
**Applies to**
- Windows 10
- Windows Server 2016

1
windows/security/threat-protection/windows-defender-application-control/create-your-windows-defender-application-control-planning-document.md
View File

@ -370,7 +370,6 @@ You can use the following form to construct your own WDAC planning document.
   
### Additional resources ### Additional resources
- [Deploy Windows Defender Application Control Policies](deploy-windows-defender-application-control-policies.md)
- [Windows Defender Application Control](windows-defender-application-control.md) - [Windows Defender Application Control](windows-defender-application-control.md)
   
   

6
windows/security/threat-protection/windows-defender-application-control/signing-policies-with-signtool.md
View File

@ -48,7 +48,7 @@ If you do not have a code signing certificate, see the [Optional: Create a code
> [!Note] > [!Note]
> This example uses the WDAC policy that you created in [Create a Windows Defender Application Control policy from a reference computer](create-initial-default-policy.md). If you are signing another policy, be sure to update the **$CIPolicyPath** and **$CIPolicyBin** variables with the correct information. > This example uses the WDAC policy that you created in [Create a Windows Defender Application Control policy from a reference computer](create-initial-default-policy.md). If you are signing another policy, be sure to update the **$CIPolicyPath** and **$CIPolicyBin** variables with the correct information.
2. Import the .pfx code signing certificate. Import the code signing certificate that you will use to sign the WDAC policy into the signing user’s personal store on the computer that will be doing the signing. In this example, you use the certificate that was created in [Optional: Create a code signing certificate for Windows Defender Application Control](optional-create-a-code-signing-certificate-for-windows-defender-application-control.md). 2. Import the .pfx code signing certificate. Import the code signing certificate that you will use to sign the WDAC policy into the signing user’s personal store on the computer that will be doing the signing. In this example, you use the certificate that was created in [Optional: Create a code signing certificate for Windows Defender Application Control](create-code-signing-cert-for-windows-defender-application-control.md).
3. Export the .cer code signing certificate. After the code signing certificate has been imported, export the .cer version to your desktop. This version will be added to the policy so that it can be updated later. 3. Export the .cer code signing certificate. After the code signing certificate has been imported, export the .cer version to your desktop. This version will be added to the policy so that it can be updated later.
@ -61,8 +61,8 @@ If you do not have a code signing certificate, see the [Optional: Create a code
` Add-SignerRule -FilePath $InitialCIPolicy -CertificatePath <Path to exported .cer certificate> -Kernel -User –Update` ` Add-SignerRule -FilePath $InitialCIPolicy -CertificatePath <Path to exported .cer certificate> -Kernel -User –Update`
> [!Note] > [!Note]
> *&lt;Path to exported .cer certificate&gt;* should be the full path to the certificate that you exported in step 3. > <Path to exported .cer certificate> should be the full path to the certificate that you exported in step 3.
Also, adding update signers is crucial to being able to modify or disable this policy in the future. For more information about how to disable signed WDAC policies, see the [Disable signed Windows Defender Application Control policies within Windows](#disable-signed-windows-defender-application-control-policies-within-windows) section. Also, adding update signers is crucial to being able to modify or disable this policy in the future.
6. Use [Set-RuleOption](https://docs.microsoft.com/powershell/module/configci/set-ruleoption) to remove the unsigned policy rule option: 6. Use [Set-RuleOption](https://docs.microsoft.com/powershell/module/configci/set-ruleoption) to remove the unsigned policy rule option:

16
windows/security/threat-protection/windows-defender-application-control/windows-defender-application-control-deployment-guide.md
View File

@ -1,6 +1,6 @@
--- ---
title: Planning and getting started on the Windows Defender Application Control deployment process (Windows 10) title: Planning and getting started on the Windows Defender Application Control deployment process (Windows 10)
description: To help you plan and begin the initial test stages of a deployment of Microsoft Windows Defender Application Comntrol, this article outlines how to gather information, create a plan, and begin to create and test initial code integrity policies. description: To help you plan and begin the initial test stages of a deployment of Microsoft Windows Defender Application Control, this article outlines how to gather information, create a plan, and begin to create and test initial code integrity policies.
keywords: virtualization, security, malware keywords: virtualization, security, malware
ms.prod: w10 ms.prod: w10
ms.mktglfcycl: deploy ms.mktglfcycl: deploy
@ -19,9 +19,9 @@ This topic provides a roadmap for planning and getting started on the Windows De
## Planning ## Planning
1. **Review requirements, especially hardware requirements for VBS**. Review the [virtualization-based security (VBS) features](./device-guard/introduction-to-device-guard-virtualization-based-security-and-windows-defender-application-control.md#how-windows-defender-device-guard-features-help-protect-against-threats) and corresponding [hardware, firmware, and software requirements](./device-guard/requirements-and-deployment-planning-guidelines-for-device-guard.md#hardware-firmware-and-software-requirements-for-windows-defender-device-guard). 1. **Review requirements, especially hardware requirements for VBS**. Review the virtualization-based security (VBS) features and corresponding hardware, firmware, and software requirements.
2. **Group devices by degree of control needed**. [Group devices](./device-guard/requirements-and-deployment-planning-guidelines-for-device-guard.md#windows-defender-device-guard-deployment-in-different-scenarios-types-of-devices). Do most devices fit neatly into a few categories, or are they scattered across all categories? Are users allowed to install any application or must they choose from a list? Are users allowed to use their own peripheral devices?<br>Deployment is simpler if everything is locked down in the same way, but meeting individual departments’ needs, and working with a wide variety of devices, may require a more complicated and flexible deployment. 2. **Group devices by degree of control needed**. [Group devices](types-of-devices.md). Do most devices fit neatly into a few categories, or are they scattered across all categories? Are users allowed to install any application or must they choose from a list? Are users allowed to use their own peripheral devices?<br>Deployment is simpler if everything is locked down in the same way, but meeting individual departments’ needs, and working with a wide variety of devices, may require a more complicated and flexible deployment.
3. **Review how much variety in software and hardware is needed by roles or departments**. When several departments all use the same hardware and software, you might need to deploy only one Windows Defender Application Control (WDAC) policy for them. More variety across departments might mean you need to create and manage more WDAC policies. The following questions can help you clarify how many WDAC policies to create: 3. **Review how much variety in software and hardware is needed by roles or departments**. When several departments all use the same hardware and software, you might need to deploy only one Windows Defender Application Control (WDAC) policy for them. More variety across departments might mean you need to create and manage more WDAC policies. The following questions can help you clarify how many WDAC policies to create:
- How standardized is the hardware?<br>This can be relevant because of drivers. You could create a WDAC policy on hardware that uses a particular set of drivers, and if other drivers in your environment use the same signature, they would also be allowed to run. However, you might need to create several WDAC policies on different "reference" hardware, then merge the policies together, to ensure that the resulting policy recognizes all the drivers in your environment. - How standardized is the hardware?<br>This can be relevant because of drivers. You could create a WDAC policy on hardware that uses a particular set of drivers, and if other drivers in your environment use the same signature, they would also be allowed to run. However, you might need to create several WDAC policies on different "reference" hardware, then merge the policies together, to ensure that the resulting policy recognizes all the drivers in your environment.
@ -33,20 +33,20 @@ This topic provides a roadmap for planning and getting started on the Windows De
- Is there already a list of accepted applications?<br>A list of accepted applications can be used to help create a baseline WDAC policy.<br>As of Windows 10, version 1703, it might also be useful to have a list of plug-ins, add-ins, or modules that you want to allow only in a specific app (such as a line-of-business app). Similarly, it might be useful to have a list of plug-ins, add-ins, or modules that you want to block in a specific app (such as a browser). - Is there already a list of accepted applications?<br>A list of accepted applications can be used to help create a baseline WDAC policy.<br>As of Windows 10, version 1703, it might also be useful to have a list of plug-ins, add-ins, or modules that you want to allow only in a specific app (such as a line-of-business app). Similarly, it might be useful to have a list of plug-ins, add-ins, or modules that you want to block in a specific app (such as a browser).
- As part of a threat review process, have you reviewed systems for software that can load arbitrary DLLs or run code or scripts? - As part of a threat review process, have you reviewed systems for software that can load arbitrary DLLs or run code or scripts?
In day-to-day operations, your organization’s security policy may allow certain applications, code, or scripts to run on your systems depending on their role and the context. However, if your security policy requires that you run only trusted applications, code, and scripts on your systems, you may decide to lock these systems down securely with Windows Defender Application Control policies. You can also fine-tune your control by using Windows Defender Application Control in combination with AppLocker, as described in [Windows Defender Device Guard with AppLocker](./device-guard/introduction-to-device-guard-virtualization-based-security-and-windows-defender-application-control.md#windows-defender-device-guard-with-applocker). In day-to-day operations, your organization’s security policy may allow certain applications, code, or scripts to run on your systems depending on their role and the context. However, if your security policy requires that you run only trusted applications, code, and scripts on your systems, you may decide to lock these systems down securely with Windows Defender Application Control policies. You can also fine-tune your control by using Windows Defender Application Control in combination with AppLocker, as described in [Windows Defender Device Guard with AppLocker](windows-defender-application-control-and-applocker.md).
Legitimate applications from trusted vendors provide valid functionality. However, an attacker could also potentially use that same functionality to run malicious executable code that could bypass WDAC. Legitimate applications from trusted vendors provide valid functionality. However, an attacker could also potentially use that same functionality to run malicious executable code that could bypass WDAC.
For operational scenarios that require elevated security, certain applications with known Code Integrity bypasses may represent a security risk if you whitelist them in your WDAC policies. Other applications where older versions of the application had vulnerabilities also represent a risk. Therefore, you may want to deny or block such applications from your WDAC policies. For applications with vulnerabilities, once the vulnerabilities are fixed you can create a rule that only allows the fixed or newer versions of that application. The decision to allow or block applications depends on the context and on how the reference system is being used. For operational scenarios that require elevated security, certain applications with known Code Integrity bypasses may represent a security risk if you whitelist them in your WDAC policies. Other applications where older versions of the application had vulnerabilities also represent a risk. Therefore, you may want to deny or block such applications from your WDAC policies. For applications with vulnerabilities, once the vulnerabilities are fixed you can create a rule that only allows the fixed or newer versions of that application. The decision to allow or block applications depends on the context and on how the reference system is being used.
Security professionals collaborate with Microsoft continuously to help protect customers. With the help of their valuable reports, Microsoft has identified a list of known applications that an attacker could potentially use to bypass Windows Defender Application Control. Depending on the context, you may want to block these applications. To view this list of applications and for use case examples, such as disabling msbuild.exe, see [Steps to Deploy Windows Defender Application Control](./device-guard/steps-to-deploy-windows-defender-application-control.md). Security professionals collaborate with Microsoft continuously to help protect customers. With the help of their valuable reports, Microsoft has identified a list of known applications that an attacker could potentially use to bypass Windows Defender Application Control. Depending on the context, you may want to block these applications. To view this list of applications and for use case examples, such as disabling msbuild.exe, see [Microsoft recommended block rules](microsoft-recommended-block-rules.md).
4. **Identify LOB applications that are currently unsigned**. Although requiring signed code (through WDAC) protects against many threats, your organization might use unsigned LOB applications, for which the process of signing might be difficult. You might also have applications that are signed, but you want to add a secondary signature to them. If so, identify these applications, because you will need to create a catalog file for them. For a basic description of catalog files, see the table in [Introduction to Windows Defender Device Guard: virtualization-based security and Windows Defender Application Control](./device-guard/introduction-to-device-guard-virtualization-based-security-and-windows-defender-application-control.md). For more background information about catalog files, see [Reviewing your applications: application signing and catalog files](./device-guard/requirements-and-deployment-planning-guidelines-for-device-guard.md#reviewing-your-applications-application-signing-and-catalog-files). 4. **Identify LOB applications that are currently unsigned**. Although requiring signed code (through WDAC) protects against many threats, your organization might use unsigned LOB applications, for which the process of signing might be difficult. You might also have applications that are signed, but you want to add a secondary signature to them. If so, identify these applications, because you will need to create a catalog file for them. For more background information about catalog files, see [Deploy catalog files to support Windows Defender Application Control](deploy-catalog-files-to-support-windows-defender-application-control.md).
## Getting started on the deployment process ## Getting started on the deployment process
@ -72,7 +72,3 @@ This topic provides a roadmap for planning and getting started on the Windows De
> [!WARNING] > [!WARNING]
> Virtualization-based protection of code integrity may be incompatible with some devices and applications. We strongly recommend testing this configuration in your lab before enabling virtualization-based protection of code integrity on production systems. Failure to do so may result in unexpected failures up to and including data loss or a blue screen error (also called a stop error). > Virtualization-based protection of code integrity may be incompatible with some devices and applications. We strongly recommend testing this configuration in your lab before enabling virtualization-based protection of code integrity on production systems. Failure to do so may result in unexpected failures up to and including data loss or a blue screen error (also called a stop error).
For information about enabling VBS features, see [Enable virtualization-based protection of code integrity](./device-guard/deploy-device-guard-enable-virtualization-based-security.md).
<br />