deepblue/windows-itpro-docs
1
0
Fork 0
mirror of https://github.com/MicrosoftDocs/windows-itpro-docs.git synced 2025-06-16 02:43:43 +00:00
Code Issues Actions 3 Packages Projects Releases Wiki Activity

Fix multiple broken bookmarks.

Browse Source
This commit is contained in:
John Tobin
2017-08-18 11:19:47 -07:00
parent 9e5d566b30
commit d71729971c
7 changed files with 17 additions and 16 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
windows/device-security/bitlocker/bitlocker-management-for-enterprises.md
View File

@ -50,7 +50,7 @@ Though much Windows BitLocker [documentation](bitlocker-overview.md) has been p
<a id="dom_join"></a>
## Recommendations for domain-joined computers
Windows continues to be the focus for new features and improvements for built-in encryption management, for example, automatically enabling encryption on devices that support InstantGo beginning with Windows 8.1. For more information, see [Overview of BitLocker Device Encryption in Windows 10](bitlocker-device-encryption-overview-windows-10.md#device-encryption).
Windows continues to be the focus for new features and improvements for built-in encryption management, for example, automatically enabling encryption on devices that support InstantGo beginning with Windows 8.1. For more information, see [Overview of BitLocker Device Encryption in Windows 10](bitlocker-device-encryption-overview-windows-10.md#bitlocker-device-encryption).
Companies that image their own computers using Microsoft System Center 2012 Configuration Manager SP1 (SCCM) or later can use an existing task sequence to [pre-provision BitLocker](https://technet.microsoft.com/library/hh846237.aspx#BKMK_PreProvisionBitLocker) encryption while in Windows Preinstallation Environment (WinPE) and can then [enable protection](https://technet.microsoft.com/library/hh846237.aspx#BKMK_EnableBitLocker). This can help ensure that computers are encrypted from the start, even before users receive them. As part of the imaging process, a company could also decide to use SCCM to pre-set any desired [BitLocker Group Policy](https://technet.microsoft.com/library/ee706521(v=ws.10).aspx).
@ -143,7 +143,7 @@ PS C:\> Enable-BitLocker -MountPoint "C:" -EncryptionMethod XtsAes256 -UsedSpace
[Microsoft BitLocker Administration and Management (MBAM)](https://technet.microsoft.com/windows/hh826072.aspx)
[Overview of BitLocker Device Encryption in Windows 10](bitlocker-device-encryption-overview-windows-10.md#device-encryption)
[Overview of BitLocker Device Encryption in Windows 10](bitlocker-device-encryption-overview-windows-10.md#bitlocker-device-encryption)
[System Center 2012 Configuration Manager SP1](https://technet.microsoft.com/library/hh846237.aspx#BKMK_PreProvisionBitLocker) *(Pre-provision BitLocker task sequence)*

4
windows/device-security/device-guard/deploy-code-integrity-policies-policy-rules-and-file-rules.md
View File

@ -15,7 +15,7 @@ author: brianlic-msft
- Windows Server 2016
Code integrity policies provide control over a computer running Windows 10 by specifying whether a driver or application is trusted and can be run. For an overview of code integrity, see:
- [How Windows Defender Device Guard features help protect against threats](introduction-to-device-guard-virtualization-based-security-and-code-integrity-policies.md#how-device-guard-features-help-protect-against-threats) in "Introduction to Windows Defender Device Guard: virtualization-based security and code integrity policies."
- [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) in "Introduction to Windows Defender Device Guard: virtualization-based security and code integrity policies."
- [Code integrity policy formats and signing](requirements-and-deployment-planning-guidelines-for-device-guard.md#code-integrity-policy-formats-and-signing) in "Requirements and deployment planning guidelines for Windows Defender Device Guard."
If you already understand the basics of code integrity policy and want procedures for creating, auditing, and merging code integrity policies, see [Deploy code integrity policies: steps](deploy-code-integrity-policies-steps.md).
@ -113,5 +113,5 @@ They could also choose to create a catalog that captures information about the u
## Related topics
- [How Windows Defender Device Guard features help protect against threats](introduction-to-device-guard-virtualization-based-security-and-code-integrity-policies.md#how-device-guard-features-help-protect-against-threats)
- [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)
- [Deploy code integrity policies: steps](deploy-code-integrity-policies-steps.md)

2
windows/device-security/device-guard/deploy-device-guard-deploy-code-integrity-policies.md
View File

@ -23,7 +23,7 @@ This section includes the following topics:
- [Deploy Managed Installer for Windows Defender Device Guard](deploy-managed-installer-for-device-guard.md)
To increase the protection for devices that meet certain hardware requirements, you can use virtualization-based security (VBS) with your code integrity 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-device-guard) in "Requirements and deployment planning guidelines for Windows Defender Device Guard."
- 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 [Deploy Windows Defender Device Guard: enable virtualization-based security](deploy-device-guard-enable-virtualization-based-security.md).
## Related topics

8
windows/device-security/device-guard/deploy-device-guard-enable-virtualization-based-security.md
View File

@ -18,7 +18,7 @@ Hardware-based security features, also called virtualization-based security or V
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.
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-device-guard).
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).
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).
@ -28,7 +28,7 @@ For information about enabling Windows Defender Credential Guard, see [Protect d
## 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-device-guard), you must confirm that certain operating system features are enabled before you can enable VBS:
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:
- Beginning with Windows 10, version 1607 or Windows Server 2016:<br>
Hyper-V Hypervisor, which is enabled automatically. No further action is needed.
@ -76,7 +76,7 @@ There are multiple ways to configure VBS features for Windows Defender Device Gu
Figure 4. Configure VBS, Secure Boot setting (in Windows 10, version 1607)
> **Important**&nbsp;&nbsp;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-device-guard-features-help-protect-against-threats).
> **Important**&nbsp;&nbsp;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.
@ -111,7 +111,7 @@ Set the following registry keys to enable VBS and Windows Defender Device Guard.
<!--This comment ensures that the Important above and the Warning below don't merge together. -->
> **Important**&nbsp;&nbsp;
> - 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-device-guard-features-help-protect-against-threats).<br>
> - 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>
> - 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

6
windows/device-security/device-guard/introduction-to-device-guard-virtualization-based-security-and-code-integrity-policies.md
View File

@ -30,9 +30,9 @@ The following table lists security threats and describes the corresponding Windo
| --------------------------------- | ----------------------------------------------------------- |
| **Exposure to new malware**, for which the "signature" is not yet known | **Code integrity policies**:&nbsp;&nbsp;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**:&nbsp;&nbsp;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)**:&nbsp;&nbsp;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-device-guard). |
| **Malware that gains access to the kernel** and then, from within the kernel, captures sensitive information or damages the system | **Virtualization-based security (VBS)**:&nbsp;&nbsp;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**:&nbsp;&nbsp;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**:&nbsp;&nbsp; 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-device-guard). |
| **Exposure to boot kits or to a physically present attacker at boot time** | **Universal Extensible Firmware Interface (UEFI) Secure Boot**:&nbsp;&nbsp; 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). |
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).
@ -48,7 +48,7 @@ You can easily manage Windows Defender Device Guard features by using familiar e
- **Group Policy**. Windows 10 provides an administrative template to configure and deploy the configurable code integrity policies for your organization. This template also allows you to specify which hardware-based security features you would like to enable and deploy. You can manage these settings along with your existing Group Policy Objects (GPOs), which makes it simpler to implement Windows Defender Device Guard features. In addition to these code integrity and hardware-based security features, you can use Group Policy to help you manage your catalog files.
- For a description of catalog files, see the table row describing **Exposure to unsigned code** in [How Windows Defender Device Guard features help protect against threats](#how-device-guard-features-help-protect-against-threats), earlier in this topic.
- For a description of catalog files, see the table row describing **Exposure to unsigned code** in [How Windows Defender Device Guard features help protect against threats](#how-windows-defender-device-guard-features-help-protect-against-threats), earlier in this topic.
- For information about using Group Policy as a deployment tool, see:<br>[Deploy catalog files with Group Policy](deploy-catalog-files-to-support-code-integrity-policies.md#deploy-catalog-files-with-group-policy)<br>[Deploy and manage code integrity policies with Group Policy](deploy-code-integrity-policies-steps.md#deploy-and-manage-code-integrity-policies-with-group-policy)
- **Microsoft System Center Configuration Manager**. You can use System Center Configuration Manager to simplify deployment and management of catalog files, code integrity policies, and hardware-based security features, as well as provide version control. For more information, see [Deploy catalog files with System Center Configuration Manager](deploy-catalog-files-to-support-code-integrity-policies.md#deploy-catalog-files-with-system-center-configuration-manager).

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

@ -18,9 +18,10 @@ This topic provides a roadmap for planning and getting started on the Windows De
## 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-code-integrity-policies.md#how-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 [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-device-guard).
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-code-integrity-policies.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 [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. **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#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 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 code integrity policy for them. More variety across departments might mean you need to create and manage more code integrity policies. The following questions can help you clarify how many code integrity policies to create:
- How standardized is the hardware?<br>This can be relevant because of drivers. You could create a code integrity 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 code integrity policies on different "reference" hardware, then merge the policies together, to ensure that the resulting policy recognizes all the drivers in your environment.
@ -67,7 +68,7 @@ This topic provides a roadmap for planning and getting started on the Windows De
- [Enforce code integrity policies](deploy-code-integrity-policies-steps.md#enforce-code-integrity-policies)
- [Deploy and manage code integrity policies with Group Policy](deploy-code-integrity-policies-steps.md#deploy-and-manage-code-integrity-policies-with-group-policy)<br>
8. **Enable desired hardware (VBS) security features**. Hardware-based security features—also called virtualization-based security (VBS) features—strengthen the protections offered by code integrity policies, as described in [How Windows Defender Device Guard features help protect against threats](introduction-to-device-guard-virtualization-based-security-and-code-integrity-policies.md#how-device-guard-features-help-protect-against-threats).
8. **Enable desired hardware (VBS) security features**. Hardware-based security features—also called virtualization-based security (VBS) features—strengthen the protections offered by code integrity policies, as described in [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).
> [!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).

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

@ -32,7 +32,7 @@ You can deploy Windows Defender Device Guard in phases, and plan these phases in
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.
> **Notes**<br>
> • To understand the requirements in the following tables, you will need to be familiar with the main features in Windows Defender Device Guard: configurable code integrity policies, virtualization-based security (VBS), and Universal Extensible Firmware Interface (UEFI) Secure Boot. For information about these features, see [How Windows Defender Device Guard features help protect against threats](introduction-to-device-guard-virtualization-based-security-and-code-integrity-policies.md#how-device-guard-features-help-protect-against-threats).<br>
> • To understand the requirements in the following tables, you will need to be familiar with the main features in Windows Defender Device Guard: configurable code integrity policies, virtualization-based security (VBS), and Universal Extensible Firmware Interface (UEFI) Secure Boot. For information about these features, see [How Windows Defender Device Guard features help protect against threats](introduction-to-windows-defender-device-guard-virtualization-based-security-and-code-integrity-policies.md#how-device-guard-features-help-protect-against-threats).<br>
> • Beginning with Windows 10, version 1607, Trusted Platform Module (TPM 2.0) must be enabled by default on new computers.
## Baseline protections