mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-06-24 14:53:44 +00:00
Merge branch 'master' of https://cpubwin.visualstudio.com/_git/it-client into FromPrivateRepo
This commit is contained in:
Alma Jenks
@ -0,0 +1,30 @@
|
||||
# [Windows Defender Exploit Guard](windows-defender-exploit-guard.md)
|
||||
|
||||
## [Evaluate Windows Defender Exploit Guard](evaluate-windows-defender-exploit-guard.md)
|
||||
### [Use auditing mode to evaluate Windows Defender Exploit Guard](audit-windows-defender-exploit-guard.md)
|
||||
### [View Exploit Guard events](event-views-exploit-guard.md)
|
||||
|
||||
## [Exploit protection](exploit-protection-exploit-guard.md)
|
||||
### [Comparison with Enhanced Mitigation Experience Toolkit](emet-exploit-protection-exploit-guard.md)
|
||||
### [Evaluate Exploit protection](evaluate-exploit-protection.md)
|
||||
### [Enable Exploit protection](enable-exploit-protection.md)
|
||||
### [Customize Exploit protection](customize-exploit-protection.md)
|
||||
#### [Import, export, and deploy Exploit protection configurations](import-export-exploit-protection-emet-xml.md)
|
||||
### [Memory integrity](memory-integrity.md)
|
||||
#### [Requirements for virtualization-based protection of code integrity](requirements-and-deployment-planning-guidelines-for-virtualization-based-protection-of-code-integrity.md)
|
||||
#### [Enable virtualization-based protection of code integrity](enable-virtualization-based-protection-of-code-integrity.md)
|
||||
## [Attack surface reduction](attack-surface-reduction-exploit-guard.md)
|
||||
### [Evaluate Attack surface reduction](evaluate-attack-surface-reduction.md)
|
||||
### [Enable Attack surface reduction](enable-attack-surface-reduction.md)
|
||||
### [Customize Attack surface reduction](customize-attack-surface-reduction.md)
|
||||
### [Troubleshoot Attack surface reduction rules](troubleshoot-asr.md)
|
||||
## [Network Protection](network-protection-exploit-guard.md)
|
||||
### [Evaluate Network Protection](evaluate-network-protection.md)
|
||||
### [Enable Network Protection](enable-network-protection.md)
|
||||
### [Troubleshoot Network protection](troubleshoot-np.md)
|
||||
## [Controlled folder access](controlled-folders-exploit-guard.md)
|
||||
### [Evaluate Controlled folder access](evaluate-controlled-folder-access.md)
|
||||
### [Enable Controlled folder access](enable-controlled-folders-exploit-guard.md)
|
||||
### [Customize Controlled folder access](customize-controlled-folders-exploit-guard.md)
|
||||
|
||||
|
||||
@ -0,0 +1,280 @@
|
||||
---
|
||||
title: Enable virtualization-based protection of code integrity
|
||||
description: This article explains the steps to opt in to using HVCI on Windows devices.
|
||||
ms.prod: w10
|
||||
ms.mktglfcycl: deploy
|
||||
ms.localizationpriority: high
|
||||
ms.author: justinha
|
||||
author: brianlic-msft
|
||||
ms.date: 04/19/2018
|
||||
---
|
||||
|
||||
# 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.
|
||||
|
||||
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.
|
||||
If this happens, see [Troubleshooting](#troubleshooting) for remediation steps.
|
||||
|
||||
## How to turn on HVCI in Windows 10
|
||||
|
||||
To enable HVCI on Windows 10 devices with supporting hardware throughout an enterprise, use any of these options:
|
||||
- [Microsoft Intune (or another MDM provider)](#enable-hvci-using-intune)
|
||||
- [Group Policy](#enable-hvci-using-group-policy)
|
||||
- [System Center Configuration Manager](https://cloudblogs.microsoft.com/enterprisemobility/2015/10/30/managing-windows-10-device-guard-with-configuration-manager/)
|
||||
- [Registry](#use-registry-keys-to-enable-virtualization-based-protection-of-code-integrity)
|
||||
|
||||
### Enable HVCI using Intune
|
||||
|
||||
Enabling in Intune requires using the Code Integrity node in the [AppLocker CSP](https://docs.microsoft.com/windows/client-management/mdm/applocker-csp).
|
||||
|
||||
### Enable HVCI using Group Policy
|
||||
|
||||
1. Use Group Policy Editor (gpedit.msc) to either edit an existing GPO or create a new one.
|
||||
2. Navigate to **Computer Configuration** > **Administrative Templates** > **System** > **Device Guard**.
|
||||
3. Double-click **Turn on Virtualization Based Security**.
|
||||
4. Click **Enabled** and under **Virtualization Based Protection of Code Integrity**, select **Enabled with UEFI lock** to ensure HVCI cannot be enabled remotely or select **Enabled without UEFI lock**.
|
||||
|
||||
|
||||
|
||||
5. Click **Ok** to close the editor.
|
||||
|
||||
To apply the new policy on a domain-joined computer, either restart or run `gpupdate /force` in an elevated command prompt.
|
||||
|
||||
### 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.
|
||||
|
||||
<!--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 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:
|
||||
|
||||
` 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.
|
||||
|
||||
|
||||
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
A. If a device driver fails to load or crashes at runtime, you may be able to update the driver using **Device Manager**.
|
||||
|
||||
B. If you experience software or device malfunction after using the above procedure to turn on HVCI, but you are able to log in to Windows, you can turn off HVCI by renaming or deleting the SIPolicy.p7b file from the file location in step 3 above and then restart your device.
|
||||
|
||||
C. If you experience a critical error during boot or your system is unstable after using the above procedure to turn on HVCI, you can recover using the Windows Recovery Environment (Windows RE). To boot to Windows RE, see [Windows RE Technical Reference](https://docs.microsoft.com/windows-hardware/manufacture/desktop/windows-recovery-environment--windows-re--technical-reference). After logging in to Windows RE, you can turn off HVCI by renaming or deleting the SIPolicy.p7b file from the file location in step 3 above and then restart your device.
|
||||
|
||||
## How to turn off HVCI on the Windows 10 Fall Creators Update
|
||||
|
||||
1. Rename or delete the SIPolicy.p7b file located at C:\Windows\System32\CodeIntegrity.
|
||||
2. Restart the device.
|
||||
3. To confirm HVCI has been successfully disabled, open System Information and check **Virtualization-based security Services Running**, which should now have no value displayed.
|
||||
|
||||
## HVCI deployment in virtual machines
|
||||
|
||||
HVCI can protect a Hyper-V virtual machine, just as it would a physical machine. The steps to enable WDAC are the same from within the virtual machine.
|
||||
|
||||
WDAC 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 WDAC for a virtual machine:
|
||||
|
||||
```powershell
|
||||
Set-VMSecurity -VMName <VMName> -VirtualizationBasedSecurityOptOut $true
|
||||
```
|
||||
|
||||
### Requirements for running HVCI 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.
|
||||
- HVCI 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 HVCI. 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 HVCI. Before configuring a pass-through disk with AllowFullSCSICommandSet, you must first opt out of virtualization-based security using `Set-VMSecurity`.
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 74 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 37 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 65 KiB |
@ -0,0 +1,28 @@
|
||||
---
|
||||
title: Memory integrity
|
||||
keywords: mitigations, vulnerabilities, vulnerability, mitigation, exploit, exploits, emet
|
||||
description: Memory integrity.
|
||||
search.product: eADQiWindows 10XVcnh
|
||||
ms.pagetype: security
|
||||
ms.prod: w10
|
||||
ms.mktglfcycl: manage
|
||||
ms.sitesec: library
|
||||
ms.pagetype: security
|
||||
localizationpriority: medium
|
||||
author: iaanw
|
||||
ms.author: iawilt
|
||||
ms.date: 02/20/2018
|
||||
---
|
||||
|
||||
|
||||
|
||||
# Memory integrity
|
||||
|
||||
|
||||
**Applies to:**
|
||||
|
||||
- Windows 10, version 1709
|
||||
- Windows Server 2016
|
||||
|
||||
Memory integrity 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. Memory integrity helps block many types of malware from running on computers that run Windows 10 and Windows Server 2016.
|
||||
|
||||
@ -0,0 +1,74 @@
|
||||
---
|
||||
title: Requirements and deployment planning guidelines for irtualization-based protection of code integrity (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
|
||||
---
|
||||
|
||||
# Requirements and deployment planning guidelines for virtualization-based protection of code integrity
|
||||
|
||||
**Applies to**
|
||||
- Windows 10
|
||||
- Windows Server 2016
|
||||
|
||||
Computers must meet certain hardware, firmware, and software requirements in order to take adavantage of all of the virtualization-based security (VBS) features in Windows Defender Device Guard. Computers lacking these requirements can still be protected by Windows Defender Application Control (WDAC) policies—the difference is that those computers will not be as hardened against certain threats.
|
||||
|
||||
For example, hardware that includes CPU virtualization extensions and SLAT will be hardened against malware that attempts to gain access to the kernel, but without protected BIOS options such as “Boot only from internal hard drive,” the computer could be booted (by a malicious person who has physical access) into an operating system on bootable media.
|
||||
|
||||
> [!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).
|
||||
|
||||
The following tables provide more information about the hardware, firmware, and software required for deployment of various Windows Defender Device Guard features. The tables describe baseline protections, plus protections for improved security that are associated with hardware and firmware options available in 2015, 2016, and 2017.
|
||||
|
||||
> [!NOTE]
|
||||
> Beginning with Windows 10, version 1607, Trusted Platform Module (TPM 2.0) must be enabled by default on new computers.
|
||||
|
||||
## Baseline protections
|
||||
|
||||
|Baseline Protections | Description | Security benefits |
|
||||
|--------------------------------|----------------------------------------------------|-------------------|
|
||||
| Hardware: **64-bit CPU** | A 64-bit computer is required for the Windows hypervisor to provide VBS. | |
|
||||
| Hardware: **CPU virtualization extensions**,<br>plus **extended page tables** | These hardware features are required for VBS:<br>One of the following virtualization extensions:<br>• VT-x (Intel) or<br>• AMD-V<br>And:<br>• Extended page tables, also called Second Level Address Translation (SLAT). | VBS provides isolation of the secure kernel from the normal operating system. Vulnerabilities and zero-days in the normal operating system cannot be exploited because of this isolation. |
|
||||
| Firmware: **UEFI firmware version 2.3.1.c or higher with UEFI Secure Boot** | See the following Windows Hardware Compatibility Program requirement: [System.Fundamentals.Firmware.UEFISecureBoot](https://docs.microsoft.com/windows-hardware/design/compatibility/systems#systemfundamentalsfirmwareuefisecureboot) | UEFI Secure Boot helps ensure that the device boots only authorized code. This can prevent boot kits and root kits from installing and persisting across reboots. |
|
||||
| Firmware: **Secure firmware update process** | UEFI firmware must support secure firmware update found under the following Windows Hardware Compatibility Program requirement: [System.Fundamentals.Firmware.UEFISecureBoot](https://docs.microsoft.com/windows-hardware/design/compatibility/systems#systemfundamentalsfirmwareuefisecureboot) | UEFI firmware just like software can have security vulnerabilities that, when found, need to be patched through firmware updates. Patching helps prevent root kits from getting installed. |
|
||||
| Software: **HVCI compatible drivers** | See the Windows Hardware Compatibility Program requirements under [Filter.Driver.DeviceGuard.DriverCompatibility](https://docs.microsoft.com/windows-hardware/design/compatibility/filter#filterdriverdeviceguarddrivercompatibility).| [HVCI Compatible](https://blogs.msdn.microsoft.com/windows_hardware_certification/2015/05/22/driver-compatibility-with-device-guard-in-windows-10/) drivers help ensure that VBS can maintain appropriate memory permissions. This increases resistance to bypassing vulnerable kernel drivers and helps ensure that malware cannot run in kernel. Only code verified through code integrity can run in kernel mode. |
|
||||
| Software: Qualified **Windows operating system** | Windows 10 Enterprise, Windows 10 Education, Windows Server 2016, or Windows 10 IoT Enterprise<br><blockquote><p><strong>Important:</strong><br> Windows Server 2016 running as a domain controller does not support Windows Defender Credential Guard. Only virtualization-based protection of code integrity is supported in this configuration.</p></blockquote> | Support for VBS and for management features that simplify configuration of Windows Defender Device Guard. |
|
||||
|
||||
> **Important** The following tables list additional qualifications for improved security. You can use Windows Defender Device Guard with hardware, firmware, and software that support baseline protections, even if they do not support protections for improved security. However, we strongly recommend meeting these additional qualifications to significantly strengthen the level of security that Windows Defender Device Guard can provide.
|
||||
|
||||
## Additional qualifications for improved security
|
||||
|
||||
The following tables describe additional hardware and firmware qualifications, and the improved security that is available when these qualifications are met.
|
||||
|
||||
|
||||
### Additional security qualifications starting with Windows 10, version 1507, and Windows Server 2016, Technical Preview 4
|
||||
|
||||
| Protections for Improved Security | Description | Security benefits |
|
||||
|---------------------------------------------|----------------------------------------------------|------|
|
||||
| Firmware: **Securing Boot Configuration and Management** | • BIOS password or stronger authentication must be supported.<br>• In the BIOS configuration, BIOS authentication must be set.<br>• There must be support for protected BIOS option to configure list of permitted boot devices (for example, “Boot only from internal hard drive”) and boot device order, overriding BOOTORDER modification made by operating system.<br>• In the BIOS configuration, BIOS options related to security and boot options (list of permitted boot devices, boot order) must be secured to prevent other operating systems from starting and to prevent changes to the BIOS settings. | • BIOS password or stronger authentication helps ensure that only authenticated Platform BIOS administrators can change BIOS settings. This helps protect against a physically present user with BIOS access.<br>• Boot order when locked provides protection against the computer being booted into WinRE or another operating system on bootable media. |
|
||||
|
||||
<br>
|
||||
|
||||
### Additional security qualifications starting with Windows 10, version 1607, and Windows Server 2016
|
||||
|
||||
|
||||
| Protections for Improved Security | Description | Security benefits |
|
||||
|---------------------------------------------|----------------------------------------------------|-----|
|
||||
| Firmware: **Hardware Rooted Trust Platform Secure Boot** | • Boot Integrity (Platform Secure Boot) must be supported. See the Windows Hardware Compatibility Program requirements under [System.Fundamentals.Firmware.CS.UEFISecureBoot.ConnectedStandby](https://docs.microsoft.com/windows-hardware/design/compatibility/systems#systemfundamentalsfirmwarecsuefisecurebootconnectedstandby)<br>• The Hardware Security Test Interface (HSTI) 1.1.a must be implemented. See [Hardware Security Testability Specification](https://docs.microsoft.com/windows-hardware/test/hlk/testref/hardware-security-testability-specification). | • Boot Integrity (Platform Secure Boot) from Power-On provides protections against physically present attackers, and defense-in-depth against malware.<br>• HSTI 1.1.a provides additional security assurance for correctly secured silicon and platform. |
|
||||
| Firmware: **Firmware Update through Windows Update** | Firmware must support field updates through Windows Update and UEFI encapsulation update. | Helps ensure that firmware updates are fast, secure, and reliable. |
|
||||
| Firmware: **Securing Boot Configuration and Management** | • Required BIOS capabilities: Ability of OEM to add ISV, OEM, or Enterprise Certificate in Secure Boot DB at manufacturing time.<br>• Required configurations: Microsoft UEFI CA must be removed from Secure Boot DB. Support for 3rd-party UEFI modules is permitted but should leverage ISV-provided certificates or OEM certificate for the specific UEFI software.| • Enterprises can choose to allow proprietary EFI drivers/applications to run.<br>• Removing Microsoft UEFI CA from Secure Boot DB provides full control to enterprises over software that runs before the operating system boots. |
|
||||
|
||||
<br>
|
||||
|
||||
### Additional security qualifications starting with Windows 10, version 1703
|
||||
|
||||
|
||||
| Protections for Improved Security | Description | Security benefits |
|
||||
|---------------------------------------------|----------------------------------------------------|------|
|
||||
| Firmware: **VBS enablement of NX protection for UEFI runtime services** | • VBS will enable No-Execute (NX) protection on UEFI runtime service code and data memory regions. UEFI runtime service code must support read-only page protections, and UEFI runtime service data must not be exceutable.<br>• UEFI runtime service must meet these requirements: <br> • Implement UEFI 2.6 EFI_MEMORY_ATTRIBUTES_TABLE. All UEFI runtime service memory (code and data) must be described by this table. <br> • PE sections need to be page-aligned in memory (not required for in non-volitile storage).<br> • The Memory Attributes Table needs to correctly mark code and data as RO/NX for configuration by the OS:<br> • All entries must include attributes EFI_MEMORY_RO, EFI_MEMORY_XP, or both <br> • No entries may be left with neither of the above attributes, indicating memory that is both exceutable and writable. Memory must be either readable and executable or writeable and non-executable. <br><blockquote><p><strong>Notes:</strong><br>• This only applies to UEFI runtime service memory, and not UEFI boot service memory. <br>• This protection is applied by VBS on OS page tables.</p></blockquote><br> Please also note the following: <br>• Do not use sections that are both writeable and exceutable<br>• Do not attempt to directly modify executable system memory<br>• Do not use dynamic code | • Vulnerabilities in UEFI runtime, if any, will be blocked from compromising VBS (such as in functions like UpdateCapsule and SetVariable)<br>• Reduces the attack surface to VBS from system firmware. |
|
||||
| Firmware: **Firmware support for SMM protection** | The [Windows SMM Security Mitigations Table (WSMT) specification](http://download.microsoft.com/download/1/8/A/18A21244-EB67-4538-BAA2-1A54E0E490B6/WSMT.docx) contains details of an Advanced Configuration and Power Interface (ACPI) table that was created for use with Windows operating systems that support Windows virtualization-based security (VBS) features.| • Protects against potential vulnerabilities in UEFI runtime services, if any, will be blocked from compromising VBS (such as in functions like UpdateCapsule and SetVariable)<br>• Reduces the attack surface to VBS from system firmware.<br>• Blocks additional security attacks against SMM. |
|
||||
|
||||
Reference in New Issue
Block a user