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

Merge pull request #8130 from jsuther1974/WDAC-Docs

Browse Source 
Various fixes to WDAC docs
This commit is contained in:
Angela Fleischmann 2023-04-06 15:54:25 -06:00 committed by GitHub
commit 7524231661
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
13 changed files with 229 additions and 258 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

23
windows/security/threat-protection/windows-defender-application-control/LOB-win32-apps-on-s.md
View File

@ -4,10 +4,10 @@ description: Using Windows Defender Application Control (WDAC) supplemental poli
ms.prod: windows-client
ms.localizationpriority: medium
author: jsuther1974
ms.reviewer: isbrahm
ms.reviewer: jogeurte
ms.author: vinpa
manager: aaroncz
ms.date: 10/30/2019
ms.date: 04/05/2023
ms.technology: itpro-security
ms.topic: how-to
---
@ -17,14 +17,13 @@ ms.topic: how-to
**Applies to:**
- Windows 10
- Windows 11
> [!NOTE]
> Some capabilities of Windows Defender Application Control (WDAC) are only available on specific Windows versions. For more information, see [Windows Defender Application Control feature availability](feature-availability.md).
You can use Microsoft Intune to deploy and run critical Win32 applications and Windows components that are normally blocked in S mode on their Intune-managed Windows in S mode devices. For example, PowerShell.exe.
You can use Microsoft Intune to deploy and run critical Win32 applications, and Windows components that are normally blocked in S mode, on your Intune-managed Windows 10 in S mode devices. For example, PowerShell.exe.
With Intune, you can configure managed S mode devices using a Windows Defender Application Control supplemental policy that expands the S mode base policy to authorize the apps your organization uses. This feature changes the S mode security posture from "every app is Microsoft-verified" to "every app is verified by Microsoft or your organization".
With Intune, you can configure managed S mode devices using a Windows Defender Application Control (WDAC) supplemental policy that expands the S mode base policy to authorize the apps your organization uses. This feature changes the S mode security posture from "Microsoft has verified every app" to "Microsoft or your organization has verified every app".
For an overview and brief demo of this feature, see this video:
@ -34,13 +33,13 @@ For an overview and brief demo of this feature, see this video:
![Basic diagram of the policy authorization flow.](images/wdac-intune-policy-authorization.png)
The general steps for expanding the S mode base policy on your Intune-managed devices are to generate a supplemental policy, sign that policy, and then upload the signed policy to Intune and assign it to user or device groups. Because you need access to PowerShell cmdlets to generate your supplemental policy, you should create and manage your policies on a non-S mode device. Once the policy has been uploaded to Intune, before deploying the policy more broadly, assign it to a single test S-mode device to verify expected functioning.
The general steps for expanding the S mode base policy on your Intune-managed Windows 10 in S mode devices are to generate a supplemental policy, sign that policy, upload the signed policy to Intune, and assign it to user or device groups. Because you need access to PowerShell cmdlets to generate your supplemental policy, you should create and manage your policies on a non-S mode device. Once the policy has been uploaded to Intune, before deploying the policy more broadly, assign it to a single test Windows 10 in S mode device to verify expected functioning.
1. Generate a supplemental policy with Windows Defender Application Control tooling.
1. Generate a supplemental policy with WDAC tooling.
This policy expands the S mode base policy to authorize more applications. Anything authorized by either the S mode base policy or your supplemental policy is allowed to run. Your supplemental policies can specify filepath rules, trusted publishers, and more.
For more information on creating supplemental policies, see [Deploy multiple Windows Defender Application Control policies](deploy-multiple-windows-defender-application-control-policies.md). For more information on the right type of rules to create for your policy, see [Deploy Windows Defender Application Control policy rules and file rules](select-types-of-rules-to-create.md).
For more information on creating supplemental policies, see [Deploy multiple WDAC policies](deploy-multiple-windows-defender-application-control-policies.md). For more information on the right type of rules to create for your policy, see [Deploy WDAC policy rules and file rules](select-types-of-rules-to-create.md).
The following instructions are a basic set for creating an S mode supplemental policy:
@ -68,7 +67,7 @@ The general steps for expanding the S mode base policy on your Intune-managed de
- Since you're signing your policy, you must authorize the signing certificate you use to sign the policy. Optionally, also authorize one or more extra signers that can be used to sign updates to the policy in the future. The next step in the overall process, **Sign the policy**, describes it in more detail.
To add the signing certificate to the Windows Defender Application Control policy, use [Add-SignerRule](/powershell/module/configci/add-signerrule?view=win10-ps&preserve-view=true).
To add the signing certificate to the WDAC policy, use [Add-SignerRule](/powershell/module/configci/add-signerrule?view=win10-ps&preserve-view=true).
```powershell
Add-SignerRule -FilePath <policypath> -CertificatePath <certpath> -User -Update
@ -82,7 +81,7 @@ The general steps for expanding the S mode base policy on your Intune-managed de
2. Sign the policy.
Supplemental S mode policies must be digitally signed. To sign your policy, use your organization's custom Public Key Infrastructure (PKI). For more information on signing using an internal CA, see [Create a code signing cert for Windows Defender Application Control](create-code-signing-cert-for-windows-defender-application-control.md).
Supplemental S mode policies must be digitally signed. To sign your policy, use your organization's custom Public Key Infrastructure (PKI). For more information on signing using an internal CA, see [Create a code signing cert for WDAC](create-code-signing-cert-for-windows-defender-application-control.md).
> [!TIP]
> For more information, see [Azure Code Signing, democratizing trust for developers and consumers](https://techcommunity.microsoft.com/t5/security-compliance-and-identity/azure-code-signing-democratizing-trust-for-developers-and/ba-p/3604669).
@ -110,7 +109,7 @@ Your supplemental policy can be used to significantly relax the S mode base poli
Instead of authorizing signers external to your organization, Intune has functionality to make it easier to authorize existing applications by using signed catalogs. This feature doesn't require repackaging or access to the source code. It works for apps that may be unsigned or even signed apps when you don't want to trust all apps that may share the same signing certificate.
The basic process is to generate a catalog file for each app using Package Inspector, then sign the catalog files using a custom PKI. To authorize the catalog signing certificate in the supplemental policy, use the **Add-SignerRule** PowerShell cmdlet as shown above in step 1 of the [Policy authorization process](#policy-authorization-process). After that, use the [Standard process for deploying apps through Intune](#standard-process-for-deploying-apps-through-intune) outlined above. For more information on generating catalogs, see [Deploy catalog files to support Windows Defender Application Control](deploy-catalog-files-to-support-windows-defender-application-control.md).
The basic process is to generate a catalog file for each app using Package Inspector, then sign the catalog files using a custom PKI. To authorize the catalog signing certificate in the supplemental policy, use the **Add-SignerRule** PowerShell cmdlet as shown earlier in step 1 of the [Policy authorization process](#policy-authorization-process). After that, use the [Standard process for deploying apps through Intune](#standard-process-for-deploying-apps-through-intune) outlined earlier. For more information on generating catalogs, see [Deploy catalog files to support WDAC](deploy-catalog-files-to-support-windows-defender-application-control.md).
> [!NOTE]
> Every time an app updates, you need to deploy an updated catalog. Try to avoid using catalog files for applications that auto-update, and direct users not to update applications on their own.
@ -260,4 +259,4 @@ You can also delete a supplemental policy through Intune.
## Errata
If an S-mode device with a policy authorization token and supplemental policy is rolled back from the 1909 update to the 1903 build, it will not revert to locked-down S mode until the next policy refresh. To achieve an immediate change to a locked-down S mode state, IT Pros should delete any tokens in %SystemRoot%\System32\CI\Tokens\Active.
If a Windows 10 in S mode device with a policy authorization token and supplemental policy is rolled back from the 1909 update to the 1903 build, it will not revert to locked-down S mode until the next policy refresh. To achieve an immediate change to a locked-down S mode state, IT Pros should delete any tokens in %SystemRoot%\System32\CI\Tokens\Active.

42
windows/security/threat-protection/windows-defender-application-control/allow-com-object-registration-in-windows-defender-application-control-policy.md
View File

@ -10,11 +10,11 @@ ms.pagetype: security
ms.localizationpriority: medium
audience: ITPro
author: vinaypamnani-msft
ms.reviewer: isbrahm
ms.reviewer: jsuther
ms.author: vinpa
manager: aaroncz
ms.technology: itpro-security
ms.date: 12/31/2017
ms.date: 04/05/2023
ms.topic: article
---
@ -22,36 +22,28 @@ ms.topic: article
**Applies to:**
- Windows 10
- Windows 11
- Windows Server 2016 and later
- Windows 10
- Windows 11
- Windows Server 2016 and later
> [!NOTE]
> Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Application Control feature availability](feature-availability.md).
The [Microsoft Component Object Model (COM)](/windows/desktop/com/the-component-object-model) is a platform-independent, distributed, object-oriented system for creating binary software components that can interact. COM specifies an object model and programming requirements that enable COM objects to interact with other objects.
> [!IMPORTANT]
> Some information relates to pre-released product which may be substantially modified before it's commercially released. Microsoft makes no warranties, express or implied, with respect to the information provided here.
## COM object configurability in WDAC policy
### COM object configurability in WDAC policy
Prior to the Windows 10 1903 update, Windows Defender Application Control (WDAC) enforced a built-in allowlist for COM object registration. While this mechanism works for most common application usage scenarios, customers have provided feedback that there are cases where more COM objects need to be allowed. The 1903 update to Windows 10 introduces the ability to specify allowed COM objects via their GUID in the WDAC policy.
Windows Defender Application Control (WDAC) enforces a built-in allowlist for COM object registration. While this list works for most common application usage scenarios, you may need to allow more COM objects to support the apps used in your organization. You can specify allowed COM objects via their GUID in your WDAC policy as described in this article.
> [!NOTE]
> To add this functionality to other versions of Windows 10, you can install the following or later updates.
- Windows 10, 1809 June 18, 2019—KB4501371 (OS Build 17763.592) (https://support.microsoft.com/help/4501371/windows-10-update-kb4501371)
- Windows 10, 1803 June 18, 2019—KB4503288 (OS Build 17134.858) (https://support.microsoft.com/help/4503288/windows-10-update-kb4503288)
- Windows 10, 1709 June 18, 2019—KB4503281 (OS Build 16299.1237) (https://support.microsoft.com/help/4503281/windows-10-update-kb4503281)
- Windows 10, 1703 June 18, 2019—KB4503289 (OS Build 15063.1897) (https://support.microsoft.com/help/4503289/windows-10-update-kb4503289
- Windows 10, 1607 June 18, 2019—KB4503294 (OS Build 14393.3053) (https://support.microsoft.com/help/4503294/windows-10-update-kb4503294)
- [Windows 10, 1809 June 18, 2019—KB4501371 (OS Build 17763.592)](https://support.microsoft.com/help/4501371/windows-10-update-kb4501371)
- [Windows 10, 1607 June 18, 2019—KB4503294 (OS Build 14393.3053)](https://support.microsoft.com/help/4503294/windows-10-update-kb4503294)
### Get COM object GUID
Get GUID of application to allow in one of the following ways:
- Finding a block event in Event Viewer (Application and Service Logs > Microsoft > Windows > AppLocker > MSI and Script), and extracting GUID
- Creating an audit policy (using New-CIPolicy –Audit), potentially with a specific provider, and use the info from the block events to get the GUID
You can get the COM application GUID from the 8036 COM object block events in Event Viewer located at **Application and Service Logs > Microsoft > Windows > AppLocker > MSI and Script**, and extract the GUID from the event data.
### Author policy setting to allow or deny COM object GUID
@ -72,7 +64,7 @@ One attribute:
### Multiple policy considerations
Similar to executable files, COM objects must pass each policy on the system to be allowed by WDAC. For example, if the COM object under evaluation passes most but not all of your WDAC policies, the COM object will not be allowed. If you are using a combination of base and supplemental policies, the COM object just needs to be allowlisted in either the base policy or one of the supplemental policies.
Similar to executable files, COM objects must pass all enforced WDAC policies on the system to run. For example, if the COM object under evaluation passes most but not all of your WDAC policies, the COM object is blocked. If you're using a combination of base and supplemental policies, the COM object just needs to be allowlisted in either the base policy or one of the supplemental policies.
### Examples
@ -105,9 +97,10 @@ Example 3: Allows a specific COM object to register in PowerShell
</Value>
</Setting>
```
### How to configure settings for the CLSIDs
Here's an example of an error in the Event Viewer (**Application and Service Logs** > **Microsoft** > **Windows** > **AppLocker** > **MSI and Script**):
Here's an example of an error in the Event Viewer found at **Application and Service Logs > Microsoft > Windows > AppLocker > MSI and Script**:
> Log Name: Microsoft-Windows-AppLocker/MSI and Script<br/>
> Source: Microsoft-Windows-AppLocker<br/>
@ -156,9 +149,9 @@ To add this CLSID to the existing policy, follow these steps:
```PowerShell
PS C:\WINDOWS\system32> Set-CIPolicySetting -FilePath <path to policy xml>\WDAC_policy.xml -Key "{f8d253d9-89a4-4daa-87b6-1168369f0b21}" -Provider WSH -Value true -ValueName EnterpriseDefinedClsId -ValueType Boolean
```
Once the command has been run, you'll find that the following section is added to the policy XML.
Once the command has run, find the following section added to the policy XML.
```XML
<Settings>
<Setting Provider="WSH" Key="{f8d253d9-89a4-4daa-87b6-1168369f0b21}" ValueName="EnterpriseDefinedClsId">
@ -167,9 +160,10 @@ To add this CLSID to the existing policy, follow these steps:
</Value>
</Setting>
```
### Default COM Object allowlist
The table below describes the list of COM objects that are inherently trusted in Windows Defender Application Control. Objects in this list don't need to be allowlisted in your WDAC policies. They can be denied by creating explicit deny rules in your WDAC policy.
The table that follows describes the list of COM objects that are inherently trusted in Windows Defender Application Control. Objects in this list don't need to be allowlisted in your WDAC policies. They can be denied by creating explicit deny rules in your WDAC policy.
| File Name | CLSID |
|--------|-----------|

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

