deepblue/windows-itpro-docs
1
0
Fork 0
mirror of https://github.com/MicrosoftDocs/windows-itpro-docs.git synced 2025-05-14 06:17:22 +00:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity

Merge pull request #6265 from MicrosoftDocs/master

Browse Source 
Publish 02/04/2022, 10:30 AM
This commit is contained in:
Diana Hanson 2022-02-04 11:39:49 -07:00 committed by GitHub
commit c7676ab136
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
4 changed files with 70 additions and 60 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -55,7 +55,7 @@ Ea Value Length: 7e
## Enabling managed installer logging events ## 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. Refer to [Understanding Application Control Events](event-id-explanations.md#diagnostic-events-for-intelligent-security-graph-isg-and-managed-installer-mi) for information on enabling optional managed installer diagnostic events.
## Deploying the Managed Installer rule collection ## Deploying the Managed Installer rule collection

37
windows/security/threat-protection/windows-defender-application-control/create-wdac-deny-policy.md
View File

@ -20,21 +20,22 @@ ms.technology: windows-sec
# Guidance on Creating WDAC Deny Policies # Guidance on Creating WDAC Deny Policies
With Windows Defender Application Control (WDAC), you can create application control policies to explicitly deny specific drivers and applications, as well as signatures and certificates and file paths. With Windows Defender Application Control (WDAC), you can create policies to explicitly deny specific drivers and applications.
In this article we explain:
Topics this article will be discussing are:
1. File Rule Precedence Order 1. File Rule Precedence Order
2. Adding Allow Rules 2. Adding Allow Rules
3. Singe Policy Considerations 3. Singe Policy Considerations
4. Multiple Policy Considerations 4. Multiple Policy Considerations
5. Best Practices 5. Best Practices
6. Tutorial/Walkthrough 6. Tutorial
## File Rule Precedence Order ## File Rule Precedence Order
To create effective WDAC deny policies, it is crucial to understand how WDAC parses the policy. The WDAC engine evaluates files against the policy in the following order. To create effective WDAC deny policies, it's crucial to understand how WDAC parses the policy. The WDAC engine evaluates files against the policy in the following order.
1. Explicit deny rules - if there is an explicit deny rule, do not process the rest of the rules; the file is untrusted. 1. Explicit deny rules - if any explicit deny rule exists for a file, it will not run even if other rules are created to try to allow it. Deny rules can use any [rule level](select-types-of-rules-to-create.md#windows-defender-application-control-file-rule-levels). Use the most specific rule level practical when creating deny rules to avoid blocking more than you intend.
2. Explicit allow rules. 2. Explicit allow rules.
@ -42,12 +43,11 @@ To create effective WDAC deny policies, it is crucial to understand how WDAC par
4. Lastly, WDAC will call the Intelligent Security Graph (ISG) to get reputation on file, if the policy has support for the ISG. 4. Lastly, WDAC will call the Intelligent Security Graph (ISG) to get reputation on file, if the policy has support for the ISG.
Explicit allow and deny rules encompass rules at any level (for example hash rules, signer rules path rules, attribute rules, or package family name rules). If there is an explicit deny rule, WDAC does not process any other rules, meaning a deny rule always takes precedence in the case where a deny and allow rule would be at odds. 5. If no rule exists for the file and it's not allowed based on ISG or MI, then the file is blocked implicitly.
## Interaction with Existing Policies ## Interaction with Existing Policies
### Adding Allow Rules
In the scenario where there is not an explicit allow rule, there is not a managed installer or ISG EA and ISG is not configured, WDAC will block the file as there is nothing in the policy vouching for trust of the file. ### Adding Allow Rules
If this deny policy is the only policy on the device, the following rule(s) need to be added to the policy in addition to the deny/block rules to trust for the driver files outside of the intended blocklisted ones: If this deny policy is the only policy on the device, the following rule(s) need to be added to the policy in addition to the deny/block rules to trust for the driver files outside of the intended blocklisted ones:
@ -67,6 +67,7 @@ If this deny policy is the only policy on the device, the following rule(s) need
``` ```
If the policy enables user mode code integrity via the ***Enabled:UMCI*** rule-option, the following section needs to be added to the policy in addition to the deny/block rules to trust for the driver and user mode files outside of the intended blocklisted ones: If the policy enables user mode code integrity via the ***Enabled:UMCI*** rule-option, the following section needs to be added to the policy in addition to the deny/block rules to trust for the driver and user mode files outside of the intended blocklisted ones:
```xml ```xml
<FileRules> <FileRules>
<Allow ID="ID_ALLOW_A_1" FriendlyName="Allow Kernel Drivers" FileName="*" /> <Allow ID="ID_ALLOW_A_1" FriendlyName="Allow Kernel Drivers" FileName="*" />
@ -89,8 +90,10 @@ If the policy enables user mode code integrity via the ***Enabled:UMCI*** rule-o
</SigningScenario> </SigningScenario>
</SigningScenarios> </SigningScenarios>
``` ```
## Single Policy Considerations ## Single Policy Considerations
If the set of deny rules is to be added into an existing policy with allow rules, then the above Allow All rules should not be added to the policy. Instead, the deny policy should be merged with the existing WDAC policy via the [WDAC Wizard](wdac-wizard-merging-policies.md) or using the following PowerShell command:
If the set of deny rules is to be added into an existing policy with allow rules, then the above Allow All rules shouldn't be added to the policy. Instead, the deny policy should be merged with the existing WDAC policy via the [WDAC Wizard](wdac-wizard-merging-policies.md) or using the following PowerShell command:
```PowerShell ```PowerShell
$DenyPolicy = <path_to_deny_policy> $DenyPolicy = <path_to_deny_policy>
@ -99,41 +102,45 @@ Merge-CIPolicy -PolicyPaths $ DenyPolicy, $ExistingPolicy -OutputFilePath $Exist
``` ```
## Multiple Policy Considerations ## Multiple Policy Considerations
If you are currently using [multiple policies](deploy-multiple-windows-defender-application-control-policies.md) on a device, there are two options for integrating the blocklist into your policy set.
(Recommended) The first option is to keep the blocklist as its own policy isolated from your allow policies as it is easier to manage. Since applications need to be [allowed by both WDAC policies to run on the device](deploy-multiple-windows-defender-application-control-policies.md#base-and-supplemental-policy-interaction), you will need to add the Allow All rule(s) to your deny policy. This will not override the set of applications allowed by WDAC illustrated by the following example: If you're currently using [multiple policies](deploy-multiple-windows-defender-application-control-policies.md) on a device, there are two options for integrating the blocklist into your policy set.
Policy 1 is an allowlist of Windows and Microsoft-signed applications. Policy 2 is our new deny policy, which blocks MaliciousApp.exe with the Allow All rules. MaliciousApp.exe will be blocked since there is an explicit block rule in Policy 2. Windows and Microsoft applications will be allowed since there is an explicit allow rule in Policy 1 and Policy 2 (due to the Allow All rules). All other applications, if not Windows and Microsoft signed, for example, ExampleApp.exe, will not be allowed as this application is only trusted by Policy 2 (due to the Allow All rules) and not Policy 1. (Recommended) The first option is to keep the blocklist as its own policy isolated from your allow policies as it is easier to manage. Since applications need to be [allowed by both WDAC policies to run on the device](deploy-multiple-windows-defender-application-control-policies.md#base-and-supplemental-policy-interaction), you'll need to add the Allow All rule(s) to your deny policy. Doing so won't override the set of applications allowed by WDAC illustrated by the following example:
Policy 1 is an allowlist of Windows and Microsoft-signed applications. Policy 2 is our new deny policy, which blocks MaliciousApp.exe with the Allow All rules. MaliciousApp.exe will be blocked since there's an explicit block rule in Policy 2. Windows and Microsoft applications will be allowed since there's an explicit allow rule in Policy 1 and Policy 2 (due to the Allow All rules). All other applications, if not Windows and Microsoft signed, for example, ExampleApp.exe, won't be allowed as this application is only trusted by Policy 2 (due to the Allow All rules) and not Policy 1.
The second option involves merging the blocklist with your existing WDAC policy, regardless if the policy is an allowlist policy and contains allow and/or deny rules. The second option involves merging the blocklist with your existing WDAC policy, regardless if the policy is an allowlist policy and contains allow and/or deny rules.
## Best Practices ## Best Practices
1. **Starting with Audit Mode Policies** - as with all new policies, we recommend rolling out your new deny policy in Audit Mode and monitoring the [3077 block events](event-id-explanations.md#optional-intelligent-security-graph-isg-or-managed-installer-mi-diagnostic-events) to ensure only the applications you intended to block are being blocked. More information on monitoring block events via the Event Viewer logs and Advanced Hunting: [Managing and troubleshooting Windows Defender Application Control policies](windows-defender-application-control-operational-guide.md) 1. **Starting with Audit Mode Policies** - as with all new policies, we recommend rolling out your new deny policy in Audit Mode and monitoring the [3077 block events](event-id-explanations.md) to ensure only the applications you intended to block are being blocked. More information on monitoring block events via the Event Viewer logs and Advanced Hunting: [Managing and troubleshooting Windows Defender Application Control policies](windows-defender-application-control-operational-guide.md)
2. **Recommended Deny Rules Types** - signer and file attribute rules are recommended from a security, manageability, and performance perspective. Hash rules should only be utilized where otherwise impossible. The hash of an application is updated for every new version released by the publisher, which quickly becomes impractical to manage and protect against new threats where the attacker is quickly iterating on the payload. Additionally, WDAC has optimized parsing of hash rules, but devices may see performance impacts at runtime evaluation when policies have tens of thousands or more hash rules. 2. **Recommended Deny Rules Types** - signer and file attribute rules are recommended from a security, manageability, and performance perspective. Hash rules should only be utilized where otherwise impossible. The hash of an application is updated for every new version released by the publisher, which quickly becomes impractical to manage and protect against new threats where the attacker is quickly iterating on the payload. Additionally, WDAC has optimized parsing of hash rules, but devices may see performance impacts at runtime evaluation when policies have tens of thousands or more hash rules.
## Creating a Deny Policy Tutorial ## Creating a Deny Policy Tutorial
Deny rules and policies can be created using the PowerShell cmdlets or the [WDAC Wizard](https://webapp-wdac-wizard.azurewebsites.net/). We recommend creating signer rules (PCACertificate, Publisher, and FilePublisher) wherever possible. In the cases of unsigned binaries, rules must be created on attributes of the file, such as the original filename, or the hash. Deny rules and policies can be created using the PowerShell cmdlets or the [WDAC Wizard](https://webapp-wdac-wizard.azurewebsites.net/). We recommend creating signer rules (PCACertificate, Publisher, and FilePublisher) wherever possible. In the cases of unsigned binaries, rules must be created on attributes of the file, such as the original filename, or the hash.
### Software Publisher Based Deny Rule ### Software Publisher Based Deny Rule
```Powershell ```Powershell
$DenyRules += New-CIPolicyRule -Level FilePublisher -DriverFilePath <binary_to_block> -Deny -Fallback FileName,Hash $DenyRules += New-CIPolicyRule -Level FilePublisher -DriverFilePath <binary_to_block> -Deny -Fallback FileName,Hash
``` ```
### Software Attributes Based Deny Rule ### Software Attributes Based Deny Rule
```Powershell ```Powershell
$DenyRules += New-CIPolicyRule -Level FileName -DriverFilePath <binary_to_block> -Deny -Fallback Hash $DenyRules += New-CIPolicyRule -Level FileName -DriverFilePath <binary_to_block> -Deny -Fallback Hash
``` ```
### Hash Based Deny Rule ### Hash Based Deny Rule
```PowerShell ```PowerShell
New-CIPolicyRule -Level Hash -DriverFilePath <binary_to_block> -Deny New-CIPolicyRule -Level Hash -DriverFilePath <binary_to_block> -Deny
``` ```
### Adding Allow All Rules ### Adding Allow All Rules
If necessary, as in the cases listed above, [Allow All Rules](#adding-allow-rules) may need to be added to the policy. The Allow All rules can be manually added to the policy xml or by merging with the Allow All xml present on the client system in the WDAC template folder: If necessary, as in the cases listed above, [Allow All Rules](#adding-allow-rules) may need to be added to the policy. The Allow All rules can be manually added to the policy xml or by merging with the Allow All xml present on the client system in the WDAC template folder:
```PowerShell ```PowerShell
@ -141,7 +148,9 @@ $DenyPolicy = <path_to_deny_policy>
$AllowAllPolicy = $Env:windir + "\schemas\CodeIntegrity\ExamplePolicies\AllowAll.xml" $AllowAllPolicy = $Env:windir + "\schemas\CodeIntegrity\ExamplePolicies\AllowAll.xml"
Merge-CIPolicy -PolicyPaths $DenyPolicy, $AllowAllPolicy -OutputFilePath $DenyPolicy Merge-CIPolicy -PolicyPaths $DenyPolicy, $AllowAllPolicy -OutputFilePath $DenyPolicy
``` ```
### Deploying the Deny Policy ### Deploying the Deny Policy
Policies should be thoroughly evaluated and first rolled out in audit mode before strict enforcement. Policies can be deployed via multiple options: Policies should be thoroughly evaluated and first rolled out in audit mode before strict enforcement. Policies can be deployed via multiple options:
1. Mobile Device Management (MDM): [Deploy WDAC policies using Mobile Device Management (MDM) (Windows)](deploy-windows-defender-application-control-policies-using-intune.md) 1. Mobile Device Management (MDM): [Deploy WDAC policies using Mobile Device Management (MDM) (Windows)](deploy-windows-defender-application-control-policies-using-intune.md)

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

@ -11,10 +11,10 @@ ms.localizationpriority: medium
audience: ITPro audience: ITPro
ms.collection: M365-security-compliance ms.collection: M365-security-compliance
author: jsuther1974 author: jsuther1974
ms.reviewer: isbrahm ms.reviewer: jogeurte
ms.author: dansimp ms.author: dansimp
manager: dansimp manager: dansimp
ms.date: 06/02/2021 ms.date: 02/01/2022
ms.technology: windows-sec ms.technology: windows-sec
--- ---
@ -22,71 +22,71 @@ ms.technology: windows-sec
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: 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** - Events about WDAC policy activation and the control of executables, dlls, and drivers 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** - Events about the control of MSI installers, scripts, and COM objects appear in **Applications and Services logs** > **Microsoft** > **Windows** > **AppLocker** > **MSI and Script**
> [!NOTE] > [!NOTE]
> These event IDs are not applicable on Windows Server Core edition. > These event IDs are not included on Windows Server Core edition.
## Microsoft Windows CodeIntegrity Operational log event IDs ## WDAC events found in the Microsoft Windows CodeIntegrity Operational log
| Event ID | Explanation | | Event ID | Explanation |
|--------|-----------| |--------|-----------|
| 3076 | Audit executable/dll file | | 3004 | This event isn't common and may occur with or without a WDAC policy present. It typically indicates a kernel driver tried to load with an invalid signature. For example, the file may not be WHQL-signed on a system where WHQL is required. |
| 3077 | Block executable/dll file | | 3033 | This event isn't common. It often means the file's signature is revoked or expired. Try using option *20 Enabled:Revoked Expired As Unsigned* in your policy along with a non-signature rule (for example, hash) to address issues with revoked or expired certs. |
| 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". | | 3034 | This event isn't common. It is the audit mode equivalent of event 3033 described above. |
| 3099 | Indicates that a policy has been loaded | | 3076 | This event is the main WDAC block event for audit mode policies. It indicates that the file would have been blocked if the WDAC policy was enforced. |
| 3077 | This event is the main WDAC block event for enforced policies. It indicates that the file did not pass your WDAC policy and was blocked. |
| 3089 | This event contains signature information for files that were blocked or would have been blocked by WDAC. One 3089 event is created for each signature of a file. The event shows the total number of signatures found and an index value to identify the current signature. Unsigned files produce a single 3089 event with TotalSignatureCount 0. 3089 events are correlated with 3004, 3033, 3034, 3076 and 3077 events. You can match the events using the "Correlation ActivityID" found in the "System" portion of the event. |
| 3099 | Indicates that a policy has been loaded. This event also includes information about the policy options that were specified by the policy. Refer to the |
## Microsoft Windows AppLocker MSI and Script log event IDs ## WDAC events found in the Microsoft Windows AppLocker MSI and Script log
| Event ID | Explanation | | Event ID | Explanation |
|--------|-----------| |--------|-----------|
| 8028 | Audit script/MSI file generated by Windows LockDown Policy (WLDP) being called by the script hosts themselves. Note: there is no WDAC enforcement on third-party script hosts. | | 8028 | This event indicates that a script host, such as PowerShell, queried WDAC about a file the script host was about to run. Since the WDAC policy was in audit mode, the script or MSI file should have run. Some script hosts may have additional information in their logs. Note: Most third-party script hosts do not integrate with WDAC. Consider the risks from unverified scripts when choosing which script hosts you allow to run. |
| 8029 | Block script/MSI file | | 8029 | This event is the enforcement mode equivalent of event 8028 described above. Note: While this event says that a script was blocked, the actual script enforcement behavior is implemented by the script host. The script host may allow the file to run with restrictions and not block the file outright. For example, PowerShell will allow a script to run but only in [Constrained Language Mode](/powershell/module/microsoft.powershell.core/about/about_language_modes.md). |
| 8036| COM object was blocked. To learn more about COM object authorization, see [Allow COM object registration in a Windows Defender Application Control policy](allow-com-object-registration-in-windows-defender-application-control-policy.md). | | 8036| COM object was blocked. To learn more about COM object authorization, see [Allow COM object registration in a Windows Defender Application Control policy](allow-com-object-registration-in-windows-defender-application-control-policy.md). |
| 8038 | Signing information event correlated with either an 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". | | 8038 | Signing information event correlated with either an 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. 8038 events are correlated with 8028 and 8029 events and can be matched using the "Correlation ActivityID" found in the "System" portion of the event. |
## Optional Intelligent Security Graph (ISG) or Managed Installer (MI) diagnostic events ## Diagnostic events for Intelligent Security Graph (ISG) and Managed Installer (MI)
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 more diagnostic information. Events 3090, 3091 and 3092 prove helpful diagnostic information when the ISG or MI option is enabled by any WDAC policy. These events can help you debug why something was allowed/denied based on managed installer or ISG. These events do not necessarily indicate a problem but should be reviewed in context with other events like 3076 or 3077 described above.
| Event ID | Explanation | | Event ID | Explanation |
|--------|---------| |--------|---------|
| 3090 | Allow executable/dll file | | 3090 | *Optional* This event indicates that a file was allowed to run based purely on ISG or managed installer. |
| 3091 | Audit executable/dll file | | 3091 | This event indicates that a file did not have ISG or managed installer authorization and the policy is in audit mode. |
| 3092 | Block executable/dll file | | 3092 | This event is the enforcement mode equivalent of 3091. |
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 that 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. The above events are reported per active policy on the system, so you may see multiple events for the same file.
### SmartLocker template ### ISG and MI diagnostic event details
Below are the fields that help to diagnose what a 3090, 3091, or 3092 event indicates. The following information is found in the details for 3090, 3091, and 3092 events.
| Name | Explanation | | 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 | Indicates whether the specified policy enables managed installer trust |
| ManagedInstallerEnabled | Policy trusts a MI | | PassesManagedInstaller | Indicates whether the file originated from a MI |
| PassesManagedInstaller | File originated from a trusted MI | | SmartlockerEnabled | Indicates whether the specified policy enables ISG trust |
| SmartlockerEnabled | Policy trusts the ISG | | PassesSmartlocker | Indicates whether the file had positive reputation according to the ISG |
| PassesSmartlocker | File had positive reputation |
| AuditEnabled | True if the policy is in audit mode, otherwise it is in enforce mode | | AuditEnabled | True if the policy is in audit mode, otherwise it is in enforce mode |
| PolicyName | The name of the policy to which the event applies |
### Enabling ISG and MI diagnostic events ### 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: To enable 3090 allow events, create a TestFlags regkey with a value of 0x300 as shown in the following PowerShell command. Then restart your computer.
```powershell
reg add hklm\system\currentcontrolset\control\ci -v TestFlags -t REG_DWORD -d 0x100
```
To enable 3090 allow events, and 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 ```powershell
reg add hklm\system\currentcontrolset\control\ci -v TestFlags -t REG_DWORD -d 0x300 reg add hklm\system\currentcontrolset\control\ci -v TestFlags -t REG_DWORD -d 0x300
``` ```
## System Integrity Policy Options 3091 and 3092 events are inactive on some versions of Windows. The above steps will also turn on those events.
## Event ID 3099 Options
The WDAC policy rule-option values can be derived from the "Options" field in the Details section of the Code integrity 3099 event. To parse the values, first convert the hex value to binary. Next, use the bit addresses and their values from the table below to determine the state of each [policy rule-option](/select-types-of-rules-to-create#table-1-windows-defender-application-control-policy---rule-options). The WDAC policy rule-option values can be derived from the "Options" field in the Details section of the Code integrity 3099 event. To parse the values, first convert the hex value to binary. Next, use the bit addresses and their values from the table below to determine the state of each [policy rule-option](/select-types-of-rules-to-create#table-1-windows-defender-application-control-policy---rule-options).
| Bit Address | Policy Rule Option | | Bit Address | Policy Rule Option |
@ -113,6 +113,7 @@ The WDAC policy rule-option values can be derived from the "Options" field in th
| 28 | `Enabled:Update Policy No Reboot` | | 28 | `Enabled:Update Policy No Reboot` |
## Appendix ## Appendix
A list of other relevant event IDs and their corresponding description. A list of other relevant event IDs and their corresponding description.
| Event ID | Description | | Event ID | Description |