From aa2b2bb21c6282298361130c8960ea6c283a9099 Mon Sep 17 00:00:00 2001 From: Kim Klein Date: Mon, 3 May 2021 14:31:48 -0700 Subject: [PATCH 01/27] Creating Test TOC This is a test to see how the landing page will look without having changed the original landing page. --- .../TOC2.yml | 113 ++++++++++++++++++ 1 file changed, 113 insertions(+) create mode 100644 windows/security/threat-protection/windows-defender-application-control/TOC2.yml diff --git a/windows/security/threat-protection/windows-defender-application-control/TOC2.yml b/windows/security/threat-protection/windows-defender-application-control/TOC2.yml new file mode 100644 index 0000000000..cbd308449b --- /dev/null +++ b/windows/security/threat-protection/windows-defender-application-control/TOC2.yml @@ -0,0 +1,113 @@ + +### WDAC:Landing +title: Application Control for Windows +metadata: + title: Application Control for Windows + description: Landing page for Windows Defender Application Control +# services: service +# ms.service: microsoft-WDAC-AppLocker +# ms.subservice: Application-Control +# ms.topic: landing-page +# author: Kim Klein +# ms.author: Jordan Geurten +# manager: Jeffrey Sutherland +# ms.update: 04/30/2021 +# linkListType: overview | how-to-guide | tutorial | video +landingContent: +# Cards and links should be based on top customer tasks or top subjects +# Start card title with a verb + # Card + - title: Learn about Application Control + linkLists: + - linkListType: overview + links: + - text: What is WDAC (WDAC Overview)? + url: wdac-and-applocker-overview.md + - text: What is AppLocker? + url: applocker\applocker-overview.md + - text: WDAC and AppLocker feature availability + url: feature-availability.md + # Card + - title: Learn about the Design Guide + linkLists: + - linkListType: overview + links: + - text: Using code signing to simplify application control + url: use-code-signing-to-simplify-application-control-for-classic-windows-applications.md + - text: Merging Policies + url: wdac-wizard-merging-policies.md + - text: Recommended blocks + url: microsoft-recommended-block-rules.md #there are block rules and driver block rules, which link? + - text: Example policies + url: example-wdac-base-policies.md + - text: LOB Win32 apps on S Mode + url: LOB-win32-apps-on-s.md + - linkListType: how-to-guide + links: + - text: Create a WDAC policy for a lightly managed device + url: cardreate-wdac-policy-for-lightly-managed-devices.md + - text: Create a WDAC policy for a fully managed device + url: create-wdac-policy-for-fully-managed-devices.md + - text: Create a WDAC policy for a fixed-workload + url: create-initial-default-policy.md + - text: Using catalog files + url: deploy-catalog-files-to-support-windows-defender-application-control.md + - text: WDAC Wizard tool + url: wdac-wizard.md + - linkListType: Tutorial (videos) + links: + - text: Using the WDAC Wizard + url: video md + - text: Specifying custom values + url: video md + # Card + - title: Learn about Policy Configuration + linkLists: + - linkListType: overview + links: + - text: Understanding policy rules + url: + - text: Understanding File rules + url: + - linkListType: how-to-guide (written) + links: + - text: Allow managed installer and configure managed installer rules + url: use-windows-defender-application-control-with-managed-installer.md + - text: Allow reputable apps with ISG + url: use-windows-defender-application-control-with-intelligent-security-graph.md + # Card + - title: Learn how to deploy WDAC Policies + linkLists: + - linkListType: overview + links: + - text: Signed policies + url: use-signed-policies-to-protect-windows-defender-application-control-against-tampering.md + - text: Audit and enforce policies + url: audit-windows-defender-application-control-policies.md #(merge with enforce-windows-defender-application-control-policies.md) + - text: Disabling WDAC policies + url: disable-windows-defender-application-control-policies.md + - linkListType: tutorial + links: + - text: Deployment with MDM + url: deploy-windows-defender-application-control-policies-using-intune.md + - text: Deployment with MEMCM + url: deployment/deploy-wdac-policies-with-memcm.md + - text: Deployment with script and refresh policy + url: deployment/deploy-wdac-policies-with-script.md + # Card + - title: Learn how to monitor and reiterate WDAC Policies (operational) + linkLists: + - linkListType: overview + links: + - text: Event logs (tags, IDs) + url: event-id-explanations.md #(merge with event-tag-explanations.md) + - text: Advanced hunting + url: querying-application-control-events-centrally-using-advanced-hunting.md #same as below + - linkListType: how-to-guide + links: + - text: Querying using advanced hunting + url: querying-application-control-events-centrally-using-advanced-hunting.md #same as above + - linkListType: tutorial + links: + - text: Creating a policy from event logs + url: querying-application-control-events-centrally-using-advanced-hunting.md #same as above \ No newline at end of file From 722f7ee58d424e1ab7068d71d9d1bca4b93a9a8a Mon Sep 17 00:00:00 2001 From: Kim Klein Date: Wed, 5 May 2021 16:27:20 -0700 Subject: [PATCH 02/27] Update TOC2.yml Made a small update. --- .../windows-defender-application-control/TOC2.yml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/windows/security/threat-protection/windows-defender-application-control/TOC2.yml b/windows/security/threat-protection/windows-defender-application-control/TOC2.yml index cbd308449b..e8a04d9f6b 100644 --- a/windows/security/threat-protection/windows-defender-application-control/TOC2.yml +++ b/windows/security/threat-protection/windows-defender-application-control/TOC2.yml @@ -27,7 +27,7 @@ landingContent: url: applocker\applocker-overview.md - text: WDAC and AppLocker feature availability url: feature-availability.md - # Card + # Card - title: Learn about the Design Guide linkLists: - linkListType: overview @@ -37,7 +37,7 @@ landingContent: - text: Merging Policies url: wdac-wizard-merging-policies.md - text: Recommended blocks - url: microsoft-recommended-block-rules.md #there are block rules and driver block rules, which link? + url: microsoft-recommended-block-rules.md #there are block rules and driver block rules, which link? Add both, actually. - text: Example policies url: example-wdac-base-policies.md - text: LOB Win32 apps on S Mode From 1afb27049feb753e6f137b00a05964f9ec70caa8 Mon Sep 17 00:00:00 2001 From: Kim Klein Date: Fri, 7 May 2021 11:48:38 -0700 Subject: [PATCH 03/27] Created new page for Audit and Enforce WDAC Merged Audit Events and Enforce WDAC policy pages, as well as updated the TOC2. --- .../TOC2.yml | 12 +- ...s-defender-application-control-policies.md | 163 ++++++++++++++++++ 2 files changed, 169 insertions(+), 6 deletions(-) create mode 100644 windows/security/threat-protection/windows-defender-application-control/audit-and-enforce-windows-defender-application-control-policies.md diff --git a/windows/security/threat-protection/windows-defender-application-control/TOC2.yml b/windows/security/threat-protection/windows-defender-application-control/TOC2.yml index e8a04d9f6b..6643f8980b 100644 --- a/windows/security/threat-protection/windows-defender-application-control/TOC2.yml +++ b/windows/security/threat-protection/windows-defender-application-control/TOC2.yml @@ -37,7 +37,9 @@ landingContent: - text: Merging Policies url: wdac-wizard-merging-policies.md - text: Recommended blocks - url: microsoft-recommended-block-rules.md #there are block rules and driver block rules, which link? Add both, actually. + url: microsoft-recommended-block-rules.md + - text: Recommended driver blocks + url: microsoft-recommended-driver-block-rules.md - text: Example policies url: example-wdac-base-policies.md - text: LOB Win32 apps on S Mode @@ -83,7 +85,7 @@ landingContent: - text: Signed policies url: use-signed-policies-to-protect-windows-defender-application-control-against-tampering.md - text: Audit and enforce policies - url: audit-windows-defender-application-control-policies.md #(merge with enforce-windows-defender-application-control-policies.md) + url: audit-and-enforce-windows-defender-application-control-policies.md - text: Disabling WDAC policies url: disable-windows-defender-application-control-policies.md - linkListType: tutorial @@ -101,13 +103,11 @@ landingContent: links: - text: Event logs (tags, IDs) url: event-id-explanations.md #(merge with event-tag-explanations.md) - - text: Advanced hunting - url: querying-application-control-events-centrally-using-advanced-hunting.md #same as below - linkListType: how-to-guide links: - text: Querying using advanced hunting url: querying-application-control-events-centrally-using-advanced-hunting.md #same as above - linkListType: tutorial links: - - text: Creating a policy from event logs - url: querying-application-control-events-centrally-using-advanced-hunting.md #same as above \ No newline at end of file + - text: Creating a policy from event logs (video) + url: querying-application-control-events-centrally-using-advanced-hunting.md #Jordan will create a video for this \ No newline at end of file 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..c10855446f --- /dev/null +++ b/windows/security/threat-protection/windows-defender-application-control/audit-and-enforce-windows-defender-application-control-policies.md @@ -0,0 +1,163 @@ +--- +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 + +**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** + ![Event showing exception to WDAC policy](images/dg-fig23-exceptionstocode.png) + +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). + From 5fa1ea84d48db26ba375704f49a5763c6c706995 Mon Sep 17 00:00:00 2001 From: Kim Klein Date: Tue, 11 May 2021 09:47:30 -0700 Subject: [PATCH 04/27] Event ID and Tags explanation Merged event IDs and tag explanations into one file. Updated TOC with new link. --- .../TOC2.yml | 2 +- .../event-id-and-tag-explanations.md | 153 ++++++++++++++++++ 2 files changed, 154 insertions(+), 1 deletion(-) create mode 100644 windows/security/threat-protection/windows-defender-application-control/event-id-and-tag-explanations.md diff --git a/windows/security/threat-protection/windows-defender-application-control/TOC2.yml b/windows/security/threat-protection/windows-defender-application-control/TOC2.yml index 6643f8980b..3db9e8ccd7 100644 --- a/windows/security/threat-protection/windows-defender-application-control/TOC2.yml +++ b/windows/security/threat-protection/windows-defender-application-control/TOC2.yml @@ -102,7 +102,7 @@ landingContent: - linkListType: overview links: - text: Event logs (tags, IDs) - url: event-id-explanations.md #(merge with event-tag-explanations.md) + url: event-id-and-tag-explanations.md - linkListType: how-to-guide links: - text: Querying using advanced hunting diff --git a/windows/security/threat-protection/windows-defender-application-control/event-id-and-tag-explanations.md b/windows/security/threat-protection/windows-defender-application-control/event-id-and-tag-explanations.md new file mode 100644 index 0000000000..81c7794f17 --- /dev/null +++ b/windows/security/threat-protection/windows-defender-application-control/event-id-and-tag-explanations.md @@ -0,0 +1,153 @@ +--- +title: Understanding Application Control event IDs and tags (Windows 10) +description: Learn what different Windows Defender Application Control event IDs and tags signify. +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: 5/7/2021 +ms.technology: mde +--- + +# Understanding Application Control event IDs and tags + +A Windows Defender Application Control (WDAC) policy logs events locally in Windows Event Viewer in either enforced or audit mode. These events include a number of fields, which provide helpful troubleshooting information to figure out exactly what an event means. + +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 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". | +| 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. + +| Event ID | Explanation | +|----------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| 3090 | Allow executable/dll file | +| 3091 | Audit executable/dll file | +| 3092 | Block executable/dll file | + +3090, 3091, and 3092 events are generated based on the status code of whether a binary passed the policy, regardless of what reputation it was given or whether it was allowed by a designated MI. The SmartLocker template which appears in the event should indicate why the binary passed/failed. Only one event is generated per binary pass/fail. If both ISG and MI are disabled, 3090, 3091, and 3092 events will not be generated. + +### SmartLocker template + +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 | +| SmartlockerEnabled | Policy trusts the ISG | +| PassesSmartlocker | File had positive reputation | +| AuditEnabled | True if the policy is in audit mode, otherwise it is in enforce mode | + +### Enabling ISG and MI diagnostic events + +In order to enable 3091 audit events and 3092 block events, you must create a TestFlags regkey with a value of 0x100. You can do so using the following PowerShell command: + +```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 +reg add hklm\system\currentcontrolset\control\ci -v TestFlags -t REG_DWORD -d 0x300 +``` + +
+ +## Event Tags + +Below, we have documented the values and meanings for a few useful event tags. + +## SignatureType + +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 | +| 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 | +| 7 | File was verified | + +## ValidatedSigningLevel + +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 | +| 3 | Developer signed code | +| 4 | Authenticode signed | +| 5 | Microsoft Store signed app PPL (Protected Process Light) | +| 6 | Microsoft Store-signed | +| 7 | Signed by an Antimalware vendor whose product is using AMPPL | +| 8 | Microsoft signed | +| 11 | Only used for signing of the .NET NGEN compiler | +| 12 | Windows signed | +| 14 | Windows Trusted Computing Base signed | + +## VerificationError + +Represents why verification failed, or if it succeeded. + +| VerificationError Value | Explanation | +|----------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| 0 | Successfully verified signature | +| 2 | File contains shared writable sections | +| 4 | Revoked signature | +| 5 | Expired signature | +| 7 | Invalid root certificate | +| 8 | Signature was unable to be validated; generic error | +| 9 | Signing time not trusted | +| 12 | Not valid for a PPL (Protected Process Light) | +| 13 | Not valid for a PP (Protected Process) | +| 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 | +| 18 | Custom signing level not met; returned if signature fails to match CISigners in UMCI | +| 19 | Binary is revoked by file hash | +| 20 | SHA1 cert hash's timestamp is missing or after valid cutoff as defined by Weak Crypto Policy | +| 21 | Failed to pass WDAC policy | +| 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 | +| 26 | Explicitly denied by WADC policy | +| 28 | Resource page hash mismatch | From c04791063c19a5a607c355d9c9b38f4218006af0 Mon Sep 17 00:00:00 2001 From: Kim Klein Date: Mon, 17 May 2021 17:56:14 -0700 Subject: [PATCH 05/27] Updated existing pages and merged others 1. Added missing event tags from event-tag-explanations. 2. Corrected MD errors in event-tags and event-id files. 3. Added missing event tag to combined event-id-and-tag file and ensured there are no MD errors. 4. Edited WDAC and AppLocker overview file for grammar. 5. Combined audit WDAC policies file with enforce WDAC policies file. 6. Updated TOC2, which will replace the main TOC. --- .../TOC2.yml | 4 ++-- ...s-defender-application-control-policies.md | 6 ++--- .../event-id-and-tag-explanations.md | 23 +++++++++++------- .../event-id-explanations.md | 12 +++++----- .../event-tag-explanations.md | 13 ++++++++-- .../wdac-and-applocker-overview.md | 24 +++++++++---------- 6 files changed, 48 insertions(+), 34 deletions(-) diff --git a/windows/security/threat-protection/windows-defender-application-control/TOC2.yml b/windows/security/threat-protection/windows-defender-application-control/TOC2.yml index 3db9e8ccd7..474b426029 100644 --- a/windows/security/threat-protection/windows-defender-application-control/TOC2.yml +++ b/windows/security/threat-protection/windows-defender-application-control/TOC2.yml @@ -106,8 +106,8 @@ landingContent: - linkListType: how-to-guide links: - text: Querying using advanced hunting - url: querying-application-control-events-centrally-using-advanced-hunting.md #same as above + url: querying-application-control-events-centrally-using-advanced-hunting.md - linkListType: tutorial links: - text: Creating a policy from event logs (video) - url: querying-application-control-events-centrally-using-advanced-hunting.md #Jordan will create a video for this \ No newline at end of file + url: #Jordan will create a video for this \ No newline at end of file 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 index c10855446f..31f6314425 100644 --- 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 @@ -19,7 +19,7 @@ ms.date: 05/03/2021 ms.technology: mde --- -# Use audit events to create WDAC policy rules +## Use audit events to create WDAC policy rules and Convert **base** policy from audits to enforced **Applies to:** @@ -75,8 +75,6 @@ To familiarize yourself with creating WDAC rules from audit events, follow these 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. @@ -155,9 +153,9 @@ Since the enforced policy was given a unique PolicyID in the previous procedure, $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/event-id-and-tag-explanations.md b/windows/security/threat-protection/windows-defender-application-control/event-id-and-tag-explanations.md index 81c7794f17..9b21c840e5 100644 --- a/windows/security/threat-protection/windows-defender-application-control/event-id-and-tag-explanations.md +++ b/windows/security/threat-protection/windows-defender-application-control/event-id-and-tag-explanations.md @@ -19,15 +19,15 @@ ms.date: 5/7/2021 ms.technology: mde --- -# Understanding Application Control event IDs and tags +## Understanding Application Control event IDs and tags A Windows Defender Application Control (WDAC) policy logs events locally in Windows Event Viewer in either enforced or audit mode. These events include a number of fields, which provide helpful troubleshooting information to figure out exactly what an event means. 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 @@ -35,7 +35,7 @@ These events are generated under two locations: |----------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | 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 @@ -48,7 +48,7 @@ These events are generated under two locations: ## 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 | |----------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| @@ -84,9 +84,7 @@ In order to enable 3090 allow events as well as 3091 and 3092 events, you must i ```powershell reg add hklm\system\currentcontrolset\control\ci -v TestFlags -t REG_DWORD -d 0x300 ``` - -
- + ## Event Tags Below, we have documented the values and meanings for a few useful event tags. @@ -100,6 +98,7 @@ Represents the type of signature which verified the image. | 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 | @@ -131,14 +130,20 @@ 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 | @@ -149,5 +154,7 @@ 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 | 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..8aab0d3c1b 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 @@ -18,13 +18,13 @@ ms.date: 3/17/2020 ms.technology: mde --- -# Understanding Application Control events +## Understanding Application Control events 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 @@ -32,7 +32,7 @@ A Windows Defender Application Control (WDAC) policy logs events locally in Wind |----------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | 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 @@ -45,7 +45,7 @@ A Windows Defender Application Control (WDAC) policy logs events locally in Wind ## 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 | |----------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| @@ -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..e4a1e510ea 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 @@ -18,7 +18,7 @@ ms.date: 8/27/2020 ms.technology: mde --- -# Understanding Application Control event tags +## Understanding Application Control event tags Windows Defender Application Control (WDAC) events include a number of fields which provide helpful troubleshooting information to figure out exactly what an event means. Below, we have documented the values and meanings for a few useful event tags. @@ -31,9 +31,10 @@ Represents the type of signature which verified the image. | 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 @@ -62,14 +63,20 @@ 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,7 @@ 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 | diff --git a/windows/security/threat-protection/windows-defender-application-control/wdac-and-applocker-overview.md b/windows/security/threat-protection/windows-defender-application-control/wdac-and-applocker-overview.md index 03f0eb6f0d..0897007f32 100644 --- a/windows/security/threat-protection/windows-defender-application-control/wdac-and-applocker-overview.md +++ b/windows/security/threat-protection/windows-defender-application-control/wdac-and-applocker-overview.md @@ -19,18 +19,18 @@ ms.custom: asr ms.technology: mde --- -# Windows Defender Application Control and AppLocker Overview +## Windows Defender Application Control and AppLocker Overview **Applies to:** - Windows 10 - Windows Server 2016 and above -Windows 10 includes two technologies that can be used for application control depending on your organization's specific scenarios and requirements: Windows Defender Application Control (WDAC) and AppLocker. +Windows 10 includes two technologies that can be used for application control, depending on your organization's specific scenarios and requirements: Windows Defender Application Control (WDAC) and AppLocker. ## Windows Defender Application Control -WDAC was introduced with Windows 10 and allows organizations to control which drivers and applications are allowed to run on their Windows 10 clients. WDAC was designed as a security feature under the [servicing criteria](https://www.microsoft.com/msrc/windows-security-servicing-criteria) defined by the Microsoft Security Response Center (MSRC). +WDAC was introduced with Windows 10 and allows organizations to control which drivers and applications are allowed to run on their Windows 10 clients. It was designed as a security feature under the [servicing criteria](https://www.microsoft.com/msrc/windows-security-servicing-criteria), defined by the Microsoft Security Response Center (MSRC). WDAC policies apply to the managed computer as a whole and affects all users of the device. WDAC rules can be defined based on: @@ -41,21 +41,21 @@ WDAC policies apply to the managed computer as a whole and affects all users of - 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 which comprised the now-defunct term 'Device Guard'. +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." ### WDAC System Requirements -WDAC policies can be created on any client edition of Windows 10 build 1903+ or on Windows Server 2016 and above. +WDAC policies can be created on any client edition of Windows 10 build 1903+, or on Windows Server 2016 and above. -WDAC policies can be applied to devices running any edition of Windows 10 or Windows Server 2016 and above via a Mobile Device Management (MDM) solution like Intune, a management interface like Configuration Manager, or a script host like PowerShell. Group Policy can also be used to deploy WDAC policies to Windows 10 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, or Windows Server 2016 and above, via a Mobile Device Management (MDM) solution, e.g. Intune; a management interface, e.g. Configuration Manager; or a script host, e.g. PowerShell. Group Policy can also be used to deploy WDAC policies to Windows 10 Enterprise edition, or Windows Server 2016 and above, but cannot deploy policies to devices running non-Enterprise SKUs of Windows 10. -For more information on which individual WDAC features are available on which WDAC builds, see [WDAC feature availability](feature-availability.md). +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 it 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 does not 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: +AppLocker policies can apply to all users on a computer, or to individual users and groups. AppLocker rules can be defined based on: - Attributes of the codesigning certificate(s) used to sign an app and its binaries - Attributes of the app's binaries that come from the signed metadata for the files, such as Original Filename and version, or the hash of the file @@ -68,13 +68,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 WDAC 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 is recommended that customers, who are able to implement application control using WDAC 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. -In some cases, however, AppLocker may be the more appropriate technology for your organization. AppLocker is best when: +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. -AppLocker can also be deployed as a complement to 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 WDAC to add user or group-specific rules for shared device scenarios, where it is 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. From 6ae73515243ffa2be999d1be9c910e70fed145f2 Mon Sep 17 00:00:00 2001 From: Kim Klein Date: Thu, 20 May 2021 11:15:00 -0700 Subject: [PATCH 06/27] authorized apps merged configure managed installer 1. Created new page that merged "Authorize apps installed by a managed installer" with Configure a WDAC managed installer. 2. Updated TOC2 with merged file name. --- .../TOC2.yml | 2 +- ...-apps-deployed-with-a-managed-installer.md | 194 ++++++++++++++++++ 2 files changed, 195 insertions(+), 1 deletion(-) create mode 100644 windows/security/threat-protection/windows-defender-application-control/configure-authorized-apps-deployed-with-a-managed-installer.md diff --git a/windows/security/threat-protection/windows-defender-application-control/TOC2.yml b/windows/security/threat-protection/windows-defender-application-control/TOC2.yml index 474b426029..bb66da245a 100644 --- a/windows/security/threat-protection/windows-defender-application-control/TOC2.yml +++ b/windows/security/threat-protection/windows-defender-application-control/TOC2.yml @@ -74,7 +74,7 @@ landingContent: - linkListType: how-to-guide (written) links: - text: Allow managed installer and configure managed installer rules - url: use-windows-defender-application-control-with-managed-installer.md + url: configure-authorized-apps-deployed-with-a-managed-installer.md - text: Allow reputable apps with ISG url: use-windows-defender-application-control-with-intelligent-security-graph.md # Card 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..3922be1e3b --- /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 | Get-AppLockerFileInformation | New-AppLockerPolicy -RuleType Publisher, Hash -User Everyone -Xml > AppLocker_MI_PS_ISE.xml + ``` + +2. Manually rename the rule collection to ManagedInstaller + + Change + + ```powershell + + ``` + + to + + ```powershell + + ``` + +An example of a valid Managed Installer rule collection using Microsoft Endpoint Config Manager (MEMCM) is shown below. + +```xml + + + + + + + + + + + + + + + + +``` + +### Enable service enforcement in AppLocker policy + +Since many installation processes rely on services, it is typically necessary to enable tracking of services. +Correct tracking of services requires the presence of at least one rule in the rule collection. So, a simple audit only rule will suffice. This can be added to the policy created above, which specifies your managed installer rule collection. + +For example: + +```xml + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +``` + +## Enable the managed installer option in WDAC policy + +In order to enable trust for the binaries laid down by managed installers, the "Enabled: Managed Installer" option must be specified in your WDAC policy. +This can be done by using the [Set-RuleOption cmdlet](/powershell/module/configci/set-ruleoption) with Option 13. + +Below are steps to create a WDAC policy which allows Windows to boot and enables the managed installer option. + +1. Copy the DefaultWindows_Audit policy into your working folder from "C:\Windows\schemas\CodeIntegrity\ExamplePolicies\DefaultWindows_Audit.xml" + +2. Reset the policy ID to ensure it is in multiple policy format, and give it a different GUID from the example policies. Also, give it a friendly name to help with identification. + + For example: + + ```powershell + Set-CIPolicyIdInfo -FilePath -PolicyName "" -ResetPolicyID + ``` + +3. Set Option 13 (Enabled:Managed Installer) + + ```powershell + Set-RuleOption -FilePath -Option 13 + ``` + +## Set the AppLocker filter driver to autostart + +To enable the managed installer, you need to set the AppLocker filter driver to autostart, and start it. + +To do so, run the following command as an Administrator: + +```console +appidtel.exe start [-mionly] +``` + +Specify "-mionly" if you will not use the Intelligent Security Graph (ISG). + +## Enabling managed installer logging events + +Refer to [Understanding Application Control Events](event-id-explanations.md#optional-intelligent-security-graph-isg-or-managed-installer-mi-diagnostic-events) for information on enabling optional managed installer diagnostic events. \ No newline at end of file From d2a7d0718fe7b8174f044b5ae646f3db717535e7 Mon Sep 17 00:00:00 2001 From: Kim Klein Date: Thu, 20 May 2021 17:15:23 -0700 Subject: [PATCH 07/27] Updated language about explicit allow or deny rules Clarified language regarding when WDAC calls the cloud to determine a binary's reputation. --- ...der-application-control-with-intelligent-security-graph.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/windows/security/threat-protection/windows-defender-application-control/use-windows-defender-application-control-with-intelligent-security-graph.md b/windows/security/threat-protection/windows-defender-application-control/use-windows-defender-application-control-with-intelligent-security-graph.md index 7ad4a8467b..dcd705cd5b 100644 --- a/windows/security/threat-protection/windows-defender-application-control/use-windows-defender-application-control-with-intelligent-security-graph.md +++ b/windows/security/threat-protection/windows-defender-application-control/use-windows-defender-application-control-with-intelligent-security-graph.md @@ -31,7 +31,9 @@ Beginning with Windows 10, version 1709, you can set an option to automatically ## How does the integration between WDAC and the Intelligent Security Graph work? -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 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. Every time the binary runs, it is allowed based on its positive reputation unless there is an explicit deny rule set in the WDAC policy. Conversely, a file that has unknown or known bad reputation will be allowed if your WDAC policy explicitly allows it. +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 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, rendering ISG reputation information as moot. 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. From 9de68009d2568d04aaa2e4d87fb5d2345c7a46f7 Mon Sep 17 00:00:00 2001 From: Kim Klein Date: Thu, 20 May 2021 17:36:16 -0700 Subject: [PATCH 08/27] Updated select-types-of-rules-to-create Created a "More information about hashes," and placed it above the "Windows Defender Application Control filename rules" section. --- .../select-types-of-rules-to-create.md | 13 +++++++++++++ 1 file changed, 13 insertions(+) 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..e91bfb3d64 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 @@ -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 4 hash rules per XML file? + +(Hash Sha1, Hash Sha256, Hash Page Sha1, Hash Page Sha256) +During validation CI will choose which hashes to calculate depending on how the file is signed. E.g. 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 4 hashes (sha1/sha2 authenticode, and sha1/sha2 of first page). This is also resilient to 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 8 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. From 7bd22fdeb383508dfc31cac8927c6227d32a57a4 Mon Sep 17 00:00:00 2001 From: Kim Klein Date: Fri, 21 May 2021 14:47:28 -0700 Subject: [PATCH 09/27] Delete TOC2.yml --- .../TOC2.yml | 113 ------------------ 1 file changed, 113 deletions(-) delete mode 100644 windows/security/threat-protection/windows-defender-application-control/TOC2.yml diff --git a/windows/security/threat-protection/windows-defender-application-control/TOC2.yml b/windows/security/threat-protection/windows-defender-application-control/TOC2.yml deleted file mode 100644 index bb66da245a..0000000000 --- a/windows/security/threat-protection/windows-defender-application-control/TOC2.yml +++ /dev/null @@ -1,113 +0,0 @@ - -### WDAC:Landing -title: Application Control for Windows -metadata: - title: Application Control for Windows - description: Landing page for Windows Defender Application Control -# services: service -# ms.service: microsoft-WDAC-AppLocker -# ms.subservice: Application-Control -# ms.topic: landing-page -# author: Kim Klein -# ms.author: Jordan Geurten -# manager: Jeffrey Sutherland -# ms.update: 04/30/2021 -# linkListType: overview | how-to-guide | tutorial | video -landingContent: -# Cards and links should be based on top customer tasks or top subjects -# Start card title with a verb - # Card - - title: Learn about Application Control - linkLists: - - linkListType: overview - links: - - text: What is WDAC (WDAC Overview)? - url: wdac-and-applocker-overview.md - - text: What is AppLocker? - url: applocker\applocker-overview.md - - text: WDAC and AppLocker feature availability - url: feature-availability.md - # Card - - title: Learn about the Design Guide - linkLists: - - linkListType: overview - links: - - text: Using code signing to simplify application control - url: use-code-signing-to-simplify-application-control-for-classic-windows-applications.md - - text: Merging Policies - url: wdac-wizard-merging-policies.md - - text: Recommended blocks - url: microsoft-recommended-block-rules.md - - text: Recommended driver blocks - url: microsoft-recommended-driver-block-rules.md - - text: Example policies - url: example-wdac-base-policies.md - - text: LOB Win32 apps on S Mode - url: LOB-win32-apps-on-s.md - - linkListType: how-to-guide - links: - - text: Create a WDAC policy for a lightly managed device - url: cardreate-wdac-policy-for-lightly-managed-devices.md - - text: Create a WDAC policy for a fully managed device - url: create-wdac-policy-for-fully-managed-devices.md - - text: Create a WDAC policy for a fixed-workload - url: create-initial-default-policy.md - - text: Using catalog files - url: deploy-catalog-files-to-support-windows-defender-application-control.md - - text: WDAC Wizard tool - url: wdac-wizard.md - - linkListType: Tutorial (videos) - links: - - text: Using the WDAC Wizard - url: video md - - text: Specifying custom values - url: video md - # Card - - title: Learn about Policy Configuration - linkLists: - - linkListType: overview - links: - - text: Understanding policy rules - url: - - text: Understanding File rules - url: - - linkListType: how-to-guide (written) - links: - - text: Allow managed installer and configure managed installer rules - url: configure-authorized-apps-deployed-with-a-managed-installer.md - - text: Allow reputable apps with ISG - url: use-windows-defender-application-control-with-intelligent-security-graph.md - # Card - - title: Learn how to deploy WDAC Policies - linkLists: - - linkListType: overview - links: - - text: Signed policies - url: use-signed-policies-to-protect-windows-defender-application-control-against-tampering.md - - text: Audit and enforce policies - url: audit-and-enforce-windows-defender-application-control-policies.md - - text: Disabling WDAC policies - url: disable-windows-defender-application-control-policies.md - - linkListType: tutorial - links: - - text: Deployment with MDM - url: deploy-windows-defender-application-control-policies-using-intune.md - - text: Deployment with MEMCM - url: deployment/deploy-wdac-policies-with-memcm.md - - text: Deployment with script and refresh policy - url: deployment/deploy-wdac-policies-with-script.md - # Card - - title: Learn how to monitor and reiterate WDAC Policies (operational) - linkLists: - - linkListType: overview - links: - - text: Event logs (tags, IDs) - url: event-id-and-tag-explanations.md - - linkListType: how-to-guide - links: - - text: Querying using advanced hunting - url: querying-application-control-events-centrally-using-advanced-hunting.md - - linkListType: tutorial - links: - - text: Creating a policy from event logs (video) - url: #Jordan will create a video for this \ No newline at end of file From d8b97435929ea25323d7e1447ccc181ea2b54802 Mon Sep 17 00:00:00 2001 From: Kim Klein Date: Mon, 24 May 2021 11:09:43 -0700 Subject: [PATCH 10/27] Task ID 29550212 Made recommended edit. --- .../select-types-of-rules-to-create.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) 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 e91bfb3d64..000dc79659 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 @@ -126,14 +126,14 @@ 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 +## More information about hashes -### Why does scan create 4 hash rules per XML file? +### Why does scan create four hash rules per XML file? -(Hash Sha1, Hash Sha256, Hash Page Sha1, Hash Page Sha256) -During validation CI will choose which hashes to calculate depending on how the file is signed. E.g. 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. +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 4 hashes (sha1/sha2 authenticode, and sha1/sha2 of first page). This is also resilient to 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 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 8 hash rules for certain XML files? From 5e53adc4effca1e0294803f0385c8ba9c95364af Mon Sep 17 00:00:00 2001 From: Kim Klein Date: Mon, 24 May 2021 11:13:53 -0700 Subject: [PATCH 11/27] Task ID 33324832 Made 2 recommended edits. --- ...d-enforce-windows-defender-application-control-policies.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) 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 index 31f6314425..04664080a7 100644 --- 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 @@ -32,7 +32,7 @@ While a WDAC policy is running in audit mode, any binary that runs but would hav ## Overview of the process to create WDAC policy to allow apps using audit events -> [!Note] +> [!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. @@ -75,7 +75,7 @@ To familiarize yourself with creating WDAC rules from audit events, follow these 8. Convert the Base or Supplemental policy to binary and deploy using your preferred method. -## Convert WDAC **base** policy from audit to enforced +## 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. From c1ae84c81f44ae1590a5e7830745c0bc1ab65e4e Mon Sep 17 00:00:00 2001 From: Kim Klein Date: Mon, 24 May 2021 11:34:24 -0700 Subject: [PATCH 12/27] Task ID 33324832 Fixed primary heading size. --- ...and-enforce-windows-defender-application-control-policies.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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 index 04664080a7..4b1860ea36 100644 --- 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 @@ -19,7 +19,7 @@ ms.date: 05/03/2021 ms.technology: mde --- -## Use audit events to create WDAC policy rules and Convert **base** policy from audits to enforced +# Use audit events to create WDAC policy rules and Convert **base** policy from audits to enforced **Applies to:** From 75160b732405a061f12a6869ad46e40c3280566b Mon Sep 17 00:00:00 2001 From: Kim Klein Date: Mon, 24 May 2021 11:38:02 -0700 Subject: [PATCH 13/27] Task ID 31558721 Removed "rendering ISG reputation as moot" --- ...ender-application-control-with-intelligent-security-graph.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/windows/security/threat-protection/windows-defender-application-control/use-windows-defender-application-control-with-intelligent-security-graph.md b/windows/security/threat-protection/windows-defender-application-control/use-windows-defender-application-control-with-intelligent-security-graph.md index dcd705cd5b..082eb3a3f1 100644 --- a/windows/security/threat-protection/windows-defender-application-control/use-windows-defender-application-control-with-intelligent-security-graph.md +++ b/windows/security/threat-protection/windows-defender-application-control/use-windows-defender-application-control-with-intelligent-security-graph.md @@ -33,7 +33,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 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, rendering ISG reputation information as moot. +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 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. From b9fcf4421627b005f5db5268a4e90486e3260a20 Mon Sep 17 00:00:00 2001 From: Kim Klein Date: Mon, 24 May 2021 11:40:32 -0700 Subject: [PATCH 14/27] Task ID 33324832 Fixed first heading. --- ...nfigure-authorized-apps-deployed-with-a-managed-installer.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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 index 3922be1e3b..6612e9fbf7 100644 --- 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 @@ -18,7 +18,7 @@ ms.date: 08/14/2020 ms.technology: mde --- -## Configuring authorized apps deployed by a managed installer with AppLocker and Windows Defender Application Control +# Configuring authorized apps deployed by a managed installer with AppLocker and Windows Defender Application Control **Applies to:** From 84458fe2ffb40b4f2165e5e07ac62cac9e721629 Mon Sep 17 00:00:00 2001 From: Kim Klein Date: Mon, 24 May 2021 11:46:21 -0700 Subject: [PATCH 15/27] Updated wdac-and-applocker-overview document Restored first heading size and made suggested text edit to the WDAC System Requirements section. --- .../wdac-and-applocker-overview.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/windows/security/threat-protection/windows-defender-application-control/wdac-and-applocker-overview.md b/windows/security/threat-protection/windows-defender-application-control/wdac-and-applocker-overview.md index 0897007f32..2d7ae11177 100644 --- a/windows/security/threat-protection/windows-defender-application-control/wdac-and-applocker-overview.md +++ b/windows/security/threat-protection/windows-defender-application-control/wdac-and-applocker-overview.md @@ -19,7 +19,7 @@ ms.custom: asr ms.technology: mde --- -## Windows Defender Application Control and AppLocker Overview +# Windows Defender Application Control and AppLocker Overview **Applies to:** @@ -47,7 +47,7 @@ Note that prior to Windows 10 version 1709, Windows Defender Application Control WDAC policies can be created on any client edition of Windows 10 build 1903+, or on Windows Server 2016 and above. -WDAC policies can be applied to devices running any edition of Windows 10, or Windows Server 2016 and above, via a Mobile Device Management (MDM) solution, e.g. Intune; a management interface, e.g. Configuration Manager; or a script host, e.g. PowerShell. Group Policy can also be used to deploy WDAC policies to Windows 10 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, 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 Enterprise edition, or Windows Server 2016 and above, but cannot 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). From 087c522d61678843302f41f2abe6140ce448ab95 Mon Sep 17 00:00:00 2001 From: Kim Klein Date: Mon, 24 May 2021 13:15:14 -0700 Subject: [PATCH 16/27] Task ID 29550212 Implemented last suggested edit to the "create eight hash rules" section. --- .../select-types-of-rules-to-create.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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 000dc79659..390b687187 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 @@ -135,7 +135,7 @@ During validation CI will choose which hashes to calculate depending on how the 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 8 hash rules for certain XML files? +### 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. From 092c6bfb6c44603217a2f2d34d5d0593872c44d0 Mon Sep 17 00:00:00 2001 From: Kim Klein Date: Mon, 24 May 2021 13:26:23 -0700 Subject: [PATCH 17/27] Task ID 33324832 Updated TOC and all articles that point to old managed installer documents with new combined managed installer link. --- ...lication-control-with-managed-installer.md | 59 ------------------- 1 file changed, 59 deletions(-) delete mode 100644 windows/security/threat-protection/windows-defender-application-control/use-windows-defender-application-control-with-managed-installer.md diff --git a/windows/security/threat-protection/windows-defender-application-control/use-windows-defender-application-control-with-managed-installer.md b/windows/security/threat-protection/windows-defender-application-control/use-windows-defender-application-control-with-managed-installer.md deleted file mode 100644 index 66afc7f933..0000000000 --- a/windows/security/threat-protection/windows-defender-application-control/use-windows-defender-application-control-with-managed-installer.md +++ /dev/null @@ -1,59 +0,0 @@ ---- -title: Authorize apps installed by a managed installer (Windows 10) -description: Explains how to automatically allow applications deployed and installed by a managed 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: jogeurte -ms.author: dansimp -manager: dansimp -ms.date: 04/20/2021 -ms.technology: mde ---- - -# Authorize apps deployed by a managed installer - -**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) and 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 to boot and any other authorized applications that can't be deployed through a managed installer. - -For an example of a managed installer use case, see [Creating a WDAC policy for fully managed devices](create-wdac-policy-for-fully-managed-devices.md). - -## 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. - -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. From a85b27f4bfa623752f94ff6cf89c0cf1c50ec8c7 Mon Sep 17 00:00:00 2001 From: Kim Klein Date: Mon, 24 May 2021 13:42:46 -0700 Subject: [PATCH 18/27] Task ID 33324832 continued These are the other files that were updated for this task. --- .../windows-defender-application-control/TOC.yml | 4 ++-- .../create-wdac-policy-for-fully-managed-devices.md | 2 +- .../create-wdac-policy-for-lightly-managed-devices.md | 2 +- .../feature-availability.md | 2 +- .../plan-windows-defender-application-control-management.md | 2 +- .../select-types-of-rules-to-create.md | 2 +- ...ws-defender-application-control-policy-design-decisions.md | 2 +- .../wdac-and-applocker-overview.md | 2 +- 8 files changed, 9 insertions(+), 9 deletions(-) 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..8fa33cfe26 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,9 @@ 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 + href: configure-authorized-apps-deployed-with-a-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/create-wdac-policy-for-fully-managed-devices.md b/windows/security/threat-protection/windows-defender-application-control/create-wdac-policy-for-fully-managed-devices.md index 8399532bab..cceb8da77d 100644 --- a/windows/security/threat-protection/windows-defender-application-control/create-wdac-policy-for-fully-managed-devices.md +++ b/windows/security/threat-protection/windows-defender-application-control/create-wdac-policy-for-fully-managed-devices.md @@ -149,7 +149,7 @@ Alice has defined a policy for Lamna's fully-managed devices that makes some tra Possible mitigations: - Use signed WDAC policies and UEFI BIOS access protection to prevent tampering of WDAC policies. - **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) 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/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 8c0156d01b..5d0dd83466 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 390b687187..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.| 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/wdac-and-applocker-overview.md b/windows/security/threat-protection/windows-defender-application-control/wdac-and-applocker-overview.md index 2d7ae11177..ce2acde0e8 100644 --- a/windows/security/threat-protection/windows-defender-application-control/wdac-and-applocker-overview.md +++ b/windows/security/threat-protection/windows-defender-application-control/wdac-and-applocker-overview.md @@ -37,7 +37,7 @@ WDAC policies apply to the managed computer as a whole and affects all users of - Attributes of the codesigning certificate(s) used to sign an app and its binaries - Attributes of the app's binaries that come from the signed metadata for the files, such as Original Filename and version, or the hash of the file - The reputation of the app as determined by Microsoft's [Intelligent Security Graph](use-windows-defender-application-control-with-intelligent-security-graph.md) -- The identity of the process that initiated the installation of the app and its binaries ([managed installer](use-windows-defender-application-control-with-managed-installer.md)) +- The identity of the process that initiated the installation of the app and its binaries ([managed installer](configure-authorized-apps-deployed-with-a-managed-installer.md)) - 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 From 8faa81c72bea6f594a8828a26157afcc6a9c216b Mon Sep 17 00:00:00 2001 From: Kim Klein Date: Tue, 25 May 2021 09:35:03 -0700 Subject: [PATCH 19/27] Task ID 23142312 Added "well-known root cert types" info to the document. --- .../event-tag-explanations.md | 31 ++++++++++++++++++- 1 file changed, 30 insertions(+), 1 deletion(-) 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 e4a1e510ea..07690733e7 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 @@ -18,7 +18,7 @@ ms.date: 8/27/2020 ms.technology: mde --- -## Understanding Application Control event tags +# Understanding Application Control event tags Windows Defender Application Control (WDAC) events include a number of fields which provide helpful troubleshooting information to figure out exactly what an event means. Below, we have documented the values and meanings for a few useful event tags. @@ -91,3 +91,32 @@ Represents why verification failed, or if it succeeded. | 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 cert that chains to this root CA. Enums without values start at 0, and increment by 1 as you go down the below list. + +typedef enum _MINCRYPT_KNOWN_ROOT_ID { +    MincryptKnownRootNone, <-- 0
+    MincryptKnownRootUnknown,
+    MincryptKnownRootSelfsigned,
+    MincryptKnownRootMicrosoftAuthenticodeRoot,
+    MincryptKnownRootMicrosoftProductRoot1997,
+    MincryptKnownRootMicrosoftProductRoot2001,
+    MincryptKnownRootMicrosoftProductRoot2010,
+    MincryptKnownRootMicrosoftStandardRoot2011,
+    MincryptKnownRootMicrosoftCodeVerificationRoot2006,
+    MincryptKnownRootMicrosoftTestRoot1999,
+    MincryptKnownRootMicrosoftTestRoot2010,
+    MincryptKnownRootMicrosoftDMDTestRoot2005,
+    MincryptKnownRootMicrosoftDMDRoot2005,
+    MincryptKnownRootMicrosoftDMDPreviewRoot2005,
+    MincryptKnownRootMicrosoftFlightRoot2014,
+    MincryptKnownRootMicrosoftThirdPartyMarketplaceRoot,
+    MincryptKnownRootMicrosoftEccTestingRootCa2017,
+    MincryptKnownRootMicrosoftEccDevelopmentRootCa2018,
+    MincryptKnownRootMicrosoftEccProductRootCa2018,
+    MincryptKnownRootMicrosoftEccDevicesRootCa2017,
+} MINCRYPT_KNOWN_ROOT_ID, *PMINCRYPT_KNOWN_ROOT_ID;
+ +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 From dadf73dea9676bac0304d2663515a50a52376dc2 Mon Sep 17 00:00:00 2001 From: Kim Klein Date: Tue, 25 May 2021 12:24:24 -0700 Subject: [PATCH 20/27] Task ID 23142312 Fine tuning Root Cert section. --- .../event-tag-explanations.md | 46 +++++++++---------- 1 file changed, 23 insertions(+), 23 deletions(-) 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 07690733e7..7d75cdc009 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 @@ -94,29 +94,29 @@ Represents why verification failed, or if it succeeded. ## Microsoft Root CAs trusted by Windows -The rule means trust anything signed by a cert that chains to this root CA. Enums without values start at 0, and increment by 1 as you go down the below list. +The rule means trust anything signed by a cert that chains to this root CA. Enums without values start at 0, and increment by 1 as you go down the below list.
-typedef enum _MINCRYPT_KNOWN_ROOT_ID { -    MincryptKnownRootNone, <-- 0
-    MincryptKnownRootUnknown,
-    MincryptKnownRootSelfsigned,
-    MincryptKnownRootMicrosoftAuthenticodeRoot,
-    MincryptKnownRootMicrosoftProductRoot1997,
-    MincryptKnownRootMicrosoftProductRoot2001,
-    MincryptKnownRootMicrosoftProductRoot2010,
-    MincryptKnownRootMicrosoftStandardRoot2011,
-    MincryptKnownRootMicrosoftCodeVerificationRoot2006,
-    MincryptKnownRootMicrosoftTestRoot1999,
-    MincryptKnownRootMicrosoftTestRoot2010,
-    MincryptKnownRootMicrosoftDMDTestRoot2005,
-    MincryptKnownRootMicrosoftDMDRoot2005,
-    MincryptKnownRootMicrosoftDMDPreviewRoot2005,
-    MincryptKnownRootMicrosoftFlightRoot2014,
-    MincryptKnownRootMicrosoftThirdPartyMarketplaceRoot,
-    MincryptKnownRootMicrosoftEccTestingRootCa2017,
-    MincryptKnownRootMicrosoftEccDevelopmentRootCa2018,
-    MincryptKnownRootMicrosoftEccProductRootCa2018,
-    MincryptKnownRootMicrosoftEccDevicesRootCa2017,
-} MINCRYPT_KNOWN_ROOT_ID, *PMINCRYPT_KNOWN_ROOT_ID;
+| 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 Tes\t 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 Ca2017 | +|17 | Microsoft Ecc Developmen tRoot 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 From f3f7fe88390d7fa20eb126fd59c874094310cc1a Mon Sep 17 00:00:00 2001 From: Kim Klein Date: Tue, 25 May 2021 12:38:05 -0700 Subject: [PATCH 21/27] Task ID 23142312 Removed the "Enums without value start..." line and reduced the dashes in the table columns headers. --- .../event-tag-explanations.md | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) 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 7d75cdc009..e1ea4e1926 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,7 +27,7 @@ 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 | @@ -42,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 | @@ -61,7 +61,7 @@ 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 | @@ -94,8 +94,7 @@ Represents why verification failed, or if it succeeded. ## Microsoft Root CAs trusted by Windows -The rule means trust anything signed by a cert that chains to this root CA. Enums without values start at 0, and increment by 1 as you go down the below list.
- +The rule means trust anything signed by a cert that chains to this root CA. | Root ID | Root Name | |---|----------| |0| None | From 1bf4abff9868c390ded6f4313b9e2d43f088b1b7 Mon Sep 17 00:00:00 2001 From: Kim Klein Date: Wed, 26 May 2021 10:22:15 -0700 Subject: [PATCH 22/27] Task ID 33123704 Deleted the merged event tags and id page to rework it under a different branch. --- .../event-id-and-tag-explanations.md | 160 ------------------ 1 file changed, 160 deletions(-) delete mode 100644 windows/security/threat-protection/windows-defender-application-control/event-id-and-tag-explanations.md diff --git a/windows/security/threat-protection/windows-defender-application-control/event-id-and-tag-explanations.md b/windows/security/threat-protection/windows-defender-application-control/event-id-and-tag-explanations.md deleted file mode 100644 index 9b21c840e5..0000000000 --- a/windows/security/threat-protection/windows-defender-application-control/event-id-and-tag-explanations.md +++ /dev/null @@ -1,160 +0,0 @@ ---- -title: Understanding Application Control event IDs and tags (Windows 10) -description: Learn what different Windows Defender Application Control event IDs and tags signify. -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: 5/7/2021 -ms.technology: mde ---- - -## Understanding Application Control event IDs and tags - -A Windows Defender Application Control (WDAC) policy logs events locally in Windows Event Viewer in either enforced or audit mode. These events include a number of fields, which provide helpful troubleshooting information to figure out exactly what an event means. - -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 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". | -| 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. - -| Event ID | Explanation | -|----------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| 3090 | Allow executable/dll file | -| 3091 | Audit executable/dll file | -| 3092 | Block executable/dll file | - -3090, 3091, and 3092 events are generated based on the status code of whether a binary passed the policy, regardless of what reputation it was given or whether it was allowed by a designated MI. The SmartLocker template which appears in the event should indicate why the binary passed/failed. Only one event is generated per binary pass/fail. If both ISG and MI are disabled, 3090, 3091, and 3092 events will not be generated. - -### SmartLocker template - -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 | -| SmartlockerEnabled | Policy trusts the ISG | -| PassesSmartlocker | File had positive reputation | -| AuditEnabled | True if the policy is in audit mode, otherwise it is in enforce mode | - -### Enabling ISG and MI diagnostic events - -In order to enable 3091 audit events and 3092 block events, you must create a TestFlags regkey with a value of 0x100. You can do so using the following PowerShell command: - -```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 -reg add hklm\system\currentcontrolset\control\ci -v TestFlags -t REG_DWORD -d 0x300 -``` - -## Event Tags - -Below, we have documented the values and meanings for a few useful event tags. - -## SignatureType - -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 | -| 7 | File was verified | - -## ValidatedSigningLevel - -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 | -| 3 | Developer signed code | -| 4 | Authenticode signed | -| 5 | Microsoft Store signed app PPL (Protected Process Light) | -| 6 | Microsoft Store-signed | -| 7 | Signed by an Antimalware vendor whose product is using AMPPL | -| 8 | Microsoft signed | -| 11 | Only used for signing of the .NET NGEN compiler | -| 12 | Windows signed | -| 14 | Windows Trusted Computing Base signed | - -## VerificationError - -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 | -| 18 | Custom signing level not met; returned if signature fails to match CISigners in UMCI | -| 19 | Binary is revoked by file hash | -| 20 | SHA1 cert hash's timestamp is missing or after valid cutoff as defined by Weak Crypto Policy | -| 21 | Failed to pass WDAC policy | -| 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 | From 58ca97ae759646943a74b1d3fcb876fd7c63f2c5 Mon Sep 17 00:00:00 2001 From: Kim Klein Date: Wed, 26 May 2021 10:40:29 -0700 Subject: [PATCH 23/27] Updated TOC Removed configure managed installer name and href. --- .../windows-defender-application-control/TOC.yml | 2 -- 1 file changed, 2 deletions(-) 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 8fa33cfe26..2a9d13497a 100644 --- a/windows/security/threat-protection/windows-defender-application-control/TOC.yml +++ b/windows/security/threat-protection/windows-defender-application-control/TOC.yml @@ -22,8 +22,6 @@ items: - name: Allow apps installed by a managed installer href: configure-authorized-apps-deployed-with-a-managed-installer.md - - name: Configure managed installer rules - 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 From 36673e5b5e4bc2325d6d16345265df3cc9b5a063 Mon Sep 17 00:00:00 2001 From: Kim Klein Date: Wed, 26 May 2021 10:45:33 -0700 Subject: [PATCH 24/27] Fixed title heading size --- .../event-id-explanations.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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 8aab0d3c1b..26a3b3fd6a 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 @@ -18,7 +18,7 @@ ms.date: 3/17/2020 ms.technology: mde --- -## Understanding Application Control events +# Understanding Application Control events 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: From 09d4ac542c2acf8ddc9bc17c4a332f66c46f50de Mon Sep 17 00:00:00 2001 From: Kim Klein Date: Wed, 26 May 2021 13:14:27 -0700 Subject: [PATCH 25/27] Task ID 23142312 fixed editing issues in root cert section. --- .../event-tag-explanations.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) 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 e1ea4e1926..bcbeab1e3e 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 @@ -107,15 +107,15 @@ The rule means trust anything signed by a cert that chains to this root CA. |7 | Microsoft Standard Root 2011 | |8 | Microsoft Code Verification Root 2006 | |9 | Microsoft Test Root 1999 | -|10 | Microsoft Tes\t Root 2010 | +|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 Ca2017 | -|17 | Microsoft Ecc Developmen tRoot Ca 2018 | -|18 | Microsoft Ecc Product Root Ca 2018 | -|19 | Microsoft Ecc Devices Root Ca 2017 | +|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 From 6136ddc0d5d380854ea01aeb2c2fe9ebb336a459 Mon Sep 17 00:00:00 2001 From: Kim Klein Date: Wed, 26 May 2021 14:06:10 -0700 Subject: [PATCH 26/27] Updated event-id-explantions Cleaned up the table formatting. --- .../event-id-explanations.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) 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 26a3b3fd6a..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 @@ -29,7 +29,7 @@ A Windows Defender Application Control (WDAC) policy logs events locally in Wind ## 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". | @@ -38,7 +38,7 @@ A Windows Defender Application Control (WDAC) policy logs events locally in Wind ## 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". | | @@ -48,7 +48,7 @@ A Windows Defender Application Control (WDAC) policy logs events locally in Wind 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 | From faee789b267ba90d691979a343b4bcf8c1432eb9 Mon Sep 17 00:00:00 2001 From: Kim Klein Date: Thu, 27 May 2021 09:37:24 -0700 Subject: [PATCH 27/27] Task ID 23142312 and 29028100 Made cosmetic changes to the certificate section in event-tags-explanation, and added a line break before the Figure 1 image in audit-and-enforce. --- ...s-defender-application-control-policies.md | 3 +- .../event-tag-explanations.md | 42 +++++++++---------- 2 files changed, 23 insertions(+), 22 deletions(-) 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 index 4b1860ea36..b33cace078 100644 --- 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 @@ -41,7 +41,8 @@ To familiarize yourself with creating WDAC rules from audit events, follow these 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** + **Figure 1. Exceptions to the deployed WDAC policy**
+ ![Event showing exception to WDAC policy](images/dg-fig23-exceptionstocode.png) 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**. 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 bcbeab1e3e..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 @@ -94,28 +94,28 @@ Represents why verification failed, or if it succeeded. ## Microsoft Root CAs trusted by Windows -The rule means trust anything signed by a cert that chains to this root CA. +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 | +| 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