@ -20,56 +20,11 @@ ms.topic: article
# Guidance on Creating WDAC Deny Policies
With Windows Defender Application Control (WDAC), you can create policies to explicitly deny specific drivers and applications.
With Windows Defender Application Control (WDAC), you can create policies to explicitly deny specific drivers and applications. To create effective Windows Defender Application Control deny policies, you should [understand the order of rule precedence](/windows/security/threat-protection/windows-defender-application-control/operations/known-issues#file-rule-precedence-order) WDAC applies as it evaluates files against the active policies.
In this article we explain:
## Standalone Deny policy
1. File Rule Precedence Order
2. Adding Allow Rules
3. Single Policy Considerations
4. Multiple Policy Considerations
5. Best Practices
6. Tutorial
## File Rule Precedence Order
To create effective Windows Defender Application Control 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 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.
3. WDAC will then check for the [Managed Installer extended (EA)](configure-authorized-apps-deployed-with-a-managed-installer.md) or the [Intelligent Security Graph (ISG) EA](use-windows-defender-application-control-with-intelligent-security-graph.md) on the file.
4. Lastly, WDAC will call the Intelligent Security Graph (ISG) to get reputation on file, if the policy has support for the ISG.
5. If no rule exists for the file and it's not allowed based on ISG or MI, then the file is blocked implicitly.
> [!NOTE]
> If your Windows Defender Application Control 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. For more details, see [How does the integration between WDAC and the Intelligent Security Graph work?](/windows/security/threat-protection/windows-defender-application-control/use-windows-defender-application-control-with-intelligent-security-graph#how-does-wdac-work-with-the-isg).
## Interaction with Existing Policies
### 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:
```xml
<FileRules>
<Allow ID="ID_ALLOW_A_1" FriendlyName="Allow Kernel Drivers" FileName="*" />
</FileRules>
<SigningScenarios>
<SigningScenario Value="131" ID="ID_SIGNINGSCENARIO_DRIVERS_1" FriendlyName="Kernel Mode Signing Scenario">
<ProductSigners>
<FileRulesRef>
<FileRuleRef RuleID="ID_ALLOW_A_1" />
</FileRulesRef>
</ProductSigners>
</SigningScenario>
</SigningScenarios>
```
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:
When creating a policy that consists solely of deny rules, you must include "Allow All" rules in both the kernel and user mode sections of the policy in addition to your explicit deny rules. The "Allow All" rules ensure that anything not explicitly denied by your policy is allowed to run. If you fail to add "Allow All" rules to a deny-only policy, then you risk blocking everything. This outcome happens because some code is *explicitly* denied and all other code is *implicitly* denied, because there are no rules to authorize it. We recommend using the [AllowAll policy template](/windows/security/threat-protection/windows-defender-application-control/example-wdac-base-policies) when creating your standalone deny policies.
```xml
<FileRules>
@ -77,7 +32,7 @@ If the policy enables user mode code integrity via the ***Enabled:UMCI*** rule-o
<Allow ID="ID_ALLOW_A_2" FriendlyName="Allow User mode components" FileName="*" />
</FileRules>
<SigningScenarios>
<SigningScenario Value="131" ID="ID_SIGNINGSCENARIO_DRIVERS_1" FriendlyName="Kernel Mode Signing Scenario">
<SigningScenario Value="131" ID="ID_SIGNINGSCENARIO_DRIVERS" FriendlyName="Kernel Mode Signing Scenario">
<ProductSigners>
<FileRulesRef>
<FileRuleRef RuleID="ID_ALLOW_A_1" />
@ -94,9 +49,20 @@ If the policy enables user mode code integrity via the ***Enabled:UMCI*** rule-o
</SigningScenarios>
```
## Single Policy Considerations
Adding the preceding "Allow All" rules don't affect any other WDAC policies you've deployed that apply an explicit allowlist. To illustrate, consider the following example:
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:
Policy1 is an allowlist for Windows- and Microsoft-signed applications.
Policy2 is our new deny policy, which blocks MaliciousApp.exe and also the Windows component binary wmic.exe. It also includes the "Allow All" rules.
- MaliciousApp.exe is blocked since there's an explicit block rule in Policy2. It's also *implicitly* blocked by Policy1 since there are no allow rules that cover the file in that policy.
- The Windows-signed file wmic.exe is blocked since there's an explicit block rule in Policy2.
- All other Windows- and Microsoft-signed applications are allowed since there's an explicit allow rule in both Policy1 and Policy2 that covers the file.
- All other applications are implicitly denied. For example, ExampleApp.exe, isn't allowed since it's only trusted by Policy2 (due to the Allow All rules) and not Policy1.
## Mixed Allow and Deny policy considerations
If the set of deny rules is to be added into an existing policy that includes explicit allow rules, then don't include the preceding "Allow All" rules. Instead, the deny rules should be merged with the existing WDAC policy via the [WDAC Wizard](wdac-wizard-merging-policies.md) or using the following PowerShell command:
```PowerShell
$DenyPolicy = <path_to_deny_policy>
@ -104,62 +70,45 @@ $ExistingPolicy = <path_to_existing_policy>
Merge-CIPolicy -PolicyPaths $ DenyPolicy, $ExistingPolicy -OutputFilePath $ExistingPolicy
```
## Multiple Policy Considerations
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.
(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.
## 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) 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. **Test first in Audit mode** - as with all new policies, we recommend rolling out your new deny policy in Audit Mode and monitoring the [3076 audit block events](event-id-explanations.md) to ensure only the applications you intended to block are 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 used if necessary. Since the hash of a file changes with any change to the file, it's hard to keep up with a hash-based block policy where the attacker can trivially update the file. While WDAC has optimized parsing of hash rules, some devices may see performance impacts at runtime evaluation if 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.
### Software Publisher Based Deny Rule
### Software Publisher-based deny rule
```Powershell
$DenyRules += New-CIPolicyRule -Level FilePublisher -DriverFilePath <binary_to_block> -Fallback SignedVersion,Publisher,Hash -Deny
```
### Software Attributes Based Deny Rule
### Software attributes-based deny rule
```Powershell
$DenyRules += New-CIPolicyRule -Level FileName -DriverFilePath <binary_to_block> -Fallback Hash -Deny
```
### Hash Based Deny Rule
### Hash-based deny rule
```PowerShell
New-CIPolicyRule -Level Hash -DriverFilePath <binary_to_block> -Deny
```
### 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:
```PowerShell
$DenyPolicy = <path_to_deny_policy>
$AllowAllPolicy = $Env:windir + "\schemas\CodeIntegrity\ExamplePolicies\AllowAll.xml"
Merge-CIPolicy -PolicyPaths $DenyPolicy, $AllowAllPolicy -OutputFilePath $DenyPolicy
$DenyRules += New-CIPolicyRule -Level Hash -DriverFilePath <binary_to_block> -Deny
```
### Deploying the Deny Policy
### Merge deny rules with AllowAll template policy
Policies should be thoroughly evaluated and first rolled out in audit mode before strict enforcement. Policies can be deployed via multiple options:
After creating your deny rules, you can merge them with the AllowAll template policy:
1. Mobile Device Management (MDM): [Deploy WDAC policies using Mobile Device Management (MDM)](deployment/deploy-windows-defender-application-control-policies-using-intune.md)
```PowerShell
$DenyPolicy = <path_to_deny_policy_destination>
$AllowAllPolicy = $Env:windir + "\schemas\CodeIntegrity\ExamplePolicies\AllowAll.xml"
Merge-CIPolicy -PolicyPaths $AllowAllPolicy -OutputFilePath $DenyPolicy -Rules $DenyRules
Set-CiPolicyIdInfo -FilePath $DenyPolicy -PolicyName "My Deny Policy" -ResetPolicyID
```
2. Configuration Manager: [Deploy Windows Defender Application Control (WDAC) policies by using Configuration Manager (Windows)](deployment/deploy-wdac-policies-with-memcm.md)
### Deploy the Deny Policy
3. Scripting [Deploy Windows Defender Application Control (WDAC) policies using script (Windows)](deployment/deploy-wdac-policies-with-script.md)
4. Group Policy: [Deploy WDAC policies via Group Policy (Windows)](deployment/deploy-windows-defender-application-control-policies-using-group-policy.md)
You should now have a deny policy prepared to deploy. See the [WDAC Deployment Guide](/windows/security/threat-protection/windows-defender-application-control/windows-defender-application-control-deployment-guide) to deploy your policy to your managed endpoints.

30
windows/security/threat-protection/windows-defender-application-control/design/script-enforcement.md
View File

@ -9,7 +9,7 @@ ms.reviewer: jogeurte
ms.author: jogeurte
ms.manager: jsuther
manager: aaroncz
ms.date: 02/02/2023
ms.date: 04/05/2023
ms.technology: itpro-security
ms.topic: article
ms.localizationpriority: medium
@ -31,47 +31,47 @@ ms.localizationpriority: medium
## Script enforcement overview
By default, script enforcement is enabled for all WDAC policies unless the option **11 Disabled:Script Enforcement** is set in the policy. WDAC script enforcement involves a handshake between an enlightened script host, such as PowerShell, and WDAC. The actual enforcement behavior, however, is handled entirely by the script host. Some script hosts, like the Microsoft HTML Application Host (mshta.exe), simply block all code execution if any WDAC UMCI policy is active. Most script hosts first ask WDAC whether a script should be allowed to run based on the WDAC policies currently active. The script host then either blocks, allows, or changes *how* the script is run to best protect the user and the device.
By default, script enforcement is enabled for all WDAC policies unless the option **11 Disabled:Script Enforcement** is set in the policy. WDAC script enforcement involves a handshake between an enlightened script host, such as PowerShell, and WDAC. However, the script host handles the actual enforcement behavior. Some script hosts, like the Microsoft HTML Application Host (mshta.exe), block all code execution if any WDAC UMCI policy is active. Most script hosts first ask WDAC whether a script should be allowed to run based on the WDAC policies currently active. The script host then either blocks, allows, or changes *how* the script is run to best protect the user and the device.
Validation for signed scripts is done using the [WinVerifyTrust API](/windows/win32/api/wintrust/nf-wintrust-winverifytrust). To pass validation, the signature root must be present in the trusted root store on the device and be allowed by your WDAC policy. This behavior is different from WDAC validation for executable files, which doesn't require installation of the root certificate.
Validation for signed scripts is done using the [WinVerifyTrust API](/windows/win32/api/wintrust/nf-wintrust-winverifytrust). To pass validation, the signature root must be present in the trusted root store on the device and your WDAC policy must allow it. This behavior is different from WDAC validation for executable files, which doesn't require installation of the root certificate.
WDAC shares the *AppLocker - MSI and Script* event log for all script enforcement events. Whenever a script host asks WDAC if a script should be allowed, an event will be logged with the answer WDAC returned to the script host. For more information on WDAC script enforcement events, see [Understanding Application Control events](/windows/security/threat-protection/windows-defender-application-control/event-id-explanations#windows-applocker-msi-and-script-log).
WDAC shares the *AppLocker - MSI and Script* event log for all script enforcement events. Whenever a script host asks WDAC if a script should be allowed, an event is logged with the answer WDAC returned to the script host. For more information on WDAC script enforcement events, see [Understanding Application Control events](/windows/security/threat-protection/windows-defender-application-control/event-id-explanations#windows-applocker-msi-and-script-log).
> [!NOTE]
> When a script runs that is not allowed by policy, WDAC raises an event indicating that the script was "blocked." However, the actual script enforcement behavior is handled by the script host and may not actually completely block the file from running.
>
> Also be aware that some script hosts may change how they behave even if a WDAC policy is in audit mode only. You should review the information below for each script host and test thoroughly within your environment to ensure the scripts you need to run are working properly.
> Also be aware that some script hosts may change how they behave even if a WDAC policy is in audit mode only. You should review the script host specific information in this article and test thoroughly within your environment to ensure the scripts you need to run are working properly.
## Enlightened script hosts that are part of Windows
### PowerShell
All PowerShell scripts (.ps1), modules (.psm1), and manifests (.psd1) must be allowed by WDAC policy in order to run with Full Language rights.
Your WDAC policies must allow all PowerShell scripts (.ps1), modules (.psm1), and manifests (.psd1) for them to run with Full Language rights.
Any **dependent modules** that are loaded by an allowed module must also be allowed by WDAC policy, and module functions must be exported explicitly by name when WDAC is enforced. Modules that don't specify any exported functions (no export name list) will still load but no module functions will be accessible. Modules that use wildcards (\*) in their name will fail to load.
Your WDAC policies must also allow any **dependent modules** that are loaded by an allowed module, and module functions must be exported explicitly by name when WDAC is enforced. Modules that don't specify any exported functions (no export name list) still load but no module functions are accessible. Modules that use wildcards (\*) in their name will fail to load.
Any PowerShell script that isn't allowed by WDAC policy will still run, but only in Constrained Language Mode.
Any PowerShell script that isn't allowed by WDAC policy still runs, but only in Constrained Language Mode.
PowerShell **dot-sourcing** isn't recommended. Instead, scripts should use PowerShell modules to provide common functionality. If a script file that is allowed by WDAC does try to run dot-sourced script files, those script files must also be allowed by the policy.
PowerShell **dot-sourcing** isn't recommended. Instead, scripts should use PowerShell modules to provide common functionality. If an allowed script file does try to run dot-sourced script files, those script files must also pass the policy.
WDAC will put **interactive PowerShell** into Constrained Language Mode if any WDAC UMCI policy is enforced and *any* active WDAC policy enables script enforcement, even if that policy is in audit mode. To run interactive PowerShell with Full Language rights, you must disable script enforcement for *all* policies.
WDAC puts **interactive PowerShell** into Constrained Language Mode if any WDAC UMCI policy is enforced and *any* active WDAC policy enables script enforcement, even if that policy is in audit mode. To run interactive PowerShell with Full Language rights, you must disable script enforcement for *all* policies.
For more information on PowerShell language modes, see [About Language Modes](/powershell/module/microsoft.powershell.core/about/about_language_modes).
For more information, see [About Language Modes](/powershell/module/microsoft.powershell.core/about/about_language_modes) and [Constrained Language Mode](https://devblogs.microsoft.com/powershell/powershell-constrained-language-mode/).
### VBscript, cscript, and jscript
All scripts run using the Windows Based Script Host (wscript.exe) or the Microsoft Console Based Script Host (cscript.exe) must be allowed by the WDAC policy. If not, the script will be blocked.
Your WDAC policies must allow all scripts run using the Windows Based Script Host (wscript.exe) or the Microsoft Console Based Script Host (cscript.exe). If not, the script is blocked.
### Microsoft HTML Application Host (MSHTA) and MSXML
If any WDAC policy is active that enables script enforcement, even if that policy is in audit mode, all code execution using MSHTA or MSXML will be blocked.
All code execution using MSHTA or MSXML is blocked if any WDAC policy with script enforcement is active, even if that policy is in audit mode.
### COM objects
WDAC additionally enforces a restricted allowlist for COM objects that can be expanded or further restricted by your WDAC policy. COM object enforcement **isn't** affected by option **11 Disabled:Script Enforcement**. For more information on how to allow or deny COM objects, see [Allow COM object registration](/windows/security/threat-protection/windows-defender-application-control/allow-com-object-registration-in-windows-defender-application-control-policy).
WDAC additionally enforces a restricted allowlist for COM objects that your WDAC policy can expand or further restrict. COM object enforcement **isn't** affected by option **11 Disabled:Script Enforcement**. For more information on how to allow or deny COM objects, see [Allow COM object registration](/windows/security/threat-protection/windows-defender-application-control/allow-com-object-registration-in-windows-defender-application-control-policy).
## Scripts that aren't directly controlled by WDAC
WDAC doesn't directly control code run via the Windows Command Processor (cmd.exe), including .bat/.cmd script files. However, anything that such a batch script tries to run will be subject to WDAC control. If you don't need to run cmd.exe, it's recommended to block it outright or allow it only by exception based on the calling process. See [Use a Windows Defender Application Control policy to control specific plug-ins, add-ins, and modules](/windows/security/threat-protection/windows-defender-application-control/use-windows-defender-application-control-policy-to-control-specific-plug-ins-add-ins-and-modules).
WDAC doesn't directly control code run via the Windows Command Processor (cmd.exe), including .bat/.cmd script files. However, anything that such a batch script tries to run is subject to WDAC control. If you don't need to run cmd.exe, it's recommended to block it outright or allow it only by exception based on the calling process. See [Use a Windows Defender Application Control policy to control specific plug-ins, add-ins, and modules](/windows/security/threat-protection/windows-defender-application-control/use-windows-defender-application-control-policy-to-control-specific-plug-ins-add-ins-and-modules).
WDAC doesn't control scripts run through an unenlightened script host, such as many 3rd-party Java or Python engines. If your WDAC policy allows an unenlightened script host to run, then you implicitly allow all scripts run through that host. For non-Microsoft script hosts, you should check with the software vendor whether their script hosts are enlightened to WDAC policy.

6
windows/security/threat-protection/windows-defender-application-control/index.yml
View File

@ -8,7 +8,7 @@ metadata:
author: vinaypamnani-msft
ms.author: vinpa
manager: aaroncz
ms.date: 12/07/2022
ms.date: 04/05/2023
# linkListType: overview | how-to-guide | tutorial | video
landingContent:
# Cards and links should be based on top customer tasks or top subjects
@ -108,10 +108,12 @@ landingContent:
- text: Deployment with group policy
url: deployment/deploy-windows-defender-application-control-policies-using-group-policy.md
# Card
- title: Learn how to monitor WDAC events
- title: Learn how to troubleshoot and debug WDAC events
linkLists:
- linkListType: overview
links:
- text: Debugging and troubleshooting
url: operations/wdac-debugging-and-troubleshooting.md
- text: Understanding event IDs
url: event-id-explanations.md
- text: Understanding event Tags

108
windows/security/threat-protection/windows-defender-application-control/operations/citool-commands.md
View File

@ -5,7 +5,7 @@ author: valemieux
ms.author: jogeurte
ms.reviewer: jsuther1974
ms.topic: how-to
ms.date: 12/03/2022
ms.date: 04/05/2023
ms.custom: template-how-to
ms.prod: windows-client
ms.technology: itpro-security
@ -44,66 +44,66 @@ CiTool makes Windows Defender Application Control (WDAC) policy management easie
## Examples
1. Deploy a WDAC policy
### Deploy a WDAC policy
```powershell
CiTool --update-policy "\Windows\Temp\{BF61FE40-8929-4FDF-9EC2-F7A767717F0B}.cip"
```
```powershell
CiTool --update-policy "\Windows\Temp\{BF61FE40-8929-4FDF-9EC2-F7A767717F0B}.cip"
```
2. Refresh the WDAC policies on the system
### Refresh the WDAC policies on the system
```powershell
CiTool --refresh
```
```powershell
CiTool --refresh
```
3. Remove a specific WDAC policy by its policy ID
### Remove a specific WDAC policy by its policy ID
```powershell
CiTool --remove-policy "{BF61FE40-8929-4FDF-9EC2-F7A767717F0B}"
```
```powershell
CiTool --remove-policy "{BF61FE40-8929-4FDF-9EC2-F7A767717F0B}"
```
4. List the actively enforced WDAC policies on the system
### List the actively enforced WDAC policies on the system
```powershell
# Check each policy's IsEnforced state and return only the enforced policies
(CiTool -lp -json | ConvertFrom-Json).Policies | Where-Object {$_.IsEnforced -eq "True"} |
Select-Object -Property PolicyID,FriendlyName | Format-List
```
```powershell
# Check each policy's IsEnforced state and return only the enforced policies
(CiTool -lp -json | ConvertFrom-Json).Policies | Where-Object {$_.IsEnforced -eq "True"} |
Select-Object -Property PolicyID,FriendlyName | Format-List
```
5. Display the help menu
### Display the help menu
```powershell
CiTool -h
```powershell
CiTool -h
----------------------------- Policy Commands ---------------------------------
--update-policy /Path/To/Policy/File
Add or update a policy on the current system
aliases: -up
--remove-policy PolicyGUID
Remove a policy indicated by PolicyGUID from the system
aliases: -rp
--list-policies
Dump information about all policies on the system, whether they be active or not
aliases: -lp
----------------------------- Token Commands ---------------------------------
--add-token Path/To/Token/File <--token-id ID>
Deploy a token onto the current system, with an optional specific ID
If <ID> is specified, a pre-existing token with <ID> should not exist.
aliases:-at
--remove-token ID
Remove a Token indicated by ID from the system.
aliases: -rt
--list-tokens
Dump information about all tokens on the system
aliases: -lt
----------------------------- Misc Commands ---------------------------------
--device-id
Dump the Code Integrity Device Id
aliases: -id
--refresh
Attempt to Refresh CI Policies
aliases: -r
--help
Display this message
aliases: -h
```
----------------------------- Policy Commands ---------------------------------
--update-policy /Path/To/Policy/File
Add or update a policy on the current system
aliases: -up
--remove-policy PolicyGUID
Remove a policy indicated by PolicyGUID from the system
aliases: -rp
--list-policies
Dump information about all policies on the system, whether they be active or not
aliases: -lp
----------------------------- Token Commands ---------------------------------
--add-token Path/To/Token/File <--token-id ID>
Deploy a token onto the current system, with an optional specific ID
If <ID> is specified, a pre-existing token with <ID> should not exist.
aliases:-at
--remove-token ID
Remove a Token indicated by ID from the system.
aliases: -rt
--list-tokens
Dump information about all tokens on the system
aliases: -lt
----------------------------- Misc Commands ---------------------------------
--device-id
Dump the Code Integrity Device Id
aliases: -id
--refresh
Attempt to Refresh CI Policies
aliases: -r
--help
Display this message
aliases: -h
```

34
windows/security/threat-protection/windows-defender-application-control/operations/known-issues.md
View File

@ -21,7 +21,7 @@ ms.localizationpriority: medium
- Windows 10
- Windows 11
- Windows Server 2016 and above
- Windows Server 2016 and later
> [!NOTE]
> Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
@ -37,7 +37,7 @@ This article covers tips and tricks for admins and known issues with Windows Def
The *\{PolicyId GUID\}* value is unique by policy and defined in the policy XML with the &lt;PolicyId&gt; element.
For **single policy format WDAC policies**, in addition to the two locations above, also look for a file called SiPolicy.p7b that may be found in the following locations:
For **single policy format WDAC policies**, in addition to the two preceding locations, also look for a file called SiPolicy.p7b that may be found in the following locations:
- &lt;EFI System Partition&gt;\\Microsoft\\Boot\\SiPolicy.p7b
- &lt;OS Volume&gt;\\Windows\\System32\\CodeIntegrity\\SiPolicy.p7b
@ -45,20 +45,42 @@ For **single policy format WDAC policies**, in addition to the two locations abo
> [!NOTE]
> A multiple policy format WDAC policy using the single policy format GUID `{A244370E-44C9-4C06-B551-F6016E563076}` may exist under any of the policy file locations.
## File Rule Precedence Order
When the WDAC engine evaluates files against the active set of policies on the device, rules are applied in the following order. Once a file encounters a match, WDAC stops further processing.
1. Explicit deny rules - if any explicit deny rule exists for the file, it's blocked even if other rules are created to try to allow it. Deny rules can use any [rule level](/windows/security/threat-protection/windows-defender-application-control/select-types-of-rules-to-create#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 - if any explicit allow rul exists for the file, it's allowed by the policy.
3. WDAC then checks for the [Managed Installer extended attribute (EA)](/windows/security/threat-protection/windows-defender-application-control/configure-authorized-apps-deployed-with-a-managed-installer) or the [Intelligent Security Graph (ISG) EA](/windows/security/threat-protection/windows-defender-application-control/use-windows-defender-application-control-with-intelligent-security-graph) on the file. If either EA exists and the policy enables the corresponding option, then the file is allowed.
4. Lastly, WDAC makes a cloud call to the ISG to get reputation about the file, if the policy enables the ISG option.
5. If no rule exists for the file and it's not allowed based on ISG or MI, then the file is blocked implicitly.
## Known issues
### Boot stop failure (blue screen) occurs if more than 32 policies are active
If the maximum number of policies is exceeded, the device may bluescreen referencing ci.dll with a bug check value of 0x0000003b. Consider this maximum policy count limit when planning your WDAC policies. Any [Windows inbox policies](/windows/security/threat-protection/windows-defender-application-control/operations/inbox-wdac-policies) that are active on the device also count towards this limit.
### Managed Installer and ISG may cause excessive events
When Managed Installer and ISG are enabled, 3091 and 3092 events will be logged when a file didn't have Managed Installer or ISG authorization, regardless of whether the file was allowed. These events have been moved to the verbose channel beginning with the September 2022 Update Preview since the events don't indicate an issue with the policy.
When Managed Installer and ISG are enabled, 3091 and 3092 events are logged when a file didn't have Managed Installer or ISG authorization, regardless of whether the file was allowed. These events have been moved to the verbose channel beginning with the September 2022 Update Preview since the events don't indicate an issue with the policy.
### .NET native images may generate false positive block events
In some cases, the code integrity logs where Windows Defender Application Control errors and warnings are written will contain error events for native images generated for .NET assemblies. Typically, native image blocks are functionally benign as a blocked native image will fall back to its corresponding assembly and .NET will regenerate the native image at its next scheduled maintenance window.
In some cases, the code integrity logs where Windows Defender Application Control errors and warnings are written include error events for native images generated for .NET assemblies. Typically, native image blocks are functionally benign as a blocked native image falls back to its corresponding assembly and .NET will regenerate the native image at its next scheduled maintenance window.
### MSI installers are treated as user writeable on Windows 10 when allowed by FilePath rule
MSI installer files are always detected as user writeable on Windows 10, and on Windows Server 2022 and earlier. If you need to allow MSI files using FilePath rules, you must set option **18 Disabled:Runtime FilePath Rule Protection** in your WDAC policy.
### MSI Installations launched directly from the internet are blocked by WDAC
Installing .msi files directly from the internet to a computer protected by WDAC will fail.
For example, this command won't work:
Installing .msi files directly from the internet to a computer protected by WDAC fails.
For example, this command fails:
```console
msiexec –i https://download.microsoft.com/download/2/E/3/2E3A1E42-8F50-4396-9E7E-76209EA4F429/Windows10_Version_1511_ADMX.msi

15
windows/security/threat-protection/windows-defender-application-control/operations/wdac-debugging-and-troubleshooting.md
View File

@ -5,7 +5,7 @@ author: valemieux
ms.author: jogeurte
ms.reviewer: jsuther1974
ms.topic: how-to
ms.date: 03/23/2023
ms.date: 04/06/2023
ms.custom: template-how-to
ms.prod: windows-client
ms.technology: itpro-security
@ -255,3 +255,16 @@ To debug issues using ISG, try these steps:
- Check that the AppLocker services are running. This information is found in $env:USERPROFILE\AppData\Local\Temp\DiagOutputDir\CiDiag\AppLockerServices.txt created in section 1 of this article.
- [Use fsutil.exe](/windows/security/threat-protection/windows-defender-application-control/configure-wdac-managed-installer#using-fsutil-to-query-extended-attributes-for-intelligent-security-graph-isg) to verify files have the ISG origin extended attribute. If not, redeploy the files with the managed installer and check again.
- Check if the app is encountering a [known limitation with ISG](/windows/security/threat-protection/windows-defender-application-control/use-windows-defender-application-control-with-intelligent-security-graph#known-limitations-with-using-the-isg).
## 4 - Report issues to Microsoft, if appropriate
If after following the guidance covered by this article you believe you've identified a product issue, report the issue to Microsoft.
- Customers with Microsoft Premier Support should log a service request through normal channels.
- All other customers can report issues directly to the WDAC product team via the Windows [Feedback Hub](feedback-hub:?contextid=790&tabid=2&newFeedback=true). Select the category **Security & Privacy - Application Control** to ensure the issue is properly routed to the WDAC product team.
When reporting issues, be sure to provide the following information:
- All [WDAC diagnostic data](#1---gather-wdac-diagnostic-data) described earlier.
- If possible, the blocked file(s).
- Clear instructions to reproduce the problem.

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

@ -13,7 +13,7 @@ author: jgeurten
ms.reviewer: jsuther1974
ms.author: vinpa
manager: aaroncz
ms.date: 03/03/2023
ms.date: 04/05/2023
ms.technology: itpro-security
ms.topic: article
---
@ -24,30 +24,18 @@ ms.topic: article
- Windows 10
- Windows 11
- Windows Server 2016 and above
- Windows Server 2016 and later
> [!NOTE]
> Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [WDAC feature availability](feature-availability.md).
Windows Defender Application Control (WDAC) can control what runs on Windows 10 and Windows 11, by setting policies that specify whether a driver or application is trusted. A policy includes *policy rules* that control options such as audit mode, and *file rules* (or *file rule levels*) that specify how applications are identified and trusted.
WDAC is used to restrict devices to run only approved apps, while the operating system is hardened against kernel memory attacks using [hypervisor-protected code integrity (HVCI)](/windows/security/threat-protection/device-guard/introduction-to-device-guard-virtualization-based-security-and-windows-defender-application-control).
Windows Defender Application Control (WDAC) can control what runs on Windows 10, Windows 11, and Windows Server 2016 and later, by setting policies that specify whether a driver or application is trusted. A policy includes *policy rules* that control options such as audit mode, and *file rules* (or *file rule levels*) that specify how applications are identified and trusted.
## Windows Defender Application Control policy rules
To modify the policy rule options of an existing WDAC policy XML, use [Set-RuleOption](/powershell/module/configci/set-ruleoption). The following examples show how to use this cmdlet to add and remove a rule option on an existing WDAC policy:
To modify the policy rule options of an existing WDAC policy XML, use the [WDAC Policy Wizard](/windows/security/threat-protection/windows-defender-application-control/wdac-wizard) or the [Set-RuleOption](/powershell/module/configci/set-ruleoption) PowerShell cmdlet.
- To ensure that UMCI is enabled for a WDAC policy that was created with the `-UserPEs` (user mode) option, add rule option 0 to an existing policy, by running the following command:
`Set-RuleOption -FilePath <Path to policy XML> -Option 0`
A policy created without the `-UserPEs` option has no rules for user mode code. If you enable UMCI (Option 0) for such a policy, all applications, including critical Windows user session code, are blocked. In audit mode, WDAC simply logs an event, but when enforced, all user mode code is blocked. To create a policy that includes user mode executables (applications), run `New-CIPolicy` with the `-UserPEs` option.
- To disable UMCI on an existing WDAC policy, delete rule option 0 by running the following command:
`Set-RuleOption -FilePath <Path to policy XML> -Option 0 -Delete`
You can set several rule options within a WDAC policy. Table 1 describes each rule option, and whether they have supplemental policies. However, option 5 isn't implemented as it's reserved for future work, and option 7 isn't supported.
You can set several rule options within a WDAC policy. Table 1 describes each rule option, and whether supplemental policies can set them. Some rule options are reserved for future work or not supported.
> [!NOTE]
> We recommend that you use **Enabled:Audit Mode** initially because it allows you to test new WDAC policies before you enforce them. With audit mode, no application is blocked—instead the policy logs an event whenever an application outside the policy is started. To allow these applications, you can capture the policy information from the event log, and then merge that information into the existing policy. When the **Enabled:Audit Mode** is deleted, the policy runs in enforced mode.
@ -58,11 +46,11 @@ You can set several rule options within a WDAC policy. Table 1 describes each ru
|------------ | ----------- | ----------- |
| **0 Enabled:UMCI** | WDAC policies restrict both kernel-mode and user-mode binaries. By default, only kernel-mode binaries are restricted. Enabling this rule option validates user mode executables and scripts. | No |
| **1 Enabled:Boot Menu Protection** | This option isn't currently supported. | No |
| **2 Required:WHQL** | By default, legacy drivers that aren't Windows Hardware Quality Labs (WHQL) signed are allowed to execute. Enabling this rule requires that every executed driver is WHQL signed and removes legacy driver support. Kernel drivers built for Windows 10 should be WHQL certified. | No |
| **2 Required:WHQL** | By default, kernel drivers that aren't Windows Hardware Quality Labs (WHQL) signed are allowed to run. Enabling this rule requires that every driver is WHQL signed and removes legacy driver support. Kernel drivers built for Windows 10 should be WHQL certified. | No |
| **3 Enabled:Audit Mode (Default)** | Instructs WDAC to log information about applications, binaries, and scripts that would have been blocked, if the policy was enforced. You can use this option to identify the potential impact of your WDAC policy, and use the audit events to refine the policy before enforcement. To enforce a WDAC policy, delete this option. | No |
| **4 Disabled:Flight Signing** | If enabled, flightroot-signed binaries aren't trusted. This option is useful for organizations that only want to run released binaries, not pre-release Windows builds. | No |
| **4 Disabled:Flight Signing** | If enabled, binaries from Windows Insider builds aren't trusted. This option is useful for organizations that only want to run released binaries, not pre-release Windows builds. | No |
| **5 Enabled:Inherit Default Policy** | This option is reserved for future use and currently has no effect. | Yes |
| **6 Enabled:Unsigned System Integrity Policy (Default)** | Allows the policy to remain unsigned. When this option is removed, the policy must be signed. The certificates that are trusted for future policy updates must be identified in the UpdatePolicySigners section. | Yes |
| **6 Enabled:Unsigned System Integrity Policy (Default)** | Allows the policy to remain unsigned. When this option is removed, the policy must be signed and any supplemental policies must also be signed. The certificates that are trusted for future policy updates must be identified in the UpdatePolicySigners section. Certificates that are trusted for supplemental policies must be identified in the SupplementalPolicySigners section. | Yes |
| **7 Allowed:Debug Policy Augmented** | This option isn't currently supported. | Yes |
| **8 Required:EV Signers** | This option isn't currently supported. | No |
| **9 Enabled:Advanced Boot Options Menu** | The F8 preboot menu is disabled by default for all WDAC policies. Setting this rule option allows the F8 menu to appear to physically present users. | No |
@ -72,15 +60,15 @@ You can set several rule options within a WDAC policy. Table 1 describes each ru
| **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) | Yes |
| **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). | Yes |
| **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 causes WDAC to periodically revalidate the reputation for files previously authorized by the ISG.| No |
| **16 Enabled:Update Policy No Reboot** | Use this option to allow future WDAC policy updates to apply without requiring a system reboot.<br/> NOTE: This option is only supported on Windows 10, version 1709 and above.| No |
| **17 Enabled:Allow Supplemental Policies** | Use this option on a base policy to allow supplemental policies to expand it.<br/> NOTE: This option is only supported on Windows 10, version 1903 and above. | No |
| **18 Disabled:Runtime FilePath Rule Protection** | This option disables the default runtime check that only allows FilePath rules for paths that are only writable by an administrator.<br/> NOTE: This option is only supported on Windows 10, version 1903 and above. | Yes |
| **19 Enabled:Dynamic Code Security** | Enables policy enforcement for .NET applications and dynamically loaded libraries.<br/> NOTE: This option is only supported on Windows 10, version 1803 and above. | No |
| **20 Enabled:Revoked Expired As Unsigned** | Use this option to treat binaries signed with expired and/or revoked certificates as "Unsigned binaries" for user-mode process/components, under enterprise signing scenarios. | No |
| **16 Enabled:Update Policy No Reboot** | Use this option to allow future WDAC policy updates to apply without requiring a system reboot.<br/> NOTE: This option is only supported on Windows 10, version 1709 and later, or Windows Server 2019 and later.| No |
| **17 Enabled:Allow Supplemental Policies** | Use this option on a base policy to allow supplemental policies to expand it.<br/> NOTE: This option is only supported on Windows 10, version 1903 and later, or Windows Server 2022 and later. | No |
| **18 Disabled:Runtime FilePath Rule Protection** | This option disables the default runtime check that only allows FilePath rules for paths that are only writable by an administrator.<br/> NOTE: This option is only supported on Windows 10, version 1903 and later, or Windows Server 2022 and later. | Yes |
| **19 Enabled:Dynamic Code Security** | Enables policy enforcement for .NET applications and dynamically loaded libraries.<br/> NOTE: This option is only supported on Windows 10, version 1803 and later, or Windows Server 2019 and later. | No |
| **20 Enabled:Revoked Expired As Unsigned** | Use this option to treat binaries signed with revoked certificates, or expired certificates with the Lifetime Signing EKU on the signature, as "Unsigned binaries" for user-mode process/components, under enterprise signing scenarios. | No |
## Windows Defender Application Control file rule levels
File rule levels allow administrators to specify the level at which they want to trust their applications. This level of trust could be as granular as the hash of each binary, or as general as a CA certificate. You specify file rule levels when using WDAC PowerShell cmdlets to create and modify policies.
File rule levels allow administrators to specify the level at which they want to trust their applications. This level of trust could be as granular as the hash of each binary, or as general as a CA certificate. You specify file rule levels when using the WDAC Wizard or WDAC PowerShell cmdlets to create and modify policies.
Each file rule level has advantages and disadvantages. Use Table 2 to select the appropriate protection level for your available administrative resources and WDAC deployment scenario.
@ -129,7 +117,7 @@ As part of normal operations, they'll eventually install software updates, or pe
WDAC has a built-in file rule conflict logic that translates to precedence order. It first processes all explicit deny rules it finds. Then, it processes any explicit allow rules. If no deny or allow rule exists, WDAC checks for a [Managed Installer claim](deployment/deploy-wdac-policies-with-memcm.md) if allowed by the policy. Lastly, WDAC falls back to the [ISG](use-windows-defender-application-control-with-intelligent-security-graph.md) if allowed by the policy.
> [!NOTE]
> To make it easier to reason over your WDAC policies, we recommend maintaining separate ALLOW and DENY policies on Windows 10, version 1903 and later.
> To make it easier to reason over your WDAC policies, we recommend maintaining separate ALLOW and DENY policies on Windows versions that support [multiple WDAC policies](/windows/security/threat-protection/windows-defender-application-control/deploy-multiple-windows-defender-application-control-policies).
## More information about filepath rules
@ -176,9 +164,6 @@ Without a wildcard, the filepath rule allows only a specific file (ex. `C:\foo\b
> [!NOTE]
> When authoring WDAC policies with Configuration Manager, there is an option to create rules for specified files and folders. These rules **aren't** WDAC filepath rules. Rather, Configuration Manager performs a one-time scan of the specified files and folders and builds rules for any binaries found in those locations at the time of that scan. File changes to those specified files and folders after that scan won't be allowed unless the Configuration Manager policy is reapplied.
> [!NOTE]
> There is currently a bug where MSIs cannot be allow listed in file path rules. MSIs must be allow listed using other rule types, for example, publisher rules or file attribute rules.
## More information about hashes
WDAC uses the [Authenticode/PE image hash algorithm](https://download.microsoft.com/download/9/c/5/9c5b2167-8017-4bae-9fde-d599bac8184a/Authenticode_PE.docx) when calculating the hash of a file. Unlike the more commonly known [flat file hash](/powershell/module/microsoft.powershell.utility/get-filehash), the Authenticode hash calculation omits the file's checksum, the Certificate Table, and the Attribute Certificate Table. Therefore, the Authenticode hash of a file doesn't change when the file's signatures and timestamps are altered, or when a digital signature is removed from the file. With the help of the Authenticode hash, WDAC provides added security and less management overhead so customers don't need to revise the policy hash rules when the digital signature on the file is updated.

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

@ -10,10 +10,10 @@ ms.pagetype: security
ms.localizationpriority: medium
audience: ITPro
author: jsuther1974
ms.reviewer: isbrahm
ms.reviewer: jogeurte
ms.author: vinpa
manager: aaroncz
ms.date: 03/01/2018
ms.date: 04/05/2023
ms.technology: itpro-security
ms.topic: article
---
@ -33,12 +33,12 @@ Typically, deployment of Windows Defender Application Control (WDAC) happens bes
## Types of devices
| **Type of device** | **How WDAC relates to this type of device** |
| Type of device | How WDAC relates to this type of device |
|------------------------------------|------------------------------------------------------|
| **Lightly managed devices**: Company-owned, but users are free to install software.<br>Devices are required to run organization's antivirus solution and client management tools. | Windows Defender Application Control can be used to help protect the kernel, and to monitor (audit) for problem applications rather than limiting the applications that can be run. |
| **Fully managed devices**: Allowed software is restricted by IT department.<br>Users can request for more software, or install from a list of applications provided by IT department.<br>Examples: locked-down, company-owned desktops and laptops. | An initial baseline Windows Defender Application Control policy can be established and enforced. Whenever the IT department approves more applications, it will update the WDAC policy and (for unsigned LOB applications) the catalog.<br>WDAC policies are supported by the HVCI service. |
| **Fixed-workload devices**: Perform same tasks every day.<br>Lists of approved applications rarely change.<br>Examples: kiosks, point-of-sale systems, call center computers. | Windows Defender Application Control can be deployed fully, and deployment and ongoing administration are relatively straightforward.<br>After Windows Defender Application Control deployment, only approved applications can run. This rule is because of protections offered by WDAC. |
| **Bring Your Own Device**: Employees are allowed to bring their own devices, and also use those devices away from work. | In most cases, Windows Defender Application Control doesn't apply. Instead, you can explore other hardening and security features with MDM-based conditional access solutions, such as Microsoft Intune. However, you may choose to deploy an audit-mode policy to these devices or employ a blocklist only policy to prevent specific apps or binaries that are considered malicious or vulnerable by your organization. |
| **Lightly managed devices**: Company-owned, but users are free to install software.<br>Devices are required to run organization's antivirus solution and client management tools. | Windows Defender Application Control can be used to help protect the kernel, and to monitor (audit) for problem applications rather than limiting the applications that can be run. |
| **Fully managed devices**: Allowed software is restricted by IT department.<br>Users can request for more software, or install from a list of applications provided by IT department.<br>Examples: locked-down, company-owned desktops and laptops. | An initial baseline Windows Defender Application Control policy can be established and enforced. Whenever the IT department approves more applications, it updates the WDAC policy and (for unsigned LOB applications) the catalog. |
| **Fixed-workload devices**: Perform same tasks every day.<br>Lists of approved applications rarely change.<br>Examples: kiosks, point-of-sale systems, call center computers. | Windows Defender Application Control can be deployed fully, and deployment and ongoing administration are relatively straightforward.<br>After Windows Defender Application Control deployment, only approved applications can run. This rule is because of protections offered by WDAC. |
| **Bring Your Own Device**: Employees are allowed to bring their own devices, and also use those devices away from work. | In most cases, Windows Defender Application Control doesn't apply. Instead, you can explore other hardening and security features with MDM-based conditional access solutions, such as Microsoft Intune. However, you may choose to deploy an audit-mode policy to these devices or employ a blocklist only policy to prevent specific apps or binaries that are considered malicious or vulnerable by your organization. |
## An introduction to Lamna Healthcare Company

28
windows/security/threat-protection/windows-defender-application-control/understanding-wdac-policy-settings.md
View File

@ -7,15 +7,17 @@ author: jgeurten
ms.reviewer: vinpa
ms.author: jogeurte
manager: aaroncz
ms.date: 10/11/2021
ms.date: 04/05/2023
ms.technology: itpro-security
ms.topic: article
---
# Understanding WDAC Policy Settings
Windows Defender Application Control (WDAC) Policies expose a Settings section where policy authors can define arbitrary secure settings. Secure Settings provide local admin tamper-free settings for secure boot enabled systems, with policy signing enabled. Settings consist of a Provider, Key, and ValueName, as well as a setting value. Setting values can be of type boolean, ulong, binary, and string. Applications can query for policy settings using WldpQuerySecurityPolicy. <br/>
An example settings section of a Windows Defender Application Control Policy:
Windows Defender Application Control (WDAC) policies expose a Settings section where policy authors can define arbitrary secure settings. Secure Settings provide local admin tamper-free settings for secure boot enabled systems, with policy signing enabled. Settings consist of a Provider, Key, ValueName, and a setting value. Setting values can be of type boolean, ulong, binary, and string. Applications can query for policy settings using WldpQuerySecurityPolicy.
An example settings section of a Windows Defender Application Control policy:
```xml
<Settings>
<Setting Provider="Contoso" Key="FooApplication" ValueName="DisableMacroExecution">
@ -26,14 +28,16 @@ An example settings section of a Windows Defender Application Control Policy:
</Settings>
```
### Example Scenario
An application that may want to restrict its capabilities, when used on a system with an active Windows Defender Application Control policy. Application authors can define a WDAC policy, setting their application queries, in order to disable certain features. For example, if Contoso’s Foo Application wants to disable a risky feature, such as macro execution, they can define a WDAC policy setting, and query for it at runtime. Contoso can then instruct IT administrators to configure the setting in their WDAC policy, if they don’t want Foo Application to execute macros on a system with a WDAC policy.<br/>
## Example Scenario
An application that may want to restrict its capabilities, when used on a system with an active Windows Defender Application Control policy. Application authors can define a WDAC policy, setting their application queries, in order to disable certain features. For example, if Contoso’s Foo Application wants to disable a risky feature, such as macro execution, they can define a WDAC policy setting, and query for it at runtime. Contoso can then instruct IT administrators to configure the setting in their WDAC policy, if they don’t want Foo Application to execute macros on a system with a WDAC policy.
## WldpQuerySecurityPolicy
### WldpQuerySecurityPolicy
API that queries the secure settings of a Windows Defender Application Control policy.
### Syntax
``` C++
HRESULT WINAPI WldpQuerySecurityPolicy(
_In_ const UNICODE_STRING * Provider,
@ -45,26 +49,30 @@ HRESULT WINAPI WldpQuerySecurityPolicy(
```
### Parameters
Provider [in]
Setting Provider name.
#### Key [in]
Key name of the Key-Value pair under Setting Provider "Provider".
#### ValueName [in]
The value name of the "Key-Value" pair.
#### ValueType [in, out]
Pointer to receive the value type.
#### Value [in, out]
Pointer to a buffer to receive the value. The buffer should be of size “ValueSize”. If this value is NULL, this function will return the required buffer size for Value.
Pointer to a buffer to receive the value. The buffer should be of size “ValueSize”. If this value is NULL, this function returns the required buffer size for Value.
#### ValueSize [in, out]
On input, it indicates the buffer size of "Value". On successful return, it indicates the size of data written to Value buffer.
#### Return Value
This method returns S_OK if successful or a failure code otherwise.
#### Remarks
See [WDAC Policy Settings] for more information on WDAC policy settings.
This method returns S_OK if successful or a failure code otherwise.

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

@ -45,13 +45,12 @@ Windows Defender Application Control policies apply to the managed computer as a
- The [path from which the app or file is launched](select-types-of-rules-to-create.md#more-information-about-filepath-rules) (beginning with Windows 10 version 1903)
- The process that launched the app or binary
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."
> [!NOTE]
> WDAC was originally released as part of Device Guard and called configurable code integrity. Device Guard and configurable code integrity are no longer used except to find where to deploy WDAC policy via Group Policy.
### WDAC System Requirements
Windows Defender Application Control (WDAC) policies can be created on any client edition of Windows 10 build 1903+, or Windows 11, or on Windows Server 2016 and above.
WDAC policies can be applied to devices running any edition of Windows 10, Windows 11, or Windows Server 2016 and above, via a Mobile Device Management (MDM) solution, for example, Intune; a management interface such as Configuration Manager; or a script host such as PowerShell. Group Policy can also be used to deploy WDAC policies, but is limited to single-policy format policies that work on Windows Server 2016 and 2019.
Windows Defender Application Control (WDAC) policies can be created and applied on any client edition of Windows 10 or Windows 11, or on Windows Server 2016 and higher. WDAC policies can be deployed 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, but is limited to single-policy format policies that work on Windows Server 2016 and 2019.
For more information on which individual WDAC features are available on specific WDAC builds, see [WDAC feature availability](feature-availability.md).
@ -61,9 +60,9 @@ AppLocker was introduced with Windows 7, and allows organizations to control whi
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
- The path from which the app or file is launched
- 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 path from which the app or file is launched.
### AppLocker System Requirements
@ -72,7 +71,7 @@ AppLocker policies can be deployed using Group Policy or MDM.
## Choose when to use WDAC or AppLocker
Generally, it's recommended that customers, who are able to implement application control using Windows Defender Application Control rather than AppLocker, do so. WDAC is undergoing continual improvements, and will be getting added support from Microsoft management platforms. Although AppLocker will continue to receive security fixes, it will not undergo new feature improvements.
Generally, it's recommended that customers, who are able to implement application control using Windows Defender Application Control rather than AppLocker, do so. WDAC is undergoing continual improvements, and is getting added support from Microsoft management platforms. Although AppLocker continues to receive security fixes, it isn't getting new feature improvements.
However, in some cases, AppLocker may be the more appropriate technology for your organization. AppLocker is best when:

8
windows/security/threat-protection/windows-defender-application-control/windows-defender-application-control.md
View File

@ -13,10 +13,10 @@ ms.collection:
- highpri
- tier3
author: vinaypamnani-msft
ms.reviewer: isbrahm
ms.reviewer: jsuther
ms.author: vinpa
manager: aaroncz
ms.date: 05/26/2020
ms.date: 04/06/2023
ms.custom: asr
ms.technology: itpro-security
ms.topic: article
@ -53,7 +53,7 @@ Windows 10 and Windows 11 include two technologies that can be used for applicat
Starting in Windows 11 version 22H2, [Smart App Control](https://support.microsoft.com/topic/what-is-smart-app-control-285ea03d-fa88-4d56-882e-6698afdb7003) provides application control for consumers. Smart App Control is based on WDAC, allowing enterprise customers to create a policy that offers the same security and compatibility with the ability to customize it to run line-of-business (LOB) apps. To make it easier to implement this policy, an [example policy](example-wdac-base-policies.md) is provided. The example policy includes **Enabled:Conditional Windows Lockdown Policy** rule which isn't supported for WDAC enterprise policies. This rule must be removed before you use the example policy. To use this example policy as a starting point for creating your own policy, see [Create a custom base policy using an example WDAC base policy](create-wdac-policy-for-lightly-managed-devices.md#create-a-custom-base-policy-using-an-example-wdac-base-policy).
Smart App Control is only available on clean installation of Windows 11 version 22H2 or later, and starts in evaluation mode. Smart App Control will automatically turn off for enterprise managed devices unless the user has turned it on first. To turn Smart App Control on or off across your organization's endpoints, you can set the **VerifiedAndReputablePolicyState** (DWORD) registry value under `HKLM\SYSTEM\CurrentControlSet\Control\CI\Policy` to one of the values listed below. After you change the registry value, you must either restart the device or run [RefreshPolicy.exe](https://www.microsoft.com/download/details.aspx?id=102925) for the change to take effect.
Smart App Control is only available on clean installation of Windows 11 version 22H2 or later, and starts in evaluation mode. Smart App Control will automatically turn off for enterprise managed devices unless the user has turned it on first. To turn Smart App Control on or off across your organization's endpoints, you can set the **VerifiedAndReputablePolicyState** (DWORD) registry value under `HKLM\SYSTEM\CurrentControlSet\Control\CI\Policy` to one of the values listed below. After you change the registry value, you must either restart the device or use [CiTool.exe -r](/windows/security/threat-protection/windows-defender-application-control/operations/citool-commands#refresh-the-wdac-policies-on-the-system) for the change to take effect.
| Value | Description |
|-------|-------------|
@ -66,7 +66,7 @@ Smart App Control is only available on clean installation of Windows 11 version
### Smart App Control Enforced Blocks
Smart App Control enforces the [Microsoft Recommended Driver Block rules](microsoft-recommended-driver-block-rules.md) and the [Microsoft Recommended Block Rules](microsoft-recommended-block-rules.md), with a few exceptions for compatibility considerations. The following are not blocked by Smart App Control:
Smart App Control enforces the [Microsoft Recommended Driver Block rules](microsoft-recommended-driver-block-rules.md) and the [Microsoft Recommended Block Rules](microsoft-recommended-block-rules.md), with a few exceptions for compatibility considerations. The following are not blocked by Smart App Control:
- Infdefaultinstall.exe
- Microsoft.Build.dll