Merge pull request #6784 from MicrosoftDocs/v-smandalika-5694287-B22

windows - v-smandalika - 5694287 - Acrolinx Enhancement effort

windows/security/threat-protection/windows-defender-application-control/configure-wdac-managed-installer.md

@@ -31,7 +31,7 @@ ms.technology: windows-sec
 
 ## Using fsutil to query SmartLocker EA
 
-Customers using Windows Defender Application Control (WDAC) with Managed Installer (MI) or Intelligent Security Graph enabled can use fsutil to determine whether a file was allowed to run by one of these features. This can be achieved by querying the EAs on a file using fsutil and looking for the KERNEL.SMARTLOCKER.ORIGINCLAIM EA. The presence of this EA indicates that either MI or ISG allowed the file to run. This can be used in conjunction with enabling the MI and ISG logging events.
+Customers using Windows Defender Application Control (WDAC) with Managed Installer (MI) or Intelligent Security Graph enabled can use fsutil to determine whether a file was allowed to run by one of these features. This verification can be done by querying the EAs on a file using fsutil and looking for the KERNEL.SMARTLOCKER.ORIGINCLAIM EA. The presence of this EA indicates that either MI or ISG allowed the file to run. This EA's presence can be used in conjunction with enabling the MI and ISG logging events.
 
 **Example:**
 

windows/security/threat-protection/windows-defender-application-control/create-code-signing-cert-for-windows-defender-application-control.md

@@ -1,6 +1,6 @@
 ---
 title: Create a code signing cert for Windows Defender Application Control (Windows)
-description: Learn how to set up a publicly-issued code signing certificate, so you can sign catalog files or WDAC policies internally.
+description: Learn how to set up a publicly issued code signing certificate, so you can sign catalog files or WDAC policies internally.
 keywords: security, malware
 ms.assetid: 8d6e0474-c475-411b-b095-1c61adb2bdbb
 ms.prod: m365-security
@@ -29,11 +29,11 @@ ms.technology: windows-sec
 >[!NOTE]
 >Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](feature-availability.md).
 
-As you deploy Windows Defender Application Control (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 or an internal CA. If you have purchased a code signing certificate, you can skip this topic and instead follow other topics listed in the [Windows Defender Application Control Deployment Guide](windows-defender-application-control-deployment-guide.md). 
+As you deploy Windows Defender Application Control (WDAC), you might need to sign catalog files or WDAC policies internally. To do this signature, you'll either need a publicly issued code signing certificate or an internal CA. If you've purchased a code-signing certificate, you can skip this topic and instead follow other topics listed in the [Windows Defender Application Control Deployment Guide](windows-defender-application-control-deployment-guide.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. 
-ECDSA is not supported.
+ECDSA isn't supported.
 
 1.  Open the Certification Authority Microsoft Management Console (MMC) snap-in, and then select your issuing CA.
 
@@ -75,7 +75,7 @@ When this certificate template has been created, you must publish it to the CA p
 
     Figure 3. Select the new certificate template to issue
 
-    A list of available templates to issue appears, including the template you just created.
+    A list of available templates to issue appears, including the template you created.
 
 2.  Select the WDAC Catalog signing certificate, and then click **OK**.
 
@@ -100,7 +100,7 @@ Now that the template is available to be issued, you must request one from the c
 >[!NOTE]
 >If a certificate manager is required to approve any issued certificates and you selected to require management approval on the template, the request will need to be approved in the CA before it will be issued to the client.
 
-This certificate must be installed in the user's personal store on the computer that will be signing the catalog files and code integrity policies. If the signing is going to be taking place on the computer on which you just requested the certificate, exporting the certificate to a .pfx file will not be required because it already exists in your personal store. If you are signing on another computer, you will need to export the .pfx certificate with the necessary keys and properties. To do so, complete the following steps:
+This certificate must be installed in the user's personal store on the computer that will be signing the catalog files and code integrity policies. If the signing is going to be taking place on the computer on which you just requested the certificate, exporting the certificate to a .pfx file won't be required because it already exists in your personal store. If you're signing on another computer, you'll need to export the .pfx certificate with the necessary keys and properties. To do so, complete the following steps:
 
 1.  Right-click the certificate, point to **All Tasks**, and then click **Export**.
 

windows/security/threat-protection/windows-defender-application-control/create-initial-default-policy.md

@@ -37,7 +37,7 @@ The policy file is converted to binary format when it gets created so that Windo
 
 ## 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. Windows Defender Application Control 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 [WDAC Design Guide](windows-defender-application-control-design-guide.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 more company assets. Windows Defender Application Control 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 more WDAC policies based on what should be allowed to be installed and run and for whom. For more information on doing this assessment, see the [WDAC Design Guide](windows-defender-application-control-design-guide.md).
 
 Optionally, WDAC can align with your software catalog and 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.
 
@@ -48,12 +48,12 @@ If you plan to use an internal CA to sign catalog files or WDAC policies, see th
 
 Each installed software application should be validated as trustworthy before you create a policy.
 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 to run scripts.
+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 don't want to run scripts.
 You can remove or disable such software on the reference computer.
 
 To create a Windows Defender Application Control policy, copy each of the following commands into an elevated Windows PowerShell session, in order:
 
-1. Initialize variables that you will use.
+1. Initialize variables that you'll use.
 
    ```powershell
    $PolicyPath=$env:userprofile+"\Desktop\"
@@ -83,7 +83,7 @@ To create a Windows Defender Application Control policy, copy each of the follow
    ConvertFrom-CIPolicy $WDACPolicy $WDACPolicyBin
    ```
 
-After you complete these steps, the WDAC binary file ($WDACPolicyBin) and original .xml file ($WDACPolicy) will be available on your desktop. You can use the binary file as a WDAC policy or sign it for additional security.
+After you complete these steps, the WDAC binary file ($WDACPolicyBin) and original .xml file ($WDACPolicy) will be available on your desktop. You can use the binary file as a WDAC policy or sign it for more security.
 
 > [!NOTE]
 > 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.md).

windows/security/threat-protection/windows-defender-application-control/create-wdac-policy-for-fully-managed-devices.md

@@ -30,16 +30,16 @@ ms.technology: windows-sec
 >[!NOTE]
 >Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](feature-availability.md).
 
-This section outlines the process to create a Windows Defender Application Control (WDAC) policy for **fully managed devices** within an organization. The key difference between this scenario and [lightly managed devices](create-wdac-policy-for-lightly-managed-devices.md) is that all software deployed to a fully managed device is managed by IT and users of the device cannot install arbitrary apps. Ideally, all apps are deployed using a software distribution solution, such as Microsoft Endpoint Manager. Additionally, users on fully managed devices should ideally run as standard user and only authorized IT pros have administrative access.
+This section outlines the process to create a Windows Defender Application Control (WDAC) policy for **fully managed devices** within an organization. The key difference between this scenario and [lightly managed devices](create-wdac-policy-for-lightly-managed-devices.md) is that all software deployed to a fully managed device is managed by IT and users of the device can't install arbitrary apps. Ideally, all apps are deployed using a software distribution solution, such as Microsoft Endpoint Manager. Additionally, users on fully managed devices should ideally run as standard user and only authorized IT pros have administrative access.
 
 > [!NOTE]
 > Some of the Windows Defender Application Control options described in this topic are only available on Windows 10 version 1903 and above, or Windows 11. When using this topic to plan your own organization's WDAC policies, consider whether your managed clients can use all or some of these features and assess the impact for any features that may be unavailable on your clients. You may need to adapt this guidance to meet your specific organization's needs.
 
-As described in [common Windows Defender Application Control deployment scenarios](types-of-devices.md), we will use the example of **Lamna Healthcare Company (Lamna)** to illustrate this scenario. Lamna is attempting to adopt stronger application policies, including the use of application control to prevent unwanted or unauthorized applications from running on their managed devices.
+As described in [common Windows Defender Application Control deployment scenarios](types-of-devices.md), we'll use the example of **Lamna Healthcare Company (Lamna)** to illustrate this scenario. Lamna is attempting to adopt stronger application policies, including the use of application control to prevent unwanted or unauthorized applications from running on their managed devices.
 
 **Alice Pena** is the IT team lead tasked with the rollout of WDAC.
 
-Alice previously created a policy for the organization's lightly managed devices. Some devices, however, are more tightly managed and can benefit from a more constrained policy. In particular, certain job functions such as administrative staff and firstline workers are not granted administrator level access to their devices. Similarly, shared kiosks are configured only with a managed set of apps and all users of the device except IT run as standard user. On these devices, all apps are deployed and installed by IT.
+Alice previously created a policy for the organization's lightly managed devices. Some devices, however, are more tightly managed and can benefit from a more constrained policy. In particular, certain job functions such as administrative staff and firstline workers aren't granted administrator level access to their devices. Similarly, shared kiosks are configured only with a managed set of apps and all users of the device except IT run as standard user. On these devices, all apps are deployed and installed by IT.
 
 ## Define the "circle-of-trust" for fully managed devices
 
@@ -51,26 +51,26 @@ Alice identifies the following key factors to arrive at the "circle-of-trust" fo
 - Sometimes, IT staff install apps directly to these devices without using Configuration Manager;
 - All users except IT are standard users on these devices.
 
-Alice's team develops a simple console application, called *LamnaITInstaller.exe*, which will become the authorized way for IT staff to install apps directly to devices. *LamnaITInstaller.exe* allows the IT pro to launch another process, such as an app installer. Alice will configure *LamnaITInstaller.exe* as an additional managed installer for WDAC and allows her to remove the need for filepath rules.
+Alice's team develops a simple console application, called *LamnaITInstaller.exe*, which will become the authorized way for IT staff to install apps directly to devices. *LamnaITInstaller.exe* allows the IT pro to launch another process, such as an app installer. Alice will configure *LamnaITInstaller.exe* as an extra managed installer for WDAC and allows her to remove the need for filepath rules.
 
 Based on the above, Alice defines the pseudo-rules for the policy:
 
 1. **“Windows works”** rules that authorize:
    - Windows
-   - WHQL (3rd party kernel drivers)
+   - WHQL (third-party kernel drivers)
    - Windows Store signed apps
 
 2. **"MEMCM works”** rules that include signer and hash rules for Configuration Manager components to properly function.
 3. **Allow Managed Installer** (Configuration Manager and *LamnaITInstaller.exe* configured as a managed installer)
 
-The critical differences between this set of pseudo-rules and those defined for Lamna's [lightly managed devices](create-wdac-policy-for-lightly-managed-devices.md#define-the-circle-of-trust-for-lightly-managed-devices) are:
+The critical differences between this set of pseudo-rules and those pseudo-rules defined for Lamna's [lightly managed devices](create-wdac-policy-for-lightly-managed-devices.md#define-the-circle-of-trust-for-lightly-managed-devices) are:
 
 - Removal of the Intelligent Security Graph (ISG) option; and
 - Removal of filepath rules.
 
 ## Create a custom base policy using an example WDAC base policy
 
-Having defined the "circle-of-trust", Alice is ready to generate the initial policy for Lamna's fully-managed devices. She decides to use Configuration Manager to create the initial base policy and then customize it to meet Lamna's needs.
+Having defined the "circle-of-trust", Alice is ready to generate the initial policy for Lamna's fully managed devices and decides to use Configuration Manager to create the initial base policy and then customize it to meet Lamna's needs.
 
 Alice follows these steps to complete this task:
 
@@ -113,7 +113,7 @@ Alice follows these steps to complete this task:
       Set-RuleOption -FilePath $LamnaPolicy -Option 19 # Dynamic Code Security
       ```
 
-6. If appropriate, add additional signer or file rules to further customize the policy for your organization.
+6. If appropriate, add more signer or file rules to further customize the policy for your organization.
 
 7. Use [ConvertFrom-CIPolicy](/powershell/module/configci/convertfrom-cipolicy) to convert the Windows Defender Application Control policy to a binary format:
 
@@ -134,7 +134,7 @@ At this point, Alice now has an initial policy that is ready to deploy in audit
 Alice has defined a policy for Lamna's fully managed devices that makes some trade-offs between security and manageability for apps. Some of the trade-offs include:
 
 - **Users with administrative access**<br>
-    Although applying to fewer users, Lamna still allows some IT staff to log in to its fully managed devices as administrator. This allows these admin users (or malware running with the user's privileges) to modify or remove altogether the WDAC policy applied on the device. Additionally, administrators can configure any app they wish to operate as a managed installer that would allow them to gain persistent app authorization for whatever apps or binaries they wish.
+    Although applying to fewer users, Lamna still allows some IT staff to sign in to its fully managed devices as administrator. This privilege allows these users (or malware running with the user's privileges) to modify or remove altogether the WDAC policy applied on the device. Additionally, administrators can configure any app they wish to operate as a managed installer that would allow them to gain persistent app authorization for whatever apps or binaries they wish.
 
    Possible mitigations:
   - Use signed WDAC policies and UEFI BIOS access protection to prevent tampering of WDAC policies.

windows/security/threat-protection/windows-defender-application-control/create-wdac-policy-for-lightly-managed-devices.md

@@ -35,11 +35,11 @@ This section outlines the process to create a Windows Defender Application Contr
 > [!NOTE]
 > Some of the Windows Defender Application Control options described in this topic are only available on Windows 10 version 1903 and above, or Windows 11. When using this topic to plan your own organization's WDAC policies, consider whether your managed clients can use all or some of these features and assess the impact for any features that may be unavailable on your clients. You may need to adapt this guidance to meet your specific organization's needs.
 
-As in the [previous topic](types-of-devices.md), we will use the example of **Lamna Healthcare Company (Lamna)** to illustrate this scenario. Lamna is attempting to adopt stronger application policies, including the use of application control to prevent unwanted or unauthorized applications from running on their managed devices.
+As in the [previous topic](types-of-devices.md), we'll use the example of **Lamna Healthcare Company (Lamna)** to illustrate this scenario. Lamna is attempting to adopt stronger application policies, including the use of application control to prevent unwanted or unauthorized applications from running on their managed devices.
 
-**Alice Pena** is the IT team lead tasked with the rollout of WDAC. Recognizing where Lamna is starting from, with loose application usage policies and a culture of maximum app flexibility for users, Alice knows that she will need to take an incremental approach to application control and use different policies for different workloads.
+**Alice Pena** is the IT team lead tasked with the rollout of WDAC. Recognizing where Lamna is starting from, with loose application usage policies and a culture of maximum app flexibility for users, Alice knows that she'll need to take an incremental approach to application control and use different policies for different workloads.
 
-For the majority of users and devices, Alice wants to create an initial policy that is as relaxed as possible in order to minimize user productivity impact, while still providing security value.
+For most users and devices, Alice wants to create an initial policy that is as relaxed as possible in order to minimize user productivity impact, while still providing security value.
 
 ## Define the "circle-of-trust" for lightly managed devices
 
@@ -49,16 +49,16 @@ Alice identifies the following key factors to arrive at the "circle-of-trust" fo
 - All clients are managed by Microsoft Endpoint Manager either with Configuration Manager or with Intune.
 - Some, but not all, apps are deployed using Configuration Manager;
 - Most users are local administrators on their devices;
-- Some teams may need additional rules to authorize specific apps that don't apply generally to all other users.
+- Some teams may need more rules to authorize specific apps that don't apply generally to all other users.
 
 Based on the above, Alice defines the pseudo-rules for the policy:
 
 1. **“Windows works”** rules that authorize:
    - Windows
-   - WHQL (3rd party kernel drivers)
+   - WHQL (third-party kernel drivers)
    - Windows Store signed apps
 
-2. **"MEMCM works”** rules which include signer and hash rules for Configuration Manager components to properly function.
+2. **"MEMCM works”** rules that include signer and hash rules for Configuration Manager components to properly function.
 3. **Allow Managed Installer** (Configuration Manager configured as a managed installer)
 4. **Allow Intelligent Security Graph (ISG)** (reputation-based authorization)
 5. **Admin-only path rules** for the following locations:
@@ -68,7 +68,7 @@ Based on the above, Alice defines the pseudo-rules for the policy:
 
 ## Create a custom base policy using an example WDAC base policy
 
-Having defined the "circle-of-trust", Alice is ready to generate the initial policy for Lamna's lightly managed devices. She decides to use Configuration Manager to create the initial base policy and then customize it to meet Lamna's needs.
+Having defined the "circle-of-trust", Alice is ready to generate the initial policy for Lamna's lightly managed devices. Alice decides to use Configuration Manager to create the initial base policy and then customize it to meet Lamna's needs.
 
 Alice follows these steps to complete this task:
 
@@ -121,7 +121,7 @@ Alice follows these steps to complete this task:
       Merge-CIPolicy -OutputFilePath $LamnaPolicy -PolicyPaths $LamnaPolicy -Rules $PathRules
       ```
 
