edits

windows/security/threat-protection/device-guard/introduction-to-device-guard-virtualization-based-security-and-windows-defender-application-control.md

@@ -6,37 +6,37 @@ ms.prod: w10
 ms.mktglfcycl: deploy
 ms.localizationpriority: medium
 author: mdsakibMSFT
-ms.date: 08/23/2018
+ms.date: 08/2/2018
 ---
 
-# Device Guard: Windows Defender Application Control Configurable Code Integrity and Virtualization-based security
+# Device Guard: Windows Defender Application Control and Virtualization-based security
 
 **Applies to**
 -   Windows 10
 -   Windows Server 2016
 
-Windows 10 includes a set of hardware and OS technologies that, when configured together, allow enterprises to "lock down" Windows systems so they operate with many of the properties of mobile devices. In this configuration, specific technologies work together to restrict devices to only run authorized apps by using a feature called configurable code integrity (CI), while simultaneously hardening the OS against kernel memory attacks through the use of virtualization-based protection of code integrity (more specifically, HVCI). 
+Windows 10 includes a set of hardware and OS technologies that, when configured together, allow enterprises to "lock down" Windows systems so they operate with many of the properties of mobile devices. In this configuration, specific technologies work together to restrict devices to only run authorized apps by using a feature called configurable code integrity, while simultaneously hardening the OS against kernel memory attacks through the use of virtualization-based protection of code integrity (more specifically, HVCI). 
 
-Configurable CI and HVCI are very powerful protections that can be used separately. However, when these two technologies are configured to work together, they present a very strong protection capability for Windows 10 devices. Starting with the Windows 10 Anniversary Update (1607), this combined "configuration state" of Configurable CI and HVCI has been referred to as Windows Defender Device Guard. 
+Configurable code integrity policies and HVCI are very powerful protections that can be used separately. However, when these two technologies are configured to work together, they present a very strong protection capability for Windows 10 devices. This combined "configuration state" of configurable code integrity and HVCI has been referred to as Windows Defender Device Guard. 
 
-Using Configurable CI to restrict devices to only autherized apps has these advantages over other solutions:
+Using configurable code integrity to restrict devices to only authorized apps has these advantages over other solutions:
 
-1. Configurable CI policy is enforced by the Windows kernel itself. As such, the policy takes effect early in the boot sequence before nearly all other OS code and before traditional antivirus solutions run. 
+1. onfigurable code integrity policy is enforced by the Windows kernel itself. As such, the policy takes effect early in the boot sequence before nearly all other OS code and before traditional antivirus solutions run. 
-2. Configurable CI allows customers to set application control policy not only over code running in user mode, but also kernel mode hardware and software drivers and even code that runs as part of Windows. 
+2. Configurable code integrity allows customers to set application control policy not only over code running in user mode, but also kernel mode hardware and software drivers and even code that runs as part of Windows. 
-3. Customers can protect the configurable CI policy even from local administrator tampering by digitally signing the policy. This would mean that changing the policy would require both administrative privilege and access to the organization’s digital signing process, making it extremely difficult for an attacker with administrative privledge, or malicious software that managed to gain administrative privilege, to alter the application control policy. 
+3. Customers can protect the configurable code integrity policy even from local administrator tampering by digitally signing the policy. This would mean that changing the policy would require both administrative privilege and access to the organization’s digital signing process, making it extremely difficult for an attacker with administrative privledge, or malicious software that managed to gain administrative privilege, to alter the application control policy. 
-4. The entire configurable CI enforcement mechanism can be protected by HVCI, where even if a vulnerability exists in kernel mode code, the likelihood that an attacker could successfully exploit it is significantly diminished. Why is this relevant? That’s because an attacker that compromises the kernel would otherwise have enough privilege to disable most system defenses and override the application control policies enforced by configurable CI or any other application control solution.
+4. The entire configurable code integrity enforcement mechanism can be protected by HVCI, where even if a vulnerability exists in kernel mode code, the likelihood that an attacker could successfully exploit it is significantly diminished. Why is this relevant? That’s because an attacker that compromises the kernel would otherwise have enough privilege to disable most system defenses and override the application control policies enforced by configurable code integrity or any other application control solution.
 
 ## (Re-)Introducing Windows Defender Application Control
 
