Windows Edition | +Supported? | +
---|---|
Home | +![]() |
+
Pro | +![]() |
+
Business | +![]() |
+
Enterprise | +![]() |
+
Education | +![]() |
+
Destination edition | +Destination edition | |||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
- | - | Home | -Pro | -Pro for Workstations | -Pro Education | -Education | -Enterprise LTSC | -Enterprise | ++ | + | Home | +Pro | +Pro for Workstations | +Pro Education | +Education | +Enterprise LTSC | +Enterprise | |||||||||||||||||||||
Starting edition | +Starting edition | |||||||||||||||||||||||||||||||||||||
Home | diff --git a/windows/deployment/upgrade/windows-10-upgrade-paths.md b/windows/deployment/upgrade/windows-10-upgrade-paths.md index 57994ce79b..b0a3dcf6d5 100644 --- a/windows/deployment/upgrade/windows-10-upgrade-paths.md +++ b/windows/deployment/upgrade/windows-10-upgrade-paths.md @@ -43,17 +43,17 @@ D = Edition downgrade; personal data is maintained, applications and settings ar
- | - | Windows 10 Home | -Windows 10 Pro | -Windows 10 Pro Education | -Windows 10 Education | -Windows 10 Enterprise | -Windows 10 Mobile | -Windows 10 Mobile Enterprise | ++ | Windows 10 Home | +Windows 10 Pro | +Windows 10 Pro Education | +Windows 10 Education | +Windows 10 Enterprise | +Windows 10 Mobile | +Windows 10 Mobile Enterprise |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Windows 7 | +Windows 7 | |||||||||||||||
Starter | @@ -116,7 +116,7 @@ D = Edition downgrade; personal data is maintained, applications and settings ar||||||||||||||||
Windows 8.1 | +Windows 8.1 | |||||||||||||||
(Core) | @@ -209,7 +209,7 @@ D = Edition downgrade; personal data is maintained, applications and settings ar✔ | |||||||||||||||
Windows 10 | +Windows 10 | |||||||||||||||
Home | @@ -261,17 +261,7 @@ D = Edition downgrade; personal data is maintained, applications and settings ar✔ | |||||||||||||||
Mobile Enterprise | -- | - | - | - | - | D | -- |
Windows 10 Pro, 1803 or higher|Determines whether Application Guard can use the clipboard functionality.|**Enabled.** Turns On the clipboard functionality and lets you choose whether to additionally:
-Disable the clipboard functionality completely when Virtualization Security is enabled.
- Enable copying of certain content from Application Guard into Microsoft Edge.
- Enable copying of certain content from Microsoft Edge into Application Guard. **Important:** Allowing copied content to go from Microsoft Edge into Application Guard can cause potential security risks and isn't recommended.
**Disabled or not configured.** Completely turns Off the clipboard functionality for Application Guard.| +|Configure Microsoft Defender Application Guard clipboard settings|Windows 10 Enterprise, 1709 or higher
Windows 10 Pro, 1803 or higher|Determines whether Application Guard can use the clipboard functionality.|**Enabled.** Turns On the clipboard functionality and lets you choose whether to additionally:
- Disable the clipboard functionality completely when Virtualization Security is enabled.
- Enable copying of certain content from Application Guard into Microsoft Edge.
- Enable copying of certain content from Microsoft Edge into Application Guard. **Important:** Allowing copied content to go from Microsoft Edge into Application Guard can cause potential security risks and isn't recommended.
**Disabled or not configured.** Completely turns Off the clipboard functionality for Application Guard.| |Configure Microsoft Defender Application Guard print settings|Windows 10 Enterprise, 1709 or higher
Windows 10 Pro, 1803 or higher|Determines whether Application Guard can use the print functionality.|**Enabled.** Turns On the print functionality and lets you choose whether to additionally:
- Enable Application Guard to print into the XPS format.
- Enable Application Guard to print into the PDF format.
- Enable Application Guard to print to locally attached printers.
- Enable Application Guard to print from previously connected network printers. Employees can't search for additional printers.
**Disabled or not configured.** Completely turns Off the print functionality for Application Guard.|
|Block enterprise websites to load non-enterprise content in IE and Edge|Windows 10 Enterprise, 1709 or higher|Determines whether to allow Internet access for apps not included on the **Allowed Apps** list.|**Enabled.** Prevents network traffic from both Internet Explorer and Microsoft Edge to non-enterprise sites that can't render in the Application Guard container.
**NOTE**: This action might also block assets cached by CDNs and references to analytics sites. Add them to the trusted enterprise resources to avoid broken pages.
**Disabled or not configured.** Prevents Microsoft Edge to render network traffic to non-enterprise sites that can't render in Application Guard. |
|Allow Persistence|Windows 10 Enterprise, 1709 or higher
Windows 10 Pro, 1803 or higher|Determines whether data persists across different sessions in Microsoft Defender Application Guard.|**Enabled.** Application Guard saves user-downloaded files and other items (such as, cookies, Favorites, and so on) for use in future Application Guard sessions.
**Disabled or not configured.** All user data within Application Guard is reset between sessions.
**NOTE**: If you later decide to stop supporting data persistence for your employees, you can use our Windows-provided utility to reset the container and to discard any personal data.
**To reset the container:**
1. Open a command-line program and navigate to `Windows/System32`.
2. Type `wdagtool.exe cleanup`. The container environment is reset, retaining only the employee-generated data.
3. Type `wdagtool.exe cleanup RESET_PERSISTENCE_LAYER`. The container environment is reset, including discarding all employee-generated data.|
@@ -61,6 +61,3 @@ These settings, located at **Computer Configuration\Administrative Templates\Win
|Allow hardware-accelerated rendering for Microsoft Defender Application Guard|Windows 10 Enterprise, 1803 or higher
Windows 10 Pro, 1803 or higher|Determines whether Microsoft Defender Application Guard renders graphics using hardware or software acceleration.|**Enabled.** Microsoft Defender Application Guard uses Hyper-V to access supported, high-security rendering graphics hardware (GPUs). These GPUs improve rendering performance and battery life while using Microsoft Defender Application Guard, particularly for video playback and other graphics-intensive use cases. If this setting is enabled without connecting any high-security rendering graphics hardware, Microsoft Defender Application Guard will automatically revert to software-based (CPU) rendering. **Important:** Be aware that enabling this setting with potentially compromised graphics devices or drivers might pose a risk to the host device.
**Disabled or not configured.** Microsoft Defender Application Guard uses software-based (CPU) rendering and won’t load any third-party graphics drivers or interact with any connected graphics hardware.|
|Allow camera and microphone access in Microsoft Defender Application Guard|Windows 10 Enterprise, 1809 or higher
Windows 10 Pro, 1809 or higher|Determines whether to allow camera and microphone access inside Microsoft Defender Application Guard.|**Enabled.** Applications inside Microsoft Defender Application Guard are able to access the camera and microphone on the user's device. **Important:** Be aware that enabling this policy with a potentially compromised container could bypass camera and microphone permissions and access the camera and microphone without the user's knowledge.
**Disabled or not configured.** Applications inside Microsoft Defender Application Guard are unable to access the camera and microphone on the user's device.|
|Allow Microsoft Defender Application Guard to use Root Certificate Authorities from a user's device|Windows 10 Enterprise, 1809 or higher
Windows 10 Pro, 1809 or higher|Determines whether Root Certificates are shared with Microsoft Defender Application Guard.|**Enabled.** Certificates matching the specified thumbprint are transferred into the container. Use a comma to separate multiple certificates.
**Disabled or not configured.** Certificates are not shared with Microsoft Defender Application Guard.| -|Allow users to trust files that open in Microsoft Defender Application Guard|Windows 10 Enterprise, 1809 or higher|Determines whether users are able to manually trust untrusted files to open them on the host.|**Enabled.** Users are able to manually trust files or trust files after an antivirus check.
**Disabled or not configured.** Users are unable to manually trust files and files continue to open in Microsoft Defender Application Guard.| -|Allow extensions in the container|Windows 10 Enterprise, 1709 or higher
Windows 10 Pro, 1803 or higher|Determines whether Application Guard can use extensions.|**Enabled.** Favorites are able to sync from the host browser to the container. Note that this doesn’t work the other way around. The favorites sync to the user’s work profile by default.
**Disabled.** Users are not able to access their favorites from within the Application Guard container.| -|Allow favorites sync|Windows 10 Enterprise, 1709 or higher
Windows 10 Pro, 1803 or higher|Determines whether favorites can be accessible from Application Guard container.|**Enabled.** Favorites are able to sync from the host browser to the container, but it doesn’t work the other way around. The favorites sync to the user’s work profile by default.
**Disabled.** Users are not able to access their favorites from within the Application Guard container.
diff --git a/windows/security/threat-protection/security-compliance-toolkit-10.md b/windows/security/threat-protection/security-compliance-toolkit-10.md
index 3662667af2..2a578d07ab 100644
--- a/windows/security/threat-protection/security-compliance-toolkit-10.md
+++ b/windows/security/threat-protection/security-compliance-toolkit-10.md
@@ -28,13 +28,13 @@ The SCT enables administrators to effectively manage their enterprise’s Group
The Security Compliance Toolkit consists of:
- Windows 10 security baselines
- - Windows 10 Version 20H2 (October 2020 Update)
- - Windows 10 Version 2004 (May 2020 Update)
- - Windows 10 Version 1909 (November 2019 Update)
- - Windows 10 Version 1809 (October 2018 Update)
- - Windows 10 Version 1803 (April 2018 Update)
- - Windows 10 Version 1607 (Anniversary Update)
- - Windows 10 Version 1507
+ - Windows 10, Version 21H1 (May 2021 Update)
+ - Windows 10, Version 20H2 (October 2020 Update)
+ - Windows 10, Version 2004 (May 2020 Update)
+ - Windows 10, Version 1909 (November 2019 Update)
+ - Windows 10, Version 1809 (October 2018 Update)
+ - Windows 10, Version 1607 (Anniversary Update)
+ - Windows 10, Version 1507
- Windows Server security baselines
- Windows Server 2019
@@ -42,7 +42,7 @@ The Security Compliance Toolkit consists of:
- Windows Server 2012 R2
- Microsoft Office security baseline
- - Microsoft 365 Apps for enterprise (Sept 2019)
+ - Microsoft 365 Apps for enterprise, Version 2104
- Microsoft Edge security baseline
- Version 88
diff --git a/windows/security/threat-protection/windows-defender-application-control/TOC.yml b/windows/security/threat-protection/windows-defender-application-control/TOC.yml
index eaf0d1aa66..2a9d13497a 100644
--- a/windows/security/threat-protection/windows-defender-application-control/TOC.yml
+++ b/windows/security/threat-protection/windows-defender-application-control/TOC.yml
@@ -21,9 +21,7 @@
href: select-types-of-rules-to-create.md
items:
- name: Allow apps installed by a managed installer
- href: use-windows-defender-application-control-with-managed-installer.md
- - name: Configure managed installer rules
- href: configure-wdac-managed-installer.md
+ href: configure-authorized-apps-deployed-with-a-managed-installer.md
- name: Allow reputable apps with Intelligent Security Graph (ISG)
href: use-windows-defender-application-control-with-intelligent-security-graph.md
- name: Allow COM object registration
diff --git a/windows/security/threat-protection/windows-defender-application-control/applocker/applocker-overview.md b/windows/security/threat-protection/windows-defender-application-control/applocker/applocker-overview.md
index b7dcbcddd8..29d54546be 100644
--- a/windows/security/threat-protection/windows-defender-application-control/applocker/applocker-overview.md
+++ b/windows/security/threat-protection/windows-defender-application-control/applocker/applocker-overview.md
@@ -83,7 +83,7 @@ The following are examples of scenarios in which AppLocker can be used:
- In addition to other measures, you need to control the access to sensitive data through app usage.
> [!NOTE]
-> AppLocker is a defense-in-depth security feature and **not** a [security boundary](https://www.microsoft.com/msrc/windows-security-servicing-criteria). [Windows Defender Application Control](https://www.microsoft.com/msrc/windows-security-servicing-criteria) should be used when the goal is to provide robust protection against a threat and there are expected to be no by-design limitations that would prevent the security feature from achieving this goal.
+> AppLocker is a defense-in-depth security feature and not a [security boundary](https://www.microsoft.com/msrc/windows-security-servicing-criteria). [Windows Defender Application Control](/windows/security/threat-protection/windows-defender-application-control/wdac-and-applocker-overview) should be used when the goal is to provide robust protection against a threat and there are expected to be no by-design limitations that would prevent the security feature from achieving this goal.
AppLocker can help you protect the digital assets within your organization, reduce the threat of malicious software being introduced into your environment, and improve the management of application control and the maintenance of application control policies.
@@ -143,4 +143,3 @@ For reference in your security planning, the following table identifies the base
| [AppLocker design guide](applocker-policies-design-guide.md) | This topic for the IT professional introduces the design and planning steps required to deploy application control policies by using AppLocker. |
| [AppLocker deployment guide](applocker-policies-deployment-guide.md) | This topic for IT professionals introduces the concepts and describes the steps required to deploy AppLocker policies. |
| [AppLocker technical reference](applocker-technical-reference.md) | This overview topic for IT professionals provides links to the topics in the technical reference. |
-
diff --git a/windows/security/threat-protection/windows-defender-application-control/audit-and-enforce-windows-defender-application-control-policies.md b/windows/security/threat-protection/windows-defender-application-control/audit-and-enforce-windows-defender-application-control-policies.md
new file mode 100644
index 0000000000..b33cace078
--- /dev/null
+++ b/windows/security/threat-protection/windows-defender-application-control/audit-and-enforce-windows-defender-application-control-policies.md
@@ -0,0 +1,162 @@
+---
+title: Use audit events to create then enforce WDAC policy rules (Windows 10)
+description: Learn how audits allow admins to discover apps, binaries, and scripts that should be added to a WDAC policy, then learn how to switch that WDAC policy from audit to enforced mode.
+keywords: security, malware
+ms.assetid: 8d6e0474-c475-411b-b095-1c61adb2bdbb
+ms.prod: m365-security
+ms.mktglfcycl: deploy
+ms.sitesec: library
+ms.pagetype: security
+ms.localizationpriority: medium
+audience: ITPro
+ms.collection: M365-security-compliance
+author: jsuther1974
+ms.reviewer: jogeurte
+ms.reviewer: v-kikl
+ms.author: dansimp
+manager: dansimp
+ms.date: 05/03/2021
+ms.technology: mde
+---
+
+# Use audit events to create WDAC policy rules and Convert **base** policy from audits to enforced
+
+**Applies to:**
+
+- Windows 10
+- Windows Server 2016 and above
+
+Running Application Control in audit mode lets you discover applications, binaries, and scripts that are missing from your WDAC policy but should be included.
+
+While a WDAC policy is running in audit mode, any binary that runs but would have been denied is logged in the **Applications and Services Logs\\Microsoft\\Windows\\CodeIntegrity\\Operational** event log. Script and MSI are logged in the **Applications and Services Logs\\Microsoft\\Windows\\AppLocker\\MSI and Script** event log. These events can be used to generate a new WDAC policy that can be merged with the original Base policy or deployed as a separate Supplemental policy, if allowed.
+
+## Overview of the process to create WDAC policy to allow apps using audit events
+
+> [!NOTE]
+> You must have already deployed a WDAC audit mode policy to use this process. If you have not already done so, see [Deploying Windows Defender Application Control policies](windows-defender-application-control-deployment-guide.md).
+
+To familiarize yourself with creating WDAC rules from audit events, follow these steps on a device with a WDAC audit mode policy.
+
+1. Install and run an application not allowed by the WDAC policy but that you want to allow.
+
+2. Review the **CodeIntegrity - Operational** and **AppLocker - MSI and Script** event logs to confirm events, like those shown in Figure 1, are generated related to the application. For information about the types of events you should see, refer to [Understanding Application Control events](event-id-explanations.md).
+
+ **Figure 1. Exceptions to the deployed WDAC policy**
+
+ 
+
+3. In an elevated PowerShell session, run the following commands to initialize variables used by this procedure. This procedure builds upon the **Lamna_FullyManagedClients_Audit.xml** policy introduced in [Create a WDAC policy for fully managed devices](create-wdac-policy-for-fully-managed-devices.md) and will produce a new policy called **EventsPolicy.xml**.
+
+ ```powershell
+ $PolicyName= "Lamna_FullyManagedClients_Audit"
+ $LamnaPolicy=$env:userprofile+"\Desktop\"+$PolicyName+".xml"
+ $EventsPolicy=$env:userprofile+"\Desktop\EventsPolicy.xml"
+ $EventsPolicyWarnings=$env:userprofile+"\Desktop\EventsPolicyWarnings.txt"
+ ```
+
+4. Use [New-CIPolicy](/powershell/module/configci/new-cipolicy) to generate a new WDAC policy from logged audit events. This example uses a **FilePublisher** file rule level and a **Hash** fallback level. Warning messages are redirected to a text file **EventsPolicyWarnings.txt**.
+
+ ```powershell
+ New-CIPolicy -FilePath $EventsPolicy -Audit -Level FilePublisher -Fallback Hash –UserPEs -MultiplePolicyFormat 3> $EventsPolicyWarnings
+ ```
+
+ > [!NOTE]
+ > When you create policies from audit events, you should carefully consider the file rule level that you select to trust. The preceding example uses the **FilePublisher** rule level with a fallback level of **Hash**, which may be more specific than desired. You can re-run the above command using different **-Level** and **-Fallback** options to meet your needs. For more information about WDAC rule levels, see [Understand WDAC policy rules and file rules](select-types-of-rules-to-create.md).
+
+5. Find and review the WDAC policy file **EventsPolicy.xml** that should be found on your desktop. Ensure that it only includes file and signer rules for applications, binaries, and scripts you wish to allow. You can remove rules by manually editing the policy XML or use the WDAC Policy Wizard tool (see [Editing existing base and supplemental WDAC policies with the Wizard](wdac-wizard-editing-policy.md)).
+
+6. Find and review the text file **EventsPolicyWarnings.txt** that should be found on your desktop. This file will include a warning for any files that WDAC couldn't create a rule for at either the specified rule level or fallback rule level.
+
+ > [!NOTE]
+ > New-CIPolicy only creates rules for files that can still be found on disk. Files which are no longer present on the system will not have a rule created to allow them. However, the event log should have sufficient information to allow these files by manually editing the policy XML to add rules. You can use an existing rule as a template and verify your results against the WDAC policy schema definition found at **%windir%\schemas\CodeIntegrity\cipolicy.xsd**.
+
+7. Merge **EventsPolicy.xml** with the Base policy **Lamna_FullyManagedClients_Audit.xml** or convert it to a supplemental policy.
+
+ For information on merging policies, refer to [Merge Windows Defender Application Control policies](merge-windows-defender-application-control-policies.md) and for information on supplemental policies see [Use multiple Windows Defender Application Control Policies](deploy-multiple-windows-defender-application-control-policies.md).
+
+8. Convert the Base or Supplemental policy to binary and deploy using your preferred method.
+
+## Convert WDAC **BASE** policy from audit to enforced
+
+As described in [common WDAC 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 responsible for Lamna's WDAC rollout.
+
+Alice previously created and deployed a policy for the organization's [fully managed devices](create-wdac-policy-for-fully-managed-devices.md). They updated the policy based on audit event data as described in [Use audit events to create WDAC policy rules](audit-windows-defender-application-control-policies.md) and redeployed it. All remaining audit events are as expected and Alice is ready to switch to enforcement mode.
+
+1. Initialize the variables that will be used and create the enforced policy by copying the audit version.
+
+ ```powershell
+ $EnforcedPolicyName = "Lamna_FullyManagedClients_Enforced"
+ $AuditPolicyXML = $env:USERPROFILE+"\Desktop\Lamna_FullyManagedClients_Audit.xml"
+ $EnforcedPolicyXML = $env:USERPROFILE+"\Desktop\"+$EnforcedPolicyName+".xml"
+ cp $AuditPolicyXML $EnforcedPolicyXML
+ ```
+
+2. Use [Set-CIPolicyIdInfo](/powershell/module/configci/set-cipolicyidinfo) to give the new policy a unique ID, and descriptive name. Changing the ID and name lets you deploy the enforced policy side by side with the audit policy. Do this step if you plan to harden your WDAC policy over time. If you prefer to replace the audit policy in-place, you can skip this step.
+
+ ```powershell
+ $EnforcedPolicyID = Set-CIPolicyIdInfo -FilePath $EnforcedPolicyXML -PolicyName $EnforcedPolicyName -ResetPolicyID
+ $EnforcedPolicyID = $EnforcedPolicyID.Substring(11)
+ ```
+
+ > [!NOTE]
+ > If Set-CIPolicyIdInfo does not output the new PolicyID value on your Windows 10 version, you will need to obtain the *PolicyId* value from the XML directly.
+
+3. *[Optionally]* Use [Set-RuleOption](/powershell/module/configci/set-ruleoption) to enable rule options 9 (“Advanced Boot Options Menu”) and 10 (“Boot Audit on Failure”). Option 9 allows users to disable WDAC enforcement for a single boot session from a pre-boot menu. Option 10 instructs Windows to switch the policy from enforcement to audit only if a boot critical kernel-mode driver is blocked. We strongly recommend these options when deploying a new enforced policy to your first deployment ring. Then, if no issues are found, you can remove the options and restart your deployment.
+
+ ```powershell
+ Set-RuleOption -FilePath $EnforcedPolicyXML -Option 9
+ Set-RuleOption -FilePath $EnforcedPolicyXML -Option 10
+ ```
+
+4. Use Set-RuleOption to delete the audit mode rule option, which changes the policy to enforcement:
+
+ ```powershell
+ Set-RuleOption -FilePath $EnforcedPolicyXML -Option 3 -Delete
+ ```
+
+5. Use [ConvertFrom-CIPolicy](/powershell/module/configci/convertfrom-cipolicy) to convert the new WDAC policy to binary:
+
+ > [!NOTE]
+ > If you did not use -ResetPolicyID in Step 2 above, then you must replace $EnforcedPolicyID in the following command with the *PolicyID* attribute found in your base policy XML.
+
+ ```powershell
+ $EnforcedPolicyBinary = $env:USERPROFILE+"\Desktop\"+$EnforcedPolicyName+"_"+$EnforcedPolicyID+".xml"
+ ConvertFrom-CIPolicy $EnforcedPolicyXML $EnforcedPolicyBinary
+ ```
+
+## Make copies of any needed **supplemental** policies to use with the enforced base policy
+
+Since the enforced policy was given a unique PolicyID in the previous procedure, you need to duplicate any needed supplemental policies to use with the enforced policy. Supplemental policies always inherit the Audit or Enforcement mode from the base policy they modify. If you didn't reset the enforcement base policy's PolicyID, you can skip this procedure.
+
+1. Initialize the variables that will be used and create a copy of the current supplemental policy. Some variables and files from the previous procedure will also be used.
+
+ ```powershell
+ $SupplementalPolicyName = "Lamna_Supplemental1"
+ $CurrentSupplementalPolicy = $env:USERPROFILE+"\Desktop\"+$SupplementalPolicyName+"_Audit.xml"
+ $EnforcedSupplementalPolicy = $env:USERPROFILE+"\Desktop\"+$SupplementalPolicyName+"_Enforced.xml"
+ ```
+
+2. Use [Set-CIPolicyIdInfo](/powershell/module/configci/set-cipolicyidinfo) to give the new supplemental policy a unique ID and descriptive name, and change which base policy to supplement.
+
+ ```powershell
+ $SupplementalPolicyID = Set-CIPolicyIdInfo -FilePath $EnforcedSupplementalPolicy -PolicyName $SupplementalPolicyName -SupplementsBasePolicyID $EnforcedPolicyID -BasePolicyToSupplementPath $EnforcedPolicyXML -ResetPolicyID
+ $SupplementalPolicyID = $SupplementalPolicyID.Substring(11)
+ ```
+
+ > [!NOTE]
+ > If Set-CIPolicyIdInfo does not output the new PolicyID value on your Windows 10 version, you will need to obtain the *PolicyId* value from the XML directly.
+
+3. Use [ConvertFrom-CIPolicy](/powershell/module/configci/convertfrom-cipolicy) to convert the new WDAC supplemental policy to binary:
+
+ ```powershell
+ $EnforcedSuppPolicyBinary = $env:USERPROFILE+"\Desktop\"+$SupplementalPolicyName+"_"+$SupplementalPolicyID+".xml"
+ ConvertFrom-CIPolicy $EnforcedSupplementalPolicy $EnforcedSuppPolicyBinary
+ ```
+
+4. Repeat the steps above if you have other supplemental policies to update.
+
+## Deploy your enforced policy and supplemental policies
+
+Now that your base policy is in enforced mode, you can begin to deploy it to your managed endpoints. For information about deploying policies, see [Deploying Windows Defender Application Control (WDAC) policies](windows-defender-application-control-deployment-guide.md).
diff --git a/windows/security/threat-protection/windows-defender-application-control/configure-authorized-apps-deployed-with-a-managed-installer.md b/windows/security/threat-protection/windows-defender-application-control/configure-authorized-apps-deployed-with-a-managed-installer.md
new file mode 100644
index 0000000000..6612e9fbf7
--- /dev/null
+++ b/windows/security/threat-protection/windows-defender-application-control/configure-authorized-apps-deployed-with-a-managed-installer.md
@@ -0,0 +1,194 @@
+---
+title: Configure authorized apps deployed with a WDAC managed installer (Windows 10)
+description: Explains how to configure a custom Manged Installer.
+keywords: security, malware
+ms.assetid: 8d6e0474-c475-411b-b095-1c61adb2bdbb
+ms.prod: m365-security
+ms.mktglfcycl: deploy
+ms.sitesec: library
+ms.pagetype: security
+ms.localizationpriority: medium
+audience: ITPro
+ms.collection: M365-security-compliance
+author: jsuther1974
+ms.reviewer: isbrahm
+ms.author: dansimp
+manager: dansimp
+ms.date: 08/14/2020
+ms.technology: mde
+---
+
+# Configuring authorized apps deployed by a managed installer with AppLocker and Windows Defender Application Control
+
+**Applies to:**
+
+- Windows 10
+- Windows Server 2019
+
+Windows 10, version 1703 introduced a new option for Windows Defender Application Control (WDAC), called managed installer, that helps balance security and manageability when enforcing application control policies. This option lets you automatically allow applications installed by a designated software distribution solution such as Microsoft Endpoint Configuration Manager.
+
+## How does a managed installer work?
+
+A new rule collection in AppLocker specifies binaries that are trusted by the organization as an authorized source for application deployment. When one of these binaries runs, Windows will monitor the binary's process (and processes it launches) then tag all files it writes as having originated from a managed installer. The managed installer rule collection is configured using Group Policy and can be applied with the Set-AppLockerPolicy PowerShell cmdlet. You can't currently set managed installers with the AppLocker CSP through MDM.
+
+Having defined your managed installers using AppLocker, you can then configure WDAC to trust files installed by a managed installer by adding the "Enabled:Managed Installer" option to your WDAC policy. Once that option is set, WDAC will check for managed installer origin information when determining whether or not to allow a binary to run. As long as there are no deny rules present for the file, WDAC will allow a file to run based on its managed installer origin.
+
+You should ensure that the WDAC policy allows the system/boot components and any other authorized applications that can't be deployed through a managed installer.
+
+## Security considerations with managed installer
+
+Since managed installer is a heuristic-based mechanism, it doesn't provide the same security guarantees that explicit allow or deny rules do.
+It is best suited for use where each user operates as a standard user and where all software is deployed and installed by a software distribution solution, such as Microsoft Endpoint Configuration Manager (MEMCM).
+
+Users with administrator privileges, or malware running as an administrator user on the system, may be able to circumvent the intent of Windows Defender Application Control when the managed installer option is allowed.
+
+If a managed installer process runs in the context of a user with standard privileges, then it is possible that standard users or malware running as standard user may be able to circumvent the intent of Windows Defender Application Control.
+
+Some application installers may automatically run the application at the end of the installation process. If this happens when the installer is run by a managed installer, then the managed installer's heuristic tracking and authorization will extend to all files created during the first run of the application. This could result in over-authorization for executables that were not intended. To avoid that outcome, ensure that the application deployment solution used as a managed installer limits running applications as part of installation.
+
+## Known limitations with managed installer
+
+- Application control, based on managed installer, does not support applications that self-update. If an application deployed by a managed installer later updates itself, the updated application files won't include the managed installer origin information, and may not be able to run. When you rely on managed installers, you must deploy and install all application updates using a managed installer, or include rules to authorize the app in the WDAC policy. In some cases, it may be possible to also designate an application binary that performs self-updates as a managed installer. Proper review for functionality and security should be performed for the application before using this method.
+
+- [Packaged apps (MSIX)](/windows/msix/) deployed through a managed installer aren't tracked by the managed installer heuristic and will need to be separately authorized in your WDAC policy. See [Manage packaged apps with WDAC](manage-packaged-apps-with-windows-defender-application-control.md).
+
+- Some applications or installers may extract, download, or generate binaries and immediately attempt to run them. Files run by such a process may not be allowed by the managed installer heuristic. In some cases, it may be possible to also designate an application binary that performs such an operation as a managed installer. Proper review for functionality and security should be performed for the application before using this method.
+
+- The managed installer heuristic doesn't authorize kernel drivers. The WDAC policy must have rules that allow the necessary drivers to run.
+
+## Configuring the managed installer
+
+Setting up managed installer tracking and application execution enforcement requires applying both an AppLocker and WDAC policy, with specific rules and options enabled.
+There are three primary steps to keep in mind:
+
+- Specify managed installers, by using the Managed Installer rule collection in AppLocker policy.
+- Enable service enforcement in AppLocker policy.
+- Enable the managed installer option in a WDAC policy.
+
+## Specify managed installers using the Managed Installer rule collection in AppLocker policy
+
+The identity of the managed installer executable(s) is specified in an AppLocker policy, in a Managed Installer rule collection.
+
+### Create Managed Installer rule collection
+
+Currently, neither the AppLocker policy creation UI in GPO Editor nor the PowerShell cmdlets allow for directly specifying rules for the Managed Installer rule collection. However, you can use a text editor to make the simple changes needed to an EXE or DLL rule collection policy, to specify Type="ManagedInstaller", so that the new rule can be imported into a GPO.
+
+1. Use [New-AppLockerPolicy](/powershell/module/applocker/new-applockerpolicy?view=win10-ps) to make an EXE rule for the file you are designating as a managed installer. Note that only EXE file types can be designated as managed installers. Below is an example using the rule type Publisher with a hash fallback but other rule types can be used as well. You may need to reformat the output for readability.
+
+ ```powershell
+ Get-ChildItem
- See [security considerations with managed installer](use-windows-defender-application-control-with-managed-installer.md#security-considerations-with-managed-installer)
+ See [security considerations with managed installer](configure-authorized-apps-deployed-with-a-managed-installer.md#security-considerations-with-managed-installer)
Existing mitigations applied:
- Limit who can elevate to administrator on the device.
diff --git a/windows/security/threat-protection/windows-defender-application-control/create-wdac-policy-for-lightly-managed-devices.md b/windows/security/threat-protection/windows-defender-application-control/create-wdac-policy-for-lightly-managed-devices.md
index 08e82cbe13..c4dabcde4c 100644
--- a/windows/security/threat-protection/windows-defender-application-control/create-wdac-policy-for-lightly-managed-devices.md
+++ b/windows/security/threat-protection/windows-defender-application-control/create-wdac-policy-for-lightly-managed-devices.md
@@ -155,7 +155,7 @@ In order to minimize user productivity impact, Alice has defined a policy that m
- Use signed WDAC policies and UEFI BIOS access protection to prevent tampering of WDAC policies.
- Limit who can elevate to administrator on the device.
- **Managed installer**
- See [security considerations with managed installer](use-windows-defender-application-control-with-managed-installer.md#security-considerations-with-managed-installer)
+ See [security considerations with managed installer](configure-authorized-apps-deployed-with-a-managed-installer.md#security-considerations-with-managed-installer)
Possible mitigations:
- Create and deploy signed catalog files as part of the app deployment process in order to remove the requirement for managed installer.
diff --git a/windows/security/threat-protection/windows-defender-application-control/deployment/deploy-wdac-policies-with-script.md b/windows/security/threat-protection/windows-defender-application-control/deployment/deploy-wdac-policies-with-script.md
index 3aed014401..a0308dfadc 100644
--- a/windows/security/threat-protection/windows-defender-application-control/deployment/deploy-wdac-policies-with-script.md
+++ b/windows/security/threat-protection/windows-defender-application-control/deployment/deploy-wdac-policies-with-script.md
@@ -52,6 +52,20 @@ This topic describes how to deploy Windows Defender Application Control (WDAC) p
& $RefreshPolicyTool
```
+### Deploying signed policies
+
+In addition to the steps outlined above, the binary policy file must also be copied to the device's EFI partition. Deploying your policy via [MEM](deploy-windows-defender-application-control-policies-using-intune.md) or the [Application Control CSP](#Deploying-multiple-policies-via-ApplicationControl-CSP) will handle this step automatically.
+
+1. Mount the EFI volume and make the directory, if it does not exist, in an elevated PowerShell prompt:
+```powershell
+mountvol J: /S
+J:
+mkdir J:\EFI\Microsoft\Boot\CiPolicies\Active
+```
+
+2. Copy the signed policy binary as `{PolicyGUID}.cip` to J:\EFI\Microsoft\Boot\CiPolicies\Active
+3. Reboot the system.
+
## Script-based deployment process for Windows 10 versions earlier than 1903
1. Initialize the variables to be used by the script.
diff --git a/windows/security/threat-protection/windows-defender-application-control/enforce-windows-defender-application-control-policies.md b/windows/security/threat-protection/windows-defender-application-control/enforce-windows-defender-application-control-policies.md
index 784baf06c2..6c3b04eb5a 100644
--- a/windows/security/threat-protection/windows-defender-application-control/enforce-windows-defender-application-control-policies.md
+++ b/windows/security/threat-protection/windows-defender-application-control/enforce-windows-defender-application-control-policies.md
@@ -52,8 +52,6 @@ Alice previously created and deployed a policy for the organization's [fully man
$EnforcedPolicyID = $EnforcedPolicyID.Substring(11)
```
- > [!NOTE]
- > If Set-CIPolicyIdInfo does not output the new PolicyID value on your Windows 10 version, you will need to obtain the *PolicyId* value from the XML directly.
3. *[Optionally]* Use [Set-RuleOption](/powershell/module/configci/set-ruleoption) to enable rule options 9 (“Advanced Boot Options Menu”) and 10 (“Boot Audit on Failure”). Option 9 allows users to disable WDAC enforcement for a single boot session from a pre-boot menu. Option 10 instructs Windows to switch the policy from enforcement to audit only if a boot critical kernel-mode driver is blocked. We strongly recommend these options when deploying a new enforced policy to your first deployment ring. Then, if no issues are found, you can remove the options and restart your deployment.
@@ -74,7 +72,7 @@ Alice previously created and deployed a policy for the organization's [fully man
> If you did not use -ResetPolicyID in Step 2 above, then you must replace $EnforcedPolicyID in the following command with the *PolicyID* attribute found in your base policy XML.
```powershell
- $EnforcedPolicyBinary = $env:USERPROFILE+"\Desktop\"+$EnforcedPolicyName+"_"+$EnforcedPolicyID+".xml"
+ $EnforcedPolicyBinary = $env:USERPROFILE+"\Desktop\"+$EnforcedPolicyID+".cip"
ConvertFrom-CIPolicy $EnforcedPolicyXML $EnforcedPolicyBinary
```
diff --git a/windows/security/threat-protection/windows-defender-application-control/event-id-explanations.md b/windows/security/threat-protection/windows-defender-application-control/event-id-explanations.md
index b464707f61..e0c8044cf1 100644
--- a/windows/security/threat-protection/windows-defender-application-control/event-id-explanations.md
+++ b/windows/security/threat-protection/windows-defender-application-control/event-id-explanations.md
@@ -22,33 +22,33 @@ ms.technology: mde
A Windows Defender Application Control (WDAC) policy logs events locally in Windows Event Viewer in either enforced or audit mode. These events are generated under two locations:
- - Event IDs beginning with 30 appear in Applications and Services logs – Microsoft – Windows – CodeIntegrity – Operational
+- Event IDs beginning with 30 appear in Applications and Services logs | Microsoft | Windows | CodeIntegrity | Operational
- - Event IDs beginning with 80 appear in Applications and Services logs – Microsoft – Windows – AppLocker – MSI and Script
+- Event IDs beginning with 80 appear in Applications and Services logs | Microsoft | Windows | AppLocker | MSI and Script
## Microsoft Windows CodeIntegrity Operational log event IDs
| Event ID | Explanation |
-|----------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+|---|----------|
| 3076 | Audit executable/dll file |
| 3077 | Block executable/dll file |
-| 3089 | Signing information event correlated with either a 3076 or 3077 event. One 3089 event is generated for each signature of a file. Contains the total number of signatures on a file and an index as to which signature it is.
Unsigned files will generate a single 3089 event with TotalSignatureCount 0. Correlated in the "System" portion of the event data under "Correlation ActivityID". |
+| 3089 | Signing information event correlated with either a 3076 or 3077 event. One 3089 event is generated for each signature of a file. Contains the total number of signatures on a file and an index as to which signature it is. Unsigned files will generate a single 3089 event with TotalSignatureCount 0. Correlated in the "System" portion of the event data under "Correlation ActivityID". |
| 3099 | Indicates that a policy has been loaded |
## Microsoft Windows Applocker MSI and Script log event IDs
| Event ID | Explanation |
-|----------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+|---|----------|
| 8028 | Audit script/MSI file generated by Windows LockDown Policy (WLDP) being called by the scripthosts themselves. Note: there is no WDAC enforcement on 3rd party scripthosts. |
| 8029 | Block script/MSI file |
| 8038 | Signing information event correlated with either a 8028 or 8029 event. One 8038 event is generated for each signature of a script file. Contains the total number of signatures on a script file and an index as to which signature it is. Unsigned script files will generate a single 8038 event with TotalSignatureCount 0. Correlated in the "System" portion of the event data under "Correlation ActivityID". | |
## Optional Intelligent Security Graph (ISG) or Managed Installer (MI) diagnostic events
-If either the ISG or MI is enabled in a WDAC policy, you can optionally choose to enable 3090, 3091, and 3092 events to provide additional diagnostic information.
+If either the ISG or MI is enabled in a WDAC policy, you can optionally choose to enable 3090, 3091, and 3092 events to provide additional diagnostic information.
| Event ID | Explanation |
-|----------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+|---|----------|
| 3090 | Allow executable/dll file |
| 3091 | Audit executable/dll file |
| 3092 | Block executable/dll file |
@@ -60,7 +60,7 @@ If either the ISG or MI is enabled in a WDAC policy, you can optionally choose t
Below are the fields which help to diagnose what a 3090, 3091, or 3092 event indicates.
| Name | Explanation |
-|-------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+|---|----------|
| StatusCode | STATUS_SUCCESS indicates a binary passed the active WDAC policies. If so, a 3090 event is generated. If not, a 3091 event is generated if the blocking policy is in audit mode, and a 3092 event is generated if the policy is in enforce mode. |
| ManagedInstallerEnabled | Policy trusts a MI |
| PassesManagedInstaller | File originated from a trusted MI |
@@ -75,7 +75,7 @@ In order to enable 3091 audit events and 3092 block events, you must create a Te
```powershell
reg add hklm\system\currentcontrolset\control\ci -v TestFlags -t REG_DWORD -d 0x100
```
-
+
In order to enable 3090 allow events as well as 3091 and 3092 events, you must instead create a TestFlags regkey with a value of 0x300. You can do so using the following PowerShell command:
```powershell
diff --git a/windows/security/threat-protection/windows-defender-application-control/event-tag-explanations.md b/windows/security/threat-protection/windows-defender-application-control/event-tag-explanations.md
index 6ee1d70486..76084853c5 100644
--- a/windows/security/threat-protection/windows-defender-application-control/event-tag-explanations.md
+++ b/windows/security/threat-protection/windows-defender-application-control/event-tag-explanations.md
@@ -27,13 +27,14 @@ Windows Defender Application Control (WDAC) events include a number of fields wh
Represents the type of signature which verified the image.
| SignatureType Value | Explanation |
-|----------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+|---|----------|
| 0 | Unsigned or verification has not been attempted |
| 1 | Embedded signature |
| 2 | Cached signature; presence of CI EA shows that file had been previously verified |
+| 3 | Cached catalog verified via Catalog Database or searching catalog directly |
| 4 | Un-cached catalog verified via Catalog Database or searching catalog directly |
| 5 | Successfully verified using an EA that informs CI which catalog to try first |
-|6 | AppX / MSIX package catalog verified |
+| 6 | AppX / MSIX package catalog verified |
| 7 | File was verified |
## ValidatedSigningLevel
@@ -41,7 +42,7 @@ Represents the type of signature which verified the image.
Represents the signature level at which the code was verified.
| ValidatedSigningLevel Value | Explanation |
-|----------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+|---|----------|
| 0 | Signing level has not yet been checked |
| 1 | File is unsigned |
| 2 | Trusted by WDAC policy |
@@ -60,16 +61,22 @@ Represents the signature level at which the code was verified.
Represents why verification failed, or if it succeeded.
| VerificationError Value | Explanation |
-|----------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+|---|----------|
| 0 | Successfully verified signature |
+| 1 | File has an invalid hash |
| 2 | File contains shared writable sections |
+| 3 | File is not signed|
| 4 | Revoked signature |
| 5 | Expired signature |
+| 6 | File is signed using a weak hashing algorithm which does not meet the minimum policy |
| 7 | Invalid root certificate |
| 8 | Signature was unable to be validated; generic error |
| 9 | Signing time not trusted |
+| 10 | The file must be signed using page hashes for this scenario |
+| 11 | Page hash mismatch |
| 12 | Not valid for a PPL (Protected Process Light) |
| 13 | Not valid for a PP (Protected Process) |
+| 14 | The signature is missing the required ARM EKU |
| 15 | Failed WHQL check |
| 16 | Default policy signing level not met |
| 17 | Custom policy signing level not met; returned when signature doesn't validate against an SBCP-defined set of certs |
@@ -80,5 +87,35 @@ Represents why verification failed, or if it succeeded.
| 22 | Not IUM (Isolated User Mode) signed; indicates trying to load a non-trustlet binary into a trustlet |
| 23 | Invalid image hash |
| 24 | Flight root not allowed; indicates trying to run flight-signed code on production OS |
+| 25 | Anti-cheat policy violation |
| 26 | Explicitly denied by WADC policy |
+| 27 | The signing chain appears to be tampered/invalid |
| 28 | Resource page hash mismatch |
+
+## Microsoft Root CAs trusted by Windows
+
+The rule means trust anything signed by a certificate that chains to this root CA.
+| Root ID | Root Name |
+|---|----------|
+| 0| None |
+| 1| Unknown |
+| 2 | Self-Signed |
+| 3 | Authenticode |
+| 4 | Microsoft Product Root 1997 |
+| 5 | Microsoft Product Root 2001 |
+| 6 | Microsoft Product Root 2010 |
+| 7 | Microsoft Standard Root 2011 |
+| 8 | Microsoft Code Verification Root 2006 |
+| 9 | Microsoft Test Root 1999 |
+| 10 | Microsoft Test Root 2010 |
+| 11 | Microsoft DMD Test Root 2005 |
+| 12 | Microsoft DMDRoot 2005 |
+| 13 | Microsoft DMD Preview Root 2005 |
+| 14 | Microsoft Flight Root 2014 |
+| 15 | Microsoft Third Party Marketplace Root |
+| 16 | Microsoft ECC Testing Root CA 2017 |
+| 17 | Microsoft ECC Development Root CA 2018 |
+| 18 | Microsoft ECC Product Root CA 2018 |
+| 19 | Microsoft ECC Devices Root CA 2017 |
+
+For well-known roots, the TBS hashes for the certificates are baked into the code for WDAC. For example, they don’t need to be listed as TBS hashes in the policy file.
\ No newline at end of file
diff --git a/windows/security/threat-protection/windows-defender-application-control/feature-availability.md b/windows/security/threat-protection/windows-defender-application-control/feature-availability.md
index 3f411ffb3e..16dd454c61 100644
--- a/windows/security/threat-protection/windows-defender-application-control/feature-availability.md
+++ b/windows/security/threat-protection/windows-defender-application-control/feature-availability.md
@@ -34,7 +34,7 @@ ms.technology: mde
| Per-User and Per-User group rules | Not available (policies are device-wide) | Available on Windows 8+ |
| Kernel mode policies | Available on all Windows 10 versions | Not available |
| Per-app rules | [Available on 1703+](./use-windows-defender-application-control-policy-to-control-specific-plug-ins-add-ins-and-modules.md) | Not available |
-| Managed Installer (MI) | [Available on 1703+](./use-windows-defender-application-control-with-managed-installer.md) | Not available |
+| Managed Installer (MI) | [Available on 1703+](./configure-authorized-apps-deployed-with-a-managed-installer.md) | Not available |
| Reputation-Based intelligence | [Available on 1709+](./use-windows-defender-application-control-with-intelligent-security-graph.md) | Not available |
| Multiple policy support | [Available on 1903+](./deploy-multiple-windows-defender-application-control-policies.md) | Not available |
| Path-based rules | [Available on 1903+.](./select-types-of-rules-to-create.md#more-information-about-filepath-rules) Exclusions are not supported. Runtime user-writeability check enforced by default. | Available on Windows 8+. Exclusions are supported. No runtime user-writeability check. |
diff --git a/windows/security/threat-protection/windows-defender-application-control/plan-windows-defender-application-control-management.md b/windows/security/threat-protection/windows-defender-application-control/plan-windows-defender-application-control-management.md
index 7924b31d89..a9cd8c8585 100644
--- a/windows/security/threat-protection/windows-defender-application-control/plan-windows-defender-application-control-management.md
+++ b/windows/security/threat-protection/windows-defender-application-control/plan-windows-defender-application-control-management.md
@@ -59,7 +59,7 @@ In addition, we recommend using the [Set-CIPolicyVersion](/powershell/module/con
### 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](use-windows-defender-application-control-with-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 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.
## WDAC event management
diff --git a/windows/security/threat-protection/windows-defender-application-control/select-types-of-rules-to-create.md b/windows/security/threat-protection/windows-defender-application-control/select-types-of-rules-to-create.md
index 1314fa6e21..add268e0ee 100644
--- a/windows/security/threat-protection/windows-defender-application-control/select-types-of-rules-to-create.md
+++ b/windows/security/threat-protection/windows-defender-application-control/select-types-of-rules-to-create.md
@@ -63,7 +63,7 @@ You can set several rule options within a WDAC policy. Table 1 describes each ru
| **10 Enabled:Boot Audit on Failure** | Used when the WDAC policy is in enforcement mode. When a driver fails during startup, the WDAC policy will be placed in audit mode so that Windows will load. Administrators can validate the reason for the failure in the CodeIntegrity event log. |
| **11 Disabled: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 supported on 1709, 1803, and 1809 builds with the 2019 10C LCU or higher, and on devices with the Windows 10 May 2019 Update (1903) and higher. Using it on versions of Windows 10 without the proper update may have unintended results. |
| **12 Required:Enforce Store Applications** | If this rule option is enabled, WDAC policies will also apply to Universal Windows applications. |
-| **13 Enabled:Managed Installer** | Use this option to automatically allow applications installed by a managed installer. For more information, see [Authorize apps deployed with a WDAC managed installer](use-windows-defender-application-control-with-managed-installer.md) |
+| **13 Enabled:Managed Installer** | Use this option to automatically allow applications installed by a managed installer. For more information, see [Authorize apps deployed with a WDAC managed installer](configure-authorized-apps-deployed-with-a-managed-installer.md) |
| **14 Enabled:Intelligent Security Graph Authorization** | Use this option to automatically allow applications with "known good" reputation as defined by Microsoft’s Intelligent Security Graph (ISG). |
| **15 Enabled: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.|
| **16 Enabled:Update Policy No Reboot** | Use this option to allow future WDAC policy updates to apply without requiring a system reboot. NOTE: This option is only supported on Windows 10, version 1709, and above.|
@@ -126,6 +126,19 @@ Wildcards can be used at the beginning or end of a path rule; only one wildcard
You can also use the following macros when the exact volume may vary: `%OSDRIVE%`, `%WINDIR%`, `%SYSTEM32%`.
+## More information about hashes
+
+### 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 would not 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.
+
+### Why does scan create eight hash rules for certain XML files?
+
+Separate rules are created for UMCI and KMCI. In some cases, files which are purely user-mode or purely kernel-mode may still generate both sets, as CI cannot always precisely determine what is purely user vs. kernel mode and errs on the side of caution.
+
## Windows Defender Application Control filename rules
File name rule levels let you specify file attributes to base a rule on. File name rules provide the same security guarantees that explicit signer rules do, as they are based on non-mutable file attributes. Specification of the file name level occurs when creating new policy rules.
diff --git a/windows/security/threat-protection/windows-defender-application-control/understand-windows-defender-application-control-policy-design-decisions.md b/windows/security/threat-protection/windows-defender-application-control/understand-windows-defender-application-control-policy-design-decisions.md
index 9443134723..9bd69f5bee 100644
--- a/windows/security/threat-protection/windows-defender-application-control/understand-windows-defender-application-control-policy-design-decisions.md
+++ b/windows/security/threat-protection/windows-defender-application-control/understand-windows-defender-application-control-policy-design-decisions.md
@@ -58,7 +58,7 @@ Organizations with well-defined, centrally-managed app management and deployment
| Possible answers | Design considerations|
| - | - |
-| All apps are centrally managed and deployed using endpoint management tools like [Microsoft Endpoint Manager](https://www.microsoft.com/microsoft-365/microsoft-endpoint-manager). | Organizations that centrally manage all apps are best-suited for application control. WDAC options like [managed installer](use-windows-defender-application-control-with-managed-installer.md) can make it easy to authorize apps that are deployed by the organization's app distribution management solution. |
+| All apps are centrally managed and deployed using endpoint management tools like [Microsoft Endpoint Manager](https://www.microsoft.com/microsoft-365/microsoft-endpoint-manager). | Organizations that centrally manage all apps are best-suited for application control. WDAC options like [managed installer](configure-authorized-apps-deployed-with-a-managed-installer.md) can make it easy to authorize apps that are deployed by the organization's app distribution management solution. |
| Some apps are centrally managed and deployed, but teams can install additional apps for their members. | [Supplemental policies](deploy-multiple-windows-defender-application-control-policies.md) can be used to allow team-specific exceptions to your core organization-wide WDAC policy. Alternatively, teams can leverage managed installers to install their team-specific apps or admin-only file path rules can be used to allow apps installed by admin users. |
| Users and teams are free to download and install apps but the organization wants to restrict that right to prevalent and reputable apps only. | WDAC can integrate with Microsoft's [Intelligent Security Graph](use-windows-defender-application-control-with-intelligent-security-graph.md) (the same source of intelligence that powers Microsoft Defender Antivirus and Windows Defender SmartScreen) to allow only apps and binaries that have positive reputation. |
| Users and teams are free to download and install apps without restriction. | WDAC policies can be deployed in audit mode to gain insight into the apps and binaries running in your organization without impacting user and team productivity.|
diff --git a/windows/security/threat-protection/windows-defender-application-control/use-signed-policies-to-protect-windows-defender-application-control-against-tampering.md b/windows/security/threat-protection/windows-defender-application-control/use-signed-policies-to-protect-windows-defender-application-control-against-tampering.md
index a654d57870..498c736696 100644
--- a/windows/security/threat-protection/windows-defender-application-control/use-signed-policies-to-protect-windows-defender-application-control-against-tampering.md
+++ b/windows/security/threat-protection/windows-defender-application-control/use-signed-policies-to-protect-windows-defender-application-control-against-tampering.md
@@ -37,7 +37,7 @@ Before signing WDAC policies for the first time, be sure to enable rule options
To sign a WDAC policy with SignTool.exe, you need the following components:
-- SignTool.exe, found in the Windows SDK (Windows 7 or later)
+- 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
@@ -47,26 +47,29 @@ If you do not have a code signing certificate, see [Optional: Create a code sign
1. Initialize the variables that will be used:
- `$CIPolicyPath=$env:userprofile+"\Desktop\"`
-
- `$InitialCIPolicy=$CIPolicyPath+"InitialScan.xml"`
-
- `$CIPolicyBin=$CIPolicyPath+"DeviceGuardPolicy.bin"`
+ ```powershell
+ $CIPolicyPath=$env:userprofile+"\Desktop\"
+ $InitialCIPolicy=$CIPolicyPath+"InitialScan.xml"
+ ```
> [!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** and **$CIPolicyBin** variables with the correct information.
+ > This example uses the WDAC policy that you created in the [Create a Windows Defender Application Control policy from a reference computer](create-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).
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.
4. Navigate to your desktop as the working directory:
-
- `cd $env:USERPROFILE\Desktop`
+
+ ```powershell
+ cd $env:USERPROFILE\Desktop
+ ```
5. Use [Add-SignerRule](/powershell/module/configci/add-signerrule) to add an update signer certificate to the WDAC policy:
- `Add-SignerRule -FilePath $InitialCIPolicy -CertificatePath