-7. If appropriate, add additional signer or file rules to further customize the policy for your organization.
+7. If appropriate, add more signer or file rules to further customize the policy for your organization.
 
 8. Use [ConvertFrom-CIPolicy](/powershell/module/configci/convertfrom-cipolicy) to convert the WDAC policy to a binary format:
 
@@ -142,7 +142,7 @@ At this point, Alice now has an initial policy that is ready to deploy in audit
 In order to minimize user productivity impact, Alice has defined a policy that makes several trade-offs between security and user app flexibility. Some of the trade-offs include:
 
 - **Users with administrative access**<br>
-    By far the most impactful security trade-off, this allows the device user (or malware running with the user's privileges) to modify or remove altogether the WDAC policy applied on the device. Additionally, administrators can configure any app they wish to operate as a managed installer that would allow them to gain persistent app authorization for whatever apps or binaries they wish.
+    By far the most impactful security trade-off, this trade-off allows the device user (or malware running with the user's privileges) to modify or remove altogether the WDAC policy applied on the device. Additionally, administrators can configure any app they wish to operate as a managed installer that would allow them to gain persistent app authorization for whatever apps or binaries they wish.
 
     Possible mitigations:
   - Use signed WDAC policies and UEFI BIOS access protection to prevent tampering of WDAC policies.

windows/security/threat-protection/windows-defender-application-control/deploy-catalog-files-to-support-windows-defender-application-control.md

@@ -40,9 +40,9 @@ To create a catalog file, you use a tool called **Package Inspector**. You must
 > [!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. 
 
-1.  Be sure that a Windows Defender Application Control policy is currently deployed in audit mode on the computer on which you will run Package Inspector.
+1.  Be sure that a Windows Defender Application Control policy is currently deployed in audit mode on the computer on which you'll run Package Inspector.
 
-    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. 
+    Package Inspector doesn't 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. 
 
     > [!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.
@@ -58,7 +58,7 @@ To create a catalog file, you use a tool called **Package Inspector**. You must
 
     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.
+4.  Install the application. Install it to the same drive that the application installer is located on (the drive you're scanning). Also, while Package Inspector is running, don't run any installations or updates that you don't want to capture in the catalog.
 
     > [!IMPORTANT]
     > Every binary that is run while Package Inspector is running will be captured in the catalog. Ensure that only trusted applications are run during this time. 
@@ -71,9 +71,9 @@ To create a catalog file, you use a tool called **Package Inspector**. You must
 
     This step is necessary to ensure that the scan has captured all binaries.
     
-8.  As appropriate, with Package Inspector still running, repeat the process for another application that you want in the catalog. Copy the installation media to the local drive, install the application, ensure it is updated, and then close and reopen the application.
+8.  As appropriate, with Package Inspector still running, repeat the process for another application that you want in the catalog. Copy the installation media to the local drive, install the application, ensure it's updated, and then close and reopen the application.
 
-9. When you have confirmed that the previous steps are complete, use the following commands to generate the catalog and definition files on your computer's desktop. The filenames used in these example commands are **LOBApp-Contoso.cat** (catalog file) and **LOBApp.cdf** (definition file)—substitute different filenames as appropriate. 
+9. When you've confirmed that the previous steps are complete, use the following commands to generate the catalog and definition files on your computer's desktop. The filenames used in these example commands are **LOBApp-Contoso.cat** (catalog file) and **LOBApp.cdf** (definition file)—substitute different filenames as appropriate. 
 
     For the last command, which stops Package Inspector, be sure to type the drive letter of the drive you have been scanning, for example, C:.  
 
@@ -98,22 +98,22 @@ Packages can fail for the following reasons:
 
 - Package is too large for default USN Journal or Event Log sizes
     - To diagnose whether USN journal size is the issue, after running through Package Inspector, click Start > install app > PackageInspector stop
-        - Get the value of the reg key at HKEY\_CURRENT\_USER/PackageInspectorRegistryKey/c: (this was the most recent USN when you ran PackageInspector start)
+        - Get the value of the reg key at HKEY\_CURRENT\_USER/PackageInspectorRegistryKey/c: (this USN was the most recent one when you ran PackageInspector start)
         - `fsutil usn readjournal C: startusn=RegKeyValue > inspectedusn.txt`
         - ReadJournal command should throw an error if the older USNs don't exist anymore due to overflow
     - For USN Journal, log size can be expanded using: `fsutil usn createjournal` command with a new size and alloc delta. `Fsutil usn queryjournal` will give the current size and allocation delta, so using a multiple of that may help
     - To diagnose whether Eventlog size is the issue, look at the Microsoft/Windows/CodeIntegrity/Operational log under Applications and Services logs in Event Viewer and ensure that there are entries present from when you began Package Inspector (You can use write time as a justification; if you started the install 2 hours ago and there are only entries from 30 minutes prior, the log is definitely too small)
     - To increase Eventlog size, in Event Viewer you can right click the operational log, click properties, and then set new values (some multiple of what it was previously)
 - Package files that change hash each time the package is installed
-    - 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
+    - Package Inspector is incompatible if files in the package (temporary or otherwise) change hash each time the package is installed. You can diagnose this hash-change 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 won't 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.
-    - Windows Defender Application Control 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 Windows Defender (regardless of if you try to allow directly by policy or resign with Package Inspector)
+    - Windows Defender Application Control uses Authenticode Hashes to validate files when they're running. If the file is unhashable via the authenticode SIP, there's 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 condition. 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 Windows Defender (regardless of if you try to allow directly by policy or resign with Package Inspector)
 
 ## Catalog signing with SignTool.exe
 
-To sign a catalog file you generated by using PackageInspector.exe, you need the following:
+To sign a catalog file you generated by using PackageInspector.exe, you need:
 
 -   SignTool.exe, found in the Windows software development kit (SDK—Windows 7 or later)
 
@@ -148,15 +148,15 @@ To sign the existing catalog file, copy each of the following commands into an e
 
 5. Copy the catalog file to C:\\Windows\\System32\\catroot\\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}.
 
-   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 Microsoft Endpoint Configuration Manager. Doing this also simplifies the management of catalog versions.
+   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 Microsoft Endpoint Configuration Manager, which also simplifies the management of catalog versions.
 
 ## Add a catalog signing certificate to a Windows Defender Application Control policy
 
 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.
+1.  If you haven't 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](/powershell/module/configci/new-cipolicy) to create a Windows Defender Application Control 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](/powershell/module/configci/new-cipolicy) to create a Windows Defender Application Control policy that you'll 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`
 
@@ -212,9 +212,9 @@ To simplify the management of catalog files, you can use Group Policy preference
 
    **C:\\Windows\\System32\\catroot\\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\\LOBApp-Contoso.cat**
 
-   For the catalog file name, use the name of the catalog you are deploying.
+   For the catalog file name, use the name of the catalog you're deploying.
 
-10. On the **Common** tab of the **New File Properties** dialog box, select the **Remove this item when it is no longer applied** option. Doing this ensures that the catalog file is removed from every system, in case you ever need to stop trusting this application.
+10. On the **Common** tab of the **New File Properties** dialog box, select the **Remove this item when it is no longer applied** option. Enabling this option ensures that the catalog file is removed from every system, in case you ever need to stop trusting this application.
 
 11. Click **OK** to complete file creation.
 
@@ -224,7 +224,7 @@ Before you begin testing the deployed catalog file, make sure that the catalog s
 
 ## Deploy catalog files with Microsoft Endpoint Configuration Manager
 
-As an alternative to Group Policy, you can use Configuration Manager to deploy catalog files to the managed computers in your environment. This approach can simplify the deployment and management of multiple catalog files as well as provide reporting around which catalog each client or collection has deployed. In addition to the deployment of these files, Configuration Manager can also be used to inventory the currently deployed catalog files for reporting and compliance purposes. Complete the following steps to create a new deployment package for catalog files:
+As an alternative to Group Policy, you can use Configuration Manager to deploy catalog files to the managed computers in your environment. This approach can simplify the deployment and management of multiple catalog files and provide reporting around which catalog each client or collection has deployed. In addition to the deployment of these files, Configuration Manager can also be used to inventory the currently deployed catalog files for reporting and compliance purposes. Complete the following steps to create a new deployment package for catalog files:
 
 >[!NOTE]
 >The following example uses a network share named \\\\Shares\\CatalogShare as a source for the catalog files. If you have collection specific catalog files, or prefer to deploy them individually, use whichever folder structure works best for your organization.
@@ -263,7 +263,7 @@ As an alternative to Group Policy, you can use Configuration Manager to deploy c
 
 7.  Accept the defaults for the rest of the wizard, and then close the wizard.
 
-After you create the deployment package, deploy it to a collection so that the clients will receive the catalog files. In this example, you deploy the package you just created to a test collection:
+After you create the deployment package, deploy it to a collection so that the clients will receive the catalog files. In this example, you deploy the package you created to a test collection:
 
 1.  In the Software Library workspace, navigate to Overview\\Application Management\\Packages, right-click the catalog file package, and then click **Deploy**.
 
@@ -335,9 +335,9 @@ When catalog files have been deployed to the computers within your environment,
 
 8.  Click **OK**.
 
-9.  Now that you have created the client settings policy, right-click the new policy, click **Deploy**, and then choose the collection on which you would like to inventory the catalog files.
+9.  Now that you've created the client settings policy, right-click the new policy, click **Deploy**, and then choose the collection on which you would like to inventory the catalog files.
 
-At the time of the next software inventory cycle, when the targeted clients receive the new client settings policy, you will be able to view the inventoried files in the built-in Configuration Manager reports or Resource Explorer. To view the inventoried files on a client within Resource Explorer, complete the following steps:
+At the time of the next software inventory cycle, when the targeted clients receive the new client settings policy, you'll be able to view the inventoried files in the built-in Configuration Manager reports or Resource Explorer. To view the inventoried files on a client within Resource Explorer, complete the following steps:
 
 1.  Open the Configuration Manager console, and select the Assets and Compliance workspace.
 

windows/security/threat-protection/windows-defender-application-control/deploy-multiple-windows-defender-application-control-policies.md

@@ -29,7 +29,7 @@ ms.technology: windows-sec
 >[!NOTE]
 >Some capabilities of Windows Defender Application Control (WDAC) are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](feature-availability.md).
 
-Prior to Windows 10 1903, Windows Defender Application Control only supported a single active policy on a system at any given time. This significantly limited customers in situations where multiple policies with different intents would be useful. Beginning with Windows 10 version 1903, WDAC supports up to 32 active policies on a device at once in order to enable the following scenarios:
+Prior to Windows 10 1903, Windows Defender Application Control only supported a single active policy on a system at any given time. This limited customers in situations where multiple policies with different intents would be useful. Beginning with Windows 10 version 1903, WDAC supports up to 32 active policies on a device at once in order to enable the following scenarios:
 
 1. Enforce and Audit Side-by-Side
     - To validate policy changes before deploying in enforcement mode, users can now deploy an audit-mode base policy side by side with an existing enforcement-mode base policy
@@ -49,11 +49,11 @@ Prior to Windows 10 1903, Windows Defender Application Control only supported a
 - Multiple base policies: intersection
   - Only applications allowed by both policies run without generating block events
 - Base + supplemental policy: union
-  - Files that are allowed by either the base policy or the supplemental policy are not blocked
+  - Files that are allowed by either the base policy or the supplemental policy aren't blocked
 
 ## Creating WDAC policies in Multiple Policy Format
 
-In order to allow multiple policies to exist and take effect on a single system, policies must be created using the new Multiple Policy Format. The "MultiplePolicyFormat" switch in [New-CIPolicy](/powershell/module/configci/new-cipolicy?preserve-view=true&view=win10-ps) results in 1) unique GUIDs being generated for the policy ID and 2) the policy type being specified as base. The below is an example of creating a new policy in the multiple policy format.
+In order to allow multiple policies to exist and take effect on a single system, policies must be created using the new Multiple Policy Format. The "MultiplePolicyFormat" switch in [New-CIPolicy](/powershell/module/configci/new-cipolicy?preserve-view=true&view=win10-ps) results in 1) unique GUIDs being generated for the policy ID and 2) the policy type being specified as base. The below example describes the process of creating a new policy in the multiple policy format.
 
 ```powershell
 New-CIPolicy -MultiplePolicyFormat -ScanPath "<path>" -UserPEs -FilePath ".\policy.xml" -Level Publisher -Fallback Hash
@@ -87,7 +87,7 @@ Set-CIPolicyIdInfo [-FilePath] <string> [-PolicyName <string>] [-SupplementsBase
 
 ### Merging policies
 
-When merging, the policy type and ID of the leftmost/first policy specified is used. If the leftmost is a base policy with ID \<ID>, then regardless of what the GUIDs and types are for any subsequent policies, the merged policy will be a base policy with ID \<ID>.
+When you're merging policies, the policy type and ID of the leftmost/first policy specified is used. If the leftmost is a base policy with ID \<ID>, then regardless of what the GUIDs and types are for any subsequent policies, the merged policy will be a base policy with ID \<ID>.
 
 ## Deploying multiple policies
 
@@ -107,9 +107,9 @@ To deploy policies locally using the new multiple policy format, follow these st
 
 Multiple Windows Defender Application Control policies can be managed from an MDM server through ApplicationControl configuration service provider (CSP). The CSP also provides support for rebootless policy deployment.<br>
 
-However, when policies are un-enrolled from an MDM server, the CSP will attempt to remove every policy from devices, not just the policies added by the CSP. The reason for this is that the ApplicationControl CSP doesn't track enrollment sources for individual policies, even though it will query all policies on a device, regardless if they were deployed by the CSP.
+However, when policies are unenrolled from an MDM server, the CSP will attempt to remove every policy from devices, not just the policies added by the CSP. The reason for this is that the ApplicationControl CSP doesn't track enrollment sources for individual policies, even though it will query all policies on a device, regardless if they were deployed by the CSP.
 
-See [ApplicationControl CSP](/windows/client-management/mdm/applicationcontrol-csp) for more information on deploying multiple policies, optionally using Microsoft Endpoint Manager Intune's Custom OMA-URI capability.
+For more information on deploying multiple policies, optionally using Microsoft Endpoint Manager Intune's Custom OMA-URI capability, see [ApplicationControl CSP](/windows/client-management/mdm/applicationcontrol-csp).
 
 > [!NOTE]
 > WMI and GP do not currently support multiple policies. Instead, customers who cannot directly access the MDM stack should use the [ApplicationControl CSP via the MDM Bridge WMI Provider](/windows/client-management/mdm/applicationcontrol-csp#powershell-and-wmi-bridge-usage-guidance) to manage Multiple Policy Format Windows Defender Application Control policies.

windows/security/threat-protection/windows-defender-application-control/deployment/deploy-windows-defender-application-control-policies-using-intune.md

@@ -29,14 +29,14 @@ ms.technology: windows-sec
 > [!NOTE]
 > Some capabilities of Windows Defender Application Control (WDAC) are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](../feature-availability.md).
 
-You can use a Mobile Device Management (MDM) solution, like Microsoft Endpoint Manager Intune, to configure Windows Defender Application Control (WDAC) on client machines. Intune includes native support for WDAC which can be a helpful starting point, but customers may find the available circle-of-trust options too limiting. To deploy a custom policy through Intune and define your own circle of trust, you can configure a profile using Custom OMA-URI. If your organization uses another MDM solution, check with your solution provider for WDAC policy deployment steps.
+You can use a Mobile Device Management (MDM) solution, like Microsoft Endpoint Manager Intune, to configure Windows Defender Application Control (WDAC) on client machines. Intune includes native support for WDAC, which can be a helpful starting point, but customers may find the available circle-of-trust options too limiting. To deploy a custom policy through Intune and define your own circle of trust, you can configure a profile using Custom OMA-URI. If your organization uses another MDM solution, check with your solution provider for WDAC policy deployment steps.
 
 ## Use Intune's built-in policies
 
 Intune's built-in Windows Defender Application Control support allows you to configure Windows client computers to only run:
 
 - Windows components
-- 3rd party hardware and software kernel drivers
+- Third-party hardware and software kernel drivers
 - Microsoft Store-signed apps
 - [Optional] Reputable apps as defined by the Intelligent Security Graph (ISG)
 
@@ -68,7 +68,7 @@ The steps to use Intune's custom OMA-URI functionality are:
 4. Specify a **Name** and **Description** and use the following values for the remaining custom OMA-URI settings:
     - **OMA-URI**: ./Vendor/MSFT/ApplicationControl/Policies/_Policy GUID_/Policy
     - **Data type**: Base64
-    - **Certificate file**: upload your binary format policy file. You do not need to upload a Base64 file, as Intune will convert the uploaded .bin file to Base64 on your behalf.
+    - **Certificate file**: upload your binary format policy file. You don't need to upload a Base64 file, as Intune will convert the uploaded .bin file to Base64 on your behalf.
 
     > [!div class="mx-imgBorder"]
     > ![Configure custom WDAC.](../images/wdac-intune-custom-oma-uri.png)
@@ -78,13 +78,13 @@ The steps to use Intune's custom OMA-URI functionality are:
 
 ### Remove WDAC policies on Windows 10 1903+
 
-Upon deletion, policies deployed through Intune via the ApplicationControl CSP are removed from the system but stay in effect until the next reboot. In order to disable Windows Defender Application Control enforcement, first replace the existing policy with a new version of the policy that will "Allow *", like the rules in the example  policy at %windir%\schemas\CodeIntegrity\ExamplePolicies\AllowAll.xml. Once the updated policy is deployed, you can then delete the policy from the Intune portal. This will prevent anything from being blocked and fully remove the WDAC policy on the next reboot.
+Upon deletion, policies deployed through Intune via the ApplicationControl CSP are removed from the system but stay in effect until the next reboot. In order to disable Windows Defender Application Control enforcement, first replace the existing policy with a new version of the policy that will "Allow *", like the rules in the example  policy at %windir%\schemas\CodeIntegrity\ExamplePolicies\AllowAll.xml. Once the updated policy is deployed, you can then delete the policy from the Intune portal. This deletion will prevent anything from being blocked and fully remove the WDAC policy on the next reboot.
 
 ### For pre-1903 systems
 
 #### Deploying policies
 
-The steps to use Intune's Custom OMA-URI functionality to leverage the [AppLocker CSP](/windows/client-management/mdm/applocker-csp) and deploy a custom WDAC policy to pre-1903 systems are:
+The steps to use Intune's Custom OMA-URI functionality to apply the [AppLocker CSP](/windows/client-management/mdm/applocker-csp) and deploy a custom WDAC policy to pre-1903 systems are:
 
 1. Convert the policy XML to binary format using the ConvertFrom-CIPolicy cmdlet in order to be deployed. The binary policy may be signed or unsigned.
 
@@ -100,4 +100,4 @@ The steps to use Intune's Custom OMA-URI functionality to leverage the [AppLocke
 
 #### Removing policies
 
-Policies deployed through Intune via the AppLocker CSP cannot be deleted through the Intune console. In order to disable Windows Defender Application Control policy enforcement, either deploy an audit-mode policy or use a script to delete the existing policy.
+Policies deployed through Intune via the AppLocker CSP can't be deleted through the Intune console. In order to disable Windows Defender Application Control policy enforcement, either deploy an audit-mode policy or use a script to delete the existing policy.

windows/security/threat-protection/windows-defender-application-control/disable-windows-defender-application-control-policies.md

@@ -33,7 +33,7 @@ This topic covers how to disable unsigned or signed WDAC policies.
 
 ## Disable unsigned Windows Defender Application Control policies
 
-There may come a time when an administrator wants to disable a Windows Defender Application Control policy. For unsigned WDAC policies, this process is simple. The method used to deploy the policy (such as Group Policy) must first be disabled, then simply delete the SIPolicy.p7b policy file from the following locations, and the WDAC policy will be disabled on the next computer restart:
+There may come a time when an administrator wants to disable a Windows Defender Application Control policy. For unsigned WDAC policies, this process is simple. The method used to deploy the policy (such as Group Policy) must first be disabled, then delete the SIPolicy.p7b policy file from the following locations, and the WDAC policy will be disabled on the next computer restart:
 
 -   <EFI System Partition>\\Microsoft\\Boot\\
 -   <OS Volume>\\Windows\\System32\\CodeIntegrity\\
@@ -43,7 +43,7 @@ There may come a time when an administrator wants to disable a Windows Defender
 
 ## 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 Windows Defender Application Control 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.
+Signed policies protect Windows from administrative manipulation and malware that has gained administrative-level access to the system. For this reason, signed Windows Defender Application Control 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 WDAC policies should be replaced and removed from the following locations:
@@ -68,7 +68,7 @@ Signed policies protect Windows from administrative manipulation as well as malw
 
 5.  Restart the client computer.
 
-If the signed Windows Defender Application Control policy has been deployed using by using Group Policy, you must complete the following steps:
+If the signed Windows Defender Application Control policy has been deployed 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.
 
@@ -90,7 +90,7 @@ If the signed Windows Defender Application Control policy has been deployed usin
 
 ## Disable signed Windows Defender Application Control policies within the BIOS
 
-There may be a time when signed Windows Defender Application Control 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:
+There may be a time when signed Windows Defender Application Control policies cause a boot failure. Because WDAC policies enforce kernel mode drivers, it's 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:
 
 -   <EFI System Partition>\\Microsoft\\Boot\\
 -   <OS Volume>\\Windows\\System32\\CodeIntegrity\\

windows/security/threat-protection/windows-defender-application-control/event-id-explanations.md

@@ -91,7 +91,7 @@ reg add hklm\system\currentcontrolset\control\ci -v TestFlags -t REG_DWORD -d 0x
 
 ## Event ID 3099 Options
 
-The Application Control policy rule-option values can be derived from the "Options" field in the Details section of the Code integrity 3099 event. To parse the values, first convert the hex value to binary. To derive and parse these values, follow the below workflow.
+The Application Control policy rule option values can be derived from the "Options" field in the Details section of the Code integrity 3099 event. To parse the values, first convert the hex value to binary. To derive and parse these values, follow the below workflow.
 
 - Access Event Viewer.
 - Access the Code integrity 3099 event.

windows/security/threat-protection/windows-defender-application-control/manage-packaged-apps-with-windows-defender-application-control.md

@@ -34,7 +34,7 @@ This topic for IT professionals describes concepts and lists procedures to help
 ## Understanding Packaged Apps and Packaged App Installers
 
 Packaged apps, also known as Universal Windows apps, are based on a model that ensures all the files within an app package share the same identity. With classic Windows apps, each file within the app could have a unique identity. 
-With packaged apps, it is possible to control the entire app by using a single Windows Defender Application Control rule.
+With packaged apps, it's possible to control the entire app by using a single Windows Defender Application Control rule.
  
 Typically, an app consists of multiple components: the installer that is used to install the app, and one or more exes, dlls, or scripts. With classic Windows apps, these components don't always share common attributes such as the software’s publisher name, product name, and product version. Therefore, Windows Defender Application Control controls each of these components separately through different rule collections, such as exe, dll, script, and Windows Installer rules. In contrast, all the components of a packaged app share the same publisher name, package name, and package version attributes. Therefore, you can control an entire app with a single rule.
 
@@ -43,8 +43,8 @@ Typically, an app consists of multiple components: the installer that is used to
 Windows Defender Application Control policies for packaged apps can only be applied to apps installed on computers running at least Windows Server 2012 or Windows 8, but classic Windows apps can be controlled on devices running at least Windows Server 
 2008 R2 or Windows 7. The rules for classic Windows apps and packaged apps can be enforced in tandem. The differences between packaged apps and classic Windows apps that you should consider include:
 
--   **Installing the apps**   All packaged apps can be installed by a standard user, whereas a number of classic Windows apps require administrative privileges to install. In an environment where most of the users are standard users, you might not have numerous exe rules (because classic Windows apps require administrative privileges to install), but you might want to have more explicit policies for packaged apps.
--   **Changing the system state**   Classic Windows apps can be written to change the system state if they are run with administrative privileges. Most packaged apps cannot change the system state because they run with limited privileges. When you design your Windows Defender Application Control policies, it is important to understand whether an app that you are allowing can make system-wide changes.
+-   **Installing the apps**   All packaged apps can be installed by a standard user, whereas many classic Windows apps require administrative privileges to install. In an environment where most of the users are standard users, you might not have numerous exe rules (because classic Windows apps require administrative privileges to install), but you might want to have more explicit policies for packaged apps.
+-   **Changing the system state**   Classic Windows apps can be written to change the system state if they're run with administrative privileges. Most packaged apps can't change the system state because they run with limited privileges. When you design your Windows Defender Application Control policies, it's important to understand whether an app that you're allowing can make system-wide changes.
 -   **Acquiring the apps**   Packaged apps can be acquired through the Store, or by loading using Windows PowerShell cmdlets (which requires a special enterprise license). Classic Windows apps can be acquired through traditional means.
 
 Windows Defender Application Control uses different rule collections to control packaged apps and classic Windows apps. You have the choice to control one type, the other type, or both.
@@ -57,7 +57,7 @@ Just as there are differences in managing each rule collection, you need to mana
 
 2.  Create WDAC rules for specific packaged apps based on your policy strategies. For more information, see [Deploy Windows Defender Application Control policy (WDAC) rules and file rules](select-types-of-rules-to-create.md).
 
-3.  Continue to update the WDAC policies as new package apps are introduced into your environment. To do this, see [Merge WDAC policies](merge-windows-defender-application-control-policies.md).
+3.  Continue to update the WDAC policies as new package apps are introduced into your environment. For information on how to do this update, see [Merge WDAC policies](merge-windows-defender-application-control-policies.md).
 
 ## Blocking Packaged Apps
 
@@ -65,7 +65,7 @@ You can now use `New-CIPolicyRule -Package $Package -Deny` to block packaged app
 
 ### Blocking Packaged Apps Which Are Installed on the System
 
-Below are the list of steps you can follow to block one or more packaged apps in the case that the apps are on the system you are using the WDAC PowerShell cmdlets on:
+Below are the list of steps you can follow to block one or more packaged apps in the case that the apps are on the system you're using the WDAC PowerShell cmdlets on:
 
 1. Get the app identifier for an installed package
 
@@ -116,9 +116,9 @@ Below are the list of steps you can follow to block one or more packaged apps in
    ```powershell
    Invoke-CimMethod -Namespace root\Microsoft\Windows\CI -ClassName PS_UpdateAndCompareCIPolicy -MethodName Update -Arguments @{FilePath = "C:\compiledpolicy.bin"}
    ```
-   ### Blocking Packaged Apps Which Are Not Installed on the System
+   ### Blocking Packaged Apps Which Aren't Installed on the System
 
-If the app you intend to block is not installed on the system you are using the WDAC PowerShell cmdlets on, then follow the steps below:
+If the app you intend to block isn't installed on the system you're using the WDAC PowerShell cmdlets on, then follow the steps below:
 
 1. Create a dummy rule using Steps 1-5 in the Blocking Packaged Apps Which Are Installed on the System section above
 
@@ -148,4 +148,4 @@ The method for allowing specific packaged apps is similar to the method outlined
 $Rule = New-CIPolicyRule -Package $package -allow
 ```
 
-Since a lot of system apps are packaged apps, it is generally advised that customers rely on the sample policies in `C:\Windows\schemas\CodeIntegrity\ExamplePolicies` to help allow all inbox apps by the Store signature already included in the policies and control apps with deny rules. 
+Since many system apps are packaged apps, it's recommended that customers rely on the sample policies in `C:\Windows\schemas\CodeIntegrity\ExamplePolicies` to help allow all inbox apps by the Store signature already included in the policies and control apps with deny rules. 

windows/security/threat-protection/windows-defender-application-control/microsoft-recommended-block-rules.md

@@ -75,9 +75,9 @@ Unless your use scenarios explicitly require them, Microsoft recommends that you
 - wslconfig.exe
 - wslhost.exe
 
-<sup>1</sup> A vulnerability in bginfo.exe has been fixed in the latest version 4.22. If you use BGInfo, for security, make sure to download and run the latest version here [BGInfo 4.22](/sysinternals/downloads/bginfo). Note that BGInfo versions earlier than 4.22 are still vulnerable and should be blocked.
+<sup>1</sup> A vulnerability in bginfo.exe has been fixed in the latest version 4.22. If you use BGInfo, for security, make sure to download and run the latest version here [BGInfo 4.22](/sysinternals/downloads/bginfo). BGInfo versions earlier than 4.22 are still vulnerable and should be blocked.
 
-<sup>2</sup> If you are using your reference system in a development context and use msbuild.exe to build managed applications, we recommend that you allow msbuild.exe in your code integrity policies. However, if your reference system is an end-user device that is not being used in a development context, we recommend that you block msbuild.exe.
+<sup>2</sup> If you're using your reference system in a development context and use msbuild.exe to build managed applications, we recommend that you allow msbuild.exe in your code integrity policies. However, if your reference system is an end-user device that isn't being used in a development context, we recommend that you block msbuild.exe.
 
 <sup>*</sup> Microsoft recognizes the efforts of people in the security community who help us protect customers through responsible vulnerability disclosure, and extends thanks to the following people:
 
@@ -107,9 +107,9 @@ Unless your use scenarios explicitly require them, Microsoft recommends that you
 
 Certain software applications may allow other code to run by design. Such 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 Application Control bypass, you should add *deny* rules to your application control 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 Application Control. These modules cannot be blocked by name or version, and therefore must be blocked by their corresponding hashes. 
+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 Application Control. These modules can't 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.
+For October 2017, we're announcing an update to system.management.automation.dll in which we're revoking older versions by hash values, instead of version rules.
 
 Microsoft recommends that you block the following Microsoft-signed applications and PowerShell files by merging the following policy into your existing policy to add these deny rules using the Merge-CIPolicy cmdlet. Beginning with the March 2019 quality update, each version of Windows requires blocking a specific version of the following files:
 

windows/security/threat-protection/windows-defender-application-control/microsoft-recommended-driver-block-rules.md

@@ -36,11 +36,11 @@ The vulnerable driver blocklist is designed to help harden systems against third
 
 - Known security vulnerabilities that can be exploited by attackers to elevate privileges in the Windows kernel
 - Malicious behaviors (malware) or certificates used to sign malware
-- Behaviors that are not malicious but circumvent the Windows Security Model and can be exploited by attackers to elevate privileges in the Windows kernel
+- Behaviors that aren't malicious but circumvent the Windows Security Model and can be exploited by attackers to elevate privileges in the Windows kernel
 
 Drivers can be submitted to Microsoft for security analysis at the [Microsoft Security Intelligence Driver Submission page](https://www.microsoft.com/en-us/wdsi/driversubmission). To report an issue or request a change to the vulnerable driver blocklist, including updating a block rule once a driver vulnerability has been patched, visit the [Microsoft Security Intelligence portal](https://www.microsoft.com/wdsi) or submit feedback on this article. 
 
-Microsoft recommends enabling [HVCI](/windows/security/threat-protection/device-guard/enable-virtualization-based-protection-of-code-integrity) or S mode to protect your devices against security threats. If this isn't possible, Microsoft recommends blocking this list of drivers within your existing Windows Defender Application Control policy. Blocking kernel drivers without sufficient testing can result in devices or software to malfunction, and in rare cases, blue screen. It's recommended to first validate this policy in [audit mode](audit-windows-defender-application-control-policies.md) and review the audit block events.
+Microsoft recommends enabling [HVCI](/windows/security/threat-protection/device-guard/enable-virtualization-based-protection-of-code-integrity) or S mode to protect your devices against security threats. If this setting isn't possible, Microsoft recommends blocking this list of drivers within your existing Windows Defender Application Control policy. Blocking kernel drivers without sufficient testing can result in devices or software to malfunction, and in rare cases, blue screen. It's recommended to first validate this policy in [audit mode](audit-windows-defender-application-control-policies.md) and review the audit block events.
 
 ```xml
 <?xml version="1.0" encoding="utf-8"?>

windows/security/threat-protection/windows-defender-application-control/plan-windows-defender-application-control-management.md

@@ -37,11 +37,11 @@ The first step in implementing application control is to consider how your polic
 
 Most Windows Defender Application Control policies will evolve over time and proceed through a set of identifiable phases during their lifetime. Typically, these phases include:
 
-1. [Define (or refine) the "circle-of-trust"](understand-windows-defender-application-control-policy-design-decisions.md) for the policy and build an audit mode version of the policy XML. In audit mode, block events are generated but files are not prevented from executing.
+1. [Define (or refine) the "circle-of-trust"](understand-windows-defender-application-control-policy-design-decisions.md) for the policy and build an audit mode version of the policy XML. In audit mode, block events are generated but files aren't prevented from executing.
 2. Deploy the audit mode policy to intended devices.
 3. Monitor audit block events from the intended devices and add/edit/delete rules as needed to address unexpected/unwanted blocks.
 4. Repeat steps 2-3 until the remaining block events meet expectations.
-5. Generate the enforced mode version of the policy. In enforced mode, files that are not allowed by the policy are prevented from executing and corresponding block events are generated.
+5. Generate the enforced mode version of the policy. In enforced mode, files that aren't allowed by the policy are prevented from executing and corresponding block events are generated.
 6. Deploy the enforced mode policy to intended devices. We recommend using staged rollouts for enforced policies to detect and respond to issues before deploying the policy broadly.
 7. Repeat steps 1-6 anytime the desired "circle-of-trust" changes.  
 
@@ -59,11 +59,11 @@ Use the [Set-CIPolicyIDInfo](/powershell/module/configci/set-cipolicyidinfo) cmd
 > PolicyID only applies to policies using the [multiple policy format](deploy-multiple-windows-defender-application-control-policies.md) on computers running Windows 10, version 1903 and above, or Windows 11. Running -ResetPolicyId on a policy created for pre-1903 computers will convert it to multiple policy format and prevent it from running on those earlier versions of Windows 10.
 > PolicyID should be set only once per policy and use different PolicyID's for the audit and enforced mode versions of each policy.
 
-In addition, we recommend using the [Set-CIPolicyVersion](/powershell/module/configci/set-cipolicyversion) cmdlet to increment the policy's internal version number when you make changes to the policy. The version must be defined as a standard four-part version string (e.g. "1.0.0.0").
+In addition, we recommend using the [Set-CIPolicyVersion](/powershell/module/configci/set-cipolicyversion) cmdlet to increment the policy's internal version number when you make changes to the policy. The version must be defined as a standard four-part version string (for example, "1.0.0.0").
 
 ### Policy rule updates
 
-As new apps are deployed or existing apps are updated by the software publisher, you may need to make revisions to your rules to ensure that these apps run correctly. Whether policy rule updates are required will depend significantly on the types of rules your policy includes. Rules based on codesigning certificates provide the most resiliency against app changes while rules based on file attributes or hash are most likely to require updates when apps change. Alternatively, if you leverage WDAC [managed installer](configure-authorized-apps-deployed-with-a-managed-installer.md) functionality and consistently deploy all apps and their updates through your managed installer, then you are less likely to need policy updates.
+As new apps are deployed or existing apps are updated by the software publisher, you may need to make revisions to your rules to ensure that these apps run correctly. Whether policy rule updates are required will depend significantly on the types of rules your policy includes. Rules based on codesigning certificates provide the most resiliency against app changes while rules based on file attributes or hash are most likely to require updates when apps change. Alternatively, if you use WDAC [managed installer](configure-authorized-apps-deployed-with-a-managed-installer.md) functionality and consistently deploy all apps and their updates through your managed installer, then you're less likely to need policy updates.
 
 ## WDAC event management
 
@@ -84,16 +84,16 @@ Considerations include:
 
 ### Help desk support
 
-If your organization has an established help desk support department in place, consider the following when deploying Windows Defender Application Control policies:
+If your organization has an established help desk support department in place, consider the following points when deploying Windows Defender Application Control policies:
 
 - What documentation does your support department require for new policy deployments?
 - What are the critical processes in each business group both in work flow and timing that will be affected by application control policies and how could they affect your support department's workload?
 - Who are the contacts in the support department?
-- How will the support department resolve application control issues between the end user and those who maintain the Windows Defender Application Control rules?
+- How will the support department resolve application control issues between the end user and those resources who maintain the Windows Defender Application Control rules?
 
 ### End-user support
 
-Because Windows Defender Application Control is preventing unapproved apps from running, it is important that your organization carefully plan how to provide end-user support. Considerations include:
+Because Windows Defender Application Control is preventing unapproved apps from running, it's important that your organization carefully plan how to provide end-user support. Considerations include:
 
 - Do you want to use an intranet site as a first line of support for users who have tried to run a blocked app?
 - How do you want to support exceptions to the policy? Will you allow users to run a script to temporarily allow access to a blocked app?
@@ -102,6 +102,6 @@ Because Windows Defender Application Control is preventing unapproved apps from
 
 After deciding how your organization will manage your Windows Defender Application Control policy, record your findings.
 
-- **End-user support policy.** Document the process that you will use for handling calls from users who have attempted to run a blocked app, and ensure that support personnel have clear escalation steps so that the administrator can update the Windows Defender Application Control policy, if necessary.
+- **End-user support policy.** Document the process that you'll use for handling calls from users who have attempted to run a blocked app, and ensure that support personnel have clear escalation steps so that the administrator can update the Windows Defender Application Control policy, if necessary.
 - **Event processing.** Document whether events will be collected in a central location called a store, how that store will be archived, and whether the events will be processed for analysis.
-- **Policy management.** Detail what policies are planned, how they will be managed, and how rules will be maintained over time.
+- **Policy management.** Detail what policies are planned, how they'll be managed, and how rules will be maintained over time.

windows/security/threat-protection/windows-defender-application-control/select-types-of-rules-to-create.md

@@ -88,13 +88,13 @@ Each file rule level has its benefit and disadvantage. Use Table 2 to select the
 
 | Rule level | Description |
 |----------- | ----------- |
-| **Hash** | Specifies individual [Authenticode/PE image hash values](#more-information-about-hashes) for each discovered binary. This is the most specific level, and requires more effort to maintain the current product versions’ hash values. Each time a binary is updated, the hash value changes, therefore requiring a policy update. |
+| **Hash** | Specifies individual [Authenticode/PE image hash values](#more-information-about-hashes) for each discovered binary. This level is the most specific level, and requires more effort to maintain the current product versions’ hash values. Each time a binary is updated, the hash value changes, therefore requiring a policy update. |
 | **FileName** | Specifies the original filename for each binary. Although the hash values for an application are modified when updated, the file names are typically not. This level offers less specific security than the hash level, but it doesn't typically require a policy update when any binary is modified. |
 | **FilePath** | Beginning with Windows 10 version 1903, this level allows binaries to run from specific file path locations. More information about FilePath level rules can be found below. |
 | **SignedVersion** | This level combines the publisher rule with a version number. It allows anything to run from the specified publisher with a version at or above the specified version number. |
 | **Publisher** | This level combines the PcaCertificate level (typically one certificate below the root) and the common name (CN) of the leaf certificate. You can use this rule level to trust a certificate issued by a particular CA and issued to a specific company you trust (such as Intel, for device drivers). |
 | **FilePublisher** | This level combines 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 other certificate levels, so the Windows Defender Application Control policy must be updated whenever these certificates change. |
+| **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. When this level is used, no policy update would be needed to run the new version of the application. However, leaf certificates have much shorter validity periods than other certificate levels, so the Windows Defender Application Control policy must be updated whenever these certificates change. |
 | **PcaCertificate** | Adds the highest available certificate in the provided certificate chain to signers. This level is typically one certificate below the root certificate because the scan doesn't validate anything beyond the certificates included in the provided signature (it doesn't go online or check local root stores). |
 | **RootCertificate** | Currently unsupported. |
 | **WHQL** | Trusts binaries if they've been validated and signed by WHQL. This level is primarily for kernel binaries. |
@@ -112,13 +112,13 @@ Each file rule level has its benefit and disadvantage. Use Table 2 to select the
 
 For example, consider an IT professional in a department that runs many servers. They only want to run software signed by 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 Windows Defender Application Control 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](/powershell/module/configci/new-cipolicy) with **-Level Publisher** (to allow software from their software providers, the "Publishers") and **-Fallback Hash** (to allow the internal, unsigned application). They deploy the policy in auditing mode to determine the potential impact from enforcing the policy. Using the audit data, they update their WDAC policies to include any additional software they want to run. Then they enable the WDAC policy in enforced mode for their servers.
+To create the Windows Defender Application Control 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](/powershell/module/configci/new-cipolicy) with **-Level Publisher** (to allow software from their software providers, the "Publishers") and **-Fallback Hash** (to allow the internal, unsigned application). They deploy the policy in auditing mode to determine the potential impact from enforcing the policy. With the help of the audit data, they update their WDAC policies to include any other software they want to run. Then they enable the WDAC policy in enforced mode for their servers.
 
 As part of normal operations, they'll 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 won't need to update their WDAC policy. If the unsigned, internal application is updated, they must also update the WDAC policy to allow the new version.
 
 ## File rule precedence order
 
-Windows Defender Application Control has a built-in file rule conflict logic that translates to precedence order. It will first process all explicit deny rules it finds. Then, it will process all explicit allow rules. If no deny or allow rule exists, WDAC will check for [Managed Installer EA](deployment/deploy-wdac-policies-with-memcm.md). Lastly, if none of these exist, WDAC will fall back on [ISG](use-windows-defender-application-control-with-intelligent-security-graph.md).
+Windows Defender Application Control has a built-in file rule conflict logic that translates to precedence order. It will first process all explicit deny rules it finds. Then, it will process all explicit allow rules. If no deny or allow rule exists, WDAC will check for [Managed Installer EA](deployment/deploy-wdac-policies-with-memcm.md). Lastly, if none of these sets exist, WDAC will fall back on [ISG](use-windows-defender-application-control-with-intelligent-security-graph.md).
 
 ## More information about filepath rules
 
@@ -132,7 +132,7 @@ WDAC's list of well-known admin SIDs are:
 
 S-1-3-0; S-1-5-18; S-1-5-19; S-1-5-20; S-1-5-32-544; S-1-5-32-549; S-1-5-32-550; S-1-5-32-551; S-1-5-32-577; S-1-5-32-559; S-1-5-32-568; S-1-15-2-1430448594-2639229838-973813799-439329657-1197984847-4069167804-1277922394; S-1-15-2-95739096-486727260-2033287795-3853587803-1685597119-444378811-2746676523.
 
-When generating filepath rules using [New-CIPolicy](/powershell/module/configci/new-cipolicy), a unique, fully qualified path rule is generated for every file discovered in the scanned path(s). To create rules that instead allow all files under a specified folder path, use [New-CIPolicyRule](/powershell/module/configci/new-cipolicyrule) to define rules containing wildcards, using the [-FilePathRules](/powershell/module/configci/new-cipolicyrule#parameters) switch.
+When filepath rules are being generated using [New-CIPolicy](/powershell/module/configci/new-cipolicy), a unique, fully qualified path rule is generated for every file discovered in the scanned path(s). To create rules that instead allow all files under a specified folder path, use [New-CIPolicyRule](/powershell/module/configci/new-cipolicyrule) to define rules containing wildcards, using the [-FilePathRules](/powershell/module/configci/new-cipolicyrule#parameters) switch.
 
 Wildcards can be used at the beginning or end of a path rule; only one wildcard is allowed per path rule. Wildcards placed at the end of a path authorize all files in that path and its subdirectories recursively (ex. `C:\*` would include `C:\foo\*` ). Wildcards placed at the beginning of a path will allow the exact specified filename under any path (ex. `*\bar.exe` would allow `C:\bar.exe` and `C:\foo\bar.exe`). Wildcards in the middle of a path aren't supported (ex. `C:\*\foo.exe`). Without a wildcard, the rule will allow only a specific file (ex. `C:\foo\bar.exe`).
 
@@ -146,16 +146,16 @@ You can also use the following macros when the exact volume may vary: `%OSDRIVE%
 
 ## More information about hashes
 
-WDAC uses the [Authenticode/PE image hash algorithm](https://download.microsoft.com/download/9/c/5/9c5b2167-8017-4bae-9fde-d599bac8184a/Authenticode_PE.docx) when calculating the hash of a file. Unlike the more popular, but less secure, [flat file hash](/powershell/module/microsoft.powershell.utility/get-filehash), the Authenticode hash calculation omits the file's checksum and the Certificate Table and the Attribute Certificate Table. Therefore, the Authenticode hash of a file does not change when the file is re-signed or timestamped, or the digital signature is removed from the file. By using the Authenticode hash, WDAC provides added security and less management overhead so customers do not need to revise the policy hash rules when the digital signature on the file is updated. 
+WDAC uses the [Authenticode/PE image hash algorithm](https://download.microsoft.com/download/9/c/5/9c5b2167-8017-4bae-9fde-d599bac8184a/Authenticode_PE.docx) when calculating the hash of a file. Unlike the more popular, but less secure, [flat file hash](/powershell/module/microsoft.powershell.utility/get-filehash), the Authenticode hash calculation omits the file's checksum and the Certificate Table and the Attribute Certificate Table. Therefore, the Authenticode hash of a file doesn't change when the file is re-signed or timestamped, or the digital signature is removed from the file. With the help of the Authenticode hash, WDAC provides added security and less management overhead so customers don't need to revise the policy hash rules when the digital signature on the file is updated. 
 
-The Authenticode/PE image hash can be calculated for digitally-signed and unsigned files. 
+The Authenticode/PE image hash can be calculated for digitally signed and unsigned files. 
 
 ### Why does scan create four hash rules per XML file?
 
 The PowerShell cmdlet will produce an Authenticode Sha1 Hash, Sha256 Hash, Sha1 Page Hash, Sha256 Page Hash.
-During validation CI will choose which hashes to calculate, depending on how the file is signed.  For example, if the file is page-hash signed the entire file wouldn't get paged in to do a full sha256 authenticode, and we would just match using the first page hash.
+During validation, CI will choose which hashes to calculate, depending on how the file is signed.  For example, if the file is page-hash signed the entire file wouldn't get paged in to do a full sha256 authenticode, and we would just match using the first page hash.
 
-In the cmdlets, rather than try to predict which hash CI will use, we pre-calculate and use the four hashes (sha1/sha2 authenticode, and sha1/sha2 of first page).  This is also resilient, if the signing status of the file changes and necessary for deny rules to ensure that changing/stripping the signature doesn’t result in a different hash than what was in the policy being used by CI.
+In the cmdlets, rather than try to predict which hash CI will use, we pre-calculate and use the four hashes (sha1/sha2 authenticode, and sha1/sha2 of first page).  This method is also resilient, if the signing status of the file changes and necessary for deny rules to ensure that changing/stripping the signature doesn’t result in a different hash than what was in the policy being used by CI.
 
 ### Why does scan create eight hash rules for certain XML files?
 

windows/security/threat-protection/windows-defender-application-control/types-of-devices.md

@@ -29,27 +29,27 @@ ms.technology: windows-sec
 > [!NOTE]
 > Some capabilities of Windows Defender Application Control (WDAC) are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](feature-availability.md).
 
-Typically, deployment of Windows Defender Application Control (WDAC) happens best in phases, rather than being a feature that you simply “turn on.” The choice and sequence of phases depends on the way various computers and other devices are used in your organization, and to what degree IT manages those devices. The following table can help you begin to develop a plan for deploying WDAC in your organization. It is common for organizations to have device use cases across each of the categories described.
+Typically, deployment of Windows Defender Application Control (WDAC) happens best in phases, rather than being a feature that you simply “turn on.” The choice and sequence of phases depends on the way various computers and other devices are used in your organization, and to what degree IT manages those devices. The following table can help you begin to develop a plan for deploying WDAC in your organization. It's common for organizations to have device use cases across each of the categories described.
 
 ## Types of devices
 
 | **Type of device**                 | **How WDAC relates to this type of device**  | 
 |------------------------------------|------------------------------------------------------|
 | **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 Application Control can be used to help protect the kernel, and to monitor (audit) for problem applications rather than limiting the applications that can be run. | 
-| **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 Windows Defender Application Control 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. | 
-| **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 Application Control can be deployed fully, and deployment and ongoing administration are relatively straightforward.<br>After Windows Defender Application Control deployment, only approved applications can run. This is because of protections offered by WDAC. | 
-| **Bring Your Own Device**: Employees are allowed to bring their own devices, and also use those devices away from work. | In most cases, Windows Defender Application Control does not apply. Instead, you can explore other hardening and security features with MDM-based conditional access solutions, such as Microsoft Intune. However, you may choose to deploy an audit-mode policy to these devices or employ a blocklist only policy to prevent specific apps or binaries that are considered malicious or vulnerable by your organization. | 
+| **Fully managed devices**: Allowed software is restricted by IT department.<br>Users can request for more software, or install from a list of applications provided by IT department.<br>Examples: locked-down, company-owned desktops and laptops. | An initial baseline Windows Defender Application Control policy can be established and enforced. Whenever the IT department approves more applications, it will update the WDAC policy and (for unsigned LOB applications) the catalog.<br>WDAC policies are supported by the HVCI service. | 
+| **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 Application Control can be deployed fully, and deployment and ongoing administration are relatively straightforward.<br>After Windows Defender Application Control deployment, only approved applications can run. This rule is because of protections offered by WDAC. | 
+| **Bring Your Own Device**: Employees are allowed to bring their own devices, and also use those devices away from work. | In most cases, Windows Defender Application Control doesn't apply. Instead, you can explore other hardening and security features with MDM-based conditional access solutions, such as Microsoft Intune. However, you may choose to deploy an audit-mode policy to these devices or employ a blocklist only policy to prevent specific apps or binaries that are considered malicious or vulnerable by your organization. | 
 
 ## An introduction to Lamna Healthcare Company
 
-In the next set of topics, we will explore each of the above scenarios using a fictional organization called Lamna Healthcare Company.
+In the next set of topics, we'll explore each of the above scenarios using a fictional organization called Lamna Healthcare Company.
 
 Lamna Healthcare Company (Lamna) is a large healthcare provider operating in the United States. Lamna employs thousands of people, from doctors and nurses to accountants, in-house lawyers, and IT technicians. Their device use cases are varied and include single-user workstations for their professional staff, shared kiosks used by doctors and nurses to access patient records, dedicated medical devices such as MRI scanners, and many others. Additionally, Lamna has a relaxed, bring-your-own-device policy for many of their professional staff.
 
 Lamna uses [Microsoft Endpoint Manager](https://www.microsoft.com/microsoft-365/microsoft-endpoint-manager) in hybrid mode with both Configuration Manager and Intune. Although they use Microsoft Endpoint Manager to deploy many applications, Lamna has always had relaxed application usage practices: individual teams and employees have been able to install and use any applications they deem necessary for their role on their own workstations. Lamna also recently started to use [Microsoft Defender for Endpoint](https://www.microsoft.com/microsoft-365/windows/microsoft-defender-atp) for better endpoint detection and response.
 
-Recently, Lamna experienced a ransomware event that required an expensive recovery process and may have included data exfiltration by the unknown attacker. Part of the attack included installing and running malicious binaries that evaded detection by Lamna's antivirus solution but would have been blocked by an application control policy. In response, Lamna's executive board has authorized a number of new security IT responses, including tightening policies for application use and introducing application control.
+Recently, Lamna experienced a ransomware event that required an expensive recovery process and may have included data exfiltration by the unknown attacker. Part of the attack included installing and running malicious binaries that evaded detection by Lamna's antivirus solution but would have been blocked by an application control policy. In response, Lamna's executive board has authorized many new security IT responses, including tightening policies for application use and introducing application control.
 
 ## Up next
 
-- [Create a Windows Defender Application Control policy for lightly-managed devices](create-wdac-policy-for-lightly-managed-devices.md)
+- [Create a Windows Defender Application Control policy for lightly managed devices](create-wdac-policy-for-lightly-managed-devices.md)

windows/security/threat-protection/windows-defender-application-control/understand-windows-defender-application-control-policy-design-decisions.md

@@ -44,15 +44,15 @@ You should consider using Windows Defender Application Control as part of your o
 
 ## Decide what policies to create
 
-Beginning with Windows 10, version 1903, Windows Defender Application Control allows [multiple simultaneous policies](deploy-multiple-windows-defender-application-control-policies.md) to be applied to each device. This opens up many new use cases for organizations, but your policy management can easily become unwieldy without a well-thought-out plan for the number and types of policies to create.
+Beginning with Windows 10, version 1903, Windows Defender Application Control allows [multiple simultaneous policies](deploy-multiple-windows-defender-application-control-policies.md) to be applied to each device. This concurrent application opens up many new use cases for organizations, but your policy management can easily become unwieldy without a well-thought-out plan for the number and types of policies to create.
 
 The first step is to define the desired "circle-of-trust" for your WDAC policies. By "circle-of-trust," we mean a description of the business intent of the policy expressed in natural language. This "circle-of-trust" definition will guide you as you create the actual policy rules for your policy XML.
 
 For example, the DefaultWindows policy, which can be found under %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies, establishes a "circle-of-trust" that allows Windows, 3rd-party hardware and software kernel drivers, and applications from the Microsoft Store.
 
-Configuration Manager uses the DefaultWindows policy as the basis for its policy but then modifies the policy rules to allow Configuration Manager and its dependencies, sets the managed installer policy rule, and additionally configures Configuration Manager as a managed installer. It also can optionally authorize apps with positive reputation and perform a one-time scan of folder paths specified by the Configuration Manager administrator, which adds rules for any apps found in the specified paths on the managed endpoint. This establishes the "circle-of-trust" for Configuration Manager's native WDAC integration.
+Configuration Manager uses the DefaultWindows policy as the basis for its policy but then modifies the policy rules to allow Configuration Manager and its dependencies, sets the managed installer policy rule, and additionally configures Configuration Manager as a managed installer. It also can optionally authorize apps with positive reputation and perform a one-time scan of folder paths specified by the Configuration Manager administrator, which adds rules for any apps found in the specified paths on the managed endpoint. This process establishes the "circle-of-trust" for Configuration Manager's native WDAC integration.
 
-The following questions can help you plan your Windows Defender Application Control deployment and determine the right "circle-of-trust" for your policies. They are not in priority or sequential order, and are not meant to be an exhaustive set of design considerations.
+The following questions can help you plan your Windows Defender Application Control deployment and determine the right "circle-of-trust" for your policies. They aren't in priority or sequential order, and aren't meant to be an exhaustive set of design considerations.
 
 ## WDAC design considerations
 
@@ -74,11 +74,11 @@ Traditional Win32 apps on Windows can run without being digitally signed. This p
 | Possible answers | Design considerations |
 | - | - |
 | All apps used in your organization must be signed. | Organizations that enforce [codesigning](use-code-signing-to-simplify-application-control-for-classic-windows-applications.md) for all executable code are best-positioned to protect their Windows computers from malicious code execution. Windows Defender Application Control rules can be created to authorize apps and binaries from the organization's internal development teams and from trusted independent software vendors (ISV). |
-| Apps used in your organization do not need to meet any codesigning requirements. | Organizations can  [use built-in Windows tools](deploy-catalog-files-to-support-windows-defender-application-control.md) to add organization-specific App Catalog signatures to existing apps as a part of the app deployment process, which can be used to authorize code execution. Solutions like Microsoft Endpoint Manager offer multiple ways to distribute signed App Catalogs. | 
+| Apps used in your organization don't need to meet any codesigning requirements. | Organizations can  [use built-in Windows tools](deploy-catalog-files-to-support-windows-defender-application-control.md) to add organization-specific App Catalog signatures to existing apps as a part of the app deployment process, which can be used to authorize code execution. Solutions like Microsoft Endpoint Manager offer multiple ways to distribute signed App Catalogs. | 
  
 ### Are there specific groups in your organization that need customized application control policies?
 
-Most business teams or departments have specific security requirements that pertain to data access and the applications used to access that data. Consider the scope of the project for each group and the group’s priorities before you deploy application control policies for the entire organization. There is overhead in managing policies that might lead you to choose between broad, organization-wide policies and multiple team-specific policies.
+Most business teams or departments have specific security requirements that pertain to data access and the applications used to access that data. Consider the scope of the project for each group and the group’s priorities before you deploy application control policies for the entire organization. There's overhead in managing policies that might lead you to choose between broad, organization-wide policies and multiple team-specific policies.
 
 | Possible answers | Design considerations |
 | - | - |
@@ -91,12 +91,12 @@ The time and resources that are available to you to perform the research and ana
 
 | Possible answers | Design considerations |
 | - | - |
-| Yes | Invest the time to analyze your organization's application control requirements, and plan a complete deployment that uses rules that are constructed as simply as possible.|
+| Yes | Invest the time to analyze your organization's application control requirements, and plan a complete deployment that uses rules that are constructed as possible.|
 | No | Consider a focused and phased deployment for specific groups by using few rules. As you apply controls to applications in a specific group, learn from that deployment to plan your next deployment. Alternatively, you can create a policy with a broad trust profile to authorize as many apps as possible. |
 
 ### Does your organization have Help Desk support?
 
-Preventing your users from accessing known, deployed, or personal applications will initially cause an increase in end-user support. It will be necessary to address the various support issues in your organization so security policies are followed and business workflow is not hampered.
+Preventing your users from accessing known, deployed, or personal applications will initially cause an increase in end-user support. It will be necessary to address the various support issues in your organization so security policies are followed and business workflow isn't hampered.
 
 | Possible answers | Design considerations |
 | - | - |

windows/security/threat-protection/windows-defender-application-control/use-code-signing-to-simplify-application-control-for-classic-windows-applications.md

@@ -1,6 +1,6 @@
 ---
 title: Use code signing to simplify application control for classic Windows applications (Windows)
-description: With embedded signing, your WDAC policies typically do not have to be updated when an app is updated. To set this up, you can choose from a variety of methods.
+description: With embedded signing, your WDAC policies typically don't have to be updated when an app is updated. To set up this embedded signing, you can choose from various methods.
 keywords: security, malware
 ms.assetid: 8d6e0474-c475-411b-b095-1c61adb2bdbb
 ms.prod: m365-security
@@ -33,13 +33,13 @@ This topic covers guidelines for using code signing control classic Windows apps
 
 ## Reviewing your applications: application signing and catalog files
 
-Typically, Windows Defender Application Control (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.
+Typically, Windows Defender Application Control (WDAC) policies are configured to use the application's signing certificate as part or all of what identifies the application as trusted. This purpose 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 Windows Defender Application Control 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).
+Catalog files can be useful for unsigned LOB applications that can't easily be given an embedded signature. However, catalogs need to be updated each time an application is updated. In contrast, with embedded signing, your Windows Defender Application Control policies typically don't 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:
+To obtain signed applications or embed signatures in your in-house applications, you can choose from various methods:
 
-- Using the Microsoft Store publishing process. All apps that come out of the Microsoft Store are automatically signed with special signatures that can roll-up to our certificate authority (CA) or to your own.
+- Using the Microsoft Store publishing process. All apps that come out of the Microsoft Store are automatically signed with special signatures that can roll up to our certificate authority (CA) or to your own.
 
 - Using your own digital certificate or public key infrastructure (PKI). ISV's and enterprises can sign their own Classic Windows applications themselves, adding themselves to the trusted list of signers.
 
@@ -53,11 +53,11 @@ To use catalog signing, you can choose from the following options:
 
 ### Catalog files
 
-Catalog files (which you can create in Windows 10 and Windows 11 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 Windows Defender Application Control in the same way as any other signed application.
+Catalog files (which you can create in Windows 10 and Windows 11 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 don't 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 Windows Defender Application Control 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.
+Catalog files are 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 WDAC policies to trust the signer or signing certificate of those files.
+After you've created and signed your catalog files, you can configure your WDAC policies to trust the signer or signing certificate of those files.
 
 > [!NOTE]
 > Package Inspector only works on operating systems that support Windows Defender, such as Windows 10 and Windows 11 Enterprise, Windows 10 and Windows 11 Education, Windows 2016 Server, or Windows Enterprise IoT.
@@ -66,8 +66,8 @@ For procedures for working with catalog files, see [Deploy catalog files to supp
 
 ## Windows Defender Application Control policy formats and signing
 
-When you generate a Windows Defender Application Control policy, you are generating a binary-encoded XML document that includes configuration settings for both the User and Kernel-modes of Windows 10 and Windows 11 Enterprise, along with restrictions on Windows 10 and Windows 11 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 **<Rules>** section of the file.
+When you generate a Windows Defender Application Control policy, you're generating a binary-encoded XML document that includes configuration settings for both the User and Kernel-modes of Windows 10 and Windows 11 Enterprise, along with restrictions on Windows 10 and Windows 11 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 **<Rules>** section of the file.
 
 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 Windows Defender Application Control 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 Windows Defender Application Control policy is deployed, it restricts the software that can run on a device. The XML document can be signed, helping to add more protection against administrative users changing or removing the policy. 

windows/security/threat-protection/windows-defender-application-control/use-signed-policies-to-protect-windows-defender-application-control-against-tampering.md

@@ -29,20 +29,20 @@ ms.technology: windows-sec
 > [!NOTE]
 > Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](feature-availability.md).
 
-Signed Windows Defender Application Control (WDAC) policies give organizations the highest level of malware protection available in Windows—must be signed with [PKCS #7](https://datatracker.ietf.org/doc/html/rfc5652). 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 WDAC policies. Note that SecureBoot must be enabled in order to restrict users from updating or removing signed WDAC policies.
+Signed Windows Defender Application Control (WDAC) policies give organizations the highest level of malware protection available in Windows—must be signed with [PKCS #7](https://datatracker.ietf.org/doc/html/rfc5652). In addition to their enforced policy rules, signed policies can't 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 idea of the policies in mind, it's much more difficult to remove signed WDAC policies. SecureBoot must be enabled in order to restrict users from updating or removing signed WDAC policies.
 
 Before you sign with PKCS #7 and deploy a signed WDAC policy, we recommend that you [audit the policy](audit-windows-defender-application-control-policies.md) to discover any blocked applications that should be allowed to run. 
 
 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 Windows Defender Application Control](create-code-signing-cert-for-windows-defender-application-control.md) to create one with your on-premises CA. 
+If you don't 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](create-code-signing-cert-for-windows-defender-application-control.md) to create one with your on-premises CA. 
 
-Before PKCS #7-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](select-types-of-rules-to-create.md).
+Before PKCS #7-signing WDAC policies for the first time, ensure you 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](select-types-of-rules-to-create.md).
 
 To sign a Windows Defender Application Control policy with SignTool.exe, you need the following components:
 
 -   SignTool.exe, found in the [Windows SDK](https://developer.microsoft.com/windows/downloads/windows-10-sdk/) (Windows 7 or later)
 
--   The binary format of the WDAC policy that you generated in [Create a Windows Defender Application Control policy from a reference computer](create-initial-default-policy.md) or another WDAC policy that you have created
+-   The binary format of the WDAC policy that you generated in [Create a Windows Defender Application Control policy from a reference computer](create-initial-default-policy.md) or another WDAC policy that you've created
 
 -   An internal CA code signing certificate or a purchased code signing certificate
 
@@ -52,7 +52,7 @@ To sign a Windows Defender Application Control policy with SignTool.exe, you nee
 >Certificate fields, like 'subject common name' and 'issuer common name,' cannot be UTF-8 encoded, otherwise, blue screens may occur. These strings must be encoded as PRINTABLE_STRING, IA5STRING or BMPSTRING.
 
 
-If you do not have a code signing certificate, see [Optional: Create a code signing certificate for Windows Defender Application Control](create-code-signing-cert-for-windows-defender-application-control.md) for instructions on how to create one. If you use an alternate certificate or Windows Defender Application Control (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:
+If you don't have a code signing certificate, see [Optional: Create a code signing certificate for Windows Defender Application Control](create-code-signing-cert-for-windows-defender-application-control.md) for instructions on how to create one. If you use an alternate certificate or Windows Defender Application Control (WDAC) policy, ensure you 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:
 
@@ -64,7 +64,7 @@ If you do not have a code signing certificate, see [Optional: Create a code sign
    > [!NOTE]
    > This example uses the WDAC policy that you created in the [Create a Windows Defender Application Control policy from a reference computer](create-initial-default-policy.md) section. If you are signing another policy, be sure to update the **$CIPolicyPath** variable with the correct information.
 
-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](create-code-signing-cert-for-windows-defender-application-control.md).
+2. Import the .pfx code signing certificate. Import the code signing certificate that you'll 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](create-code-signing-cert-for-windows-defender-application-control.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.
 

windows/security/threat-protection/windows-defender-application-control/use-windows-defender-application-control-policy-to-control-specific-plug-ins-add-ins-and-modules.md

@@ -29,7 +29,7 @@ ms.technology: windows-sec
 > [!NOTE]
 > Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](feature-availability.md).
 
-As of Windows 10, version 1703, you can use Windows Defender Application Control (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):
+As of Windows 10, version 1703, you can use Windows Defender Application Control (WDAC) policies to control applications and 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 |
 |---|---|
@@ -38,7 +38,7 @@ As of Windows 10, version 1703, you can use Windows Defender Application Control
 
 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 Windows Defender Application Control policy allowing **addin1.dll** and **addin2.dll** to run in **ERP1.exe**, your organization's enterprise resource planning (ERP) application, 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 Windows Defender Application Control policy allowing **addin1.dll** and **addin2.dll** to run in **ERP1.exe**, your organization's enterprise resource planning (ERP) application, run the following commands. In the second command, **+=** is used to add a second rule to the **$rule** variable:
 
 ```powershell
 $rule = New-CIPolicyRule -DriverFilePath '.\temp\addin1.dll' -Level FileName -AppID '.\ERP1.exe'

windows/security/threat-protection/windows-defender-application-control/use-windows-defender-application-control-with-dynamic-code-security.md

@@ -20,7 +20,7 @@ ms.technology: windows-sec
 
 # Windows Defender Application Control and .NET hardening 
 
-Historically, Windows Defender Application Control (WDAC) has restricted the set of applications, libraries, and scripts that are allowed to run to those approved by an organization. 
+Historically, Windows Defender Application Control (WDAC) has restricted the set of applications, libraries, and scripts that are allowed to run to those sets approved by an organization. 
 Security researchers have found that some .NET applications may be used to circumvent those controls by using .NET’s capabilities to load libraries from external sources or generate new code on the fly.
 Beginning with Windows 10, version 1803, or Windows 11, Windows Defender Application Control features a new capability, called *Dynamic Code Security* to verify code loaded by .NET at runtime.
 
@@ -28,8 +28,8 @@ When the Dynamic Code Security option is enabled, Application Control policy is
 
 Additionally, it detects tampering in code generated to disk by .NET and blocks loading code that has been tampered with. 
 
-Dynamic Code Security is not enabled by default because existing policies may not account for externally loaded libraries. 
-Additionally, a few .NET loading features, including loading unsigned assemblies built with System.Reflection.Emit, are not currently supported with Dynamic Code Security enabled. 
+Dynamic Code Security isn't enabled by default because existing policies may not account for externally loaded libraries. 
+Additionally, a few .NET loading features, including loading unsigned assemblies built with System.Reflection.Emit, aren't currently supported with Dynamic Code Security enabled. 
 Microsoft recommends testing Dynamic Code Security in audit mode before enforcing it to discover whether any new libraries should be included in the policy. 
 
 Additionally, customers can precompile for deployment only to prevent an allowed executable from being terminated because it tries to load unsigned dynamically generated code. See the "Precompiling for Deployment Only" section in the [ASP.NET Precompilation Overview](/aspnet/web-forms/overview/older-versions-getting-started/deploying-web-site-projects/precompiling-your-website-cs) document for how to fix that.

windows/security/threat-protection/windows-defender-application-control/use-windows-defender-application-control-with-intelligent-security-graph.md

@@ -36,7 +36,7 @@ Beginning with Windows 10, version 1709, you can set an option to automatically
 
 The ISG uses the same vast security intelligence and machine learning analytics that power Microsoft Defender SmartScreen and Microsoft Defender Antivirus to help classify applications as having "known good," "known bad," or "unknown" reputation. When a binary runs on a system, with Windows Defender Application Control (WDAC) enabled with the ISG option, WDAC checks the file's reputation, by sending its hash and signing information to the cloud. If the ISG reports that the file has a "known good" reputation, the $KERNEL.SMARTLOCKER.ORIGINCLAIM kernel Extended Attribute (EA) is written to the file.
 
-If your WDAC policy does not have an explicit rule to allow or deny a binary to run, then WDAC will make a call to the cloud to determine whether the binary is familiar and safe. However, if your policy already authorizes or denies the binary, then WDAC will not make a call to the cloud.
+If your WDAC policy doesn't have an explicit rule to allow or deny a binary to run, then WDAC will make a call to the cloud to determine whether the binary is familiar and safe. However, if your policy already authorizes or denies the binary, then WDAC won't make a call to the cloud.
 
 If the file with good reputation is an application installer, its reputation will pass along to any files that it writes to disk. This way, all the files needed to install and run an app inherit the positive reputation data from the installer.
 
@@ -54,7 +54,7 @@ Setting up the ISG is easy using any management solution you wish. Configuring t
 
 ### Ensure that the Intelligent Security Graph option is enabled in the WDAC policy XML
 
-To allow apps and binaries based on the Microsoft Intelligent Security Graph, the **Enabled:Intelligent Security Graph authorization** option must be specified in the Windows Defender Application Control policy. This step can be done with the Set-RuleOption cmdlet. You should also enable the **Enabled:Invalidate EAs on Reboot** option so that ISG results are verified again after each reboot. The ISG option is not recommended for devices that don't have regular access to the internet. The following example shows both options being set.
+To allow apps and binaries based on the Microsoft Intelligent Security Graph, the **Enabled:Intelligent Security Graph authorization** option must be specified in the Windows Defender Application Control policy. This step can be done with the Set-RuleOption cmdlet. You should also enable the **Enabled:Invalidate EAs on Reboot** option so that ISG results are verified again after each reboot. The ISG option isn't recommended for devices that don't have regular access to the internet. The following example shows both options being set.
 
 ```xml
 <Rules> 
@@ -84,7 +84,7 @@ To allow apps and binaries based on the Microsoft Intelligent Security Graph, th
 
 ### Enable the necessary services to allow WDAC to use the ISG correctly on the client
 
-In order for the heuristics used by the ISG to function properly, a number of components in Windows must be enabled. You can configure these components by running the appidtel executable in `c:\windows\system32`.
+In order for the heuristics used by the ISG to function properly, many components in Windows must be enabled. You can configure these components by running the appidtel executable in `c:\windows\system32`.
 
 ```console
 appidtel start
@@ -99,7 +99,7 @@ Since the Microsoft Intelligent Security Graph is a heuristic-based mechanism, i
 Processes running with kernel privileges can circumvent WDAC by setting the ISG extended file attribute to make a binary appear to have known good reputation. Also, since the ISG option passes along reputation from application installers to the binaries they write to disk, it can over-authorize files in some cases where the installer launches the application upon completion.
 
 ## Using fsutil to query SmartLocker EA
-Customers using Windows Defender Application Control (WDAC) with Managed Installer (MI) or Intelligent Security Graph enabled can use fsutil to determine whether a file was allowed to run by one of these features. This can be achieved by querying the EAs on a file using fsutil and looking for the KERNEL.SMARTLOCKER.ORIGINCLAIM EA. The presence of this EA indicates that either MI or ISG allowed the file to run. This can be used in conjunction with enabling the MI and ISG logging events.
+Customers using Windows Defender Application Control (WDAC) with Managed Installer (MI) or Intelligent Security Graph enabled can use fsutil to determine whether a file was allowed to run by one of these features. This verification can be done by querying the EAs on a file using fsutil and looking for the KERNEL.SMARTLOCKER.ORIGINCLAIM EA. The presence of this EA indicates that either MI or ISG allowed the file to run. This EA's presence can be used in conjunction with enabling the MI and ISG logging events.
 
 #### Example
 
@@ -123,9 +123,9 @@ Ea Value Length: 7e
 
 ## Known limitations with using the Intelligent Security Graph
 
-Since the ISG only allows binaries that are known good, there are cases where legitimate software may be unknown to the ISG and will be blocked by Windows Defender Application Control (WDAC). In this case, you need to allow the software with a rule in your WDAC policy, deploy a catalog signed by a certificate trusted in the WDAC policy, or install the software from a WDAC managed installer. Installers or applications that dynamically create binaries at runtime, as well as self-updating applications, may exhibit this symptom.
+Since the ISG only allows binaries that are known good, there are cases where legitimate software may be unknown to the ISG and will be blocked by Windows Defender Application Control (WDAC). In this case, you need to allow the software with a rule in your WDAC policy, deploy a catalog signed by a certificate trusted in the WDAC policy, or install the software from a WDAC managed installer. Installers or applications that dynamically create binaries at runtime, and self-updating applications, may exhibit this symptom.
 
-Packaged apps are not supported with the Microsoft Intelligent Security Graph heuristics and will need to be separately authorized in your WDAC policy. Since packaged apps have a strong app identity and must be signed, it is straightforward to authorize these apps with your WDAC policy.
+Packaged apps aren't supported with the Microsoft Intelligent Security Graph heuristics and will need to be separately authorized in your WDAC policy. Since packaged apps have a strong app identity and must be signed, it's straightforward to authorize these apps with your WDAC policy.
 
 The ISG doesn't authorize kernel mode drivers. The WDAC policy must have rules that allow the necessary drivers to run.  
 

windows/security/threat-protection/windows-defender-application-control/wdac-and-applocker-overview.md

@@ -45,19 +45,19 @@ Windows Defender Application Control policies apply to the managed computer as a
 - The [path from which the app or file is launched](select-types-of-rules-to-create.md#more-information-about-filepath-rules) (beginning with Windows 10 version 1903)
 - The process that launched the app or binary
 
-Note that prior to Windows 10 version 1709, Windows Defender Application Control was known as configurable code integrity (CCI). WDAC was also one of the features that comprised the now-defunct term "Device Guard."
+Prior to Windows 10 version 1709, Windows Defender Application Control was known as configurable code integrity (CCI). WDAC was also one of the features that comprised the now-defunct term "Device Guard."
 
 ### WDAC System Requirements
 
 Windows Defender Application Control (WDAC) policies can be created on any client edition of Windows 10 build 1903+, or Windows 11, or on Windows Server 2016 and above.
 
-WDAC policies can be applied to devices running any edition of Windows 10, Windows 11, or Windows Server 2016 and above, via a Mobile Device Management (MDM) solution, for example, Intune; a management interface such as Configuration Manager; or a script host such as PowerShell. Group Policy can also be used to deploy WDAC policies to Windows 10 and Windows 11 Enterprise edition, or Windows Server 2016 and above, but cannot deploy policies to devices running non-Enterprise SKUs of Windows 10.
+WDAC policies can be applied to devices running any edition of Windows 10, Windows 11, or Windows Server 2016 and above, via a Mobile Device Management (MDM) solution, for example, Intune; a management interface such as Configuration Manager; or a script host such as PowerShell. Group Policy can also be used to deploy WDAC policies to Windows 10 and Windows 11 Enterprise edition, or Windows Server 2016 and above, but can't deploy policies to devices running non-Enterprise SKUs of Windows 10.
 
 For more information on which individual WDAC features are available on specific WDAC builds, see [WDAC feature availability](feature-availability.md).
 
 ## AppLocker
 
-AppLocker was introduced with Windows 7, and allows organizations to control which applications are allowed to run on their Windows clients. AppLocker helps to prevent end-users from running unapproved software on their computers but does not meet the servicing criteria for being a security feature.
+AppLocker was introduced with Windows 7, and allows organizations to control which applications are allowed to run on their Windows clients. AppLocker helps to prevent end-users from running unapproved software on their computers but doesn't meet the servicing criteria for being a security feature.
 
 AppLocker policies can apply to all users on a computer, or to individual users and groups. AppLocker rules can be defined based on:
 
@@ -72,13 +72,13 @@ AppLocker policies can be deployed using Group Policy or MDM.
 
 ## Choose when to use WDAC or AppLocker
 
-Generally, it is recommended that customers, who are able to implement application control using Windows Defender Application Control rather than AppLocker, do so. WDAC is undergoing continual improvements, and will be getting added support from Microsoft management platforms. Although AppLocker will continue to receive security fixes, it will not undergo new feature improvements.
+Generally, it's recommended that customers, who are able to implement application control using Windows Defender Application Control rather than AppLocker, do so. WDAC is undergoing continual improvements, and will be getting added support from Microsoft management platforms. Although AppLocker will continue to receive security fixes, it will not undergo new feature improvements.
 
 However, in some cases, AppLocker may be the more appropriate technology for your organization. AppLocker is best when:
 
 - You have a mixed Windows operating system (OS) environment and need to apply the same policy controls to Windows 10 and earlier versions of the OS.
 - You need to apply different policies for different users or groups on shared computers.
-- You do not want to enforce application control on application files such as DLLs or drivers.
+- You don't want to enforce application control on application files such as DLLs or drivers.
 
-AppLocker can also be deployed as a complement to Windows Defender Application Control (WDAC) to add user or group-specific rules for shared device scenarios, where it is important to prevent some users from running specific apps.
+AppLocker can also be deployed as a complement to Windows Defender Application Control (WDAC) to add user or group-specific rules for shared device scenarios, where it's important to prevent some users from running specific apps.
 As a best practice, you should enforce WDAC at the most restrictive level possible for your organization, and then you can use AppLocker to further fine-tune the restrictions.

windows/security/threat-protection/windows-defender-application-control/wdac-wizard-create-base-policy.md

@@ -30,7 +30,7 @@ ms.technology: windows-sec
 > [!NOTE]
 > Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](feature-availability.md).
 
-When creating policies for use with Windows Defender Application Control (WDAC), it is recommended to start with a template policy and then add or remove rules to suit your application control scenario. For this reason, the WDAC Wizard offers three template policies to start from and customize during the base policy creation workflow. Prerequisite information about application control can be accessed through the [WDAC design guide](windows-defender-application-control-design-guide.md). This page outlines the steps to create a new application control policy from a template, configure the policy options, and the signer and file rules. 
+When creating policies for use with Windows Defender Application Control (WDAC), it's recommended to start with a template policy, and then add or remove rules to suit your application control scenario. For this reason, the WDAC Wizard offers three template policies to start from and customize during the base policy creation workflow. Prerequisite information about application control can be accessed through the [WDAC design guide](windows-defender-application-control-design-guide.md). This page outlines the steps to create a new application control policy from a template, configure the policy options, and the signer and file rules. 
 
 
 ## Template Base Policies
@@ -64,11 +64,11 @@ A description of each policy rule, beginning with the left-most column, is provi
 |------------ | ----------- |
 | **Advanced Boot Options Menu** | The F8 preboot menu is disabled by default for all Windows Defender Application Control policies. Setting this rule option allows the F8 menu to appear to physically present users. |
 | **Allow Supplemental Policies** | Use this option on a base policy to allow supplemental policies to expand it. |
-| **Disable Script Enforcement** | This option disables script enforcement options. Unsigned PowerShell scripts and interactive PowerShell are no longer restricted to [Constrained Language Mode](/powershell/module/microsoft.powershell.core/about/about_language_modes). NOTE: This option is required to run HTA files, and is only supported with the Windows 10 May 2019 Update (1903) and higher. Using it on earlier versions of Windows 10 is not supported and may have unintended results. |
+| **Disable Script Enforcement** | This option disables script enforcement options. Unsigned PowerShell scripts and interactive PowerShell are no longer restricted to [Constrained Language Mode](/powershell/module/microsoft.powershell.core/about/about_language_modes). NOTE: This option is required to run HTA files, and is only supported with the Windows 10 May 2019 Update (1903) and higher. Using it on earlier versions of Windows 10 isn't supported and may have unintended results. |
 |**[Hypervisor-protected code integrity (HVCI)](../device-guard/enable-virtualization-based-protection-of-code-integrity.md)**| When enabled, policy enforcement uses virtualization-based security to run the code integrity service inside a secure environment. HVCI provides stronger protections against kernel malware.|
 | **Intelligent Security Graph Authorization** | Use this option to automatically allow applications with "known good" reputation as defined by the Microsoft Intelligent Security Graph (ISG). |
 | **Managed Installer** | Use this option to automatically allow applications installed by a software distribution solution, such as Microsoft Endpoint Configuration Manager, that has been defined as a managed installer. |
-| **Require 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–compatible driver must be WHQL certified. |
+| **Require WHQL** | By default, legacy drivers that aren't 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. Henceforth, every new Windows–compatible driver must be WHQL certified. |
 | **Update Policy without Rebooting** | Use this option to allow future Windows Defender Application Control policy updates to apply without requiring a system reboot. |
 | **Unsigned System Integrity Policy** | 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. |
 | **User Mode Code Integrity** | Windows Defender Application Control 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. |
@@ -83,7 +83,7 @@ Selecting the **+ Advanced Options** label will show another column of policy ru
 | Rule option | Description |
 |------------ | ----------- |
 | **Boot Audit on Failure** | Used when the Windows Defender Application Control (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. |
-| **Disable 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 flight/preview-signed builds. |
+| **Disable Flight Signing** | If enabled, WDAC policies won't trust flightroot-signed binaries. This option would be used in the scenario in which organizations only want to run released binaries, not flight/preview-signed builds. |
 | **Disable Runtime FilePath Rule Protection** | Disable default FilePath rule protection (apps and executables allowed based on file path rules must come from a file path that's only writable by an administrator) for any FileRule that allows a file based on FilePath. |
 | **Dynamic Code Security** | Enables policy enforcement for .NET applications and dynamically loaded libraries (DLLs). |
 | **Invalidate EAs on Reboot** | When the Intelligent Security Graph option (14) is used, WDAC sets an extended file attribute that indicates that the file was authorized to run. This option will cause WDAC to periodically revalidate the reputation for files that were authorized by the ISG.| 
@@ -104,17 +104,17 @@ The Publisher file rule type uses properties in the code signing certificate cha
 
 | Rule Condition | WDAC Rule Level | Description |
 |------------ | ----------- | ----------- |
-| **Issuing CA** | PCACertificate | Highest available certificate is added to the signers. This is typically the PCA certificate, one level below the root certificate. Any file signed by this certificate will be affected. |
-| **Publisher** | Publisher | This rule is a combination of the PCACertificate rule and the common name (CN) of the leaf certificate. Any file signed by a major CA but with a leaf from a specific company, for example a device driver corp, is affected. |
+| **Issuing CA** | PCACertificate | Highest available certificate is added to the signers. This certificate is typically the PCA certificate, one level below the root certificate. Any file signed by this certificate will be affected. |
+| **Publisher** | Publisher | This rule is a combination of the PCACertificate rule and the common name (CN) of the leaf certificate. Any file signed by a major CA but with a leaf from a specific company, for example, a device driver corp, is affected. |
 | **File version** | SignedVersion | This rule is a combination of PCACertificate, publisher, and a version number. Anything from the specified publisher with a version at or above the one specified is affected. |
-| **File name** | FilePublisher | Most specific. Combination of the file name, publisher, and PCA certificate as well as a minimum version number. Files from the publisher with the specified name and greater or equal to the specified version are affected. |
+| **File name** | FilePublisher | Most specific. Combination of the file name, publisher, and PCA certificate and a minimum version number. Files from the publisher with the specified name and greater or equal to the specified version are affected. |
 
 
 ![Custom filepublisher file rule creation.](images/wdac-wizard-custom-publisher-rule.png)
 
 ### Filepath Rules
 
-Filepath rules do not provide the same security guarantees that explicit signer rules do, as they are based on mutable access permissions. To create a filepath rule, select the file using the *Browse* button. 
+Filepath rules don't provide the same security guarantees that explicit signer rules do, as they're based on mutable access permissions. To create a filepath rule, select the file using the *Browse* button. 
 
 ### File Attribute Rules
 
@@ -132,11 +132,11 @@ The Wizard supports the creation of [file name rules](select-types-of-rules-to-c
 
 ### File Hash Rules
 
-Lastly, the Wizard supports creating file rules using the hash of the file. Although this level is specific, it can cause additional administrative overhead to maintain the current product version's hash values. Each time a binary is updated, the hash value changes, therefore requiring a policy update. By default, the Wizard will use file hash as the fallback in case a file rule cannot be created using the specified file rule level.
+Lastly, the Wizard supports creating file rules using the hash of the file. Although this level is specific, it can cause extra administrative overhead to maintain the current product version's hash values. Each time a binary is updated, the hash value changes, therefore requiring a policy update. By default, the Wizard will use file hash as the fallback in case a file rule can't be created using the specified file rule level.
 
 #### Deleting Signing Rules
   
-The policy signing rules list table on the left of the page will document the allow and deny rules in the template, as well as any custom rules you create. Template signing rules and custom rules can be deleted from the policy by selecting the rule from the rules list table. Once the rule is highlighted, press the delete button underneath the table. you will be prompted for additional confirmation. Select `Yes` to remove the rule from the policy and the rules table. 
+The policy signing rules list table on the left of the page will document the allow and deny rules in the template, and any custom rules you create. Template signing rules and custom rules can be deleted from the policy by selecting the rule from the rules list table. Once the rule is highlighted, press the delete button underneath the table. You'll be prompted for another confirmation. Select `Yes` to remove the rule from the policy and the rules table. 
 
 ## Up next
 

windows/security/threat-protection/windows-defender-application-control/wdac-wizard-create-supplemental-policy.md

@@ -30,7 +30,7 @@ ms.technology: windows-sec
 > [!NOTE]
 > Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](feature-availability.md).
 
-Beginning in Windows 10 version 1903, Windows Defender Application Control (WDAC) supports the creation of multiple active policies on a device. One or more supplemental policies allow customers to expand a [WDAC base policy](wdac-wizard-create-base-policy.md) to increase the circle of trust of the policy. A supplemental policy can expand only one base policy, but multiple supplementals can expand the same base policy. When using supplemental policies, applications allowed by the base or its supplemental policy/policies will be allowed to execute.
+Beginning in Windows 10 version 1903, Windows Defender Application Control (WDAC) supports the creation of multiple active policies on a device. One or more supplemental policies allow customers to expand a [WDAC base policy](wdac-wizard-create-base-policy.md) to increase the circle of trust of the policy. A supplemental policy can expand only one base policy, but multiple supplementals can expand the same base policy. When supplemental policies are being used, applications allowed by the base or its supplemental policy/policies will be allowed to execute.
 
 Prerequisite information about application control can be accessed through the [WDAC design guide](windows-defender-application-control-design-guide.md). This page outlines the steps to create a supplemental application control policy, configure the policy options, and the signer and file rules.
 
@@ -40,17 +40,17 @@ Once the Supplemental Policy type is chosen on the New Policy page, policy name
 
 ![Base policy allows supplemental policies.](images/wdac-wizard-supplemental-expandable.png)
 
-If the base policy is not configured for supplemental policies, the Wizard will attempt to convert the policy to one that can be supplemented. Once successful, the Wizard will show a dialog demonstrating that the addition of the Allow Supplemental Policy rule was completed.  
+If the base policy isn't configured for supplemental policies, the Wizard will attempt to convert the policy to one that can be supplemented. Once successful, the Wizard will show a dialog demonstrating that the addition of the Allow Supplemental Policy rule was completed.  
 
 ![Wizard confirms modification of base policy.](images/wdac-wizard-confirm-base-policy-modification.png)
 
-Policies that cannot be supplemented, for instance, a supplemental policy, will be detected by the Wizard and will show the following error. Only a base policy can be supplemented. More information on supplemental policies can be found on our [Multiple Policies article](deploy-multiple-windows-defender-application-control-policies.md).
+Policies that can't be supplemented, for instance, a supplemental policy, will be detected by the Wizard and will show the following error. Only a base policy can be supplemented. More information on supplemental policies can be found on our [Multiple Policies article](deploy-multiple-windows-defender-application-control-policies.md).
 
 ![Wizard detects a bad base policy.](images/wdac-wizard-supplemental-not-base.png)
 
 ## Configuring Policy Rules
 
-Upon page launch, policy rules will be automatically enabled/disabled depending on the chosen base policy from the previous page. Most of the supplemental policy rules must be inherited from the base policy. The Wizard will automatically parse the base policy and set the required supplemental policy rules to match the base policy rules. Inherited policy rules will be grayed out and will not be modifiable in the user interface. 
+Upon page launch, policy rules will be automatically enabled/disabled depending on the chosen base policy from the previous page. Most of the supplemental policy rules must be inherited from the base policy. The Wizard will automatically parse the base policy and set the required supplemental policy rules to match the base policy rules. Inherited policy rules will be grayed out and won't be modifiable in the user interface. 
 
 A short description of the rule will be shown at the bottom of the page when the cursor is placed on the rule title. 
 
@@ -78,7 +78,7 @@ The Publisher file rule type uses properties in the code signing certificate cha
 | Rule Condition | WDAC Rule Level | Description |
 |------------ | ----------- | ----------- |
 | **Issuing CA** | PCACertificate | Highest available certificate is added to the signers. This certificate is typically the PCA certificate, one level below the root certificate. Any file signed by this certificate will be affected. |
-| **Publisher** | Publisher | This rule is a combination of the PCACertificate rule and the common name (CN) of the leaf certificate. Any file signed by a major CA but with a leaf from a specific company, for example a device driver publisher, is affected. |
+| **Publisher** | Publisher | This rule is a combination of the PCACertificate rule and the common name (CN) of the leaf certificate. Any file signed by a major CA but with a leaf from a specific company, for example, a device driver publisher, is affected. |
 | **File version** | SignedVersion | This rule is a combination of the PCACertificate and Publisher rule, and a version number. Anything from the specified publisher with a version at or above the one specified is affected. |
 | **File name** | FilePublisher | Most specific. Combination of the file name, publisher, and PCA certificate and a minimum version number. Files from the publisher with the specified name and greater or equal to the specified version are affected. |
 
@@ -87,7 +87,7 @@ The Publisher file rule type uses properties in the code signing certificate cha
 
 ### Filepath Rules
 
-Filepath rules do not provide the same security guarantees that explicit signer rules do, as they are based on mutable access permissions. To create a filepath rule, select the file using the *Browse* button. 
+Filepath rules don't provide the same security guarantees that explicit signer rules do, as they're based on mutable access permissions. To create a filepath rule, select the file using the *Browse* button. 
 
 ### File Attribute Rules
 
@@ -105,12 +105,12 @@ The Wizard supports the creation of [file name rules](select-types-of-rules-to-c
 
 ### File Hash Rules
 
-Lastly, the Wizard supports creating file rules using the hash of the file. Although this level is specific, it can cause extra administrative overhead to maintain the current product versions’ hash values. Each time a binary is updated, the hash value changes, therefore requiring a policy update. By default, the Wizard will use file hash as the fallback in case a file rule cannot be created using the specified file rule level. 
+Lastly, the Wizard supports creating file rules using the hash of the file. Although this level is specific, it can cause extra administrative overhead to maintain the current product versions’ hash values. Each time a binary is updated, the hash value changes, therefore requiring a policy update. By default, the Wizard will use file hash as the fallback in case a file rule can't be created using the specified file rule level. 
 
 
 #### Deleting Signing Rules 
   
-The table on the left of the page will document the allow and deny rules in the template, and any custom rules you create. Rules can be deleted from the policy by selecting the rule from the rules list table. Once the rule is highlighted, press the delete button underneath the table. you will be prompted for additional confirmation. Select `Yes` to remove the rule from the policy and the rules table. 
+The table on the left of the page will document the allow and deny rules in the template, and any custom rules you create. Rules can be deleted from the policy by selecting the rule from the rules list table. Once the rule is highlighted, press the delete button underneath the table. you'll be prompted for another confirmation. Select `Yes` to remove the rule from the policy and the rules table. 
 
 ## Up next
 

windows/security/threat-protection/windows-defender-application-control/wdac-wizard-editing-policy.md

@@ -39,7 +39,7 @@ The Windows Defender Application Control Wizard makes editing and viewing WDAC p
 
 ## Configuring Policy Rules
 
-The `Policy Rules` page will load with the in-edit policy rules configured per the set rules. Selecting the `+ Advanced Options` button will reveal the advanced policy rule options panel. This grouping of rules contains additional policy rule options that are less common to the majority of users. To edit any of the rules, flip the corresponding policy rule state.  For instance, to disable Audit Mode and enable Enforcement Mode in the figure below, the button beside the `Audit Mode` label needs only to be pressed. Once the policy rules are configured, select the Next button to continue the next stage of editing: [Adding File Rules](#adding-file-rules).
+The `Policy Rules` page will load with the in-edit policy rules configured per the set rules. Selecting the `+ Advanced Options` button will reveal the advanced policy rule options panel. This grouping of rules contains other policy rule options that are less common to most users. To edit any of the rules, flip the corresponding policy rule state.  For instance, to disable Audit Mode and enable Enforcement Mode in the figure below, the button beside the `Audit Mode` label needs only to be pressed. Once the policy rules are configured, select the Next button to continue the next stage of editing: [Adding File Rules](#adding-file-rules).
 
 ![Configuring the policy rules.](images/wdac-wizard-edit-policy-rules.png)
 
@@ -47,7 +47,7 @@ A description of the policy rule is shown at the bottom of the page when the cur
 
 ## Adding File Rules
 
-The Windows Defender Application Control Wizard allows users to add rules to their existing policy seamlessly. Previously, this would have involved creating a new policy with the new rules and merging it with the existing policy. 
+The Windows Defender Application Control Wizard allows users to add rules to their existing policy seamlessly. Previously, this rule-adding task would have involved creating a new policy with the new rules and merging it with the existing policy. 
 
 Selecting the `+ Custom Rules` button will open the Custom Rules panel. For more information on creating new policy file rules, see the guidelines provided in the [creating policy file rules section](wdac-wizard-create-base-policy.md#creating-custom-file-rules).
 

windows/security/threat-protection/windows-defender-application-control/wdac-wizard-merging-policies.md

@@ -21,7 +21,7 @@ ms.technology: windows-sec
 
 # Merging existing policies with the WDAC Wizard
 
-Beginning in Windows 10 version 1903, Windows Defender Application Control (WDAC)supports multiple policies. Before version 1903, however, Windows 10 could only have one WDAC policy. Consequently, users were required to merge multiple WDAC policies into one. The WDAC Wizard has a simple to use user interface to allow users to merge multiple WDAC policies. The Wizard can support up to 15 policy files as input during the merge workflow.  
+Beginning in Windows 10 version 1903, Windows Defender Application Control (WDAC) supports multiple policies. Before version 1903, however, Windows 10 could only have one WDAC policy. So, users were required to merge multiple WDAC policies into one. The WDAC Wizard has a simple to use user interface to allow users to merge multiple WDAC policies. The Wizard can support up to 15 policy files as input during the merge workflow.  
 
 Select the policies you wish to merge into one policy using the `+ Add Policy` button under the table. Once added, policies will be enumerated within the table. To remove a policy from the table, if accidentally added, highlight the policy row and select the `- Remove Policy` button. Confirmation will be required before the policy is withdrawn from the table. 
 

windows/security/threat-protection/windows-defender-application-control/windows-defender-application-control-deployment-guide.md

@@ -28,7 +28,7 @@ You should now have one or more Windows Defender Application Control (WDAC) poli
 
 ## Plan your deployment
 
-As with any significant change to your environment, implementing application control can have unintended consequences. To ensure the best chance for success, you should follow safe deployment practices and plan your deployment carefully. Decide what devices you will manage with Windows Defender Application Control and split them into deployment rings so you can control the scale of the deployment and respond if anything goes wrong. Define the success criteria that will determine when it's safe to continue from one ring to the next.
+As with any significant change to your environment, implementing application control can have unintended consequences. To ensure the best chance for success, you should follow safe deployment practices and plan your deployment carefully. Decide what devices you'll manage with Windows Defender Application Control and split them into deployment rings so you can control the scale of the deployment and respond if anything goes wrong. Define the success criteria that will determine when it's safe to continue from one ring to the next.
 
 All Windows Defender Application Control policy changes should be deployed in audit mode before proceeding to enforcement. Carefully monitor events from devices where the policy has been deployed to ensure the block events you observe match your expectation before broadening the deployment to other deployment rings. If your organization uses Microsoft Defender for Endpoint, you can use the Advanced Hunting feature to centrally monitor WDAC-related events. Otherwise, we recommend using an event log forwarding solution to collect relevant events from your managed endpoints.
 

windows/security/threat-protection/windows-defender-application-control/windows-defender-application-control-design-guide.md

@@ -30,18 +30,18 @@ ms.technology: windows-sec
 > [!NOTE]
 > Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](feature-availability.md).
 
-This guide covers design and planning for Windows Defender Application Control (WDAC). It is intended to help security architects, security administrators, and system administrators create a plan that addresses specific application control requirements for different departments or business groups within an organization.
+This guide covers design and planning for Windows Defender Application Control (WDAC). It's intended to help security architects, security administrators, and system administrators create a plan that addresses specific application control requirements for different departments or business groups within an organization.
 
 ## Plan for success
 
-A common refrain you may hear about application control is that it is "too hard." While it is true that application control is not as simple as flipping a switch, organizations can be successful, if they're methodical when carefully planning their approach. In reality, the issues that lead to failure with application control often arise from business issues rather than technology challenges. Organizations that have successfully deployed application control have ensured the following before starting their planning:
+A common refrain you may hear about application control is that it is "too hard." While it's true that application control isn't as simple as flipping a switch, organizations can be successful, if they're methodical when carefully planning their approach. In reality, the issues that lead to failure with application control often arise from business issues rather than technology challenges. Organizations that have successfully deployed application control have ensured the following before starting their planning:
 
 -   Executive sponsorship and organizational buy-in is in place.
--   There is a clear **business** objective for using application control, and it is not being planned as a purely technical problem from IT.
+-   There's a clear **business** objective for using application control, and it's not being planned as a purely technical problem from IT.
 -   The organization has a plan to handle potential helpdesk support requests for users who are blocked from running some apps.
 -   The organization has considered where application control can be most useful (for example, securing sensitive workloads or business functions) and also where it may be difficult to achieve (for example, developer workstations).
 
-Once these business factors are in place, you are ready to begin planning your Windows Defender Application Control (WDAC) deployment. The following topics can help guide you through your planning process.
+Once these business factors are in place, you're ready to begin planning your Windows Defender Application Control (WDAC) deployment. The following topics can help guide you through your planning process.
 
 ## In this section