-When we originally designed the configuration state that we have referred to as Windows Defender Device Guard, we did so with a specific security promise in mind. Although there were no direct dependencies between the two main OS features of the Device Guard configuration, configurable CI and HVCI, we intentionally focused our discussion around the Device Guard lockdown state you achieve when deploying them together. 
+When we originally designed the configuration state that we have referred to as Windows Defender Device Guard, we did so with a specific security promise in mind. Although there were no direct dependencies between the two main OS features of the Device Guard configuration, configurable code integrity and HVCI, we intentionally focused our discussion around the Device Guard lockdown state you achieve when deploying them together. 
 
 However, the use of the term Device Guard to describe this configuration state has unintentionally left an impression for many IT professionals that the two features were inexorably linked and could not be deployed separately. 
 Additionally, given that HVCI relies on Windows virtualization-based security, it comes with additional hardware, firmware, and kernel driver compatibility requirements that some older systems can’t meet. 
 
-As a result, many IT Professionals assumed that because some systems couldn't use HVCI, they couldn’t use configurable CI either. 
+As a result, many IT Professionals assumed that because some systems couldn't use HVCI, they couldn’t use configurable code integrity either. 
-But configurable CI carries no specific hardware or software requirements other than running Windows 10, which means many IT professionals were wrongly denied the benefits of this powerful application control capability.
+But configurable code integrity carries no specific hardware or software requirements other than running Windows 10, which means many IT professionals were wrongly denied the benefits of this powerful application control capability.
 
-Since the initial release of Windows 10, the world has witnessed numerous hacking and malware attacks where application control alone could have prevented the attack altogether. With this in mind, we are discussing and documenting configurable CI as a independent technology within our security stack and giving it a name of its own: [Windows Defender Application Control](https://docs.microsoft.com/windows/security/threat-protection/windows-defender-application-control). 
+Since the initial release of Windows 10, the world has witnessed numerous hacking and malware attacks where application control alone could have prevented the attack altogether. With this in mind, we are discussing and documenting configurable code integrity as a independent technology within our security stack and giving it a name of its own: [Windows Defender Application Control](https://docs.microsoft.com/windows/security/threat-protection/windows-defender-application-control). 
 We hope this change will help us better communicate options for adopting application control within an organization.
 
 Does this mean Windows Defender Device Guard configuration state is going away? Not at all. The term Device Guard will continue to be used as a way to describe the fully locked down state achieved through the use of Windows Defender Application Control (WDAC), HVCI, and hardware and firmware security features. It also allows us to work with our OEM partners to identify specifications for devices that are “Device Guard capable” so that our joint customers can easily purchase devices that meet all of the hardware and firmware requirements of the original "Device Guard" locked down scenario for Windows 10 based devices.

windows/security/threat-protection/windows-defender-exploit-guard/exploit-protection-exploit-guard.md

@@ -11,7 +11,7 @@ ms.pagetype: security
 ms.localizationpriority: medium
 author: andreabichsel
 ms.author: v-anbic
-ms.date: 05/30/2018
+ms.date: 08/30/2018
 ---
 
 
@@ -56,7 +56,7 @@ Exploit protection works best with [Windows Defender Advanced Threat Protection]
  Many of the features in the [Enhanced Mitigation Experience Toolkit (EMET)](https://technet.microsoft.com/en-us/security/jj653751) have been included in Exploit protection, and you can convert and import existing EMET configuration profiles into Exploit protection. See the [Comparison between Enhanced Mitigation Experience Toolkit and Windows Defender Exploit Guard topic](emet-exploit-protection-exploit-guard.md) for more information on how Exploit protection supersedes EMET and what the benefits are when considering moving to Exploit protection on Windows 10. 
 
  >[!IMPORTANT]
- >If you are currently using EMET you should be aware that [EMET will reach end of life on July 31, 2018](https://blogs.technet.microsoft.com/srd/2016/11/03/beyond-emet/). You should consider replacing EMET with Exploit protection in Windows 10. You can [convert an existing EMET configuration file into Exploit protection](import-export-exploit-protection-emet-xml.md#convert-an-emet-configuration-file-to-an-exploit-protection-configuration-file) to make the migration easier and keep your existing settings.
+ >If you are currently using EMET, you should be aware that [EMET reached end of life on July 31, 2018](https://blogs.technet.microsoft.com/srd/2016/11/03/beyond-emet/). You should consider replacing EMET with Exploit protection in Windows 10. You can [convert an existing EMET configuration file into Exploit protection](import-export-exploit-protection-emet-xml.md#convert-an-emet-configuration-file-to-an-exploit-protection-configuration-file) to make the migration easier and keep your existing settings.
 
 >[!WARNING] 
 >Some security mitigation technologies may have compatibility issues with some applications. You should test Exploit protection in all target use scenarios by using [audit mode](audit-windows-defender-exploit-guard.md) before deploying the configuration across a production environment or the rest of your network.