mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-05-12 21:37:22 +00:00
Merged PR 3991: Merge vsts12911015 to master
This commit is contained in:
Justin Hall
commit
81c23f82ab
@ -6,6 +6,7 @@ ms.prod: w10
|
||||
ms.mktglfcycl: deploy
|
||||
ms.localizationpriority: high
|
||||
author: brianlic-msft
|
||||
ms.date: 10/20/2017
|
||||
---
|
||||
|
||||
# Deploy catalog files to support code integrity policies
|
||||
|
||||
@ -6,6 +6,7 @@ ms.prod: w10
|
||||
ms.mktglfcycl: deploy
|
||||
ms.localizationpriority: high
|
||||
author: brianlic-msft
|
||||
ms.date: 10/20/2017
|
||||
---
|
||||
|
||||
# Deploy code integrity policies: policy rules and file rules
|
||||
|
||||
@ -6,6 +6,7 @@ ms.prod: w10
|
||||
ms.mktglfcycl: deploy
|
||||
ms.localizationpriority: high
|
||||
author: brianlic-msft
|
||||
ms.date: 10/20/2017
|
||||
---
|
||||
|
||||
# Deploy code integrity policies: steps
|
||||
|
||||
@ -6,6 +6,7 @@ ms.prod: w10
|
||||
ms.mktglfcycl: deploy
|
||||
ms.localizationpriority: high
|
||||
author: brianlic-msft
|
||||
ms.date: 10/20/2017
|
||||
---
|
||||
|
||||
# Deploy Windows Defender Device Guard: deploy code integrity policies
|
||||
|
||||
@ -6,6 +6,7 @@ ms.prod: w10
|
||||
ms.mktglfcycl: deploy
|
||||
ms.localizationpriority: high
|
||||
author: brianlic-msft
|
||||
ms.date: 10/20/2017
|
||||
---
|
||||
|
||||
# Deploy Windows Defender Device Guard: enable virtualization-based security
|
||||
@ -14,78 +15,61 @@ author: brianlic-msft
|
||||
- Windows 10
|
||||
- Windows Server 2016
|
||||
|
||||
Hardware-based security features, also called virtualization-based security or VBS, make up a large part of Windows Defender Device Guard security offerings. VBS reinforces the most important feature of Windows Defender Device Guard: configurable code integrity. There are a few steps to configure hardware-based security features in Windows Defender Device Guard:
|
||||
Hardware-based security features, also called virtualization-based security or VBS, reinforce Windows Defender Application Control. There are a few steps to configure virtualization-based security:
|
||||
|
||||
1. **Decide whether to use the procedures in this topic, or to use the Windows Defender Device Guard readiness tool**. To enable VBS, you can download and use [the hardware readiness tool on the Microsoft Download Center](https://www.microsoft.com/en-us/download/details.aspx?id=53337), or follow the procedures in this topic.
|
||||
1. **Decide whether to use the procedures in this topic, or to use the Windows Defender Device Guard readiness tool**. To enable VBS, 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 possess the necessary hardware and firmware to run these features. A list of requirements for hardware-based security features is available in [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).
|
||||
2. **Verify that hardware and firmware requirements are met**. Verify that your client computers have the hardware and firmware to run VBS. For a list of 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).
|
||||
|
||||
3. **Enable the necessary Windows features**. There are several ways to enable the Windows features required for hardware-based security. You can use the [Windows Defender Device Guard and Windows Defender Credential Guard hardware readiness tool](https://www.microsoft.com/en-us/download/details.aspx?id=53337), or see the following section, [Windows feature requirements for virtualization-based security](#windows-feature-requirements-for-virtualization-based-security-and-device-guard).
|
||||
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-security-and-device-guard).
|
||||
|
||||
4. **Enable additional features as desired**. When the necessary Windows features have been enabled, you can enable additional hardware-based security features as desired. You can use the [Windows Defender Device Guard and Windows Defender Credential Guard hardware readiness tool](https://www.microsoft.com/en-us/download/details.aspx?id=53337), or see [Enable virtualization-based security (VBS)](#enable-virtualization-based-security-vbs-and-device-guard), later in this topic.
|
||||
|
||||
For information about enabling Windows Defender Credential Guard, see [Protect derived domain credentials with Windows Defender Credential Guard](/windows/access-protection/credential-guard/credential-guard).
|
||||
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 security (VBS)](#enable-virtualization-based-security-vbs-and-device-guard).
|
||||
|
||||
## Windows feature requirements for virtualization-based security and Windows Defender Device Guard
|
||||
|
||||
In addition to the hardware requirements found in [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), you must confirm that certain operating system features are enabled before you can enable VBS:
|
||||
Make sure these operating system features are enabled before you can enable VBS:
|
||||
|
||||
- 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).
|
||||
|
||||
> **Note** You can configure these features by using Group Policy or Deployment Image Servicing and Management, or manually by using Windows PowerShell or the Windows Features dialog box.
|
||||
|
||||
|
||||
|
||||
**Figure 1. Enable operating system features for VBS, 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 Security (VBS) and Windows Defender Device Guard
|
||||
|
||||
There are multiple ways to configure VBS features for Windows Defender Device Guard:
|
||||
|
||||
- You can use the [readiness tool](https://www.microsoft.com/en-us/download/details.aspx?id=53337) rather than the procedures in this topic.
|
||||
- You can use Group Policy, as described in the procedure that follows.
|
||||
- You can configure VBS manually, as described in [Use registry keys to enable VBS and Windows Defender Device Guard](#use-registry-keys-to-enable-vbs-and-device-guard), later in this topic.
|
||||
|
||||
> **Note** We recommend that you test-enable these features on a group of test computers before you enable them on users' computers. If untested, there is a possibility that this feature can cause system instability and ultimately cause the client operating system to fail.
|
||||
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 VBS.
|
||||
|
||||
### Use Group Policy to enable VBS and Windows Defender Device Guard
|
||||
|
||||
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**.
|
||||
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**.
|
||||
|
||||
|
||||
|
||||
Figure 2. Create a new OU-linked GPO
|
||||
|
||||
2. Give the new GPO a name, for example, **Contoso VBS settings GPO Test**, or any name you prefer. Ideally, the name will align with your existing GPO naming convention.
|
||||
2. Give the new GPO a name, then right-click the new GPO, and click **Edit**.
|
||||
|
||||
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\\Policies\\Administrative Templates\\System\\Windows Defender Device Guard. Right-click **Turn On Virtualization Based Security**, and then 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**.
|
||||
|
||||
|
||||
|
||||
Figure 3. Enable VBS
|
||||
|
||||
5. Select the **Enabled** button, and then choose a secure boot option, such as **Secure Boot**, from the **Select Platform Security Level** list.
|
||||
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 (hardware-based) protection, although it can have Windows Defender Application Control enabled.<br>For information about how VBS uses the hypervisor to strengthen protections provided by a code integrity policy, see [How Windows Defender Device Guard features help protect against threats](introduction-to-device-guard-virtualization-based-security-and-code-integrity-policies.md#how-windows-defender-device-guard-features-help-protect-against-threats).
|
||||
|
||||
Figure 4. Configure VBS, Secure Boot setting (in Windows 10, version 1607)
|
||||
For **Virtualization Based Protection of Code Integrity**:
|
||||
|
||||
> **Important** These settings include **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 (hardware-based) protection, although it can have code integrity policies enabled.<br>For information about how VBS uses the hypervisor to strengthen protections provided by a code integrity policy, see [How Windows Defender Device Guard features help protect against threats](introduction-to-device-guard-virtualization-based-security-and-code-integrity-policies.md#how-windows-defender-device-guard-features-help-protect-against-threats).
|
||||
|
||||
6. For **Virtualization Based Protection of Code Integrity**, select the appropriate option.
|
||||
|
||||
> [!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).
|
||||
|
||||
Select an option as follows:
|
||||
|
||||
- With Windows 10, version 1607 or Windows Server 2016, choose an appropriate option:<br>For an initial deployment or test deployment, we recommend **Enabled without lock**.<br>When your deployment is stable in your environment, we recommend changing to **Enabled with lock**. This option helps protect the registry from tampering, either through malware or by an unauthorized person.
|
||||
- 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.
|
||||
|
||||
@ -95,23 +79,16 @@ There are multiple ways to configure VBS features for Windows Defender Device Gu
|
||||
|
||||
7. Close the Group Policy Management Editor, and then restart the Windows 10 test computer. The settings will take effect upon restart.
|
||||
|
||||
8. Check the test computer’s event log for Windows Defender Device Guard GPOs.
|
||||
|
||||
Processed Windows Defender Device Guard policies are logged in event viewer at **Applications and Services Logs\\Microsoft\\Windows\\DeviceGuard-GPEXT\\Operational**. When the **Turn On Virtualization Based Security** policy is successfully processed, event ID 7000 is logged, which contains the selected settings within the policy.
|
||||
|
||||
>**Note** Events will be logged in this event channel only when Group Policy is used to enable Windows Defender Device Guard features, not through other methods. If other methods such as registry keys are used, Windows Defender Device Guard features will be enabled but the events won’t be logged in this event channel.
|
||||
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 VBS and Windows Defender Device Guard
|
||||
|
||||
Set the following registry keys to enable VBS and Windows Defender Device Guard. This provides exactly the same set of configuration options provided by Group Policy.
|
||||
|
||||
> [!WARNING]
|
||||
> Virtualization-based protection of code integrity (controlled through the registry key **HypervisorEnforcedCodeIntegrity**) 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).
|
||||
|
||||
<!--This comment ensures that the Important above and the Warning below don't merge together. -->
|
||||
|
||||
> **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 simply 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 (hardware-based) protection, although it can still have code integrity policies enabled.<br>For information about how VBS uses the hypervisor to strengthen protections provided by a code integrity policy, see [How Windows Defender Device Guard features help protect against threats](introduction-to-device-guard-virtualization-based-security-and-code-integrity-policies.md#how-windows-defender-device-guard-features-help-protect-against-threats).<br>
|
||||
> [!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 (hardware-based) protection, although it can still have code integrity policies enabled.<br>For information about how VBS uses the hypervisor to strengthen protections provided by a code integrity policy, see [How Windows Defender Device Guard features help protect against threats](introduction-to-device-guard-virtualization-based-security-and-code-integrity-policies.md#how-windows-defender-device-guard-features-help-protect-against-threats).<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
|
||||
@ -212,104 +189,92 @@ reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v "Unlocked" /t REG
|
||||
|
||||
### Validate enabled Windows Defender Device Guard hardware-based security features
|
||||
|
||||
Windows 10 and Windows Server 2016 and later have a WMI class for Windows Defender Device Guard–related properties and features: *Win32\_DeviceGuard*. This class can be queried from an elevated Windows PowerShell session by using the following command:
|
||||
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:
|
||||
|
||||
` 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.
|
||||
> [!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. For detailed information about what each property means, refer to Table 1.
|
||||
The output of this command provides details of the available hardware-based security features as well as those features that are currently enabled.
|
||||
|
||||
Table 1. Win32\_DeviceGuard properties
|
||||
#### AvailableSecurityProperties
|
||||
|
||||
<table>
|
||||
<colgroup>
|
||||
<col width="33%" />
|
||||
<col width="33%" />
|
||||
<col width="33%" />
|
||||
</colgroup>
|
||||
<thead>
|
||||
<tr class="header">
|
||||
<th align="left"><strong>Properties</strong></th>
|
||||
<th align="left"><strong>Description</strong></th>
|
||||
<th align="left"><strong>Valid values</strong></th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr class="odd">
|
||||
<td align="left"><strong>AvailableSecurityProperties</strong></td>
|
||||
<td align="left">This field helps to enumerate and report state on the relevant security properties for Windows Defender Device Guard.</td>
|
||||
<td align="left"><ul>
|
||||
<li><p><strong>0.</strong> If present, no relevant properties exist on the device.</p></li>
|
||||
<li><p><strong>1.</strong> If present, hypervisor support is available.</p></li>
|
||||
<li><p><strong>2.</strong> If present, Secure Boot is available.</p></li>
|
||||
<li><p><strong>3.</strong> If present, DMA protection is available.</p></li>
|
||||
<li><p><strong>4.</strong> If present, Secure Memory Overwrite is available.</p></li>
|
||||
<li><p><strong>5.</strong> If present, NX protections are available.</p></li>
|
||||
<li><p><strong>6.</strong> If present, SMM mitigations are available.</p></li>
|
||||
</ul>
|
||||
<p><strong>Note</strong>: 4, 5, and 6 were added as of Windows 10, version 1607.</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td align="left"><strong>InstanceIdentifier</strong></td>
|
||||
<td align="left">A string that is unique to a particular device.</td>
|
||||
<td align="left">Determined by WMI.</td>
|
||||
</tr>
|
||||
<tr class="odd">
|
||||
<td align="left"><strong>RequiredSecurityProperties</strong></td>
|
||||
<td align="left">This field describes the required security properties to enable virtualization-based security.</td>
|
||||
<td align="left"><ul>
|
||||
<li><p><strong>0.</strong> Nothing is required.</p></li>
|
||||
<li><p><strong>1.</strong> If present, hypervisor support is needed.</p></li>
|
||||
<li><p><strong>2.</strong> If present, Secure Boot is needed.</p></li>
|
||||
<li><p><strong>3.</strong> If present, DMA protection is needed.</p></li>
|
||||
<li><p><strong>4.</strong> If present, Secure Memory Overwrite is needed.</p></li>
|
||||
<li><p><strong>5.</strong> If present, NX protections are needed.</p></li>
|
||||
<li><p><strong>6.</strong> If present, SMM mitigations are needed.</p></li>
|
||||
</ul>
|
||||
<p><strong>Note</strong>: 4, 5, and 6 were added as of Windows 10, version 1607.</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td align="left"><strong>SecurityServicesConfigured</strong></td>
|
||||
<td align="left">This field indicates whether the Windows Defender Credential Guard or HVCI service has been configured.</td>
|
||||
<td align="left"><ul>
|
||||
<li><p><strong>0.</strong> No services configured.</p></li>
|
||||
<li><p><strong>1.</strong> If present, Windows Defender Credential Guard is configured.</p></li>
|
||||
<li><p><strong>2.</strong> If present, HVCI is configured.</p></li>
|
||||
</ul></td>
|
||||
</tr>
|
||||
<tr class="odd">
|
||||
<td align="left"><strong>SecurityServicesRunning</strong></td>
|
||||
<td align="left">This field indicates whether the Windows Defender Credential Guard or HVCI service is running.</td>
|
||||
<td align="left"><ul>
|
||||
<li><p><strong>0.</strong> No services running.</p></li>
|
||||
<li><p><strong>1.</strong> If present, Windows Defender Credential Guard is running.</p></li>
|
||||
<li><p><strong>2.</strong> If present, HVCI is running.</p></li>
|
||||
</ul></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td align="left"><strong>Version</strong></td>
|
||||
<td align="left">This field lists the version of this WMI class.</td>
|
||||
<td align="left">The only valid value now is <strong>1.0</strong>.</td>
|
||||
</tr>
|
||||
<tr class="odd">
|
||||
<td align="left"><strong>VirtualizationBasedSecurityStatus</strong></td>
|
||||
<td align="left">This field indicates whether VBS is enabled and running.</td>
|
||||
<td align="left"><ul>
|
||||
<li><p><strong>0.</strong> VBS is not enabled.</p></li>
|
||||
<li><p><strong>1.</strong> VBS is enabled but not running.</p></li>
|
||||
<li><p><strong>2.</strong> VBS is enabled and running.</p></li>
|
||||
</ul></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td align="left"><strong>PSComputerName</strong></td>
|
||||
<td align="left">This field lists the computer name.</td>
|
||||
<td align="left">All valid values for computer name.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
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.
|
||||
|
||||
|
||||
@ -6,6 +6,7 @@ ms.prod: w10
|
||||
ms.mktglfcycl: deploy
|
||||
ms.localizationpriority: high
|
||||
author: mdsakibMSFT
|
||||
ms.date: 10/20/2017
|
||||
---
|
||||
|
||||
# Deploy Managed Installer for Windows Defender Device Guard
|
||||
|
||||
@ -7,6 +7,7 @@ ms.prod: w10
|
||||
ms.mktglfcycl: deploy
|
||||
ms.localizationpriority: high
|
||||
author: brianlic-msft
|
||||
ms.date: 10/20/2017
|
||||
---
|
||||
|
||||
# Windows Defender Device Guard deployment guide
|
||||
@ -15,7 +16,12 @@ author: brianlic-msft
|
||||
- Windows 10
|
||||
- Windows Server 2016
|
||||
|
||||
Windows Defender Device Guard is a combination of enterprise-related hardware and software security features that, when configured together, will lock a device down so that it can only run trusted applications that you define in your code integrity policies. If the app isn’t trusted it can’t run, period. With hardware that meets basic requirements, it also means that even if an attacker manages to get control of the Windows kernel, he or she will be much less likely to be able to run malicious executable code. With appropriate hardware, Windows Defender Device Guard can use the new virtualization-based security in Windows 10 (available in Enterprise and Education desktop SKUs and in all Server SKUs) to isolate the Code Integrity service from the Microsoft Windows kernel itself. In this case, the Code Integrity service runs alongside the kernel in a Windows hypervisor-protected container.
|
||||
Windows Defender Device Guard is a combination of 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 will lock a device down so that it can only run trusted applications that you define in your code integrity policies. If the app isn’t trusted, it can’t run, period.
|
||||
|
||||
> [!NOTE]
|
||||
> Beginning with Windows 10, version 1709, configurable code integrity policies are known as Windows Defender Application Control.
|
||||
|
||||
With hardware that meets basic qualifications, Windows Defender Device Guard can also use 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:
|
||||
|
||||
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 30 KiB After Width: | Height: | Size: 32 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 33 KiB After Width: | Height: | Size: 38 KiB |
@ -6,6 +6,7 @@ ms.prod: w10
|
||||
ms.mktglfcycl: deploy
|
||||
ms.localizationpriority: high
|
||||
author: brianlic-msft
|
||||
ms.date: 10/20/2017
|
||||
---
|
||||
|
||||
# Introduction to Windows Defender Device Guard: virtualization-based security and code integrity policies
|
||||
@ -14,13 +15,14 @@ author: brianlic-msft
|
||||
- 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 on Windows 10 Enterprise 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. You designate these trusted apps by creating *code integrity policies*.
|
||||
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 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. You designate these trusted apps by creating *code integrity policies*.
|
||||
|
||||
Like the operating system, code integrity contains two primary components: kernel mode code integrity (KMCI) and user mode code integrity (UMCI). KMCI has been available in previous versions of the Windows operating system, and protects the kernel mode from running unsigned drivers. In Windows 10 and Windows Server 2016, UMCI is also available, to help protect against viruses and malware.
|
||||
> [!NOTE]
|
||||
> Beginning with Windows 10, version 1709, configurable code integrity policies are known as Windows Defender Application Control.
|
||||
|
||||
To increase the security level offered by code integrity policies, Windows Defender Device Guard can leverage advanced hardware features on hardware that supports them. These features include CPU virtualization extensions (called "Intel VT-x" or "AMD-V") and second-level address translation (SLAT). In addition, hardware that includes input/output memory management units (IOMMUs) provides even stronger protections. When you enable the features associated with CPU virtualization extensions and SLAT, the Code Integrity service can run alongside the kernel in a Windows hypervisor-protected container. The following table provides more information about how Windows Defender Device Guard and these hardware features can help protect against various threats.
|
||||
On hardware that includes CPU virtualization extensions (called "Intel VT-x" or "AMD-V") and second-level address translation (SLAT), Windows Defender Device Guard can also use Virtualization Based Security (VBS) to run the Code Integrity service alongside the kernel in a Windows hypervisor-protected container, which increases the security of code integrity policies. On hardware that includes input/output memory management units (IOMMUs), Windows Defender Device Guard can also help protect against DMA attacks. The following table provides more information about how Windows Defender Device Guard and these hardware features can help protect against various threats.
|
||||
|
||||
For an overview of the process of deploying Windows Defender Device Guard features, see [Planning and getting started on the Windows Defender Device Guard deployment process](planning-and-getting-started-on-the-device-guard-deployment-process.md).
|
||||
When Windows Defender Application Control and hardware-based security features are combined, Windows Defender Device Guard provides a locked-down configuration for computers.
|
||||
|
||||
## How Windows Defender Device Guard features help protect against threats
|
||||
|
||||
@ -28,17 +30,19 @@ The following table lists security threats and describes the corresponding Windo
|
||||
|
||||
| Security threat in the enterprise | How a Windows Defender Device Guard feature helps protect against the threat |
|
||||
| --------------------------------- | ----------------------------------------------------------- |
|
||||
| **Exposure to new malware**, for which the "signature" is not yet known | **Code integrity policies**: You can maintain a whitelist of software that is allowed to run (a configurable code integrity policy), rather than trying to stay ahead of attackers by maintaining a constantly-updated list of "signatures" of software that should be blocked. This approach uses the trust-nothing model well known in mobile device operating systems.<br>Only code that is verified by Code Integrity, usually through the digital signature that you have identified as being from a trusted signer, is allowed to run. This allows full control over allowed code in both kernel and user mode.<br><br>**Specialized hardware required?** No security-related hardware features are required, although code integrity policies are strengthened by such features, as described in the last three rows of this table. |
|
||||
| **Exposure to unsigned code** (most malware is unsigned) | **Code integrity policies, plus catalog files as needed**: Because most malware is unsigned, using a code integrity policy (which in most cases requires signed code) can immediately help protect against a large number of threats. However, many organizations use unsigned line-of-business (LOB) applications, for which the process of signing might be difficult. This has changed in Windows 10, because you can use a tool called Package Inspector to create a *catalog* of all deployed and executed binary files for your trusted applications. After you sign and distribute the catalog, your trusted applications can be handled by code integrity policies in the same way as any other signed application. With this foundation, you can more easily block all unsigned applications, allowing only signed applications to run.<br><br>**Specialized hardware required?** No security-related hardware features are required for creating and using code integrity policies and catalogs. However, code integrity policies and catalogs are strengthened by the hardware features, as described in later rows of this table. |
|
||||
| **Malware that gains access to the kernel** and then, from within the kernel, captures sensitive information or damages the system | **Virtualization-based security (VBS)**: This is protection that uses the hypervisor to help protect the kernel and other parts of the operating system. When VBS is enabled, it strengthens either the default kernel-mode code integrity policy (which protects against bad drivers or system files), or the configurable code integrity policy that you deploy.<br>With VBS, even if malware gains access to the kernel, the effects can be severely limited, because the hypervisor can prevent the malware from executing code. The hypervisor, the most privileged level of system software, enforces R/W/X permissions across system memory. Code integrity checks are performed in a secure environment which is resistant to attack from kernel mode software, and page permissions for kernel mode are set and maintained by the hypervisor. Even if there are vulnerabilities that allow memory modification, like a buffer overflow, the modified memory cannot be executed.<br><br>**Specialized hardware required?** Yes, VBS requires at least CPU virtualization extensions and SLAT, as described in [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). |
|
||||
| **DMA-based attacks**, for example, attacks launched from a malicious device that reads secrets from memory, making the enterprise more vulnerable to attack | **Virtualization-based security (VBS) using IOMMUs**: With this type of VBS protection, when the DMA-based attack makes a memory request, input/output memory management units (IOMMUs) will evaluate the request and deny access.<br><br>**Specialized hardware required?** Yes, IOMMUs are a hardware feature that supports the hypervisor, and if you choose hardware that includes them, they can help protect against malicious attempts to access memory. |
|
||||
| **Exposure to boot kits or to a physically present attacker at boot time** | **Universal Extensible Firmware Interface (UEFI) Secure Boot**: Secure Boot and related methods protect the boot process and firmware from tampering. This tampering can come from a physically present attacker or from forms of malware that run early in the boot process or in kernel after startup. UEFI is locked down (Boot order, Boot entries, Secure Boot, Virtualization extensions, IOMMU, Microsoft UEFI CA), so the settings in UEFI cannot be changed to compromise Windows Defender Device Guard security.<br><br>**Specialized hardware required?** With UEFI Secure Boot, the requirements are firmware requirements. For more information, 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). |
|
||||
| **Exposure to new malware**, for which the "signature" is not yet known | **Windows Defender Application Control**: You can maintain a whitelist of software that is allowed to run (a configurable code integrity policy), rather than constantly update a list of "signatures" of software that should be blocked. This approach uses the trust-nothing model well known in mobile device operating systems.<br>Only code that is verified by Windows Defender Application Control (AC), usually through the digital signature that you have identified as being from a trusted signer, is allowed to run. This allows full control over allowed code in both kernel and user mode.<br><br>**Specialized hardware required?** No security-related hardware features are required, but Windows Defender AC is strengthened by such features, as described in the next rows. |
|
||||
| **Exposure to unsigned code** (most malware is unsigned) | **Windows Defender AC plus catalog files as needed**: Because most malware is unsigned, Windows Defender AC (which in most cases requires signed code) can immediately help protect against a large number of threats. For organizations that use unsigned line-of-business (LOB) applications, you can use a tool called Package Inspector to create a *catalog* of all deployed and executed binary files for your trusted applications. After you sign and distribute the catalog, your trusted applications can be handled by Windows Defender AC in the same way as any other signed application. With this foundation, you can more easily block all unsigned applications, allowing only signed applications to run.<br><br>**Specialized hardware required?** No, but Windows Defender AC and catalogs are strengthened by the hardware features, as described in the next rows. |
|
||||
| **Malware that gains access to the kernel** and then, from within the kernel, captures sensitive information or damages the system | **Virtualization-based security (VBS)**: This is protection that uses the hypervisor to help protect the kernel and other parts of the operating system. When VBS is enabled, it strengthens either the default kernel-mode code integrity policy (which protects against bad drivers or system files), or the configurable code integrity policy that you deploy.<br>With VBS, even if malware gains access to the kernel, the effects can be severely limited because the hypervisor can prevent the malware from executing code. The hypervisor, the most privileged level of system software, enforces R/W/X permissions across system memory. Code integrity checks are performed in a secure environment which is resistant to attack from kernel mode software, and page permissions for kernel mode are set and maintained by the hypervisor. Even if there are vulnerabilities that allow memory modification, like a buffer overflow, the modified memory cannot be executed.<br><br>**Specialized hardware required?** Yes, VBS requires at least CPU virtualization extensions and SLAT, as described in [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). |
|
||||
| **DMA-based attacks**, for example, attacks launched from a malicious device that reads secrets from memory, making the enterprise more vulnerable to attack | **Virtualization-based security (VBS) using IOMMUs**: With this type of VBS protection, when the DMA-based attack makes a memory request, IOMMUs will evaluate the request and deny access.<br><br>**Specialized hardware required?** Yes, IOMMUs are a hardware feature that supports the hypervisor, and if you choose hardware that includes them, they can help protect against malicious attempts to access memory. |
|
||||
| **Exposure to boot kits or to a physically present attacker at boot time** | **Universal Extensible Firmware Interface (UEFI) Secure Boot**: Secure Boot and related methods protect the boot process and firmware from tampering. This tampering can come from a physically present attacker or from forms of malware that run early in the boot process or in the kernel after startup. UEFI is locked down (Boot order, Boot entries, Secure Boot, Virtualization extensions, IOMMU, Microsoft UEFI CA), so the settings in UEFI cannot be changed to compromise Windows Defender Device Guard security.<br><br>**Specialized hardware required?** UEFI Secure Boot has firmware requirements. For more information, 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 this guide, you learn about the individual features found within Windows Defender Device Guard as well as how to plan for, configure, and deploy them. Windows Defender Device Guard with configurable code integrity is intended for deployment alongside additional threat-mitigating Windows features such as [Windows Defender Credential Guard](/windows/access-protection/credential-guard/credential-guard) and [AppLocker](/windows/device-security/applocker/applocker-overview).
|
||||
|
||||
## New and changed functionality
|
||||
|
||||
As of Windows 10, version 1703, you can use code integrity policies not only to control applications, but also to control whether specific plug-ins, add-ins, and modules can run from specific apps (such as a line-of-business application or a browser). For more information, see [Use a code integrity policy to control specific plug-ins, add-ins, and modules](deploy-code-integrity-policies-steps.md#plug-ins).
|
||||
Beginning with Windows 10, version 1709, configurable code integrity policies are known as Windows Defender Application Control.
|
||||
|
||||
Beginning with Windows 10, version 1703, you can use code integrity policies not only to control applications, but also to control whether specific plug-ins, add-ins, and modules can run from specific apps (such as a line-of-business application or a browser). For more information, see [Use a code integrity policy to control specific plug-ins, add-ins, and modules](deploy-code-integrity-policies-steps.md#plug-ins).
|
||||
|
||||
## Tools for managing Windows Defender Device Guard features
|
||||
|
||||
|
||||
@ -6,6 +6,7 @@ ms.prod: w10
|
||||
ms.mktglfcycl: deploy
|
||||
ms.localizationpriority: high
|
||||
author: brianlic-msft
|
||||
ms.date: 10/20/2017
|
||||
---
|
||||
|
||||
# Optional: Create a code signing certificate for code integrity policies
|
||||
|
||||
@ -6,6 +6,7 @@ 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
|
||||
|
||||
@ -6,6 +6,7 @@ ms.prod: w10
|
||||
ms.mktglfcycl: deploy
|
||||
ms.localizationpriority: high
|
||||
author: brianlic-msft
|
||||
ms.date: 10/20/2017
|
||||
---
|
||||
|
||||
# Requirements and deployment planning guidelines for Windows Defender Device Guard
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user