revised configurable CI policies

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

@@ -14,9 +14,11 @@ 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 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. 
 
-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.
+Beginning with Windows 10, verwsion 1709, you designate these trusted apps by using Windows Defender Application Control (Windows Defender AC). On previous versions of Windows 10, this is done 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 protects the kernel mode from running unsigned drivers. Beginning with Windows 10 and Windows Server 2016, UMCI is also available to help protect against viruses and malware.
 
 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.
 
@@ -28,11 +30,11 @@ 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**:&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 new malware**, for which the "signature" is not yet known | **Windows Defender Application Control**:&nbsp;&nbsp;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) | **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. |
+| **Exposure to unsigned code** (most malware is unsigned) | **Windows Defender AC plus catalog files as needed**:&nbsp;&nbsp;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)**:&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). |
+| **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-windows-defender-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 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).