Merged PR 5118: 1/3 AM Publish

windows/device-security/device-guard/deploy-catalog-files-to-support-code-integrity-policies.md

@@ -1,6 +1,6 @@
 ---
 title: Deploy catalog files to support code integrity policies (Windows 10)
-description: This article describes how to deploy catalog files to support code integrity policies, one of the main features that are part of Windows Defender Device Guard in Windows 10. 
+description: This article describes how to deploy catalog files to support Windows Defender Application Control, one of the main features that are part of Windows Defender Device Guard in Windows 10. 
 keywords: virtualization, security, malware
 ms.prod: w10
 ms.mktglfcycl: deploy
@@ -9,29 +9,29 @@ author: brianlic-msft
 ms.date: 10/27/2017
 ---
 
-# Deploy catalog files to support code integrity policies
+# Deploy catalog files to support Windows Defender Application Control
 
 **Applies to**
 -   Windows 10
 -   Windows Server 2016
 
-Catalog files can be important in your deployment of code integrity polices if you have unsigned line-of-business (LOB) applications for which the process of signing is difficult. To prepare to create code integrity policies that allow these trusted applications but block unsigned code (most malware is unsigned), you create a *catalog file* that contains information about the 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.
+Catalog files can be important in your deployment of Windows Defender Application Control (WDAC) if you have unsigned line-of-business (LOB) applications for which the process of signing is difficult. To prepare to create WDAC policies that allow these trusted applications but block unsigned code (most malware is unsigned), you create a *catalog file* that contains information about the trusted applications. After you sign and distribute the catalog, your trusted applications can be handled by WDAC 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.
 
 For more description of catalog files, see [Reviewing your applications: application signing and catalog files](requirements-and-deployment-planning-guidelines-for-device-guard.md#reviewing-your-applications-application-signing-and-catalog-files) in "Requirements and deployment planning guidelines for Windows Defender Device Guard." 
 
 ## Create catalog files
 
-The creation of a catalog file is a necessary step for adding an unsigned application to a code integrity policy.
+The creation of a catalog file simplifies the steps to run unsigned applications in the presence of a WDAC policy.
 
-To create a catalog file, you use a tool called **Package Inspector**. You must also have a code integrity policy deployed in audit mode on the computer on which you run Package Inspector, because Package Inspector does not always detect installation files that have been removed from the computer during the installation process.
+To create a catalog file, you use a tool called **Package Inspector**. You must also have a WDAC policy deployed in audit mode on the computer on which you run Package Inspector, so that Package Inspector can include any temporary installation files that are added and then removed from the computer during the installation process.
 
 > **Note**  When you establish a naming convention it makes it easier to detect deployed catalog files in the future. In this guide, *\*-Contoso.cat* is used as the example naming convention. For more information about why this practice is helpful to inventory or detect catalog files, see [Inventory catalog files with System Center Configuration Manager](#inventory-catalog-files-with-system-center-configuration-manager), later in this topic.
 
-1.  Be sure that a code integrity policy is currently deployed in audit mode on the computer on which you will run Package Inspector.
+1.  Be sure that a WDAC policy is currently deployed in audit mode on the computer on which you will run Package Inspector.
 
-    Package Inspector does not always detect installation files that have been removed from the computer during the installation process. To ensure that these binaries are also trusted, deploy a code integrity policy in audit mode. You can use the code integrity policy that you created and audited in [Create a code integrity policy from a reference computer](deploy-code-integrity-policies-steps.md#create-a-code-integrity-policy-from-a-reference-computer) and [Audit code integrity policies](deploy-code-integrity-policies-steps.md#audit-code-integrity-policies).
+    Package Inspector does not always detect temporary installation files that are added and then removed from the computer during the installation process. To ensure that these binaries are also included in your catalog file, deploy a WDAC policy in audit mode. You can use the WDAC policy that you created and audited in [Create a Windows Defender Application Control policy from a reference computer](deploy-code-integrity-policies-steps.md#create-a-windows-defender-application-control-policy-from-a-reference-computer) and [Audit Windows Defender Application Control policies](deploy-code-integrity-policies-steps.md#audit-windows-defender-application-control-policies).
 
-    > **Note**  This process should **not** be performed on a system with an enforced Windows Defender Device Guard policy, only with a policy in audit mode. If a policy is currently being enforced, you will not be able to install and run the application.
+    > **Note**  This process should **not** be performed on a system with an enforced Windows Defender Application Control policy, only with a policy in audit mode. If a policy is currently being enforced, you will not be able to install and run the application unless the policy already allows it.
 
 2.  Start Package Inspector, and then start scanning a local drive, for example, drive C:
 
@@ -41,7 +41,7 @@ To create a catalog file, you use a tool called **Package Inspector**. You must
     
 3.  Copy the installation media to the local drive (typically drive C).
 
-    By copying the installation media to the local drive, you ensure that Package Inspector detects and catalogs the actual installer. If you skip this step, the future code integrity policy may trust the application to run but not to be installed.
+    By copying the installation media to the local drive, you ensure that Package Inspector detects and catalogs the actual installer. If you skip this step, the future WDAC policy may allow the application to run but not to be installed.
 
 4.  Install the application. Install it to the same drive that the application installer is located on (the drive you are scanning). Also, while Package Inspector is running, do not run any installations or updates that you don't want to capture in the catalog.
 
@@ -73,11 +73,11 @@ To create a catalog file, you use a tool called **Package Inspector**. You must
 
 When finished, the files will be saved to your desktop. You can double-click the \*.cat file to see its contents, and you can view the \*.cdf file with a text editor. 
 
-To trust this catalog file within a code integrity policy, the catalog must first be signed. Then, the signing certificate can be added to the code integrity policy, and the catalog file can be distributed to the individual client computers. 
+To trust the contents of the catalog file within a WDAC policy, the catalog must first be signed. Then, the signing certificate can be added to the WDAC policy, and the catalog file can be distributed to the individual client computers. 
 
 For information about signing catalog files by using a certificate and SignTool.exe, a free tool available in the Windows SDK, see the next section, [Catalog signing with SignTool.exe](#catalog-signing-with-signtoolexe).
 
-For information about adding the signing certificate to a code integrity policy, see [Add a catalog signing certificate to a code integrity policy](#add-a-catalog-signing-certificate-to-a-code-integrity-policy).
+For information about adding the signing certificate to a WDAC policy, see [Add a catalog signing certificate to a Windows Defender Application Control policy](#add-a-catalog-signing-certificate-to-a-windows-defender-application-control-policy).
 
 ### Resolving package failures
 
@@ -95,7 +95,7 @@ Packages can fail for the following reasons:
     - Package Inspector is completely incompatible if files in the package (temporary or otherwise) change hash each time the package is installed. You can diagnose this by looking at the hash field in the 3077 block events when the package is failing in enforcement.  If each time you attempt to run the package you get a new block event with a different hash, the package will not work with Package Inspector
 - Files with an invalid signature blob or otherwise “unhashable” files
     - This issue arises when a file that has been signed is modified post signing in a way that invalidates the PE header and renders the file unable to be hashed by the Authenticode Spec.
-    - Device Guard uses Authenticode Hashes to validate files when they are running. If the file is unhashable via the authenticode SIP, there is no way to identify the file to allow it, regardless of if you attempt to add the file to the policy directly, or re-sign the file with a Package Inspector catalog (the signature is invalidated due to file being edited, file can’t be allowed by hash due to authenticode hashing algorithm rejecting it)
+    - WDAC uses Authenticode Hashes to validate files when they are running. If the file is unhashable via the authenticode SIP, there is no way to identify the file to allow it, regardless of if you attempt to add the file to the policy directly, or re-sign the file with a Package Inspector catalog (the signature is invalidated due to file being edited, file can’t be allowed by hash due to authenticode hashing algorithm rejecting it)
     - Recent versions of InstallShield packages that use custom actions can hit this. If the DLL input to the custom action was signed before being put through InstallShield, InstallShield adds tracking markers to the file (editing it post signature) which leaves the file in this “unhashable” state and renders the file unable to be allowed by Device Guard (regardless of if you try to allow directly by policy or resign with Package Inspector)
 
 ## Catalog signing with SignTool.exe
@@ -108,7 +108,7 @@ In this section, you sign a catalog file you generated by using PackageInspector
 
 -   An internal certification authority (CA) code signing certificate or purchased code signing certificate
 
-If you do not have a code signing certificate, see [Optional: Create a code signing certificate for code integrity policies](optional-create-a-code-signing-certificate-for-code-integrity-policies.md) for a walkthrough of how to create one. That topic uses an example certificate name of **ContosoDGSigningCert**, and the procedure that follows uses that example certificate name to sign the catalog file that you created in [Create catalog files](#create-catalog-files), earlier in this topic. If you are using an alternate certificate or catalog file, update the following steps with the appropriate variables and certificate. 
+If you do not have a code signing certificate, see [Optional: Create a code signing certificate for Windows Defender Application Control](optional-create-a-code-signing-certificate-for-code-integrity-policies.md) for a walkthrough of how to create one. That topic uses an example certificate name of **ContosoDGSigningCert**, and the procedure that follows uses that example certificate name to sign the catalog file that you created in [Create catalog files](#create-catalog-files), earlier in this topic. If you are using an alternate certificate or catalog file, update the following steps with the appropriate variables and certificate. 
 
 To sign the existing catalog file, copy each of the following commands into an elevated Windows PowerShell session.
 
@@ -120,7 +120,7 @@ To sign the existing catalog file, copy each of the following commands into an e
 
     > **Note**  This example specifies the catalog file you created in the [Create catalog files](#create-catalog-files) section. If you are signing another catalog file, update the *$ExamplePath* and *$CatFileName* variables with the correct information.
 
-2.  Import the code signing certificate that will be used to sign the catalog file. Import it to the signing user’s personal store. This example uses the certificate name from [Optional: Create a code signing certificate for code integrity policies](optional-create-a-code-signing-certificate-for-code-integrity-policies.md).
+2.  Import the code signing certificate that will be used to sign the catalog file. Import it to the signing user’s personal store. This example uses the certificate name from [Optional: Create a code signing certificate for Windows Defender Application Control](optional-create-a-code-signing-certificate-for-code-integrity-policies.md).
 
 3.  Sign the catalog file with Signtool.exe:
 
@@ -140,29 +140,29 @@ To sign the existing catalog file, copy each of the following commands into an e
 
     For testing purposes, you can manually copy signed catalog files to their intended folder. For large-scale implementations, to copy the appropriate catalog files to all desired computers, we recommend that you use Group Policy File Preferences or an enterprise systems management product such as System Center Configuration Manager. Doing this also simplifies the management of catalog versions.
 
-## Add a catalog signing certificate to a code integrity policy
+## Add a catalog signing certificate to a Windows Defender Application Control policy
 
-After the catalog file is signed, add the signing certificate to a code integrity policy, as described in the following steps.
+After the catalog file is signed, add the signing certificate to a WDAC policy, as described in the following steps.
 
 1.  If you have not already verified the catalog file digital signature, right-click the catalog file, and then click **Properties**. On the **Digital Signatures** tab, verify that your signing certificate exists with the algorithm you expect.
 
-2.  If you already have an XML policy file that you want to add the signing certificate to, skip to the next step. Otherwise, use [New-CIPolicy](https://technet.microsoft.com/library/mt634473.aspx) to create a code integrity policy that you will later merge into another policy (not deploy as-is). This example creates a policy called **CatalogSignatureOnly.xml** in the location **C:\\PolicyFolder**:
+2.  If you already have an XML policy file that you want to add the signing certificate to, skip to the next step. Otherwise, use [New-CIPolicy](https://technet.microsoft.com/library/mt634473.aspx) to create a WDAC policy that you will later merge into another policy (not deploy as-is). This example creates a policy called **CatalogSignatureOnly.xml** in the location **C:\\PolicyFolder**:
 
     ` New-CIPolicy -Level PcaCertificate -FilePath C:\PolicyFolder\CatalogSignatureOnly.xml –UserPEs`
 
     > **Note**  Include the **-UserPEs** parameter to ensure that the policy includes user mode code integrity.
 
-3.  Use [Add-SignerRule](https://technet.microsoft.com/library/mt634479.aspx) to add the signing certificate to the code integrity policy, filling in the correct path and filenames for `<policypath>` and `<certpath>`:
+3.  Use [Add-SignerRule](https://technet.microsoft.com/library/mt634479.aspx) to add the signing certificate to the WDAC policy, filling in the correct path and filenames for `<policypath>` and `<certpath>`:
 
     ` Add-SignerRule -FilePath <policypath> -CertificatePath <certpath> -User `
 
-If you used step 2 to create a new code integrity policy, and want information about merging policies together, see [Merge code integrity policies](deploy-code-integrity-policies-steps.md#merge-code-integrity-policies).  
+If you used step 2 to create a new WDAC policy, and want information about merging policies together, see [Merge Windows Defender Application Control policies](deploy-code-integrity-policies-steps.md#merge-windows-defender-application-control-policies).  
 
 ## Deploy catalog files with Group Policy
 
 To simplify the management of catalog files, you can use Group Policy preferences to deploy catalog files to the appropriate computers in your organization. The following process walks you through the deployment of a signed catalog file called **LOBApp-Contoso.cat** to a test OU called DG Enabled PCs with a GPO called **Contoso DG Catalog File GPO Test**.
 
-> **Note**&nbsp;&nbsp;This walkthrough requires that you have previously created a signed catalog file and have a computer running Windows 10 on which to test a Group Policy deployment. For more information about how to create a catalog file, see [Create catalog files](#create-catalog-files), earlier in this topic. Also, before you begin testing of a catalog file with the code integrity policy it supports, review [Add a catalog signing certificate to a code integrity policy](#add-a-catalog-signing-certificate-to-a-code-integrity-policy).
+> **Note**&nbsp;&nbsp;This walkthrough requires that you have previously created a signed catalog file and have a computer running Windows 10 on which to test a Group Policy deployment. For more information about how to create a catalog file, see [Create catalog files](#create-catalog-files), earlier in this topic. Also, before you begin testing of a catalog file with the WDAC policy it supports, review [Add a catalog signing certificate to a Windows Defender Application Control policy](#add-a-catalog-signing-certificate-to-a-windows-defender-application-control-policy).
 
 **To deploy a catalog file with Group Policy:**
 
@@ -170,7 +170,7 @@ To simplify the management of catalog files, you can use Group Policy preference
 
 2.  Create a new GPO: right-click an OU, for example, the **DG Enabled PCs OU**, and then click **Create a GPO in this domain, and Link it here**, as shown in Figure 2.
 
-    > **Note**&nbsp;&nbsp;You can use any OU name. Also, security group filtering is an option when you consider different ways of combining code integrity policies (or keeping them separate), as discussed in [Planning and getting started on the Windows Defender Device Guard deployment process](planning-and-getting-started-on-the-device-guard-deployment-process.md).
+    > **Note**&nbsp;&nbsp;You can use any OU name. Also, security group filtering is an option when you consider different ways of combining WDAC policies (or keeping them separate), as discussed in [Planning and getting started on the Windows Defender Device Guard deployment process](planning-and-getting-started-on-the-device-guard-deployment-process.md).
 
    ![Group Policy Management, create a GPO](images/dg-fig13-createnewgpo.png)
 
@@ -210,7 +210,7 @@ To simplify the management of catalog files, you can use Group Policy preference
 
 12. Close the Group Policy Management Editor, and then update the policy on the test computer running Windows 10, by running GPUpdate.exe. When the policy has been updated, verify that the catalog file exists in C:\\Windows\\System32\\catroot\\{F750E6C3-38EE-11D1-85E5-00C04FC295EE} on the computer running Windows 10.
 
-Before you begin testing the deployed catalog file, make sure that the catalog signing certificate has been added to an appropriate code integrity policy, as described in [Add a catalog signing certificate to a code integrity policy](#add-a-catalog-signing-certificate-to-a-code-integrity-policy).
+Before you begin testing the deployed catalog file, make sure that the catalog signing certificate has been added to an appropriate WDAC policy, as described in [Add a catalog signing certificate to a Windows Defender Application Control policy](#add-a-catalog-signing-certificate-to-a-windows-defender-application-control-policy).
 
 ## Deploy catalog files with System Center Configuration Manager
 
@@ -284,7 +284,7 @@ After you create the deployment package, deploy it to a collection so that the c
 
 11. Close the wizard.
 
-Before you begin testing the deployed catalog file, make sure that the catalog signing certificate has been added to an appropriate code integrity policy, as described in [Add a catalog signing certificate to a code integrity policy](#add-a-catalog-signing-certificate-to-a-code-integrity-policy).
+Before you begin testing the deployed catalog file, make sure that the catalog signing certificate has been added to an appropriate WDAC policy, as described in [Add a catalog signing certificate to a Windows Defender Application Control policy](#add-a-catalog-signing-certificate-to-a-windows-defender-application-control-policy).
 
 ## Inventory catalog files with System Center Configuration Manager
 
@@ -338,9 +338,9 @@ At the time of the next software inventory cycle, when the targeted clients rece
 
 ## Related topics
 
-- [Introduction to Windows Defender Device Guard: virtualization-based security and code integrity policies](introduction-to-device-guard-virtualization-based-security-and-code-integrity-policies.md)
+- [Introduction to Windows Defender Device Guard: virtualization-based security and Windows Defender Application Control](introduction-to-device-guard-virtualization-based-security-and-code-integrity-policies.md)
 
 - [Planning and getting started on the Windows Defender Device Guard deployment process](planning-and-getting-started-on-the-device-guard-deployment-process.md)
 
-- [Deploy Windows Defender Device Guard: deploy code integrity policies](deploy-device-guard-deploy-code-integrity-policies.md)
+- [Deploy Windows Defender Application Control](deploy-device-guard-deploy-code-integrity-policies.md)
 

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

@@ -9,81 +9,81 @@ author: brianlic-msft
 ms.date: 10/20/2017
 ---
 
-# Deploy code integrity policies: policy rules and file rules
+# Deploy Windows Defender Application Control: policy rules and file rules
 
 **Applies to**
 -   Windows 10
 -   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:
+Windows Defender Application Control (WDAC) provides control over a computer running Windows 10 by specifying whether a driver or application is trusted and can be run. For an overview of WDAC, 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) 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 Windows Defender Application Control."
-- [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."
+- [Windows Defender Application Control policy formats and signing](requirements-and-deployment-planning-guidelines-for-device-guard.md#windows-defender-application-control-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).
+If you already understand the basics of WDAC and want procedures for creating, auditing, and merging WDAC policies, see [Deploy Windows Defender Application Control: steps](deploy-code-integrity-policies-steps.md).
 
 This topic includes the following sections:
 
-- [Overview of the process of creating code integrity policies](#overview-of-the-process-of-creating-code-integrity-policies): Helps familiarize you with the process described in this and related topics.
+- [Overview of the process of creating Windows Defender Application Control policies](#overview-of-the-process-of-creating-windows-defender-application-control-policies): Helps familiarize you with the process described in this and related topics.
-- [Code integrity policy rules](#code-integrity-policy-rules): Describes one key element you specify in a policy, the *policy rules*, which control options such as audit mode or whether user mode code integrity (UMCI) is enabled in a code integrity policy.
+- [Windows Defender Application Control policy rules](#windows-defender-application-control-policy-rules): Describes one key element you specify in a policy, the *policy rules*, which control options such as audit mode or whether user mode code integrity (UMCI) is enabled in a WDAC policy.
-- [Code integrity file rule levels](#code-integrity-file-rule-levels): Describes the other key element you specify in a policy, the *file rules* (or *file rule levels*), which specify the level at which applications will be identified and trusted.
+- [Windows Defender Application Control file rule levels](#windows-defender-application-control-file-rule-levels): Describes the other key element you specify in a policy, the *file rules* (or *file rule levels*), which specify the level at which applications will be identified and trusted.
 - [Example of file rule levels in use](#example-of-file-rule-levels-in-use): Gives an example of how file rule levels can be applied.
 
-## Overview of the process of creating code integrity policies
+## Overview of the process of creating Windows Defender Application Control policies
 
-A common system imaging practice in today’s IT organization is to establish a “golden” image as a reference for what an ideal system should look like, and then use that image to clone additional company assets. Code integrity policies follow a similar methodology, that begins with the establishment of a golden computer. As with imaging, you can have multiple golden computers based on model, department, application set, and so on. Although the thought process around the creation of code integrity policies is similar to imaging, these policies should be maintained independently. Assess the necessity of additional code integrity policies based on what should be allowed to be installed and run and for whom. For more details on doing this assessment, see the planning steps in [Planning and getting started on the Windows Defender Device Guard deployment process](planning-and-getting-started-on-the-device-guard-deployment-process.md).
+A common system imaging practice in today’s IT organization is to establish a “golden” image as a reference for what an ideal system should look like, and then use that image to clone additional company assets. WDAC policies follow a similar methodology, that begins with the establishment of a golden computer. As with imaging, you can have multiple golden computers based on model, department, application set, and so on. Although the thought process around the creation of WDAC policies is similar to imaging, these policies should be maintained independently. Assess the necessity of additional WDAC policies based on what should be allowed to be installed and run and for whom. For more details on doing this assessment, see the planning steps in [Planning and getting started on the Windows Defender Device Guard deployment process](planning-and-getting-started-on-the-device-guard-deployment-process.md).
 
-> **Note**  Each computer can have only **one** code integrity policy at a time. Whichever way you deploy this policy, it is renamed to SIPolicy.p7b and copied to **C:\\Windows\\System32\\CodeIntegrity** and, for UEFI computers, **<EFI System Partition>\\Microsoft\\Boot**. Keep this in mind when you create your code integrity policies.
+> **Note**  Each computer can have only **one** WDAC policy at a time. Whichever way you deploy this policy, it is renamed to SIPolicy.p7b and copied to **C:\\Windows\\System32\\CodeIntegrity** and, for UEFI computers, **<EFI System Partition>\\Microsoft\\Boot**. Keep this in mind when you create your WDAC policies.
 
-Optionally, code integrity policies can align with your software catalog as well as any IT department–approved applications. One straightforward method to implement code integrity policies is to use existing images to create one master code integrity policy. You do so by creating a code integrity policy from each image, and then by merging the policies. This way, what is installed on all of those images will be allowed to run, if the applications are installed on a computer based on a different image. Alternatively, you may choose to create a base applications policy and add policies based on the computer’s role or department. Organizations have a choice of how their policies are created, merged or serviced, and managed.
+Optionally, WDAC can align with your software catalog as well as any IT department–approved applications. One straightforward method to implement WDAC is to use existing images to create one master WDAC policy. You do so by creating a WDAC policy from each image, and then by merging the policies. This way, what is installed on all of those images will be allowed to run, if the applications are installed on a computer based on a different image. Alternatively, you may choose to create a base applications policy and add policies based on the computer’s role or department. Organizations have a choice of how their policies are created, merged or serviced, and managed.
 
-If you plan to use an internal CA to sign catalog files or code integrity policies, see the steps in [Optional: Create a code signing certificate for code integrity policies](optional-create-a-code-signing-certificate-for-code-integrity-policies.md). 
+If you plan to use an internal CA to sign catalog files or WDAC policies, see the steps in [Optional: Create a code signing certificate for Windows Defender Application Control](optional-create-a-code-signing-certificate-for-code-integrity-policies.md). 
 
-## Code integrity policy rules
+## Windows Defender Application Control policy rules
 
-Code integrity policies include *policy rules*, which control options such as audit mode or whether UMCI is enabled in a code integrity policy. You can modify these options in a new or existing code integrity policy. (For information about *file rules*, which specify the level at which applications will be identified and trusted, see the next section, [Code integrity file rule levels](#code-integrity-file-rule-levels).)
+WDAC policies include *policy rules*, which control options such as audit mode or whether UMCI is enabled in a WDAC policy. You can modify these options in a new or existing WDAC policy. (For information about *file rules*, which specify the level at which applications will be identified and trusted, see the next section, [Windows Defender Application Control file rule levels](#windows-defender-application-control-file-rule-levels).)
 
-To modify the policy rule options of an existing code integrity policy, use the [Set-RuleOption](https://technet.microsoft.com/library/mt634483.aspx) Windows PowerShell cmdlet. Note the following examples of how to use this cmdlet to add and remove a rule option on an existing code integrity policy:
+To modify the policy rule options of an existing WDAC policy, use the [Set-RuleOption](https://technet.microsoft.com/library/mt634483.aspx) Windows PowerShell cmdlet. Note the following examples of how to use this cmdlet to add and remove a rule option on an existing WDAC policy:
 
--   To ensure that UMCI is enabled for a code integrity policy that was created with the `-UserPEs` (user mode) option, add rule option 0 to an existing policy by running the following command:
+-   To ensure that UMCI is enabled for a WDAC policy that was created with the `-UserPEs` (user mode) option, add rule option 0 to an existing policy by running the following command:
 
     ` Set-RuleOption -FilePath <Path to policy> -Option 0`
 
-    Note that a policy that was created without the `-UserPEs` option is empty of user mode executables, that is, applications. If you enable UMCI (Option 0) for such a policy and then attempt to run an application, Windows Defender Device Guard will see that the application is not on its list (which is empty of applications), and respond. In audit mode, the response is logging an event, and in enforced mode, the response is blocking the application. To create a policy that includes user mode executables (applications), when you run `New-CIPolicy`, include the `-UserPEs` option. 
+    Note that a policy that was created without the `-UserPEs` option is empty of user mode executables, that is, applications. If you enable UMCI (Option 0) for such a policy and then attempt to run an application, Windows Defender Application Control will see that the application is not on its list (which is empty of applications), and respond. In audit mode, the response is logging an event, and in enforced mode, the response is blocking the application. To create a policy that includes user mode executables (applications), when you run `New-CIPolicy`, include the `-UserPEs` option. 
 
--   To disable UMCI on an existing code integrity policy, delete rule option 0 by running the following command:
+-   To disable UMCI on an existing WDAC policy, delete rule option 0 by running the following command:
 
     ` Set-RuleOption -FilePath <Path to policy> -Option 0 -Delete`
 
-You can set several rule options within a code integrity policy. To display a list of rule options, you can type **Set-
+You can set several rule options within a WDAC policy. To display a list of rule options, you can type **Set-
 RuleOption -Help** in a Windows PowerShell session. Table 2 describes each rule option. 
 
-> **Note**&nbsp;&nbsp;**Enabled:Audit Mode** is an important rule option. We recommend that you use this option for a period of time with all new code integrity policies, because it allows you to test them before you enforce them. With audit mode, no application is blocked—the policy just logs an event whenever an application outside the policy is started. To expand the policy so that (when enforced) it will allow these applications, you can use Windows PowerShell commands to capture the needed policy information from the event log, and then merge that information into the existing policy.
+> **Note**&nbsp;&nbsp;**Enabled:Audit Mode** is an important rule option. We recommend that you use this option for a period of time with all new WDAC policies, because it allows you to test them before you enforce them. With audit mode, no application is blocked—the policy just logs an event whenever an application outside the policy is started. To expand the policy so that (when enforced) it will allow these applications, you can use Windows PowerShell commands to capture the needed policy information from the event log, and then merge that information into the existing policy.
 
-> The mode—audit mode or enforced mode—is set by including or deleting **Enabled:Audit Mode** in the code integrity policy. When this option is deleted, the policy runs in enforced mode.
+> The mode—audit mode or enforced mode—is set by including or deleting **Enabled:Audit Mode** in the WDAC policy. When this option is deleted, the policy runs in enforced mode.
 
-**Table 2. Code integrity policy - policy rule options**
+**Table 2. Windows Defender Application Control policy - policy rule options**
 
 | Rule option | Description |
 |------------ | ----------- |
-| **0 Enabled:UMCI** | Code integrity policies restrict both kernel-mode and user-mode binaries. By default, only kernel-mode binaries are restricted. Enabling this rule option validates user mode executables and scripts. |
+| **0 Enabled:UMCI** | WDAC policies restrict both kernel-mode and user-mode binaries. By default, only kernel-mode binaries are restricted. Enabling this rule option validates user mode executables and scripts. |
 | **1 Enabled:Boot Menu Protection** | This option is not currently supported. |
 | **2 Required:WHQL** | By default, legacy drivers that are not Windows Hardware Quality Labs (WHQL) signed are allowed to execute. Enabling this rule requires that every executed driver is WHQL signed and removes legacy driver support. Going forward, every new Windows 10–compatible driver must be WHQL certified. |
-| **3 Enabled:Audit Mode (Default)** | Enables the execution of binaries outside of the code integrity policy but logs each occurrence in the CodeIntegrity event log, which can be used to update the existing policy before enforcement. To begin enforcing a code integrity policy, delete this option. |
+| **3 Enabled:Audit Mode (Default)** | Enables the execution of binaries outside of the WDAC policy but logs each occurrence in the CodeIntegrity event log, which can be used to update the existing policy before enforcement. To begin enforcing a WDAC policy, delete this option. |
-| **4 Disabled:Flight Signing** | If enabled, code integrity policies will not trust flightroot-signed binaries. This would be used in the scenario in which organizations only want to run released binaries, not flighted builds. |
+| **4 Disabled:Flight Signing** | If enabled, WDAC policies will not trust flightroot-signed binaries. This would be used in the scenario in which organizations only want to run released binaries, not flighted builds. |
 | **5 Enabled:Inherent Default Policy** | This option is not currently supported. |
 | **6 Enabled:Unsigned System Integrity Policy (Default)** | Allows the policy to remain unsigned. When this option is removed, the policy must be signed and have UpdatePolicySigners added to the policy to enable future policy modifications. |
 | **7 Allowed:Debug Policy Augmented** | This option is not currently supported. |
 | **8 Required:EV Signers** | In addition to being WHQL signed, this rule requires that drivers must have been submitted by a partner that has an Extended Verification (EV) certificate. All future Windows 10 and later drivers will meet this requirement. |
-| **9 Enabled:Advanced Boot Options Menu** | The F8 preboot menu is disabled by default for all code integrity policies. Setting this rule option allows the F8 menu to appear to physically present users. |
+| **9 Enabled:Advanced Boot Options Menu** | The F8 preboot menu is disabled by default for all WDAC policies. Setting this rule option allows the F8 menu to appear to physically present users. |
-| **10 Enabled:Boot Audit on Failure** | Used when the code integrity policy is in enforcement mode. When a driver fails during startup, the code integrity policy will be placed in audit mode so that Windows will load. Administrators can validate the reason for the failure in the CodeIntegrity event log. |
+| **10 Enabled:Boot Audit on Failure** | Used when the WDAC policy is in enforcement mode. When a driver fails during startup, the WDAC policy will be placed in audit mode so that Windows will load. Administrators can validate the reason for the failure in the CodeIntegrity event log. |
 
-## Code integrity file rule levels
+## Windows Defender Application Control file rule levels
 
-File rule levels allow administrators to specify the level at which they want to trust their applications. This level of trust could be as fine-tuned as the hash of each binary or as general as a CA certificate. You specify file rule levels both when you create a new code integrity policy from a scan and when you create a policy from audit events. In addition, to combine rule levels found in multiple policies, you can merge the policies. When merged, code integrity policies combine their file rules, so that any application that would be allowed by either of the original policies will be allowed by the combined policy. 
+File rule levels allow administrators to specify the level at which they want to trust their applications. This level of trust could be as fine-tuned as the hash of each binary or as general as a CA certificate. You specify file rule levels both when you create a new WDAC policy from a scan and when you create a policy from audit events. In addition, to combine rule levels found in multiple policies, you can merge the policies. When merged, WDAC policies combine their file rules, so that any application that would be allowed by either of the original policies will be allowed by the combined policy. 
 
-Each file rule level has its benefit and disadvantage. Use Table 3 to select the appropriate protection level for your available administrative resources and Windows Defender Device Guard deployment scenario.
+Each file rule level has its benefit and disadvantage. Use Table 3 to select the appropriate protection level for your available administrative resources and Windows Defender Application Control deployment scenario.
 
-Table 3. Code integrity policy - file rule levels
+Table 3. Windows Defender Application Control policy - file rule levels
 
 | Rule level | Description |
 |----------- | ----------- |
@@ -92,27 +92,27 @@ Table 3. Code integrity policy - file rule levels
 | **SignedVersion** | This combines the publisher rule with a version number. This option allows anything from the specified publisher, with a version at or above the specified version number, to run. |
 | **Publisher** | This is a combination of the PcaCertificate level (typically one certificate below the root) and the common name (CN) of the leaf certificate. This rule level allows organizations to trust a certificate from a major CA (such as Symantec), but only if the leaf certificate is from a specific company (such as Intel, for device drivers). |
 | **FilePublisher** | This is a combination of the “FileName” attribute of the signed file, plus “Publisher” (PCA certificate with CN of leaf), plus a minimum version number. This option trusts specific files from the specified publisher, with a version at or above the specified version number. |
-| **LeafCertificate** | Adds trusted signers at the individual signing certificate level. The benefit of using this level versus the individual hash level is that new versions of the product will have different hash values but typically the same signing certificate. Using this level, no policy update would be needed to run the new version of the application. However, leaf certificates have much shorter validity periods than CA certificates, so additional administrative overhead is associated with updating the code integrity policy when these certificates expire. |
+| **LeafCertificate** | Adds trusted signers at the individual signing certificate level. The benefit of using this level versus the individual hash level is that new versions of the product will have different hash values but typically the same signing certificate. Using this level, no policy update would be needed to run the new version of the application. However, leaf certificates have much shorter validity periods than CA certificates, so additional administrative overhead is associated with updating the WDAC policy when these certificates expire. |
 | **PcaCertificate** | Adds the highest available certificate in the provided certificate chain to signers. This is typically one certificate below the root certificate, because the scan does not validate anything beyond the certificates included in the provided signature (it does not go online or check local root stores). |
 | **RootCertificate** | Currently unsupported. |
 | **WHQL** | Trusts binaries if they have been validated and signed by WHQL. This is primarily for kernel binaries. |
 | **WHQLPublisher** | This is a combination of the WHQL and the CN on the leaf certificate and is primarily for kernel binaries. |
 | **WHQLFilePublisher** | Specifies that the binaries are validated and signed by WHQL, with a specific publisher (WHQLPublisher), and that the binary is the specified version or newer. This is primarily for kernel binaries. |
 
-> **Note**&nbsp;&nbsp;When you create code integrity policies with the [New-CIPolicy](https://technet.microsoft.com/library/mt634473.aspx) cmdlet, you can specify a primary file rule level by including the **-Level** parameter. For discovered binaries that cannot be trusted based on the primary file rule criteria, use the **-Fallback** parameter. For example, if the primary file rule level is PCACertificate but you would like to trust the unsigned applications as well, using the Hash rule level as a fallback adds the hash values of binaries that did not have a signing certificate.
+> **Note**&nbsp;&nbsp;When you create WDAC policies with the [New-CIPolicy](https://technet.microsoft.com/library/mt634473.aspx) cmdlet, you can specify a primary file rule level by including the **-Level** parameter. For discovered binaries that cannot be trusted based on the primary file rule criteria, use the **-Fallback** parameter. For example, if the primary file rule level is PCACertificate but you would like to trust the unsigned applications as well, using the Hash rule level as a fallback adds the hash values of binaries that did not have a signing certificate.
 
 ## Example of file rule levels in use
 
 For example, consider some IT professionals in a department that runs many servers. They decide they want their servers to run only software signed by the providers of their software and drivers, that is, the companies that provide their hardware, operating system, antivirus, and other important software. They know that their servers also run an internally written application that is unsigned but is rarely updated. They want to allow this application to run.
 
-To create the code integrity policy, they build a reference server on their standard hardware, and install all of the software that their servers are known to run. Then they run [New-CIPolicy](https://technet.microsoft.com/library/mt634473.aspx) with **-Level Publisher** (to allow software from their software providers, the "Publishers") and **-Fallback Hash** (to allow the internal, unsigned application). They enable the policy in auditing mode and gather information about any necessary software that was not included on the reference server. They merge code integrity policies into the original policy to allow that additional software to run. Then they enable the code integrity policy in enforced mode for their servers.
+To create the WDAC policy, they build a reference server on their standard hardware, and install all of the software that their servers are known to run. Then they run [New-CIPolicy](https://technet.microsoft.com/library/mt634473.aspx) with **-Level Publisher** (to allow software from their software providers, the "Publishers") and **-Fallback Hash** (to allow the internal, unsigned application). They enable the policy in auditing mode and gather information about any necessary software that was not included on the reference server. They merge WDAC policies into the original policy to allow that additional software to run. Then they enable the WDAC policy in enforced mode for their servers.
 
-As part of normal operations, they will eventually install software updates, or perhaps add software from the same software providers. Because the "Publisher" remains the same on those updates and software, they will not need to update their code integrity policy. If they come to a time when the internally-written, unsigned application must be updated, they must also update the code integrity policy so that the hash in the policy matches the hash of the updated internal application.
+As part of normal operations, they will eventually install software updates, or perhaps add software from the same software providers. Because the "Publisher" remains the same on those updates and software, they will not need to update their WDAC policy. If they come to a time when the internally-written, unsigned application must be updated, they must also update the WDAC policy so that the hash in the policy matches the hash of the updated internal application.
 
-They could also choose to create a catalog that captures information about the unsigned internal application, then sign and distribute the catalog. Then the internal application could be handled by code integrity policies in the same way as any other signed application. An update to the internal application would only require that the catalog be regenerated, signed, and distributed (no restarts would be required).
+They could also choose to create a catalog that captures information about the unsigned internal application, then sign and distribute the catalog. Then the internal application could be handled by WDAC policies in the same way as any other signed application. An update to the internal application would only require that the catalog be regenerated, signed, and distributed (no restarts would be required).
 
 
 ## 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-windows-defender-device-guard-features-help-protect-against-threats)
-- [Deploy code integrity policies: steps](deploy-code-integrity-policies-steps.md)
+- [Deploy Windows Defender Application Control: steps](deploy-code-integrity-policies-steps.md)

windows/device-security/device-guard/deploy-code-integrity-policies-steps.md

@@ -9,23 +9,23 @@ author: brianlic-msft
 ms.date: 11/02/2017
 ---
 
-# Deploy code integrity policies: steps
+# Deploy Windows Defender Application Control: steps
 
 **Applies to**
 -   Windows 10
 -   Windows Server 2016
 
-For an overview of the process described in the following procedures, see [Deploy code integrity policies: policy rules and file rules](deploy-code-integrity-policies-policy-rules-and-file-rules.md). To understand how the deployment of code integrity policies fits with other steps in the Windows Defender Device Guard deployment process, see [Planning and getting started on the Windows Defender Device Guard deployment process](planning-and-getting-started-on-the-device-guard-deployment-process.md).
+For an overview of the process described in the following procedures, see [Deploy Windows Defender Application Control: policy rules and file rules](deploy-code-integrity-policies-policy-rules-and-file-rules.md). To understand how the deployment of Windows Defender Application Control (WDAC) fits with other steps in the Windows Defender Device Guard deployment process, see [Planning and getting started on the Windows Defender Device Guard deployment process](planning-and-getting-started-on-the-device-guard-deployment-process.md).
 
-## Create a code integrity policy from a reference computer
+## Create a Windows Defender Application Control policy from a reference computer
 
-This section outlines the process to create a code integrity policy with Windows PowerShell. 
+This section outlines the process to create a WDAC policy with Windows PowerShell. 
 For this example, you must initiate variables to be used during the creation process or use the full file paths in the command. 
-Then create the code integrity policy by scanning the system for installed applications. 
+Then create the WDAC policy by scanning the system for installed applications. 
 The policy file is converted to binary format when it gets created so that Windows can interpret it.
 
 > [!Note] 
-> Make sure the reference computer is virus and malware-free, and install any software you want to be scanned before creating the code integrity policy. 
+> Make sure the reference computer is virus and malware-free, and install any software you want to be scanned before creating the WDAC policy. 
 
 ### Scripting and applications
 
@@ -33,11 +33,11 @@ Each installed software application should be validated as trustworthy before yo
 We recommend that you review the reference computer for software that can load arbitrary DLLs and run code or scripts that could render the PC more vulnerable. 
 Examples include software aimed at development or scripting such as msbuild.exe (part of Visual Studio and the .NET Framework) which can be removed if you do not want it to run scripts. 
 You can remove or disable such software on the reference computer. 
-You can also fine-tune your control by [using Windows Defender Device Guard in combination with AppLocker](https://technet.microsoft.com/itpro/windows/keep-secure/introduction-to-device-guard-virtualization-based-security-and-code-integrity-policies#device-guard-with-applocker). 
+You can also fine-tune your control by [using Windows Defender Application Control in combination with AppLocker](introduction-to-device-guard-virtualization-based-security-and-code-integrity-policies.md#windows-defender-device-guard-with-applocker). 
 
-Members of the security community<sup>\*</sup> continuously collaborate with Microsoft to help protect customers. With the help of their valuable reports, Microsoft has identified a list of valid applications that an attacker could also potentially use to bypass Windows Defender Device Guard code integrity policies. 
+Members of the security community<sup>\*</sup> continuously collaborate with Microsoft to help protect customers. With the help of their valuable reports, Microsoft has identified a list of valid applications that an attacker could also potentially use to bypass Windows Defender Application Control. 
 
-Unless your use scenarios explicitly require them, Microsoft recommends that you block the following applications. These applications or files can be used by an attacker to circumvent Application Whitelisting policies, including Windows Defender Device Guard:
+Unless your use scenarios explicitly require them, Microsoft recommends that you block the following applications. These applications or files can be used by an attacker to circumvent application whitelisting policies, including Windows Defender Application Control:
 
 - addinprocess.exe
 - addinprocess32.exe
@@ -84,11 +84,11 @@ Unless your use scenarios explicitly require them, Microsoft recommends that you
 >This application list will be updated with the latest vendor information as application vulnerabilities are resolved and new issues are discovered. 
 
 Certain software applications may allow additional code to run by design. 
-These types of applications should be blocked by your Windows Defender Device Guard policy. 
+These types of applications should be blocked by your Windows Defender Application Control policy. 
-In addition, when an application version is upgraded to fix a security vulnerability or potential Windows Defender Device Guard bypass, you should add deny rules to your code integrity policies for that application’s previous, less secure versions. 
+In addition, when an application version is upgraded to fix a security vulnerability or potential Windows Defender Application Control bypass, you should add deny rules to your WDAC policies for that application’s previous, less secure versions. 
 
 Microsoft recommends that you install the latest security updates. 
-The June 2017 Windows updates resolve several issues in PowerShell modules that allowed an attacker to bypass Windows Defender Device Guard code integrity policies. 
+The June 2017 Windows updates resolve several issues in PowerShell modules that allowed an attacker to bypass Windows Defender Application Control. 
 These modules cannot be blocked by name or version, and therefore must be blocked by their corresponding hashes. 
 
 For October 2017, we are announcing an update to system.management.automation.dll in which we are revoking older versions by hash values, instead of version rules.
@@ -690,7 +690,7 @@ Microsoft recommends that you block the following Microsoft-signed applications
 ```
 <br />
 
-To create a code integrity policy, copy each of the following commands into an elevated Windows PowerShell session, in order:
+To create a WDAC policy, copy each of the following commands into an elevated Windows PowerShell session, in order:
 
 1.  Initialize variables that you will use. The following example commands use **InitialScan.xml** and **DeviceGuardPolicy.bin** for the names of the files that will be created:
 
@@ -700,89 +700,89 @@ To create a code integrity policy, copy each of the following commands into an e
 
     ` $CIPolicyBin=$CIPolicyPath+"DeviceGuardPolicy.bin"`
 
-2.  Use [New-CIPolicy](https://technet.microsoft.com/library/mt634473.aspx) to create a new code integrity policy by scanning the system for installed applications:
+2.  Use [New-CIPolicy](https://technet.microsoft.com/library/mt634473.aspx) to create a new WDAC policy by scanning the system for installed applications:
 
     ` New-CIPolicy -Level PcaCertificate -FilePath $InitialCIPolicy –UserPEs 3> CIPolicyLog.txt `
 
     > [!Note] 
     
-    > - When you specify the **-UserPEs** parameter (to include user mode executables in the scan), rule option **0 Enabled:UMCI** is automatically added to the code integrity policy. In contrast, if you do not specify **-UserPEs**, the policy will be empty of user mode executables and will only have rules for kernel mode binaries like drivers, in other words, the whitelist will not include applications. If you create such a policy and later add rule option **0 Enabled:UMCI**, all attempts to start applications will cause a response from Windows Defender Device Guard. In audit mode, the response is logging an event, and in enforced mode, the response is blocking the application. 
+    > - When you specify the **-UserPEs** parameter (to include user mode executables in the scan), rule option **0 Enabled:UMCI** is automatically added to the WDAC policy. In contrast, if you do not specify **-UserPEs**, the policy will be empty of user mode executables and will only have rules for kernel mode binaries like drivers, in other words, the whitelist will not include applications. If you create such a policy and later add rule option **0 Enabled:UMCI**, all attempts to start applications will cause a response from Windows Defender Application Control. In audit mode, the response is logging an event, and in enforced mode, the response is blocking the application. 
     
-    > - You can add the **-Fallback** parameter to catch any applications not discovered using the primary file rule level specified by the **-Level** parameter. For more information about file rule level options, see [Code integrity file rule levels](deploy-code-integrity-policies-policy-rules-and-file-rules.md#code-integrity-file-rule-levels) in “Deploy code integrity policies: policy rules and file rules.”
+    > - You can add the **-Fallback** parameter to catch any applications not discovered using the primary file rule level specified by the **-Level** parameter. For more information about file rule level options, see [Windows Defender Application Control file rule levels](deploy-code-integrity-policies-policy-rules-and-file-rules.md#windows-defender-application-control-file-rule-levels) in “Deploy Windows Defender Application Control: policy rules and file rules.”
 
-    > - To specify that the code integrity policy scan only a specific drive, include the **-ScanPath** parameter followed by a path. Without this parameter, the entire system is scanned.
+    > - To specify that the WDAC policy scan only a specific drive, include the **-ScanPath** parameter followed by a path. Without this parameter, the entire system is scanned.
     
     > - The preceding example includes `3> CIPolicylog.txt`, which redirects warning messages to a text file, **CIPolicylog.txt**.
 
-3.  Use [ConvertFrom-CIPolicy](https://technet.microsoft.com/library/mt733073.aspx) to convert the code integrity policy to a binary format:
+3.  Use [ConvertFrom-CIPolicy](https://technet.microsoft.com/library/mt733073.aspx) to convert the WDAC policy to a binary format:
 
     ` ConvertFrom-CIPolicy $InitialCIPolicy $CIPolicyBin`
 
-After you complete these steps, the Windows Defender Device Guard binary file (DeviceGuardPolicy.bin) and original .xml file (IntialScan.xml) will be available on your desktop. You can use the binary version as a code integrity policy or sign it for additional security.
+After you complete these steps, the WDAC binary file (DeviceGuardPolicy.bin) and original .xml file (IntialScan.xml) will be available on your desktop. You can use the binary file as a WDAC policy or sign it for additional security.
 
 > [!Note] 
-> We recommend that you keep the original .xml file of the policy for use when you need to merge the code integrity policy with another policy or update its rule options. Alternatively, you would have to create a new policy from a new scan for servicing. For more information about how to merge code integrity policies, see [Merge code integrity policies](#merge-code-integrity-policies).
+> We recommend that you keep the original .xml file of the policy for use when you need to merge the WDAC policy with another policy or update its rule options. Alternatively, you would have to create a new policy from a new scan for servicing. For more information about how to merge WDAC policies, see [Merge Windows Defender Application Control policies](#merge-windows-defender-application-control-policies).
 
-We recommend that every code integrity policy be run in audit mode before being enforced. Doing so allows administrators to discover any issues with the policy without receiving error message dialog boxes. For information about how to audit a code integrity policy, see the next section, [Audit code integrity policies](#audit-code-integrity-policies).
+We recommend that every WDAC policy be run in audit mode before being enforced. Doing so allows administrators to discover any issues with the policy without receiving error message dialog boxes. For information about how to audit a WDAC policy, see the next section, [Audit Windows Defender Application Control policies](#audit-windows-defender-application-control-policies).
 
-## Audit code integrity policies
+## Audit Windows Defender Application Control policies
 
-When code integrity policies are run in audit mode, it allows administrators to discover any applications that were missed during an initial policy scan and to identify any new applications that have been installed and run since the original policy was created. While a code integrity policy is running in audit mode, any binary that runs and would have been denied had the policy been enforced is logged in the **Applications and Services Logs\\Microsoft\\Windows\\CodeIntegrity\\Operational** event log. When these logged binaries have been validated, they can easily be added to a new code integrity policy. When the new exception policy is created, you can merge it with your existing code integrity policies.
+When WDAC policies are run in audit mode, it allows administrators to discover any applications that were missed during an initial policy scan and to identify any new applications that have been installed and run since the original policy was created. While a WDAC policy is running in audit mode, any binary that runs and would have been denied had the policy been enforced is logged in the **Applications and Services Logs\\Microsoft\\Windows\\CodeIntegrity\\Operational** event log. When these logged binaries have been validated, they can easily be added to a new WDAC policy. When the new exception policy is created, you can merge it with your existing WDAC policies.
 
 > [!Note] 
-> Before you begin this process, you need to create a code integrity policy binary file. If you have not already done so, see [Create a code integrity policy from a reference computer](#create-a-code-integrity-policy-from-a-reference-computer), earlier in this topic, for a step-by-step walkthrough of the process to create a code integrity policy and convert it to binary format.
+> Before you begin this process, you need to create a WDAC policy binary file. If you have not already done so, see [Create a Windows Defender Application Control policy from a reference computer](#create-a-windows-defender-application-control-policy-from-a-reference-computer), earlier in this topic, for a step-by-step walkthrough of the process to create a WDAC policy and convert it to binary format.
 
-**To audit a code integrity policy with local policy:**
+**To audit a Windows Defender Application Control policy with local policy:**
 
-1.  Find a *.bin policy file that you have created, for example, the DeviceGuardPolicy.bin file that resulted from the steps in the earlier section, [Create a code integrity policy from a reference computer](#create-a-code-integrity-policy-from-a-reference-computer). Copy the file to C:\\Windows\\System32\\CodeIntegrity.
+1.  Find a *.bin policy file that you have created, for example, the DeviceGuardPolicy.bin file that resulted from the steps in the earlier section, [Create a Windows Defender Application Control policy from a reference computer](#create-a-windows-defender-application-control-policy-from-a-reference-computer). Copy the file to C:\\Windows\\System32\\CodeIntegrity.
 
 2.  On the computer you want to run in audit mode, open the Local Group Policy Editor by running **GPEdit.msc**.
 
     > [!Note]
     
-    > - The computer that you will run in audit mode must be clean of viruses or malware. Otherwise, in the process that you follow after auditing the system, you might unintentionally merge in a code integrity policy that allows viruses or malware to run.
+    > - The computer that you will run in audit mode must be clean of viruses or malware. Otherwise, in the process that you follow after auditing the system, you might unintentionally merge in a policy that allows viruses or malware to run.
     
     > - An alternative method to test a policy is to rename the test file to SIPolicy.p7b and drop it into C:\\Windows\\System32\\CodeIntegrity, rather than deploy it by using the Local Group Policy Editor.
     
-3.  Navigate to **Computer Configuration\\Administrative Templates\\System\\Windows Defender Device Guard**, and then select **Deploy Code Integrity Policy**. Enable this setting by using the appropriate file path, for example, C:\\Windows\\System32\\CodeIntegrity\\DeviceGuardPolicy.bin, as shown in Figure 1.
+3.  Navigate to **Computer Configuration\\Administrative Templates\\System\\Windows Defender Device Guard**, and then select **Deploy Windows Defender Application Control**. Enable this setting by using the appropriate file path, for example, C:\\Windows\\System32\\CodeIntegrity\\DeviceGuardPolicy.bin, as shown in Figure 1.
 
     > [!Note]
     
-    > - The illustration shows the example file name *DeviceGuardPolicy.bin* because this name was used earlier in this topic, in [Create a code integrity policy from a reference computer](#create-a-code-integrity-policy-from-a-reference-computer). Also, this policy file does not need to be copied to every system. You can instead copy the code integrity policies to a file share to which all computer accounts have access.
+    > - The illustration shows the example file name *DeviceGuardPolicy.bin* because this name was used earlier in this topic, in [Create a Windows Defender Application Control policy from a reference computer](#create-a-windows-defender-application-control-policy-from-a-reference-computer). Also, this policy file does not need to be copied to every system. You can instead copy the WDAC policies to a file share to which all computer accounts have access.
 
     > - Any policy you select here is converted to SIPolicy.p7b when it is deployed to the individual computers.
 
-    > - You might have noticed that the GPO setting references a .p7b file and this policy uses a .bin file. Regardless of the type of policy you deploy (.bin, .p7b, or .p7), they are all converted to SIPolicy.p7b when dropped onto the computers running Windows 10. We recommend that you make your code integrity policy names friendly and allow the system to convert the policy names for you. By doing this, it ensures that the policies are easily distinguishable when viewed in a share or any other central repository.
+    > - You might have noticed that the GPO setting references a .p7b file and this policy uses a .bin file. Regardless of the type of policy you deploy (.bin, .p7b, or .p7), they are all converted to SIPolicy.p7b when dropped onto the computers running Windows 10. We recommend that you make your WDAC policy names friendly and allow the system to convert the policy names for you. By doing this, it ensures that the policies are easily distinguishable when viewed in a share or any other central repository.
 
-   ![Group Policy called Deploy Code Integrity Policy](images/dg-fig22-deploycode.png)
+   ![Group Policy called Deploy Windows Defender Application Control](images/dg-fig22-deploycode.png)
 
-   Figure 1. Deploy your code integrity policy
+   Figure 1. Deploy your Windows Defender Application Control policy
 
-4.  Restart the reference system for the code integrity policy to take effect.
+4.  Restart the reference system for the WDAC policy to take effect.
 
-5.  Use the system as you normally would, and monitor code integrity events in the event log. While in audit mode, any exception to the deployed code integrity policy will be logged in the **Applications and Services Logs\\Microsoft\\Windows\\CodeIntegrity\\Operational** event log, as shown in Figure 2.
+5.  Use the system as you normally would, and monitor code integrity events in the event log. While in audit mode, any exception to the deployed WDAC policy will be logged in the **Applications and Services Logs\\Microsoft\\Windows\\CodeIntegrity\\Operational** event log, as shown in Figure 2.
 
-   ![Event showing exception to code integrity policy](images/dg-fig23-exceptionstocode.png)
+   ![Event showing exception to WDAC policy](images/dg-fig23-exceptionstocode.png)
 
-   Figure 2. Exceptions to the deployed code integrity policy
+   Figure 2. Exceptions to the deployed WDAC policy
 
    You will be reviewing the exceptions that appear in the event log, and making a list of any applications that should be allowed to run in your environment.
    
-6. If you want to create a catalog file to simplify the process of including unsigned LOB applications in your code integrity policy, this is a good time to create it. For information, see [Deploy catalog files to support code integrity policies](deploy-catalog-files-to-support-code-integrity-policies.md).   
+6. If you want to create a catalog file to simplify the process of including unsigned LOB applications in your WDAC policy, this is a good time to create it. For information, see [Deploy catalog files to support Windows Defender Application Control](deploy-catalog-files-to-support-code-integrity-policies.md).   
 
-Now that you have a code integrity policy deployed in audit mode, you can capture any audit information that appears in the event log. This is described in the next section.
+Now that you have a WDAC policy deployed in audit mode, you can capture any audit information that appears in the event log. This is described in the next section.
 
-## Create a code integrity policy that captures audit information from the event log
+## Create a Windows Defender Application Control policy that captures audit information from the event log
 
-Use the following procedure after you have been running a computer with a code integrity policy in audit mode for a period of time. When you are ready to capture the needed policy information from the event log (so that you can later merge that information into the original code integrity policy), complete the following steps. 
+Use the following procedure after you have been running a computer with a WDAC policy in audit mode for a period of time. When you are ready to capture the needed policy information from the event log (so that you can later merge that information into the original WDAC policy), complete the following steps. 
 
 <!-- Watch the phrase "later step in this procedure" in step 1, in case the organization of the procedures changes. -->
 
-1.  Review the audit information in the event log. From the code integrity policy exceptions that you see, make a list of any applications that should be allowed to run in your environment, and decide on the file rule level that should be used to trust these applications.
+1.  Review the audit information in the event log. From the WDAC policy exceptions that you see, make a list of any applications that should be allowed to run in your environment, and decide on the file rule level that should be used to trust these applications.
 
-    Although the Hash file rule level will catch all of these exceptions, it may not be the best way to trust all of them. For information about file rule levels, see [Code integrity file rule levels](deploy-code-integrity-policies-policy-rules-and-file-rules.md#code-integrity-file-rule-levels) in "Deploy code integrity policies: policy rules and file rules."
+    Although the Hash file rule level will catch all of these exceptions, it may not be the best way to trust all of them. For information about file rule levels, see [Windows Defender Application Control file rule levels](deploy-code-integrity-policies-policy-rules-and-file-rules.md#windows-defender-application-control-file-rule-levels) in "Deploy Windows Defender Application Control: policy rules and file rules."
     
-    Your event log might also contain exceptions for applications that you eventually want your code integrity policy to block. If these appear, make a list of these also, for a later step in this procedure.
+    Your event log might also contain exceptions for applications that you eventually want your WDAC policy to block. If these appear, make a list of these also, for a later step in this procedure.
 
 2.  In an elevated Windows PowerShell session, initialize the variables that will be used. The example filename shown here is **DeviceGuardAuditPolicy.xml**:
 
@@ -790,27 +790,27 @@ Use the following procedure after you have been running a computer with a code i
 
     ` $CIAuditPolicy=$CIPolicyPath+"DeviceGuardAuditPolicy.xml"`
 
-3.  Use [New-CIPolicy](https://technet.microsoft.com/library/mt634473.aspx) to generate a new code integrity policy from logged audit events. This example uses a file rule level of **Hash** and includes `3> CIPolicylog.txt`, which redirects warning messages to a text file, **CIPolicylog.txt**.
+3.  Use [New-CIPolicy](https://technet.microsoft.com/library/mt634473.aspx) to generate a new WDAC policy from logged audit events. This example uses a file rule level of **Hash** and includes `3> CIPolicylog.txt`, which redirects warning messages to a text file, **CIPolicylog.txt**.
 
     ` New-CIPolicy -Audit -Level Hash -FilePath $CIAuditPolicy –UserPEs 3> CIPolicylog.txt`
 
   > [!Note] 
   > When you create policies from audit events, you should carefully consider the file rule level that you select to trust. The preceding example uses the **Hash** rule level, which is the most specific. Any change to the file (such as replacing the file with a newer version of the same file) will change the Hash value, and require an update to the policy.
 
-4.  Find and review the Windows Defender Device Guard audit policy .xml file that you created. If you used the example variables as shown, the filename will be **DeviceGuardAuditPolicy.xml**, and it will be on your desktop. Look for the following:
+4.  Find and review the WDAC audit policy .xml file that you created. If you used the example variables as shown, the filename will be **DeviceGuardAuditPolicy.xml**, and it will be on your desktop. Look for the following:
 
     - Any applications that were caught as exceptions, but should be allowed to run in your environment. These are applications that should be in the .xml file. Leave these as-is in the file.
     
-    - Any applications that actually should not be allowed to run in your environment. Edit these out of the .xml file. If they remain in the .xml file, and the information in the file is merged into your existing code integrity policy, the policy will treat the applications as trusted, and allow them to run. 
+    - Any applications that actually should not be allowed to run in your environment. Edit these out of the .xml file. If they remain in the .xml file, and the information in the file is merged into your existing WDAC policy, the policy will treat the applications as trusted, and allow them to run. 
 
-You can now use this file to update the existing code integrity policy that you ran in audit mode by merging the two policies. For instructions on how to merge this audit policy with the existing code integrity policy, see the next section, [Merge code integrity policies](#merge-code-integrity-policies).
+You can now use this file to update the existing WDAC policy that you ran in audit mode by merging the two policies. For instructions on how to merge this audit policy with the existing WDAC policy, see the next section, [Merge Windows Defender Application Control policies](#merge-windows-defender-application-control-policies).
 
 > [!Note] 
-> You may have noticed that you did not generate a binary version of this policy as you did in [Create a code integrity policy from a reference computer](#create-a-code-integrity-policy-from-a-reference-computer). This is because code integrity policies created from an audit log are not intended to run as stand-alone policies but rather to update existing code integrity policies.
+> You may have noticed that you did not generate a binary version of this policy as you did in [Create a Windows Defender Application Control policy from a reference computer](#create-a-windows-defender-application-control-policy-from-a-reference-computer). This is because WDAC policies created from an audit log are not intended to run as stand-alone policies but rather to update existing WDAC policies.
 
-## <a href="" id="plug-ins"></a>Use a code integrity policy to control specific plug-ins, add-ins, and modules
+## <a href="" id="plug-ins"></a>Use a Windows Defender Application Control policy to control specific plug-ins, add-ins, and modules
 
-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):
+As of Windows 10, version 1703, you can use WDAC 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):
 
 | Approach (as of Windows 10, version 1703) | Guideline |
 |---|---|
@@ -819,7 +819,7 @@ As of Windows 10, version 1703, you can use code integrity policies not only to
 
 To work with these options, the typical method is to create a policy that only affects plug-ins, add-ins, and modules, then merge it into your ‘master’ policy (merging is described in the next section).
 
-For example, to create a code integrity policy that allows **addin1.dll** and **addin2.dll** to run in **ERP1.exe**, your organization’s enterprise resource planning (ERP) application, but blocks those add-ins in other applications, run the following commands. Note that in the second command, **+=** is used to add a second rule to the **$rule** variable:
+For example, to create a WDAC policy that allows **addin1.dll** and **addin2.dll** to run in **ERP1.exe**, your organization’s enterprise resource planning (ERP) application, but blocks those add-ins in other applications, run the following commands. Note that in the second command, **+=** is used to add a second rule to the **$rule** variable:
 
 ```
 $rule = New-CIPolicyRule -DriverFilePath '.\temp\addin1.dll' -Level FileName -AppID '.\ERP1.exe'
@@ -827,21 +827,21 @@ $rule += New-CIPolicyRule -DriverFilePath '.\temp\addin2.dll' -Level FileName -A
 New-CIPolicy -Rules $rule -FilePath ".\AllowERPAddins.xml" -UserPEs
 ```
 
-As another example, to create a code integrity policy that blocks **addin3.dll** from running in Microsoft Word, run the following command. You must include the `-Deny` option to block the specified add-ins in the specifed application:
+As another example, to create a WDAC policy that blocks **addin3.dll** from running in Microsoft Word, run the following command. You must include the `-Deny` option to block the specified add-ins in the specifed application:
 
 ```
 $rule = New-CIPolicyRule -DriverFilePath '.\temp\addin3.dll' -Level FileName -Deny -AppID '.\winword.exe'
 New-CIPolicy -Rules $rule -FilePath ".\BlockAddins.xml" -UserPEs
 ```
 
-## Merge code integrity policies
+## Merge Windows Defender Application Control policies
 
-When you develop code integrity policies, you will occasionally need to merge two policies. A common example is when a code integrity policy is initially created and audited. Another example is when you create a single master policy by using multiple code integrity policies previously created from reference computers. Because each computer running Windows 10 can have only one code integrity policy, it is important to properly maintain these policies. In this example, audit events have been saved into a secondary code integrity policy that you then merge with the initial code integrity policy.
+When you develop WDAC policies, you will occasionally need to merge two policies. A common example is when a WDAC policy is initially created and audited. Another example is when you create a single master policy by using multiple policies previously created from reference computers. Because each computer running Windows 10 can have only one WDAC policy, it is important to properly maintain these policies. In this example, audit events have been saved into a secondary WDAC policy that you then merge with the initial WDAC policy.
 
 > [!Note] 
-> The following example uses several of the code integrity policy .xml files that you created in earlier sections in this topic. You can follow this process, however, with any two code integrity policies you would like to combine.
+> The following example uses several of the WDAC policy .xml files that you created in earlier sections in this topic. You can follow this process, however, with any two WDAC policies you would like to combine.
 
-To merge two code integrity policies, complete the following steps in an elevated Windows PowerShell session:
+To merge two WDAC policies, complete the following steps in an elevated Windows PowerShell session:
 
 1.  Initialize the variables that will be used:
 
@@ -856,24 +856,24 @@ To merge two code integrity policies, complete the following steps in an elevate
     ` $CIPolicyBin=$CIPolicyPath+"NewDeviceGuardPolicy.bin"`
 
   > [!Note] 
-  > The variables in this section specifically expect to find an initial policy on your desktop called **InitialScan.xml** and an audit code integrity policy called **DeviceGuardAuditPolicy.xml**. If you want to merge other code integrity policies, update the variables accordingly.
+  > The variables in this section specifically expect to find an initial policy on your desktop called **InitialScan.xml** and an audit WDAC policy called **DeviceGuardAuditPolicy.xml**. If you want to merge other WDAC policies, update the variables accordingly.
 
-2.  Use [Merge-CIPolicy](https://technet.microsoft.com/library/mt634485.aspx) to merge two policies and create a new code integrity policy:
+2.  Use [Merge-CIPolicy](https://technet.microsoft.com/library/mt634485.aspx) to merge two policies and create a new WDAC policy:
 
     ` Merge-CIPolicy -PolicyPaths $InitialCIPolicy,$AuditCIPolicy -OutputFilePath $MergedCIPolicy`
 
-3.  Use [ConvertFrom-CIPolicy](https://technet.microsoft.com/library/mt733073.aspx) to convert the merged code integrity policy to binary format:
+3.  Use [ConvertFrom-CIPolicy](https://technet.microsoft.com/library/mt733073.aspx) to convert the merged WDAC policy to binary format:
 
     ` ConvertFrom-CIPolicy $MergedCIPolicy $CIPolicyBin `
 
-Now that you have created a new code integrity policy (for example, called **NewDeviceGuardPolicy.bin**), you can deploy the policy to systems manually or by using Group Policy or Microsoft client management solutions. For information about how to deploy this new policy with Group Policy, see the [Deploy and manage code integrity policies with Group Policy](#deploy-and-manage-code-integrity-policies-with-group-policy) section.
+Now that you have created a new WDAC policy (for example, called **NewDeviceGuardPolicy.bin**), you can deploy the policy binary to systems manually or by using Group Policy or Microsoft client management solutions. For information about how to deploy this new policy with Group Policy, see the [Deploy and manage Windows Defender Application Control with Group Policy](#deploy-and-manage-windows-defender-application-control-with-group-policy) section.
 
-## Enforce code integrity policies
+## Enforce Windows Defender Application Control policies
 
-Every code integrity policy is created with audit mode enabled. After you have successfully deployed and tested a code integrity policy in audit mode and are ready to test the policy in enforced mode, complete the following steps in an elevated Windows PowerShell session:
+Every WDAC policy is created with audit mode enabled. After you have successfully deployed and tested a WDAC policy in audit mode and are ready to test the policy in enforced mode, complete the following steps in an elevated Windows PowerShell session:
 
 > [!Note] 
-> Every code integrity policy should be tested in audit mode first. For information about how to audit code integrity policies, see [Audit code integrity policies](#audit-code-integrity-policies), earlier in this topic.
+> Every WDAC policy should be tested in audit mode first. For information about how to audit WDAC policies, see [Audit Windows Defender Application Control policies](#audit-windows-defender-application-control-policies), earlier in this topic.
 
 1.  Initialize the variables that will be used:
 
@@ -886,9 +886,9 @@ Every code integrity policy is created with audit mode enabled. After you have s
     ` $CIPolicyBin=$CIPolicyPath+"EnforcedDeviceGuardPolicy.bin"`
 
     > [!Note] 
-    > The initial code integrity policy that this section refers to was created in the [Create a code integrity policy from a reference computer](#create-a-code-integrity-policy-from-a-reference-computer) section. If you are using a different code integrity policy, update the **CIPolicyPath** and **InitialCIPolicy** variables.
+    > The initial WDAC policy that this section refers to was created in the [Create a Windows Defender Application Control policy from a reference computer](#create-a-windows-defender-application-control-policy-from-a-reference-computer) section. If you are using a different WDAC policy, update the **CIPolicyPath** and **InitialCIPolicy** variables.
 
-2. Ensure that rule options 9 (“Advanced Boot Options Menu”) and 10 (“Boot Audit on Failure”) are set the way that you intend for this policy. We strongly recommend that you enable these rule options before you run any enforced policy for the first time. Enabling these options provides administrators with a pre-boot command prompt, and allows Windows to start even if the code integrity policy blocks a kernel-mode driver from running. When ready for enterprise deployment, you can remove these options.
+2. Ensure that rule options 9 (“Advanced Boot Options Menu”) and 10 (“Boot Audit on Failure”) are set the way that you intend for this policy. We strongly recommend that you enable these rule options before you run any enforced policy for the first time. Enabling these options provides administrators with a pre-boot command prompt, and allows Windows to start even if the WDAC policy blocks a kernel-mode driver from running. When ready for enterprise deployment, you can remove these options.
 
     To ensure that these options are enabled in a policy, use [Set-RuleOption](https://technet.microsoft.com/library/mt634483.aspx) as shown in the following commands. You can run these commands even if you're not sure whether options 9 and 10 are already enabled—if so, the commands have no effect.
     
@@ -905,36 +905,36 @@ Every code integrity policy is created with audit mode enabled. After you have s
     ` Set-RuleOption -FilePath $EnforcedCIPolicy -Option 3 -Delete`
 
   > [!Note] 
-  > To enforce a code integrity policy, you delete option 3, the **Audit Mode Enabled** option. There is no “enforced” option that can be placed in a code integrity policy.
+  > To enforce a WDAC policy, you delete option 3, the **Audit Mode Enabled** option. There is no “enforced” option that can be placed in a WDAC policy.
 
-5.  Use [ConvertFrom-CIPolicy](https://technet.microsoft.com/library/mt733073.aspx) to convert the new code integrity policy to binary format:
+5.  Use [ConvertFrom-CIPolicy](https://technet.microsoft.com/library/mt733073.aspx) to convert the new WDAC policy to binary format:
 
     ` ConvertFrom-CIPolicy $EnforcedCIPolicy $CIPolicyBin`
 
-Now that this policy is in enforced mode, you can deploy it to your test computers. Rename the policy to SIPolicy.p7b and copy it to C:\\Windows\\System32\\CodeIntegrity for testing, or deploy the policy through Group Policy by following the instructions in [Deploy and manage code integrity policies with Group Policy](#deploy-and-manage-code-integrity-policies-with-group-policy). You can also use other client management software to deploy and manage the policy.
+Now that this policy is in enforced mode, you can deploy it to your test computers. Rename the policy to SIPolicy.p7b and copy it to C:\\Windows\\System32\\CodeIntegrity for testing, or deploy the policy through Group Policy by following the instructions in [Deploy and manage Windows Defender Application Control with Group Policy](#deploy-and-manage-windows-defender-application-control-with-group-policy). You can also use other client management software to deploy and manage the policy.
 
-## Signing code integrity policies with SignTool.exe
+## Signing Windows Defender Application Control policies with SignTool.exe
 
-Signed code integrity policies give organizations the highest level of malware protection available in Windows 10. 
+Signed WDAC policies give organizations the highest level of malware protection available in Windows 10. 
 In addition to their enforced policy rules, signed policies cannot be modified or deleted by a user or administrator on the computer. 
 These policies are designed to prevent administrative tampering and kernel mode exploit access. 
-With this in mind, it is much more difficult to remove signed code integrity policies. 
+With this in mind, it is much more difficult to remove signed WDAC policies. 
-Before you sign and deploy a signed code integrity policy, we recommend that you [audit the policy](#audit-code-integrity-policies) to discover any blocked applications that should be allowed to run. 
+Before you sign and deploy a signed WDAC policy, we recommend that you [audit the policy](#audit-windows-defender-application-control-policies) to discover any blocked applications that should be allowed to run. 
 
-Signing code integrity policies by using an on-premises CA-generated certificate or a purchased code signing certificate is straightforward. 
+Signing WDAC policies by using an on-premises CA-generated certificate or a purchased code signing certificate is straightforward. 
-If you do not currently have a code signing certificate exported in .pfx format (containing private keys, extensions, and root certificates), see [Optional: Create a code signing certificate for code integrity policies](optional-create-a-code-signing-certificate-for-code-integrity-policies.md) to create one with your on-premises CA. 
+If you do not currently have a code signing certificate exported in .pfx format (containing private keys, extensions, and root certificates), see [Optional: Create a code signing certificate for Windows Defender Application Control](optional-create-a-code-signing-certificate-for-code-integrity-policies.md) to create one with your on-premises CA. 
 
-Before signing code integrity policies for the first time, be sure to enable rule options 9 (“Advanced Boot Options Menu”) and 10 (“Boot Audit on Failure”) to leave troubleshooting options available to administrators. To ensure that a rule option is enabled, you can run a command such as `Set-RuleOption -FilePath <PathAndFilename> -Option 9` even if you're not sure whether the option is already enabled—if so, the command has no effect. When validated and ready for enterprise deployment, you can remove these options. For more information about rule options, see [Code integrity policy rules](deploy-code-integrity-policies-policy-rules-and-file-rules.md#code-integrity-policy-rules) in "Deploy code integrity policies: policy rules and file rules."
+Before signing WDAC policies for the first time, be sure to enable rule options 9 (“Advanced Boot Options Menu”) and 10 (“Boot Audit on Failure”) to leave troubleshooting options available to administrators. To ensure that a rule option is enabled, you can run a command such as `Set-RuleOption -FilePath <PathAndFilename> -Option 9` even if you're not sure whether the option is already enabled—if so, the command has no effect. When validated and ready for enterprise deployment, you can remove these options. For more information about rule options, see [Windows Defender Application Control policy rules](deploy-code-integrity-policies-policy-rules-and-file-rules.md#windows-defender-application-control-policy-rules) in "Deploy Windows Defender Application Control: policy rules and file rules."
 
-To sign a code integrity policy with SignTool.exe, you need the following components:
+To sign a WDAC policy with SignTool.exe, you need the following components:
 
 -   SignTool.exe, found in the Windows SDK (Windows 7 or later)
 
--   The binary format of the code integrity policy that you generated in the [Create a code integrity policy from a reference computer](#create-a-code-integrity-policy-from-a-reference-computer) section or another code integrity policy that you have created
+-   The binary format of the WDAC policy that you generated in the [Create a Windows Defender Application Control policy from a reference computer](#create-a-windows-defender-application-control-policy-from-a-reference-computer) section or another WDAC policy that you have created
 
 -   An internal CA code signing certificate or a purchased code signing certificate
 
-If you do not have a code signing certificate, see the [Optional: Create a code signing certificate for code integrity policies](optional-create-a-code-signing-certificate-for-code-integrity-policies.md) section for instructions on how to create one. If you use an alternate certificate or code integrity policy, be sure to update the following steps with the appropriate variables and certificate so that the commands will function properly. To sign the existing code integrity policy, copy each of the following commands into an elevated Windows PowerShell session:
+If you do not have a code signing certificate, see the [Optional: Create a code signing certificate for Windows Defender Application Control](optional-create-a-code-signing-certificate-for-code-integrity-policies.md) section for instructions on how to create one. If you use an alternate certificate or WDAC policy, be sure to update the following steps with the appropriate variables and certificate so that the commands will function properly. To sign the existing WDAC policy, copy each of the following commands into an elevated Windows PowerShell session:
 
 1.  Initialize the variables that will be used:
 
@@ -945,9 +945,9 @@ If you do not have a code signing certificate, see the [Optional: Create a code
     ` $CIPolicyBin=$CIPolicyPath+"DeviceGuardPolicy.bin"`
 
    > [!Note] 
-   > This example uses the code integrity policy that you created in the [Create a code integrity policy from a reference computer](#create-a-code-integrity-policy-from-a-reference-computer) section. If you are signing another policy, be sure to update the **$CIPolicyPath** and **$CIPolicyBin** variables with the correct information.
+   > This example uses the WDAC policy that you created in the [Create a Windows Defender Application Control policy from a reference computer](#create-a-windows-defender-application-control-policy-from-a-reference-computer) section. If you are signing another policy, be sure to update the **$CIPolicyPath** and **$CIPolicyBin** variables with the correct information.
 
-2.  Import the .pfx code signing certificate. Import the code signing certificate that you will use to sign the code integrity policy into the signing user’s personal store on the computer that will be doing the signing. In this example, you use the certificate that was created in [Optional: Create a code signing certificate for code integrity policies](optional-create-a-code-signing-certificate-for-code-integrity-policies.md).
+2.  Import the .pfx code signing certificate. Import the code signing certificate that you will use to sign the WDAC policy into the signing user’s personal store on the computer that will be doing the signing. In this example, you use the certificate that was created in [Optional: Create a code signing certificate for Windows Defender Application Control](optional-create-a-code-signing-certificate-for-code-integrity-policies.md).
 
 3.  Export the .cer code signing certificate. After the code signing certificate has been imported, export the .cer version to your desktop. This version will be added to the policy so that it can be updated later.
 
@@ -955,13 +955,13 @@ If you do not have a code signing certificate, see the [Optional: Create a code
 
     ` cd $env:USERPROFILE\Desktop `
 
-5.  Use [Add-SignerRule](https://technet.microsoft.com/library/mt634479.aspx) to add an update signer certificate to the code integrity policy:
+5.  Use [Add-SignerRule](https://technet.microsoft.com/library/mt634479.aspx) to add an update signer certificate to the WDAC policy:
 
     ` Add-SignerRule -FilePath $InitialCIPolicy -CertificatePath <Path to exported .cer certificate> -Kernel -User –Update`
 
    > [!Note] 
    > *&lt;Path to exported .cer certificate&gt;* should be  the full path to the certificate that you exported in   step 3.
-    Also, adding update signers is crucial to being able to modify or disable this policy in the future. For more information about how to disable signed code integrity policies, see the [Disable signed code integrity policies within Windows](#disable-signed-code-integrity-policies-within-windows) section.
+    Also, adding update signers is crucial to being able to modify or disable this policy in the future. For more information about how to disable signed WDAC policies, see the [Disable signed Windows Defender Application Control policies within Windows](#disable-signed-windows-defender-application-control-policies-within-windows) section.
 
 6.  Use [Set-RuleOption](https://technet.microsoft.com/library/mt634483.aspx) to remove the unsigned policy rule option:
 
@@ -971,31 +971,31 @@ If you do not have a code signing certificate, see the [Optional: Create a code
 
     ` ConvertFrom-CIPolicy $InitialCIPolicy $CIPolicyBin`
 
-8.  Sign the code integrity policy by using SignTool.exe:
+8.  Sign the WDAC policy by using SignTool.exe:
 
     ` <Path to signtool.exe> sign -v /n "ContosoDGSigningCert" -p7 . -p7co 1.3.6.1.4.1.311.79.1 -fd sha256 $CIPolicyBin`
 
    > [!Note] 
-   > The *&lt;Path to signtool.exe&gt;* variable should be the full path to the SignTool.exe utility. **ContosoDGSigningCert** is the subject name of the certificate that will be used to sign the code integrity policy. You should import this certificate to your personal certificate store on the computer you use to sign the policy.
+   > The *&lt;Path to signtool.exe&gt;* variable should be the full path to the SignTool.exe utility. **ContosoDGSigningCert** is the subject name of the certificate that will be used to sign the WDAC policy. You should import this certificate to your personal certificate store on the computer you use to sign the policy.
 
-9.  Validate the signed file. When complete, the commands should output a signed policy file called DeviceGuardPolicy.bin.p7 to your desktop. You can deploy this file the same way you deploy an enforced or non-enforced policy. For information about how to deploy code integrity policies, see [Deploy and manage code integrity policies with Group Policy](#deploy-and-manage-code-integrity-policies-with-group-policy).
+9.  Validate the signed file. When complete, the commands should output a signed policy file called DeviceGuardPolicy.bin.p7 to your desktop. You can deploy this file the same way you deploy an enforced or non-enforced policy. For information about how to deploy WDAC policies, see [Deploy and manage Windows Defender Application Control with Group Policy](#deploy-and-manage-windows-defender-application-control-with-group-policy).
 
-## Disable unsigned code integrity policies
+## Disable unsigned Windows Defender Application Control policies
 
-There may come a time when an administrator wants to disable a code integrity policy. For unsigned code integrity policies, this process is simple. Depending on how the code integrity policy was deployed, unsigned policies can be disabled in one of two ways. If a code integrity policy was manually enabled and copied to the code integrity folder location, simply delete the file and restart the computer. The following locations can contain executing code integrity policies:
+There may come a time when an administrator wants to disable a WDAC policy. For unsigned WDAC policies, this process is simple. Depending on how the WDAC policy was deployed, unsigned policies can be disabled in one of two ways. If a WDAC policy was manually enabled and copied to the code integrity folder location, simply delete the file and restart the computer. The following locations can contain executing WDAC policies:
 
 -   &lt;EFI System Partition&gt;\\Microsoft\\Boot\\
 
 -   &lt;OS Volume&gt;\\Windows\\System32\\CodeIntegrity\\
 
-If the code integrity policy was deployed by using Group Policy, the GPO that is currently enabling and deploying the policy must be set to disabled. Then, the code integrity policy will be disabled on the next computer restart.
+If the WDAC policy was deployed by using Group Policy, the GPO that is currently enabling and deploying the policy must be set to disabled. Then, the WDAC policy will be disabled on the next computer restart.
 
-## Disable signed code integrity policies within Windows
+## Disable signed Windows Defender Application Control policies within Windows
 
-Signed policies protect Windows from administrative manipulation as well as malware that has gained administrative-level access to the system. For this reason, signed code integrity policies are intentionally more difficult to remove than unsigned policies. They inherently protect themselves from modification or removal and therefore are difficult even for administrators to remove successfully. If the signed code integrity policy is manually enabled and copied to the CodeIntegrity folder, to remove the policy, you must complete the following steps.
+Signed policies protect Windows from administrative manipulation as well as malware that has gained administrative-level access to the system. For this reason, signed WDAC policies are intentionally more difficult to remove than unsigned policies. They inherently protect themselves from modification or removal and therefore are difficult even for administrators to remove successfully. If the signed WDAC policy is manually enabled and copied to the CodeIntegrity folder, to remove the policy, you must complete the following steps.
 
 > [!Note] 
-> For reference, signed code integrity policies should be replaced and removed from the following locations:
+> For reference, signed WDAC policies should be replaced and removed from the following locations:
 
 -   &lt;EFI System Partition&gt;\\Microsoft\\Boot\\
 
@@ -1016,7 +1016,7 @@ Signed policies protect Windows from administrative manipulation as well as malw
 
 5.  Restart the client computer.
 
-If the signed code integrity policy has been deployed using by using Group Policy, you must complete the following steps:
+If the signed WDAC policy has been deployed using by using Group Policy, you must complete the following steps:
 
 1.  Replace the existing policy in the GPO with another signed policy that has the **6 Enabled: Unsigned System Integrity Policy** rule option enabled.
 
@@ -1034,31 +1034,31 @@ If the signed code integrity policy has been deployed using by using Group Polic
 
 6.  Restart the client computer.
 
-## Disable signed code integrity policies within the BIOS
+## Disable signed Windows Defender Application Control policies within the BIOS
 
-There may be a time when signed code integrity policies cause a boot failure. Because code integrity policies enforce kernel mode drivers, it is important that they be thoroughly tested on each software and hardware configuration before being enforced and signed. Signed code integrity policies are validated in the pre-boot sequence by using Secure Boot. When you disable the Secure Boot feature in the BIOS, and then delete the file from the following locations on the operating system disk, it allows the system to boot into Windows:
+There may be a time when signed WDAC policies cause a boot failure. Because WDAC policies enforce kernel mode drivers, it is important that they be thoroughly tested on each software and hardware configuration before being enforced and signed. Signed WDAC policies are validated in the pre-boot sequence by using Secure Boot. When you disable the Secure Boot feature in the BIOS, and then delete the file from the following locations on the operating system disk, it allows the system to boot into Windows:
 
 -   &lt;EFI System Partition&gt;\\Microsoft\\Boot\\
 
 -   &lt;OS Volume&gt;\\Windows\\System32\\CodeIntegrity\\
 
-## Deploy and manage code integrity policies with Group Policy
+## Deploy and manage Windows Defender Application Control with Group Policy
 
-Code integrity policies can easily be deployed and managed with Group Policy. A Windows Defender Device Guard administrative template will be available in Windows Server 2016 that allows you to simplify deployment of Windows Defender Device Guard hardware-based security features and code integrity policies. The following procedure walks you through how to deploy a code integrity policy called **DeviceGuardPolicy.bin** to a test OU called *DG Enabled PCs* by using a GPO called **Contoso GPO Test**.
+WDAC policies can easily be deployed and managed with Group Policy. A Windows Defender Device Guard administrative template will be available in Windows Server 2016 that allows you to simplify deployment of Windows Defender Device Guard hardware-based security features and Windows Defender Application Control policies. The following procedure walks you through how to deploy a WDAC policy called **DeviceGuardPolicy.bin** to a test OU called *DG Enabled PCs* by using a GPO called **Contoso GPO Test**.
 
 > [!Note] 
-> This walkthrough requires that you have previously created a code integrity policy and have a computer running Windows 10 on which to test a Group Policy deployment. For more information about how to create a code integrity policy, see [Create a code integrity policy from a reference computer](#create-a-code-integrity-policy-from-a-reference-computer), earlier in this topic.
+> This walkthrough requires that you have previously created a WDAC policy and have a computer running Windows 10 on which to test a Group Policy deployment. For more information about how to create a WDAC policy, see [Create a Windows Defender Application Control policy from a reference computer](#create-a-windows-defender-application-control-policy-from-a-reference-computer), earlier in this topic.
 
 > [!Note] 
-> Signed code integrity policies can cause boot failures when deployed. We recommend that signed code integrity policies be thoroughly tested on each hardware platform before enterprise deployment.
+> Signed WDAC policies can cause boot failures when deployed. We recommend that signed WDAC policies be thoroughly tested on each hardware platform before enterprise deployment.
 
-To deploy and manage a code integrity policy with Group Policy:
+To deploy and manage a WDAC policy with Group Policy:
 
 1.  On a domain controller on a client computer on which RSAT is installed, open the GPMC by running **GPMC.MSC** or searching for “Group Policy Management” in Windows Search.
 
 2.  Create a new GPO: right-click an OU, for example, the **DG Enabled PCs OU**, and then click **Create a GPO in this domain, and Link it here**, as shown in Figure 3.
 
-    > **Note**&nbsp;&nbsp;You can use any OU name. Also, security group filtering is an option when you consider different ways of combining code integrity policies (or keeping them separate), as discussed in [Planning and getting started on the Windows Defender Device Guard deployment process](planning-and-getting-started-on-the-device-guard-deployment-process.md).
+    > **Note**&nbsp;&nbsp;You can use any OU name. Also, security group filtering is an option when you consider different ways of combining WDAC policies (or keeping them separate), as discussed in [Planning and getting started on the Windows Defender Device Guard deployment process](planning-and-getting-started-on-the-device-guard-deployment-process.md).
 
    ![Group Policy Management, create a GPO](images/dg-fig24-creategpo.png)
 
@@ -1068,31 +1068,31 @@ To deploy and manage a code integrity policy with Group Policy:
 
 4.  Open the Group Policy Management Editor: right-click the new GPO, and then click **Edit**.
 
-5.  In the selected GPO, navigate to Computer Configuration\\Administrative Templates\\System\\Windows Defender Device Guard. Right-click **Deploy Code Integrity Policy** and then click **Edit**.
+5.  In the selected GPO, navigate to Computer Configuration\\Administrative Templates\\System\\Windows Defender Device Guard. Right-click **Deploy Windows Defender Application Control** and then click **Edit**.
 
-    ![Edit the group policy for code integrity](images/dg-fig25-editcode.png)
+    ![Edit the group policy for Windows Defender Application Control](images/dg-fig25-editcode.png)
 
-    Figure 4. Edit the group policy for code integrity
+    Figure 4. Edit the group policy for Windows Defender Application Control
 
-6.  In the **Display Code Integrity Policy** dialog box, select the **Enabled** option, and then specify the code integrity policy deployment path.
+6.  In the **Deploy Windows Defender Application Control** dialog box, select the **Enabled** option, and then specify the code integrity policy deployment path.
 
    In this policy setting, you specify either the local path in which the policy will exist on the client computer or a Universal Naming Convention (UNC) path that the client computers will look to retrieve the latest version of the policy. For example, with DeviceGuardPolicy.bin on the test computer, the example file path would be C:\\Windows\\System32\\CodeIntegrity\\DeviceGuardPolicy.bin, as shown in Figure 5.
 
   > [!Note] 
-  > The illustration shows the example file name *DeviceGuardPolicy.bin* because this name was used earlier in this topic, in [Create a code integrity policy from a reference computer](#create-a-code-integrity-policy-from-a-reference-computer). Also, this policy file does not need to be copied to every computer. You can instead copy the code integrity policies to a file share to which all computer accounts have access. Any policy selected here is converted to SIPolicy.p7b when it is deployed to the individual client computers.
+  > The illustration shows the example file name *DeviceGuardPolicy.bin* because this name was used earlier in this topic, in [Create a Windows Defender Application Control policy from a reference computer](#create-a-windows-defender-application-control-policy-from-a-reference-computer). Also, this policy file does not need to be copied to every computer. You can instead copy the WDAC policies to a file share to which all computer accounts have access. Any policy selected here is converted to SIPolicy.p7b when it is deployed to the individual client computers.
 
-   ![Group Policy called Deploy Code Integrity Policy](images/dg-fig26-enablecode.png)
+   ![Group Policy called Deploy Windows Defender Application Control](images/dg-fig26-enablecode.png)
 
-   Figure 5. Enable the code integrity policy
+   Figure 5. Enable the Windows Defender Application Control policy
 
    > [!Note] 
-   > You may have noticed that the GPO setting references a .p7b file and this example uses a .bin file for the policy. Regardless of the type of policy you deploy (.bin, .p7b, or .p7), they are all converted to SIPolicy.p7b when dropped on the client computer running Windows 10. Make your code integrity policies friendly and allow the system to convert the policy names for you to ensure that the policies are easily distinguishable when viewed in a share or any other central repository.
+   > You may have noticed that the GPO setting references a .p7b file and this example uses a .bin file for the policy. Regardless of the type of policy you deploy (.bin, .p7b, or .p7), they are all converted to SIPolicy.p7b when dropped on the client computer running Windows 10. Make your WDAC policies friendly and allow the system to convert the policy names for you to ensure that the policies are easily distinguishable when viewed in a share or any other central repository.
 
-7.  Close the Group Policy Management Editor, and then restart the Windows 10 test computer. Restarting the computer updates the code integrity policy. For information about how to audit code integrity policies, see the [Audit code integrity policies](#audit-code-integrity-policies) section.
+7.  Close the Group Policy Management Editor, and then restart the Windows 10 test computer. Restarting the computer updates the WDAC policy. For information about how to audit WDAC policies, see the [Audit Windows Defender Application Control policies](#audit-windows-defender-application-control-policies) section.
 
 ## Related topics
 
-[Introduction to Windows Defender Device Guard: virtualization-based security and code integrity policies](introduction-to-device-guard-virtualization-based-security-and-code-integrity-policies.md)
+[Introduction to Windows Defender Device Guard: virtualization-based security and Windows Defender Application Control](introduction-to-device-guard-virtualization-based-security-and-code-integrity-policies.md)
 
-[Deploy Windows Defender Device Guard: enable virtualization-based security](deploy-device-guard-enable-virtualization-based-security.md)
+[Enable virtualization-based protection of code integrity](deploy-device-guard-enable-virtualization-based-security.md)
 

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

@@ -9,7 +9,7 @@ author: brianlic-msft
 ms.date: 10/20/2017
 ---
 
-# Deploy Windows Defender Device Guard: deploy code integrity policies
+# Deploy Windows Defender Application Control
 
 **Applies to**
 -   Windows 10
@@ -17,17 +17,17 @@ ms.date: 10/20/2017
 
 This section includes the following topics:
 
-- [Optional: Create a code signing certificate for code integrity policies](optional-create-a-code-signing-certificate-for-code-integrity-policies.md)
+- [Optional: Create a code signing certificate for Windows Defender Application Control](optional-create-a-code-signing-certificate-for-code-integrity-policies.md)
-- [Deploy code integrity policies: policy rules and file rules](deploy-code-integrity-policies-policy-rules-and-file-rules.md)
+- [Deploy Windows Defender Application Control: policy rules and file rules](deploy-code-integrity-policies-policy-rules-and-file-rules.md)
-- [Deploy code integrity policies: steps](deploy-code-integrity-policies-steps.md)
+- [Deploy Windows Defender Application Control: steps](deploy-code-integrity-policies-steps.md)
-- [Deploy catalog files to support code integrity policies](deploy-catalog-files-to-support-code-integrity-policies.md)
+- [Deploy catalog files to support Windows Defender Application Control](deploy-catalog-files-to-support-code-integrity-policies.md)
-- [Deploy Managed Installer for Windows Defender Device Guard](deploy-managed-installer-for-device-guard.md)
+- [Deploy Managed Installer for Windows Defender Application Control](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.
+To increase the protection for devices that meet certain hardware requirements, you can use virtualization-based protection of code integrity with your Windows Defender Application Control (WDAC) 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-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).
+- For steps, see [Enable virtualization-based protection of code integrity](deploy-device-guard-enable-virtualization-based-security.md).
 
 ## Related topics
 
-[Introduction to Windows Defender Device Guard: virtualization-based security and code integrity policies](introduction-to-device-guard-virtualization-based-security-and-code-integrity-policies.md)
+[Introduction to Windows Defender Device Guard: virtualization-based security and Windows Defender Application Control](introduction-to-device-guard-virtualization-based-security-and-code-integrity-policies.md)
 

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

@@ -9,25 +9,30 @@ author: brianlic-msft
 ms.date: 10/20/2017
 ---
 
-# Deploy Windows Defender Device Guard: enable virtualization-based security
+# Enable virtualization-based protection of code integrity
 
 **Applies to**
 -   Windows 10
 -   Windows Server 2016
 
-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:
+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. When used with Windows Defender Application Control (WDAC), HVCI helps achieve a locked down configuration state known as Windows Defender Device Guard that can block many types of malware from running on computers running Windows 10 and Windows Server 2016.
 
-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.
+> [!NOTE]
+> 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. We recommend testing thoroughly before enabling HVCI on production systems.
 
-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).
+Use the following procedure to enable virtualization-based protection of code integrity:
 
-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).
+1.  **Decide whether to use the procedures in this topic, or to use the Windows Defender Device Guard readiness tool**. To enable HVCI, 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.
 
-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). 
+2.  **Verify that hardware and firmware requirements are met**. Verify that your client computers have the hardware and firmware to run HVCI. 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).
 
-## Windows feature requirements for virtualization-based security and Windows Defender 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-protection-of-code-integrity).
 
-Make sure these operating system features are enabled before you can enable VBS:
+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 protection of code integrity](#enable-virtualization-based-protection-of-code-integrity). 
+
+## Windows feature requirements for virtualization-based protection of code integrity
+
+Make sure these operating system features are enabled before you can enable HVCI:
 
 - Beginning with Windows 10, version 1607 or Windows Server 2016:<br> 
 Hyper-V Hypervisor, which is enabled automatically. No further action is needed.
@@ -37,16 +42,16 @@ Hyper-V Hypervisor and Isolated User Mode (shown in Figure 1).
  
 ![Turn Windows features on or off](images/dg-fig1-enableos.png)
 
-**Figure 1. Enable operating system features for VBS, Windows 10, version 1511**
+**Figure 1. Enable operating system features for HVCI, 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
+## Enable virtualization-based protection of code integrity
 
-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.
+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 HVCI.
 
-### Use Group Policy to enable VBS and Windows Defender Device Guard
+### Use Group Policy to enable virtualization-based protection of code integrity
 
 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**.
 
@@ -60,12 +65,12 @@ If you don't want to use the [hardware readiness tool](https://www.microsoft.com
 
     ![Edit the group policy for Virtualization Based Security](images/dg-fig3-enablevbs.png)
 
-    Figure 3. Enable VBS
+    Figure 3. Enable virtualization-based security (VBS)
 
 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).
+    - **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 or HVCI protection, although it can have WDAC enabled.<br>For information about how VBS uses the hypervisor to strengthen protections provided by WDAC, 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).
 
     For **Virtualization Based Protection of Code Integrity**:
 
@@ -75,20 +80,20 @@ If you don't want to use the [hardware readiness tool](https://www.microsoft.com
 
     ![Group Policy, Turn On Virtualization Based Security](images/dg-fig7-enablevbsofkmci.png)
 
-    Figure 5. Configure VBS, Lock setting (in Windows 10, version 1607)
+    Figure 5. Configure HVCI, Lock setting (in Windows 10, version 1607)
 
 7.  Close the Group Policy Management Editor, and then restart the Windows 10 test computer. The settings will take effect upon restart.
 
 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
+### Use registry keys to enable virtualization-based protection of code integrity
 
-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.
+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 (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>
+> - 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>For information about how VBS uses the hypervisor to strengthen protections provided by WDAC, 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
@@ -284,6 +289,6 @@ Figure 6. Windows Defender Device Guard properties in the System Summary
 
 ## Related topics
 
-- [Introduction to Windows Defender Device Guard: virtualization-based security and code integrity policies](introduction-to-device-guard-virtualization-based-security-and-code-integrity-policies.md)
+- [Introduction to Windows Defender Device Guard: virtualization-based security and Windows Defender Application Control](introduction-to-device-guard-virtualization-based-security-and-code-integrity-policies.md)
 
-- [Deploy Windows Defender Device Guard: deploy code integrity policies](deploy-device-guard-deploy-code-integrity-policies.md)
+- [Deploy Windows Defender Application Control](deploy-device-guard-deploy-code-integrity-policies.md)

windows/device-security/device-guard/deploy-managed-installer-for-device-guard.md

@@ -9,9 +9,9 @@ author: mdsakibMSFT
 ms.date: 10/20/2017
 ---
 
-# Deploy Managed Installer for Windows Defender Device Guard
+# Deploy Managed Installer for Windows Defender Application Control
 
-Creating and maintaining application execution control policies has always been challenging, and finding ways to address this issue has been a frequently-cited request for customers of AppLocker and Windows Defender Device Guard [configurable code integrity (CI)](device-guard-deployment-guide.md). 
+Creating and maintaining application execution control policies has always been challenging, and finding ways to address this issue has been a frequently-cited request for customers of AppLocker and Windows Defender Application Control (WDAC). 
 This is especially true for enterprises with large, ever changing software catalogs. 
 
 Windows 10, version 1703 (also known as the Windows 10 Creators Update) provides a new option, known as a managed installer, that allows IT administrators to automatically authorize applications deployed and installed by a designated software distribution solution, such as System Center Configuration Manager. 
@@ -22,23 +22,23 @@ A managed installer helps an IT admin balance security and manageability require
 A managed installer uses a new rule collection in AppLocker to specify one or more executables that are trusted by the organization as an authorized source for application deployment. 
 Specifying an executable as a managed installer will cause Windows to tag files that are written from the executable’s process (or processes it launches) as having originated from a trusted installation authority.  
 
-Once the IT administrator adds the Allow: Managed Installer option to a configurable CI policy for Windows Defender Device Guard, the configurable CI component will subsequently check for the presence of the origin information when evaluating other application execution control rules specified in the policy. 
+Once the IT administrator adds the Allow: Managed Installer option to a WDAC policy, the WDAC component will subsequently check for the presence of the origin information when evaluating other application execution control rules specified in the policy. 
 If there are no deny rules present for the file, it will be authorized based on the managed installer origin information.
 
 > [!NOTE] 
-> Admins needs to ensure that there is a CI policy in place to allow the system to boot and run any other authorized applications that may not be deployed through a managed installer. 
+> Admins needs to ensure that there is a WDAC policy in place to allow the system to boot and run any other authorized applications that may not be deployed through a managed installer. 
 >
-> Examples of CI policies available in C:\Windows\schemas\CodeIntegrity\ExamplePolicies help authorize Windows OS components, WHQL signed drivers and all Store apps. 
+> Examples of WDAC policies available in C:\Windows\schemas\CodeIntegrity\ExamplePolicies help authorize Windows OS components, WHQL signed drivers and all Store apps. 
-> Admins can reference and customize them as needed for their Windows Defender Device Guard deployment.
+> Admins can reference and customize them as needed for their Windows Defender Application Control deployment or create a custom WDAC policy as described in [Deploy Windows Defender Application Control: steps](deploy-code-integrity-policies-steps.md#create-a-windows-defender-application-control-policy-from-a-reference-computer).
 
-## Configuring a managed installer with AppLocker and configurable code integrity policy
+## Configuring a managed installer with AppLocker and Windows Defender Application Control
 
-Setting up managed installer tracking and application execution enforcement requires applying both an AppLocker and configurable CI policy with specific rules and options enabled. 
+Setting up managed installer tracking and application execution enforcement requires applying both an AppLocker and WDAC policy with specific rules and options enabled. 
 There are three primary steps to keep in mind:
 
 - Specify managed installers using the Managed Installer rule collection in AppLocker policy
 - Enable service enforcement in AppLocker policy
-- Enable the managed installer option in a configurable CI policy
+- Enable the managed installer option in a WDAC policy
 
 ### Specify managed installers using the Managed Installer rule collection in AppLocker policy
 
@@ -105,45 +105,29 @@ For example:
   </RuleCollection>
 ```
 
-### Enable the managed installer option in CI policy
+### Enable the managed installer option in WDAC policy
 
-In order to enable trust for the binaries laid down by managed installers, the Allow: Managed Installer option must be specified in your configurable CI policy. .
+In order to enable trust for the binaries laid down by managed installers, the Allow: Managed Installer option must be specified in your WDAC policy.
 This can be done by using the [Set-RuleOption cmdlet](https://technet.microsoft.com/itpro/powershell/windows/configci/set-ruleoption). 
 An example of the managed installer option being set in policy is shown below.
 
 ```code
 <Rules>  
-
     <Rule>  
-
       <Option>Enabled:Unsigned System Integrity Policy</Option>  
-
     </Rule>  
-
     <Rule>  
-
       <Option>Enabled:Advanced Boot Options Menu</Option>  
-
     </Rule>  
-
     <Rule>  
-
       <Option>Enabled:UMCI</Option>  
-
     </Rule>  
-
     <Rule>  
-
       <Option>Enabled:Inherit Default Policy</Option>  
-
     </Rule>
-
     <Rule>  
-
       <Option>Enabled:Managed Installer </Option>  
-
     </Rule>  
-
   </Rules>  
 ```
 
@@ -152,32 +136,31 @@ An example of the managed installer option being set in policy is shown below.
 Since managed installer is a heuristic-based mechanism, it does not provide the same security guarantees that explicit allow or deny rules do. 
 It is best suited for deployment to systems where each user is configured as a standard user and where all software is deployed and installed by a software distribution solution, such as System Center Configuration Manager. 
 
-Users with administrator privileges on the system may be able to circumvent the intent of Windows Defender Device Guard configurable CI when the managed installer option is allowed. 
+Users with administrator privileges or malware running as an administrator user on the system may be able to circumvent the intent of Windows Defender Application Control when the managed installer option is allowed. 
-If the authorized managed installer process performs installations in the context of a user with standard privileges, then it is possible that standard users may be able to circumvent the intent of Windows Defender Device Guard configurable CI policy. 
+If the authorized managed installer process performs installations in the context of a user with standard privileges, then it is possible that standard users or malware running as standard user may be able to circumvent the intent of Windows Defender Application Control. 
-In some cases, the heuristic tracking and authorizing applications may be active on the first execution of an application that is laid down from a designated managed installer. 
+Some application installers include an option to automatically run the application at the end of the installation process. If this happens when the installer is run by a managed installer, then the managed installer's heuristic tracking and authorization may continue to apply to all files created during the first run of the application. This could result in over-authorization for executables that were not intended.
-Typically, this would occur if the managed installer executes the application directly as part of the installation process. 
 To avoid this, ensure that the application deployment solution being used as a managed installer limits running applications as part of installation.   
 
 ## Known limitations with managed installer
 
 - Application execution control based on managed installer does not support applications that self-update. 
-If an application deployed by a managed installer subsequently updates itself, the updated application files will no longer include the managed installer origin EA information and will not be authorized to run. 
+If an application deployed by a managed installer subsequently updates itself, the updated application files will no longer include the managed installer origin information and will not be authorized to run. 
 Enterprises should deploy and install all application updates using the managed installer. 
 In some cases, it may be possible to also designate an application binary that performs the self-updates as a managed installer. 
 Proper review for functionality and security should be performed for the application before using this method. 
 
-- Although configurable CI policies can be deployed in both audit and enforced mode, the managed installer option is currently only recommended for use with policies set to enforced except in lab environments. 
+- Although WDAC policies can be deployed in both audit and enforced mode, the managed installer option is currently only recommended for use with policies set to enforced except in lab environments. 
-Using the managed installer option with configurable CI policies set to audit only may result in unexpected behavior if the policy is subsequently changed to enforced mode. 
+Using the managed installer option with WDAC policies set to audit only may result in unexpected behavior if the policy is subsequently changed to enforced mode. 
 
-- Modern apps deployed through a managed installer will not be tracked by the heuristic and will need to be appropriately authorized in policy.
+- Modern apps deployed through a managed installer will not be tracked by the managed installer heuristic and will need to be separately authorized in your WDAC policy.
 
-- Executables that extract files and then attempt to execute may fail the heuristic. 
+- Executables that extract files and then attempt to execute may not be allowed by the managed installer heuristic. 
 In some cases, it may be possible to also designate an application binary that performs such an operation as a managed installer. 
 Proper review for functionality and security should be performed for the application before using this method.
 
 - The managed installer heuristic does not authorize drivers. 
-The configurable code integrity policy being used must have rules that allow the necessary drivers to run.  
+The WDAC policy must have rules that allow the necessary drivers to run.  
 
-- In some cases, the code integrity logs will contain error events for native images generated for .NET assemblies. 
+- In some cases, the code integrity logs where WDAC errors and warnings are written will contain error events for native images generated for .NET assemblies. 
 Typically, the error is functionally benign as a blocked native image will result in the corresponding assembly being re-interpreted. 
 Review for functionality and performance for the related applications using the native images maybe necessary in some cases. 

windows/device-security/device-guard/device-guard-deployment-guide.md

@@ -16,32 +16,29 @@ ms.date: 10/20/2017
 -   Windows 10
 -   Windows Server 2016
 
-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. 
+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 describes a locked-down device configuration state that uses multiple 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 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. If the app isn’t trusted, it can’t run, period. 
 
-> [!NOTE]
+Windows Defender Device Guard also uses 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. 
-> 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:
 
-- [Introduction to Windows Defender Device Guard: virtualization-based security and code integrity policies](introduction-to-device-guard-virtualization-based-security-and-code-integrity-policies.md)
+- [Introduction to Windows Defender Device Guard: virtualization-based security and Windows Defender Application Control](introduction-to-device-guard-virtualization-based-security-and-code-integrity-policies.md)
 
 - [Requirements and deployment planning guidelines for Windows Defender Device Guard](requirements-and-deployment-planning-guidelines-for-device-guard.md)
 
 - [Planning and getting started on the Windows Defender Device Guard deployment process](planning-and-getting-started-on-the-device-guard-deployment-process.md)
 
-- [Deploy Windows Defender Device Guard: deploy code integrity policies](deploy-device-guard-deploy-code-integrity-policies.md)
+- [Deploy Windows Defender Application Control](deploy-device-guard-deploy-code-integrity-policies.md)
 
-    - [Optional: Create a code signing certificate for code integrity policies](optional-create-a-code-signing-certificate-for-code-integrity-policies.md)
+    - [Optional: Create a code signing certificate for Windows Defender Application Control](optional-create-a-code-signing-certificate-for-code-integrity-policies.md)
 
-    - [Deploy code integrity policies: policy rules and file rules](deploy-code-integrity-policies-policy-rules-and-file-rules.md)
+    - [Deploy Windows Defender Application Control: policy rules and file rules](deploy-code-integrity-policies-policy-rules-and-file-rules.md)
 
-    - [Deploy code integrity policies: steps](deploy-code-integrity-policies-steps.md)
+    - [Deploy Windows Defender Application Control: steps](deploy-code-integrity-policies-steps.md)
 
-    - [Deploy catalog files to support code integrity policies](deploy-catalog-files-to-support-code-integrity-policies.md)
+    - [Deploy catalog files to support Windows Defender Application Control](deploy-catalog-files-to-support-code-integrity-policies.md)
 
-- [Deploy Windows Defender Device Guard: enable virtualization-based security](deploy-device-guard-enable-virtualization-based-security.md)
+- [Enable virtualization-based protection of code integrity](deploy-device-guard-enable-virtualization-based-security.md)
 
 ## Related topics
 

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

@@ -9,16 +9,16 @@ author: brianlic-msft
 ms.date: 10/20/2017
 ---
 
-# Introduction to Windows Defender Device Guard: virtualization-based security and code integrity policies
+# Introduction to Windows Defender Device Guard: virtualization-based security and Windows Defender Application Control
 
 **Applies to**
 -   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 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 *Windows Defender Application Control (WDAC) policies*.
 
 > [!NOTE]
-> Beginning with Windows 10, version 1709, configurable code integrity policies are known as Windows Defender Application Control.
+> Prior to Windows 10, version 1709, Windows Defender Application Control was known as configurable code integrity policies.
 
 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.
 
@@ -30,19 +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 | **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 new malware**, for which the "signature" is not yet known | **Windows Defender Application Control (WDAC)**:&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 WDAC, 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 WDAC is strengthened by such features, as described in the next rows.<br><br> [!NOTE] Prior to Windows 10, version 1709, Windows Defender Application Control was known as configurable code integrity policies. |
-| **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. |
+| **Exposure to unsigned code** (most malware is unsigned) | **WDAC plus catalog files as needed**:&nbsp;&nbsp;Because most malware is unsigned, WDAC 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 WDAC 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 WDAC 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 protection of code integrity**:&nbsp;&nbsp;This is protection that uses Windows 10’s new virtualization-based security (VBS) feature to help protect the kernel and other parts of the operating system. When virtualization-based protection of code integrity (also known as hypervisor-protected code integrity, or HVCI) 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 HVCI, 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, 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 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).
+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 WDAC 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
 
-Beginning with Windows 10, version 1709, configurable code integrity policies are known as Windows Defender Application Control. 
+Prior to Windows 10, version 1709, Windows Defender Application Control (WDAC) was known as configurable code integrity policies. 
 
-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).
+Beginning with Windows 10, version 1703, you can use WDAC 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 Windows Defender Application Control 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
 
@@ -50,36 +50,36 @@ You can easily manage Windows Defender Device Guard features by using familiar e
 
 <!-- The item about "Intune" below could be updated at some point, when more information and a link are available. -->
 
--   **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.
+-   **Group Policy**. Windows 10 provides an administrative template to configure and deploy the configurable WDAC policies for your organization. Another template 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 WDAC 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-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)
+    - 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 WDAC with Group Policy](deploy-code-integrity-policies-steps.md#deploy-and-manage-windows-defender-application-control-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).
+-   **Microsoft System Center Configuration Manager**. You can use System Center Configuration Manager to simplify deployment and management of catalog files, WDAC 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).
 
-- **Microsoft Intune**. In a future release of Microsoft Intune, Microsoft is considering including features that will support the deployment and management of code integrity policies and catalog files.
+- **Microsoft Intune**. You can use Microsoft Intune to simplify deployment and management of WDAC policies, as well as provide version control. In a future release of Microsoft Intune, Microsoft is considering including features that will support the deployment and management of catalog files.
 
--   **Windows PowerShell**. You can use Windows PowerShell to create and service code integrity policies. For more information, see [Deploy code integrity policies: steps](deploy-code-integrity-policies-steps.md) and [Configurable Code Integrity Policy for Windows PowerShell](https://technet.microsoft.com/library/mt634481.aspx).
+-   **Windows PowerShell**. You can use Windows PowerShell to create and service WDAC policies. For more information, see [Deploy Windows Defender Application Control: steps](deploy-code-integrity-policies-steps.md).
 
 These options provide the same experience you're used to in order to manage your existing enterprise management solutions. 
 
 For more information about the deployment of Windows Defender Device Guard features, see:
-- [Deploy Windows Defender Device Guard: deploy code integrity policies](deploy-device-guard-deploy-code-integrity-policies.md)
+- [Deploy Windows Defender Application Control](deploy-device-guard-deploy-code-integrity-policies.md)
-- [Deploy Windows Defender Device Guard: enable virtualization-based security](deploy-device-guard-enable-virtualization-based-security.md)
+- [Deploy virtualization-based protection of code integrity](deploy-device-guard-enable-virtualization-based-security.md)
 
 ## Other features that relate to Windows Defender Device Guard
 
 ### Windows Defender Device Guard with AppLocker
 
-Although [AppLocker](/windows/device-security/applocker/applocker-overview) is not considered a new Windows Defender Device Guard feature, it complements Windows Defender Device Guard functionality when enforced code integrity cannot be fully implemented or its functionality does not cover every desired scenario. There are many scenarios in which code integrity policies would be used alongside AppLocker rules. As a best practice, you should enforce code integrity policies at the most restrictive level possible for your organization, and then you can use AppLocker to fine-tune the restrictions to an even lower level.
+Although [AppLocker](/windows/device-security/applocker/applocker-overview) is not considered a new Windows Defender Device Guard feature, it complements Windows Defender Device Guard functionality when WDAC cannot be fully implemented or its functionality does not cover every desired scenario. There are many scenarios in which WDAC would be used alongside AppLocker rules. As a best practice, you should enforce WDAC at the most restrictive level possible for your organization, and then you can use AppLocker to fine-tune the restrictions to an even lower level.
 
-> **Note**&nbsp;&nbsp;One example of how Windows Defender Device Guard functionality can be enhanced by AppLocker is when you want to limit universal applications. Universal applications have already been validated by Microsoft to be trustworthy to run, but an organization may not want to allow specific universal applications to run in their environment. You can accomplish this enforcement by using an AppLocker rule.
+> **Note**&nbsp;&nbsp;One example of how Windows Defender Device Guard functionality can be enhanced by AppLocker is when you want to apply different policies for different users on the same device. For example, you may allow your IT support personnel to run additional apps that you do not allow for your end-users. You can accomplish this user-specific enforcement by using an AppLocker rule.
 
 AppLocker and Windows Defender Device Guard should run side-by-side in your organization, which offers the best of both security features at the same time and provides the most comprehensive security to as many devices as possible. In addition to these features, we recommend that you continue to maintain an enterprise antivirus solution for a well-rounded enterprise security portfolio.
 
 ### Windows Defender Device Guard with Windows Defender Credential Guard
 
-Another Windows 10 feature that employs VBS is [Windows Defender Credential Guard](/windows/access-protection/credential-guard/credential-guard). Windows Defender Credential Guard provides additional protection to Active Directory domain users by storing domain credentials within the same type of VBS virtualization container that hosts code integrity. By isolating these domain credentials from the active user mode and kernel mode, they have a much lower risk of being stolen. For more information about Windows Defender Credential Guard (which is not a feature within Windows Defender Device Guard), see [Protect derived domain credentials with Windows Defender Credential Guard](/windows/access-protection/credential-guard/credential-guard).
+Another Windows 10 feature that employs VBS is [Windows Defender Credential Guard](/windows/access-protection/credential-guard/credential-guard). Windows Defender Credential Guard provides additional protection to Active Directory domain users by storing domain credentials within the same type of VBS virtualization container that hosts code integrity when HVCI is enabled. By isolating these domain credentials from the active user mode and kernel mode, they have a much lower risk of being stolen. For more information about Windows Defender Credential Guard (which is not a feature within Windows Defender Device Guard), see [Protect derived domain credentials with Windows Defender Credential Guard](/windows/access-protection/credential-guard/credential-guard).
 
 Windows Defender Credential Guard is targeted at resisting pass-the-hash and pass-the-ticket techniques. By employing multifactor authentication with Windows Defender Credential Guard, organizations can gain additional protection against such threats. 
 

windows/device-security/device-guard/optional-create-a-code-signing-certificate-for-code-integrity-policies.md

@@ -9,13 +9,13 @@ author: brianlic-msft
 ms.date: 10/20/2017
 ---
 
-# Optional: Create a code signing certificate for code integrity policies
+# Optional: Create a code signing certificate for Windows Defender Application Control
 
 **Applies to**
 -   Windows 10
 -   Windows Server 2016
 
-As you deploy code integrity policies (part of Windows Defender Device Guard), you might need to sign catalog files or code integrity policies internally. To do this, you will either need a publicly issued code signing certificate or an internal CA. If you have purchased a code signing certificate, you can skip this topic and instead follow other topics listed in [Deploy Windows Defender Device Guard: deploy code integrity policies](deploy-device-guard-deploy-code-integrity-policies.md). 
+As you deploy Windows Defender Application Control (WDAC) (also part of Windows Defender Device Guard), you might need to sign catalog files or WDAC policies internally. To do this, you will either need a publicly issued code signing certificate or an internal CA. If you have purchased a code signing certificate, you can skip this topic and instead follow other topics listed in [Deploy Windows Defender Application Control](deploy-device-guard-deploy-code-integrity-policies.md). 
 
 If you have an internal CA, complete these steps to create a code signing certificate. 
 Only RSA algorithm is supported for the code signing certificate, and signatures must be PKCS 1.5 padded. 
@@ -33,7 +33,7 @@ ECDSA is not supported.
 
 4.  On the **Compatibility** tab, clear the **Show resulting changes** check box. Select **Windows Server 2012** from the **Certification Authority** list, and then select **Windows 8 / Windows Server 2012** from the **Certificate recipient** list.
 
-5.  On the **General** tab, specify the **Template display name** and **Template name**. This example uses the name **DG Catalog Signing Certificate**.
+5.  On the **General** tab, specify the **Template display name** and **Template name**. This example uses the name **WDAC Catalog Signing Certificate**.
 
 6.  On the **Request Handling** tab, select the **Allow private key to be exported** check box.
 
@@ -63,7 +63,7 @@ When this certificate template has been created, you must publish it to the CA p
 
     A list of available templates to issue appears, including the template you just created.
 
-2.  Select the DG Catalog signing certificate, and then click **OK**.
+2.  Select the WDAC Catalog signing certificate, and then click **OK**.
 
 Now that the template is available to be issued, you must request one from the computer running Windows 10 on which you create and sign catalog files. To begin, open the MMC, and then complete the following steps:
 
@@ -93,13 +93,13 @@ This certificate must be installed in the user’s personal store on the compute
 
 3.  Choose the default settings, and then select **Export all extended properties**.
 
-4.  Set a password, select an export path, and then select **DGCatSigningCert.pfx** as the file name.
+4.  Set a password, select an export path, and then select **WDACCatSigningCert.pfx** as the file name.
 
 When the certificate has been exported, import it into the personal store for the user who will be signing the catalog files or code integrity policies on the specific computer that will be signing them.
 
 ## Related topics
 
-- [Introduction to Windows Defender Device Guard: virtualization-based security and code integrity policies](introduction-to-device-guard-virtualization-based-security-and-code-integrity-policies.md)
+- [Introduction to Windows Defender Device Guard: virtualization-based security and Windows Defender Application Control](introduction-to-device-guard-virtualization-based-security-and-code-integrity-policies.md)
 
-- [Deploy Windows Defender Device Guard: deploy code integrity policies](deploy-device-guard-deploy-code-integrity-policies.md)
+- [Deploy Windows Defender Application Control](deploy-device-guard-deploy-code-integrity-policies.md)
 

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

@@ -19,61 +19,60 @@ 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-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#windows-defender-hardware-firmware-and-software-requirements-for-
+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). 
-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#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:
+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 Windows Defender Application Control (WDAC) policy for them. More variety across departments might mean you need to create and manage more WDAC policies. The following questions can help you clarify how many WDAC 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.
+    - How standardized is the hardware?<br>This can be relevant because of drivers. You could create a WDAC 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 WDAC policies on different "reference" hardware, then merge the policies together, to ensure that the resulting policy recognizes all the drivers in your environment.
 
-    - What software does each department or role need? Should they be able to install and run other departments’ software?<br>If multiple departments are allowed to run the same list of software, you might be able to merge several code integrity policies to simplify management.
+    - What software does each department or role need? Should they be able to install and run other departments’ software?<br>If multiple departments are allowed to run the same list of software, you might be able to merge several WDAC policies to simplify management.
          
-    - Are there departments or roles where unique, restricted software is used?<br>If one department needs to run an application that no other department is allowed, it might require a separate code integrity policy. Similarly, if only one department must run an old version of an application (while other departments allow only the newer version), it might require a separate code integrity policy.
+    - Are there departments or roles where unique, restricted software is used?<br>If one department needs to run an application that no other department is allowed, it might require a separate WDAC policy. Similarly, if only one department must run an old version of an application (while other departments allow only the newer version), it might require a separate WDAC policy.
 
-    - Is there already a list of accepted applications?<br>A list of accepted applications can be used to help create a baseline code integrity policy.<br>As of Windows 10, version 1703, it might also be useful to have a list of plug-ins, add-ins, or modules that you want to allow only in a specific app (such as a line-of-business app). Similarly, it might be useful to have a list of plug-ins, add-ins, or modules that you want to block in a specific app (such as a browser).
+    - Is there already a list of accepted applications?<br>A list of accepted applications can be used to help create a baseline WDAC policy.<br>As of Windows 10, version 1703, it might also be useful to have a list of plug-ins, add-ins, or modules that you want to allow only in a specific app (such as a line-of-business app). Similarly, it might be useful to have a list of plug-ins, add-ins, or modules that you want to block in a specific app (such as a browser).
 
     - As part of a threat review process, have you reviewed systems for software that can load arbitrary DLLs or run code or scripts? 
-    In day-to-day operations, your organization’s security policy may allow certain applications, code, or scripts to run on your systems depending on their role and the context. However, if your security policy requires that you run only trusted applications, code, and scripts on your systems, you may decide to lock these systems down securely with Windows Defender Device Guard code integrity policies. You can also fine-tune your control by using Windows Defender Device Guard in combination with AppLocker, as described in [Windows Defender Device Guard with AppLocker](https://technet.microsoft.com/itpro/windows/keep-secure/introduction-to-device-guard-virtualization-based-security-and-code-integrity-policies#device-guard-with-applocker). 
+    In day-to-day operations, your organization’s security policy may allow certain applications, code, or scripts to run on your systems depending on their role and the context. However, if your security policy requires that you run only trusted applications, code, and scripts on your systems, you may decide to lock these systems down securely with Windows Defender Application Control policies. You can also fine-tune your control by using Windows Defender Application Control in combination with AppLocker, as described in [Windows Defender Device Guard with AppLocker](introduction-to-device-guard-virtualization-based-security-and-code-integrity-policies.md#windows-defender-device-guard-with-applocker). 
 
-    Legitimate applications from trusted vendors provide valid functionality. However, an attacker could also potentially use that same functionality to run malicious executable code that could bypass code integrity policies.
+    Legitimate applications from trusted vendors provide valid functionality. However, an attacker could also potentially use that same functionality to run malicious executable code that could bypass WDAC.
 
-    For operational scenarios that require elevated security, certain applications with known Code Integrity bypasses may represent a security risk if you whitelist them in your code integrity policies. Other applications where older versions of the application had vulnerabilities also represent a risk. Therefore, you may want to deny or block such applications from your code integrity policies. For applications with vulnerabilities, once the vulnerabilities are fixed you can create a rule that only allows the fixed or newer versions of that application. The decision to allow or block applications depends on the context and on how the reference system is being used.
+    For operational scenarios that require elevated security, certain applications with known Code Integrity bypasses may represent a security risk if you whitelist them in your WDAC policies. Other applications where older versions of the application had vulnerabilities also represent a risk. Therefore, you may want to deny or block such applications from your WDAC policies. For applications with vulnerabilities, once the vulnerabilities are fixed you can create a rule that only allows the fixed or newer versions of that application. The decision to allow or block applications depends on the context and on how the reference system is being used.
 
-    Security professionals collaborate with Microsoft continuously to help protect customers. With the help of their valuable reports, Microsoft has identified a list of known applications that an attacker could potentially use to bypass Windows Defender Device Guard code integrity policies. Depending on the context, you may want to block these applications. To view this list of applications and for use case examples, such as disabling msbuild.exe, see [Deploy code integrity policies: steps](https://technet.microsoft.com/itpro/windows/keep-secure/deploy-code-integrity-policies-steps).
+    Security professionals collaborate with Microsoft continuously to help protect customers. With the help of their valuable reports, Microsoft has identified a list of known applications that an attacker could potentially use to bypass Windows Defender Application Control. Depending on the context, you may want to block these applications. To view this list of applications and for use case examples, such as disabling msbuild.exe, see [Deploy Windows Defender Application Control: steps](deploy-code-integrity-policies-steps.md).
 
 
 
 
 
 
-4.  **Identify LOB applications that are currently unsigned**. Although requiring signed code (through code integrity policies) protects against many threats, your organization might use unsigned LOB applications, for which the process of signing might be difficult. You might also have applications that are signed, but you want to add a secondary signature to them. If so, identify these applications, because you will need to create a catalog file for them. For a basic description of catalog files, see the table in [Introduction to Windows Defender Device Guard: virtualization-based security and code integrity policies](introduction-to-device-guard-virtualization-based-security-and-code-integrity-policies.md). For more background information about catalog files, see [Reviewing your applications: application signing and catalog files](requirements-and-deployment-planning-guidelines-for-device-guard.md#reviewing-your-applications-application-signing-and-catalog-files).
+4.  **Identify LOB applications that are currently unsigned**. Although requiring signed code (through WDAC) protects against many threats, your organization might use unsigned LOB applications, for which the process of signing might be difficult. You might also have applications that are signed, but you want to add a secondary signature to them. If so, identify these applications, because you will need to create a catalog file for them. For a basic description of catalog files, see the table in [Introduction to Windows Defender Device Guard: virtualization-based security and Windows Defender Application Control](introduction-to-device-guard-virtualization-based-security-and-code-integrity-policies.md). For more background information about catalog files, see [Reviewing your applications: application signing and catalog files](requirements-and-deployment-planning-guidelines-for-device-guard.md#reviewing-your-applications-application-signing-and-catalog-files).
 
 ## Getting started on the deployment process
 
-1.  **Optionally, create a signing certificate for code integrity policies**. As you deploy code integrity policies, you might need to sign catalog files or code integrity policies internally. To do this, you will either need a publicly issued code signing certificate (that you purchase) or an internal CA. If you choose to use an internal CA, you will need to create a code signing certificate. For more information, see [Optional: Create a code signing certificate for code integrity policies](optional-create-a-code-signing-certificate-for-code-integrity-policies.md).
+1.  **Optionally, create a signing certificate for Windows Defender Application Control**. As you deploy WDAC, you might need to sign catalog files or WDAC policies internally. To do this, you will either need a publicly issued code signing certificate (that you purchase) or an internal CA. If you choose to use an internal CA, you will need to create a code signing certificate. For more information, see [Optional: Create a code signing certificate for Windows Defender Application Control](optional-create-a-code-signing-certificate-for-code-integrity-policies.md).
 
-2.  **Create code integrity policies from “golden” computers**. When you have identified departments or roles that use distinctive or partly-distinctive sets of hardware and software, you can set up “golden” computers containing that software and hardware. In this respect, creating and managing code integrity policies to align with the needs of roles or departments can be similar to managing corporate images. From each “golden” computer, you can create a code integrity policy, and decide how to manage that policy. You can merge code integrity policies to create a broader policy or a master policy, or you can manage and deploy each policy individually. For more information, see:
+2.  **Create WDAC policies from “golden” computers**. When you have identified departments or roles that use distinctive or partly-distinctive sets of hardware and software, you can set up “golden” computers containing that software and hardware. In this respect, creating and managing WDAC policies to align with the needs of roles or departments can be similar to managing corporate images. From each “golden” computer, you can create a WDAC policy, and decide how to manage that policy. You can merge WDAC policies to create a broader policy or a master policy, or you can manage and deploy each policy individually. For more information, see:
-    - [Deploy code integrity policies: policy rules and file rules](deploy-code-integrity-policies-policy-rules-and-file-rules.md)
+    - [Deploy Windows Defender Application Control: policy rules and file rules](deploy-code-integrity-policies-policy-rules-and-file-rules.md)
-    - [Deploy code integrity policies: steps](deploy-code-integrity-policies-steps.md)<br>
+    - [Deploy Windows Defender Application Control: steps](deploy-code-integrity-policies-steps.md)<br>
 
-3.  **Audit the code integrity policy and capture information about applications that are outside the policy**. We recommend that you use “audit mode” to carefully test each code integrity policy before you enforce it. With audit mode, no application is blocked—the policy just logs an event whenever an application outside the policy is started. Later, you can expand the policy to allow these applications, as needed. For more information, see [Audit code integrity policies](deploy-code-integrity-policies-steps.md#audit-code-integrity-policies).
+3.  **Audit the WDAC policy and capture information about applications that are outside the policy**. We recommend that you use “audit mode” to carefully test each WDAC policy before you enforce it. With audit mode, no application is blocked—the policy just logs an event whenever an application outside the policy is started. Later, you can expand the policy to allow these applications, as needed. For more information, see [Audit Windows Defender Application Control policies](deploy-code-integrity-policies-steps.md#audit-windows-defender-application-control-policies).
 
-4.  **Create a “catalog file” for unsigned LOB applications**. Use the Package Inspector tool to create and sign a catalog file for your unsigned LOB applications. For more information, review step 4 **Identify LOB applications that are currently unsigned**, earlier in this list, and see [Deploy catalog files to support code integrity policies](deploy-catalog-files-to-support-code-integrity-policies.md). In later steps, you can merge the catalog file's signature into your code integrity policy, so that applications in the catalog will be allowed by the policy. 
+4.  **Create a “catalog file” for unsigned LOB applications**. Use the Package Inspector tool to create and sign a catalog file for your unsigned LOB applications. For more information, review step 4 **Identify LOB applications that are currently unsigned**, earlier in this list, and see [Deploy catalog files to support Windows Defender Application Control](deploy-catalog-files-to-support-code-integrity-policies.md). In later steps, you can merge the catalog file's signature into your WDAC policy, so that applications in the catalog will be allowed by the policy. 
 
-6.  **Capture needed policy information from the event log, and merge information into the existing policy as needed**. After a code integrity policy has been running for a time in audit mode, the event log will contain information about applications that are outside the policy. To expand the policy so that it allows for these applications, use Windows PowerShell commands to capture the needed policy information from the event log, and then merge that information into the existing policy. You can merge code integrity policies from other sources also, for flexibility in how you create your final code integrity policies. For more information, see:
+6.  **Capture needed policy information from the event log, and merge information into the existing policy as needed**. After a WDAC policy has been running for a time in audit mode, the event log will contain information about applications that are outside the policy. To expand the policy so that it allows for these applications, use Windows PowerShell commands to capture the needed policy information from the event log, and then merge that information into the existing policy. You can merge WDAC policies from other sources also, for flexibility in how you create your final WDAC policies. For more information, see:
-    - [Create a code integrity policy that captures audit information from the event log](deploy-code-integrity-policies-steps.md#create-a-code-integrity-policy-that-captures-audit-information-from-the-event-log)
+    - [Create a Windows Defender Application Control policy that captures audit information from the event log](deploy-code-integrity-policies-steps.md#create-a-windows-defender-application-control-policy-that-captures-audit-information-from-the-event-log)
-    - [Merge code integrity policies](deploy-code-integrity-policies-steps.md#merge-code-integrity-policies)<br>
+    - [Merge Windows Defender Application Control policies](deploy-code-integrity-policies-steps.md#merge-windows-defender-application-control-policies)<br>
 
-7.  **Deploy code integrity policies and catalog files**. After you confirm that you have completed all the preceding steps, you can begin deploying catalog files and taking code integrity policies out of auditing mode. We strongly recommend that you begin this process with a test group of users. This provides a final quality-control validation before you deploy the catalog files and code integrity policies more broadly. For more information, see:
+7.  **Deploy WDAC policies and catalog files**. After you confirm that you have completed all the preceding steps, you can begin deploying catalog files and taking WDAC policies out of auditing mode. We strongly recommend that you begin this process with a test group of users. This provides a final quality-control validation before you deploy the catalog files and WDAC policies more broadly. For more information, see:
-    - [Enforce code integrity policies](deploy-code-integrity-policies-steps.md#enforce-code-integrity-policies)
+    - [Enforce Windows Defender Application Control policies](deploy-code-integrity-policies-steps.md#enforce-windows-defender-application-control-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>
+    - [Deploy and manage Windows Defender Application Control with Group Policy](deploy-code-integrity-policies-steps.md#deploy-and-manage-windows-defender-application-control-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-windows-defender-device-guard-features-help-protect-against-threats). 
+8.  **Enable desired virtualization-based security (VBS) features**. Hardware-based security features—also called virtualization-based security (VBS) features—strengthen the protections offered by Windows Defender Application Control, 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).
 
-    For information about enabling VBS features, see [Deploy Windows Defender Device Guard: enable virtualization-based security](deploy-device-guard-enable-virtualization-based-security.md).
+    For information about enabling VBS features, see [Enable virtualization-based protection of code integrity](deploy-device-guard-enable-virtualization-based-security.md).
 
 <br />

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

@@ -21,9 +21,9 @@ The information in this article is intended for IT professionals, and provides a
 
 ## Hardware, firmware, and software requirements for Windows Defender Device Guard
 
-To deploy Windows Defender Device Guard in a way that uses all of its virtualization-based security (VBS) features, the computers you are protecting must meet certain hardware, firmware, and software requirements. However, computers lacking some of the hardware and firmware requirements will still receive some protection when you deploy code integrity policies—the difference is that those computers will not be as hardened against certain threats. 
+To deploy Windows Defender Device Guard in a way that uses all of its virtualization-based security (VBS) features, the computers you are protecting must meet certain hardware, firmware, and software requirements. However, computers lacking some of the hardware and firmware requirements will still receive some protection when you deploy 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. For an outline of how VBS-related hardware strengthens the hardening offered by Windows Defender Device Guard, see [Introduction to Windows Defender Device Guard: virtualization-based security and code integrity policies](introduction-to-device-guard-virtualization-based-security-and-code-integrity-policies.md).
+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. For an outline of how VBS-related hardware strengthens the hardening offered by Windows Defender Device Guard, see [Introduction to Windows Defender Device Guard: virtualization-based security and Windows Defender Application Control](introduction-to-device-guard-virtualization-based-security-and-code-integrity-policies.md).
 
 You can deploy Windows Defender Device Guard in phases, and plan these phases in relation to the computer purchases you plan for your next hardware refresh.
 
@@ -33,7 +33,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-windows-defender-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: Windows Defender Application Control (WDAC), virtualization-based protection of code integrity, 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-windows-defender-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
@@ -45,7 +45,7 @@ The following tables provide more information about the hardware, firmware, and
 | 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](http://msdn.microsoft.com/library/windows/hardware/dn932805.aspx#system-fundamentals-firmware-uefisecureboot) | 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](http://msdn.microsoft.com/library/windows/hardware/dn932805.aspx#system-fundamentals-firmware-uefisecureboot). | 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://msdn.microsoft.com/library/windows/hardware/mt589732(v=vs.85).aspx).| [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 Windows Defender Device Guard is supported in this configuration.</p></blockquote> | Support for VBS and for management features that simplify configuration of Windows Defender Device Guard. |
+| 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**&nbsp;&nbsp;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.
 
@@ -87,9 +87,9 @@ Typically, deployment of Windows Defender Device Guard happens best in phases, r
 
 | **Type of device**                 | **How Windows Defender Device Guard relates to this type of device**  | **Windows Defender Device Guard components that you can use to protect this kind of device**    |
 |------------------------------------|------------------------------------------------------|--------------------------------------------------------------------------------|
-| **Fixed-workload devices**: Perform same tasks every day.<br>Lists of approved applications rarely change.<br>Examples: kiosks, point-of-sale systems, call center computers. | Windows Defender Device Guard can be deployed fully, and deployment and ongoing administration are relatively straightforward.<br>After Windows Defender Device Guard deployment, only approved applications can run. This is because of protections offered by the Hypervisor Code Integrity (HVCI) service. | - VBS (hardware-based) protections, enabled.<br><br>• Code integrity policies in enforced mode, with UMCI enabled. |
+| **Fixed-workload devices**: Perform same tasks every day.<br>Lists of approved applications rarely change.<br>Examples: kiosks, point-of-sale systems, call center computers. | Windows Defender Device Guard can be deployed fully, and deployment and ongoing administration are relatively straightforward.<br>After Windows Defender Device Guard deployment, only approved applications can run. This is because of protections offered by WDAC. | - VBS (hardware-based) protections, enabled.<br><br>• WDAC in enforced mode, with UMCI enabled. |
-| **Fully managed devices**: Allowed software is restricted by IT department.<br>Users can request additional software, or install from a list of applications provided by IT department.<br>Examples: locked-down, company-owned desktops and laptops. | An initial baseline code integrity policy can be established and enforced. Whenever the IT department approves additional applications, it will update the code integrity policy and (for unsigned LOB applications) the catalog.<br>Code integrity policies are supported by the HVCI service. | - VBS (hardware-based) protections, enabled.<br><br>• Code integrity policies in enforced mode, with UMCI enabled. |
+| **Fully managed devices**: Allowed software is restricted by IT department.<br>Users can request additional software, or install from a list of applications provided by IT department.<br>Examples: locked-down, company-owned desktops and laptops. | An initial baseline WDAC policy can be established and enforced. Whenever the IT department approves additional applications, it will update the WDAC policy and (for unsigned LOB applications) the catalog.<br>WDAC policies are supported by the HVCI service. | - VBS (hardware-based) protections, enabled.<br><br>• WDAC in enforced mode, with UMCI enabled. |
-| **Lightly managed devices**: Company-owned, but users are free to install software.<br>Devices are required to run organization's antivirus solution and client management tools. | Windows Defender Device Guard can be used to help protect the kernel, and to monitor (audit) for problem applications rather than limiting the applications that can be run. | - VBS (hardware-based) protections, enabled. When enabled with a code integrity policy in audit mode only, VBS means the hypervisor helps enforce the default kernel-mode code integrity policy, which protects against unsigned drivers or system files.<br><br>• Code integrity policies, with UMCI enabled, but running in audit mode only. This means applications are not blocked—the policy just logs an event whenever an application outside the policy is started.  |
+| **Lightly managed devices**: Company-owned, but users are free to install software.<br>Devices are required to run organization's antivirus solution and client management tools. | Windows Defender Device Guard can be used to help protect the kernel, and to monitor (audit) for problem applications rather than limiting the applications that can be run. | - VBS (hardware-based) protections, enabled. When enabled with a WDAC policy in audit mode only, VBS means the hypervisor helps enforce the default kernel-mode code integrity policy, which protects against unsigned drivers or system files.<br><br>• WDAC, with UMCI enabled, but running in audit mode only. This means applications are not blocked—the policy just logs an event whenever an application outside the policy is started.  |
 | **Bring Your Own Device**: Employees are allowed to bring their own devices, and also use those devices away from work. | Windows Defender Device Guard does not apply. Instead, you can explore other hardening and security features with MDM-based conditional access solutions, such as Microsoft Intune. | N/A | 
 
 ## Windows Defender Device Guard deployment in virtual machines
@@ -111,9 +111,9 @@ Windows Defender Device Guard protects against malware running in the guest virt
 
 ## Reviewing your applications: application signing and catalog files 
 
-Typically, code integrity policies are configured to use the application's signing certificate as part or all of what identifies the application as trusted. This means that applications must either use embedded signing—where the signature is part of the binary—or catalog signing, where you generate a “catalog file” from the applications, sign it, and through the signed catalog file, configure the code integrity policy to recognize the applications as signed.
+Typically, WDAC policies are configured to use the application's signing certificate as part or all of what identifies the application as trusted. This means that applications must either use embedded signing—where the signature is part of the binary—or catalog signing, where you generate a “catalog file” from the applications, sign it, and through the signed catalog file, configure the WDAC policy to recognize the applications as signed.
 
-Catalog files can be very useful for unsigned LOB applications that cannot easily be given an embedded signature. However, catalogs need to be updated each time an application is updated. In contrast, with embedded signing, your code integrity policies typically do not have to be updated when an application is updated. For this reason, if code-signing is or can be included in your in-house application development process, it can simplify the management of your code integrity policies (compared to using catalog signing).
+Catalog files can be very useful for unsigned LOB applications that cannot easily be given an embedded signature. However, catalogs need to be updated each time an application is updated. In contrast, with embedded signing, your WDAC policies typically do not have to be updated when an application is updated. For this reason, if code-signing is or can be included in your in-house application development process, it can simplify the management of WDAC (compared to using catalog signing).
 
 To obtain signed applications or embed signatures in your in-house applications, you can choose from a variety of methods:
 
@@ -131,27 +131,27 @@ To use catalog signing, you can choose from the following options:
 
 ### Catalog files
 
-Catalog files (which you can create in Windows 10 with a tool called Package Inspector) contain information about all deployed and executed binary files associated with your trusted but unsigned applications. When you create catalog files, you can also include signed applications for which you do not want to trust the signer but rather the specific application. After creating a catalog, you must sign the catalog file itself by using enterprise public key infrastructure (PKI), or a purchased code signing certificate. Then you can distribute the catalog, so that your trusted applications can be handled by code integrity policies in the same way as any other signed application.
+Catalog files (which you can create in Windows 10 with a tool called Package Inspector) contain information about all deployed and executed binary files associated with your trusted but unsigned applications. When you create catalog files, you can also include signed applications for which you do not want to trust the signer but rather the specific application. After creating a catalog, you must sign the catalog file itself by using enterprise public key infrastructure (PKI), or a purchased code signing certificate. Then you can distribute the catalog, so that your trusted applications can be handled by WDAC in the same way as any other signed application.
 
 Catalog files are simply Secure Hash Algorithm 2 (SHA2) hash lists of discovered binaries. These binaries’ hash values are updated each time an application is updated, which requires the catalog file to be updated also.
 
-After you have created and signed your catalog files, you can configure your code integrity policies to trust the signer or signing certificate of those files.
+After you have created and signed your catalog files, you can configure your WDAC policies to trust the signer or signing certificate of those files.
 
 > **Note**&nbsp;&nbsp;Package Inspector only works on operating systems that support Windows Defender Device Guard, such as Windows 10 Enterprise, Windows 10 Education, Windows 2016 Server, or Windows Enterprise IoT.
 
-For information about how creating catalog files fits into Windows Defender Device Guard deployment, see [Planning and getting started on the Windows Defender Device Guard deployment process](planning-and-getting-started-on-the-device-guard-deployment-process.md). For procedures for working with catalog files, see [Deploy catalog files to support code integrity policies](deploy-catalog-files-to-support-code-integrity-policies.md).
+For information about how creating catalog files fits into Windows Defender Device Guard deployment, see [Planning and getting started on the Windows Defender Device Guard deployment process](planning-and-getting-started-on-the-device-guard-deployment-process.md). For procedures for working with catalog files, see [Deploy catalog files to support Windows Defender Application Control](deploy-catalog-files-to-support-code-integrity-policies.md).
 
-## Code integrity policy formats and signing
+## Windows Defender Application Control policy formats and signing
 
-When you generate a code integrity policy, you are generating a binary-encoded XML document that includes configuration settings for both the User and Kernel-modes of Windows 10 Enterprise, along with restrictions on Windows 10 script hosts. You can view your original XML document in a text editor, for example if you want to check the rule options that are present in the **&lt;Rules&gt;** section of the file.
+When you generate a WDAC policy, you are generating a binary-encoded XML document that includes configuration settings for both the User and Kernel-modes of Windows 10 Enterprise, along with restrictions on Windows 10 script hosts. You can view your original XML document in a text editor, for example if you want to check the rule options that are present in the **&lt;Rules&gt;** section of the file.
 
-We recommend that you keep the original XML file for use when you need to merge the code integrity policy with another policy or update its rule options. For deployment purposes, the file is converted to a binary format, which can be done using a simple Windows PowerShell command.
+We recommend that you keep the original XML file for use when you need to merge the WDAC policy with another policy or update its rule options. For deployment purposes, the file is converted to a binary format, which can be done using a simple Windows PowerShell command.
 
-When the code integrity policy is deployed, it restricts the software that can run on a device. The XML document can be signed, helping to add additional protection against administrative users changing or removing the policy. 
+When the WDAC policy is deployed, it restricts the software that can run on a device. The XML document can be signed, helping to add additional protection against administrative users changing or removing the policy. 
 
 ## Related topics
 
 - [Planning and getting started on the Windows Defender Device Guard deployment process](planning-and-getting-started-on-the-device-guard-deployment-process.md)
-- [Deploy Windows Defender Device Guard: deploy code integrity policies](deploy-device-guard-deploy-code-integrity-policies.md)
+- [Deploy Windows Defender Application Control](deploy-device-guard-deploy-code-integrity-policies.md)
 
 

windows/threat-protection/windows-information-protection/create-wip-policy-using-mam-intune-azure.md

@@ -72,10 +72,12 @@ After you’ve set up Intune for your organization, you must create a WIP-specif
     >Optionally, you can also add your apps and set your settings from the **Add a policy** blade, but for the purposes of this documentation, we recommend instead that you create the policy first, and then use the subsequent menus that become available.
 
 ## Add apps to your Allowed apps list
-During the policy-creation process in Intune, you can choose the apps you want to give access to your enterprise data through WIP. Apps included in this list can protect data on behalf of the enterprise and are restricted from copying or moving enterprise data to unprotected apps.
+During the policy-creation process in Intune, you can choose the apps you want to allow, as well as deny, access to your enterprise data through WIP. Apps included in this list can protect data on behalf of the enterprise and are restricted from copying or moving enterprise data to unprotected apps.
 
 The steps to add your apps are based on the type of template being applied. You can add a recommended app, a store app (also known as a Universal Windows Platform (UWP) app), or a signed Windows desktop app. You can also import a list of approved apps or add exempt apps.
 
+In addition, you can create an app deny list related to the policy based on an **action** value. The action can be either **Allow** or **Deny**. When you specify the deny action for an app using the policy, corporate access is denied to the app.
+
 >[!Important]
 >Enlightened apps are expected to prevent enterprise data from going to unprotected network locations and to avoid encrypting personal data. On the other hand, WIP-unaware apps might not respect the corporate network boundary, and WIP-unaware apps will encrypt all files they create or modify. This means that they could encrypt personal data and cause data loss during the revocation process.<br><br>Care must be taken to get a support statement from the software provider that their app is safe with WIP before adding it to your **Allowed apps** list. If you don’t get this statement, it’s possible that you could experience app compatibility issues due to an app losing the ability to access a necessary file after revocation.