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

Update App Control for Business redirect links

Browse Source
This commit is contained in:
Vinay Pamnani (from Dev Box) 2024-09-11 13:08:45 -06:00
parent 9fbf7abbcd
commit ce67c73e1f
72 changed files with 1028 additions and 1068 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

13
windows/security/application-security/application-control/app-control-for-business/AppIdTagging/appcontrol-appid-tagging-guide.md
View File

@ -1,23 +1,22 @@
---
title: Designing, creating, managing, and troubleshooting Windows Defender Application Control AppId Tagging policies
description: How to design, create, manage, and troubleshoot your WDAC AppId Tagging policies
title: Designing, creating, managing, and troubleshooting App Control for Business AppId Tagging policies
description: How to design, create, manage, and troubleshoot your App Control AppId Tagging policies
ms.localizationpriority: medium
ms.date: 04/27/2022
ms.topic: conceptual
---
# WDAC Application ID (AppId) Tagging guide
# App Control Application ID (AppId) Tagging guide
> [!NOTE]
> Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](../feature-availability.md).
[!INCLUDE [Feature availability note](../includes/feature-availability-note.md)]
## AppId Tagging Feature Overview
The Application ID (AppId) Tagging Policy feature, while based off Windows Defender Application Control (WDAC), doesn't control whether applications run. AppId Tagging policies can be used to mark the processes of the running application with a customizable tag defined in the policy. Application processes that pass the AppId policy receive the tag while failing applications don't.
The Application ID (AppId) Tagging Policy feature, while based off App Control for Business, doesn't control whether applications run. AppId Tagging policies can be used to mark the processes of the running application with a customizable tag defined in the policy. Application processes that pass the AppId policy receive the tag while failing applications don't.
## AppId Tagging Feature Availability
The WDAC AppId Tagging feature is available on the following versions of the Windows platform:
The App Control AppId Tagging feature is available on the following versions of the Windows platform:
Client:
- Windows 10 20H1, 20H2, and 21H1 versions only

7
windows/security/application-security/application-control/app-control-for-business/AppIdTagging/debugging-operational-guide-appid-tagging-policies.md
View File

@ -8,14 +8,13 @@ ms.topic: troubleshooting
# Testing and Debugging AppId Tagging Policies
> [!NOTE]
> Some capabilities of Windows Defender Application Control (WDAC) are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](../feature-availability.md).
[!INCLUDE [Feature availability note](../includes/feature-availability-note.md)]
After deployment of the WDAC AppId Tagging policy, WDAC will log a 3099 policy deployed event in the [Event Viewer logs](../operations/event-id-explanations.md). You first should ensure that the policy has been successfully deployed onto the system by verifying the presence of the 3099 event.
After deployment of the App Control AppId Tagging policy, App Control will log a 3099 policy deployed event in the [Event Viewer logs](../operations/event-id-explanations.md). You first should ensure that the policy has been successfully deployed onto the system by verifying the presence of the 3099 event.
## Verifying Tags on Running Processes
After verifying the policy has been deployed, the next step is to verify that the application processes you expect to pass the AppId Tagging policy have your tag set. Note that processes running at the time of policy deployment will need to be restarted since Windows Defender Application Control (WDAC) can only tag processes created after the policy has been deployed.
After verifying the policy has been deployed, the next step is to verify that the application processes you expect to pass the AppId Tagging policy have your tag set. Note that processes running at the time of policy deployment will need to be restarted since App Control for Business can only tag processes created after the policy has been deployed.
1. Download and Install the Windows Debugger

21
windows/security/application-security/application-control/app-control-for-business/AppIdTagging/deploy-appid-tagging-policies.md
View File

@ -1,17 +1,16 @@
---
title: Deploying Windows Defender Application Control AppId tagging policies
description: How to deploy your WDAC AppId tagging policies locally and globally within your managed environment.
title: Deploying App Control for Business AppId tagging policies
description: How to deploy your App Control AppId tagging policies locally and globally within your managed environment.
ms.localizationpriority: medium
ms.date: 04/29/2022
ms.topic: conceptual
---
# Deploying Windows Defender Application Control AppId tagging policies
# Deploying App Control for Business AppId tagging policies
> [!NOTE]
> Some capabilities of Windows Defender Application Control are only available on specific Windows versions. For more information, see [Windows Defender Application Control feature availability](../feature-availability.md).
[!INCLUDE [Feature availability note](../includes/feature-availability-note.md)]
Similar to Windows Defender Application Control (WDAC) policies, WDAC AppId tagging policies can be deployed locally and to your managed endpoints several ways. Once you've created your AppId tagging policy, use one of the following methods to deploy:
Similar to App Control for Business policies, App Control AppId tagging policies can be deployed locally and to your managed endpoints several ways. Once you've created your AppId tagging policy, use one of the following methods to deploy:
1. [Deploy AppId tagging policies with MDM](#deploy-appid-tagging-policies-with-mdm)
1. [Deploy policies with Configuration Manager](#deploy-appid-tagging-policies-with-configuration-manager)
@ -20,23 +19,23 @@ Similar to Windows Defender Application Control (WDAC) policies, WDAC AppId tagg
## Deploy AppId tagging policies with MDM
Custom AppId tagging policies can be deployed to endpoints using [the OMA-URI feature in MDM](../deployment/deploy-appcontrol-policies-using-intune.md#deploy-wdac-policies-with-custom-oma-uri).
Custom AppId tagging policies can be deployed to endpoints using [the OMA-URI feature in MDM](../deployment/deploy-appcontrol-policies-using-intune.md#deploy-app-control-policies-with-custom-oma-uri).
## Deploy AppId tagging policies with Configuration Manager
Custom AppId tagging policies can be deployed via Configuration Manager using the [deployment task sequences](../deployment/deploy-appcontrol-policies-with-memcm.md#deploy-custom-wdac-policies-using-packagesprograms-or-task-sequences), policies can be deployed to your managed endpoints and users.
Custom AppId tagging policies can be deployed via Configuration Manager using the [deployment task sequences](../deployment/deploy-appcontrol-policies-with-memcm.md#deploy-custom-app-control-policies-using-packagesprograms-or-task-sequences), policies can be deployed to your managed endpoints and users.
### Deploy AppId tagging Policies via Scripting
Scripting hosts can be used to deploy AppId tagging policies as well. This approach is often best suited for local deployment, but works for deployment to managed endpoints and users too. For more information on how to deploy WDAC AppId tagging policies via scripting, see [Deploy WDAC policies using script](../deployment/deploy-appcontrol-policies-with-script.md). For AppId tagging policies, the only applicable method is deploying to version 1903 or later.
Scripting hosts can be used to deploy AppId tagging policies as well. This approach is often best suited for local deployment, but works for deployment to managed endpoints and users too. For more information on how to deploy App Control AppId tagging policies via scripting, see [Deploy App Control policies using script](../deployment/deploy-appcontrol-policies-with-script.md). For AppId tagging policies, the only applicable method is deploying to version 1903 or later.
### Deploying policies via the ApplicationControl CSP
Multiple WDAC policies can be managed from an MDM server through ApplicationControl configuration service provider (CSP). The CSP also provides support for rebootless policy deployment.
Multiple App Control policies can be managed from an MDM server through ApplicationControl configuration service provider (CSP). The CSP also provides support for rebootless policy deployment.
However, when policies are unenrolled from an MDM server, the CSP will attempt to remove every policy from devices, not just the policies added by the CSP. The reason for this is that the ApplicationControl CSP doesn't track enrollment sources for individual policies, even though it will query all policies on a device, regardless if they were deployed by the CSP.
For more information, see [ApplicationControl CSP](/windows/client-management/mdm/applicationcontrol-csp) to deploy multiple policies, and optionally use Microsoft Intune's Custom OMA-URI capability.
> [!NOTE]
> WMI and GP don't currently support multiple policies. If you can't directly access the MDM stack, use the [ApplicationControl CSP via the MDM Bridge WMI Provider](/windows/client-management/mdm/applicationcontrol-csp#powershell-and-wmi-bridge-usage-guidance) to manage multiple policy format Windows Defender Application Control policies.
> WMI and GP don't currently support multiple policies. If you can't directly access the MDM stack, use the [ApplicationControl CSP via the MDM Bridge WMI Provider](/windows/client-management/mdm/applicationcontrol-csp#powershell-and-wmi-bridge-usage-guidance) to manage multiple policy format App Control for Business policies.

102
windows/security/application-security/application-control/app-control-for-business/AppIdTagging/design-create-appid-tagging-policies.md
View File

@ -1,85 +1,83 @@
---
title: Create your Windows Defender Application Control AppId Tagging Policies
description: Create your Windows Defender Application Control AppId tagging policies for Windows devices.
title: Create your App Control for Business AppId Tagging Policies
description: Create your App Control for Business AppId tagging policies for Windows devices.
ms.localizationpriority: medium
ms.date: 04/29/2022
ms.topic: conceptual
---
# Creating your WDAC AppId Tagging Policies
# Creating your App Control AppId Tagging Policies
> [!NOTE]
> Some capabilities of Windows Defender Application Control (WDAC) are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](../feature-availability.md).
[!INCLUDE [Feature availability note](../includes/feature-availability-note.md)]
## Create the policy using the WDAC Wizard
## Create the policy using the App Control Wizard
You can use the Windows Defender Application Control (WDAC) Wizard and the PowerShell commands to create an application control policy and convert it to an AppIdTagging policy. The WDAC Wizard is available for download at the [WDAC Wizard Installer site](https://aka.ms/wdacwizard). These PowerShell commands are only available on the supported platforms listed in [AppId Tagging Guide](appcontrol-appid-tagging-guide.md).
You can use the App Control for Business Wizard and the PowerShell commands to create an application control policy and convert it to an AppIdTagging policy. The App Control Wizard is available for download at the [App Control Wizard Installer site](https://aka.ms/wdacwizard). These PowerShell commands are only available on the supported platforms listed in [AppId Tagging Guide](appcontrol-appid-tagging-guide.md).
1. Create a new base policy using the templates:
Start with the Policy Creator task and select Multiple Policy Format and Base Policy. Select the Base Template to use for the policy. The following example shows beginning with the [Default Windows Mode](../design/appcontrol-wizard-create-base-policy.md#template-base-policies) template and build on top of these rules.
Start with the Policy Creator task and select Multiple Policy Format and Base Policy. Select the Base Template to use for the policy. The following example shows beginning with the [Default Windows Mode](../design/appcontrol-wizard-create-base-policy.md#template-base-policies) template and build on top of these rules.
![Configuring the policy base and template.](../images/appid-appcontrol-wizard-1.png)
![Configuring the policy base and template.](../images/appid-appcontrol-wizard-1.png)
> [!NOTE]
> If your AppId Tagging Policy does build off the base templates or does not allow Windows in-box processes, you will notice significant performance regressions, especially during boot. For this reason, it is strongly recommended to build off the base templates.
For more information on the issue, see the [AppId Tagging Known Issue](../operations/known-issues.md#slow-boot-and-performance-with-custom-policies).
> [!NOTE]
> If your AppId Tagging Policy does build off the base templates or does not allow Windows in-box processes, you will notice significant performance regressions, especially during boot. For this reason, it is strongly recommended to build off the base templates. For more information on the issue, see the [AppId Tagging Known Issue](../operations/known-issues.md#slow-boot-and-performance-with-custom-policies).
2. Set the following rule-options using the Wizard toggles:
2. Set the following rule-options using the Wizard toggles:
![Configuring the policy rule-options.](../images/appid-appcontrol-wizard-2.png)
![Configuring the policy rule-options.](../images/appid-appcontrol-wizard-2.png)
3. Create custom rules:
Selecting the `+ Custom Rules` button opens the Custom Rules panel. The Wizard supports five types of file rules:
Selecting the `+ Custom Rules` button opens the Custom Rules panel. The Wizard supports five types of file rules:
- Publisher rules: Create a rule based off the signing certificate hierarchy. Additionally, the original filename and version can be combined with the signing certificate for added security.
- Path rules: Create a rule based off the path to a file or a parent folder path. Path rules support wildcards.
- File attribute rules: Create a rule based off a file's immutable properties like the original filename, file description, product name or internal name.
- Package app name rules: Create a rule based off the package family name of an appx/msix.
- Hash rules: Create a rule based off the PE Authenticode hash of a file.
- Publisher rules: Create a rule based off the signing certificate hierarchy. Additionally, the original filename and version can be combined with the signing certificate for added security.
- Path rules: Create a rule based off the path to a file or a parent folder path. Path rules support wildcards.
- File attribute rules: Create a rule based off a file's immutable properties like the original filename, file description, product name or internal name.
- Package app name rules: Create a rule based off the package family name of an appx/msix.
- Hash rules: Create a rule based off the PE Authenticode hash of a file.
For more information on creating new policy file rules, see the guidelines provided in the [creating policy file rules section](../design/appcontrol-wizard-create-base-policy.md#creating-custom-file-rules).
For more information on creating new policy file rules, see the guidelines provided in the [creating policy file rules section](../design/appcontrol-wizard-create-base-policy.md#creating-custom-file-rules).
4. Convert to AppId Tagging Policy:
After the Wizard builds the policy file, open the file in a text editor and remove the entire "Value=131" SigningScenario text block. The only remaining signing scenario should be "Value=12" which is the user mode application section. Next, open PowerShell in an elevated prompt and run the following command. Replace the AppIdTagging Key-Value pair for your scenario:
After the Wizard builds the policy file, open the file in a text editor and remove the entire "Value=131" SigningScenario text block. The only remaining signing scenario should be "Value=12" which is the user mode application section. Next, open PowerShell in an elevated prompt and run the following command. Replace the AppIdTagging Key-Value pair for your scenario:
```powershell
Set-CIPolicyIdInfo -ResetPolicyID -FilePath .\AppIdPolicy.xml -AppIdTaggingPolicy -AppIdTaggingKey "MyKey" -AppIdTaggingValue "MyValue"
```
The policyID GUID is returned by the PowerShell command if successful.
```powershell
Set-CIPolicyIdInfo -ResetPolicyID -FilePath .\AppIdPolicy.xml -AppIdTaggingPolicy -AppIdTaggingKey "MyKey" -AppIdTaggingValue "MyValue"
```
The policyID GUID is returned by the PowerShell command if successful.
## Create the policy using PowerShell
Using this method, you create an AppId Tagging policy directly using the WDAC PowerShell commands. These PowerShell commands are only available on the supported platforms listed in [AppId Tagging Guide](appcontrol-appid-tagging-guide.md). In an elevate PowerShell instance:
Using this method, you create an AppId Tagging policy directly using the App Control PowerShell commands. These PowerShell commands are only available on the supported platforms listed in [AppId Tagging Guide](appcontrol-appid-tagging-guide.md). In an elevate PowerShell instance:
1. Create an AppId rule for the policy based on a combination of the signing certificate chain and version of the application. In the example below, the level has been set to SignedVersion. Any of the [WDAC File Rule Levels](../design/select-types-of-rules-to-create.md#table-2-windows-defender-application-control-policy---file-rule-levels) can be used in AppId rules:
1. Create an AppId rule for the policy based on a combination of the signing certificate chain and version of the application. In the example below, the level has been set to SignedVersion. Any of the [App Control File Rule Levels](../design/select-types-of-rules-to-create.md#table-2-app-control-for-business-policy---file-rule-levels) can be used in AppId rules:
```powershell
$rule = New-CiPolicyRule -Level SignedVersion -DriverFilePath <path_to_application>
```
```powershell
$rule = New-CiPolicyRule -Level SignedVersion -DriverFilePath <path_to_application>
```
2. Create the AppId Tagging Policy. Replace the AppIdTagging Key-Value pair for your scenario:
```powershell
New-CIPolicy -rules $rule -FilePath .\AppIdPolicy.xml -AppIdTaggingPolicy -AppIdTaggingKey "MyKey" -AppIdTaggingValue "MyValue"
```
```powershell
New-CIPolicy -rules $rule -FilePath .\AppIdPolicy.xml -AppIdTaggingPolicy -AppIdTaggingKey "MyKey" -AppIdTaggingValue "MyValue"
```
3. Set the rule-options for the policy:
```powershell
Set-RuleOption -Option 0 .\AppIdPolicy.xml # Usermode Code Integrity (UMCI)
Set-RuleOption -Option 16 .\AppIdPolicy.xml # Refresh Policy no Reboot
Set-RuleOption -Option 18 .\AppIdPolicy.xml # (Optional) Disable FilePath Rule Protection
```
```powershell
Set-RuleOption -Option 0 .\AppIdPolicy.xml # Usermode Code Integrity (UMCI)
Set-RuleOption -Option 16 .\AppIdPolicy.xml # Refresh Policy no Reboot
Set-RuleOption -Option 18 .\AppIdPolicy.xml # (Optional) Disable FilePath Rule Protection
```
If you're using filepath rules, you may want to set option 18. Otherwise, there's no need.
If you're using filepath rules, you may want to set option 18. Otherwise, there's no need.
4. Set the name and ID on the policy, which is helpful for future debugging:
```powershell
Set-CIPolicyIdInfo -ResetPolicyId -PolicyName "MyPolicyName" -PolicyId "MyPolicyId" -AppIdTaggingPolicy -FilePath ".\AppIdPolicy.xml"
```
The policyID GUID is returned by the PowerShell command if successful.
```powershell
Set-CIPolicyIdInfo -ResetPolicyId -PolicyName "MyPolicyName" -PolicyId "MyPolicyId" -AppIdTaggingPolicy -FilePath ".\AppIdPolicy.xml"
```
The policyID GUID is returned by the PowerShell command if successful.
## Deploy for Local Testing
@ -87,18 +85,18 @@ After creating your AppId Tagging policy in the above steps, you can deploy the
1. Depending on your deployment method, convert the xml to binary:
```powershell
Convertfrom-CIPolicy .\policy.xml ".\{PolicyIDGUID}.cip"
```
```powershell
Convertfrom-CIPolicy .\policy.xml ".\{PolicyIDGUID}.cip"
```
2. Optionally, deploy it for local testing:
```powershell
copy ".\{Policy ID}.cip" c:\windows\system32\codeintegrity\CiPolicies\Active\
./RefreshPolicy.exe
```
```powershell
copy ".\{Policy ID}.cip" c:\windows\system32\codeintegrity\CiPolicies\Active\
./RefreshPolicy.exe
```
RefreshPolicy.exe is available for download from the [Microsoft Download Center](https://www.microsoft.com/download/details.aspx?id=102925).
RefreshPolicy.exe is available for download from the [Microsoft Download Center](https://www.microsoft.com/download/details.aspx?id=102925).
## Next Steps
For more information on debugging and broad deployment of the AppId Tagging policy, see [Debugging AppId policies](debugging-operational-guide-appid-tagging-policies.md) and [Deploying AppId policies](deploy-appid-tagging-policies.md).

92
windows/security/application-security/application-control/app-control-for-business/TOC.yml
View File

@ -4,22 +4,22 @@
href: appcontrol.md
expanded: true
items:
- name: WDAC and AppLocker Overview
- name: App Control and AppLocker Overview
href: appcontrol-and-applocker-overview.md
- name: WDAC and AppLocker Feature Availability
- name: App Control and AppLocker Feature Availability
href: feature-availability.md
- name: Virtualization-based protection of code integrity
href: ../introduction-to-device-guard-virtualization-based-security-and-windows-defender-application-control.md
- name: WDAC design guide
href: ../introduction-to-virtualization-based-security-and-appcontrol.md
- name: App Control design guide
href: design/appcontrol-design-guide.md
items:
- name: Plan for WDAC policy lifecycle management
- name: Plan for App Control policy lifecycle management
href: design/plan-appcontrol-management.md
- name: Design your WDAC policy
- name: Design your App Control policy
items:
- name: Understand WDAC policy design decisions
- name: Understand App Control policy design decisions
href: design/understand-appcontrol-policy-design-decisions.md
- name: Understand WDAC policy rules and file rules
- name: Understand App Control policy rules and file rules
href: design/select-types-of-rules-to-create.md
items:
- name: Allow apps installed by a managed installer
@ -28,88 +28,88 @@
href: design/use-appcontrol-with-intelligent-security-graph.md
- name: Allow COM object registration
href: design/allow-com-object-registration-in-appcontrol-policy.md
- name: Use WDAC with .NET hardening
- name: Use App Control with .NET hardening
href: design/appcontrol-and-dotnet.md
- name: Script enforcement with Windows Defender Application Control
- name: Script enforcement with App Control for Business
href: design/script-enforcement.md
- name: Manage packaged apps with WDAC
- name: Manage packaged apps with App Control
href: design/manage-packaged-apps-with-appcontrol.md
- name: Use WDAC to control specific plug-ins, add-ins, and modules
- name: Use App Control to control specific plug-ins, add-ins, and modules
href: design/use-appcontrol-policy-to-control-specific-plug-ins-add-ins-and-modules.md
- name: Understand WDAC policy settings
- name: Understand App Control policy settings
href: design/understanding-appcontrol-policy-settings.md
- name: Use multiple WDAC policies
- name: Use multiple App Control policies
href: design/deploy-multiple-appcontrol-policies.md
- name: Create your WDAC policy
- name: Create your App Control policy
items:
- name: Example WDAC base policies
- name: Example App Control base policies
href: design/example-appcontrol-base-policies.md
- name: Policy creation for common WDAC usage scenarios
- name: Policy creation for common App Control usage scenarios
href: design/common-appcontrol-use-cases.md
items:
- name: Create a WDAC policy for lightly managed devices
- name: Create a App Control policy for lightly managed devices
href: design/create-appcontrol-policy-for-lightly-managed-devices.md
- name: Create a WDAC policy for fully managed devices
- name: Create a App Control policy for fully managed devices
href: design/create-appcontrol-policy-for-fully-managed-devices.md
- name: Create a WDAC policy for fixed-workload devices
- name: Create a App Control policy for fixed-workload devices
href: design/create-appcontrol-policy-using-reference-computer.md
- name: Create a WDAC deny list policy
- name: Create a App Control deny list policy
href: design/create-appcontrol-deny-policy.md
- name: Applications that can bypass WDAC and how to block them
- name: Applications that can bypass App Control and how to block them
href: design/applications-that-can-bypass-appcontrol.md
- name: Microsoft recommended driver block rules
href: design/microsoft-recommended-driver-block-rules.md
- name: Use the WDAC Wizard tool
- name: Use the App Control Wizard tool
href: design/appcontrol-wizard.md
items:
- name: Create a base WDAC policy with the Wizard
- name: Create a base App Control policy with the Wizard
href: design/appcontrol-wizard-create-base-policy.md
- name: Create a supplemental WDAC policy with the Wizard
- name: Create a supplemental App Control policy with the Wizard
href: design/appcontrol-wizard-create-supplemental-policy.md
- name: Editing a WDAC policy with the Wizard
- name: Editing a App Control policy with the Wizard
href: design/appcontrol-wizard-editing-policy.md
- name: Creating WDAC Policy Rules from WDAC Events
- name: Creating App Control Policy Rules from App Control Events
href: design/appcontrol-wizard-parsing-event-logs.md
- name: Merging multiple WDAC policies with the Wizard
- name: Merging multiple App Control policies with the Wizard
href: design/appcontrol-wizard-merging-policies.md
- name: WDAC deployment guide
- name: App Control deployment guide
href: deployment/appcontrol-deployment-guide.md
items:
- name: Deploy WDAC policies with MDM
- name: Deploy App Control policies with MDM
href: deployment/deploy-appcontrol-policies-using-intune.md
- name: Deploy WDAC policies with Configuration Manager
- name: Deploy App Control policies with Configuration Manager
href: deployment/deploy-appcontrol-policies-with-memcm.md
- name: Deploy WDAC policies with script
- name: Deploy App Control policies with script
href: deployment/deploy-appcontrol-policies-with-script.md
- name: Deploy WDAC policies with group policy
- name: Deploy App Control policies with group policy
href: deployment/deploy-appcontrol-policies-using-group-policy.md
- name: Audit WDAC policies
- name: Audit App Control policies
href: deployment/audit-appcontrol-policies.md
- name: Merge WDAC policies
- name: Merge App Control policies
href: deployment/merge-appcontrol-policies.md
- name: Enforce WDAC policies
- name: Enforce App Control policies
href: deployment/enforce-appcontrol-policies.md
- name: Use code signing for added control and protection with WDAC
- name: Use code signing for added control and protection with App Control
href: deployment/use-code-signing-for-better-control-and-protection.md
items:
- name: Deploy catalog files to support WDAC
- name: Deploy catalog files to support App Control
href: deployment/deploy-catalog-files-to-support-appcontrol.md
- name: Use signed policies to protect Windows Defender Application Control against tampering
- name: Use signed policies to protect App Control for Business against tampering
href: deployment/use-signed-policies-to-protect-appcontrol-against-tampering.md
- name: "Optional: Create a code signing cert for WDAC"
- name: "Optional: Create a code signing cert for App Control"
href: deployment/create-code-signing-cert-for-appcontrol.md
- name: Disable WDAC policies
- name: Disable App Control policies
href: deployment/disable-appcontrol-policies.md
- name: WDAC operational guide
- name: App Control operational guide
href: operations/appcontrol-operational-guide.md
items:
- name: WDAC debugging and troubleshooting
- name: App Control debugging and troubleshooting
href: operations/appcontrol-debugging-and-troubleshooting.md
- name: Understanding Application Control event IDs
href: operations/event-id-explanations.md
- name: Understanding Application Control event tags
href: operations/event-tag-explanations.md
- name: Query WDAC events with Advanced hunting
- name: Query App Control events with Advanced hunting
href: operations/querying-application-control-events-centrally-using-advanced-hunting.md
- name: Known Issues
href: operations/known-issues.md
@ -117,9 +117,9 @@
href: operations/configure-appcontrol-managed-installer.md
- name: CITool.exe technical reference
href: operations/citool-commands.md
- name: Inbox WDAC policies
- name: Inbox App Control policies
href: operations/inbox-appcontrol-policies.md
- name: WDAC AppId Tagging guide
- name: App Control AppId Tagging guide
href: AppIdTagging/appcontrol-appid-tagging-guide.md
items:
- name: Creating AppId Tagging Policies

31
windows/security/application-security/application-control/app-control-for-business/appcontrol-and-applocker-overview.md
View File

@ -1,23 +1,22 @@
---
title: WDAC and AppLocker Overview
title: App Control and AppLocker Overview
description: Compare Windows application control technologies.
ms.localizationpriority: medium
ms.date: 01/03/2024
ms.topic: conceptual
---
# Windows Defender Application Control and AppLocker Overview
# App Control for Business and AppLocker Overview
> [!NOTE]
> Some capabilities of Windows Defender Application Control (WDAC) are only available on specific Windows versions. Learn more about the [WDAC feature availability](feature-availability.md).
[!INCLUDE [Feature availability note](includes/feature-availability-note.md)]
Windows 10 and Windows 11 include two technologies that can be used for application control, depending on your organization's specific scenarios and requirements: Windows Defender Application Control (WDAC) and AppLocker.
Windows 10 and Windows 11 include two technologies that can be used for application control, depending on your organization's specific scenarios and requirements: App Control for Business and AppLocker.
## Windows Defender Application Control
## App Control for Business
WDAC was introduced with Windows 10 and allows organizations to control which drivers and applications are allowed to run on their Windows clients. It was designed as a security feature under the [servicing criteria](https://www.microsoft.com/msrc/windows-security-servicing-criteria), defined by the Microsoft Security Response Center (MSRC).
App Control was introduced with Windows 10 and allows organizations to control which drivers and applications are allowed to run on their Windows clients. It was designed as a security feature under the [servicing criteria](https://www.microsoft.com/msrc/windows-security-servicing-criteria), defined by the Microsoft Security Response Center (MSRC).
WDAC policies apply to the managed computer as a whole and affects all users of the device. WDAC rules can be defined based on:
App Control policies apply to the managed computer as a whole and affects all users of the device. App Control 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
@ -27,13 +26,13 @@ WDAC policies apply to the managed computer as a whole and affects all users of
- The process that launched the app or binary
> [!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.
> App Control 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 App Control policy via Group Policy.
### WDAC System Requirements
### App Control System Requirements
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.
App Control policies can be created and applied on any client edition of Windows 10 or Windows 11, or on Windows Server 2016 and higher. App Control 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 App Control 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).
For more information on which individual App Control features are available on specific App Control builds, see [App Control feature availability](feature-availability.md).
## AppLocker
@ -45,16 +44,16 @@ AppLocker policies can apply to all users on a computer, or to individual users
- 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 is also used by some features of WDAC, including [managed installer](/windows/security/application-security/application-control/windows-defender-application-control/design/configure-authorized-apps-deployed-with-a-managed-installer) and the [Intelligent Security Graph](/windows/security/application-security/application-control/windows-defender-application-control/design/use-wdac-with-intelligent-security-graph).
AppLocker is also used by some features of App Control, including [managed installer](design/configure-authorized-apps-deployed-with-a-managed-installer.md) and the [Intelligent Security Graph](design/use-appcontrol-with-intelligent-security-graph.md).
### AppLocker System Requirements
AppLocker policies can only be configured on and applied to devices that are running on the supported versions and editions of the Windows operating system. For more info, see [Requirements to Use AppLocker](applocker/requirements-to-use-applocker.md).
AppLocker policies can be deployed using Group Policy or MDM.
## Choose when to use WDAC or AppLocker
## Choose when to use App Control or AppLocker
Generally, customers who are able to implement application control using WDAC, rather than AppLocker, should 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.
Generally, customers who are able to implement application control using App Control, rather than AppLocker, should do so. App Control 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 might be the more appropriate technology for your organization. AppLocker is best when:
@ -62,4 +61,4 @@ However, in some cases, AppLocker might be the more appropriate technology for y
- You need to apply different policies for different users or groups on shared computers.
- You don't want to enforce application control on application files such as DLLs or drivers.
AppLocker can also be deployed as a complement to WDAC to add user or group-specific rules for shared device scenarios, where it's important to prevent some users from running specific apps. As a best practice, you should enforce WDAC at the most restrictive level possible for your organization, and then you can use AppLocker to further fine-tune the restrictions.
AppLocker can also be deployed as a complement to App Control to add user or group-specific rules for shared device scenarios, where it's important to prevent some users from running specific apps. As a best practice, you should enforce App Control at the most restrictive level possible for your organization, and then you can use AppLocker to further fine-tune the restrictions.

17
windows/security/application-security/application-control/app-control-for-business/appcontrol.md
View File

@ -10,8 +10,7 @@ ms.topic: overview
# Application Control for Windows
> [!NOTE]
> Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](feature-availability.md).
[!INCLUDE [Feature availability note](includes/feature-availability-note.md)]
With thousands of new malicious files created every day, using traditional methods like antivirus solutions-signature-based detection to fight against malware-provides an inadequate defense against new attacks.
@ -26,14 +25,14 @@ Application control is a crucial line of defense for protecting enterprises give
Windows 10 and Windows 11 include two technologies that can be used for application control depending on your organization's specific scenarios and requirements:
- **Windows Defender Application Control (WDAC)**; and
- **App Control for Business**; and
- **AppLocker**
## WDAC and Smart App Control
## App Control and Smart App Control
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](design/example-appcontrol-base-policies.md) is provided. The example policy includes **Enabled:Conditional Windows Lockdown Policy** option that 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](design/create-appcontrol-policy-for-lightly-managed-devices.md#create-a-custom-base-policy-using-an-example-wdac-base-policy).
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 App Control, 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](design/example-appcontrol-base-policies.md) is provided. The example policy includes **Enabled:Conditional Windows Lockdown Policy** option that isn't supported for App Control 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 App Control base policy](design/create-appcontrol-policy-for-lightly-managed-devices.md#create-a-custom-base-policy-using-an-example-app-control-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 is automatically turned off for enterprise managed devices unless the user has turned it on first. To turn off Smart App Control across your organization's endpoints, you can set the **VerifiedAndReputablePolicyState** (DWORD) registry value under `HKLM\SYSTEM\CurrentControlSet\Control\CI\Policy` as shown in the following table. 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.
Smart App Control is only available on clean installation of Windows 11 version 22H2 or later, and starts in evaluation mode. Smart App Control is automatically turned off for enterprise managed devices unless the user has turned it on first. To turn off Smart App Control across your organization's endpoints, you can set the **VerifiedAndReputablePolicyState** (DWORD) registry value under `HKLM\SYSTEM\CurrentControlSet\Control\CI\Policy` as shown in the following table. After you change the registry value, you must either restart the device or use [CiTool.exe -r](operations/citool-commands.md#refresh-the-app-control-policies-on-the-system) for the change to take effect.
| Value | Description |
|-------|-------------|
@ -57,7 +56,7 @@ Smart App Control enforces the [Microsoft Recommended Driver Block rules](design
## Related articles
- [WDAC design guide](design/appcontrol-design-guide.md)
- [WDAC deployment guide](deployment/appcontrol-deployment-guide.md)
- [WDAC operational guide](operations/appcontrol-operational-guide.md)
- [App Control design guide](design/appcontrol-design-guide.md)
- [App Control deployment guide](deployment/appcontrol-deployment-guide.md)
- [App Control operational guide](operations/appcontrol-operational-guide.md)
- [AppLocker overview](applocker/applocker-overview.md)

6
windows/security/application-security/application-control/app-control-for-business/applocker/applocker-overview.md
View File

@ -11,13 +11,13 @@ ms.date: 01/03/2024
# AppLocker
This article provides a description of AppLocker and can help you decide if your organization can benefit from deploying AppLocker application control policies. AppLocker helps you control which apps and files users can run. These include executable files, scripts, Windows Installer files, dynamic-link libraries (DLLs), packaged apps, and packaged app installers. AppLocker is also used by some features of Windows Defender Application Control.
This article provides a description of AppLocker and can help you decide if your organization can benefit from deploying AppLocker application control policies. AppLocker helps you control which apps and files users can run. These include executable files, scripts, Windows Installer files, dynamic-link libraries (DLLs), packaged apps, and packaged app installers. AppLocker is also used by some features of App Control for Business.
> [!NOTE]
> AppLocker is a defense-in-depth security feature and not considered a defensible Windows [security feature](https://www.microsoft.com/msrc/windows-security-servicing-criteria). [Windows Defender Application Control](/windows/security/threat-protection/windows-defender-application-control/wdac-and-applocker-overview) should be used when the goal is to provide robust protection against a threat and there are expected to be no by-design limitations that would prevent the security feature from achieving this goal.
> AppLocker is a defense-in-depth security feature and not considered a defensible Windows [security feature](https://www.microsoft.com/msrc/windows-security-servicing-criteria). [App Control for Business](../appcontrol-and-applocker-overview.md) should be used when the goal is to provide robust protection against a threat and there are expected to be no by-design limitations that would prevent the security feature from achieving this goal.
> [!NOTE]
> By default, AppLocker policy only applies to code launched in a user's context. On Windows 10, Windows 11, and Windows Server 2016 or later, you can apply AppLocker policy to non-user processes, including those running as SYSTEM. For more information, see [AppLocker rule collection extensions](/windows/security/application-security/application-control/windows-defender-application-control/applocker/rule-collection-extensions#services-enforcement).
> By default, AppLocker policy only applies to code launched in a user's context. On Windows 10, Windows 11, and Windows Server 2016 or later, you can apply AppLocker policy to non-user processes, including those running as SYSTEM. For more information, see [AppLocker rule collection extensions](rule-collection-extensions.md#services-enforcement).
AppLocker can help you:

2
windows/security/application-security/application-control/app-control-for-business/applocker/applocker-policies-design-guide.md
View File

@ -12,7 +12,7 @@ This article for the IT professional introduces the design and planning steps re
This guide provides important designing and planning information for deploying application control policies by using AppLocker. Through a sequential and iterative process, you can create an AppLocker policy deployment plan for your organization that addresses your specific application control requirements by department, organizational unit, or business group.
To understand if AppLocker is the correct application control solution for your organization, see [Windows Defender Application Control and AppLocker overview](/windows/security/application-security/application-control/windows-defender-application-control/wdac-and-applocker-overview).
To understand if AppLocker is the correct application control solution for your organization, see [App Control for Business and AppLocker overview](../appcontrol-and-applocker-overview.md).
## In this section

3
windows/security/application-security/application-control/app-control-for-business/applocker/applocker-processes-and-interactions.md
View File

@ -8,8 +8,7 @@ ms.date: 12/23/2023
# AppLocker processes and interactions
> [!NOTE]
> Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
[!INCLUDE [Feature availability note](../includes/feature-availability-note.md)]
This article for the IT professional describes the process dependencies and interactions when AppLocker evaluates and enforces rules.

2
windows/security/application-security/application-control/app-control-for-business/applocker/merge-applocker-policies-by-using-set-applockerpolicy.md
View File

@ -10,7 +10,7 @@ ms.date: 12/22/2023
This article for IT professionals describes the steps to merge AppLocker policies by using Windows PowerShell.
The **Set-AppLockerPolicy** cmdlet sets the specified Group Policy Object (GPO) to contain the specified AppLocker policy. If no Lightweight Directory Access Protocol (LDAP) is specified, the local policy is used. When the Merge parameter is used, rules in the specified AppLocker policy are merged with the AppLocker rules in the target GPO specified in the LDAP path. Merging policies removes rules with duplicate rule IDs, and the enforcement mode setting is chosen as described in [Working with AppLocker rules](/windows/security/application-security/application-control/windows-defender-application-control/applocker/working-with-applocker-rules#enforcement-modes). If the Merge parameter isn't specified, then the new policy overwrites the existing policy.
The **Set-AppLockerPolicy** cmdlet sets the specified Group Policy Object (GPO) to contain the specified AppLocker policy. If no Lightweight Directory Access Protocol (LDAP) is specified, the local policy is used. When the Merge parameter is used, rules in the specified AppLocker policy are merged with the AppLocker rules in the target GPO specified in the LDAP path. Merging policies removes rules with duplicate rule IDs, and the enforcement mode setting is chosen as described in [Working with AppLocker rules](working-with-applocker-rules.md#enforcement-modes). If the Merge parameter isn't specified, then the new policy overwrites the existing policy.
For info about using **Set-AppLockerPolicy**, including syntax descriptions and parameters, see [Set-AppLockerPolicy](/powershell/module/applocker/set-applockerpolicy).

2
windows/security/application-security/application-control/app-control-for-business/applocker/merge-applocker-policies-manually.md
View File

@ -12,7 +12,7 @@ This article for IT professionals describes the steps to manually merge AppLocke
If you need to merge multiple AppLocker policies into a single one, you can either manually merge the policies or use the Windows PowerShell cmdlets for AppLocker. You can't automatically merge policies by using the AppLocker console. For info about merging policies by using Windows PowerShell, see [Merge AppLocker policies by using Set-ApplockerPolicy](merge-applocker-policies-by-using-set-applockerpolicy.md).
The AppLocker policy is stored in XML format, and an exported policy can be edited with any text or XML editor. To export an AppLocker policy, see [Export an AppLocker policy to an XML file](/windows/security/application-security/application-control/windows-defender-application-control/applocker/export-an-applocker-policy-to-an-xml-file). Before making changes to an AppLocker policy manually, review [Working with AppLocker rules](/windows/security/application-security/application-control/windows-defender-application-control/applocker/working-with-applocker-rules).
The AppLocker policy is stored in XML format, and an exported policy can be edited with any text or XML editor. To export an AppLocker policy, see [Export an AppLocker policy to an XML file](export-an-applocker-policy-to-an-xml-file.md). Before making changes to an AppLocker policy manually, review [Working with AppLocker rules](working-with-applocker-rules.md).
Membership in the local **Administrators** group, or equivalent, is the minimum required to complete this procedure.

2
windows/security/application-security/application-control/app-control-for-business/applocker/rule-collection-extensions.md
View File

@ -29,7 +29,7 @@ This article describes the rule collection extensions added in Windows 10 and la
## Services enforcement
By default, AppLocker policy only applies to code running in a user's context. On Windows 10, Windows 11, and Windows Server 2016 or later, you can apply AppLocker policy to nonuser processes, including services running as SYSTEM. You must enable services enforcement when using AppLocker with Windows Defender Application Control's (WDAC) [managed installer](/windows/security/application-security/application-control/windows-defender-application-control/design/configure-authorized-apps-deployed-with-a-managed-installer) feature.
By default, AppLocker policy only applies to code running in a user's context. On Windows 10, Windows 11, and Windows Server 2016 or later, you can apply AppLocker policy to nonuser processes, including services running as SYSTEM. You must enable services enforcement when using AppLocker with App Control for Business's [managed installer](../design/configure-authorized-apps-deployed-with-a-managed-installer.md) feature.
To apply AppLocker policy to nonuser processes, set ``<Services EnforcementMode="Enabled"/>`` in the ``<ThresholdExtensions>`` section as shown in the preceding XML fragment.

2
windows/security/application-security/application-control/app-control-for-business/applocker/understand-applocker-rules-and-enforcement-setting-inheritance-in-group-policy.md
View File

@ -10,7 +10,7 @@ ms.date: 12/22/2023
This article for the IT professional describes how application control policies configured in AppLocker are applied through Group Policy.
Rule enforcement is applied only to collections of rules, not individual rules. For more info on rule collections, see [AppLocker rule collections](/windows/security/application-security/application-control/windows-defender-application-control/applocker/working-with-applocker-rules#rule-collections).
Rule enforcement is applied only to collections of rules, not individual rules. For more info on rule collections, see [AppLocker rule collections](working-with-applocker-rules.md#rule-collections).
Group Policy merges AppLocker policy in two ways:

2
windows/security/application-security/application-control/app-control-for-business/applocker/what-is-applocker.md
View File

@ -10,7 +10,7 @@ ms.date: 12/23/2023
This article for the IT professional describes what AppLocker is.
Windows includes two technologies that can be used for application control, depending on your organization's specific scenarios and requirements: Windows Defender Application Control (WDAC) and AppLocker. For information to help you choose when to use WDAC or AppLocker, see [WDAC and AppLocker overview](/windows/security/application-security/application-control/windows-defender-application-control/wdac-and-applocker-overview).
Windows includes two technologies that can be used for application control, depending on your organization's specific scenarios and requirements: App Control for Business and AppLocker. For information to help you choose when to use App Control or AppLocker, see [App Control and AppLocker overview](../appcontrol-and-applocker-overview.md).
AppLocker helps you create rules to allow or deny apps from running based on information about the apps' files. You can also use AppLocker to control which users or groups can run those apps.

37
windows/security/application-security/application-control/app-control-for-business/deployment/appcontrol-deployment-guide.md
View File

@ -1,29 +1,28 @@
---
title: Deploying Windows Defender Application Control (WDAC) policies
description: Learn how to plan and implement a WDAC deployment.
title: Deploying App Control for Business policies
description: Learn how to plan and implement a App Control deployment.
ms.localizationpriority: medium
ms.date: 01/23/2023
ms.topic: overview
---
# Deploying Windows Defender Application Control (WDAC) policies
# Deploying App Control for Business policies
> [!NOTE]
> Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](../feature-availability.md).
[!INCLUDE [Feature availability note](../includes/feature-availability-note.md)]
You should now have one or more Windows Defender Application Control (WDAC) policies ready to deploy. If you haven't yet completed the steps described in the [WDAC Design Guide](../design/appcontrol-design-guide.md), do so now before proceeding.
You should now have one or more App Control for Business policies ready to deploy. If you haven't yet completed the steps described in the [App Control Design Guide](../design/appcontrol-design-guide.md), do so now before proceeding.
## Convert your WDAC policy XML to binary
## Convert your App Control policy XML to binary
Before you deploy your WDAC policies, you must first convert the XML to its binary form. You can do this using the following PowerShell example. You must set the $WDACPolicyXMLFile variable to point to your WDAC policy XML file.
Before you deploy your App Control policies, you must first convert the XML to its binary form. You can do this using the following PowerShell example. You must set the $AppControlPolicyXMLFile variable to point to your App Control policy XML file.
```powershell
## Update the path to your WDAC policy XML
$WDACPolicyXMLFile = $env:USERPROFILE + "\Desktop\MyWDACPolicy.xml"
[xml]$WDACPolicy = Get-Content -Path $WDACPolicyXMLFile
if (($WDACPolicy.SiPolicy.PolicyID) -ne $null) ## Multiple policy format (For Windows builds 1903+ only, including Server 2022)
## Update the path to your App Control policy XML
$AppControlPolicyXMLFile = $env:USERPROFILE + "\Desktop\MyAppControlPolicy.xml"
[xml]$AppControlPolicy = Get-Content -Path $AppControlPolicyXMLFile
if (($AppControlPolicy.SiPolicy.PolicyID) -ne $null) ## Multiple policy format (For Windows builds 1903+ only, including Server 2022)
{
$PolicyID = $WDACPolicy.SiPolicy.PolicyID
$PolicyID = $AppControlPolicy.SiPolicy.PolicyID
$PolicyBinary = $PolicyID+".cip"
}
else ## Single policy format (Windows Server 2016 and 2019, and Windows 10 1809 LTSC)
@ -32,23 +31,23 @@ Before you deploy your WDAC policies, you must first convert the XML to its bina
}
## Binary file will be written to your desktop
ConvertFrom-CIPolicy -XmlFilePath $WDACPolicyXMLFile -BinaryFilePath $env:USERPROFILE\Desktop\$PolicyBinary
ConvertFrom-CIPolicy -XmlFilePath $AppControlPolicyXMLFile -BinaryFilePath $env:USERPROFILE\Desktop\$PolicyBinary
```
## Plan your deployment
As with any significant change to your environment, implementing application control can have unintended consequences. To ensure the best chance for success, you should follow safe deployment practices and plan your deployment carefully. Identify the devices you'll manage with WDAC and split them into deployment rings. This way, you can control the speed and scale of the deployment and respond if anything goes wrong. Define the success criteria that will determine when it's safe to continue from one ring to the next.
As with any significant change to your environment, implementing application control can have unintended consequences. To ensure the best chance for success, you should follow safe deployment practices and plan your deployment carefully. Identify the devices you'll manage with App Control and split them into deployment rings. This way, you can control the speed and scale of the deployment and respond if anything goes wrong. Define the success criteria that will determine when it's safe to continue from one ring to the next.
All Windows Defender Application Control policy changes should be deployed in audit mode before proceeding to enforcement. Carefully monitor events from devices where the policy has been deployed to ensure the block events you observe match your expectation before broadening the deployment to other deployment rings. If your organization uses Microsoft Defender for Endpoint, you can use the Advanced Hunting feature to centrally monitor WDAC-related events. Otherwise, we recommend using an event log forwarding solution to collect relevant events from your managed endpoints.
All App Control for Business policy changes should be deployed in audit mode before proceeding to enforcement. Carefully monitor events from devices where the policy has been deployed to ensure the block events you observe match your expectation before broadening the deployment to other deployment rings. If your organization uses Microsoft Defender for Endpoint, you can use the Advanced Hunting feature to centrally monitor App Control-related events. Otherwise, we recommend using an event log forwarding solution to collect relevant events from your managed endpoints.
## Choose how to deploy WDAC policies
## Choose how to deploy App Control policies
> [!IMPORTANT]
> Due to a known issue, you should always activate new **signed** WDAC Base policies with a reboot on systems with [**memory integrity**](../../../../hardware-security/enable-virtualization-based-protection-of-code-integrity.md) enabled. We recommend [deploying via script](deploy-appcontrol-policies-with-script.md) in this case.
> Due to a known issue, you should always activate new **signed** App Control Base policies with a reboot on systems with [**memory integrity**](../../../../hardware-security/enable-virtualization-based-protection-of-code-integrity.md) enabled. We recommend [deploying via script](deploy-appcontrol-policies-with-script.md) in this case.
>
> This issue does not affect updates to signed Base policies that are already active on the system, deployment of unsigned policies, or deployment of supplemental policies (signed or unsigned). It also does not affect deployments to systems that are not running memory integrity.
There are several options to deploy Windows Defender Application Control policies to managed endpoints, including:
There are several options to deploy App Control for Business policies to managed endpoints, including:
- [Deploy using a Mobile Device Management (MDM) solution](deploy-appcontrol-policies-using-intune.md), such as Microsoft Intune
- [Deploy using Microsoft Configuration Manager](deploy-appcontrol-policies-with-memcm.md)

39
windows/security/application-security/application-control/app-control-for-business/deployment/audit-appcontrol-policies.md
View File

@ -1,35 +1,34 @@
---
title: Use audit events to create WDAC policy rules
description: Audits allow admins to discover apps, binaries, and scripts that should be added to the WDAC policy.
title: Use audit events to create App Control policy rules
description: Audits allow admins to discover apps, binaries, and scripts that should be added to the App Control policy.
ms.localizationpriority: medium
ms.date: 05/03/2018
ms.topic: conceptual
---
# Use audit events to create WDAC policy rules
# Use audit events to create App Control policy rules
>[!NOTE]
>Some capabilities of Windows Defender Application Control (WDAC) are only available on specific Windows versions. Learn more about the [Application Control feature availability](../feature-availability.md).
[!INCLUDE [Feature availability note](../includes/feature-availability-note.md)]
Running Application Control in audit mode lets you discover applications, binaries, and scripts that are missing from your WDAC policy but should be included.
Running Application Control in audit mode lets you discover applications, binaries, and scripts that are missing from your App Control policy but should be included.
While a WDAC policy is running in audit mode, any binary that runs but would have been denied is logged in the **Applications and Services Logs\\Microsoft\\Windows\\CodeIntegrity\\Operational** event log. Script and MSI are logged in the **Applications and Services Logs\\Microsoft\\Windows\\AppLocker\\MSI and Script** event log. These events can be used to generate a new WDAC policy that can be merged with the original Base policy or deployed as a separate Supplemental policy, if allowed.
While a App Control policy is running in audit mode, any binary that runs but would have been denied is logged in the **Applications and Services Logs\\Microsoft\\Windows\\CodeIntegrity\\Operational** event log. Script and MSI are logged in the **Applications and Services Logs\\Microsoft\\Windows\\AppLocker\\MSI and Script** event log. These events can be used to generate a new App Control policy that can be merged with the original Base policy or deployed as a separate Supplemental policy, if allowed.
## Overview of the process to create WDAC policy to allow apps using audit events
## Overview of the process to create App Control policy to allow apps using audit events
> [!Note]
> You must have already deployed a WDAC audit mode policy to use this process. If you have not already done so, see [Deploying Windows Defender Application Control policies](appcontrol-deployment-guide.md).
> You must have already deployed a App Control audit mode policy to use this process. If you have not already done so, see [Deploying App Control for Business policies](appcontrol-deployment-guide.md).
To familiarize yourself with creating WDAC rules from audit events, follow these steps on a device with a WDAC audit mode policy.
To familiarize yourself with creating App Control rules from audit events, follow these steps on a device with a App Control audit mode policy.
1. Install and run an application not allowed by the WDAC policy but that you want to allow.
1. Install and run an application not allowed by the App Control policy but that you want to allow.
2. Review the **CodeIntegrity - Operational** and **AppLocker - MSI and Script** event logs to confirm events, like those shown in Figure 1, are generated related to the application. For information about the types of events you should see, refer to [Understanding Application Control events](../operations/event-id-explanations.md).
**Figure 1. Exceptions to the deployed WDAC policy**
![Event showing exception to WDAC policy.](../images/dg-fig23-exceptionstocode.png)
**Figure 1. Exceptions to the deployed App Control policy**
![Event showing exception to App Control policy.](../images/dg-fig23-exceptionstocode.png)
3. In an elevated PowerShell session, run the following commands to initialize variables used by this procedure. This procedure builds upon the **Lamna_FullyManagedClients_Audit.xml** policy introduced in [Create a WDAC policy for fully managed devices](../design/create-appcontrol-policy-for-fully-managed-devices.md) and will produce a new policy called **EventsPolicy.xml**.
3. In an elevated PowerShell session, run the following commands to initialize variables used by this procedure. This procedure builds upon the **Lamna_FullyManagedClients_Audit.xml** policy introduced in [Create a App Control policy for fully managed devices](../design/create-appcontrol-policy-for-fully-managed-devices.md) and will produce a new policy called **EventsPolicy.xml**.
```powershell
$PolicyName= "Lamna_FullyManagedClients_Audit"
@ -38,24 +37,24 @@ To familiarize yourself with creating WDAC rules from audit events, follow these
$EventsPolicyWarnings=$env:userprofile+"\Desktop\EventsPolicyWarnings.txt"
```
4. Use [New-CIPolicy](/powershell/module/configci/new-cipolicy) to generate a new WDAC policy from logged audit events. This example uses a **FilePublisher** file rule level and a **Hash** fallback level. Warning messages are redirected to a text file **EventsPolicyWarnings.txt**.
4. Use [New-CIPolicy](/powershell/module/configci/new-cipolicy) to generate a new App Control policy from logged audit events. This example uses a **FilePublisher** file rule level and a **Hash** fallback level. Warning messages are redirected to a text file **EventsPolicyWarnings.txt**.
```powershell
New-CIPolicy -FilePath $EventsPolicy -Audit -Level FilePublisher -Fallback SignedVersion,FilePublisher,Hash -UserPEs -MultiplePolicyFormat 3> $EventsPolicyWarnings
```
> [!NOTE]
> When you create policies from audit events, you should carefully consider the file rule level that you select to trust. The preceding example uses the **FilePublisher** rule level with a fallback level of **Hash**, which may be more specific than desired. You can re-run the above command using different **-Level** and **-Fallback** options to meet your needs. For more information about WDAC rule levels, see [Understand WDAC policy rules and file rules](../design/select-types-of-rules-to-create.md).
> When you create policies from audit events, you should carefully consider the file rule level that you select to trust. The preceding example uses the **FilePublisher** rule level with a fallback level of **Hash**, which may be more specific than desired. You can re-run the above command using different **-Level** and **-Fallback** options to meet your needs. For more information about App Control rule levels, see [Understand App Control policy rules and file rules](../design/select-types-of-rules-to-create.md).
5. Find and review the WDAC policy file **EventsPolicy.xml** that should be found on your desktop. Ensure that it only includes file and signer rules for applications, binaries, and scripts you wish to allow. You can remove rules by manually editing the policy XML or use the WDAC Policy Wizard tool (see [Editing existing base and supplemental WDAC policies with the Wizard](../design/appcontrol-wizard-editing-policy.md)).
5. Find and review the App Control policy file **EventsPolicy.xml** that should be found on your desktop. Ensure that it only includes file and signer rules for applications, binaries, and scripts you wish to allow. You can remove rules by manually editing the policy XML or use the App Control Policy Wizard tool (see [Editing existing base and supplemental App Control policies with the Wizard](../design/appcontrol-wizard-editing-policy.md)).
6. Find and review the text file **EventsPolicyWarnings.txt** that should be found on your desktop. This file will include a warning for any files that WDAC couldn't create a rule for at either the specified rule level or fallback rule level.
6. Find and review the text file **EventsPolicyWarnings.txt** that should be found on your desktop. This file will include a warning for any files that App Control couldn't create a rule for at either the specified rule level or fallback rule level.
> [!NOTE]
> New-CIPolicy only creates rules for files that can still be found on disk. Files which are no longer present on the system will not have a rule created to allow them. However, the event log should have sufficient information to allow these files by manually editing the policy XML to add rules. You can use an existing rule as a template and verify your results against the WDAC policy schema definition found at **%windir%\schemas\CodeIntegrity\cipolicy.xsd**.
> New-CIPolicy only creates rules for files that can still be found on disk. Files which are no longer present on the system will not have a rule created to allow them. However, the event log should have sufficient information to allow these files by manually editing the policy XML to add rules. You can use an existing rule as a template and verify your results against the App Control policy schema definition found at **%windir%\schemas\CodeIntegrity\cipolicy.xsd**.
7. Merge **EventsPolicy.xml** with the Base policy **Lamna_FullyManagedClients_Audit.xml** or convert it to a supplemental policy.
For information on merging policies, refer to [Merge Windows Defender Application Control policies](merge-appcontrol-policies.md) and for information on supplemental policies see [Use multiple Windows Defender Application Control Policies](../design/deploy-multiple-appcontrol-policies.md).
For information on merging policies, refer to [Merge App Control for Business policies](merge-appcontrol-policies.md) and for information on supplemental policies see [Use multiple App Control for Business Policies](../design/deploy-multiple-appcontrol-policies.md).
8. Convert the Base or Supplemental policy to binary and deploy using your preferred method.

19
windows/security/application-security/application-control/app-control-for-business/deployment/create-code-signing-cert-for-appcontrol.md
View File

@ -1,22 +1,21 @@
---
title: Create a code signing cert for Windows Defender Application Control
description: Learn how to set up a publicly issued code signing certificate, so you can sign catalog files or WDAC policies internally.
title: Create a code signing cert for App Control for Business
description: Learn how to set up a publicly issued code signing certificate, so you can sign catalog files or App Control policies internally.
ms.localizationpriority: medium
ms.topic: conceptual
ms.date: 12/01/2022
---
# Optional: Create a code signing cert for Windows Defender Application Control
# Optional: Create a code signing cert for App Control for Business
>[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](../feature-availability.md).
[!INCLUDE [Feature availability note](../includes/feature-availability-note.md)]
As you deploy Windows Defender Application Control (WDAC), you might need to sign catalog files or WDAC policies internally. To do this signing, you'll either need to use [Microsoft's Trusted Signing service](/azure/trusted-signing/), a publicly issued code signing certificate or an internal CA. If you've purchased a code signing certificate, you can skip this article, and instead follow other articles listed in the [Windows Defender Application Control Deployment Guide](appcontrol-deployment-guide.md).
As you deploy App Control for Business, you might need to sign catalog files or App Control policies internally. To do this signing, you'll either need to use [Microsoft's Trusted Signing service](/azure/trusted-signing/), a publicly issued code signing certificate or an internal CA. If you've purchased a code signing certificate, you can skip this article, and instead follow other articles listed in the [App Control for Business Deployment Guide](appcontrol-deployment-guide.md).
If you have an internal CA, complete these steps to create a code signing certificate.
> [!WARNING]
> When creating signing certificates for WDAC policy signing, Boot failure (blue screen) may occur if your signing certificate does not follow these rules:
> When creating signing certificates for App Control policy signing, Boot failure (blue screen) may occur if your signing certificate does not follow these rules:
>
> - All policies, including base and supplemental, must be signed according to the [PKCS 7 Standard](https://datatracker.ietf.org/doc/html/rfc5652).
> - Use RSA keys with 2K, 3K, or 4K key size only. ECDSA isn't supported.
@ -34,7 +33,7 @@ If you have an internal CA, complete these steps to create a code signing certif
4. On the **Compatibility** tab, clear the **Show resulting changes** check box. Select **Windows Server 2012** from the **Certification Authority** list, and then select **Windows 8 / Windows Server 2012** from the **Certificate recipient** list.
5. On the **General** tab, specify the **Template display name** and **Template name**. This example uses the name **WDAC Catalog Signing Certificate**.
5. On the **General** tab, specify the **Template display name** and **Template name**. This example uses the name **App Control Catalog Signing Certificate**.
6. On the **Request Handling** tab, select the **Allow private key to be exported** check box.
@ -64,7 +63,7 @@ When this certificate template has been created, you must publish it to the CA p
A list of available templates to issue appears, including the template you created.
2. Select the WDAC Catalog signing certificate, and then select **OK**.
2. Select the App Control Catalog signing certificate, and then select **OK**.
Now that the template is available to be issued, you must request one from the computer running Windows 10 or Windows 11 on which you create and sign catalog files. To begin, open the MMC, and then complete the following steps:
@ -95,6 +94,6 @@ This certificate must be installed in the user's personal store on the computer
3. Choose the default settings, and then select **Export all extended properties**.
4. Set a password, select an export path, and then select **WDACCatSigningCert.pfx** as the file name.
4. Set a password, select an export path, and then select **AppControlCatSigningCert.pfx** as the file name.
When the certificate has been exported, import it into the personal store for the user who will be signing the catalog files or code integrity policies on the specific computer that will be signing them.

39
windows/security/application-security/application-control/app-control-for-business/deployment/deploy-appcontrol-policies-using-group-policy.md
View File

@ -1,38 +1,37 @@
---
title: Deploy WDAC policies via Group Policy
description: Windows Defender Application Control (WDAC) policies can easily be deployed and managed with Group Policy. Learn how by following this step-by-step guide.
title: Deploy App Control policies via Group Policy
description: App Control for Business policies can easily be deployed and managed with Group Policy. Learn how by following this step-by-step guide.
ms.localizationpriority: medium
ms.date: 01/23/2023
ms.topic: how-to
---
# Deploy Windows Defender Application Control policies by using Group Policy
# Deploy App Control for Business policies by using Group Policy
> [!NOTE]
> Some capabilities of Windows Defender Application Control (WDAC) are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](../feature-availability.md).
[!INCLUDE [Feature availability note](../includes/feature-availability-note.md)]
> [!IMPORTANT]
> Due to a known issue, you should always activate new **signed** WDAC Base policies *with a reboot* on systems with [**memory integrity**](../../../../hardware-security/enable-virtualization-based-protection-of-code-integrity.md) enabled. Instead of Group Policy, deploy new signed WDAC Base policies [via script](/windows/security/threat-protection/windows-defender-application-control/deployment/deploy-wdac-policies-with-script#deploying-signed-policies) and activate the policy with a system restart.
> Due to a known issue, you should always activate new **signed** App Control Base policies *with a reboot* on systems with [**memory integrity**](../../../../hardware-security/enable-virtualization-based-protection-of-code-integrity.md) enabled. Instead of Group Policy, deploy new signed App Control Base policies [via script](deploy-appcontrol-policies-with-script.md#deploying-signed-policies) and activate the policy with a system restart.
>
> This issue does not affect updates to signed Base policies that are already active on the system, deployment of unsigned policies, or deployment of supplemental policies (signed or unsigned). It also does not affect deployments to systems that are not running memory integrity.
Single-policy format Windows Defender Application Control policies (pre-1903 policy schema) can be easily deployed and managed with Group Policy.
Single-policy format App Control for Business policies (pre-1903 policy schema) can be easily deployed and managed with Group Policy.
> [!IMPORTANT]
> Group Policy-based deployment of Windows Defender Application Control policies only supports single-policy format WDAC policies. To use WDAC on devices running Windows 10 1903 and greater, or Windows 11, we recommend using an alternative method for policy deployment.
> Group Policy-based deployment of App Control for Business policies only supports single-policy format App Control policies. To use App Control on devices running Windows 10 1903 and greater, or Windows 11, we recommend using an alternative method for policy deployment.
You should now have a WDAC policy converted into binary form. If not, follow the steps described in [Deploying Windows Defender Application Control (WDAC) policies](/windows/security/threat-protection/windows-defender-application-control/windows-defender-application-control-deployment-guide).
You should now have a App Control policy converted into binary form. If not, follow the steps described in [Deploying App Control for Business policies](appcontrol-deployment-guide.md).
The following procedure walks you through how to deploy a WDAC policy called **SiPolicy.p7b** to a test OU called *WDAC Enabled PCs* by using a GPO called **Contoso GPO Test**.
The following procedure walks you through how to deploy a App Control policy called **SiPolicy.p7b** to a test OU called *App Control Enabled PCs* by using a GPO called **Contoso GPO Test**.
To deploy and manage a Windows Defender Application Control policy with Group Policy:
To deploy and manage a App Control for Business policy with Group Policy:
1. On a client computer on which RSAT is installed, open the GPMC by running **GPMC.MSC**
2. Create a new GPO: right-click an OU and then select **Create a GPO in this domain, and Link it here**.
> [!NOTE]
> You can use any OU name. Also, security group filtering is an option when you consider different ways of combining WDAC policies (or keeping them separate), as discussed in [Plan for Windows Defender Application Control lifecycle policy management](../design/plan-appcontrol-management.md).
> You can use any OU name. Also, security group filtering is an option when you consider different ways of combining App Control policies (or keeping them separate), as discussed in [Plan for App Control for Business lifecycle policy management](../design/plan-appcontrol-management.md).
![Group Policy Management, create a GPO.](../images/dg-fig24-creategpo.png)
@ -40,20 +39,20 @@ To deploy and manage a Windows Defender Application Control policy with Group Po
4. Open the Group Policy Management Editor: right-click the new GPO, and then select **Edit**.
5. In the selected GPO, navigate to Computer Configuration\\Administrative Templates\\System\\Device Guard. Right-click **Deploy Windows Defender Application Control** and then select **Edit**.
5. In the selected GPO, navigate to Computer Configuration\\Administrative Templates\\System\\Device Guard. Right-click **Deploy App Control for Business** and then select **Edit**.
![Edit the Group Policy for Windows Defender Application Control.](../images/appcontrol-edit-gp.png)
![Edit the Group Policy for App Control for Business.](../images/appcontrol-edit-gp.png)
6. In the **Deploy Windows Defender Application Control** dialog box, select the **Enabled** option, and then specify the WDAC policy deployment path.
6. In the **Deploy App Control for Business** dialog box, select the **Enabled** option, and then specify the App Control policy deployment path.
In this policy setting, you specify either the local path where the policy will exist on each client computer or a Universal Naming Convention (UNC) path that the client computers will look to retrieve the latest version of the policy. For example, the path to SiPolicy.p7b using the steps described in [Deploying Windows Defender Application Control (WDAC) policies](/windows/security/threat-protection/windows-defender-application-control/windows-defender-application-control-deployment-guide) would be %USERPROFILE%\Desktop\SiPolicy.p7b.
In this policy setting, you specify either the local path where the policy will exist on each client computer or a Universal Naming Convention (UNC) path that the client computers will look to retrieve the latest version of the policy. For example, the path to SiPolicy.p7b using the steps described in [Deploying App Control for Business policies](appcontrol-deployment-guide.md) would be %USERPROFILE%\Desktop\SiPolicy.p7b.
> [!NOTE]
> This policy file does not need to be copied to every computer. You can instead copy the WDAC policies to a file share to which all computer accounts have access. Any policy selected here is converted to SIPolicy.p7b when it is deployed to the individual client computers.
> This policy file does not need to be copied to every computer. You can instead copy the App Control policies to a file share to which all computer accounts have access. Any policy selected here is converted to SIPolicy.p7b when it is deployed to the individual client computers.
![Group Policy called Deploy Windows Defender Application Control.](../images/dg-fig26-enablecode.png)
![Group Policy called Deploy App Control for Business.](../images/dg-fig26-enablecode.png)
> [!NOTE]
> You may have noticed that the GPO setting references a .p7b file, but the file extension and name of the policy binary do not matter. Regardless of what you name your policy binary, they are all converted to SIPolicy.p7b when applied to the client computers running Windows 10. If you are deploying different WDAC policies to different sets of devices, you may want to give each of your WDAC policies a friendly name and allow the system to convert the policy names for you to ensure that the policies are easily distinguishable when viewed in a share or any other central repository.
> You may have noticed that the GPO setting references a .p7b file, but the file extension and name of the policy binary do not matter. Regardless of what you name your policy binary, they are all converted to SIPolicy.p7b when applied to the client computers running Windows 10. If you are deploying different App Control policies to different sets of devices, you may want to give each of your App Control policies a friendly name and allow the system to convert the policy names for you to ensure that the policies are easily distinguishable when viewed in a share or any other central repository.
7. Close the Group Policy Management Editor, and then restart the Windows test computer. Restarting the computer updates the WDAC policy.
7. Close the Group Policy Management Editor, and then restart the Windows test computer. Restarting the computer updates the App Control policy.

39
windows/security/application-security/application-control/app-control-for-business/deployment/deploy-appcontrol-policies-using-intune.md
View File

@ -1,26 +1,25 @@
---
title: Deploy WDAC policies using Mobile Device Management (MDM)
description: You can use an MDM like Microsoft Intune to configure Windows Defender Application Control (WDAC). Learn how with this step-by-step guide.
title: Deploy App Control policies using Mobile Device Management (MDM)
description: You can use an MDM like Microsoft Intune to configure App Control for Business. Learn how with this step-by-step guide.
ms.localizationpriority: medium
ms.date: 08/30/2023
ms.topic: how-to
---
# Deploy WDAC policies using Mobile Device Management (MDM)
# Deploy App Control policies using Mobile Device Management (MDM)
> [!NOTE]
> Some capabilities of Windows Defender Application Control (WDAC) are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](../feature-availability.md).
[!INCLUDE [Feature availability note](../includes/feature-availability-note.md)]
You can use a Mobile Device Management (MDM) solution, like Microsoft Intune, to configure Windows Defender Application Control (WDAC) on client machines. Intune includes native support for WDAC, which can be a helpful starting point, but customers may find the available circle-of-trust options too limiting. To deploy a custom policy through Intune and define your own circle of trust, you can configure a profile using Custom OMA-URI. If your organization uses another MDM solution, check with your solution provider for WDAC policy deployment steps.
You can use a Mobile Device Management (MDM) solution, like Microsoft Intune, to configure App Control for Business on client machines. Intune includes native support for App Control, which can be a helpful starting point, but customers may find the available circle-of-trust options too limiting. To deploy a custom policy through Intune and define your own circle of trust, you can configure a profile using Custom OMA-URI. If your organization uses another MDM solution, check with your solution provider for App Control policy deployment steps.
> [!IMPORTANT]
> Due to a known issue, you should always activate new **signed** WDAC Base policies *with a reboot* on systems with [**memory integrity**](../../../../hardware-security/enable-virtualization-based-protection-of-code-integrity.md) enabled. Instead of Mobile Device Management (MDM), deploy new signed WDAC Base policies [via script](deploy-appcontrol-policies-with-script.md) and activate the policy with a system restart.
> Due to a known issue, you should always activate new **signed** App Control Base policies *with a reboot* on systems with [**memory integrity**](../../../../hardware-security/enable-virtualization-based-protection-of-code-integrity.md) enabled. Instead of Mobile Device Management (MDM), deploy new signed App Control Base policies [via script](deploy-appcontrol-policies-with-script.md) and activate the policy with a system restart.
>
> This issue does not affect updates to signed Base policies that are already active on the system, deployment of unsigned policies, or deployment of supplemental policies (signed or unsigned). It also does not affect deployments to systems that are not running memory integrity.
## Use Intune's built-in policies
Intune's built-in Windows Defender Application Control support allows you to configure Windows client computers to only run:
Intune's built-in App Control for Business support allows you to configure Windows client computers to only run:
- Windows components
- Third-party hardware and software kernel drivers
@ -28,21 +27,21 @@ Intune's built-in Windows Defender Application Control support allows you to con
- [Optional] Reputable apps as defined by the Intelligent Security Graph (ISG)
> [!NOTE]
> Intune's built-in policies use the pre-1903 single-policy format version of the DefaultWindows policy. Use the [improved Intune WDAC experience](/mem/intune/protect/endpoint-security-app-control-policy), currently in public preview, to create and deploy multiple-policy format files. Or, you can use Intune's custom OMA-URI feature to deploy your own multiple-policy format WDAC policies and leverage features available on Windows 10 1903+ or Windows 11 as described later in this topic.
> Intune's built-in policies use the pre-1903 single-policy format version of the DefaultWindows policy. Use the [improved Intune App Control experience](/mem/intune/protect/endpoint-security-app-control-policy), currently in public preview, to create and deploy multiple-policy format files. Or, you can use Intune's custom OMA-URI feature to deploy your own multiple-policy format App Control policies and leverage features available on Windows 10 1903+ or Windows 11 as described later in this topic.
> [!NOTE]
> Intune currently uses the AppLocker CSP to deploy its built-in policies. The AppLocker CSP always requests a device restart when it applies WDAC policies. Use the [improved Intune WDAC experience](/mem/intune/protect/endpoint-security-app-control-policy), currently in public preview, to deploy your own WDAC policies without a restart. Or, you can use Intune's custom OMA-URI feature with the ApplicationControl CSP.
> Intune currently uses the AppLocker CSP to deploy its built-in policies. The AppLocker CSP always requests a device restart when it applies App Control policies. Use the [improved Intune App Control experience](/mem/intune/protect/endpoint-security-app-control-policy), currently in public preview, to deploy your own App Control policies without a restart. Or, you can use Intune's custom OMA-URI feature with the ApplicationControl CSP.
To use Intune's built-in WDAC policies, configure [Endpoint Protection for Windows 10 (and later)](/mem/intune/protect/endpoint-protection-windows-10?toc=/intune/configuration/toc.json&bc=/intune/configuration/breadcrumb/toc.json).
To use Intune's built-in App Control policies, configure [Endpoint Protection for Windows 10 (and later)](/mem/intune/protect/endpoint-protection-windows-10?toc=/intune/configuration/toc.json&bc=/intune/configuration/breadcrumb/toc.json).
## Deploy WDAC policies with custom OMA-URI
## Deploy App Control policies with custom OMA-URI
> [!NOTE]
> Policies deployed through Intune custom OMA-URI are subject to a 350,000 byte limit. Customers should create Windows Defender Application Control policies that use signature-based rules, the Intelligent Security Graph, and managed installers where practical. Customers whose devices are running 1903+ builds of Windows are also encouraged to use [multiple policies](../design/deploy-multiple-appcontrol-policies.md) which allow more granular policy.
> Policies deployed through Intune custom OMA-URI are subject to a 350,000 byte limit. Customers should create App Control for Business policies that use signature-based rules, the Intelligent Security Graph, and managed installers where practical. Customers whose devices are running 1903+ builds of Windows are also encouraged to use [multiple policies](../design/deploy-multiple-appcontrol-policies.md) which allow more granular policy.
You should now have one or more WDAC policies converted into binary form. If not, follow the steps described in [Deploying Windows Defender Application Control (WDAC) policies](/windows/security/threat-protection/windows-defender-application-control/windows-defender-application-control-deployment-guide).
You should now have one or more App Control policies converted into binary form. If not, follow the steps described in [Deploying App Control for Business policies](appcontrol-deployment-guide.md).
### Deploy custom WDAC policies on Windows 10 1903+
### Deploy custom App Control policies on Windows 10 1903+
Beginning with Windows 10 1903, custom OMA-URI policy deployment can use the [ApplicationControl CSP](/windows/client-management/mdm/applicationcontrol-csp), which has support for multiple policies and rebootless policies.
@ -58,20 +57,20 @@ The steps to use Intune's custom OMA-URI functionality are:
- **Data type**: Base64 (file)
- **Certificate file**: Upload your binary format policy file. To do this, change your {GUID}.cip file to {GUID}.bin. You don't need to upload a Base64 file, as Intune converts the uploaded .bin file to Base64 on your behalf.
:::image type="content" alt-text="Configure custom WDAC." source="../images/appcontrol-intune-custom-oma-uri.png" lightbox="../images/appcontrol-intune-custom-oma-uri.png":::
:::image type="content" alt-text="Configure custom App Control." source="../images/appcontrol-intune-custom-oma-uri.png" lightbox="../images/appcontrol-intune-custom-oma-uri.png":::
> [!NOTE]
> For the _Policy GUID_ value, do not include the curly brackets.
### Remove WDAC policies on Windows 10 1903+
### Remove App Control policies on Windows 10 1903+
Upon deletion, policies deployed through Intune via the ApplicationControl CSP are removed from the system but stay in effect until the next reboot. In order to disable Windows Defender Application Control enforcement, first replace the existing policy with a new version of the policy that will "Allow *", like the rules in the example policy at %windir%\schemas\CodeIntegrity\ExamplePolicies\AllowAll.xml. Once the updated policy is deployed, you can then delete the policy from the Intune portal. This deletion will prevent anything from being blocked and fully remove the WDAC policy on the next reboot.
Upon deletion, policies deployed through Intune via the ApplicationControl CSP are removed from the system but stay in effect until the next reboot. In order to disable App Control for Business enforcement, first replace the existing policy with a new version of the policy that will "Allow *", like the rules in the example policy at %windir%\schemas\CodeIntegrity\ExamplePolicies\AllowAll.xml. Once the updated policy is deployed, you can then delete the policy from the Intune portal. This deletion will prevent anything from being blocked and fully remove the App Control policy on the next reboot.
### For pre-1903 systems
#### Deploying policies
The steps to use Intune's Custom OMA-URI functionality to apply the [AppLocker CSP](/windows/client-management/mdm/applocker-csp) and deploy a custom WDAC policy to pre-1903 systems are:
The steps to use Intune's Custom OMA-URI functionality to apply the [AppLocker CSP](/windows/client-management/mdm/applocker-csp) and deploy a custom App Control policy to pre-1903 systems are:
1. Convert the policy XML to binary format using the [ConvertFrom-CIPolicy](/powershell/module/configci/convertfrom-cipolicy) cmdlet in order to be deployed. The binary policy may be signed or unsigned.
@ -87,4 +86,4 @@ The steps to use Intune's Custom OMA-URI functionality to apply the [AppLocker C
#### Removing policies
Policies deployed through Intune via the AppLocker CSP can't be deleted through the Intune console. In order to disable Windows Defender Application Control policy enforcement, either deploy an audit-mode policy or use a script to delete the existing policy.
Policies deployed through Intune via the AppLocker CSP can't be deleted through the Intune console. In order to disable App Control for Business policy enforcement, either deploy an audit-mode policy or use a script to delete the existing policy.

41
windows/security/application-security/application-control/app-control-for-business/deployment/deploy-appcontrol-policies-with-memcm.md
View File

@ -1,21 +1,20 @@
---
title: Deploy Windows Defender Application Control policies with Configuration Manager
description: You can use Microsoft Configuration Manager to configure Windows Defender Application Control (WDAC). Learn how with this step-by-step guide.
title: Deploy App Control for Business policies with Configuration Manager
description: You can use Microsoft Configuration Manager to configure App Control for Business. Learn how with this step-by-step guide.
ms.date: 06/27/2022
ms.topic: how-to
ms.localizationpriority: medium
---
# Deploy WDAC policies by using Microsoft Configuration Manager
# Deploy App Control policies by using Microsoft Configuration Manager
> [!NOTE]
> Some capabilities of Windows Defender Application Control (WDAC) are only available on specific Windows versions. Learn more about the [Application Control feature availability](../feature-availability.md).
[!INCLUDE [Feature availability note](../includes/feature-availability-note.md)]
You can use Microsoft Configuration Manager to configure Windows Defender Application Control (WDAC) on client machines.
You can use Microsoft Configuration Manager to configure App Control for Business on client machines.
## Use Configuration Manager's built-in policies
Configuration Manager includes native support for WDAC, which allows you to configure Windows 10 and Windows 11 client computers with a policy that will only allow:
Configuration Manager includes native support for App Control, which allows you to configure Windows 10 and Windows 11 client computers with a policy that will only allow:
- Windows components
- Microsoft Store apps
@ -23,24 +22,24 @@ Configuration Manager includes native support for WDAC, which allows you to conf
- (Optional) Reputable apps as defined by the Intelligent Security Graph (ISG)
- (Optional) Apps and executables already installed in admin-definable folder locations that Configuration Manager will allow through a one-time scan during policy creation on managed endpoints.
Configuration Manager doesn't remove policies once deployed. To stop enforcement, you should switch the policy to audit mode, which will produce the same effect. If you want to disable Windows Defender Application Control (WDAC) altogether (including audit mode), you can deploy a script to delete the policy file from disk, and either trigger a reboot or wait for the next reboot.
Configuration Manager doesn't remove policies once deployed. To stop enforcement, you should switch the policy to audit mode, which will produce the same effect. If you want to disable App Control for Business altogether (including audit mode), you can deploy a script to delete the policy file from disk, and either trigger a reboot or wait for the next reboot.
### Create a WDAC Policy in Configuration Manager
### Create a App Control Policy in Configuration Manager
1. Select **Asset and Compliance** > **Endpoint Protection** > **Windows Defender Application Control** > **Create Application Control Policy**
1. Select **Asset and Compliance** > **Endpoint Protection** > **App Control for Business** > **Create Application Control Policy**
![Create a WDAC policy in Configuration Manager.](../images/memcm/memcm-create-appcontrol-policy.jpg)
![Create a App Control policy in Configuration Manager.](../images/memcm/memcm-create-appcontrol-policy.jpg)
2. Enter the name of the policy > **Next**
3. Enable **Enforce a restart of devices so that this policy can be enforced for all processes**
4. Select the mode that you want the policy to run (Enforcement enabled / Audit Only)
5. Select **Next**
![Create an enforced WDAC policy in Configuration Manager.](../images/memcm/memcm-create-appcontrol-policy-2.jpg)
![Create an enforced App Control policy in Configuration Manager.](../images/memcm/memcm-create-appcontrol-policy-2.jpg)
6. Select **Add** to begin creating rules for trusted software
![Create a WDAC path rule in Configuration Manager.](../images/memcm/memcm-create-appcontrol-rule.jpg)
![Create a App Control path rule in Configuration Manager.](../images/memcm/memcm-create-appcontrol-rule.jpg)
7. Select **File** or **Folder** to create a path rule > **Browse**
@ -53,13 +52,13 @@ Configuration Manager doesn't remove policies once deployed. To stop enforcement
9. Select **OK** to add the rule to the table of trusted files or folder
10. Select **Next** to navigate to the summary page > **Close**
![Confirm the WDAC path rule in Configuration Manager.](../images/memcm/memcm-confirm-appcontrol-rule.jpg)
![Confirm the App Control path rule in Configuration Manager.](../images/memcm/memcm-confirm-appcontrol-rule.jpg)
### Deploy the WDAC policy in Configuration Manager
### Deploy the App Control policy in Configuration Manager
1. Right-click the newly created policy > **Deploy Application Control Policy**
![Deploy WDAC via Configuration Manager.](../images/memcm/memcm-deploy-appcontrol.jpg)
![Deploy App Control via Configuration Manager.](../images/memcm/memcm-deploy-appcontrol.jpg)
2. Select **Browse**
@ -71,12 +70,12 @@ Configuration Manager doesn't remove policies once deployed. To stop enforcement
4. Change the schedule > **OK**
![Change the WDAC deployment schedule.](../images/memcm/memcm-deploy-appcontrol-4.jpg)
![Change the App Control deployment schedule.](../images/memcm/memcm-deploy-appcontrol-4.jpg)
For more information on using Configuration Manager's native WDAC policies, see [Windows Defender Application Control management with Configuration Manager](/mem/configmgr/protect/deploy-use/use-device-guard-with-configuration-manager).
For more information on using Configuration Manager's native App Control policies, see [App Control for Business management with Configuration Manager](/mem/configmgr/protect/deploy-use/use-device-guard-with-configuration-manager).
Download the entire [WDAC in Configuration Manager lab paper](https://download.microsoft.com/download/c/f/d/cfd6227c-8ec4-442d-8c50-825550d412f6/WDAC-Deploy-WDAC-using-MEMCM.pdf).
Download the entire [App Control in Configuration Manager lab paper](https://download.microsoft.com/download/c/f/d/cfd6227c-8ec4-442d-8c50-825550d412f6/App Control-Deploy-App Control-using-MEMCM.pdf).
## Deploy custom WDAC policies using Packages/Programs or Task Sequences
## Deploy custom App Control policies using Packages/Programs or Task Sequences
Using Configuration Manager's built-in policies can be a helpful starting point, but customers may find the circle-of-trust options available in Configuration Manager too limiting. To define your own circle-of-trust, you can use Configuration Manager to deploy custom WDAC policies using [script-based deployment](deploy-appcontrol-policies-with-script.md) via Software Distribution Packages and Programs or Operating System Deployment Task Sequences.
Using Configuration Manager's built-in policies can be a helpful starting point, but customers may find the circle-of-trust options available in Configuration Manager too limiting. To define your own circle-of-trust, you can use Configuration Manager to deploy custom App Control policies using [script-based deployment](deploy-appcontrol-policies-with-script.md) via Software Distribution Packages and Programs or Operating System Deployment Task Sequences.

31
windows/security/application-security/application-control/app-control-for-business/deployment/deploy-appcontrol-policies-with-script.md
View File

@ -1,29 +1,28 @@
---
title: Deploy Windows Defender Application Control (WDAC) policies using script
description: Use scripts to deploy Windows Defender Application Control (WDAC) policies. Learn how with this step-by-step guide.
title: Deploy App Control for Business policies using script
description: Use scripts to deploy App Control for Business policies. Learn how with this step-by-step guide.
ms.manager: jsuther
ms.date: 01/23/2023
ms.topic: how-to
ms.localizationpriority: medium
---
# Deploy WDAC policies using script
# Deploy App Control policies using script
>[!NOTE]
>Some capabilities of Windows Defender Application Control (WDAC) 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).
[!INCLUDE [Feature availability note](../includes/feature-availability-note.md)]
This article describes how to deploy Windows Defender Application Control (WDAC) policies using script. The following instructions use PowerShell but can work with any scripting host.
This article describes how to deploy App Control for Business policies using script. The following instructions use PowerShell but can work with any scripting host.
You should now have one or more WDAC policies converted into binary form. If not, follow the steps described in [Deploying Windows Defender Application Control (WDAC) policies](/windows/security/threat-protection/windows-defender-application-control/windows-defender-application-control-deployment-guide).
You should now have one or more App Control policies converted into binary form. If not, follow the steps described in [Deploying App Control for Business policies](appcontrol-deployment-guide.md).
> [!IMPORTANT]
> Due to a known issue, you should always activate new **signed** WDAC Base policies with a reboot on systems with [**memory integrity**](../../../../hardware-security/enable-virtualization-based-protection-of-code-integrity.md) enabled. Skip all steps below that use CiTool, RefreshPolicy.exe, or WMI to initiate a policy activation. Instead, copy the policy binary to the correct system32 and EFI locations and then activate the policy with a system restart.
> Due to a known issue, you should always activate new **signed** App Control Base policies with a reboot on systems with [**memory integrity**](../../../../hardware-security/enable-virtualization-based-protection-of-code-integrity.md) enabled. Skip all steps below that use CiTool, RefreshPolicy.exe, or WMI to initiate a policy activation. Instead, copy the policy binary to the correct system32 and EFI locations and then activate the policy with a system restart.
>
> This issue does not affect updates to signed Base policies that are already active on the system, deployment of unsigned policies, or deployment of supplemental policies (signed or unsigned). It also does not affect deployments to systems that are not running memory integrity.
## Deploying policies for Windows 11 22H2 and above
You can use the inbox [CiTool](/windows/security/threat-protection/windows-defender-application-control/operations/citool-commands) to apply policies on Windows 11 22H2 with the following commands. Be sure to replace **&lt;Path to policy binary file to deploy&gt;** in the following example with the actual path to your WDAC policy binary file.
You can use the inbox [CiTool](../operations/citool-commands.md) to apply policies on Windows 11 22H2 with the following commands. Be sure to replace **&lt;Path to policy binary file to deploy&gt;** in the following example with the actual path to your App Control policy binary file.
```powershell
# Policy binary files should be named as {GUID}.cip for multiple policy format files (where {GUID} = <PolicyId> from the Policy XML)
@ -33,7 +32,7 @@ CiTool --update-policy $PolicyBinary [-json]
## Deploying policies for Windows 11, Windows 10 version 1903 and above, and Windows Server 2022 and above
To use this procedure, download and distribute the [WDAC policy refresh tool](https://aka.ms/refreshpolicy) to all managed endpoints. Ensure your WDAC policies allow the WDAC policy refresh tool or use a managed installer to distribute the tool.
To use this procedure, download and distribute the [App Control policy refresh tool](https://aka.ms/refreshpolicy) to all managed endpoints. Ensure your App Control policies allow the App Control policy refresh tool or use a managed installer to distribute the tool.
1. Initialize the variables to be used by the script.
@ -44,14 +43,14 @@ To use this procedure, download and distribute the [WDAC policy refresh tool](ht
$RefreshPolicyTool = "<Path where RefreshPolicy.exe can be found from managed endpoints>"
```
2. Copy Windows Defender Application Control (WDAC) policy binary to the destination folder.
2. Copy App Control for Business policy binary to the destination folder.
```powershell
Copy-Item -Path $PolicyBinary -Destination $DestinationFolder -Force
```
3. Repeat steps 1-2 as appropriate to deploy more WDAC policies.
4. Run RefreshPolicy.exe to activate and refresh all WDAC policies on the managed endpoint.
3. Repeat steps 1-2 as appropriate to deploy more App Control policies.
4. Run RefreshPolicy.exe to activate and refresh all App Control policies on the managed endpoint.
```powershell
& $RefreshPolicyTool
@ -69,13 +68,13 @@ Use WMI to apply policies on all other versions of Windows and Windows Server.
$DestinationBinary = $env:windir+"\System32\CodeIntegrity\SiPolicy.p7b"
```
2. Copy Windows Defender Application Control (WDAC) policy binary to the destination.
2. Copy App Control for Business policy binary to the destination.
```powershell
Copy-Item -Path $PolicyBinary -Destination $DestinationBinary -Force
```
3. Refresh and activate WDAC policy using WMI
3. Refresh and activate App Control policy using WMI
```powershell
Invoke-CimMethod -Namespace root\Microsoft\Windows\CI -ClassName PS_UpdateAndCompareCIPolicy -MethodName Update -Arguments @{FilePath = $DestinationBinary}
@ -83,7 +82,7 @@ Use WMI to apply policies on all other versions of Windows and Windows Server.
## Deploying signed policies
If you're using [signed WDAC policies](/windows/security/threat-protection/windows-defender-application-control/use-signed-policies-to-protect-windows-defender-application-control-against-tampering), the policies must be deployed into your device's EFI partition in addition to the locations outlined in the earlier sections. Unsigned WDAC policies don't need to be present in the EFI partition. <!-- Deploying your policy via [Microsoft Intune](/windows/security/threat-protection/windows-defender-application-control/deploy-windows-defender-application-control-policies-using-intune) or the Application Control CSP will handle this step automatically. -->
If you're using [signed App Control policies](use-signed-policies-to-protect-appcontrol-against-tampering.md), the policies must be deployed into your device's EFI partition in addition to the locations outlined in the earlier sections. Unsigned App Control policies don't need to be present in the EFI partition.
1. Mount the EFI volume and make the directory, if it doesn't exist, in an elevated PowerShell prompt:

25
windows/security/application-security/application-control/app-control-for-business/deployment/deploy-catalog-files-to-support-appcontrol.md
View File

@ -1,21 +1,20 @@
---
title: Deploy catalog files to support Windows Defender Application Control
description: Catalog files simplify running unsigned applications in the presence of a Windows Defender Application Control (WDAC) policy.
title: Deploy catalog files to support App Control for Business
description: Catalog files simplify running unsigned applications in the presence of a App Control for Business policy.
ms.localizationpriority: medium
ms.topic: how-to
ms.date: 11/30/2022
---
# Deploy catalog files to support Windows Defender Application Control
# Deploy catalog files to support App Control for Business
> [!NOTE]
> Some capabilities of Windows Defender Application Control are only available on specific Windows versions. For more information, see [Windows Defender Application Control feature availability](../feature-availability.md).
[!INCLUDE [Feature availability note](../includes/feature-availability-note.md)]
*Catalog files* can be important in your deployment of Windows Defender Application Control (WDAC) if you have unsigned line-of-business (LOB) applications for which the process of signing is difficult. You can also use catalog files to add your own signature to apps you get from independent software vendors (ISV) when you don't want to trust all code signed by that ISV. In this way, catalog files provide a convenient way for you to "bless" apps for use in your WDAC-managed environment. And, you can create catalog files for existing apps without requiring access to the original source code or needing any expensive repackaging.
*Catalog files* can be important in your deployment of App Control for Business if you have unsigned line-of-business (LOB) applications for which the process of signing is difficult. You can also use catalog files to add your own signature to apps you get from independent software vendors (ISV) when you don't want to trust all code signed by that ISV. In this way, catalog files provide a convenient way for you to "bless" apps for use in your App Control-managed environment. And, you can create catalog files for existing apps without requiring access to the original source code or needing any expensive repackaging.
You need to [obtain a code signing certificate for your own use](use-code-signing-for-better-control-and-protection.md#obtain-code-signing-certificates-for-your-own-use) and use it to sign the catalog file. Then, distribute the signed catalog file using your preferred content deployment mechanism.
Finally, add a signer rule to your WDAC policy for your signing certificate. Then, any apps covered by your signed catalog files are able to run, even if the apps were previously unsigned. With this foundation, you can more easily build a WDAC policy that blocks all unsigned code, because most malware is unsigned.
Finally, add a signer rule to your App Control policy for your signing certificate. Then, any apps covered by your signed catalog files are able to run, even if the apps were previously unsigned. With this foundation, you can more easily build a App Control policy that blocks all unsigned code, because most malware is unsigned.
## Create catalog files using Package Inspector
@ -34,7 +33,7 @@ To create a catalog file for an existing app, you can use a tool called **Packag
$PolicyBinary = $env:USERPROFILE+"\Desktop\"+$PolicyId.substring(11)+".cip"
```
Then apply the policy as described in [Deploy Windows Defender Application Control policies with script](deploy-appcontrol-policies-with-script.md).
Then apply the policy as described in [Deploy App Control for Business policies with script](deploy-appcontrol-policies-with-script.md).
2. Start Package Inspector to monitor file creation on a **local drive** where you install the app, for example, drive C:
@ -123,14 +122,14 @@ For testing purposes, you can manually copy signed catalog files to this folder.
To simplify the management of catalog files, you can use group policy preferences to deploy catalog files to the appropriate computers in your organization.
The following process walks you through the deployment of a signed catalog file called **LOBApp-Contoso.cat** to a test OU called **WDAC Enabled PCs** with a GPO called **Contoso Catalog File GPO Test**.
The following process walks you through the deployment of a signed catalog file called **LOBApp-Contoso.cat** to a test OU called **App Control Enabled PCs** with a GPO called **Contoso Catalog File GPO Test**.
1. From either a domain controller or a client computer that has Remote Server Administration Tools installed, open the Group Policy Management Console by running **GPMC.MSC** or by searching for Group Policy Management.
2. Create a new GPO: right-click an OU, for example, the **WDAC Enabled PCs OU**, and then select **Create a GPO in this domain, and Link it here**, as shown in Figure 2.
2. Create a new GPO: right-click an OU, for example, the **App Control Enabled PCs OU**, and then select **Create a GPO in this domain, and Link it here**, as shown in Figure 2.
> [!NOTE]
> You can use any OU name. Also, security group filtering is an option when you consider different ways of combining WDAC policies.
> You can use any OU name. Also, security group filtering is an option when you consider different ways of combining App Control policies.
![Group Policy Management, create a GPO.](../images/dg-fig13-createnewgpo.png)
@ -299,9 +298,9 @@ At the time of the next software inventory cycle, when the targeted clients rece
> [!NOTE]
> If nothing is displayed in this view, navigate to Software\\Last Software Scan in Resource Explorer to verify that the client has recently completed a software inventory scan.
## Allow apps signed by your catalog signing certificate in your WDAC policy
## Allow apps signed by your catalog signing certificate in your App Control policy
Now that you have your signed catalog file, you can add a signer rule to your policy that allows anything signed with that certificate. If you haven't yet created a WDAC policy, see the [Windows Defender Application Control design guide](../design/appcontrol-design-guide.md).
Now that you have your signed catalog file, you can add a signer rule to your policy that allows anything signed with that certificate. If you haven't yet created a App Control policy, see the [App Control for Business design guide](../design/appcontrol-design-guide.md).
On a computer where the signed catalog file has been deployed, you can use [New-CiPolicyRule](/powershell/module/configci/new-cipolicyrule) to create a signer rule from any file included in that catalog. Then use [Merge-CiPolicy](/powershell/module/configci/merge-cipolicy) to add the rule to your policy XML. Be sure to replace the path values in the following sample:

55
windows/security/application-security/application-control/app-control-for-business/deployment/disable-appcontrol-policies.md
View File

@ -1,24 +1,23 @@
---
title: Remove Windows Defender Application Control policies
description: Learn how to disable both signed and unsigned Windows Defender Application Control policies, within Windows and within the BIOS.
title: Remove App Control for Business policies
description: Learn how to disable both signed and unsigned App Control for Business policies, within Windows and within the BIOS.
ms.localizationpriority: medium
ms.date: 11/04/2022
ms.topic: how-to
---
# Remove Windows Defender Application Control (WDAC) policies
# Remove App Control for Business policies
>[!NOTE]
>Some capabilities of Windows Defender Application Control (WDAC) are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](../feature-availability.md).
[!INCLUDE [Feature availability note](../includes/feature-availability-note.md)]
## Removing WDAC policies
## Removing App Control policies
There may come a time when you want to remove one or more WDAC policies, or remove all WDAC policies you've deployed. This article describes the various ways to remove WDAC policies.
There may come a time when you want to remove one or more App Control policies, or remove all App Control policies you've deployed. This article describes the various ways to remove App Control policies.
> [!IMPORTANT]
> **Signed WDAC policy**
> **Signed App Control policy**
>
> If the policy you are trying to remove is a signed WDAC policy, you must first deploy a signed replacement policy that includes option **6 Enabled:Unsigned System Integrity Policy**.
> If the policy you are trying to remove is a signed App Control policy, you must first deploy a signed replacement policy that includes option **6 Enabled:Unsigned System Integrity Policy**.
>
> The replacement policy must have the same PolicyId as the one it's replacing and a version that's equal to or greater than the existing policy. The replacement policy must also include \<UpdatePolicySigners\>.
>
@ -33,15 +32,15 @@ To make a policy effectively inactive before removing it, you can first replace
1. Replace the policy rules with "Allow *" rules;
2. Set option **3 Enabled:Audit Mode** to change the policy to audit mode only;
3. Set option **11 Disabled:Script Enforcement**;
4. Allow all COM objects. See [Allow COM object registration in a WDAC policy](/windows/security/threat-protection/windows-defender-application-control/allow-com-object-registration-in-windows-defender-application-control-policy#examples);
4. Allow all COM objects. See [Allow COM object registration in a App Control policy](../design/allow-com-object-registration-in-appcontrol-policy.md#examples);
5. If applicable, remove option **0 Enabled:UMCI** to convert the policy to kernel mode only.
> [!IMPORTANT]
> After you remove a policy, restart the computer for it to take effect. You can't remove WDAC policies without restarting the device.
> After you remove a policy, restart the computer for it to take effect. You can't remove App Control policies without restarting the device.
### Remove WDAC policies using CiTool.exe
### Remove App Control policies using CiTool.exe
Beginning with the Windows 11 2022 Update, you can remove WDAC policies using CiTool.exe. From an elevated command window, run the following command. Be sure to replace the text *PolicyId GUID* with the actual PolicyId of the WDAC policy you want to remove:
Beginning with the Windows 11 2022 Update, you can remove App Control policies using CiTool.exe. From an elevated command window, run the following command. Be sure to replace the text *PolicyId GUID* with the actual PolicyId of the App Control policy you want to remove:
```powershell
CiTool.exe -rp "{PolicyId GUID}" -json
@ -49,13 +48,13 @@ Beginning with the Windows 11 2022 Update, you can remove WDAC policies using Ci
Then restart the computer.
### Remove WDAC policies using MDM solutions like Intune
### Remove App Control policies using MDM solutions like Intune
You can use a Mobile Device Management (MDM) solution, like Microsoft Intune, to remove WDAC policies from client machines using the [ApplicationControl CSP](/windows/client-management/mdm/applicationcontrol-csp).
You can use a Mobile Device Management (MDM) solution, like Microsoft Intune, to remove App Control policies from client machines using the [ApplicationControl CSP](/windows/client-management/mdm/applicationcontrol-csp).
<!-- Waiting for information from Intune team on specific steps...
The steps to use Intune's custom OMA-URI functionality to remove a WDAC policy are:
The steps to use Intune's custom OMA-URI functionality to remove a App Control policy are:
1. Open the Microsoft Intune portal and [create a profile with custom settings](/mem/intune/configuration/custom-settings-windows-10).
@ -65,7 +64,7 @@ The steps to use Intune's custom OMA-URI functionality to remove a WDAC policy a
- **Certificate file**: upload your binary format policy file. You don't need to upload a Base64 file, as Intune will convert the uploaded .bin file to Base64 on your behalf.
> [!div class="mx-imgBorder"]
> ![Configure custom WDAC.](../images/appcontrol-intune-custom-oma-uri.png)
> ![Configure custom App Control.](../images/appcontrol-intune-custom-oma-uri.png)
> [!NOTE]
> For the _Policy GUID_ value, do not include the curly brackets.
@ -75,24 +74,24 @@ Consult your MDM solution provider for specific information on using the Applica
Then restart the computer.
### Remove WDAC policies using script
### Remove App Control policies using script
To remove WDAC policies using script, your script must delete the policy file(s) from the computer. For **multiple policy format (1903+) WDAC policies**, look for the policy files in the following locations. Be sure to replace the *PolicyId GUID* with the actual PolicyId of the WDAC policy you want to remove.
To remove App Control policies using script, your script must delete the policy file(s) from the computer. For **multiple policy format (1903+) App Control policies**, look for the policy files in the following locations. Be sure to replace the *PolicyId GUID* with the actual PolicyId of the App Control policy you want to remove.
- &lt;EFI System Partition&gt;\\Microsoft\\Boot\\CiPolicies\Active\\*\{PolicyId GUID\}*.cip
- &lt;OS Volume&gt;\\Windows\\System32\\CodeIntegrity\\CiPolicies\Active\\*\{PolicyId GUID\}*.cip
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 App Control policies**, in addition to the two locations above, 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
Then restart the computer.
#### Sample script to delete a single WDAC policy
#### Sample script to delete a single App Control policy
```powershell
# Set PolicyId GUID to the PolicyId from your WDAC policy XML
# Set PolicyId GUID to the PolicyId from your App Control policy XML
$PolicyId = "{PolicyId GUID}"
# Initialize variables
@ -138,17 +137,17 @@ mountvol $MountPoint /D
```
> [!NOTE]
> You must run the script as administrator to remove WDAC policies on your computer.
> You must run the script as administrator to remove App Control policies on your computer.
## Remove WDAC policies causing boot stop failures
## Remove App Control policies causing boot stop failures
A WDAC policy that blocks boot critical drivers can cause a boot stop failure (BSOD) to occur, though this can be mitigated by setting option **10 Enabled:Boot Audit On Failure** in your policies. Additionally, signed WDAC policies protect the policy from administrative manipulation and malware that has gained administrative-level access to the system. For this reason, signed WDAC policies are intentionally more difficult to remove than unsigned policies even for administrators. Tampering with or removing a signed WDAC policy will cause a BSOD to occur.
A App Control policy that blocks boot critical drivers can cause a boot stop failure (BSOD) to occur, though this can be mitigated by setting option **10 Enabled:Boot Audit On Failure** in your policies. Additionally, signed App Control policies protect the policy from administrative manipulation and malware that has gained administrative-level access to the system. For this reason, signed App Control policies are intentionally more difficult to remove than unsigned policies even for administrators. Tampering with or removing a signed App Control policy will cause a BSOD to occur.
To remove a policy that is causing boot stop failures:
1. If the policy is a **signed** WDAC policy, turn off Secure Boot from your [UEFI BIOS menu](/windows-hardware/manufacture/desktop/boot-to-uefi-mode-or-legacy-bios-mode). For help with locating where to turn off Secure Boot within your BIOS menu, consult with your original equipment manufacturer (OEM).
2. Access the Advanced Boot Options menu on your computer and choose the option to **Disable Driver Signature Enforcement**. For instructions on accessing the Advanced Boot Options menu during startup, consult with your OEM. This option will suspend all code integrity checks, including WDAC, for a single boot session.
3. Start Windows normally and sign in. Then, [remove WDAC policies using script](#remove-wdac-policies-using-script).
1. If the policy is a **signed** App Control policy, turn off Secure Boot from your [UEFI BIOS menu](/windows-hardware/manufacture/desktop/boot-to-uefi-mode-or-legacy-bios-mode). For help with locating where to turn off Secure Boot within your BIOS menu, consult with your original equipment manufacturer (OEM).
2. Access the Advanced Boot Options menu on your computer and choose the option to **Disable Driver Signature Enforcement**. For instructions on accessing the Advanced Boot Options menu during startup, consult with your OEM. This option will suspend all code integrity checks, including App Control, for a single boot session.
3. Start Windows normally and sign in. Then, [remove App Control policies using script](#remove-app-control-policies-using-script).
4. If you turned off Secure Boot in step 1 above and your drive is protected by BitLocker, [suspend BitLocker protection](/troubleshoot/windows-client/windows-security/suspend-bitlocker-protection-non-microsoft-updates) then turn on Secure Boot from your UEFI BIOS menu.
5. Restart the computer.

31
windows/security/application-security/application-control/app-control-for-business/deployment/enforce-appcontrol-policies.md
View File

@ -1,29 +1,28 @@
---
title: Enforce Windows Defender Application Control (WDAC) policies
description: Learn how to switch a WDAC policy from audit to enforced mode.
title: Enforce App Control for Business policies
description: Learn how to switch a App Control policy from audit to enforced mode.
ms.manager: jsuther
ms.date: 04/22/2021
ms.topic: how-to
ms.localizationpriority: medium
---
# Enforce Windows Defender Application Control (WDAC) policies
# Enforce App Control for Business policies
>[!NOTE]
>Some capabilities of Windows Defender Application Control (WDAC) are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](../feature-availability.md).
[!INCLUDE [Feature availability note](../includes/feature-availability-note.md)]
You should now have one or more Windows Defender Application Control policies broadly deployed in audit mode. You have analyzed events collected from the devices with those policies and you're ready to enforce. Use this procedure to prepare and deploy your WDAC policies in enforcement mode.
You should now have one or more App Control for Business policies broadly deployed in audit mode. You have analyzed events collected from the devices with those policies and you're ready to enforce. Use this procedure to prepare and deploy your App Control policies in enforcement mode.
> [!NOTE]
> Some of the steps described in this article only apply to Windows 10 version 1903 and above, or Windows 11. When using this topic to plan your own organization's WDAC policies, consider whether your managed clients can use all or some of these features. Evaluate the impact for any features that may be unavailable on your clients running earlier versions of Windows 10 and Windows Server. You may need to adapt this guidance to meet your specific organization's needs.
> Some of the steps described in this article only apply to Windows 10 version 1903 and above, or Windows 11. When using this topic to plan your own organization's App Control policies, consider whether your managed clients can use all or some of these features. Evaluate the impact for any features that may be unavailable on your clients running earlier versions of Windows 10 and Windows Server. You may need to adapt this guidance to meet your specific organization's needs.
## Convert WDAC **base** policy from audit to enforced
## Convert App Control **base** policy from audit to enforced
As described in [common Windows Defender Application Control deployment scenarios](../design/common-appcontrol-use-cases.md), we'll use the example of **Lamna Healthcare Company (Lamna)** to illustrate this scenario. Lamna is attempting to adopt stronger application policies, including the use of application control to prevent unwanted or unauthorized applications from running on their managed devices.
As described in [common App Control for Business deployment scenarios](../design/common-appcontrol-use-cases.md), we'll use the example of **Lamna Healthcare Company (Lamna)** to illustrate this scenario. Lamna is attempting to adopt stronger application policies, including the use of application control to prevent unwanted or unauthorized applications from running on their managed devices.
**Alice Pena** is the IT team lead responsible for Lamna's WDAC rollout.
**Alice Pena** is the IT team lead responsible for Lamna's App Control rollout.
Alice previously created and deployed a policy for the organization's [fully managed devices](../design/create-appcontrol-policy-for-fully-managed-devices.md). They updated the policy based on audit event data as described in [Use audit events to create WDAC policy rules](audit-appcontrol-policies.md) and redeployed it. All remaining audit events are as expected and Alice is ready to switch to enforcement mode.
Alice previously created and deployed a policy for the organization's [fully managed devices](../design/create-appcontrol-policy-for-fully-managed-devices.md). They updated the policy based on audit event data as described in [Use audit events to create App Control policy rules](audit-appcontrol-policies.md) and redeployed it. All remaining audit events are as expected and Alice is ready to switch to enforcement mode.
1. Initialize the variables that will be used and create the enforced policy by copying the audit version.
@ -34,14 +33,14 @@ Alice previously created and deployed a policy for the organization's [fully man
cp $AuditPolicyXML $EnforcedPolicyXML
```
2. Use [Set-CIPolicyIdInfo](/powershell/module/configci/set-cipolicyidinfo) to give the new policy a unique ID, and descriptive name. Changing the ID and name lets you deploy the enforced policy side by side with the audit policy. Do this step if you plan to harden your WDAC policy over time. If you prefer to replace the audit policy in-place, you can skip this step.
2. Use [Set-CIPolicyIdInfo](/powershell/module/configci/set-cipolicyidinfo) to give the new policy a unique ID, and descriptive name. Changing the ID and name lets you deploy the enforced policy side by side with the audit policy. Do this step if you plan to harden your App Control policy over time. If you prefer to replace the audit policy in-place, you can skip this step.
```powershell
$EnforcedPolicyID = Set-CIPolicyIdInfo -FilePath $EnforcedPolicyXML -PolicyName $EnforcedPolicyName -ResetPolicyID
$EnforcedPolicyID = $EnforcedPolicyID.Substring(11)
```
3. *[Optionally]* Use [Set-RuleOption](/powershell/module/configci/set-ruleoption) to enable rule options 9 ("Advanced Boot Options Menu") and 10 ("Boot Audit on Failure"). Option 9 allows users to disable WDAC enforcement for a single boot session from a pre-boot menu. Option 10 instructs Windows to switch the policy from enforcement to audit only if a boot critical kernel-mode driver is blocked. We strongly recommend these options when deploying a new enforced policy to your first deployment ring. Then, if no issues are found, you can remove the options and restart your deployment.
3. *[Optionally]* Use [Set-RuleOption](/powershell/module/configci/set-ruleoption) to enable rule options 9 ("Advanced Boot Options Menu") and 10 ("Boot Audit on Failure"). Option 9 allows users to disable App Control enforcement for a single boot session from a pre-boot menu. Option 10 instructs Windows to switch the policy from enforcement to audit only if a boot critical kernel-mode driver is blocked. We strongly recommend these options when deploying a new enforced policy to your first deployment ring. Then, if no issues are found, you can remove the options and restart your deployment.
```powershell
Set-RuleOption -FilePath $EnforcedPolicyXML -Option 9
@ -54,7 +53,7 @@ Alice previously created and deployed a policy for the organization's [fully man
Set-RuleOption -FilePath $EnforcedPolicyXML -Option 3 -Delete
```
5. Use [ConvertFrom-CIPolicy](/powershell/module/configci/convertfrom-cipolicy) to convert the new WDAC policy to binary:
5. Use [ConvertFrom-CIPolicy](/powershell/module/configci/convertfrom-cipolicy) to convert the new App Control policy to binary:
> [!NOTE]
> If you did not use -ResetPolicyID in Step 2 above, then you must replace $EnforcedPolicyID in the following command with the *PolicyID* attribute found in your base policy XML.
@ -86,7 +85,7 @@ Since the enforced policy was given a unique PolicyID in the previous procedure,
> [!NOTE]
> If Set-CIPolicyIdInfo does not output the new PolicyID value on your Windows 10 version, you will need to obtain the *PolicyId* value from the XML directly.
3. Use [ConvertFrom-CIPolicy](/powershell/module/configci/convertfrom-cipolicy) to convert the new Windows Defender Application Control supplemental policy to binary:
3. Use [ConvertFrom-CIPolicy](/powershell/module/configci/convertfrom-cipolicy) to convert the new App Control for Business supplemental policy to binary:
```powershell
$EnforcedSuppPolicyBinary = $env:USERPROFILE+"\Desktop\"+$SupplementalPolicyName+"_"+$SupplementalPolicyID+".xml"
@ -96,4 +95,4 @@ Since the enforced policy was given a unique PolicyID in the previous procedure,
## Deploy your enforced policy and supplemental policies
Now that your base policy is in enforced mode, you can begin to deploy it to your managed endpoints. For information about deploying policies, see [Deploying Windows Defender Application Control (WDAC) policies](appcontrol-deployment-guide.md).
Now that your base policy is in enforced mode, you can begin to deploy it to your managed endpoints. For information about deploying policies, see [Deploying App Control for Business policies](appcontrol-deployment-guide.md).

39
windows/security/application-security/application-control/app-control-for-business/deployment/merge-appcontrol-policies.md
View File

@ -1,25 +1,24 @@
---
title: Merge Windows Defender Application Control policies (WDAC)
description: Learn how to merge WDAC policies as part of your policy lifecycle management.
title: Merge App Control for Business policies (App Control)
description: Learn how to merge App Control policies as part of your policy lifecycle management.
ms.manager: jsuther
ms.date: 04/22/2021
ms.topic: how-to
ms.localizationpriority: medium
---
# Merge Windows Defender Application Control (WDAC) policies
# Merge App Control for Business policies
>[!NOTE]
>Some capabilities of Windows Defender Application Control (WDAC) are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](../feature-availability.md).
[!INCLUDE [Feature availability note](../includes/feature-availability-note.md)]
This article shows how to merge multiple policy XML files together and how to merge rules directly into a policy. Windows Defender Application Control deployments often include a few base policies and optional supplemental policies for specific use cases.
This article shows how to merge multiple policy XML files together and how to merge rules directly into a policy. App Control for Business deployments often include a few base policies and optional supplemental policies for specific use cases.
> [!NOTE]
> Prior to Windows version 1903, including Windows Server 2019 and earlier, only one Windows Defender Application Control policy can be active on a system at a time. If you need to use WDAC on systems running these earlier versions of Windows, you must merge all policies before deploying.
> Prior to Windows version 1903, including Windows Server 2019 and earlier, only one App Control for Business policy can be active on a system at a time. If you need to use App Control on systems running these earlier versions of Windows, you must merge all policies before deploying.
## Merge multiple WDAC policy XML files together
## Merge multiple App Control policy XML files together
There are many scenarios where you may want to merge two or more policy files together. For example, if you [use audit events to create Windows Defender Application Control policy rules](audit-appcontrol-policies.md), you can merge those rules with your existing WDAC base policy. To merge the two WDAC policies referenced in that article, complete the following steps in an elevated Windows PowerShell session.
There are many scenarios where you may want to merge two or more policy files together. For example, if you [use audit events to create App Control for Business policy rules](audit-appcontrol-policies.md), you can merge those rules with your existing App Control base policy. To merge the two App Control policies referenced in that article, complete the following steps in an elevated Windows PowerShell session.
1. Initialize the variables that will be used:
@ -30,7 +29,7 @@ There are many scenarios where you may want to merge two or more policy files to
$MergedPolicy=$env:userprofile+"\Desktop\"+$PolicyName+"_Merged.xml"
```
2. Use [Merge-CIPolicy](/powershell/module/configci/merge-cipolicy) to merge two policies and create a new Windows Defender Application Control policy:
2. Use [Merge-CIPolicy](/powershell/module/configci/merge-cipolicy) to merge two policies and create a new App Control for Business policy:
```powershell
Merge-CIPolicy -PolicyPaths $LamnaPolicy,$EventsPolicy -OutputFilePath $MergedPolicy
@ -39,16 +38,16 @@ There are many scenarios where you may want to merge two or more policy files to
> [!NOTE]
> You can merge additional policies with the Merge-CIPolicy step above by adding them to the -PolicyPaths parameter separated by commas. The new policy file specified by -OutputFilePath will have the Policy information from the first policy in the list. For example, in the above example, the $MergedPolicy will inherit the policy type, ID, name, and version information from $LamnaPolicy. To change any of those values, use [Set-CIPolicyIdInfo](/powershell/module/configci/set-cipolicyidinfo) and [Set-CIPolicyVersion](/powershell/module/configci/set-cipolicyversion).
## Merge WDAC rules directly into a policy XML
## Merge App Control rules directly into a policy XML
Besides merging multiple policy XML files, you can also merge rules created with the New-CIPolicyRule cmdlet directly into an existing WDAC policy XML file. Directly merging rules is a convenient way to update your policy without creating extra policy XML files. For example, to add rules that allow the WDAC Wizard and the WDAC RefreshPolicy.exe tool, follow these steps:
Besides merging multiple policy XML files, you can also merge rules created with the New-CIPolicyRule cmdlet directly into an existing App Control policy XML file. Directly merging rules is a convenient way to update your policy without creating extra policy XML files. For example, to add rules that allow the App Control Wizard and the App Control RefreshPolicy.exe tool, follow these steps:
1. Install the [WDAC Wizard](../design/appcontrol-wizard.md) packaged MSIX app.
1. Install the [App Control Wizard](../design/appcontrol-wizard.md) packaged MSIX app.
2. Download the [Refresh Policy tool](https://aka.ms/refreshpolicy) for your processor architecture and save it to your desktop as RefreshPolicy.exe.
3. From a PowerShell session, run the following commands to create packaged app allow rules for the WDAC Wizard:
3. From a PowerShell session, run the following commands to create packaged app allow rules for the App Control Wizard:
```powershell
$PackageInfo = Get-AppxPackage -Name Microsoft.WDAC.WDACWizard
$PackageInfo = Get-AppxPackage -Name Microsoft.App Control.WDACWizard
$Rules = New-CIPolicyRule -Package $PackageInfo
```
@ -68,16 +67,16 @@ Besides merging multiple policy XML files, you can also merge rules created with
Now that you have your new, merged policy, you can convert and deploy the policy binary to your managed endpoints.
1. Use [ConvertFrom-CIPolicy](/powershell/module/configci/convertfrom-cipolicy) to convert the WDAC policy to a binary format:
1. Use [ConvertFrom-CIPolicy](/powershell/module/configci/convertfrom-cipolicy) to convert the App Control policy to a binary format:
```powershell
$WDACPolicyBin=$env:userprofile+"\Desktop\"+$PolicyName+"_{InsertPolicyID}.bin"
ConvertFrom-CIPolicy -XMLFilePath $MergedPolicy -BinaryFilePath $WDACPolicyBin
$AppControlPolicyBin=$env:userprofile+"\Desktop\"+$PolicyName+"_{InsertPolicyID}.bin"
ConvertFrom-CIPolicy -XMLFilePath $MergedPolicy -BinaryFilePath $AppControlPolicyBin
```
> [!NOTE]
> In the sample commands above, for policies targeting Windows 10 version 1903+ or Windows 11, replace the string "{InsertPolicyID}" with the actual PolicyID GUID (including braces **{ }**) found in your policy XML file. For Windows 10 versions prior to 1903, use the name SiPolicy.p7b for the binary file name.
2. Upload your merged policy XML and the associated binary to the source control solution you are using for your Windows Defender Application Control policies. such as [GitHub](https://github.com/) or a document management solution such as [Office 365 SharePoint](https://products.office.com/sharepoint/collaboration).
2. Upload your merged policy XML and the associated binary to the source control solution you are using for your App Control for Business policies. such as [GitHub](https://github.com/) or a document management solution such as [Office 365 SharePoint](https://products.office.com/sharepoint/collaboration).
3. Deploy the merged policy using your preferred deployment solution. See [Deploying Windows Defender Application Control (WDAC) policies](appcontrol-deployment-guide.md)
3. Deploy the merged policy using your preferred deployment solution. See [Deploying App Control for Business policies](appcontrol-deployment-guide.md)

21
windows/security/application-security/application-control/app-control-for-business/deployment/use-code-signing-for-better-control-and-protection.md
View File

@ -1,19 +1,18 @@
---
title: Use code signing for added control and protection with WDAC
description: Code signing can be used to better control Win32 app authorization and add protection for your Windows Defender Application Control (WDAC) policies.
title: Use code signing for added control and protection with App Control
description: Code signing can be used to better control Win32 app authorization and add protection for your App Control for Business policies.
ms.localizationpriority: medium
ms.topic: conceptual
ms.date: 11/29/2022
---
# Use code signing for added control and protection with Windows Defender Application Control
# Use code signing for added control and protection with App Control for Business
> [!NOTE]
> Some capabilities of Windows Defender Application Control are only available on specific Windows versions. For more information, see [Windows Defender Application Control feature availability](../feature-availability.md).
[!INCLUDE [Feature availability note](../includes/feature-availability-note.md)]
## What is code signing and why is it important?
Code signing provides some important benefits to application security features like Windows Defender Application Control (WDAC). First, it allows the system to cryptographically verify that a file hasn't been tampered with since it was signed and before any code is allowed to run. Second, it associates the file with a real-world identity, such as a company or an individual developer. This identity can make your policy trust decisions easier and allows for real-world consequences when code signing is abused or used maliciously. Although Windows doesn't require software developers to digitally sign their code, most major independent software vendors (ISV) do use code signing for much of their code. And metadata that a developer includes in a file's resource header (.RSRC), such as OriginalFileName or ProductName, can be combined with the file's signing certificate to limit the scope of trust decisions. For example, instead of allowing everything signed by Microsoft, you can choose to allow only files signed by Microsoft where ProductName is "Microsoft Teams". Then use other rules to authorize any other files that need to run.
Code signing provides some important benefits to application security features like App Control for Business. First, it allows the system to cryptographically verify that a file hasn't been tampered with since it was signed and before any code is allowed to run. Second, it associates the file with a real-world identity, such as a company or an individual developer. This identity can make your policy trust decisions easier and allows for real-world consequences when code signing is abused or used maliciously. Although Windows doesn't require software developers to digitally sign their code, most major independent software vendors (ISV) do use code signing for much of their code. And metadata that a developer includes in a file's resource header (.RSRC), such as OriginalFileName or ProductName, can be combined with the file's signing certificate to limit the scope of trust decisions. For example, instead of allowing everything signed by Microsoft, you can choose to allow only files signed by Microsoft where ProductName is "Microsoft Teams". Then use other rules to authorize any other files that need to run.
Wherever possible, you should require all app binaries and scripts are code signed as part of your app acceptance criteria. And, you should ensure that internal line-of-business (LOB) app developers have access to code signing certificates controlled by your organization.
@ -26,13 +25,13 @@ You can use catalog files to easily add a signature to an existing application w
> [!NOTE]
> Since catalogs identify the files they sign by hash, any change to the file may invalidate its signature. You will need to deploy updated catalog signatures any time the application is updated. Integrating code signing with your app development or app deployment processes is generally the best approach. Be aware of self-updating apps, as their app binaries may change without your knowledge.
To learn how to create and manage catalog files for existing apps, see [Deploy catalog files to support Windows Defender Application Control](deploy-catalog-files-to-support-appcontrol.md).
To learn how to create and manage catalog files for existing apps, see [Deploy catalog files to support App Control for Business](deploy-catalog-files-to-support-appcontrol.md).
## Signed WDAC policies
## Signed App Control policies
While a WDAC policy begins as an XML document, it's then converted into a binary-encoded file before deployment. This binary version of your policy can be code signed like any other application binary, offering many of the same benefits as described above for signed code. Additionally, signed policies are treated specially by WDAC and help protect against tampering or removal of a policy even by an admin user.
While a App Control policy begins as an XML document, it's then converted into a binary-encoded file before deployment. This binary version of your policy can be code signed like any other application binary, offering many of the same benefits as described above for signed code. Additionally, signed policies are treated specially by App Control and help protect against tampering or removal of a policy even by an admin user.
For more information on using signed policies, see [Use signed policies to protect Windows Defender Application Control against tampering](/windows/security/threat-protection/windows-defender-application-control/use-signed-policies-to-protect-windows-defender-application-control-against-tampering)
For more information on using signed policies, see [Use signed policies to protect App Control for Business against tampering](use-signed-policies-to-protect-appcontrol-against-tampering.md)
## Obtain code signing certificates for your own use
@ -40,4 +39,4 @@ Some ways to obtain code signing certificates for your own use, include:
- Use Microsoft's [Trusted Signing service](/azure/trusted-signing/).
- Purchase a code signing certificate from one of the [Microsoft Trusted Root Program participants](/security/trusted-root/participants-list).
- To use your own digital certificate or public key infrastructure (PKI) to issue code signing certificates, see [Optional: Create a code signing certificate for Windows Defender Application Control](create-code-signing-cert-for-appcontrol.md).
- To use your own digital certificate or public key infrastructure (PKI) to issue code signing certificates, see [Optional: Create a code signing certificate for App Control for Business](create-code-signing-cert-for-appcontrol.md).

33
windows/security/application-security/application-control/app-control-for-business/deployment/use-signed-policies-to-protect-appcontrol-against-tampering.md
View File

@ -1,17 +1,16 @@
---
title: Use signed policies to protect Windows Defender Application Control against tampering
description: Signed Windows Defender Application Control (WDAC) policies give organizations the highest level of malware protection available in Windows 10 and Windows 11.
title: Use signed policies to protect App Control for Business against tampering
description: Signed App Control for Business policies give organizations the highest level of malware protection available in Windows 10 and Windows 11.
ms.localizationpriority: medium
ms.topic: conceptual
ms.date: 11/04/2022
---
# Use signed policies to protect Windows Defender Application Control against tampering
# Use signed policies to protect App Control for Business against tampering
> [!NOTE]
> Some capabilities of Windows Defender Application Control are only available on specific Windows versions. For more information, see [Windows Defender Application Control feature availability](../feature-availability.md).
[!INCLUDE [Feature availability note](../includes/feature-availability-note.md)]
Signed Windows Defender Application Control (WDAC) policies give organizations the highest level of protection available in Windows. These policies are designed to detect administrative tampering of the policy, such as by malware running as admin, and will result in a boot failure or blue screen. With this goal in mind, it's much more difficult to remove signed WDAC policies. SecureBoot must be enabled in order to provide this protection for signed WDAC policies.
Signed App Control for Business policies give organizations the highest level of protection available in Windows. These policies are designed to detect administrative tampering of the policy, such as by malware running as admin, and will result in a boot failure or blue screen. With this goal in mind, it's much more difficult to remove signed App Control policies. SecureBoot must be enabled in order to provide this protection for signed App Control policies.
If you don't currently have a code signing certificate you can use to sign your policies, see [Obtain code signing certificates for your own use](use-code-signing-for-better-control-and-protection.md#obtain-code-signing-certificates-for-your-own-use).
@ -22,12 +21,12 @@ If you don't currently have a code signing certificate you can use to sign your
> - Use RSA keys with 2K, 3K, or 4K key size only. ECDSA isn't supported.
> - You can use SHA-256, SHA-384, or SHA-512 as the digest algorithm on Windows 11, as well as Windows 10 and Windows Server 2019 and above after applying the November 2022 cumulative security update. All other devices only support SHA-256.
Before you attempt to deploy a signed policy, you should first deploy an unsigned version of the policy to uncover any issues with the policy rules. We also recommend you enable rule options **9 - Enabled:Advanced Boot Options Menu** and **10 - Enabled:Boot Audit on Failure** to leave troubleshooting options available to administrators. To ensure that a rule option is enabled, you can run a command such as `Set-RuleOption -FilePath <PathAndFilename> -Option 9`, even if you're not sure whether the option is already enabled. If so, the command has no effect. When validated and ready for enterprise deployment, you can remove these options. For more information about rule options, see [Windows Defender Application Control policy rules](../design/select-types-of-rules-to-create.md).
Before you attempt to deploy a signed policy, you should first deploy an unsigned version of the policy to uncover any issues with the policy rules. We also recommend you enable rule options **9 - Enabled:Advanced Boot Options Menu** and **10 - Enabled:Boot Audit on Failure** to leave troubleshooting options available to administrators. To ensure that a rule option is enabled, you can run a command such as `Set-RuleOption -FilePath <PathAndFilename> -Option 9`, even if you're not sure whether the option is already enabled. If so, the command has no effect. When validated and ready for enterprise deployment, you can remove these options. For more information about rule options, see [App Control for Business policy rules](../design/select-types-of-rules-to-create.md).
> [!NOTE]
> When signing a Base policy that has existing Supplemental policies, you must also switch to signed policy for all of the Supplementals. Authorize the signed supplemental policies by adding a `<SupplementalPolicySigner>` rule to the Base policy.
## Prepare your WDAC policy for signing
## Prepare your App Control policy for signing
1. Open an elevated Windows PowerShell session and initialize the variables to use:
@ -38,7 +37,7 @@ Before you attempt to deploy a signed policy, you should first deploy an unsigne
```
> [!NOTE]
> This example uses an enforced version of the WDAC policy that you created in [Create a Windows Defender Application Control policy from a reference computer](../design/create-appcontrol-policy-using-reference-computer.md) article. If you sign another policy, be sure to update the **$PolicyPath** and **$PolicyName** variables with the correct information.
> This example uses an enforced version of the App Control policy that you created in [Create a App Control for Business policy from a reference computer](../design/create-appcontrol-policy-using-reference-computer.md) article. If you sign another policy, be sure to update the **$PolicyPath** and **$PolicyName** variables with the correct information.
2. Navigate to your desktop as the working directory:
@ -46,7 +45,7 @@ Before you attempt to deploy a signed policy, you should first deploy an unsigne
cd $PolicyPath
```
3. If your WDAC policy doesn't already include an `<UpdatePolicySigner>` rule for your policy signing certificate, you must add it. At least one `<UpdatePolicySigner>` rule must exist to convert your policy XML with [ConvertFrom-CiPolicy](/powershell/module/configci/convertfrom-cipolicy).
3. If your App Control policy doesn't already include an `<UpdatePolicySigner>` rule for your policy signing certificate, you must add it. At least one `<UpdatePolicySigner>` rule must exist to convert your policy XML with [ConvertFrom-CiPolicy](/powershell/module/configci/convertfrom-cipolicy).
Use [Add-SignerRule](/powershell/module/configci/add-signerrule) and create an `<UpdatePolicySigner>` rule from your certificate file (.cer). If you purchased a code signing certificate or issued one from your own public key infrastructure (PKI), you can export the certificate file.
@ -58,7 +57,7 @@ Before you attempt to deploy a signed policy, you should first deploy an unsigne
```
> [!IMPORTANT]
> Failing to perform this step will leave you unable to modify or disable this policy and will lead to boot failure. For more information about how to disable signed policies causing boot failure, see [Remove Windows Defender Application Control policies causing boot stop failures](disable-appcontrol-policies.md#remove-wdac-policies-causing-boot-stop-failures).
> Failing to perform this step will leave you unable to modify or disable this policy and will lead to boot failure. For more information about how to disable signed policies causing boot failure, see [Remove App Control for Business policies causing boot stop failures](disable-appcontrol-policies.md#remove-app-control-policies-causing-boot-stop-failures).
4. Use [Set-RuleOption](/powershell/module/configci/set-ruleoption) to remove the unsigned policy rule option:
@ -86,11 +85,11 @@ Before you attempt to deploy a signed policy, you should first deploy an unsigne
### Policy signing with signtool.exe
If you purchased a code signing certificate or issued one from your own PKI, you can use [SignTool.exe](/windows/win32/seccrypto/signtool) to sign your WDAC policy files:
If you purchased a code signing certificate or issued one from your own PKI, you can use [SignTool.exe](/windows/win32/seccrypto/signtool) to sign your App Control policy files:
1. Import the .pfx code signing certificate into the user's personal store on the computer where the signing will happen. In this example, you use the certificate that was created in [Optional: Create a code signing certificate for Windows Defender Application Control](create-code-signing-cert-for-appcontrol.md).
1. Import the .pfx code signing certificate into the user's personal store on the computer where the signing will happen. In this example, you use the certificate that was created in [Optional: Create a code signing certificate for App Control for Business](create-code-signing-cert-for-appcontrol.md).
2. Sign the WDAC policy by using SignTool.exe:
2. Sign the App Control policy by using SignTool.exe:
```powershell
<Path to signtool.exe> sign -v -n "ContosoSigningCert" -p7 . -p7co 1.3.6.1.4.1.311.79.1 -fd sha256 $CIPolicyBin
@ -99,7 +98,7 @@ If you purchased a code signing certificate or issued one from your own PKI, you
> [!NOTE]
> The *&lt;Path to signtool.exe&gt;* variable should be the full path to the SignTool.exe utility. **ContosoSigningCert** is the subject name of the certificate that will be used to sign the policy. You should import this certificate to your personal certificate store on the computer you use to sign the policy.
When complete, the commands should output a signed policy file with a `.p7` extension. You must rename the file to `{GUID}.cip` where "{GUID}" is the &lt;PolicyId&gt; from your original WDAC policy XML.
When complete, the commands should output a signed policy file with a `.p7` extension. You must rename the file to `{GUID}.cip` where "{GUID}" is the &lt;PolicyId&gt; from your original App Control policy XML.
## Verify and deploy the signed policy
@ -117,9 +116,9 @@ $SignedCryptoMsgSyntax.Decode([System.IO.File]::ReadAllBytes($CIPolicyBin))
$SignedCryptoMsgSyntax.Certificates | Format-List -Property *
```
Thoroughly test the signed policy on a representative set of computers before proceeding with deployment. Be sure to reboot the test computers at least twice after applying the signed WDAC policy to ensure you don't encounter a boot failure.
Thoroughly test the signed policy on a representative set of computers before proceeding with deployment. Be sure to reboot the test computers at least twice after applying the signed App Control policy to ensure you don't encounter a boot failure.
Once you've verified the signed policy, deploy it using your preferred deployment method. For more information about deploying policies, see [Deploying Windows Defender Application Control policies](/windows/security/threat-protection/windows-defender-application-control/windows-defender-application-control-deployment-guide).
Once you've verified the signed policy, deploy it using your preferred deployment method. For more information about deploying policies, see [Deploying App Control for Business policies](appcontrol-deployment-guide.md).
> [!NOTE]
> Anti-tampering protection for signed policies takes effect after the first reboot once the signed policy is applied to a computer. This protection only applies to computers with UEFI Secure Boot enabled.

21
windows/security/application-security/application-control/app-control-for-business/design/allow-com-object-registration-in-appcontrol-policy.md
View File

@ -1,21 +1,20 @@
---
title: Allow COM object registration in a WDAC policy
description: You can allow COM object registration in a Windows Defender Application Control policy.
title: Allow COM object registration in a App Control policy
description: You can allow COM object registration in a App Control for Business policy.
ms.localizationpriority: medium
ms.date: 04/05/2023
ms.topic: how-to
---
# Allow COM object registration in a Windows Defender Application Control policy
# Allow COM object registration in a App Control for Business policy
> [!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).
[!INCLUDE [Feature availability note](../includes/feature-availability-note.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.
## COM object configurability in WDAC policy
## COM object configurability in App Control 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.
App Control for Business 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 App Control 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.
@ -46,7 +45,7 @@ One attribute:
### Multiple policy considerations
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.
Similar to executable files, COM objects must pass all enforced App Control policies on the system to run. For example, if the COM object under evaluation passes most but not all of your App Control 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
@ -126,10 +125,10 @@ To add this CLSID to the existing policy, follow these steps:
1. Open PowerShell ISE with Administrative privileges.
2. Copy and edit this command, then run it from the admin PowerShell ISE. Consider the policy name to be `WDAC_policy.xml`.
2. Copy and edit this command, then run it from the admin PowerShell ISE. Consider the policy name to be `AppControl_policy.xml`.
```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
PS C:\WINDOWS\system32> Set-CIPolicySetting -FilePath <path to policy xml>\AppControl_policy.xml -Key "{f8d253d9-89a4-4daa-87b6-1168369f0b21}" -Provider WSH -Value true -ValueName EnterpriseDefinedClsId -ValueType Boolean
```
Once the command has run, find the following section added to the policy XML.
@ -145,7 +144,7 @@ To add this CLSID to the existing policy, follow these steps:
### Default COM Object allowlist
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.
The table that follows describes the list of COM objects that are inherently trusted in App Control for Business. Objects in this list don't need to be allowlisted in your App Control policies. They can be denied by creating explicit deny rules in your App Control policy.
| File Name | CLSID |
|--------|-----------|

28
windows/security/application-security/application-control/app-control-for-business/design/appcontrol-and-dotnet.md
View File

@ -1,34 +1,34 @@
---
title: Windows Defender Application Control and .NET
description: Understand how WDAC and .NET work together and use Dynamic Code Security to verify code loaded by .NET at runtime.
title: App Control for Business and .NET
description: Understand how App Control and .NET work together and use Dynamic Code Security to verify code loaded by .NET at runtime.
ms.localizationpriority: medium
ms.date: 11/22/2023
ms.topic: conceptual
---
# Windows Defender Application Control (WDAC) and .NET
# App Control for Business and .NET
.NET apps (as written in a high-level language like C#) are compiled to an Intermediate Language (IL). IL is a compact code format that can be supported on any operating system or architecture. Most .NET apps use APIs that are supported in multiple environments, requiring only the .NET runtime to run. IL needs to be compiled to native code in order to execute on a CPU, for example Arm64 or x64. When .NET compiles IL to native image (NI) on a device with a WDAC user mode policy, it first checks whether the original IL file passes the current WDAC policies. If so, .NET sets an NTFS extended attribute (EA) on the generated NI file so that WDAC knows to trust it as well. When the .NET app runs, WDAC sees the EA on the NI file and allows it.
.NET apps (as written in a high-level language like C#) are compiled to an Intermediate Language (IL). IL is a compact code format that can be supported on any operating system or architecture. Most .NET apps use APIs that are supported in multiple environments, requiring only the .NET runtime to run. IL needs to be compiled to native code in order to execute on a CPU, for example Arm64 or x64. When .NET compiles IL to native image (NI) on a device with a App Control user mode policy, it first checks whether the original IL file passes the current App Control policies. If so, .NET sets an NTFS extended attribute (EA) on the generated NI file so that App Control knows to trust it as well. When the .NET app runs, App Control sees the EA on the NI file and allows it.
The EA set on the NI file only applies to the currently active WDAC policies. If one of the active WDAC policies is updated or a new policy is applied, the EA on the NI file is invalidated. The next time the app runs, WDAC will block the NI file. .NET handles the block gracefully and falls back to the original IL code. If the IL still passes the latest WDAC policies, then the app runs without any functional impact. Since the IL is now being compiled at runtime, you might notice a slight impact to performance of the app. When .NET must fall back to IL, .NET will also schedule a process to run at the next maintenance window to regenerate all NI files, thus reestablishing the WDAC EA for all code that passes the latest WDAC policies.
The EA set on the NI file only applies to the currently active App Control policies. If one of the active App Control policies is updated or a new policy is applied, the EA on the NI file is invalidated. The next time the app runs, App Control will block the NI file. .NET handles the block gracefully and falls back to the original IL code. If the IL still passes the latest App Control policies, then the app runs without any functional impact. Since the IL is now being compiled at runtime, you might notice a slight impact to performance of the app. When .NET must fall back to IL, .NET will also schedule a process to run at the next maintenance window to regenerate all NI files, thus reestablishing the App Control EA for all code that passes the latest App Control policies.
In some cases, if an NI file is blocked, you might see a "false positive" block event in the *CodeIntegrity - Operational* event log as described in [WDAC Admin Tips & Known Issues](/windows/security/threat-protection/windows-defender-application-control/operations/known-issues#net-native-images-may-generate-false-positive-block-events).
In some cases, if an NI file is blocked, you might see a "false positive" block event in the *CodeIntegrity - Operational* event log as described in [App Control Admin Tips & Known Issues](../operations/known-issues.md#net-native-images-may-generate-false-positive-block-events).
To mitigate any performance impact caused when the WDAC EA isn't valid or missing:
To mitigate any performance impact caused when the App Control EA isn't valid or missing:
- Avoid updating the WDAC policies often.
- Run `ngen update` (on all machine architectures) to force .NET to regenerate all NI files immediately after applying changes to your WDAC policies.
- Avoid updating the App Control policies often.
- Run `ngen update` (on all machine architectures) to force .NET to regenerate all NI files immediately after applying changes to your App Control policies.
- Migrate applications to .NET Core (.NET 6 or greater).
## WDAC and .NET hardening
## App Control and .NET hardening
Security researchers found that some .NET capabilities that allow apps to load libraries from external sources or generate new code at runtime can be used to circumvent WDAC controls.
To address this potential vulnerability, WDAC includes an option called *Dynamic Code Security* that works with .NET to verify code loaded at runtime.
Security researchers found that some .NET capabilities that allow apps to load libraries from external sources or generate new code at runtime can be used to circumvent App Control controls.
To address this potential vulnerability, App Control includes an option called *Dynamic Code Security* that works with .NET to verify code loaded at runtime.
When the Dynamic Code Security option is enabled, Application Control policy is applied to libraries that .NET loads from external sources. For example, any remote sources, such as the internet or a network share.
> [!IMPORTANT]
> .Net dynamic code security hardening is *turned on and enforced* if any WDAC policy with UMCI enabled has set option **19 Enabled:Dynamic Code Security**. There is no audit mode for this feature. You should test your apps with this option set before turning it on across large numbers of devices.
> .Net dynamic code security hardening is *turned on and enforced* if any App Control policy with UMCI enabled has set option **19 Enabled:Dynamic Code Security**. There is no audit mode for this feature. You should test your apps with this option set before turning it on across large numbers of devices.
Additionally, it detects tampering in code generated to disk by .NET and blocks loading code that was tampered with.
@ -38,7 +38,7 @@ Microsoft recommends testing Dynamic Code Security in audit mode before enforcin
Additionally, customers can precompile for deployment only to prevent an allowed executable from being terminated because it tries to load unsigned dynamically generated code. See the "Precompiling for Deployment Only" section in the [ASP.NET Precompilation Overview](/previous-versions/aspnet/bb398860(v=vs.100)) document for how to fix that.
To enable Dynamic Code Security, add the following option to the `<Rules>` section of your WDAC policy:
To enable Dynamic Code Security, add the following option to the `<Rules>` section of your App Control policy:
```xml
<Rule>

25
windows/security/application-security/application-control/app-control-for-business/design/appcontrol-design-guide.md
View File

@ -1,17 +1,16 @@
---
title: Windows Defender Application Control design guide
description: Microsoft Windows Defender Application Control allows organizations to control what apps and drivers will run on their managed Windows devices.
title: App Control for Business design guide
description: Microsoft App Control for Business allows organizations to control what apps and drivers will run on their managed Windows devices.
ms.localizationpriority: medium
ms.topic: conceptual
ms.date: 02/20/2018
---
# Windows Defender Application Control design guide
# App Control for Business design guide
> [!NOTE]
> Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](../feature-availability.md).
[!INCLUDE [Feature availability note](../includes/feature-availability-note.md)]
This guide covers design and planning for Windows Defender Application Control (WDAC). It's intended to help security architects, security administrators, and system administrators create a plan that addresses specific application control requirements for different departments or business groups within an organization.
This guide covers design and planning for App Control for Business. It's intended to help security architects, security administrators, and system administrators create a plan that addresses specific application control requirements for different departments or business groups within an organization.
## Plan for success
@ -22,16 +21,16 @@ A common refrain you may hear about application control is that it is "too hard.
- The organization has a plan to handle potential helpdesk support requests for users who are blocked from running some apps.
- The organization has considered where application control can be most useful (for example, securing sensitive workloads or business functions) and also where it may be difficult to achieve (for example, developer workstations).
Once these business factors are in place, you're ready to begin planning your Windows Defender Application Control (WDAC) deployment. The following topics can help guide you through your planning process.
Once these business factors are in place, you're ready to begin planning your App Control for Business deployment. The following topics can help guide you through your planning process.
## In this section
| Topic | Description |
| - | - |
| [Plan for WDAC policy management](plan-appcontrol-management.md) | This topic describes the decisions you need to make to establish the processes for managing and maintaining WDAC policies. |
| [Understand WDAC policy design decisions](understand-appcontrol-policy-design-decisions.md) | This topic lists the design questions, possible answers, and ramifications of the decisions, when you plan a deployment of application control policies. |
| [Understand WDAC policy rules and file rules](select-types-of-rules-to-create.md) | This topic lists resources you can use when selecting your application control policy rules by using WDAC. |
| [Policy creation for common WDAC usage scenarios](common-appcontrol-use-cases.md) | This set of topics outlines common use case scenarios, and helps you begin to develop a plan for deploying WDAC in your organization. |
| [Policy creation using the WDAC Wizard tool](appcontrol-wizard.md) | This set of topics describes how to use the WDAC Wizard desktop app to easily create, edit, and merge WDAC policies. |
| [Plan for App Control policy management](plan-appcontrol-management.md) | This topic describes the decisions you need to make to establish the processes for managing and maintaining App Control policies. |
| [Understand App Control policy design decisions](understand-appcontrol-policy-design-decisions.md) | This topic lists the design questions, possible answers, and ramifications of the decisions, when you plan a deployment of application control policies. |
| [Understand App Control policy rules and file rules](select-types-of-rules-to-create.md) | This topic lists resources you can use when selecting your application control policy rules by using App Control. |
| [Policy creation for common App Control usage scenarios](common-appcontrol-use-cases.md) | This set of topics outlines common use case scenarios, and helps you begin to develop a plan for deploying App Control in your organization. |
| [Policy creation using the App Control Wizard tool](appcontrol-wizard.md) | This set of topics describes how to use the App Control Wizard desktop app to easily create, edit, and merge App Control policies. |
After planning is complete, the next step is to deploy WDAC. The [Windows Defender Application Control Deployment Guide](../deployment/appcontrol-deployment-guide.md) covers creating and testing policies, deploying the enforcement setting, and managing and maintaining policies.
After planning is complete, the next step is to deploy App Control. The [App Control for Business Deployment Guide](../deployment/appcontrol-deployment-guide.md) covers creating and testing policies, deploying the enforcement setting, and managing and maintaining policies.

39
windows/security/application-security/application-control/app-control-for-business/design/appcontrol-wizard-create-base-policy.md
View File

@ -1,6 +1,6 @@
---
title: Windows Defender Application Control Wizard Base Policy Creation
description: Creating new base application control policies with the Microsoft Windows Defender Application (WDAC) Wizard.
title: App Control for Business Wizard Base Policy Creation
description: Creating new base application control policies with the Microsoft Windows Defender Application (App Control) Wizard.
ms.localizationpriority: medium
ms.topic: conceptual
ms.date: 06/07/2023
@ -8,14 +8,13 @@ ms.date: 06/07/2023
# Creating a new Base Policy with the Wizard
> [!NOTE]
> Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](../feature-availability.md).
[!INCLUDE [Feature availability note](../includes/feature-availability-note.md)]
When creating policies for use with Windows Defender Application Control (WDAC), it's recommended to start with a template policy, and then add or remove rules to suit your application control scenario. For this reason, the WDAC Wizard offers three template policies to start from and customize during the base policy creation workflow. Prerequisite information about application control can be accessed through the [WDAC design guide](appcontrol-design-guide.md). This page outlines the steps to create a new application control policy from a template, configure the policy options, and the signer and file rules.
When creating policies for use with App Control for Business, it's recommended to start with a template policy, and then add or remove rules to suit your application control scenario. For this reason, the App Control Wizard offers three template policies to start from and customize during the base policy creation workflow. Prerequisite information about application control can be accessed through the [App Control design guide](appcontrol-design-guide.md). This page outlines the steps to create a new application control policy from a template, configure the policy options, and the signer and file rules.
## Template Base Policies
Each of the template policies has a unique set of policy allowlist rules that affect the circle-of-trust and security model of the policy. The following table lists the policies in increasing order of trust and freedom. For instance, the Default Windows mode policy trusts fewer application publishers and signers than the Signed and Reputable mode policy. The Default Windows policy has a smaller circle-of-trust with better security than the Signed and Reputable policy, but at the expense of compatibility.
Each of the template policies has a unique set of policy allowlist rules that affect the circle-of-trust and security model of the policy. The following table lists the policies in increasing order of trust and freedom. For instance, the Default Windows mode policy trusts fewer application publishers and signers than the Signed and Reputable mode policy. The Default Windows policy has a smaller circle-of-trust with better security than the Signed and Reputable policy, but at the expense of compatibility.
| Template Base Policy | Description |
|---------------------------------|-------------------------------------------------------------------|
@ -25,7 +24,7 @@ Each of the template policies has a unique set of policy allowlist rules that af
*Italicized content denotes the changes in the current policy with respect to the policy prior.*
More information about the Default Windows Mode and Allow Microsoft Mode policies can be accessed through the [Example Windows Defender Application Control base policies article](example-appcontrol-base-policies.md).
More information about the Default Windows Mode and Allow Microsoft Mode policies can be accessed through the [Example App Control for Business base policies article](example-appcontrol-base-policies.md).
![Selecting a base template for the policy.](../images/appcontrol-wizard-template-selection.png)
@ -37,20 +36,20 @@ Upon page launch, policy rules are automatically enabled/disabled depending on t
### Policy Rules Description
The following table has a description of each policy rule, beginning with the left-most column. The [Policy rules article](select-types-of-rules-to-create.md#windows-defender-application-control-policy-rules) provides a fuller description of each policy rule.
The following table has a description of each policy rule, beginning with the left-most column. The [Policy rules article](select-types-of-rules-to-create.md#app-control-for-business-policy-rules) provides a fuller description of each policy rule.
| Rule option | Description |
|------------ | ----------- |
| **Advanced Boot Options Menu** | The F8 preboot menu is disabled by default for all Windows Defender Application Control policies. Setting this rule option allows the F8 menu to appear to physically present users. |
| **Advanced Boot Options Menu** | The F8 preboot menu is disabled by default for all App Control for Business policies. Setting this rule option allows the F8 menu to appear to physically present users. |
| **Allow Supplemental Policies** | Use this option on a base policy to allow supplemental policies to expand it. |
| **Disable Script Enforcement** | This option disables script enforcement options. Unsigned PowerShell scripts and interactive PowerShell are no longer restricted to [Constrained Language Mode](/powershell/module/microsoft.powershell.core/about/about_language_modes). NOTE: This option is required to run HTA files, and is only supported with the Windows 10 May 2019 Update (1903) and higher. Using it on earlier versions of Windows 10 isn't supported and may have unintended results. |
|**[Hypervisor-protected code integrity (HVCI)](../../../../hardware-security/enable-virtualization-based-protection-of-code-integrity.md)**| When enabled, policy enforcement uses virtualization-based security to run the code integrity service inside a secure environment. HVCI provides stronger protections against kernel malware.|
| **Intelligent Security Graph Authorization** | Use this option to automatically allow applications with "known good" reputation as defined by the Microsoft Intelligent Security Graph (ISG). |
| **Managed Installer** | Use this option to automatically allow applications installed by a software distribution solution, such as Microsoft Configuration Manager, that has been defined as a managed installer. |
| **Require WHQL** | By default, legacy drivers that aren't Windows Hardware Quality Labs (WHQL) signed are allowed to execute. Enabling this rule requires that every executed driver is WHQL signed and removes legacy driver support. Henceforth, every new Windows-compatible driver must be WHQL certified. |
| **Update Policy without Rebooting** | Use this option to allow future Windows Defender Application Control policy updates to apply without requiring a system reboot. |
| **Update Policy without Rebooting** | Use this option to allow future App Control for Business policy updates to apply without requiring a system reboot. |
| **Unsigned System Integrity Policy** | Allows the policy to remain unsigned. When this option is removed, the policy must be signed and have UpdatePolicySigners added to the policy to enable future policy modifications. |
| **User Mode Code Integrity** | Windows Defender Application Control policies restrict both kernel-mode and user-mode binaries. By default, only kernel-mode binaries are restricted. Enabling this rule option validates user mode executables and scripts. |
| **User Mode Code Integrity** | App Control for Business 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. |
> [!div class="mx-imgBorder"]
> ![Rule options UI for Windows Allowed mode policy.](../images/appcontrol-wizard-rule-options-UI-advanced-collapsed.png)
@ -61,27 +60,27 @@ Selecting the **+ Advanced Options** label shows another column of policy rules,
| Rule option | Description |
|------------ | ----------- |
| **Boot Audit on Failure** | Used when the Windows Defender Application Control (WDAC) policy is in enforcement mode. When a driver fails during startup, the WDAC policy is placed in audit mode so that Windows loads. Administrators can validate the reason for the failure in the CodeIntegrity event log. |
| **Disable Flight Signing** | If enabled, WDAC policies block flightroot-signed binaries. This option would be used in the scenario in which organizations only want to run released binaries, not flight/preview-signed builds. |
| **Boot Audit on Failure** | Used when the App Control for Business policy is in enforcement mode. When a driver fails during startup, the App Control policy is placed in audit mode so that Windows loads. Administrators can validate the reason for the failure in the CodeIntegrity event log. |
| **Disable Flight Signing** | If enabled, App Control policies block flightroot-signed binaries. This option would be used in the scenario in which organizations only want to run released binaries, not flight/preview-signed builds. |
| **Disable Runtime FilePath Rule Protection** | This option disables the default runtime check that only allows FilePath rules for paths that are only writable by an administrator. |
| **Dynamic Code Security** | Enables policy enforcement for .NET applications and dynamically loaded libraries (DLLs). |
| **Invalidate EAs on Reboot** | When the Intelligent Security Graph option (14) is used, WDAC sets an extended file attribute that indicates that the file was authorized to run. This option causes WDAC to periodically revalidate the reputation for files authorized by the ISG.|
| **Invalidate EAs on Reboot** | When the Intelligent Security Graph option (14) is used, App Control sets an extended file attribute that indicates that the file was authorized to run. This option causes App Control to periodically revalidate the reputation for files authorized by the ISG.|
| **Require EV Signers** | This option isn't currently supported. |
![Rule options UI for Windows Allowed mode.](../images/appcontrol-wizard-rule-options-UI.png)
> [!NOTE]
> We recommend that you **enable Audit Mode** initially because it allows you to test new Windows Defender Application Control 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. For this reason, all templates have Audit Mode enabled by default.
> We recommend that you **enable Audit Mode** initially because it allows you to test new App Control for Business 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. For this reason, all templates have Audit Mode enabled by default.
## Creating custom file rules
[File rules](select-types-of-rules-to-create.md#windows-defender-application-control-file-rule-levels) in an application control policy specify the level at which applications are identified and trusted. File rules are the main mechanism for defining trust in the application control policy. Selecting **+ Custom Rules** opens the custom file rule conditions panel to create custom file rules for your policy. The Wizard supports four types of file rules:
[File rules](select-types-of-rules-to-create.md#app-control-for-business-file-rule-levels) in an application control policy specify the level at which applications are identified and trusted. File rules are the main mechanism for defining trust in the application control policy. Selecting **+ Custom Rules** opens the custom file rule conditions panel to create custom file rules for your policy. The Wizard supports four types of file rules:
### Publisher Rules
The Publisher file rule type uses properties in the code signing certificate chain to base file rules. Once the file to base the rule off of, called the *reference file*, is selected, use the slider to indicate the specificity of the rule. The following table shows the relationship between the slider placement, the corresponding Windows Defender Application Control (WDAC) rule level and its description. The lower the placement on the table and the UI slider, the greater the specificity of the rule.
The Publisher file rule type uses properties in the code signing certificate chain to base file rules. Once the file to base the rule off of, called the *reference file*, is selected, use the slider to indicate the specificity of the rule. The following table shows the relationship between the slider placement, the corresponding App Control for Business rule level and its description. The lower the placement on the table and the UI slider, the greater the specificity of the rule.
| Rule Condition | WDAC Rule Level | Description |
| Rule Condition | App Control Rule Level | Description |
|------------ | ----------- | ----------- |
| **Issuing CA** | PCACertificate | Highest available certificate is added to the signers. This certificate is typically the PCA certificate, one level below the root certificate. Any file signed by this certificate is affected. |
| **Publisher** | Publisher | This rule is a combination of the PCACertificate rule and the common name (CN) of the leaf certificate. Any file signed by a major CA but with a leaf from a specific company, for example, a device driver corp, is affected. |
@ -113,9 +112,9 @@ The Wizard supports the creation of [file name rules](select-types-of-rules-to-c
Lastly, the Wizard supports creating file rules using the hash of the file. Although this level is specific, it can cause extra administrative overhead to maintain the current product version's hash values. Each time a binary is updated, the hash value changes, therefore requiring a policy update. By default, the Wizard uses file hash as the fallback in case a file rule can't be created using the specified file rule level.
#### Deleting Signing Rules
The policy signing rules list table on the left of the page documents the allow and deny rules in the template, and any custom rules you create. Template signing rules and custom rules can be deleted from the policy by selecting the rule from the rules list table. Once the rule is highlighted, press the delete button underneath the table. You're then prompted for another confirmation. Select `Yes` to remove the rule from the policy and the rules table.
## Up next
- [Editing a Windows Defender Application Control (WDAC) policy using the Wizard](appcontrol-wizard-editing-policy.md)
- [Editing a App Control for Business policy using the Wizard](appcontrol-wizard-editing-policy.md)

23
windows/security/application-security/application-control/app-control-for-business/design/appcontrol-wizard-create-supplemental-policy.md
View File

@ -1,6 +1,6 @@
---
title: Windows Defender Application Control Wizard Supplemental Policy Creation
description: Creating supplemental application control policies with the WDAC Wizard.
title: App Control for Business Wizard Supplemental Policy Creation
description: Creating supplemental application control policies with the App Control Wizard.
ms.localizationpriority: medium
ms.topic: conceptual
ms.date: 06/07/2023
@ -8,20 +8,19 @@ ms.date: 06/07/2023
# Creating a new Supplemental Policy with the Wizard
> [!NOTE]
> Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](../feature-availability.md).
[!INCLUDE [Feature availability note](../includes/feature-availability-note.md)]
Beginning in Windows 10 version 1903, Windows Defender Application Control (WDAC) supports the creation of multiple active policies on a device. One or more supplemental policies allow customers to expand a [WDAC base policy](appcontrol-wizard-create-base-policy.md) to increase the circle of trust of the policy. A supplemental policy can expand only one base policy, but multiple supplementals can expand the same base policy. When supplemental policies are used, applications allowed by the base or any of its supplemental policies are allowed to run.
Beginning in Windows 10 version 1903, App Control for Business supports the creation of multiple active policies on a device. One or more supplemental policies allow customers to expand a [App Control base policy](appcontrol-wizard-create-base-policy.md) to increase the circle of trust of the policy. A supplemental policy can expand only one base policy, but multiple supplementals can expand the same base policy. When supplemental policies are used, applications allowed by the base or any of its supplemental policies are allowed to run.
Prerequisite information about application control can be accessed through the [WDAC design guide](appcontrol-design-guide.md). This page outlines the steps to create a supplemental application control policy, configure the policy options, and the signer and file rules.
Prerequisite information about application control can be accessed through the [App Control design guide](appcontrol-design-guide.md). This page outlines the steps to create a supplemental application control policy, configure the policy options, and the signer and file rules.
## Expanding a Base Policy
Once the Supplemental Policy type is chosen on the New Policy page, policy name and file dialog fields can be used to name and save the supplemental policy. The next step requires selecting a base policy to expand. To expand a base policy, the base must allow supplemental policies. The WDAC Wizard verifies if the base policy allows supplementals and shows the following confirmation.
Once the Supplemental Policy type is chosen on the New Policy page, policy name and file dialog fields can be used to name and save the supplemental policy. The next step requires selecting a base policy to expand. To expand a base policy, the base must allow supplemental policies. The App Control Wizard verifies if the base policy allows supplementals and shows the following confirmation.
![Base policy allows supplemental policies.](../images/appcontrol-wizard-supplemental-expandable.png)
If the base policy isn't configured for supplemental policies, the Wizard attempts to convert the policy to one that can be supplemented. Once successful, the Wizard shows a dialog demonstrating that the addition of the Allow Supplemental Policy rule was completed.
If the base policy isn't configured for supplemental policies, the Wizard attempts to convert the policy to one that can be supplemented. Once successful, the Wizard shows a dialog demonstrating that the addition of the Allow Supplemental Policy rule was completed.
![Wizard confirms modification of base policy.](../images/appcontrol-wizard-confirm-base-policy-modification.png)
@ -53,9 +52,9 @@ File rules in an application control policy specify the level at which applicati
### Publisher Rules
The Publisher file rule type uses properties in the code signing certificate chain to base file rules. Once the file to base the rule off of, called the *reference file*, is selected, use the slider to indicate the specificity of the rule. The following table shows the relationship between the slider placement, the corresponding Windows Defender Application Control (WDAC) rule level, and its description. The lower the placement on the table and the UI slider, the greater the specificity of the rule.
The Publisher file rule type uses properties in the code signing certificate chain to base file rules. Once the file to base the rule off of, called the *reference file*, is selected, use the slider to indicate the specificity of the rule. The following table shows the relationship between the slider placement, the corresponding App Control for Business rule level, and its description. The lower the placement on the table and the UI slider, the greater the specificity of the rule.
| Rule Condition | WDAC Rule Level | Description |
| Rule Condition | App Control Rule Level | Description |
|------------ | ----------- | ----------- |
| **Issuing CA** | PCACertificate | Highest available certificate is added to the signers. This certificate is typically the PCA certificate, one level below the root certificate. Any file signed by this certificate is affected. |
| **Publisher** | Publisher | This rule is a combination of the PCACertificate rule and the common name (CN) of the leaf certificate. Any file signed by a major CA but with a leaf from a specific company, for example, a device driver publisher, is affected. |
@ -86,9 +85,9 @@ The Wizard supports the creation of [file name rules](select-types-of-rules-to-c
Lastly, the Wizard supports creating file rules using the hash of the file. Although this level is specific, it can cause extra administrative overhead to maintain the current product versions' hash values. Each time a binary is updated, the hash value changes, therefore requiring a policy update. By default, the Wizard uses file hash as the fallback in case a file rule can't be created using the specified file rule level.
#### Deleting Signing Rules
The table on the left of the page documents the allow and deny rules in the template, and any custom rules you create. Rules can be deleted from the policy by selecting the rule from the rules list table. Once the rule is highlighted, press the delete button underneath the table. You're again prompted for another confirmation. Select `Yes` to remove the rule from the policy and the rules table.
## Up next
- [Editing a Windows Defender Application Control (WDAC) policy using the Wizard](appcontrol-wizard-editing-policy.md)
- [Editing a App Control for Business policy using the Wizard](appcontrol-wizard-editing-policy.md)

23
windows/security/application-security/application-control/app-control-for-business/design/appcontrol-wizard-editing-policy.md
View File

@ -1,17 +1,16 @@
---
title: Editing Windows Defender Application Control Policies with the Wizard
description: Editing existing base and supplemental policies with the Microsoft WDAC Wizard.
title: Editing App Control for Business Policies with the Wizard
description: Editing existing base and supplemental policies with the Microsoft App Control Wizard.
ms.localizationpriority: medium
ms.topic: conceptual
ms.date: 10/14/2020
---
# Editing existing base and supplemental WDAC policies with the Wizard
# Editing existing base and supplemental App Control policies with the Wizard
> [!NOTE]
> Some capabilities of Windows Defender Application Control (WDAC) are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](../feature-availability.md).
[!INCLUDE [Feature availability note](../includes/feature-availability-note.md)]
The Windows Defender Application Control Wizard makes editing and viewing WDAC policies easier than the PowerShell cmdlets or manually. The Wizard currently supports the following editing capabilities:
The App Control for Business Wizard makes editing and viewing App Control policies easier than the PowerShell cmdlets or manually. The Wizard currently supports the following editing capabilities:
<ul>
<li><a href="#configuring-policy-rules">Configuring policy rules</a></li>
<li><a href="#adding-file-rules">Adding new allow or block file rules to existing policies</a></li>
@ -24,21 +23,21 @@ The `Policy Rules` page will load with the in-edit policy rules configured per t
![Configuring the policy rules.](../images/appcontrol-wizard-edit-policy-rules.png)
A description of the policy rule is shown at the bottom of the page when the cursor is placed over the rule title. For a complete list of the policy rules and their capabilities, see the [Windows Defender Application Control policy rules table](select-types-of-rules-to-create.md#windows-defender-application-control-policy-rules).
A description of the policy rule is shown at the bottom of the page when the cursor is placed over the rule title. For a complete list of the policy rules and their capabilities, see the [App Control for Business policy rules table](select-types-of-rules-to-create.md#app-control-for-business-policy-rules).
## Adding File Rules
The Windows Defender Application Control Wizard allows users to add rules to their existing policy seamlessly. Previously, this rule-adding task would have involved creating a new policy with the new rules and merging it with the existing policy.
The App Control for Business Wizard allows users to add rules to their existing policy seamlessly. Previously, this rule-adding task would have involved creating a new policy with the new rules and merging it with the existing policy.
Selecting the `+ Custom Rules` button will open the Custom Rules panel. For more information on creating new policy file rules, see the guidelines provided in the [creating policy file rules section](appcontrol-wizard-create-base-policy.md#creating-custom-file-rules).
## Removing File Rules
The WDAC Wizard makes deleting file rules from an existing policy quick and easy. To remove any type of file rule: publisher rule, path rule, filename rule, or a hash rule, select the rule in the `Policy Signing Rules List` table on the left-hand side of the page. Selecting the rule will highlight the entire row. Once the row is highlighted, select the remove icon underneath the table. The Wizard will prompt for user confirmation before removing the file rule. Once removed, the rule will no longer appear in the policy or the table.
The App Control Wizard makes deleting file rules from an existing policy quick and easy. To remove any type of file rule: publisher rule, path rule, filename rule, or a hash rule, select the rule in the `Policy Signing Rules List` table on the left-hand side of the page. Selecting the rule will highlight the entire row. Once the row is highlighted, select the remove icon underneath the table. The Wizard will prompt for user confirmation before removing the file rule. Once removed, the rule will no longer appear in the policy or the table.
![Removing file rule from policy during edit.](../images/appcontrol-wizard-edit-remove-file-rule.png)
**Note:** removing a publisher rule will also remove the associated File Attribute rules. For instance, in the xml block below, removing ID_SIGNER_CONTOSO_PUBLISHER would also remove the rules ID_FILEATTRIB_LOB_APP_1 and ID_FILEATTRIB_LOB_APP_2.
**Note:** removing a publisher rule will also remove the associated File Attribute rules. For instance, in the xml block below, removing ID_SIGNER_CONTOSO_PUBLISHER would also remove the rules ID_FILEATTRIB_LOB_APP_1 and ID_FILEATTRIB_LOB_APP_2.
```xml
<Signer ID="ID_SIGNER_CONTOSO_PUBLISHER" Name="Contoso LOB Publisher CA">
@ -52,8 +51,8 @@ The WDAC Wizard makes deleting file rules from an existing policy quick and easy
### Policy Creation
Once the policy is created, the new policy will be written to the same path as the in-edit policy. The new policy file name will have the policy version appended to the end of the file name. For instance, if the in-edit policy is saved at MyDocuments\BasePolicy.xml, after edit, the new policy will be saved at MyDocuments\BasePolicy_v10.0.0.1.xml.
Once the policy is created, the new policy will be written to the same path as the in-edit policy. The new policy file name will have the policy version appended to the end of the file name. For instance, if the in-edit policy is saved at MyDocuments\BasePolicy.xml, after edit, the new policy will be saved at MyDocuments\BasePolicy_v10.0.0.1.xml.
## Up next
- [Merging Windows Defender Application Control (WDAC) policies using the Wizard](appcontrol-wizard-merging-policies.md)
- [Merging App Control for Business policies using the Wizard](appcontrol-wizard-merging-policies.md)

16
windows/security/application-security/application-control/app-control-for-business/design/appcontrol-wizard-merging-policies.md
View File

@ -1,20 +1,20 @@
---
title: Windows Defender Application Control Wizard Policy Merging Operation
description: Merging multiple policies into a single application control policy with the Microsoft WDAC Wizard.
title: App Control for Business Wizard Policy Merging Operation
description: Merging multiple policies into a single application control policy with the Microsoft App Control Wizard.
ms.localizationpriority: medium
ms.topic: conceptual
ms.date: 10/14/2020
---
# Merging existing policies with the WDAC Wizard
# Merging existing policies with the App Control Wizard
Beginning in Windows 10 version 1903, Windows Defender Application Control (WDAC) supports multiple policies. Before version 1903, however, Windows 10 could only have one WDAC policy. So, users were required to merge multiple WDAC policies into one. The WDAC Wizard has a simple to use user interface to allow users to merge multiple WDAC policies. The Wizard can support up to 15 policy files as input during the merge workflow.
Beginning in Windows 10 version 1903, App Control for Business supports multiple policies. Before version 1903, however, Windows 10 could only have one App Control policy. So, users were required to merge multiple App Control policies into one. The App Control Wizard has a simple to use user interface to allow users to merge multiple App Control policies. The Wizard can support up to 15 policy files as input during the merge workflow.
Select the policies you wish to merge into one policy using the `+ Add Policy` button under the table. Once added, policies will be enumerated within the table. To remove a policy from the table, if accidentally added, highlight the policy row and select the `- Remove Policy` button. Confirmation will be required before the policy is withdrawn from the table.
Select the policies you wish to merge into one policy using the `+ Add Policy` button under the table. Once added, policies will be enumerated within the table. To remove a policy from the table, if accidentally added, highlight the policy row and select the `- Remove Policy` button. Confirmation will be required before the policy is withdrawn from the table.
> [!NOTE]
> The policy type and ID of the final output policy will be determined based on the type and ID of the **first policy** in the policy list table. For instance, if a legacy policy format policy and a multi-policy format policy are merged together, the output format of the policy will be whichever policy is specified first in the table. For more information on policy formats, visit the [Multiple Windows Defender Application Control (WDAC) Policies page](deploy-multiple-appcontrol-policies.md).
> The policy type and ID of the final output policy will be determined based on the type and ID of the **first policy** in the policy list table. For instance, if a legacy policy format policy and a multi-policy format policy are merged together, the output format of the policy will be whichever policy is specified first in the table. For more information on policy formats, visit the [Multiple App Control for Business Policies page](deploy-multiple-appcontrol-policies.md).
Lastly, select a filepath save location for the final merged policy using the `Browse` button. If a minimum of two policies are selected, and the save location is specified, select the `Next` button to build the policy.
Lastly, select a filepath save location for the final merged policy using the `Browse` button. If a minimum of two policies are selected, and the save location is specified, select the `Next` button to build the policy.
![Merging WDAC policies into a final WDAC policy.](../images/appcontrol-wizard-merge.png)
![Merging App Control policies into a final App Control policy.](../images/appcontrol-wizard-merge.png)

73
windows/security/application-security/application-control/app-control-for-business/design/appcontrol-wizard-parsing-event-logs.md
View File

@ -1,60 +1,59 @@
---
title: Windows Defender Application Control Wizard WDAC Event Parsing
description: Creating WDAC policy rules from the WDAC event logs and the MDE Advanced Hunting WDAC events.
title: App Control for Business Wizard App Control Event Parsing
description: Creating App Control policy rules from the App Control event logs and the MDE Advanced Hunting App Control events.
ms.localizationpriority: medium
ms.topic: conceptual
ms.date: 01/24/2024
---
# Creating WDAC Policy Rules from WDAC Events in the Wizard
# Creating App Control Policy Rules from App Control Events in the Wizard
> [!NOTE]
> Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](../feature-availability.md).
[!INCLUDE [Feature availability note](../includes/feature-availability-note.md)]
As of [version 2.2.0.0](https://webapp-wdac-wizard.azurewebsites.net/archives.html), the WDAC Wizard supports creating WDAC policy rules from the following event log types:
As of [version 2.2.0.0](https://webapp-app-control-wizard.azurewebsites.net/archives.html), the App Control Wizard supports creating App Control policy rules from the following event log types:
1. [WDAC event log events on the system](#wdac-event-viewer-log-parsing)
2. [Exported WDAC events (EVTX files) from any system](#wdac-event-log-file-parsing)
3. [Exported WDAC events from MDE Advanced Hunting](#mde-advanced-hunting-wdac-event-parsing)
1. [App Control event log events on the system](#app-control-event-viewer-log-parsing)
2. [Exported App Control events (EVTX files) from any system](#app-control-event-log-file-parsing)
3. [Exported App Control events from MDE Advanced Hunting](#mde-advanced-hunting-app-control-event-parsing)
## WDAC Event Viewer Log Parsing
## App Control Event Viewer Log Parsing
To create rules from the WDAC event logs on the system:
To create rules from the App Control event logs on the system:
1. Select **Policy Editor** from the main page.
2. Select **Convert Event Log to a WDAC Policy**.
2. Select **Convert Event Log to a App Control Policy**.
3. Select the **Parse Event Logs** button under the **Parse Event Logs from the System Event Viewer to Policy** header.
The Wizard parses the relevant audit and block events from the CodeIntegrity (WDAC) Operational and AppLocker MSI and Script logs. You see a notification when the Wizard successfully finishes reading the events.
The Wizard parses the relevant audit and block events from the CodeIntegrity (App Control) Operational and AppLocker MSI and Script logs. You see a notification when the Wizard successfully finishes reading the events.
> [!div class="mx-imgBorder"]
> [![Parse WDAC and AppLocker event log system events](../images/appcontrol-wizard-event-log-system.png)](../images/appcontrol-wizard-event-log-system-expanded.png)
> [![Parse App Control and AppLocker event log system events](../images/appcontrol-wizard-event-log-system.png)](../images/appcontrol-wizard-event-log-system-expanded.png)
4. Select the Next button to view the audit and block events and create rules.
5. [Generate rules from the events](#creating-policy-rules-from-the-events).
## WDAC Event Log File Parsing
## App Control Event Log File Parsing
To create rules from the WDAC `.EVTX` event logs files on the system:
To create rules from the App Control `.EVTX` event logs files on the system:
1. Select **Policy Editor** from the main page.
2. Select **Convert Event Log to a WDAC Policy**.
2. Select **Convert Event Log to a App Control Policy**.
3. Select the **Parse Log File(s)** button under the **Parse Event Log evtx Files to Policy** header.
4. Select the WDAC CodeIntegrity Event log EVTX file(s) from the disk to parse.
4. Select the App Control CodeIntegrity Event log EVTX file(s) from the disk to parse.
The Wizard parses the relevant audit and block events from the selected log files. You see a notification when the Wizard successfully finishes reading the events.
The Wizard parses the relevant audit and block events from the selected log files. You see a notification when the Wizard successfully finishes reading the events.
> [!div class="mx-imgBorder"]
> [![Parse evtx file WDAC events](../images/appcontrol-wizard-event-log-files.png)](../images/appcontrol-wizard-event-log-files-expanded.png)
> [![Parse evtx file App Control events](../images/appcontrol-wizard-event-log-files.png)](../images/appcontrol-wizard-event-log-files-expanded.png)
5. Select the Next button to view the audit and block events and create rules.
6. [Generate rules from the events](#creating-policy-rules-from-the-events).
## MDE Advanced Hunting WDAC Event Parsing
## MDE Advanced Hunting App Control Event Parsing
To create rules from the WDAC events in [MDE Advanced Hunting](../operations/querying-application-control-events-centrally-using-advanced-hunting.md):
To create rules from the App Control events in [MDE Advanced Hunting](../operations/querying-application-control-events-centrally-using-advanced-hunting.md):
1. Navigate to the Advanced Hunting section within the MDE console and query the WDAC events. **The Wizard requires the following fields** in the Advanced Hunting csv file export:
1. Navigate to the Advanced Hunting section within the MDE console and query the App Control events. **The Wizard requires the following fields** in the Advanced Hunting csv file export:
```KQL
| project-keep Timestamp, DeviceId, DeviceName, ActionType, FileName, FolderPath, SHA1, SHA256, IssuerName, IssuerTBSHash, PublisherName, PublisherTBSHash, AuthenticodeHash, PolicyId, PolicyName
@ -63,9 +62,9 @@ To create rules from the WDAC events in [MDE Advanced Hunting](../operations/que
The following Advanced Hunting query is recommended:
```KQL
DeviceEvents
// Take only WDAC events
| where ActionType startswith 'AppControlCodeIntegrity'
DeviceEvents
// Take only App Control events
| where ActionType startswith 'AppControlCodeIntegrity'
// SigningInfo Fields
| extend IssuerName = parsejson(AdditionalFields).IssuerName
| extend IssuerTBSHash = parsejson(AdditionalFields).IssuerTBSHash
@ -75,33 +74,33 @@ To create rules from the WDAC events in [MDE Advanced Hunting](../operations/que
| extend AuthenticodeHash = parsejson(AdditionalFields).AuthenticodeHash
| extend PolicyId = parsejson(AdditionalFields).PolicyID
| extend PolicyName = parsejson(AdditionalFields).PolicyName
// Keep only required fields for the WDAC Wizard
// Keep only required fields for the App Control Wizard
| project-keep Timestamp,DeviceId,DeviceName,ActionType,FileName,FolderPath,SHA1,SHA256,IssuerName,IssuerTBSHash,PublisherName,PublisherTBSHash,AuthenticodeHash,PolicyId,PolicyName
```
2. Export the WDAC event results by selecting the **Export** button in the results view.
2. Export the App Control event results by selecting the **Export** button in the results view.
> [!div class="mx-imgBorder"]
> [![Export the MDE Advanced Hunting results to CSV](../images/appcontrol-wizard-event-log-mde-ah-export.png)](../images/appcontrol-wizard-event-log-mde-ah-export-expanded.png)
3. Select **Policy Editor** from the main page.
4. Select **Convert Event Log to a WDAC Policy**.
4. Select **Convert Event Log to a App Control Policy**.
5. Select the **Parse Log File(s)** button under the "Parse MDE Advanced Hunting Events to Policy" header.
6. Select the WDAC MDE Advanced Hunting export CSV files from the disk to parse.
6. Select the App Control MDE Advanced Hunting export CSV files from the disk to parse.
The Wizard will parse the relevant audit and block events from the selected Advanced Hunting log files. You see a notification when the Wizard successfully finishes reading the events.
The Wizard will parse the relevant audit and block events from the selected Advanced Hunting log files. You see a notification when the Wizard successfully finishes reading the events.
> [!div class="mx-imgBorder"]
> [![Parse the Advanced Hunting CSV WDAC event files](../images/appcontrol-wizard-event-log-mde-ah-parsing.png)](../images/appcontrol-wizard-event-log-mde-ah-parsing-expanded.png)
> [![Parse the Advanced Hunting CSV App Control event files](../images/appcontrol-wizard-event-log-mde-ah-parsing.png)](../images/appcontrol-wizard-event-log-mde-ah-parsing-expanded.png)
7. Select the Next button to view the audit and block events and create rules.
8. [Generate rules from the events](#creating-policy-rules-from-the-events).
## Creating Policy Rules from the Events
On the "Configure Event Log Rules" page, the unique WDAC log events are shown in the table. Event Ids, filenames, product names, the policy name that audited or blocked the file, and the file publisher are all shown in the table. The table can be sorted alphabetically by clicking on any of the headers.
On the "Configure Event Log Rules" page, the unique App Control log events are shown in the table. Event Ids, filenames, product names, the policy name that audited or blocked the file, and the file publisher are all shown in the table. The table can be sorted alphabetically by clicking on any of the headers.
To create a rule and add it to the WDAC policy:
To create a rule and add it to the App Control policy:
1. Select an audit or block event in the table by selecting the row of interest.
2. Select a rule type from the dropdown. The Wizard supports creating Publisher, Path, File Attribute, Packaged App and Hash rules.
@ -109,13 +108,13 @@ To create a rule and add it to the WDAC policy:
4. Select the **Add Allow Rule** button to add the configured rule to the policy generated by the Wizard. The "Added to policy" label is shown in the selected row confirming that the rule will be generated.
> [!div class="mx-imgBorder"]
> [![Adding a publisher rule to the WDAC policy](../images/appcontrol-wizard-event-rule-creation.png)](../images/appcontrol-wizard-event-rule-creation-expanded.png)
> [![Adding a publisher rule to the App Control policy](../images/appcontrol-wizard-event-rule-creation.png)](../images/appcontrol-wizard-event-rule-creation-expanded.png)
5. Select the **Next** button to output the policy. Once generated, the event log policy should be merged with your base or supplemental policies.
5. Select the **Next** button to output the policy. Once generated, the event log policy should be merged with your base or supplemental policies.
> [!WARNING]
> It is not recommended to deploy the event log policy on its own, as it likely lacks rules to authorize Windows and may cause blue screens.
## Up next
- [Merging Windows Defender Application Control (WDAC) policies using the Wizard](appcontrol-wizard-merging-policies.md)
- [Merging App Control for Business policies using the Wizard](appcontrol-wizard-merging-policies.md)

13
windows/security/application-security/application-control/app-control-for-business/design/appcontrol-wizard.md
View File

@ -1,21 +1,20 @@
---
title: Windows Defender Application Control Wizard
description: The Windows Defender Application Control policy wizard tool allows you to create, edit, and merge application control policies in a simple to use Windows application.
title: App Control for Business Wizard
description: The App Control for Business policy wizard tool allows you to create, edit, and merge application control policies in a simple to use Windows application.
ms.localizationpriority: medium
ms.topic: conceptual
ms.date: 05/24/2022
---
# Windows Defender Application Control Wizard
# App Control for Business Wizard
> [!NOTE]
> Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](../feature-availability.md).
[!INCLUDE [Feature availability note](../includes/feature-availability-note.md)]
The Windows Defender Application Control policy wizard is an open-source Windows desktop application written in C# and bundled as an MSIX package. It was built to provide security architects with security, and system administrators with a more user-friendly means to create, edit, and merge Application Control policies. This tool uses the [ConfigCI PowerShell cmdlets](/powershell/module/configci) in the backend so the output policy of the tool and PowerShell cmdlets is identical.
The App Control for Business policy wizard is an open-source Windows desktop application written in C# and bundled as an MSIX package. It was built to provide security architects with security, and system administrators with a more user-friendly means to create, edit, and merge Application Control policies. This tool uses the [ConfigCI PowerShell cmdlets](/powershell/module/configci) in the backend so the output policy of the tool and PowerShell cmdlets is identical.
## Downloading the application
Download the tool from the official [Windows Defender Application Control Policy Wizard website](https://webapp-wdac-wizard.azurewebsites.net/) as an MSIX packaged application. The tool's source code is available as part of Microsoft's Open Source Software offerings on GitHub at the [Windows Defender Application Control (WDAC) Policy Wizard repository](https://github.com/MicrosoftDocs/WDAC-Toolkit).
Download the tool from the official [App Control for Business Policy Wizard website](https://webapp-app-control-wizard.azurewebsites.net/) as an MSIX packaged application. The tool's source code is available as part of Microsoft's Open Source Software offerings on GitHub at the [App Control for Business Policy Wizard repository](https://github.com/MicrosoftDocs/App Control-Toolkit).
### Supported clients

21
windows/security/application-security/application-control/app-control-for-business/design/applications-that-can-bypass-appcontrol.md
View File

@ -1,19 +1,18 @@
---
title: Applications that can bypass WDAC and how to block them
title: Applications that can bypass App Control and how to block them
description: View a list of recommended block rules, based on knowledge shared between Microsoft and the wider security community.
ms.localizationpriority: medium
ms.date: 06/14/2023
ms.topic: reference
---
# Applications that can bypass WDAC and how to block them
# Applications that can bypass App Control and how to block them
> [!NOTE]
> Some capabilities of Windows Defender Application Control (WDAC) are only available on specific Windows versions. Learn more about the [WDAC feature availability](../feature-availability.md).
[!INCLUDE [Feature availability note](../includes/feature-availability-note.md)]
Members of the security community<sup>*</sup> continuously collaborate with Microsoft to help protect customers. With the help of their valuable reports, Microsoft has identified a list of valid applications that an attacker could also potentially use to bypass WDAC.
Members of the security community<sup>*</sup> continuously collaborate with Microsoft to help protect customers. With the help of their valuable reports, Microsoft has identified a list of valid applications that an attacker could also potentially use to bypass App Control.
Unless your use scenarios explicitly require them, Microsoft recommends that you block the following applications. An attacker can use these applications or files to circumvent application allow policies, including WDAC:
Unless your use scenarios explicitly require them, Microsoft recommends that you block the following applications. An attacker can use these applications or files to circumvent application allow policies, including App Control:
- addinprocess.exe
- addinprocess32.exe
@ -88,9 +87,9 @@ Unless your use scenarios explicitly require them, Microsoft recommends that you
> [!NOTE]
> This application list will be updated with the latest vendor information as application vulnerabilities are resolved and new issues are discovered.
Certain software applications may allow other code to run by design. Unless these applications are business critical, you should block them in your WDAC policy. In addition, when an application version is upgraded to fix a security vulnerability or potential WDAC bypass, add *deny* rules to your application control policies for that application's previous, less secure versions.
Certain software applications may allow other code to run by design. Unless these applications are business critical, you should block them in your App Control policy. In addition, when an application version is upgraded to fix a security vulnerability or potential App Control bypass, add *deny* rules to your application control policies for that application's previous, less secure versions.
Microsoft recommends that you install the latest security updates. For example, updates help resolve several issues in PowerShell modules that allowed an attacker to bypass WDAC. These modules can be blocked by their corresponding hashes.
Microsoft recommends that you install the latest security updates. For example, updates help resolve several issues in PowerShell modules that allowed an attacker to bypass App Control. These modules can be blocked by their corresponding hashes.
As of October 2017, system.management.automation.dll is updated to revoke earlier versions by hash values, instead of version rules.
@ -100,9 +99,9 @@ If you wish to use this blocklist policy on Windows Server 2016, locate the deny
- msxml6.dll
- jscript9.dll
The blocklist policy that follows includes "Allow all" rules for both kernel and user mode that make it safe to deploy as a standalone WDAC policy. On Windows versions 1903 and above, Microsoft recommends converting this policy to multiple policy format using the *Set-CiPolicyIdInfo* cmdlet with the *-ResetPolicyId* switch. Then, you can deploy it as a Base policy side-by-side with any other policies in your environment. To instead add these rules to an existing Base policy, you can merge the policy that follows using the *Merge-CIPolicy* cmdlet. If merging into an existing policy that includes an explicit allowlist, you should first remove the two "Allow all" rules and their corresponding FileRuleRefs from the blocklist policy.
The blocklist policy that follows includes "Allow all" rules for both kernel and user mode that make it safe to deploy as a standalone App Control policy. On Windows versions 1903 and above, Microsoft recommends converting this policy to multiple policy format using the *Set-CiPolicyIdInfo* cmdlet with the *-ResetPolicyId* switch. Then, you can deploy it as a Base policy side-by-side with any other policies in your environment. To instead add these rules to an existing Base policy, you can merge the policy that follows using the *Merge-CIPolicy* cmdlet. If merging into an existing policy that includes an explicit allowlist, you should first remove the two "Allow all" rules and their corresponding FileRuleRefs from the blocklist policy.
**WDAC policy XML**:
**App Control policy XML**:
```xml
<?xml version="1.0" encoding="utf-8"?>
@ -1531,4 +1530,4 @@ The blocklist policy that follows includes "Allow all" rules for both kernel and
## More information
- [Merge WDAC policies](../deployment/merge-appcontrol-policies.md)
- [Merge App Control policies](../deployment/merge-appcontrol-policies.md)

23
windows/security/application-security/application-control/app-control-for-business/design/common-appcontrol-use-cases.md
View File

@ -1,26 +1,25 @@
---
title: Policy creation for common WDAC usage scenarios
description: Develop a plan for deploying Windows Defender Application Control (WDAC) in your organization based on these common scenarios.
title: Policy creation for common App Control usage scenarios
description: Develop a plan for deploying App Control for Business in your organization based on these common scenarios.
ms.localizationpriority: medium
ms.date: 04/05/2023
ms.topic: conceptual
---
# Windows Defender Application Control deployment in different scenarios: types of devices
# App Control for Business deployment in different scenarios: types of devices
> [!NOTE]
> Some capabilities of Windows Defender Application Control (WDAC) are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](../feature-availability.md).
[!INCLUDE [Feature availability note](../includes/feature-availability-note.md)]
Typically, deployment of Windows Defender Application Control (WDAC) happens best in phases, rather than being a feature that you simply "turn on." The choice and sequence of phases depends on the way various computers and other devices are used in your organization, and to what degree IT manages those devices. The following table can help you begin to develop a plan for deploying WDAC in your organization. It's common for organizations to have device use cases across each of the categories described.
Typically, deployment of App Control for Business happens best in phases, rather than being a feature that you simply "turn on." The choice and sequence of phases depends on the way various computers and other devices are used in your organization, and to what degree IT manages those devices. The following table can help you begin to develop a plan for deploying App Control in your organization. It's common for organizations to have device use cases across each of the categories described.
## Types of devices
| Type of device | How WDAC relates to this type of device |
| Type of device | How App Control 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 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. |
| **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. | App Control for Business 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 App Control for Business policy can be established and enforced. Whenever the IT department approves more applications, it updates the App Control 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. | App Control for Business can be deployed fully, and deployment and ongoing administration are relatively straightforward.<br>After App Control for Business deployment, only approved applications can run. This rule is because of protections offered by App Control. |
| **Bring Your Own Device**: Employees are allowed to bring their own devices, and also use those devices away from work. | In most cases, App Control for Business 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
@ -34,4 +33,4 @@ Recently, Lamna experienced a ransomware event that required an expensive recove
## Up next
- [Create a Windows Defender Application Control policy for lightly managed devices](create-appcontrol-policy-for-lightly-managed-devices.md)
- [Create a App Control for Business policy for lightly managed devices](create-appcontrol-policy-for-lightly-managed-devices.md)

33
windows/security/application-security/application-control/app-control-for-business/design/configure-authorized-apps-deployed-with-a-managed-installer.md
View File

@ -1,43 +1,42 @@
---
title: Allow apps deployed with a WDAC managed installer
title: Allow apps deployed with a App Control managed installer
description: Explains how to configure a custom Managed Installer.
ms.localizationpriority: medium
ms.date: 02/02/2023
ms.topic: how-to
---
# Automatically allow apps deployed by a managed installer with Windows Defender Application Control
# Automatically allow apps deployed by a managed installer with App Control for Business
> [!NOTE]
> Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](../feature-availability.md).
[!INCLUDE [Feature availability note](../includes/feature-availability-note.md)]
Windows Defender Application Control (WDAC) includes an option called **managed installer** that helps balance security and manageability when enforcing application control policies. This option lets you automatically allow applications installed by a designated software distribution solution, such as Microsoft Configuration Manager (MEMCM) or Microsoft Intune.
App Control for Business includes an option called **managed installer** that helps balance security and manageability when enforcing application control policies. This option lets you automatically allow applications installed by a designated software distribution solution, such as Microsoft Configuration Manager (MEMCM) or Microsoft Intune.
## How does a managed installer work?
Managed installer uses a special rule collection in **AppLocker** to designate binaries that are trusted by your organization as an authorized source for application installation. When one of these trusted binaries runs, Windows monitors the binary's process (and any child processes it launches) and watches for files being written to disk. As files are written, they're tagged as originating from a managed installer.
You can then configure WDAC to trust files that are installed by a managed installer by adding the "Enabled:Managed Installer" option to your WDAC policy. When that option is set, WDAC will check for managed installer origin information when determining whether or not to allow a binary to run. As long as there are no deny rules for the binary, WDAC will allow it to run based purely on its managed installer origin.
You can then configure App Control to trust files that are installed by a managed installer by adding the "Enabled:Managed Installer" option to your App Control policy. When that option is set, App Control will check for managed installer origin information when determining whether or not to allow a binary to run. As long as there are no deny rules for the binary, App Control will allow it to run based purely on its managed installer origin.
## Security considerations with managed installer
Since managed installer is a heuristic-based mechanism, it doesn't provide the same security guarantees as explicit allow or deny rules do. Managed installer is best suited where users operate as standard user, and where all software is deployed and installed by a software distribution solution such as MEMCM.
Users with administrator privileges, or malware running as an administrator user on the system, may be able to circumvent the intent of your WDAC policies when the managed installer option is allowed.
Users with administrator privileges, or malware running as an administrator user on the system, may be able to circumvent the intent of your App Control policies when the managed installer option is allowed.
If a managed installer process runs in the context of a user with standard privileges, then it's possible that standard users or malware running as standard user may be able to circumvent the intent of your WDAC policies.
If a managed installer process runs in the context of a user with standard privileges, then it's possible that standard users or malware running as standard user may be able to circumvent the intent of your App Control policies.
Some application installers may automatically run the application at the end of the installation process. If the application runs automatically, and the installer was run by a managed installer, then the managed installer's heuristic tracking and authorization will extend to all files that are created during the first run of the application. This extension could result in unintentional authorization of an executable. To avoid that, ensure that the method of application deployment that is used as a managed installer limits running applications as part of installation.
## Known limitations with managed installer
- Application control, based on managed installer, doesn't support applications that self-update. If an application that was deployed by a managed installer later updates itself, the updated application files won't include the origin information from the managed installer, and they might not be able to run. When you rely on managed installers, you must deploy and install all application updates by using a managed installer, or include rules to authorize the app in the WDAC policy. In some cases, it may be possible to also designate an application binary that performs self-updates as a managed installer. Proper review for functionality and security should be performed for the application before using this method.
- Application control, based on managed installer, doesn't support applications that self-update. If an application that was deployed by a managed installer later updates itself, the updated application files won't include the origin information from the managed installer, and they might not be able to run. When you rely on managed installers, you must deploy and install all application updates by using a managed installer, or include rules to authorize the app in the App Control policy. In some cases, it may be possible to also designate an application binary that performs self-updates as a managed installer. Proper review for functionality and security should be performed for the application before using this method.
- Some applications or installers may extract, download, or generate binaries and immediately attempt to run them. Files run by such a process may not be allowed by the managed installer heuristic. In some cases, it may be possible to also designate an application binary that performs such an operation as a managed installer. Proper review for functionality and security should be performed for the application before using this method.
- The managed installer heuristic doesn't authorize kernel drivers. The WDAC policy must have rules that allow the necessary drivers to run.
- The managed installer heuristic doesn't authorize kernel drivers. The App Control policy must have rules that allow the necessary drivers to run.
## Configure managed installer tracking with AppLocker and WDAC
## Configure managed installer tracking with AppLocker and App Control
To turn on managed installer tracking, you must:
@ -48,7 +47,7 @@ To turn on managed installer tracking, you must:
> The managed installer AppLocker policy below is designed to be safely merged with any pre-existing AppLocker policies and won't change the behavior of those policies. However, if applied on a device that doesn't currently have any AppLocker policy, you will see a large increase in warning events generated in the *AppLocker - EXE and DLL* event log. If you're using an event forwarding and collection service, like LogAnalytics, you may want to adjust the configuration for that event log to only collect Error events or stop collecting events from that log altogether.
> [!NOTE]
> MEMCM will automatically configure itself as a managed installer, and enable the required AppLocker components, if you deploy one of its inbox WDAC policies. If you are configuring MEMCM as a managed installer using any other method, additional setup is required. Use the [**ManagedInstaller** cmdline switch in your ccmsetup.exe setup](/mem/configmgr/core/clients/deploy/about-client-installation-properties#managedinstaller). Or you can deploy one of the MEMCM inbox audit mode policies alongside your custom policy.
> MEMCM will automatically configure itself as a managed installer, and enable the required AppLocker components, if you deploy one of its inbox App Control policies. If you are configuring MEMCM as a managed installer using any other method, additional setup is required. Use the [**ManagedInstaller** cmdline switch in your ccmsetup.exe setup](/mem/configmgr/core/clients/deploy/about-client-installation-properties#managedinstaller). Or you can deploy one of the MEMCM inbox audit mode policies alongside your custom policy.
### Create and deploy an AppLocker policy that defines your managed installer rules and enables services enforcement for executables and DLLs
@ -189,12 +188,12 @@ The AppLocker policy creation UI in GPO Editor and the AppLocker PowerShell cmdl
> [!NOTE]
> Managed installer tracking will start the next time a process runs that matches your managed installer rules. If an intended process is already running, you must restart it.
## Enable the managed installer option in WDAC policy
## Enable the managed installer option in App Control policy
In order to enable trust for the binaries laid down by managed installers, the "Enabled: Managed Installer" option must be specified in your WDAC policy.
In order to enable trust for the binaries laid down by managed installers, the "Enabled: Managed Installer" option must be specified in your App Control policy.
This setting can be defined by using the [Set-RuleOption cmdlet](/powershell/module/configci/set-ruleoption) with Option 13.
Below are steps to create a WDAC policy that allows Windows to boot and enables the managed installer option.
Below are steps to create a App Control policy that allows Windows to boot and enables the managed installer option.
1. Copy the DefaultWindows_Audit policy into your working folder from "C:\Windows\schemas\CodeIntegrity\ExamplePolicies\DefaultWindows_Audit.xml"
@ -212,10 +211,10 @@ Below are steps to create a WDAC policy that allows Windows to boot and enables
Set-RuleOption -FilePath <XML filepath> -Option 13
```
4. Deploy your WDAC policy. See [Deploying Windows Defender Application Control (WDAC) policies](../deployment/appcontrol-deployment-guide.md).
4. Deploy your App Control policy. See [Deploying App Control for Business policies](../deployment/appcontrol-deployment-guide.md).
> [!NOTE]
> Your WDAC policy must include rules for all system/boot components, kernel drivers, and any other authorized applications that can't be deployed through a managed installer.
> Your App Control policy must include rules for all system/boot components, kernel drivers, and any other authorized applications that can't be deployed through a managed installer.
## Remove Managed Installer feature

22
windows/security/application-security/application-control/app-control-for-business/design/create-appcontrol-deny-policy.md
View File

@ -1,18 +1,18 @@
---
title: Create WDAC Deny Policy
description: Explains how to create WDAC deny policies
title: Create App Control Deny Policy
description: Explains how to create App Control deny policies
ms.localizationpriority: medium
ms.date: 12/31/2017
ms.topic: how-to
---
# Guidance on Creating WDAC Deny Policies
# Guidance on Creating App Control Deny Policies
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.
With App Control for Business, you can create policies to explicitly deny specific drivers and applications. To create effective App Control for Business deny policies, you should [understand the order of rule precedence](../operations/known-issues.md#file-rule-precedence-order) App Control applies as it evaluates files against the active policies.
## Standalone Deny policy
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.
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](example-appcontrol-base-policies.md) when creating your standalone deny policies.
```xml
<FileRules>
@ -37,7 +37,7 @@ When creating a policy that consists solely of deny rules, you must include "All
</SigningScenarios>
```
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:
Adding the preceding "Allow All" rules don't affect any other App Control policies you've deployed that apply an explicit allowlist. To illustrate, consider the following example:
Policy1 is an allowlist for Windows- and Microsoft-signed applications.
@ -50,7 +50,7 @@ Policy2 is our new deny policy, which blocks MaliciousApp.exe and also the Windo
## 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](appcontrol-wizard-merging-policies.md) or using the following PowerShell command:
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 App Control policy via the [App Control Wizard](appcontrol-wizard-merging-policies.md) or using the following PowerShell command:
```PowerShell
$DenyPolicy = <path_to_deny_policy>
@ -60,13 +60,13 @@ Merge-CIPolicy -PolicyPaths $ DenyPolicy, $ExistingPolicy -OutputFilePath $Exist
## Best Practices
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](../operations/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](../operations/appcontrol-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](../operations/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 App Control for Business policies](../operations/appcontrol-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 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.
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 App Control 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
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 [App Control Wizard](https://webapp-app-control-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
@ -99,4 +99,4 @@ Set-CiPolicyIdInfo -FilePath $DenyPolicy -PolicyName "My Deny Policy" -ResetPoli
### Deploy the Deny Policy
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.
You should now have a deny policy prepared to deploy. See the [App Control Deployment Guide](../deployment/appcontrol-deployment-guide.md) to deploy your policy to your managed endpoints.

39
windows/security/application-security/application-control/app-control-for-business/design/create-appcontrol-policy-for-fully-managed-devices.md
View File

@ -1,24 +1,23 @@
---
title: Create a WDAC policy for fully managed devices
description: Windows Defender Application Control restricts which applications users are allowed to run and the code that runs in system core.
title: Create a App Control policy for fully managed devices
description: App Control for Business restricts which applications users are allowed to run and the code that runs in system core.
ms.topic: conceptual
ms.localizationpriority: medium
ms.date: 11/07/2022
---
# Create a WDAC policy for fully managed devices
# Create a App Control policy for fully managed devices
>[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](../feature-availability.md).
[!INCLUDE [Feature availability note](../includes/feature-availability-note.md)]
This section outlines the process to create a Windows Defender Application Control (WDAC) policy for **fully managed devices** within an organization. The key difference between this scenario and [lightly managed devices](create-appcontrol-policy-for-lightly-managed-devices.md) is that all software deployed to a fully managed device is managed by IT and users of the device can't install arbitrary apps. Ideally, all apps are deployed using a software distribution solution, such as Microsoft Intune. Additionally, users on fully managed devices should ideally run as standard user and only authorized IT pros have administrative access.
This section outlines the process to create a App Control for Business policy for **fully managed devices** within an organization. The key difference between this scenario and [lightly managed devices](create-appcontrol-policy-for-lightly-managed-devices.md) is that all software deployed to a fully managed device is managed by IT and users of the device can't install arbitrary apps. Ideally, all apps are deployed using a software distribution solution, such as Microsoft Intune. Additionally, users on fully managed devices should ideally run as standard user and only authorized IT pros have administrative access.
> [!NOTE]
> Some of the Windows Defender Application Control options described in this topic are only available on Windows 10 version 1903 and above, or Windows 11. When using this topic to plan your own organization's WDAC policies, consider whether your managed clients can use all or some of these features and assess the impact for any features that may be unavailable on your clients. You may need to adapt this guidance to meet your specific organization's needs.
> Some of the App Control for Business options described in this topic are only available on Windows 10 version 1903 and above, or Windows 11. When using this topic to plan your own organization's App Control policies, consider whether your managed clients can use all or some of these features and assess the impact for any features that may be unavailable on your clients. You may need to adapt this guidance to meet your specific organization's needs.
As described in [common Windows Defender Application Control deployment scenarios](common-appcontrol-use-cases.md), we'll use the example of **Lamna Healthcare Company (Lamna)** to illustrate this scenario. Lamna is attempting to adopt stronger application policies, including the use of application control to prevent unwanted or unauthorized applications from running on their managed devices.
As described in [common App Control for Business deployment scenarios](common-appcontrol-use-cases.md), we'll use the example of **Lamna Healthcare Company (Lamna)** to illustrate this scenario. Lamna is attempting to adopt stronger application policies, including the use of application control to prevent unwanted or unauthorized applications from running on their managed devices.
**Alice Pena** is the IT team lead tasked with the rollout of WDAC.
**Alice Pena** is the IT team lead tasked with the rollout of App Control.
Alice previously created a policy for the organization's lightly managed devices. Some devices, however, are more tightly managed and can benefit from a more constrained policy. In particular, certain job functions such as administrative staff and firstline workers aren't granted administrator level access to their devices. Similarly, shared kiosks are configured only with a managed set of apps and all users of the device except IT run as standard user. On these devices, all apps are deployed and installed by IT.
@ -32,7 +31,7 @@ Alice identifies the following key factors to arrive at the "circle-of-trust" fo
- Sometimes, IT staff install apps directly to these devices without using Configuration Manager;
- All users except IT are standard users on these devices.
Alice's team develops a simple console application, called *LamnaITInstaller.exe*, which will become the authorized way for IT staff to install apps directly to devices. *LamnaITInstaller.exe* allows the IT pro to launch another process, such as an app installer. Alice will configure *LamnaITInstaller.exe* as an extra managed installer for WDAC and allows her to remove the need for filepath rules.
Alice's team develops a simple console application, called *LamnaITInstaller.exe*, which will become the authorized way for IT staff to install apps directly to devices. *LamnaITInstaller.exe* allows the IT pro to launch another process, such as an app installer. Alice will configure *LamnaITInstaller.exe* as an extra managed installer for App Control and allows her to remove the need for filepath rules.
Based on the above, Alice defines the pseudo-rules for the policy:
@ -49,14 +48,14 @@ The critical differences between this set of pseudo-rules and those pseudo-rules
- Removal of the Intelligent Security Graph (ISG) option; and
- Removal of filepath rules.
## Create a custom base policy using an example WDAC base policy
## Create a custom base policy using an example App Control base policy
Having defined the "circle-of-trust", Alice is ready to generate the initial policy for Lamna's fully managed devices and decides to use Configuration Manager to create the initial base policy and then customize it to meet Lamna's needs.
Alice follows these steps to complete this task:
> [!NOTE]
> If you do not use Configuration Manager or prefer to use a different [example Windows Defender Application Control base policy](example-appcontrol-base-policies.md) for your own policy, skip to step 2 and substitute the Configuration Manager policy path with your preferred example base policy.
> If you do not use Configuration Manager or prefer to use a different [example App Control for Business base policy](example-appcontrol-base-policies.md) for your own policy, skip to step 2 and substitute the Configuration Manager policy path with your preferred example base policy.
1. [Use Configuration Manager to create and deploy an audit policy](/configmgr/protect/deploy-use/use-device-guard-with-configuration-manager) to a client device running Windows 10 version 1903 or above, or Windows 11.
@ -97,7 +96,7 @@ Alice follows these steps to complete this task:
6. If appropriate, add more signer or file rules to further customize the policy for your organization.
7. Use [ConvertFrom-CIPolicy](/powershell/module/configci/convertfrom-cipolicy) to convert the Windows Defender Application Control policy to a binary format:
7. Use [ConvertFrom-CIPolicy](/powershell/module/configci/convertfrom-cipolicy) to convert the App Control for Business policy to a binary format:
```powershell
[xml]$PolicyXML = Get-Content $LamnaPolicy
@ -114,12 +113,12 @@ At this point, Alice now has an initial policy that is ready to deploy in audit
Alice has defined a policy for Lamna's fully managed devices that makes some trade-offs between security and manageability for apps. Some of the trade-offs include:
- **Users with administrative access**<br>
Although applying to fewer users, Lamna still allows some IT staff to sign in to its fully managed devices as administrator. This privilege allows these users (or malware running with the user's privileges) to modify or remove altogether the WDAC policy applied on the device. Additionally, administrators can configure any app they wish to operate as a managed installer that would allow them to gain persistent app authorization for whatever apps or binaries they wish.
Although applying to fewer users, Lamna still allows some IT staff to sign in to its fully managed devices as administrator. This privilege allows these users (or malware running with the user's privileges) to modify or remove altogether the App Control policy applied on the device. Additionally, administrators can configure any app they wish to operate as a managed installer that would allow them to gain persistent app authorization for whatever apps or binaries they wish.
Possible mitigations:
- Use signed WDAC policies and UEFI BIOS access protection to prevent tampering of WDAC policies.
- Use signed App Control policies and UEFI BIOS access protection to prevent tampering of App Control policies.
- Create and deploy signed catalog files as part of the app deployment process in order to remove the requirement for managed installer.
- Use device attestation to detect the configuration state of WDAC at boot time and use that information to condition access to sensitive corporate resources.
- Use device attestation to detect the configuration state of App Control at boot time and use that information to condition access to sensitive corporate resources.
- **Unsigned policies**<br>
Unsigned policies can be replaced or removed without consequence by any process running as administrator. Unsigned base policies that also enable supplemental policies can have their "circle-of-trust" altered by any unsigned supplemental policy.
@ -127,7 +126,7 @@ Alice has defined a policy for Lamna's fully managed devices that makes some tra
- Limit who can elevate to administrator on the device.
Possible mitigations:
- Use signed WDAC policies and UEFI BIOS access protection to prevent tampering of WDAC policies.
- Use signed App Control policies and UEFI BIOS access protection to prevent tampering of App Control policies.
- **Managed installer**<br>
See [security considerations with managed installer](configure-authorized-apps-deployed-with-a-managed-installer.md#security-considerations-with-managed-installer)
@ -140,10 +139,10 @@ Alice has defined a policy for Lamna's fully managed devices that makes some tra
Supplemental policies are designed to relax the associated base policy. Additionally allowing unsigned policies allows any administrator process to expand the "circle-of-trust" defined by the base policy without restriction.
Possible mitigations:
- Use signed WDAC policies that allow authorized signed supplemental policies only.
- Use signed App Control policies that allow authorized signed supplemental policies only.
- Use a restrictive audit mode policy to audit app usage and augment vulnerability detection.
## Up next
- [Create a Windows Defender Application Control policy for fixed-workload devices using a reference computer](create-appcontrol-policy-using-reference-computer.md)
- [Prepare to deploy Windows Defender Application Control policies](../deployment/appcontrol-deployment-guide.md)
- [Create a App Control for Business policy for fixed-workload devices using a reference computer](create-appcontrol-policy-using-reference-computer.md)
- [Prepare to deploy App Control for Business policies](../deployment/appcontrol-deployment-guide.md)

39
windows/security/application-security/application-control/app-control-for-business/design/create-appcontrol-policy-for-lightly-managed-devices.md
View File

@ -1,24 +1,23 @@
---
title: Create a WDAC policy for lightly managed devices
description: Windows Defender Application Control restricts which applications users are allowed to run and the code that runs in the system core.
title: Create a App Control policy for lightly managed devices
description: App Control for Business restricts which applications users are allowed to run and the code that runs in the system core.
ms.topic: conceptual
ms.localizationpriority: medium
ms.date: 11/07/2022
---
# Create a WDAC policy for lightly managed devices
# Create a App Control policy for lightly managed devices
>[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](../feature-availability.md).
[!INCLUDE [Feature availability note](../includes/feature-availability-note.md)]
This section outlines the process to create a Windows Defender Application Control (WDAC) policy for **lightly managed devices** within an organization. Typically, organizations that are new to application control will be most successful if they start with a permissive policy like the one described in this article. Organizations can choose to harden the policy over time to achieve a stronger overall security posture on their WDAC-managed devices as described in later articles.
This section outlines the process to create a App Control for Business policy for **lightly managed devices** within an organization. Typically, organizations that are new to application control will be most successful if they start with a permissive policy like the one described in this article. Organizations can choose to harden the policy over time to achieve a stronger overall security posture on their App Control-managed devices as described in later articles.
> [!NOTE]
> Some of the Windows Defender Application Control options described in this topic are only available on Windows 10 version 1903 and above, or Windows 11. When using this topic to plan your own organization's WDAC policies, consider whether your managed clients can use all or some of these features and assess the impact for any features that may be unavailable on your clients. You may need to adapt this guidance to meet your specific organization's needs.
> Some of the App Control for Business options described in this topic are only available on Windows 10 version 1903 and above, or Windows 11. When using this topic to plan your own organization's App Control policies, consider whether your managed clients can use all or some of these features and assess the impact for any features that may be unavailable on your clients. You may need to adapt this guidance to meet your specific organization's needs.
As in [Windows Defender Application Control deployment in different scenarios: types of devices](common-appcontrol-use-cases.md), we'll use the example of **Lamna Healthcare Company (Lamna)** to illustrate this scenario. Lamna is attempting to adopt stronger application policies, including the use of application control to prevent unwanted or unauthorized applications from running on their managed devices.
As in [App Control for Business deployment in different scenarios: types of devices](common-appcontrol-use-cases.md), we'll use the example of **Lamna Healthcare Company (Lamna)** to illustrate this scenario. Lamna is attempting to adopt stronger application policies, including the use of application control to prevent unwanted or unauthorized applications from running on their managed devices.
**Alice Pena** is the IT team lead tasked with the rollout of WDAC. Lamna currently has loose application usage policies and a culture of maximum app flexibility for users. So, Alice knows she'll need to take an incremental approach to application control and use different policies for different workloads.
**Alice Pena** is the IT team lead tasked with the rollout of App Control. Lamna currently has loose application usage policies and a culture of maximum app flexibility for users. So, Alice knows she'll need to take an incremental approach to application control and use different policies for different workloads.
For most users and devices, Alice wants to create an initial policy that is as relaxed as possible in order to minimize user productivity impact, while still providing security value.
@ -52,7 +51,7 @@ Based on the above, Alice defines the pseudo-rules for the policy:
- C:\Program Files (x86)\*
- %windir%\*
## Create a custom base policy using an example WDAC base policy
## Create a custom base policy using an example App Control base policy
Having defined the "circle-of-trust", Alice is ready to generate the initial policy for Lamna's lightly managed devices. Alice decides to use the example `SmartAppControl.xml` to create the initial base policy and then customize it to meet Lamna's needs.
@ -61,7 +60,7 @@ Alice follows these steps to complete this task:
1. On a client device, run the following commands in an elevated Windows PowerShell session to initialize variables:
> [!NOTE]
> If you prefer to use a different [example Windows Defender Application Control base policy](example-appcontrol-base-policies.md), substitute the example policy path with your preferred base policy in this step.
> If you prefer to use a different [example App Control for Business base policy](example-appcontrol-base-policies.md), substitute the example policy path with your preferred base policy in this step.
```powershell
$PolicyPath = $env:userprofile+"\Desktop\"
@ -79,7 +78,7 @@ Alice follows these steps to complete this task:
1. Modify the policy to remove unsupported rule:
> [!NOTE]
> `SmartAppControl.xml` is available on Windows 11 version 22H2 and later. This policy includes "Enabled:Conditional Windows Lockdown Policy" rule that is unsupported for enterprise WDAC policies and must be removed. For more information, see [WDAC and Smart App Control](../appcontrol.md#wdac-and-smart-app-control). If you are using an example policy other than `SmartAppControl.xml`, skip this step.
> `SmartAppControl.xml` is available on Windows 11 version 22H2 and later. This policy includes "Enabled:Conditional Windows Lockdown Policy" rule that is unsupported for enterprise App Control policies and must be removed. For more information, see [App Control and Smart App Control](../appcontrol.md#app-control-and-smart-app-control). If you are using an example policy other than `SmartAppControl.xml`, skip this step.
```powershell
[xml]$xml = Get-Content $LamnaPolicy
@ -127,7 +126,7 @@ Alice follows these steps to complete this task:
1. If appropriate, add more signer or file rules to further customize the policy for your organization.
1. Use [ConvertFrom-CIPolicy](/powershell/module/configci/convertfrom-cipolicy) to convert the Windows Defender Application Control policy to a binary format:
1. Use [ConvertFrom-CIPolicy](/powershell/module/configci/convertfrom-cipolicy) to convert the App Control for Business policy to a binary format:
```powershell
[xml]$PolicyXML = Get-Content $LamnaPolicy
@ -145,13 +144,13 @@ In order to minimize user productivity impact, Alice has defined a policy that m
- **Users with administrative access**
This trade-off is the most impactful security trade-off. It allows the device user, or malware running with the user's privileges, to modify or remove the WDAC policy on the device. Additionally, administrators can configure any app to act as a managed installer, which would allow them to gain persistent app authorization for whatever apps or binaries they wish.
This trade-off is the most impactful security trade-off. It allows the device user, or malware running with the user's privileges, to modify or remove the App Control policy on the device. Additionally, administrators can configure any app to act as a managed installer, which would allow them to gain persistent app authorization for whatever apps or binaries they wish.
Possible mitigations:
- Use signed WDAC policies and UEFI BIOS access protection to prevent tampering of WDAC policies.
- Use signed App Control policies and UEFI BIOS access protection to prevent tampering of App Control policies.
- To remove the requirement for managed installer, create and deploy signed catalog files as part of the app deployment process.
- Use device attestation to detect the configuration state of WDAC at boot time and use that information to condition access to sensitive corporate resources.
- Use device attestation to detect the configuration state of App Control at boot time and use that information to condition access to sensitive corporate resources.
- **Unsigned policies**
@ -159,7 +158,7 @@ In order to minimize user productivity impact, Alice has defined a policy that m
Possible mitigations:
- Use signed WDAC policies and UEFI BIOS access protection to prevent tampering of WDAC policies.
- Use signed App Control policies and UEFI BIOS access protection to prevent tampering of App Control policies.
- Limit who can elevate to administrator on the device.
- **Managed installer**
@ -186,7 +185,7 @@ In order to minimize user productivity impact, Alice has defined a policy that m
Possible mitigations:
- Use signed WDAC policies that allow authorized signed supplemental policies only.
- Use signed App Control policies that allow authorized signed supplemental policies only.
- Use a restrictive audit mode policy to audit app usage and augment vulnerability detection.
- **FilePath rules**
@ -208,5 +207,5 @@ In order to minimize user productivity impact, Alice has defined a policy that m
## Up next
- [Create a Windows Defender Application Control policy for fully managed devices](create-appcontrol-policy-for-fully-managed-devices.md)
- [Prepare to deploy Windows Defender Application Control policies](../deployment/appcontrol-deployment-guide.md)
- [Create a App Control for Business policy for fully managed devices](create-appcontrol-policy-for-fully-managed-devices.md)
- [Prepare to deploy App Control for Business policies](../deployment/appcontrol-deployment-guide.md)

37
windows/security/application-security/application-control/app-control-for-business/design/create-appcontrol-policy-using-reference-computer.md
View File

@ -1,31 +1,30 @@
---
title: Create a WDAC policy using a reference computer
description: To create a Windows Defender Application Control (WDAC) policy that allows all code installed on a reference computer within your organization, follow this guide.
title: Create a App Control policy using a reference computer
description: To create a App Control for Business policy that allows all code installed on a reference computer within your organization, follow this guide.
ms.localizationpriority: medium
ms.date: 08/08/2022
ms.topic: how-to
---
# Create a WDAC policy using a reference computer
# Create a App Control policy using a reference computer
>[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](../feature-availability.md).
[!INCLUDE [Feature availability note](../includes/feature-availability-note.md)]
This section outlines the process to create a Windows Defender Application Control (WDAC) policy **using a reference computer** that is already configured with the software you want to allow. You can use this approach for fixed-workload devices that are dedicated to a specific functional purpose and share common configuration attributes with other devices servicing the same functional role. Examples of fixed-workload devices may include Active Directory Domain Controllers, Secure Admin Workstations, pharmaceutical drug-mixing equipment, manufacturing devices, cash registers, ATMs, etc. This approach can also be used to turn on WDAC on systems "in the wild" and you want to minimize the potential impact on users' productivity.
This section outlines the process to create a App Control for Business policy **using a reference computer** that is already configured with the software you want to allow. You can use this approach for fixed-workload devices that are dedicated to a specific functional purpose and share common configuration attributes with other devices servicing the same functional role. Examples of fixed-workload devices may include Active Directory Domain Controllers, Secure Admin Workstations, pharmaceutical drug-mixing equipment, manufacturing devices, cash registers, ATMs, etc. This approach can also be used to turn on App Control on systems "in the wild" and you want to minimize the potential impact on users' productivity.
> [!NOTE]
> Some of the Windows Defender Application Control options described in this topic are only available on Windows 10 version 1903 and above, or Windows 11. When using this topic to plan your own organization's WDAC policies, consider whether your managed clients can use all or some of these features and assess the impact for any features that may be unavailable on your clients. You may need to adapt this guidance to meet your specific organization's needs.
> Some of the App Control for Business options described in this topic are only available on Windows 10 version 1903 and above, or Windows 11. When using this topic to plan your own organization's App Control policies, consider whether your managed clients can use all or some of these features and assess the impact for any features that may be unavailable on your clients. You may need to adapt this guidance to meet your specific organization's needs.
As described in [common Windows Defender Application Control deployment scenarios](common-appcontrol-use-cases.md), we'll use the example of **Lamna Healthcare Company (Lamna)** to illustrate this scenario. Lamna is attempting to adopt stronger application policies, including the use of application control to prevent unwanted or unauthorized applications from running on their managed devices.
As described in [common App Control for Business deployment scenarios](common-appcontrol-use-cases.md), we'll use the example of **Lamna Healthcare Company (Lamna)** to illustrate this scenario. Lamna is attempting to adopt stronger application policies, including the use of application control to prevent unwanted or unauthorized applications from running on their managed devices.
**Alice Pena** is the IT team lead tasked with the rollout of WDAC.
**Alice Pena** is the IT team lead tasked with the rollout of App Control.
## Create a custom base policy using a reference device
Alice previously created a policy for the organization's fully managed end-user devices. She now wants to use WDAC to protect Lamna's critical infrastructure servers. Lamna's imaging practice for infrastructure systems is to establish a "golden" image as a reference for what an ideal system should look like, and then use that image to clone more company assets. Alice decides to use these same "golden" image systems to create the WDAC policies, which will result in separate custom base policies for each type of infrastructure server. As with imaging, she'll have to create policies from multiple golden computers based on model, department, application set, and so on.
Alice previously created a policy for the organization's fully managed end-user devices. She now wants to use App Control to protect Lamna's critical infrastructure servers. Lamna's imaging practice for infrastructure systems is to establish a "golden" image as a reference for what an ideal system should look like, and then use that image to clone more company assets. Alice decides to use these same "golden" image systems to create the App Control policies, which will result in separate custom base policies for each type of infrastructure server. As with imaging, she'll have to create policies from multiple golden computers based on model, department, application set, and so on.
> [!NOTE]
> Make sure the reference computer is virus and malware-free, and install any software you want to be scanned before creating the WDAC policy. <br><br> Each installed software application should be validated as trustworthy before you create a policy. <br><br> We recommend that you review the reference computer for software that can load arbitrary DLLs and run code or scripts that could render the PC more vulnerable. Examples include software aimed at development or scripting such as msbuild.exe (part of Visual Studio and the .NET Framework) which can be removed if you don't want to run scripts. You can remove or disable such software on the reference computer.
> Make sure the reference computer is virus and malware-free, and install any software you want to be scanned before creating the App Control policy. <br><br> Each installed software application should be validated as trustworthy before you create a policy. <br><br> We recommend that you review the reference computer for software that can load arbitrary DLLs and run code or scripts that could render the PC more vulnerable. Examples include software aimed at development or scripting such as msbuild.exe (part of Visual Studio and the .NET Framework) which can be removed if you don't want to run scripts. You can remove or disable such software on the reference computer.
Alice identifies the following key factors to arrive at the "circle-of-trust" for Lamna's critical infrastructure servers:
@ -42,7 +41,7 @@ Based on the above, Alice defines the pseudo-rules for the policy:
2. Rules for **scanned files** that authorize all pre-existing app binaries found on the device
To create the WDAC policy, Alice runs each of the following commands in an elevated Windows PowerShell session, in order:
To create the App Control policy, Alice runs each of the following commands in an elevated Windows PowerShell session, in order:
1. Initialize variables.
@ -53,7 +52,7 @@ To create the WDAC policy, Alice runs each of the following commands in an eleva
$DefaultWindowsPolicy=$env:windir+"\schemas\CodeIntegrity\ExamplePolicies\DefaultWindows_Audit.xml"
```
2. Use [New-CIPolicy](/powershell/module/configci/new-cipolicy) to create a new WDAC policy by scanning the system for installed applications:
2. Use [New-CIPolicy](/powershell/module/configci/new-cipolicy) to create a new App Control policy by scanning the system for installed applications:
```powershell
New-CIPolicy -FilePath $LamnaServerPolicy -Level SignedVersion -Fallback FilePublisher,FileName,Hash -ScanPath c:\ -UserPEs -MultiplePolicyFormat -OmitPaths c:\Windows,'C:\Program Files\WindowsApps\',c:\windows.old\,c:\users\ 3> CIPolicyLog.txt
@ -61,9 +60,9 @@ To create the WDAC policy, Alice runs each of the following commands in an eleva
> [!Note]
>
> - You can add the **-Fallback** parameter to catch any applications not discovered using the primary file rule level specified by the **-Level** parameter. For more information about file rule level options, see [Windows Defender Application Control file rule levels](select-types-of-rules-to-create.md).
> - To specify that the WDAC policy scan only a specific drive, include the **-ScanPath** parameter followed by a path. Without this parameter, the tool will scan the C-drive by default.
> - When you specify the **-UserPEs** parameter (to include user mode executables in the scan), rule option **0 Enabled:UMCI** is automatically added to the WDAC policy. If you do not specify **-UserPEs**, the policy will be empty of user mode executables and will only have rules for kernel mode binaries like drivers. In other words, the allow list will not include applications. If you create such a policy and later add rule option **0 Enabled:UMCI**, all attempts to start applications will cause a response from Windows Defender Application Control. In audit mode, the response is logging an event, and in enforced mode, the response is blocking the application.
> - You can add the **-Fallback** parameter to catch any applications not discovered using the primary file rule level specified by the **-Level** parameter. For more information about file rule level options, see [App Control for Business file rule levels](select-types-of-rules-to-create.md).
> - To specify that the App Control policy scan only a specific drive, include the **-ScanPath** parameter followed by a path. Without this parameter, the tool will scan the C-drive by default.
> - When you specify the **-UserPEs** parameter (to include user mode executables in the scan), rule option **0 Enabled:UMCI** is automatically added to the App Control policy. If you do not specify **-UserPEs**, the policy will be empty of user mode executables and will only have rules for kernel mode binaries like drivers. In other words, the allow list will not include applications. If you create such a policy and later add rule option **0 Enabled:UMCI**, all attempts to start applications will cause a response from App Control for Business. In audit mode, the response is logging an event, and in enforced mode, the response is blocking the application.
> - To create a policy for Windows 10 1903 and above, including support for supplemental policies, use **-MultiplePolicyFormat**.
> - To specify a list of paths to exclude from the scan, use the **-OmitPaths** option and supply a comma-delimited list of paths.
> - The preceding example includes `3> CIPolicylog.txt`, which redirects warning messages to a text file, **CIPolicylog.txt**.
@ -95,7 +94,7 @@ To create the WDAC policy, Alice runs each of the following commands in an eleva
6. If appropriate, add more signer or file rules to further customize the policy for your organization.
7. Use [ConvertFrom-CIPolicy](/powershell/module/configci/convertfrom-cipolicy) to convert the WDAC policy to a binary format:
7. Use [ConvertFrom-CIPolicy](/powershell/module/configci/convertfrom-cipolicy) to convert the App Control policy to a binary format:
```powershell
[xml]$LamnaServerPolicyXML = Get-Content $LamnaServerPolicy
@ -110,7 +109,7 @@ Alice now has an initial policy for Lamna's critical infrastructure servers that
## Create a custom base policy to minimize user impact on in-use client devices
Alice previously created a policy for the organization's fully managed devices. Alice has included the fully managed device policy as part of Lamna's device build process so all new devices now begin with WDAC enabled. She's preparing to deploy the policy to systems that are already in use, but is worried about causing disruption to users' productivity. To minimize that risk, Alice decides to take a different approach for those systems. She'll continue to deploy the fully managed device policy in audit mode to those devices, but for enforcement mode she'll merge the fully managed device policy rules with a policy created by scanning the device for all previously installed software. In this way, each device is treated as its own "golden" system.
Alice previously created a policy for the organization's fully managed devices. Alice has included the fully managed device policy as part of Lamna's device build process so all new devices now begin with App Control enabled. She's preparing to deploy the policy to systems that are already in use, but is worried about causing disruption to users' productivity. To minimize that risk, Alice decides to take a different approach for those systems. She'll continue to deploy the fully managed device policy in audit mode to those devices, but for enforcement mode she'll merge the fully managed device policy rules with a policy created by scanning the device for all previously installed software. In this way, each device is treated as its own "golden" system.
Alice identifies the following key factors to arrive at the "circle-of-trust" for Lamna's fully managed in-use devices:
@ -122,4 +121,4 @@ Based on the above, Alice defines the pseudo-rules for the policy:
1. Everything included in the Fully Managed Devices policy
2. Rules for **scanned files** that authorize all pre-existing app binaries found on the device
For Lamna's existing, in-use devices, Alice deploys a script along with the Fully Managed Devices policy XML (not the converted WDAC policy binary). The script then generates a custom policy locally on the client as described in the previous section, but instead of merging with the DefaultWindows policy, the script merges with Lamna's Fully Managed Devices policy. Alice also modifies the steps above to match the requirements of this different use case.
For Lamna's existing, in-use devices, Alice deploys a script along with the Fully Managed Devices policy XML (not the converted App Control policy binary). The script then generates a custom policy locally on the client as described in the previous section, but instead of merging with the DefaultWindows policy, the script merges with Lamna's Fully Managed Devices policy. Alice also modifies the steps above to match the requirements of this different use case.

21
windows/security/application-security/application-control/app-control-for-business/design/deploy-multiple-appcontrol-policies.md
View File

@ -1,17 +1,16 @@
---
title: Use multiple Windows Defender Application Control Policies
description: Windows Defender Application Control supports multiple code integrity policies for one device.
title: Use multiple App Control for Business Policies
description: App Control for Business supports multiple code integrity policies for one device.
ms.localizationpriority: medium
ms.date: 04/15/2024
ms.topic: how-to
---
# Use multiple Windows Defender Application Control Policies
# Use multiple App Control for Business Policies
>[!NOTE]
>Some capabilities of Windows Defender Application Control (WDAC) are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](../feature-availability.md).
[!INCLUDE [Feature availability note](../includes/feature-availability-note.md)]
Beginning with Windows 10 version 1903 and Windows Server 2022, you can deploy multiple Windows Defender Application Control (WDAC) policies side-by-side on a device. To allow more than 32 active policies, install the Windows security update released on, or after, April 9, 2024 and then restart the device. With these updates, there's no limit for the number of policies you can deploy at once to a given device. Until you install the Windows security update released on or after April 9, 2024, your device is limited to 32 active policies and you must not exceed that number.
Beginning with Windows 10 version 1903 and Windows Server 2022, you can deploy multiple App Control for Business policies side-by-side on a device. To allow more than 32 active policies, install the Windows security update released on, or after, April 9, 2024 and then restart the device. With these updates, there's no limit for the number of policies you can deploy at once to a given device. Until you install the Windows security update released on or after April 9, 2024, your device is limited to 32 active policies and you must not exceed that number.
>[!NOTE]
>The policy limit was not removed on Windows 11 21H2 and will remain limited to 32 policies.
@ -29,7 +28,7 @@ Here are some common scenarios where multiple side-by-side policies are useful:
- For supplemental policies, applications allowed by either the base policy or its supplemental policy/policies run
> [!NOTE]
> Pre-1903 systems do not support the use of Multiple Policy Format WDAC policies.
> Pre-1903 systems do not support the use of Multiple Policy Format App Control policies.
## Base and supplemental policy interaction
@ -38,7 +37,7 @@ Here are some common scenarios where multiple side-by-side policies are useful:
- Base + supplemental policy: union
- Files allowed by either the base policy or the supplemental policy run
## Creating WDAC policies in Multiple Policy Format
## Creating App Control policies in Multiple Policy Format
In order to allow multiple policies to exist and take effect on a single system, policies must be created using the new Multiple Policy Format. The "MultiplePolicyFormat" switch in [New-CIPolicy](/powershell/module/configci/new-cipolicy?preserve-view=true&view=win10-ps) results in 1) unique values generated for the policy ID and 2) the policy type set as a Base policy. The below example describes the process of creating a new policy in the multiple policy format.
@ -75,7 +74,7 @@ When you're merging policies, the policy type and ID of the leftmost/first polic
## Deploying multiple policies
In order to deploy multiple Windows Defender Application Control policies, you must either deploy them locally by copying the `*.cip` policy files into the proper folder or by using the ApplicationControl CSP.
In order to deploy multiple App Control for Business policies, you must either deploy them locally by copying the `*.cip` policy files into the proper folder or by using the ApplicationControl CSP.
### Deploying multiple policies locally
@ -89,11 +88,11 @@ To deploy policies locally using the new multiple policy format, follow these st
### Deploying multiple policies via ApplicationControl CSP
Multiple Windows Defender Application Control policies can be managed from an MDM server through ApplicationControl configuration service provider (CSP). The CSP also provides support for rebootless policy deployment.<br>
Multiple App Control for Business policies can be managed from an MDM server through ApplicationControl configuration service provider (CSP). The CSP also provides support for rebootless policy deployment.<br>
However, when policies are unenrolled from an MDM server, the CSP attempts to remove every policy not actively deployed, not just the policies added by the CSP. This behavior happens because the system doesn't know what deployment methods were used to apply individual policies.
For more information on deploying multiple policies, optionally using Microsoft Intune's custom OMA-URI capability, see [ApplicationControl CSP](/windows/client-management/mdm/applicationcontrol-csp).
> [!NOTE]
> WMI and GP do not currently support multiple policies. Instead, customers who cannot directly access the MDM stack should use the [ApplicationControl CSP via the MDM Bridge WMI Provider](/windows/client-management/mdm/applicationcontrol-csp#powershell-and-wmi-bridge-usage-guidance) to manage Multiple Policy Format Windows Defender Application Control policies.
> WMI and GP do not currently support multiple policies. Instead, customers who cannot directly access the MDM stack should use the [ApplicationControl CSP via the MDM Bridge WMI Provider](/windows/client-management/mdm/applicationcontrol-csp#powershell-and-wmi-bridge-usage-guidance) to manage Multiple Policy Format App Control for Business policies.

29
windows/security/application-security/application-control/app-control-for-business/design/example-appcontrol-base-policies.md
View File

@ -1,32 +1,31 @@
---
title: Example Windows Defender Application Control base policies
description: When creating a Windows Defender Application Control (WDAC) policy for an organization, start from one of the many available example base policies.
title: Example App Control for Business base policies
description: When creating a App Control for Business policy for an organization, start from one of the many available example base policies.
ms.topic: reference
ms.localizationpriority: medium
ms.date: 03/31/2023
---
# Windows Defender Application Control example base policies
# App Control for Business example base policies
> [!NOTE]
> Some capabilities of Windows Defender Application Control are only available on specific Windows versions. For more information, see [Windows Defender Application Control feature availability](../feature-availability.md).
[!INCLUDE [Feature availability note](../includes/feature-availability-note.md)]
When you create policies for use with Windows Defender Application Control (WDAC), start from an existing base policy and then add or remove rules to build your own custom policy. Windows includes several example policies that you can use. These example policies are provided "as-is". You should thoroughly test the policies you deploy using safe deployment methods.
When you create policies for use with App Control for Business, start from an existing base policy and then add or remove rules to build your own custom policy. Windows includes several example policies that you can use. These example policies are provided "as-is". You should thoroughly test the policies you deploy using safe deployment methods.
| **Example Base Policy** | **Description** | **Where it can be found** |
|-------------------------|---------------------------------------------------------------|--------|
| **DefaultWindows_\*.xml** | This example policy is available in both audit and enforced mode. It includes rules to allow Windows, third-party hardware and software kernel drivers, and Windows Store apps. Used as the basis for the [Microsoft Intune product family](https://www.microsoft.com/security/business/endpoint-management/microsoft-intune) policies. | %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies\DefaultWindows_\*.xml <br> %ProgramFiles%\WindowsApps\Microsoft.WDAC.WDACWizard*\DefaultWindows_Audit.xml |
| **AllowMicrosoft.xml** | This example policy includes the rules from DefaultWindows and adds rules to trust apps signed by the Microsoft product root certificate. | %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies\AllowMicrosoft.xml <br> %ProgramFiles%\WindowsApps\Microsoft.WDAC.WDACWizard*\AllowMicrosoft.xml |
| **DefaultWindows_\*.xml** | This example policy is available in both audit and enforced mode. It includes rules to allow Windows, third-party hardware and software kernel drivers, and Windows Store apps. Used as the basis for the [Microsoft Intune product family](https://www.microsoft.com/security/business/endpoint-management/microsoft-intune) policies. | %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies\DefaultWindows_\*.xml <br> %ProgramFiles%\WindowsApps\Microsoft.App Control.WDACWizard*\DefaultWindows_Audit.xml |
| **AllowMicrosoft.xml** | This example policy includes the rules from DefaultWindows and adds rules to trust apps signed by the Microsoft product root certificate. | %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies\AllowMicrosoft.xml <br> %ProgramFiles%\WindowsApps\Microsoft.App Control.WDACWizard*\AllowMicrosoft.xml |
| **AllowAll.xml** | This example policy is useful when creating a blocklist. All block policies should include rules allowing all other code to run and then add the DENY rules for your organization's needs. | %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies\AllowAll.xml |
| **AllowAll_EnableHVCI.xml** | This example policy can be used to enable [memory integrity](https://support.microsoft.com/windows/core-isolation-e30ed737-17d8-42f3-a2a9-87521df09b78) (also known as hypervisor-protected code integrity) using WDAC. | %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies\AllowAll_EnableHVCI.xml |
| **AllowAll_EnableHVCI.xml** | This example policy can be used to enable [memory integrity](https://support.microsoft.com/windows/core-isolation-e30ed737-17d8-42f3-a2a9-87521df09b78) (also known as hypervisor-protected code integrity) using App Control. | %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies\AllowAll_EnableHVCI.xml |
| **DenyAllAudit.xml** | ***Warning: Will cause boot issues on Windows Server 2019 and earlier. Do not use on those operating systems.*** Only deploy this example policy in audit mode to track all binaries running on critical systems or to meet regulatory requirements. | %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies\DenyAllAudit.xml |
| **Microsoft Configuration Manager** | Customers who use Configuration Manager can deploy a policy with Configuration Manager's built-in WDAC integration, and then use the generated policy XML as an example base policy. | %OSDrive%\Windows\CCM\DeviceGuard on a managed endpoint |
| **SmartAppControl.xml** | This example policy includes rules based on [Smart App Control](https://support.microsoft.com/topic/what-is-smart-app-control-285ea03d-fa88-4d56-882e-6698afdb7003) that are well-suited for lightly managed systems. This policy includes a rule that is unsupported for enterprise WDAC policies and must be removed. For more information about using this example policy, see [Create a custom base policy using an example base policy](create-appcontrol-policy-for-lightly-managed-devices.md#create-a-custom-base-policy-using-an-example-wdac-base-policy). | %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies\SmartAppControl.xml <br>%ProgramFiles%\WindowsApps\Microsoft.WDAC.WDACWizard*\SignedReputable.xml |
| **Microsoft Configuration Manager** | Customers who use Configuration Manager can deploy a policy with Configuration Manager's built-in App Control integration, and then use the generated policy XML as an example base policy. | %OSDrive%\Windows\CCM\DeviceGuard on a managed endpoint |
| **SmartAppControl.xml** | This example policy includes rules based on [Smart App Control](https://support.microsoft.com/topic/what-is-smart-app-control-285ea03d-fa88-4d56-882e-6698afdb7003) that are well-suited for lightly managed systems. This policy includes a rule that is unsupported for enterprise App Control policies and must be removed. For more information about using this example policy, see [Create a custom base policy using an example base policy](create-appcontrol-policy-for-lightly-managed-devices.md#create-a-custom-base-policy-using-an-example-app-control-base-policy). | %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies\SmartAppControl.xml <br>%ProgramFiles%\WindowsApps\Microsoft.App Control.WDACWizard*\SignedReputable.xml |
| **Example supplemental policy** | This example policy shows how to use supplemental policy to expand the DefaultWindows_Audit.xml allow a single Microsoft-signed file. | %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies\DefaultWindows_Supplemental.xml |
| **Microsoft Recommended Block List** | This policy includes a list of Windows and Microsoft-signed code that Microsoft recommends blocking when using WDAC, if possible. | [Microsoft recommended block rules](/windows/security/threat-protection/windows-defender-application-control/microsoft-recommended-block-rules) <br> %ProgramFiles%\WindowsApps\Microsoft.WDAC.WDACWizard*\Recommended_UserMode_Blocklist.xml |
| **Microsoft recommended driver blocklist** | This policy includes rules to block known vulnerable or malicious kernel drivers. | [Microsoft recommended driver block rules](/windows/security/threat-protection/windows-defender-application-control/microsoft-recommended-driver-block-rules) <br> %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies\RecommendedDriverBlock_Enforced.xml <br> %ProgramFiles%\WindowsApps\Microsoft.WDAC.WDACWizard*\Recommended_Driver_Blocklist.xml |
| **Windows S mode** | This policy includes the rules used to enforce [Windows S mode](https://support.microsoft.com/windows/windows-10-and-windows-11-in-s-mode-faq-851057d6-1ee9-b9e5-c30b-93baebeebc85). | %ProgramFiles%\WindowsApps\Microsoft.WDAC.WDACWizard*\WinSiPolicy.xml.xml |
| **Windows 11 SE** | This policy includes the rules used to enforce [Windows 11 SE](/education/windows/windows-11-se-overview), a version of Windows built for use in schools. | %ProgramFiles%\WindowsApps\Microsoft.WDAC.WDACWizard*\WinSEPolicy.xml.xml |
| **Microsoft Recommended Block List** | This policy includes a list of Windows and Microsoft-signed code that Microsoft recommends blocking when using App Control, if possible. | [Microsoft recommended block rules](applications-that-can-bypass-appcontrol.md) <br> %ProgramFiles%\WindowsApps\Microsoft.App Control.WDACWizard*\Recommended_UserMode_Blocklist.xml |
| **Microsoft recommended driver blocklist** | This policy includes rules to block known vulnerable or malicious kernel drivers. | [Microsoft recommended driver block rules](microsoft-recommended-driver-block-rules.md) <br> %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies\RecommendedDriverBlock_Enforced.xml <br> %ProgramFiles%\WindowsApps\Microsoft.App Control.WDACWizard*\Recommended_Driver_Blocklist.xml |
| **Windows S mode** | This policy includes the rules used to enforce [Windows S mode](https://support.microsoft.com/windows/windows-10-and-windows-11-in-s-mode-faq-851057d6-1ee9-b9e5-c30b-93baebeebc85). | %ProgramFiles%\WindowsApps\Microsoft.App Control.WDACWizard*\WinSiPolicy.xml.xml |
| **Windows 11 SE** | This policy includes the rules used to enforce [Windows 11 SE](/education/windows/windows-11-se-overview), a version of Windows built for use in schools. | %ProgramFiles%\WindowsApps\Microsoft.App Control.WDACWizard*\WinSEPolicy.xml.xml |
> [!NOTE]
> Not all policies shown available at %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies can be found on all versions of Windows.

37
windows/security/application-security/application-control/app-control-for-business/design/manage-packaged-apps-with-appcontrol.md
View File

@ -1,28 +1,27 @@
---
title: Manage packaged apps with WDAC
description: Packaged apps, also known as Universal Windows apps, allow you to control the entire app by using a single Windows Defender Application Control (WDAC) rule.
title: Manage packaged apps with App Control
description: Packaged apps, also known as Universal Windows apps, allow you to control the entire app by using a single App Control for Business rule.
ms.localizationpriority: medium
ms.date: 03/01/2023
ms.topic: how-to
---
# Manage Packaged Apps with Windows Defender Application Control
# Manage Packaged Apps with App Control for Business
>[!NOTE]
>Some capabilities of Windows Defender Application Control (WDAC) are only available on specific Windows versions. Learn more about the [WDAC feature availability](../feature-availability.md).
[!INCLUDE [Feature availability note](../includes/feature-availability-note.md)]
This article for IT professionals describes concepts and lists procedures to help you manage packaged apps with Windows Defender Application Control (WDAC) as part of your overall application control strategy.
This article for IT professionals describes concepts and lists procedures to help you manage packaged apps with App Control for Business as part of your overall application control strategy.
## Comparing classic Windows Apps and Packaged Apps
The biggest challenge in adopting application control is the lack of a strong app identity for classic Windows apps, also known as win32 apps. A typical win32 app consists of multiple components, including the installer that is used to install the app, and one or more exes, dlls, or scripts. An app can consist of hundreds or even thousands of individual binaries that work together to deliver the functionality that your users understand as the app. Some of that code may be signed by the software publisher, some may be signed by other companies, and some of it may not be signed at all. Much of the code may be written to disk by a common set of installers, but some may already be installed and some downloaded on demand. Some of the binaries have common resource header metadata, such as product name and product version, but other files won't share that information. So while you want to be able to express rules like "allow app Foo", that isn't something Windows inherently understands for classic Windows apps. Instead, you may have to create many WDAC rules to allow all the files that comprise the app.
The biggest challenge in adopting application control is the lack of a strong app identity for classic Windows apps, also known as win32 apps. A typical win32 app consists of multiple components, including the installer that is used to install the app, and one or more exes, dlls, or scripts. An app can consist of hundreds or even thousands of individual binaries that work together to deliver the functionality that your users understand as the app. Some of that code may be signed by the software publisher, some may be signed by other companies, and some of it may not be signed at all. Much of the code may be written to disk by a common set of installers, but some may already be installed and some downloaded on demand. Some of the binaries have common resource header metadata, such as product name and product version, but other files won't share that information. So while you want to be able to express rules like "allow app Foo", that isn't something Windows inherently understands for classic Windows apps. Instead, you may have to create many App Control rules to allow all the files that comprise the app.
Packaged apps on the other hand, also known as [MSIX](/windows/msix/overview), ensure that all the files that make up an app share the same identity and have a common signature. Therefore, with packaged apps, it's possible to control the entire app with a single WDAC rule.
Packaged apps on the other hand, also known as [MSIX](/windows/msix/overview), ensure that all the files that make up an app share the same identity and have a common signature. Therefore, with packaged apps, it's possible to control the entire app with a single App Control rule.
## Using WDAC to Manage Packaged Apps
## Using App Control to Manage Packaged Apps
> [!IMPORTANT]
> When controlling packaged apps, you must choose between signer rules or Package Family Name (PFN) rules. If **any** Package Family Name (PFN) rule is used in your WDAC base policy or one of its supplemental policies, then **all** packaged apps must be controlled exclusively using PFN rules. You can't mix-and-match PFN rules with signature-based rules within a given base policy's scope. This will affect many inbox system apps like the Start menu. You can use wildcards in PFN rules on Windows 11 to simplify the rule creation.
> When controlling packaged apps, you must choose between signer rules or Package Family Name (PFN) rules. If **any** Package Family Name (PFN) rule is used in your App Control base policy or one of its supplemental policies, then **all** packaged apps must be controlled exclusively using PFN rules. You can't mix-and-match PFN rules with signature-based rules within a given base policy's scope. This will affect many inbox system apps like the Start menu. You can use wildcards in PFN rules on Windows 11 to simplify the rule creation.
### Creating signature-based rules for Packaged Apps
@ -35,16 +34,16 @@ $FilePath = $env:USERPROFILE+'\Downloads\WDACWizard_2.1.0.1_x64_8wekyb3d8bbwe.MS
$Rules = New-CIPolicyRule -DriverFilePath $FilePath -Level Publisher
```
Then use the [Merge-CIPolicy](/powershell/module/configci/merge-cipolicy) PowerShell cmdlet to merge your new rule into your existing WDAC policy XML.
Then use the [Merge-CIPolicy](/powershell/module/configci/merge-cipolicy) PowerShell cmdlet to merge your new rule into your existing App Control policy XML.
#### Create signer rule from AppxSignature.p7x
```powershell
$FilePath = $env:ProgramFiles+'\WindowsApps\Microsoft.WDAC.WDACWizard_2.1.0.1_x64__8wekyb3d8bbwe\AppxSignature.p7x'
$FilePath = $env:ProgramFiles+'\WindowsApps\Microsoft.App Control.WDACWizard_2.1.0.1_x64__8wekyb3d8bbwe\AppxSignature.p7x'
$Rules = New-CIPolicyRule -DriverFilePath $FilePath -Level Publisher
```
Then use the [Merge-CIPolicy](/powershell/module/configci/merge-cipolicy) PowerShell cmdlet to merge your new rule into your existing WDAC policy XML.
Then use the [Merge-CIPolicy](/powershell/module/configci/merge-cipolicy) PowerShell cmdlet to merge your new rule into your existing App Control policy XML.
### Creating PackageFamilyName rules for Packaged Apps
@ -61,15 +60,15 @@ foreach ($Package in $Packages)
}
```
Then use the [Merge-CIPolicy](/powershell/module/configci/merge-cipolicy) PowerShell cmdlet to merge your new rule(s) into your existing WDAC policy XML.
Then use the [Merge-CIPolicy](/powershell/module/configci/merge-cipolicy) PowerShell cmdlet to merge your new rule(s) into your existing App Control policy XML.
#### Create PFN rules using the WDAC Wizard
#### Create PFN rules using the App Control Wizard
##### Create PFN rule from an installed MSIX app
Use the following steps to create a WDAC PFN rule for an app that is installed on the system:
Use the following steps to create a App Control PFN rule for an app that is installed on the system:
1. From the **Policy Signing Rules** page of the [WDAC Wizard](https://aka.ms/wdacwizard), select **Add Custom Rule**.
1. From the **Policy Signing Rules** page of the [App Control Wizard](https://aka.ms/wdacwizard), select **Add Custom Rule**.
2. Check **Usermode Rule** as the Rule Scope, if not checked.
3. Select either **Allow** or **Deny** for your Rule Action.
4. Select **Packaged App** for your Rule Type.
@ -78,7 +77,7 @@ Use the following steps to create a WDAC PFN rule for an app that is installed o
7. Select **Create Rule**.
8. Create any other rules desired, then complete the Wizard.
![Create PFN rule from WDAC Wizard](../images/appcontrol-wizard-custom-pfn-rule.png)
![Create PFN rule from App Control Wizard](../images/appcontrol-wizard-custom-pfn-rule.png)
##### Create a PFN rule using a custom string
@ -91,4 +90,4 @@ Use the following steps to create a PFN rule with a custom string value:
5. Select **Create Rule**.
6. Create any other rules desired, then complete the Wizard.
![Create PFN rule with custom string from WDAC Wizard](../images/appcontrol-wizard-custom-manual-pfn-rule.png)
![Create PFN rule with custom string from App Control Wizard](../images/appcontrol-wizard-custom-manual-pfn-rule.png)

23
windows/security/application-security/application-control/app-control-for-business/design/microsoft-recommended-driver-block-rules.md
View File

@ -11,8 +11,7 @@ ms.topic: how-to
# Microsoft recommended driver block rules
>[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
[!INCLUDE [Feature availability note](../includes/feature-availability-note.md)]
Microsoft has strict requirements for code running in kernel. So, malicious actors are turning to exploit vulnerabilities in legitimate and signed kernel drivers to run malware in kernel. One of the many strengths of the Windows platform is our strong collaboration with independent hardware vendors (IHVs) and OEMs. Microsoft works closely with our IHVs and security community to ensure the highest level of driver security for our customers. When vulnerabilities in drivers are found, we work with our partners to ensure they're quickly patched and rolled out to the ecosystem. The vulnerable driver blocklist is designed to help harden systems against non-Microsoft-developed drivers across the Windows ecosystem with any of the following attributes:
@ -39,24 +38,24 @@ With Windows 11 2022 update, the vulnerable driver blocklist is enabled by defa
The blocklist is updated with each new major release of Windows, typically 1-2 times per year, including most recently with the Windows 11 2022 update released in September 2022. The most current blocklist is now also available for Windows 10 20H2 and Windows 11 21H2 users as an optional update from Windows Update. Microsoft will occasionally publish future updates through regular Windows servicing.
Customers who always want the most up-to-date driver blocklist can also use Windows Defender Application Control (WDAC) to apply the latest recommended driver blocklist contained in this article. For your convenience, we provide a download of the most up-to-date vulnerable driver blocklist along with instructions to apply it on your computer at the end of this article. Otherwise, use the following XML to create your own custom WDAC policies.
Customers who always want the most up-to-date driver blocklist can also use App Control for Business to apply the latest recommended driver blocklist contained in this article. For your convenience, we provide a download of the most up-to-date vulnerable driver blocklist along with instructions to apply it on your computer at the end of this article. Otherwise, use the following XML to create your own custom App Control policies.
## Blocking vulnerable drivers using WDAC
## Blocking vulnerable drivers using App Control
Microsoft recommends enabling [HVCI](../../../../hardware-security/enable-virtualization-based-protection-of-code-integrity.md) or S mode to protect your devices against security threats. If this setting isn't possible, Microsoft recommends blocking [this list of drivers](#vulnerable-driver-blocklist-xml) within your existing Windows Defender Application Control policy. Blocking kernel drivers without sufficient testing can cause devices or software to malfunction, and in rare cases, blue screen. It's recommended to first validate this policy in [audit mode](/windows/security/threat-protection/windows-defender-application-control/audit-windows-defender-application-control-policies) and review the audit block events.
Microsoft recommends enabling [HVCI](../../../../hardware-security/enable-virtualization-based-protection-of-code-integrity.md) or S mode to protect your devices against security threats. If this setting isn't possible, Microsoft recommends blocking [this list of drivers](#vulnerable-driver-blocklist-xml) within your existing App Control for Business policy. Blocking kernel drivers without sufficient testing can cause devices or software to malfunction, and in rare cases, blue screen. It's recommended to first validate this policy in [audit mode](../deployment/audit-appcontrol-policies.md) and review the audit block events.
> [!IMPORTANT]
> Microsoft also recommends enabling Attack Surface Reduction (ASR) rule [**Block abuse of exploited vulnerable signed drivers**](/microsoft-365/security/defender-endpoint/attack-surface-reduction-rules-reference#block-abuse-of-exploited-vulnerable-signed-drivers) to prevent an application from writing a vulnerable signed driver to disk. The ASR rule doesn't block a driver already existing on the system from loading, however enabling **Microsoft vulnerable driver blocklist** or applying this WDAC policy will prevent the existing driver from loading.
> Microsoft also recommends enabling Attack Surface Reduction (ASR) rule [**Block abuse of exploited vulnerable signed drivers**](/microsoft-365/security/defender-endpoint/attack-surface-reduction-rules-reference#block-abuse-of-exploited-vulnerable-signed-drivers) to prevent an application from writing a vulnerable signed driver to disk. The ASR rule doesn't block a driver already existing on the system from loading, however enabling **Microsoft vulnerable driver blocklist** or applying this App Control policy will prevent the existing driver from loading.
## Steps to download and apply the vulnerable driver blocklist binary
If you prefer to apply the [vulnerable driver blocklist](#vulnerable-driver-blocklist-xml) exactly as shown, follow these steps:
1. Download the [WDAC policy refresh tool](https://aka.ms/refreshpolicy)
1. Download the [App Control policy refresh tool](https://aka.ms/refreshpolicy)
2. Download and extract the [vulnerable driver blocklist binaries](https://aka.ms/VulnerableDriverBlockList)
3. Select either the audit only version or the enforced version and rename the file to SiPolicy.p7b
4. Copy SiPolicy.p7b to %windir%\system32\CodeIntegrity
5. Run the WDAC policy refresh tool you downloaded in Step 1 above to activate and refresh all WDAC policies on your computer
5. Run the App Control policy refresh tool you downloaded in Step 1 above to activate and refresh all App Control policies on your computer
To check that the policy was successfully applied on your computer:
@ -64,15 +63,15 @@ To check that the policy was successfully applied on your computer:
2. Browse to **Applications and Services Logs - Microsoft - Windows - CodeIntegrity - Operational**
3. Select **Filter Current Log...**
4. Replace "&lt;All Event IDs&gt;" with "3099" and select OK.
5. Look for a 3099 event where the PolicyNameBuffer and PolicyIdBuffer match the Name and Id PolicyInfo settings found at the bottom of the blocklist WDAC Policy XML in this article. NOTE: Your computer may have more than one 3099 event if other WDAC policies are also present.
5. Look for a 3099 event where the PolicyNameBuffer and PolicyIdBuffer match the Name and Id PolicyInfo settings found at the bottom of the blocklist App Control Policy XML in this article. NOTE: Your computer may have more than one 3099 event if other App Control policies are also present.
> [!NOTE]
> If any vulnerable drivers are already running that would be blocked by the policy, you must reboot your computer for those drivers to be blocked. Running processes aren't shutdown when activating a new WDAC policy without reboot.
> If any vulnerable drivers are already running that would be blocked by the policy, you must reboot your computer for those drivers to be blocked. Running processes aren't shutdown when activating a new App Control policy without reboot.
## Vulnerable driver blocklist XML
> [!IMPORTANT]
> The following policy contains **Allow All** rules. If your version of Windows supports WDAC multiple policies, we recommend deploying this policy alongside any existing WDAC policies. If you do plan to merge this policy with another policy, you may need to remove the **Allow All** rules before merging it if the other policy applies an explicit allow list. For more information, see [Create a WDAC Deny Policy](/windows/security/threat-protection/windows-defender-application-control/create-wdac-deny-policy#single-policy-considerations).
> The following policy contains **Allow All** rules. If your version of Windows supports App Control multiple policies, we recommend deploying this policy alongside any existing App Control policies. If you do plan to merge this policy with another policy, you may need to remove the **Allow All** rules before merging it if the other policy applies an explicit allow list. For more information, see [Create a App Control Deny Policy](create-appcontrol-deny-policy.md#guidance-on-creating-app-control-deny-policies).
> [!NOTE]
> To use this policy with Windows Server 2016, you must convert the policy XML on a device running a newer operating system.
@ -4756,4 +4755,4 @@ The following recommended blocklist xml policy file can also be downloaded from
## More information
- [Merge Windows Defender Application Control policies](/windows/security/threat-protection/windows-defender-application-control/merge-windows-defender-application-control-policies)
- [Merge App Control for Business policies](../deployment/merge-appcontrol-policies.md)

51
windows/security/application-security/application-control/app-control-for-business/design/plan-appcontrol-management.md
View File

@ -1,41 +1,40 @@
---
title: Plan for WDAC policy management
description: Learn about the decisions you need to make to establish the processes for managing and maintaining Windows Defender Application Control policies.
title: Plan for App Control policy management
description: Learn about the decisions you need to make to establish the processes for managing and maintaining App Control for Business policies.
ms.localizationpriority: medium
ms.date: 11/22/2023
ms.topic: conceptual
---
# Plan for Windows Defender Application Control lifecycle policy management
# Plan for App Control for Business lifecycle policy management
>[!NOTE]
>Some capabilities of Windows Defender Application Control (WDAC) are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](../feature-availability.md).
[!INCLUDE [Feature availability note](../includes/feature-availability-note.md)]
This article describes the decisions you need to make to establish the processes for managing and maintaining Windows Defender Application Control (WDAC) policies.
This article describes the decisions you need to make to establish the processes for managing and maintaining App Control for Business policies.
## Policy XML lifecycle management
The first step in implementing application control is to consider how your policies will be managed and maintained over time. Developing a process for managing Windows Defender Application Control policies helps ensure that WDAC continues to effectively control how applications are allowed to run in your organization.
The first step in implementing application control is to consider how your policies will be managed and maintained over time. Developing a process for managing App Control for Business policies helps ensure that App Control continues to effectively control how applications are allowed to run in your organization.
Most Windows Defender Application Control policies will evolve over time and proceed through a set of identifiable phases during their lifetime. Typically, these phases include:
Most App Control for Business policies will evolve over time and proceed through a set of identifiable phases during their lifetime. Typically, these phases include:
1. [Define (or refine) the "circle-of-trust"](understand-appcontrol-policy-design-decisions.md) for the policy and build an audit mode version of the policy XML. In audit mode, block events are generated but files aren't prevented from executing.
2. [Deploy the audit mode policy](/windows/security/threat-protection/windows-defender-application-control/audit-windows-defender-application-control-policies) to intended devices.
3. [Monitor audit block events](/windows/security/threat-protection/windows-defender-application-control/event-id-explanations) from the intended devices and add/edit/delete rules as needed to address unexpected/unwanted blocks.
2. [Deploy the audit mode policy](../deployment/audit-appcontrol-policies.md) to intended devices.
3. [Monitor audit block events](../operations/event-id-explanations.md) from the intended devices and add/edit/delete rules as needed to address unexpected/unwanted blocks.
4. Repeat steps 2-3 until the remaining block events meet expectations.
5. [Generate the enforced mode version](/windows/security/threat-protection/windows-defender-application-control/enforce-windows-defender-application-control-policies) of the policy. In enforced mode, files that the policy doesn't allow are prevented from running and corresponding block events are generated.
6. [Deploy the enforced mode policy](/windows/security/threat-protection/windows-defender-application-control/windows-defender-application-control-deployment-guide) to intended devices. We recommend using staged rollouts for enforced policies to detect and respond to issues before deploying the policy broadly.
5. [Generate the enforced mode version](../deployment/enforce-appcontrol-policies.md) of the policy. In enforced mode, files that the policy doesn't allow are prevented from running and corresponding block events are generated.
6. [Deploy the enforced mode policy](../deployment/appcontrol-deployment-guide.md) to intended devices. We recommend using staged rollouts for enforced policies to detect and respond to issues before deploying the policy broadly.
7. Repeat steps 1-6 anytime the desired "circle-of-trust" changes.
![Recommended WDAC policy deployment process.](../images/policyflow.png)
![Recommended App Control policy deployment process.](../images/policyflow.png)
### Keep WDAC policies in a source control or document management solution
### Keep App Control policies in a source control or document management solution
To effectively manage Windows Defender Application Control policies, you should store and maintain your policy XML documents in a central repository that is accessible to everyone responsible for WDAC policy management. We recommend a source control solution such as [GitHub](https://github.com/) or a document management solution such as [Office 365 SharePoint](https://products.office.com/sharepoint/collaboration), which provide version control and allow you to specify metadata about the XML documents.
To effectively manage App Control for Business policies, you should store and maintain your policy XML documents in a central repository that is accessible to everyone responsible for App Control policy management. We recommend a source control solution such as [GitHub](https://github.com/) or a document management solution such as [Office 365 SharePoint](https://products.office.com/sharepoint/collaboration), which provide version control and allow you to specify metadata about the XML documents.
### Set PolicyName, PolicyID, and Version metadata for each policy
Use the [Set-CIPolicyIDInfo](/powershell/module/configci/set-cipolicyidinfo) cmdlet to give each policy a descriptive name and set a unique policy ID. These unique attributes help you differentiate each policy when reviewing Windows Defender Application Control events or when viewing the policy XML document. Although you can specify a string value for PolicyId, for policies using the multiple policy format we recommend using the -ResetPolicyId switch to let the system autogenerate a unique ID for the policy.
Use the [Set-CIPolicyIDInfo](/powershell/module/configci/set-cipolicyidinfo) cmdlet to give each policy a descriptive name and set a unique policy ID. These unique attributes help you differentiate each policy when reviewing App Control for Business events or when viewing the policy XML document. Although you can specify a string value for PolicyId, for policies using the multiple policy format we recommend using the -ResetPolicyId switch to let the system autogenerate a unique ID for the policy.
> [!NOTE]
> PolicyID only applies to policies using the [multiple policy format](deploy-multiple-appcontrol-policies.md) on computers running Windows 10, version 1903 and above, or Windows 11. Running -ResetPolicyId on a policy created for pre-1903 computers will convert it to multiple policy format and prevent it from running on those earlier versions of Windows 10.
@ -45,15 +44,15 @@ In addition, we recommend using the [Set-CIPolicyVersion](/powershell/module/con
### Policy rule updates
You might need to revise your policy when new apps are deployed or existing apps are updated by the software publisher to ensure that apps run correctly. Whether policy rule updates are required will depend significantly on the types of rules your policy includes. Rules based on codesigning certificates provide the most resiliency against app changes while rules based on file attributes or hash are most likely to require updates when apps change. Alternatively, if you use WDAC [managed installer](configure-authorized-apps-deployed-with-a-managed-installer.md) functionality and consistently deploy all apps and their updates through your managed installer, then you're less likely to need policy updates.
You might need to revise your policy when new apps are deployed or existing apps are updated by the software publisher to ensure that apps run correctly. Whether policy rule updates are required will depend significantly on the types of rules your policy includes. Rules based on codesigning certificates provide the most resiliency against app changes while rules based on file attributes or hash are most likely to require updates when apps change. Alternatively, if you use App Control [managed installer](configure-authorized-apps-deployed-with-a-managed-installer.md) functionality and consistently deploy all apps and their updates through your managed installer, then you're less likely to need policy updates.
## WDAC event management
## App Control event management
Each time that WDAC blocks a process, events are written to either the CodeIntegrity\Operational or the AppLocker\MSI and Script Windows event logs. The event describes the file that tried to run, the attributes of that file and its signatures, and the process that attempted to run the blocked file.
Each time that App Control blocks a process, events are written to either the CodeIntegrity\Operational or the AppLocker\MSI and Script Windows event logs. The event describes the file that tried to run, the attributes of that file and its signatures, and the process that attempted to run the blocked file.
Collecting these events in a central location can help you maintain your Windows Defender Application Control policy and troubleshoot rule configuration problems. You can [use the Azure Monitor Agent](/azure/azure-monitor/agents/data-collection-rule-azure-monitor-agent) to automatically collect your WDAC events for analysis.
Collecting these events in a central location can help you maintain your App Control for Business policy and troubleshoot rule configuration problems. You can [use the Azure Monitor Agent](/azure/azure-monitor/agents/data-collection-rule-azure-monitor-agent) to automatically collect your App Control events for analysis.
Additionally, [Microsoft Defender for Endpoint](/microsoft-365/security/defender-endpoint/microsoft-defender-endpoint) collects WDAC events which can be queried using the [advanced hunting](../operations/querying-application-control-events-centrally-using-advanced-hunting.md) feature.
Additionally, [Microsoft Defender for Endpoint](/microsoft-365/security/defender-endpoint/microsoft-defender-endpoint) collects App Control events which can be queried using the [advanced hunting](../operations/querying-application-control-events-centrally-using-advanced-hunting.md) feature.
## Application and user support policy
@ -66,24 +65,24 @@ Considerations include:
### Help desk support
If your organization has an established help desk support department in place, consider the following points when deploying Windows Defender Application Control policies:
If your organization has an established help desk support department in place, consider the following points when deploying App Control for Business policies:
- What documentation does your support department require for new policy deployments?
- What are the critical processes in each business group both in work flow and timing that will be affected by application control policies and how could they affect your support department's workload?
- Who are the contacts in the support department?
- How will the support department resolve application control issues between the end user and those resources who maintain the Windows Defender Application Control rules?
- How will the support department resolve application control issues between the end user and those resources who maintain the App Control for Business rules?
### End-user support
Because Windows Defender Application Control is preventing unapproved apps from running, it's important that your organization carefully plans how to provide end-user support. Considerations include:
Because App Control for Business is preventing unapproved apps from running, it's important that your organization carefully plans how to provide end-user support. Considerations include:
- Do you want to use an intranet site as a frontline of support for users who try to run a blocked app?
- How do you want to support exceptions to the policy? Will you allow users to run a script to temporarily allow access to a blocked app?
## Document your plan
After deciding how your organization will manage your Windows Defender Application Control policy, record your findings.
After deciding how your organization will manage your App Control for Business policy, record your findings.
- **End-user support policy.** Document the process that you'll use for handling calls from users who have attempted to run a blocked app, and ensure that support personnel have clear escalation steps so that the administrator can update the Windows Defender Application Control policy, if necessary.
- **End-user support policy.** Document the process that you'll use for handling calls from users who have attempted to run a blocked app, and ensure that support personnel have clear escalation steps so that the administrator can update the App Control for Business policy, if necessary.
- **Event processing.** Document whether events will be collected in a central location called a store, how that store will be archived, and whether the events will be processed for analysis.
- **Policy management.** Detail what policies are planned, how they'll be managed, and how rules will be maintained over time.

39
windows/security/application-security/application-control/app-control-for-business/design/script-enforcement.md
View File

@ -1,63 +1,62 @@
---
title: Understand WDAC script enforcement
description: WDAC script enforcement
title: Understand App Control script enforcement
description: App Control script enforcement
ms.manager: jsuther
ms.date: 05/26/2023
ms.topic: conceptual
ms.localizationpriority: medium
---
# Script enforcement with Windows Defender Application Control (WDAC)
# Script enforcement with App Control for Business
> [!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).
[!INCLUDE [Feature availability note](../includes/feature-availability-note.md)]
> [!IMPORTANT]
> Option **11 Disabled:Script Enforcement** is not supported on **Windows Server 2016** or on **Windows 10 1607 LTSB** and should not be used on those platforms. Doing so will result in unexpected script enforcement behaviors.
## 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. 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.
By default, script enforcement is enabled for all App Control policies unless the option **11 Disabled:Script Enforcement** is set in the policy. App Control script enforcement involves a handshake between an enlightened script host, such as PowerShell, and App Control. 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 App Control UMCI policy is active. Most script hosts first ask App Control whether a script should be allowed to run based on the App Control 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 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.
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 App Control policy must allow it. This behavior is different from App Control 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 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).
App Control shares the *AppLocker - MSI and Script* event log for all script enforcement events. Whenever a script host asks App Control if a script should be allowed, an event is logged with the answer App Control returned to the script host. For more information on App Control script enforcement events, see [Understanding Application Control events](../operations/event-id-explanations.md#app-control-block-events-for-packaged-apps-msi-installers-scripts-and-com-objects).
> [!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.
> When a script runs that is not allowed by policy, App Control 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 script host specific information in this article 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 App Control 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
Your WDAC policies must allow all PowerShell scripts (.ps1), modules (.psm1), and manifests (.psd1) for them to run with Full Language rights.
Your App Control policies must allow all PowerShell scripts (.ps1), modules (.psm1), and manifests (.psd1) for them to run with Full Language rights.
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.
Your App Control policies must also allow any **dependent modules** that are loaded by an allowed module, and module functions must be exported explicitly by name when App Control 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 still runs, but only in Constrained Language Mode.
Any PowerShell script that isn't allowed by App Control 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 an allowed script file does try to run dot-sourced script files, those script files must also pass the policy.
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.
App Control puts **interactive PowerShell** into Constrained Language Mode if any App Control UMCI policy is enforced and *any* active App Control 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, 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
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.
Your App Control 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
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.
All code execution using MSHTA or MSXML is blocked if any App Control 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 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).
App Control additionally enforces a restricted allowlist for COM objects that your App Control 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](allow-com-object-registration-in-appcontrol-policy.md).
## Scripts that aren't directly controlled by WDAC
## Scripts that aren't directly controlled by App Control
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).
App Control 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 App Control 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 App Control for Business policy to control specific plug-ins, add-ins, and modules](use-appcontrol-policy-to-control-specific-plug-ins-add-ins-and-modules.md).
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.
App Control doesn't control scripts run through an unenlightened script host, such as many 3rd-party Java or Python engines. If your App Control 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 App Control policy.

99
windows/security/application-security/application-control/app-control-for-business/design/select-types-of-rules-to-create.md
View File

@ -1,66 +1,65 @@
---
title: Understand Windows Defender Application Control (WDAC) policy rules and file rules
description: Learn how WDAC policy rules and file rules can control your Windows 10 and Windows 11 computers.
title: Understand App Control for Business policy rules and file rules
description: Learn how App Control policy rules and file rules can control your Windows 10 and Windows 11 computers.
ms.localizationpriority: medium
ms.date: 11/22/2023
ms.topic: conceptual
---
# Understand Windows Defender Application Control (WDAC) policy rules and file rules
# Understand App Control for Business policy rules and file rules
[!INCLUDE [Feature availability note](../includes/feature-availability-note.md)]
App Control for Business can control what runs on your Windows devices 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 to identify applications your organization trusts.
## App Control for Business policy rules
To modify the policy rule options of an existing App Control policy XML, use the [App Control Policy Wizard](appcontrol-wizard.md) or the [Set-RuleOption](/powershell/module/configci/set-ruleoption) PowerShell cmdlet.
You can set several rule options within a App Control 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]
> 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 your Windows devices 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 to identify applications your organization trusts.
## Windows Defender Application Control policy rules
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.
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, applications run normally but WDAC logs events whenever a file runs that isn't allowed by the policy. To allow these files, 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.
> We recommend that you use **Enabled:Audit Mode** initially because it allows you to test new App Control policies before you enforce them. With audit mode, applications run normally but App Control logs events whenever a file runs that isn't allowed by the policy. To allow these files, 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.
>
> Some apps may behave differently even when your policy is in audit mode. When an option may change behaviors in audit mode, that is noted in Table 1. You should always test your apps thoroughly when deploying significant updates to your WDAC policies.
> Some apps may behave differently even when your policy is in audit mode. When an option may change behaviors in audit mode, that is noted in Table 1. You should always test your apps thoroughly when deploying significant updates to your App Control policies.
### Table 1. Windows Defender Application Control policy - policy rule options
### Table 1. App Control for Business policy - policy rule options
| Rule option | Description | Valid supplemental option |
|------------ | ----------- | ----------- |
| **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 |
| **0 Enabled:UMCI** | App Control policies restrict both kernel-mode and user-mode binaries. By default, only kernel-mode binaries are restricted. Enabling this rule option validates user mode executables and scripts. | No |
| **1 Enabled:Boot Menu Protection** | This option isn't currently supported. | 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 |
| **3 Enabled:Audit Mode (Default)** | Instructs App Control 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 App Control policy, and use the audit events to refine the policy before enforcement. To enforce a App Control policy, delete this option. | 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 prerelease 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 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 |
| **10 Enabled:Boot Audit on Failure** | Used when the WDAC policy is in enforcement mode. When a boot-critical driver fails during startup, the WDAC policy is placed in audit mode so that Windows loads. Administrators can validate the reason for the failure in the CodeIntegrity event log. | No |
| **11 Disabled:Script Enforcement** | This option disables script enforcement options, covering PowerShell, Windows Based Script Host (wscript.exe), Windows Console Based Script Host (cscript.exe), HTA files run in Microsoft HTML Application Host (mshta.exe), and MSXML. Some script hosts may behave differently even when your policy is in audit mode. For more information on script enforcement, see [Script enforcement with WDAC](/windows/security/threat-protection/windows-defender-application-control/design/script-enforcement). <br/> NOTE: This option isn't supported on Windows Server 2016 or Windows 10 1607 LTSB and shouldn't be used on those operating systems. | No |
| **12 Required:Enforce Store Applications** | If this rule option is enabled, WDAC policies also apply to Universal Windows applications. | No |
| **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 |
| **9 Enabled:Advanced Boot Options Menu** | The F8 preboot menu is disabled by default for all App Control policies. Setting this rule option allows the F8 menu to appear to physically present users. | No |
| **10 Enabled:Boot Audit on Failure** | Used when the App Control policy is in enforcement mode. When a boot-critical driver fails during startup, the App Control policy is placed in audit mode so that Windows loads. Administrators can validate the reason for the failure in the CodeIntegrity event log. | No |
| **11 Disabled:Script Enforcement** | This option disables script enforcement options, covering PowerShell, Windows Based Script Host (wscript.exe), Windows Console Based Script Host (cscript.exe), HTA files run in Microsoft HTML Application Host (mshta.exe), and MSXML. Some script hosts may behave differently even when your policy is in audit mode. For more information on script enforcement, see [Script enforcement with App Control](script-enforcement.md). <br/> NOTE: This option isn't supported on Windows Server 2016 or Windows 10 1607 LTSB and shouldn't be used on those operating systems. | No |
| **12 Required:Enforce Store Applications** | If this rule option is enabled, App Control policies also apply to Universal Windows applications. | No |
| **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 App Control 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 later, or Windows Server 2019 and later.| No |
| **15 Enabled:Invalidate EAs on Reboot** | When the Intelligent Security Graph option (14) is used, App Control sets an extended file attribute that indicates that the file was authorized to run. This option causes App Control 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 App Control 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.<br/> NOTE: This option is always enforced if *any* WDAC UMCI policy enables it. There's no audit mode for .NET dynamic code security hardening. | No |
| **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.<br/> NOTE: This option is always enforced if *any* App Control UMCI policy enables it. There's no audit mode for .NET dynamic code security hardening. | 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 |
| **Enabled:Developer Mode Dynamic Code Trust** | Use this option to trust UWP apps that are [debugged in Visual Studio](/visualstudio/debugger/run-windows-store-apps-on-a-remote-machine) or deployed through device portal when Developer Mode is enabled on the system. | No |
## Windows Defender Application Control file rule levels
## App Control for Business 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 the WDAC Wizard or 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 App Control Wizard or App Control 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.
Each file rule level has advantages and disadvantages. Use Table 2 to select the appropriate protection level for your available administrative resources and App Control deployment scenario.
> [!NOTE]
> WDAC signer-based rules only work with RSA cryptography with a maximum key length of 4096 bits. ECC algorithms, such as ECDSA, aren't supported. If you try to allow files by signature based on ECC signatures, you'll see VerificationError = 23 on the corresponding 3089 signature information events. Files can be allowed instead by hash or file attribute rules, or using other signer rules if the file is also signed with signatures using RSA.
> App Control signer-based rules only work with RSA cryptography with a maximum key length of 4096 bits. ECC algorithms, such as ECDSA, aren't supported. If you try to allow files by signature based on ECC signatures, you'll see VerificationError = 23 on the corresponding 3089 signature information events. Files can be allowed instead by hash or file attribute rules, or using other signer rules if the file is also signed with signatures using RSA.
### Table 2. Windows Defender Application Control policy - file rule levels
### Table 2. App Control for Business policy - file rule levels
| Rule level | Description |
|----------- | ----------- |
@ -70,7 +69,7 @@ Each file rule level has advantages and disadvantages. Use Table 2 to select the
| **SignedVersion** | This level combines the publisher rule with a version number. It allows anything to run from the specified publisher with a version at or above the specified version number. |
| **Publisher** | This level combines the PcaCertificate level (typically one certificate below the root) and the common name (CN) of the leaf certificate. You can use this rule level to trust a certificate issued by a particular CA and issued to a specific company you trust (such as Intel, for device drivers). |
| **FilePublisher** | This level combines the "FileName" attribute of the signed file, plus "Publisher" (PCA certificate with CN of leaf), plus a minimum version number. This option trusts specific files from the specified publisher, with a version at or above the specified version number. By default, this level uses the OriginalFileName attribute of the file's resource header. Use [-SpecificFileNameLevel](#use--specificfilenamelevel-with-filename-filepublisher-or-whqlfilepublisher-level-rules) to choose an alternative attribute, such as ProductName. |
| **LeafCertificate** | Adds trusted signers at the individual signing certificate level. The benefit of using this level versus the individual hash level is that new versions of the product have different hash values but typically the same signing certificate. When this level is used, no policy update would be needed to run the new version of the application. However, leaf certificates typically have shorter validity periods than other certificate levels, so the WDAC policy must be updated whenever these certificates change. |
| **LeafCertificate** | Adds trusted signers at the individual signing certificate level. The benefit of using this level versus the individual hash level is that new versions of the product have different hash values but typically the same signing certificate. When this level is used, no policy update would be needed to run the new version of the application. However, leaf certificates typically have shorter validity periods than other certificate levels, so the App Control policy must be updated whenever these certificates change. |
| **PcaCertificate** | Adds the highest available certificate in the provided certificate chain to signers. This level is typically one certificate below the root because the scan doesn't resolve the complete certificate chain via the local root stores or with an online check. |
| **RootCertificate** | Not supported. |
| **WHQL** | Only trusts binaries that were submitted to Microsoft and signed by the Windows Hardware Qualification Lab (WHQL). This level is primarily for kernel binaries. |
@ -78,7 +77,7 @@ Each file rule level has advantages and disadvantages. Use Table 2 to select the
| **WHQLFilePublisher** | This level combines the "FileName" attribute of the signed file, plus "WHQLPublisher", plus a minimum version number. This level is primarily for kernel binaries. By default, this level uses the OriginalFileName attribute of the file's resource header. Use [-SpecificFileNameLevel](#use--specificfilenamelevel-with-filename-filepublisher-or-whqlfilepublisher-level-rules) to choose an alternative attribute, such as ProductName. |
> [!NOTE]
> When you create WDAC policies with [New-CIPolicy](/powershell/module/configci/new-cipolicy), you can specify a primary file rule level, by including the **-Level** parameter. For discovered binaries that cannot be trusted based on the primary file rule criteria, use the **-Fallback** parameter. For example, if the primary file rule level is PCACertificate, but you would like to trust the unsigned applications as well, using the Hash rule level as a fallback adds the hash values of binaries that did not have a signing certificate.
> When you create App Control policies with [New-CIPolicy](/powershell/module/configci/new-cipolicy), you can specify a primary file rule level, by including the **-Level** parameter. For discovered binaries that cannot be trusted based on the primary file rule criteria, use the **-Fallback** parameter. For example, if the primary file rule level is PCACertificate, but you would like to trust the unsigned applications as well, using the Hash rule level as a fallback adds the hash values of binaries that did not have a signing certificate.
> [!NOTE]
> When applicable, minimum and maximum version numbers in a file rule are referenced as MinimumFileVersion and MaximumFileVersion respectively in the policy XML.
@ -91,16 +90,16 @@ Each file rule level has advantages and disadvantages. Use Table 2 to select the
For example, consider an IT professional in a department that runs many servers. They only want to run software signed by the companies that provide their hardware, operating system, antivirus, and other important software. They know that their servers also run an internally written application that is unsigned but is rarely updated. They want to allow this application to run.
To create the WDAC policy, they build a reference server on their standard hardware, and install all of the software that their servers are known to run. Then they run [New-CIPolicy](/powershell/module/configci/new-cipolicy) with **-Level Publisher** (to allow software from their software providers, the "Publishers") and **-Fallback Hash** (to allow the internal, unsigned application). They deploy the policy in auditing mode to determine the potential impact from enforcing the policy. With the help of the audit data, they update their WDAC policies to include any other software they want to run. Then they enable the WDAC policy in enforced mode for their servers.
To create the App Control policy, they build a reference server on their standard hardware, and install all of the software that their servers are known to run. Then they run [New-CIPolicy](/powershell/module/configci/new-cipolicy) with **-Level Publisher** (to allow software from their software providers, the "Publishers") and **-Fallback Hash** (to allow the internal, unsigned application). They deploy the policy in auditing mode to determine the potential impact from enforcing the policy. With the help of the audit data, they update their App Control policies to include any other software they want to run. Then they enable the App Control policy in enforced mode for their servers.
As part of normal operations, they'll eventually install software updates, or perhaps add software from the same software providers. Because the "Publisher" remains the same on those updates and software, they don't need to update their WDAC policy. If the unsigned, internal application is updated, they must also update the WDAC policy to allow the new version.
As part of normal operations, they'll eventually install software updates, or perhaps add software from the same software providers. Because the "Publisher" remains the same on those updates and software, they don't need to update their App Control policy. If the unsigned, internal application is updated, they must also update the App Control policy to allow the new version.
## File rule precedence order
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-appcontrol-policies-with-memcm.md) if allowed by the policy. Lastly, WDAC falls back to the [ISG](use-appcontrol-with-intelligent-security-graph.md) if allowed by the policy.
App Control 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, App Control checks for a [Managed Installer claim](../deployment/deploy-appcontrol-policies-with-memcm.md) if allowed by the policy. Lastly, App Control falls back to the [ISG](use-appcontrol-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 versions that support [multiple WDAC policies](/windows/security/threat-protection/windows-defender-application-control/deploy-multiple-windows-defender-application-control-policies).
> To make it easier to reason over your App Control policies, we recommend maintaining separate ALLOW and DENY policies on Windows versions that support [multiple App Control policies](deploy-multiple-appcontrol-policies.md).
## Use -SpecificFileNameLevel with FileName, FilePublisher, or WHQLFilePublisher level rules
@ -125,19 +124,19 @@ Filepath rules don't provide the same security guarantees that explicit signer r
### User-writable filepaths
By default, WDAC performs a user-writeability check at runtime that ensures that the current permissions on the specified filepath only allow write access for admin users.
By default, App Control performs a user-writeability check at runtime that ensures that the current permissions on the specified filepath only allow write access for admin users.
There's a defined list of SIDs that WDAC recognizes as admins. If a filepath allows write permissions for any SID not in this list, the filepath is considered to be user-writeable, even if the SID is associated to a custom admin user. To handle these special cases, you can override WDAC's runtime admin-writeable check with the **Disabled:Runtime FilePath Rule Protection** option described earlier.
There's a defined list of SIDs that App Control recognizes as admins. If a filepath allows write permissions for any SID not in this list, the filepath is considered to be user-writeable, even if the SID is associated to a custom admin user. To handle these special cases, you can override App Control's runtime admin-writeable check with the **Disabled:Runtime FilePath Rule Protection** option described earlier.
WDAC's list of well-known admin SIDs are:
App Control's list of well-known admin SIDs are:
S-1-3-0; S-1-5-18; S-1-5-19; S-1-5-20; S-1-5-32-544; S-1-5-32-549; S-1-5-32-550; S-1-5-32-551; S-1-5-32-577; S-1-5-32-559; S-1-5-32-568; S-1-15-2-1430448594-2639229838-973813799-439329657-1197984847-4069167804-1277922394; S-1-15-2-95739096-486727260-2033287795-3853587803-1685597119-444378811-2746676523.
When filepath rules are generated using [New-CIPolicy](/powershell/module/configci/new-cipolicy), a unique, fully qualified path rule is generated for every file discovered in the scanned path(s). To create rules that instead allow all files under a specified folder path, use [New-CIPolicyRule](/powershell/module/configci/new-cipolicyrule) to define rules containing wildcards, using the [-FilePathRules](/powershell/module/configci/new-cipolicyrule#parameters) switch.
### Using wildcards in WDAC filepath rules
### Using wildcards in App Control filepath rules
The following wildcards can be used in WDAC filepath rules:
The following wildcards can be used in App Control filepath rules:
| Wildcard character | Meaning | Supported operating systems |
|------------ | ----------- | ----------- |
@ -157,30 +156,30 @@ You can also use the following macros when the exact volume may vary: `%OSDRIVE%
|------------ | ----------- | ----------- |
| **C:\\Windows\\\*** <br> **D:\\EnterpriseApps\\MyApp\\\*** <br> **%OSDRIVE%\\Windows\\\*** | Wildcards placed at the end of a path authorize all files in the immediate path and its subdirectories recursively. | Windows 11, Windows 10, and Windows Server 2022 |
| **\*\\bar.exe** | Wildcards placed at the beginning of a path allow the exact specified filename in any location. | Windows 11, Windows 10, and Windows Server 2022 |
| **C:\\\*\\CCMCACHE\\\*\\7z????-x64.exe** <br> **%OSDRIVE%\\\*\\CCMCACHE\\\*\\7z????-x64.exe** | Wildcards used in the middle of a path allow all files that match that pattern. Consider carefully all the possible matches, particularly if your policy disables the admin-writeable check with the **Disabled:Runtime FilePath Rule Protection** option. In this example, both of these hypothetical paths would match: <br> *`C:\WINDOWS\CCMCACHE\12345\7zabcd-x64.exe`* <br> *`C:\USERS\WDACUSER\Downloads\Malware\CCMCACHE\Pwned\7zhaha-x64.exe`* | Windows 11 only |
| **C:\\\*\\CCMCACHE\\\*\\7z????-x64.exe** <br> **%OSDRIVE%\\\*\\CCMCACHE\\\*\\7z????-x64.exe** | Wildcards used in the middle of a path allow all files that match that pattern. Consider carefully all the possible matches, particularly if your policy disables the admin-writeable check with the **Disabled:Runtime FilePath Rule Protection** option. In this example, both of these hypothetical paths would match: <br> *`C:\WINDOWS\CCMCACHE\12345\7zabcd-x64.exe`* <br> *`C:\USERS\AppControlUSER\Downloads\Malware\CCMCACHE\Pwned\7zhaha-x64.exe`* | Windows 11 only |
Without a wildcard, the filepath rule allows only a specific file (ex. `C:\foo\bar.exe`).
> [!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.
> When authoring App Control policies with Configuration Manager, there is an option to create rules for specified files and folders. These rules **aren't** App Control 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.
## 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.
App Control 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, App Control provides added security and less management overhead so customers don't need to revise the policy hash rules when the digital signature on the file is updated.
The Authenticode/PE image hash can be calculated for digitally signed and unsigned files.
### Why does scan create four hash rules per XML file?
The PowerShell cmdlet produces an Authenticode Sha1 Hash, Sha256 Hash, Sha1 Page Hash, Sha256 Page Hash.
During validation, WDAC selects which hashes are calculated based on how the file is signed and the scenario in which the file is used. For example, if the file is page-hash signed, WDAC validates each page of the file and avoids loading the entire file in memory to calculate the full sha256 authenticode hash.
During validation, App Control selects which hashes are calculated based on how the file is signed and the scenario in which the file is used. For example, if the file is page-hash signed, App Control validates each page of the file and avoids loading the entire file in memory to calculate the full sha256 authenticode hash.
In the cmdlets, rather than try to predict which hash will be used, we precalculate and use the four hashes (sha1/sha2 authenticode, and sha1/sha2 of first page). This method is also resilient to changes in how the file is signed since your WDAC policy has more than one hash available for the file already.
In the cmdlets, rather than try to predict which hash will be used, we precalculate and use the four hashes (sha1/sha2 authenticode, and sha1/sha2 of first page). This method is also resilient to changes in how the file is signed since your App Control policy has more than one hash available for the file already.
### Why does scan create eight hash rules for certain files?
Separate rules are created for UMCI and KMCI. If the cmdlets can't determine that a file only runs in user-mode or in the kernel, then rules are created for both signing scenarios out of an abundance of caution. If you know that a particular file only loads in either user-mode or kernel, then you can safely remove the extra rules.
### When does WDAC use the flat file hash value?
### When does App Control use the flat file hash value?
There are some rare cases where a file's format doesn't conform to the Authenticode spec and so WDAC falls back to use the flat file hash. This behavior can occur for many reasons, such as if changes are made to the in-memory version of the file at runtime. In such cases, you'll see that the hash shown in the correlated 3089 signature information event matches the flat file hash from the 3076/3077 block event. To create rules for files with an invalid format, you can add hash rules to the policy for the flat file hash using the WDAC Wizard or by editing the policy XML directly.
There are some rare cases where a file's format doesn't conform to the Authenticode spec and so App Control falls back to use the flat file hash. This behavior can occur for many reasons, such as if changes are made to the in-memory version of the file at runtime. In such cases, you'll see that the hash shown in the correlated 3089 signature information event matches the flat file hash from the 3076/3077 block event. To create rules for files with an invalid format, you can add hash rules to the policy for the flat file hash using the App Control Wizard or by editing the policy XML directly.

39
windows/security/application-security/application-control/app-control-for-business/design/understand-appcontrol-policy-design-decisions.md
View File

@ -1,21 +1,20 @@
---
title: Understand Windows Defender Application Control policy design decisions
description: Understand Windows Defender Application Control policy design decisions.
title: Understand App Control for Business policy design decisions
description: Understand App Control for Business policy design decisions.
ms.localizationpriority: medium
ms.date: 02/08/2018
ms.topic: conceptual
---
# Understand Windows Defender Application Control policy design decisions
# Understand App Control for Business policy design decisions
> [!NOTE]
> Some capabilities of Windows Defender Application Control (WDAC) are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](../feature-availability.md).
[!INCLUDE [Feature availability note](../includes/feature-availability-note.md)]
This article is for the IT professional. It lists the design questions, possible answers, and ramifications for decisions made, when planning application control policies deployment using Windows Defender Application Control (WDAC), within a Windows operating system environment.
This article is for the IT professional. It lists the design questions, possible answers, and ramifications for decisions made, when planning application control policies deployment using App Control for Business, within a Windows operating system environment.
When you begin the design and planning process, you should consider the ramifications of your design choices. The resulting decisions will affect your policy deployment scheme and subsequent application control policy maintenance.
You should consider using Windows Defender Application Control as part of your organization's application control policies if the following are true:
You should consider using App Control for Business as part of your organization's application control policies if the following are true:
- You have deployed or plan to deploy the supported versions of Windows in your organization.
- You need improved control over the access to your organization's applications and the data your users access.
@ -26,28 +25,28 @@ You should consider using Windows Defender Application Control as part of your o
## Decide what policies to create
Beginning with Windows 10, version 1903, Windows Defender Application Control allows [multiple simultaneous policies](deploy-multiple-appcontrol-policies.md) to be applied to each device. This concurrent application opens up many new use cases for organizations, but your policy management can easily become unwieldy without a well-thought-out plan for the number and types of policies to create.
Beginning with Windows 10, version 1903, App Control for Business allows [multiple simultaneous policies](deploy-multiple-appcontrol-policies.md) to be applied to each device. This concurrent application opens up many new use cases for organizations, but your policy management can easily become unwieldy without a well-thought-out plan for the number and types of policies to create.
The first step is to define the desired "circle-of-trust" for your WDAC policies. By "circle-of-trust," we mean a description of the business intent of the policy expressed in natural language. This "circle-of-trust" definition will guide you as you create the actual policy rules for your policy XML.
The first step is to define the desired "circle-of-trust" for your App Control policies. By "circle-of-trust," we mean a description of the business intent of the policy expressed in natural language. This "circle-of-trust" definition will guide you as you create the actual policy rules for your policy XML.
For example, the DefaultWindows policy, which can be found under %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies, establishes a "circle-of-trust" that allows Windows, 3rd-party hardware and software kernel drivers, and applications from the Microsoft Store.
Configuration Manager uses the DefaultWindows policy as the basis for its policy but then modifies the policy rules to allow Configuration Manager and its dependencies, sets the managed installer policy rule, and additionally configures Configuration Manager as a managed installer. It also can optionally authorize apps with positive reputation and perform a one-time scan of folder paths specified by the Configuration Manager administrator, which adds rules for any apps found in the specified paths on the managed endpoint. This process establishes the "circle-of-trust" for Configuration Manager's native WDAC integration.
Configuration Manager uses the DefaultWindows policy as the basis for its policy but then modifies the policy rules to allow Configuration Manager and its dependencies, sets the managed installer policy rule, and additionally configures Configuration Manager as a managed installer. It also can optionally authorize apps with positive reputation and perform a one-time scan of folder paths specified by the Configuration Manager administrator, which adds rules for any apps found in the specified paths on the managed endpoint. This process establishes the "circle-of-trust" for Configuration Manager's native App Control integration.
The following questions can help you plan your Windows Defender Application Control deployment and determine the right "circle-of-trust" for your policies. They aren't in priority or sequential order, and aren't meant to be an exhaustive set of design considerations.
The following questions can help you plan your App Control for Business deployment and determine the right "circle-of-trust" for your policies. They aren't in priority or sequential order, and aren't meant to be an exhaustive set of design considerations.
## WDAC design considerations
## App Control design considerations
### How are apps managed and deployed in your organization?
Organizations with well-defined, centrally managed app management and deployment processes can create more restrictive, more secure policies. Other organizations may be able to deploy Windows Defender Application Control with more relaxed rules, or may choose to deploy WDAC in audit mode to gain better visibility to the apps being used in their organization.
Organizations with well-defined, centrally managed app management and deployment processes can create more restrictive, more secure policies. Other organizations may be able to deploy App Control for Business with more relaxed rules, or may choose to deploy App Control in audit mode to gain better visibility to the apps being used in their organization.
| Possible answers | Design considerations|
| - | - |
| All apps are centrally managed and deployed using endpoint management tools like [Microsoft Intune](https://www.microsoft.com/microsoft-365/microsoft-endpoint-manager). | Organizations that centrally manage all apps are best-suited for application control. Windows Defender Application Control options like [managed installer](configure-authorized-apps-deployed-with-a-managed-installer.md) can make it easy to authorize apps that are deployed by the organization's app distribution management solution. |
| Some apps are centrally managed and deployed, but teams can install other apps for their members. | [Supplemental policies](deploy-multiple-appcontrol-policies.md) can be used to allow team-specific exceptions to your core organization-wide Windows Defender Application Control policy. Alternatively, teams can use managed installers to install their team-specific apps, or admin-only file path rules can be used to allow apps installed by admin users. |
| Users and teams are free to download and install apps but the organization wants to restrict that right to prevalent and reputable apps only. | Windows Defender Application Control can integrate with Microsoft's [Intelligent Security Graph](use-appcontrol-with-intelligent-security-graph.md) (the same source of intelligence that powers Microsoft Defender Antivirus and Windows Defender SmartScreen) to allow only apps and binaries that have positive reputation. |
| Users and teams are free to download and install apps without restriction. | Windows Defender Application Control policies can be deployed in audit mode to gain insight into the apps and binaries running in your organization without impacting user and team productivity.|
| All apps are centrally managed and deployed using endpoint management tools like [Microsoft Intune](https://www.microsoft.com/microsoft-365/microsoft-endpoint-manager). | Organizations that centrally manage all apps are best-suited for application control. App Control for Business options like [managed installer](configure-authorized-apps-deployed-with-a-managed-installer.md) can make it easy to authorize apps that are deployed by the organization's app distribution management solution. |
| Some apps are centrally managed and deployed, but teams can install other apps for their members. | [Supplemental policies](deploy-multiple-appcontrol-policies.md) can be used to allow team-specific exceptions to your core organization-wide App Control for Business policy. Alternatively, teams can use managed installers to install their team-specific apps, or admin-only file path rules can be used to allow apps installed by admin users. |
| Users and teams are free to download and install apps but the organization wants to restrict that right to prevalent and reputable apps only. | App Control for Business can integrate with Microsoft's [Intelligent Security Graph](use-appcontrol-with-intelligent-security-graph.md) (the same source of intelligence that powers Microsoft Defender Antivirus and Windows Defender SmartScreen) to allow only apps and binaries that have positive reputation. |
| Users and teams are free to download and install apps without restriction. | App Control for Business policies can be deployed in audit mode to gain insight into the apps and binaries running in your organization without impacting user and team productivity.|
### Are internally developed line-of-business (LOB) apps and apps developed by third-party companies digitally signed?
@ -55,7 +54,7 @@ Traditional Win32 apps on Windows can run without being digitally signed. This p
| Possible answers | Design considerations |
| - | - |
| All apps used in your organization must be signed. | Organizations that enforce [codesigning](../deployment/use-code-signing-for-better-control-and-protection.md) for all executable code are best-positioned to protect their Windows computers from malicious code execution. Windows Defender Application Control rules can be created to authorize apps and binaries from the organization's internal development teams and from trusted independent software vendors (ISV). |
| All apps used in your organization must be signed. | Organizations that enforce [codesigning](../deployment/use-code-signing-for-better-control-and-protection.md) for all executable code are best-positioned to protect their Windows computers from malicious code execution. App Control for Business rules can be created to authorize apps and binaries from the organization's internal development teams and from trusted independent software vendors (ISV). |
| Apps used in your organization don't need to meet any codesigning requirements. | Organizations can [use built-in Windows tools](../deployment/deploy-catalog-files-to-support-appcontrol.md) to add organization-specific App Catalog signatures to existing apps as a part of the app deployment process, which can be used to authorize code execution. Solutions like Microsoft Intune offer multiple ways to distribute signed App Catalogs. |
### Are there specific groups in your organization that need customized application control policies?
@ -64,8 +63,8 @@ Most business teams or departments have specific security requirements that pert
| Possible answers | Design considerations |
| - | - |
| Yes | WDAC policies can be created unique per team, or team-specific supplemental policies can be used to expand what is allowed by a common, centrally defined base policy.|
| No | WDAC policies can be applied globally to applications that are installed on PCs running Windows 10 and Windows 11. Depending on the number of apps you need to control, managing all the rules and exceptions might be challenging.|
| Yes | App Control policies can be created unique per team, or team-specific supplemental policies can be used to expand what is allowed by a common, centrally defined base policy.|
| No | App Control policies can be applied globally to applications that are installed on PCs running Windows 10 and Windows 11. Depending on the number of apps you need to control, managing all the rules and exceptions might be challenging.|
### Does your IT department have resources to analyze application usage, and to design and manage the policies?

14
windows/security/application-security/application-control/app-control-for-business/design/understanding-appcontrol-policy-settings.md
View File

@ -1,16 +1,16 @@
---
title: Understanding Windows Defender Application Control (WDAC) secure settings
description: Learn about secure settings in Windows Defender Application Control.
title: Understanding App Control for Business secure settings
description: Learn about secure settings in App Control for Business.
ms.localizationpriority: medium
ms.date: 04/05/2023
ms.topic: conceptual
---
# Understanding WDAC Policy Settings
# Understanding App Control 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, ValueName, and a setting value. Setting values can be of type boolean, ulong, binary, and string. Applications can query for policy settings using WldpQuerySecurityPolicy.
App Control for Business 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:
An example settings section of a App Control for Business policy:
```xml
<Settings>
@ -24,11 +24,11 @@ An example settings section of a Windows Defender Application Control policy:
## 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.
An application that may want to restrict its capabilities, when used on a system with an active App Control for Business policy. Application authors can define a App Control 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 App Control policy setting, and query for it at runtime. Contoso can then instruct IT administrators to configure the setting in their App Control policy, if they don't want Foo Application to execute macros on a system with a App Control policy.
## WldpQuerySecurityPolicy
API that queries the secure settings of a Windows Defender Application Control policy.
API that queries the secure settings of a App Control for Business policy.
### Syntax

15
windows/security/application-security/application-control/app-control-for-business/design/use-appcontrol-policy-to-control-specific-plug-ins-add-ins-and-modules.md
View File

@ -1,31 +1,30 @@
---
title: Use a Windows Defender Application Control policy to control specific plug-ins, add-ins, and modules
description: WDAC policies can be used not only to control applications, but also to control whether specific plug-ins, add-ins, and modules can run from specific apps.
title: Use a App Control for Business policy to control specific plug-ins, add-ins, and modules
description: App Control policies can be used not only to control applications, but also to control whether specific plug-ins, add-ins, and modules can run from specific apps.
ms.localizationpriority: medium
ms.date: 11/02/2022
ms.topic: how-to
---
# Use a Windows Defender Application Control policy to control specific plug-ins, add-ins, and modules
# Use a App Control for Business policy to control specific plug-ins, add-ins, and modules
> [!NOTE]
> Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](../feature-availability.md).
[!INCLUDE [Feature availability note](../includes/feature-availability-note.md)]
You can use Windows Defender Application Control (WDAC) policies to control applications and also to control whether specific plug-ins, add-ins, and modules can run from specific apps (such as a line-of-business application or a browser):
You can use App Control for Business policies to control applications and also to control whether specific plug-ins, add-ins, and modules can run from specific apps (such as a line-of-business application or a browser):
| Approach | Guideline |
|---|---|
| You can work from a list of plug-ins, add-ins, or modules that you want only a specific application to be able to run. Other applications would be blocked from running them. | Use `New-CIPolicyRule` with the `-AppID` option. |
| In addition, you can work from a list of plug-ins, add-ins, or modules that you want to block in a specific application. Other applications would be allowed to run them. | Use `New-CIPolicyRule` with the `-AppID` and `-Deny` options. |
For example, to add rules to a WDAC policy called "Lamna_FullyManagedClients_Audit.xml" that allow **addin1.dll** and **addin2.dll** to be run by **ERP1.exe**, Lamna's enterprise resource planning (ERP) application, run the following commands. In the second command, **+=** is used to add a second rule to the **$rule** variable:
For example, to add rules to a App Control policy called "Lamna_FullyManagedClients_Audit.xml" that allow **addin1.dll** and **addin2.dll** to be run by **ERP1.exe**, Lamna's enterprise resource planning (ERP) application, run the following commands. In the second command, **+=** is used to add a second rule to the **$rule** variable:
```powershell
$rule = New-CIPolicyRule -DriverFilePath '.\temp\addin1.dll' -Level FileName -AppID '.\ERP1.exe'
$rule += New-CIPolicyRule -DriverFilePath '.\temp\addin2.dll' -Level FileName -AppID '.\ERP1.exe'
```
As another example, to create a Windows Defender Application Control policy that blocks **addin3.dll** from running in Microsoft Word, run the following command. You must include the `-Deny` option to block the specified add-ins in the specified application. Once you have all the rules you want, you can merge them into an existing WDAC policy using the Merge-CIPolicy cmdlet as shown here:
As another example, to create a App Control for Business policy that blocks **addin3.dll** from running in Microsoft Word, run the following command. You must include the `-Deny` option to block the specified add-ins in the specified application. Once you have all the rules you want, you can merge them into an existing App Control policy using the Merge-CIPolicy cmdlet as shown here:
```powershell
$rule += New-CIPolicyRule -DriverFilePath '.\temp\addin3.dll' -Level FileName -Deny -AppID '.\winword.exe'

39
windows/security/application-security/application-control/app-control-for-business/design/use-appcontrol-with-intelligent-security-graph.md
View File

@ -8,38 +8,37 @@ ms.topic: how-to
# Authorize reputable apps with the Intelligent Security Graph (ISG)
> [!NOTE]
> Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](../feature-availability.md).
[!INCLUDE [Feature availability note](../includes/feature-availability-note.md)]
Application control can be difficult to implement in organizations that don't deploy and manage applications through an IT-managed system. In such environments, users can acquire the applications they want to use for work, making it hard to build an effective application control policy.
To reduce end-user friction and helpdesk calls, you can set Windows Defender Application Control (WDAC) to automatically allow applications that Microsoft's Intelligent Security Graph (ISG) recognizes as having known good reputation. The ISG option helps organizations begin to implement application control even when the organization has limited control over their app ecosystem. To learn more about the ISG, see the Security section in [Major services and features in Microsoft Graph](/graph/overview-major-services).
To reduce end-user friction and helpdesk calls, you can set App Control for Business to automatically allow applications that Microsoft's Intelligent Security Graph (ISG) recognizes as having known good reputation. The ISG option helps organizations begin to implement application control even when the organization has limited control over their app ecosystem. To learn more about the ISG, see the Security section in [Major services and features in Microsoft Graph](/graph/overview-major-services).
> [!WARNING]
> Binaries that are critical to boot the system must be allowed using explicit rules in your WDAC policy. Do not rely on the ISG to authorize these files.
> Binaries that are critical to boot the system must be allowed using explicit rules in your App Control policy. Do not rely on the ISG to authorize these files.
>
> The ISG option is not the recommended way to allow apps that are business critical. You should always authorize business critical apps using explicit allow rules or by installing them with a [managed installer](/windows/security/threat-protection/windows-defender-application-control/configure-authorized-apps-deployed-with-a-managed-installer).
> The ISG option is not the recommended way to allow apps that are business critical. You should always authorize business critical apps using explicit allow rules or by installing them with a [managed installer](configure-authorized-apps-deployed-with-a-managed-installer.md).
## How does WDAC work with the ISG?
## How does App Control work with the ISG?
The ISG isn't a "list" of apps. Rather, it uses the same vast security intelligence and machine learning analytics that power Microsoft Defender SmartScreen and Microsoft Defender Antivirus to help classify applications as having "known good", "known bad", or "unknown" reputation. This cloud-based AI is based on trillions of signals collected from Windows endpoints and other data sources, and processed every 24 hours. As a result, the decision from the cloud can change.
WDAC only checks the ISG for binaries that aren't explicitly allowed or denied by your policy, and that weren't installed by a managed installer. When such a binary runs on a system with WDAC enabled with the ISG option, WDAC will check the file's reputation by sending its hash and signing information to the cloud. If the ISG reports that the file has a "known good" reputation, then the file will be allowed to run. Otherwise, it will be blocked by WDAC.
App Control only checks the ISG for binaries that aren't explicitly allowed or denied by your policy, and that weren't installed by a managed installer. When such a binary runs on a system with App Control enabled with the ISG option, App Control will check the file's reputation by sending its hash and signing information to the cloud. If the ISG reports that the file has a "known good" reputation, then the file will be allowed to run. Otherwise, it will be blocked by App Control.
If the file with good reputation is an application installer, the installer's reputation will pass along to any files that it writes to disk. This way, all the files needed to install and run an app inherit the positive reputation data from the installer. Files authorized based on the installer's reputation will have the $KERNEL.SMARTLOCKER.ORIGINCLAIM kernel Extended Attribute (EA) written to the file.
WDAC periodically requeries the reputation data on a file. Additionally, enterprises can specify that any cached reputation results are flushed on reboot by using the **Enabled:Invalidate EAs on Reboot** option.
App Control periodically requeries the reputation data on a file. Additionally, enterprises can specify that any cached reputation results are flushed on reboot by using the **Enabled:Invalidate EAs on Reboot** option.
## Configuring ISG authorization for your WDAC policy
## Configuring ISG authorization for your App Control policy
Setting up the ISG is easy using any management solution you wish. Configuring the ISG option involves these basic steps:
- [Ensure that the **Enabled:Intelligent Security Graph authorization** option is set in the WDAC policy XML](#ensure-that-the-isg-option-is-set-in-the-wdac-policy-xml)
- [Enable the necessary services to allow WDAC to use the ISG correctly on the client](#enable-the-necessary-services-to-allow-wdac-to-use-the-isg-correctly-on-the-client)
- [Ensure that the **Enabled:Intelligent Security Graph authorization** option is set in the App Control policy XML](#ensure-that-the-isg-option-is-set-in-the-app-control-policy-xml)
- [Enable the necessary services to allow App Control to use the ISG correctly on the client](#enable-the-necessary-services-to-allow-app-control-to-use-the-isg-correctly-on-the-client)
### Ensure that the ISG option is set in the WDAC policy XML
### Ensure that the ISG option is set in the App Control policy XML
To allow apps and binaries based on the Microsoft Intelligent Security Graph, the **Enabled:Intelligent Security Graph authorization** option must be specified in the WDAC policy. This step can be done with the Set-RuleOption cmdlet. You should also set the **Enabled:Invalidate EAs on Reboot** option so that ISG results are verified again after each reboot. The ISG option isn't recommended for devices that don't have regular access to the internet. The following example shows both options set.
To allow apps and binaries based on the Microsoft Intelligent Security Graph, the **Enabled:Intelligent Security Graph authorization** option must be specified in the App Control policy. This step can be done with the Set-RuleOption cmdlet. You should also set the **Enabled:Invalidate EAs on Reboot** option so that ISG results are verified again after each reboot. The ISG option isn't recommended for devices that don't have regular access to the internet. The following example shows both options set.
```xml
<Rules>
@ -67,7 +66,7 @@ To allow apps and binaries based on the Microsoft Intelligent Security Graph, th
</Rules>
```
### Enable the necessary services to allow WDAC to use the ISG correctly on the client
### Enable the necessary services to allow App Control to use the ISG correctly on the client
In order for the heuristics used by the ISG to function properly, other components in Windows must be enabled. You can configure these components by running the appidtel executable in `c:\windows\system32`.
@ -75,23 +74,23 @@ In order for the heuristics used by the ISG to function properly, other componen
appidtel start
```
This step isn't required for WDAC policies deployed over MDM, as the CSP will enable the necessary components. This step is also not required when the ISG is configured using Configuration Manager's WDAC integration.
This step isn't required for App Control policies deployed over MDM, as the CSP will enable the necessary components. This step is also not required when the ISG is configured using Configuration Manager's App Control integration.
## Security considerations with the ISG option
Since the ISG is a heuristic-based mechanism, it doesn't provide the same security guarantees as explicit allow or deny rules. It's best suited where users operate with standard user rights and where a security monitoring solution like Microsoft Defender for Endpoint is used.
Processes running with kernel privileges can circumvent WDAC by setting the ISG extended file attribute to make a binary appear to have known good reputation.
Processes running with kernel privileges can circumvent App Control by setting the ISG extended file attribute to make a binary appear to have known good reputation.
Also, since the ISG option passes along reputation from app installers to the binaries they write to disk, it can over-authorize files in some cases. For example, if the installer launches the app upon completion, any files the app writes during that first run will also be allowed.
## Known limitations with using the ISG
Since the ISG only allows binaries that are "known good", there are cases where the ISG may be unable to predict whether legitimate software is safe to run. If that happens, the software will be blocked by WDAC. In this case, you need to allow the software with a rule in your WDAC policy, deploy a catalog signed by a certificate trusted in the WDAC policy, or install the software from a WDAC managed installer. Installers or applications that dynamically create binaries at runtime, and self-updating applications, may exhibit this symptom.
Since the ISG only allows binaries that are "known good", there are cases where the ISG may be unable to predict whether legitimate software is safe to run. If that happens, the software will be blocked by App Control. In this case, you need to allow the software with a rule in your App Control policy, deploy a catalog signed by a certificate trusted in the App Control policy, or install the software from a App Control managed installer. Installers or applications that dynamically create binaries at runtime, and self-updating applications, may exhibit this symptom.
Packaged apps aren't supported with the ISG and will need to be separately authorized in your WDAC policy. Since packaged apps have a strong app identity and must be signed, it's straightforward to [authorize packaged apps](/windows/security/threat-protection/windows-defender-application-control/manage-packaged-apps-with-windows-defender-application-control) with your WDAC policy.
Packaged apps aren't supported with the ISG and will need to be separately authorized in your App Control policy. Since packaged apps have a strong app identity and must be signed, it's straightforward to [authorize packaged apps](manage-packaged-apps-with-appcontrol.md) with your App Control policy.
The ISG doesn't authorize kernel mode drivers. The WDAC policy must have rules that allow the necessary drivers to run.
The ISG doesn't authorize kernel mode drivers. The App Control policy must have rules that allow the necessary drivers to run.
> [!NOTE]
> A rule that explicitly denies or allows a file will take precedence over that file's reputation data. Microsoft Intune's built-in WDAC support includes the option to trust apps with good reputation via the ISG, but it has no option to add explicit allow or deny rules. In most cases, customers using application control will need to deploy a custom WDAC policy (which can include the ISG option if desired) using [Intune's OMA-URI functionality](../deployment/deploy-appcontrol-policies-using-intune.md#deploy-wdac-policies-with-custom-oma-uri).
> A rule that explicitly denies or allows a file will take precedence over that file's reputation data. Microsoft Intune's built-in App Control support includes the option to trust apps with good reputation via the ISG, but it has no option to add explicit allow or deny rules. In most cases, customers using application control will need to deploy a custom App Control policy (which can include the ISG option if desired) using [Intune's OMA-URI functionality](../deployment/deploy-appcontrol-policies-using-intune.md#deploy-app-control-policies-with-custom-oma-uri).

32
windows/security/application-security/application-control/app-control-for-business/feature-availability.md
View File

@ -1,30 +1,30 @@
---
title: Windows Defender Application Control feature availability
description: Compare Windows Defender Application Control (WDAC) and AppLocker feature availability.
title: App Control for Business feature availability
description: Compare App Control for Business and AppLocker feature availability.
ms.localizationpriority: medium
ms.date: 12/21/2023
ms.topic: overview
---
# Windows Defender Application Control and AppLocker feature availability
# App Control for Business and AppLocker feature availability
> [!NOTE]
> Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Review the following table to learn more.
> Some capabilities of App Control for Business are only available on specific Windows versions. Review the following table to learn more.
| Capability | Windows Defender Application Control | AppLocker |
| Capability | App Control for Business | AppLocker |
|-------------|------|-------------|
| Platform support | Available on Windows 10, Windows 11, and Windows Server 2016 or later. | Available on Windows 8 or later. |
| Edition availability | Available on Windows 10, Windows 11, and Windows Server 2016 or later. <br> WDAC PowerShell cmdlets aren't available on Home edition, but policies are effective on all editions. | Policies are supported on all editions Windows 10 version 2004 and newer with [KB 5024351](https://support.microsoft.com/help/5024351).<br><br>Windows versions older than version 2004, including Windows Server 2019:<br><ul><li>Policies deployed through GP are only supported on Enterprise and Server editions.</li><li>Policies deployed through MDM are supported on all editions.</li></ul>|
| Management solutions | <ul><li>[Intune](deployment/deploy-appcontrol-policies-using-intune.md)</li><li>[Microsoft Configuration Manager](/configmgr/protect/deploy-use/use-device-guard-with-configuration-manager) (limited built-in policies or custom policy deployment via software distribution)</li><li>[Group policy](deployment/deploy-appcontrol-policies-using-group-policy.md) </li><li>[Script](/windows/security/threat-protection/windows-defender-application-control/deployment/deploy-wdac-policies-with-script)</li></ul> | <ul><li>[Intune](/windows/client-management/mdm/applocker-csp) (custom policy deployment via OMA-URI only)</li><li>Configuration Manager (custom policy deployment via software distribution only)</li><li>[Group Policy](applocker/determine-group-policy-structure-and-rule-enforcement.md)</li><li>PowerShell</li><ul> |
| Edition availability | Available on Windows 10, Windows 11, and Windows Server 2016 or later. <br> App Control PowerShell cmdlets aren't available on Home edition, but policies are effective on all editions. | Policies are supported on all editions Windows 10 version 2004 and newer with [KB 5024351](https://support.microsoft.com/help/5024351).<br><br>Windows versions older than version 2004, including Windows Server 2019:<br><ul><li>Policies deployed through GP are only supported on Enterprise and Server editions.</li><li>Policies deployed through MDM are supported on all editions.</li></ul>|
| Management solutions | <ul><li>[Intune](deployment/deploy-appcontrol-policies-using-intune.md)</li><li>[Microsoft Configuration Manager](/configmgr/protect/deploy-use/use-device-guard-with-configuration-manager) (limited built-in policies or custom policy deployment via software distribution)</li><li>[Group policy](deployment/deploy-appcontrol-policies-using-group-policy.md) </li><li>[Script](deployment/deploy-appcontrol-policies-with-script.md)</li></ul> | <ul><li>[Intune](/windows/client-management/mdm/applocker-csp) (custom policy deployment via OMA-URI only)</li><li>Configuration Manager (custom policy deployment via software distribution only)</li><li>[Group Policy](applocker/determine-group-policy-structure-and-rule-enforcement.md)</li><li>PowerShell</li><ul> |
| Per-user and Per-user group rules | Not available (policies are device-wide). | Available on Windows 8+. |
| Kernel mode policies | Available on Windows 10, Windows 11, and Windows Server 2016 or later. | Not available. |
| [Rule option 11 - Disabled:Script Enforcement](/windows/security/threat-protection/windows-defender-application-control/design/script-enforcement) | Available on all versions of Windows 10 except 1607 LTSB, Windows 11, and Windows Server 2019 and above. **Disabled:Script Enforcement** isn't supported on **Windows Server 2016** or on **Windows 10 1607 LTSB** and shouldn't be used on those platforms. Doing so results in unexpected script enforcement behaviors. | MSI and Script rule collection is separately configurable. |
| [Per-app rules](/windows/security/threat-protection/windows-defender-application-control/use-windows-defender-application-control-policy-to-control-specific-plug-ins-add-ins-and-modules) | Available on Windows 10, Windows 11, and Windows Server 2019 or later. | Not available. |
| [Managed Installer (MI)](/windows/security/threat-protection/windows-defender-application-control/configure-authorized-apps-deployed-with-a-managed-installer) | Available on Windows 10, Windows 11, and Windows Server 2019 or later. | Not available. |
| [Reputation-Based intelligence](/windows/security/threat-protection/windows-defender-application-control/use-windows-defender-application-control-with-intelligent-security-graph) | Available on Windows 10, Windows 11, and Windows Server 2019 or later. | Not available. |
| [Multiple policy support](/windows/security/threat-protection/windows-defender-application-control/deploy-multiple-windows-defender-application-control-policies) | Available on Windows 10, version 1903 and above, Windows 11, and Windows Server 2022. | Not available. |
| [Path-based rules](/windows/security/threat-protection/windows-defender-application-control/select-types-of-rules-to-create) | Available on Windows 10, version 1903 and above, Windows 11, and Windows Server 2022 or later. Exclusions aren't supported. Runtime user-writeability checks enforced by default. | Available on Windows 8+. Exclusions are supported. No runtime user-writeability check. |
| [COM object allowlisting](/windows/security/threat-protection/windows-defender-application-control/allow-com-object-registration-in-windows-defender-application-control-policy) | Available on Windows 10, Windows 11, and Windows Server 2019 or later. | Not available. |
| [Packaged app rules](/windows/security/threat-protection/windows-defender-application-control/manage-packaged-apps-with-windows-defender-application-control) | Available on Windows 10, Windows 11, and Windows Server 2019 or later. | Available on Windows 8+. |
| [Rule option 11 - Disabled:Script Enforcement](design/script-enforcement.md) | Available on all versions of Windows 10 except 1607 LTSB, Windows 11, and Windows Server 2019 and above. **Disabled:Script Enforcement** isn't supported on **Windows Server 2016** or on **Windows 10 1607 LTSB** and shouldn't be used on those platforms. Doing so results in unexpected script enforcement behaviors. | MSI and Script rule collection is separately configurable. |
| [Per-app rules](design/use-appcontrol-policy-to-control-specific-plug-ins-add-ins-and-modules.md) | Available on Windows 10, Windows 11, and Windows Server 2019 or later. | Not available. |
| [Managed Installer (MI)](design/configure-authorized-apps-deployed-with-a-managed-installer.md) | Available on Windows 10, Windows 11, and Windows Server 2019 or later. | Not available. |
| [Reputation-Based intelligence](design/use-appcontrol-with-intelligent-security-graph.md) | Available on Windows 10, Windows 11, and Windows Server 2019 or later. | Not available. |
| [Multiple policy support](design/deploy-multiple-appcontrol-policies.md) | Available on Windows 10, version 1903 and above, Windows 11, and Windows Server 2022. | Not available. |
| [Path-based rules](design/select-types-of-rules-to-create.md) | Available on Windows 10, version 1903 and above, Windows 11, and Windows Server 2022 or later. Exclusions aren't supported. Runtime user-writeability checks enforced by default. | Available on Windows 8+. Exclusions are supported. No runtime user-writeability check. |
| [COM object allowlisting](design/allow-com-object-registration-in-appcontrol-policy.md) | Available on Windows 10, Windows 11, and Windows Server 2019 or later. | Not available. |
| [Packaged app rules](design/manage-packaged-apps-with-appcontrol.md) | Available on Windows 10, Windows 11, and Windows Server 2019 or later. | Available on Windows 8+. |
| Enforceable file types | <ul><li>Driver files: .sys</li><li>Executable files: .exe and .com</li><li>DLLs: .dll, .rll and .ocx</li><li>Windows Installer files: .msi, .mst, and .msp</li><li>Scripts: .ps1, .vbs, and .js</li><li>Packaged apps and packaged app installers: .appx</li></ul>| <ul><li>Executable files: .exe and .com</li><li>[Optional] DLLs: .dll, .rll and .ocx</li><li>Windows Installer files: .msi, .mst, and .msp</li><li>Scripts: .ps1, .bat, .cmd, .vbs, and .js</li><li>Packaged apps and packaged app installers: .appx</li></ul>|
| [Application ID (AppId) Tagging](/windows/security/threat-protection/windows-defender-application-control/AppIdTagging/windows-defender-application-control-appid-tagging-guide) | Available on Windows 10, version 20H1 and later, and Windows 11. | Not available. |
| [Application ID (AppId) Tagging](AppIdTagging/appcontrol-appid-tagging-guide.md) | Available on Windows 10, version 20H1 and later, and Windows 11. | Not available. |

9
windows/security/application-security/application-control/app-control-for-business/includes/feature-availability-note.md Normal file
View File

@ -0,0 +1,9 @@
---
author: vinaypamnani-msft
ms.author: vinpa
ms.topic: include
ms.date: 09/11/2024
---
> [!NOTE]
> Some capabilities of App Control for Business are only available on specific Windows versions. Learn more about [App Control feature availability](../feature-availability.md).

32
windows/security/application-security/application-control/app-control-for-business/index.yml
View File

@ -3,7 +3,7 @@
title: Application Control for Windows
metadata:
title: Application Control for Windows
description: Landing page for Windows Defender Application Control
description: Landing page for App Control for Business
ms.topic: landing-page
author: vinaypamnani-msft
ms.author: vinpa
@ -20,11 +20,11 @@ landingContent:
links:
- text: What is Application Control?
url: appcontrol.md
- text: What is Windows Defender Application Control (WDAC)?
- text: What is App Control for Business?
url: appcontrol-and-applocker-overview.md
- text: What is AppLocker?
url: applocker\applocker-overview.md
- text: WDAC and AppLocker feature availability
- text: App Control and AppLocker feature availability
url: feature-availability.md
# Card
- title: Learn about Policy Design
@ -33,31 +33,31 @@ landingContent:
links:
- text: Using code signing to simplify application control
url: deployment/use-code-signing-for-better-control-and-protection.md
- text: Applications that can bypass WDAC and how to block them
- text: Applications that can bypass App Control and how to block them
url: design/applications-that-can-bypass-appcontrol.md
- text: Microsoft's Recommended Driver Blocklist
url: design/microsoft-recommended-driver-block-rules.md
- text: Example WDAC policies
- text: Example App Control policies
url: design/example-appcontrol-base-policies.md
- text: Managing multiple policies
url: design/deploy-multiple-appcontrol-policies.md
- linkListType: how-to-guide
links:
- text: Create a WDAC policy for a lightly managed device
- text: Create a App Control policy for a lightly managed device
url: design/create-appcontrol-policy-for-lightly-managed-devices.md
- text: Create a WDAC policy for a fully managed device
- text: Create a App Control policy for a fully managed device
url: design/create-appcontrol-policy-for-fully-managed-devices.md
- text: Create a WDAC policy for a fixed-workload
- text: Create a App Control policy for a fixed-workload
url: design/create-appcontrol-policy-using-reference-computer.md
- text: Create a WDAC blocklist policy
- text: Create a App Control blocklist policy
url: design/create-appcontrol-deny-policy.md
- text: Deploying catalog files for WDAC management
- text: Deploying catalog files for App Control management
url: deployment/deploy-catalog-files-to-support-appcontrol.md
- text: Using the WDAC Wizard
- text: Using the App Control Wizard
url: design/appcontrol-wizard.md
#- linkListType: Tutorial (videos)
# links:
# - text: Using the WDAC Wizard
# - text: Using the App Control Wizard
# url: video md
# - text: Specifying custom values
# url: video md
@ -68,7 +68,7 @@ landingContent:
links:
- text: Understanding policy and file rules
url: design/select-types-of-rules-to-create.md
- text: Understanding WDAC secure settings
- text: Understanding App Control secure settings
url: design/understanding-appcontrol-policy-settings.md
- linkListType: how-to-guide
links:
@ -83,7 +83,7 @@ landingContent:
- text: Manage plug-ins, add-ins, and modules
url: design/use-appcontrol-policy-to-control-specific-plug-ins-add-ins-and-modules.md
# Card
- title: Learn how to deploy WDAC Policies
- title: Learn how to deploy App Control Policies
linkLists:
- linkListType: overview
links:
@ -93,7 +93,7 @@ landingContent:
url: deployment/audit-appcontrol-policies.md
- text: Enforcement mode policies
url: deployment/enforce-appcontrol-policies.md
- text: Disabling WDAC policies
- text: Disabling App Control policies
url: deployment/disable-appcontrol-policies.md
- linkListType: tutorial
links:
@ -106,7 +106,7 @@ landingContent:
- text: Deployment with group policy
url: deployment/deploy-appcontrol-policies-using-group-policy.md
# Card
- title: Learn how to troubleshoot and debug WDAC events
- title: Learn how to troubleshoot and debug App Control events
linkLists:
- linkListType: overview
links:

117
windows/security/application-security/application-control/app-control-for-business/operations/appcontrol-debugging-and-troubleshooting.md
View File

@ -1,24 +1,23 @@
---
title: WDAC debugging and troubleshooting guide
description: Learn how to debug and troubleshoot app and script failures when using WDAC
title: App Control debugging and troubleshooting guide
description: Learn how to debug and troubleshoot app and script failures when using App Control
ms.topic: how-to
ms.date: 04/06/2023
---
# WDAC debugging and troubleshooting
# App Control debugging and troubleshooting
> [!NOTE]
> Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
[!INCLUDE [Feature availability note](../includes/feature-availability-note.md)]
This article describes how to debug and troubleshoot app and script failures when using Windows Defender Application Control (WDAC).
This article describes how to debug and troubleshoot app and script failures when using App Control for Business.
## 1 - Gather WDAC diagnostic data
## 1 - Gather App Control diagnostic data
Before debugging and troubleshooting WDAC issues, you must collect information from a device exhibiting the problem behavior.
Before debugging and troubleshooting App Control issues, you must collect information from a device exhibiting the problem behavior.
Run the following commands from an elevated PowerShell window to collect the diagnostic information you may need:
1. Gather general WDAC diagnostic data and copy it to %userprofile%\AppData\Local\Temp\DiagOutputDir\CiDiag:
1. Gather general App Control diagnostic data and copy it to %userprofile%\AppData\Local\Temp\DiagOutputDir\CiDiag:
```powershell
cidiag.exe /stop
@ -26,9 +25,9 @@ Run the following commands from an elevated PowerShell window to collect the dia
If CiDiag.exe isn't present in your version of Windows, gather this information manually:
- WDAC policy binaries from the [Windows and EFI system partitions](known-issues.md#wdac-policy-file-locations)
- [WDAC event logs](#core-wdac-event-logs)
- [AppLocker event logs](#core-wdac-event-logs)
- App Control policy binaries from the [Windows and EFI system partitions](known-issues.md#app-control-policy-file-locations)
- [App Control event logs](#core-app-control-event-logs)
- [AppLocker event logs](#core-app-control-event-logs)
- [Other event logs that may contain useful information](#other-windows-event-logs-that-may-be-useful) from other Windows apps and services
2. Save the device's System Information to the CiDiag folder:
@ -37,7 +36,7 @@ Run the following commands from an elevated PowerShell window to collect the dia
msinfo32.exe /report $env:USERPROFILE\AppData\Local\Temp\DiagOutputDir\CiDiag\SystemInformation.txt
```
3. Use [CiTool.exe](citool-commands.md) to inventory the list of WDAC policies on the device. Skip this step if CiTool.exe isn't present in your version of Windows.
3. Use [CiTool.exe](citool-commands.md) to inventory the list of App Control policies on the device. Skip this step if CiTool.exe isn't present in your version of Windows.
```powershell
citool.exe -lp -json > $env:USERPROFILE\AppData\Local\Temp\DiagOutputDir\CiDiag\CiToolOutput.json
@ -76,9 +75,9 @@ Run the following commands from an elevated PowerShell window to collect the dia
sc.exe query appid > $env:USERPROFILE\AppData\Local\Temp\DiagOutputDir\CiDiag\AppLockerServices.txt; sc.exe query appidsvc >> $env:USERPROFILE\AppData\Local\Temp\DiagOutputDir\CiDiag\AppLockerServices.txt; sc.exe query applockerfltr >> $env:USERPROFILE\AppData\Local\Temp\DiagOutputDir\CiDiag\AppLockerServices.txt
```
### Core WDAC event logs
### Core App Control event logs
WDAC events are generated under two locations:
App Control events are generated under two locations:
- Applications and Services logs - Microsoft - Windows - CodeIntegrity - Operational
- Applications and Services logs - Microsoft - Windows - AppLocker - MSI and Script
@ -87,7 +86,7 @@ Within the CiDiag output directory, these event logs are called CIOperational.ev
### Other Windows event logs that may be useful
Sometimes, you may be able to supplement the information contained in the core WDAC event logs with information found in these other event logs. CIDiag.exe doesn't collect the ones shown in *italics*.
Sometimes, you may be able to supplement the information contained in the core App Control event logs with information found in these other event logs. CIDiag.exe doesn't collect the ones shown in *italics*.
- Applications and Services logs - Microsoft - Windows - CodeIntegrity - Verbose
- Applications and Services logs - Microsoft - Windows - AppLocker - EXE and DLL
@ -104,61 +103,61 @@ Sometimes, you may be able to supplement the information contained in the core W
Having gathered the necessary diagnostic information from a device, you're ready to begin your analysis of the diagnostic data collected in the previous section.
1. Verify the set of WDAC policies that are active and enforced. Confirm that only those policies you expect to be active are currently active. Be aware of the [Windows inbox policies](inbox-appcontrol-policies.md) that may also be active. You can use either of these methods:
1. Verify the set of App Control policies that are active and enforced. Confirm that only those policies you expect to be active are currently active. Be aware of the [Windows inbox policies](inbox-appcontrol-policies.md) that may also be active. You can use either of these methods:
- Review the output from *CiTool.exe -lp*, if applicable, which was saved to the CIDiag output directory as CiToolOutput.json. See [use Microsoft Edge to view the formatted json file](/microsoft-edge/devtools-guide-chromium/json-viewer/json-viewer).
- Review all [policy activation events](/windows/security/threat-protection/windows-defender-application-control/event-id-explanations#wdac-policy-activation-events) from the core WDAC event log found at **Applications and Services logs - Microsoft - Windows - CodeIntegrity - Operational**. Within the CIDiag output directory, this event log is called CIOperational.evtx.
- Review all [policy activation events](event-id-explanations.md#app-control-policy-activation-events) from the core App Control event log found at **Applications and Services logs - Microsoft - Windows - CodeIntegrity - Operational**. Within the CIDiag output directory, this event log is called CIOperational.evtx.
2. Review any [block events for executables, dlls, and drivers](/windows/security/threat-protection/windows-defender-application-control/event-id-explanations#wdac-block-events-for-executables-dlls-and-drivers) from the core WDAC event log found at **Applications and Services logs - Microsoft - Windows - CodeIntegrity - Operational**. Within the CIDiag output directory, this event log is called CIOperational.evtx. Use information from the block events and their correlated 3089 signature details event(s) to investigate any blocks that are unexplained or unexpected. See the blocked executable example described later in this article for reference.
3. Review any [block events for packaged apps, MSI installers, scripts, and COM objects](/windows/security/threat-protection/windows-defender-application-control/event-id-explanations#wdac-block-events-for-packaged-apps-msi-installers-scripts-and-com-objects) from the core script enforcement event log found at **Applications and Services logs - Microsoft - Windows - AppLocker - MSI and Script**. Within the CIDiag output directory, this event log is called ALMsiAndScript.evtx. Use information from the block events and their correlated 8038 signature details event(s) to investigate any blocks that are unexplained or unexpected.
2. Review any [block events for executables, dlls, and drivers](event-id-explanations.md#app-control-block-events-for-executables-dlls-and-drivers) from the core App Control event log found at **Applications and Services logs - Microsoft - Windows - CodeIntegrity - Operational**. Within the CIDiag output directory, this event log is called CIOperational.evtx. Use information from the block events and their correlated 3089 signature details event(s) to investigate any blocks that are unexplained or unexpected. See the blocked executable example described later in this article for reference.
3. Review any [block events for packaged apps, MSI installers, scripts, and COM objects](event-id-explanations.md#app-control-block-events-for-packaged-apps-msi-installers-scripts-and-com-objects) from the core script enforcement event log found at **Applications and Services logs - Microsoft - Windows - AppLocker - MSI and Script**. Within the CIDiag output directory, this event log is called ALMsiAndScript.evtx. Use information from the block events and their correlated 8038 signature details event(s) to investigate any blocks that are unexplained or unexpected.
Most WDAC-related issues, including app and script failures, can be diagnosed using the preceding steps.
Most App Control-related issues, including app and script failures, can be diagnosed using the preceding steps.
### Event analysis for an example blocked executable
Here's an example of detailed EventData from a typical WDAC enforcement mode block event 3077, and one of its correlated 3089 signature information events. The tables that follow each event screenshot describe some of the elements contained in the events. Following the event descriptions is a step-by-step walkthrough explaining how to use the events to understand why the block occurred.
Here's an example of detailed EventData from a typical App Control enforcement mode block event 3077, and one of its correlated 3089 signature information events. The tables that follow each event screenshot describe some of the elements contained in the events. Following the event descriptions is a step-by-step walkthrough explaining how to use the events to understand why the block occurred.
#### Event 3077 - WDAC enforcement block event
#### Event 3077 - App Control enforcement block event
![Example 3077 block event for PowerShell.exe.](../images/event-3077.png)
| Element name | Description |
| ----- | ----- |
| System - Correlation - \[ActivityID\] | **Not shown in screenshot** <br> Use the correlation ActivityID to match a WDAC block event with one or more 3089 signature events. |
| File Name | The file's path and name on disk that was blocked from running. Since the name on disk is mutable, this value **isn't** the one used when creating WDAC file rules with `-Level FileName`. Instead, see the OriginalFileName element later in this table. |
| System - Correlation - \[ActivityID\] | **Not shown in screenshot** <br> Use the correlation ActivityID to match a App Control block event with one or more 3089 signature events. |
| File Name | The file's path and name on disk that was blocked from running. Since the name on disk is mutable, this value **isn't** the one used when creating App Control file rules with `-Level FileName`. Instead, see the OriginalFileName element later in this table. |
| Process Name | The path and name of the file that attempted to run the blocked file. Also called the parent process. |
| Requested Signing Level | The Windows signing authorization level the code needed to pass in order to run. See [Requested and validated signing level](/windows/security/threat-protection/windows-defender-application-control/event-tag-explanations#requested-and-validated-signing-level). |
| Validated Signing Level | The Windows signing authorization level the code was given. See [Requested and validated signing level](/windows/security/threat-protection/windows-defender-application-control/event-tag-explanations#requested-and-validated-signing-level). |
| Requested Signing Level | The Windows signing authorization level the code needed to pass in order to run. See [Requested and validated signing level](event-tag-explanations.md#requested-and-validated-signing-level). |
| Validated Signing Level | The Windows signing authorization level the code was given. See [Requested and validated signing level](event-tag-explanations.md#requested-and-validated-signing-level). |
| Status | Windows NT status code. You can use `certutil.exe -error <status>` to look up the meaning of the status code. |
| SHA1 Hash | The SHA1 Authenticode hash for the blocked file. |
| SHA256 Hash | The SHA256 Authenticode hash for the blocked file. |
| SHA1 Flat Hash | The SHA1 flat file hash for the blocked file. |
| SHA256 Flat Hash | The SHA256 flat file hash for the blocked file. |
| PolicyName | The friendly name of the WDAC policy that caused the block event. A separate 3077 block event (or 3076 audit block event) is shown for each policy that blocks the file from running. |
| PolicyId | The friendly ID value of the WDAC policy that caused the block event. |
| PolicyHash | The SHA256 Authenticode hash of the WDAC policy binary that caused the block event. |
| OriginalFileName | The immutable file name set by the developer in the blocked file's resource header. This value is the one used when creating WDAC file rules with `-Level FileName`. |
| PolicyName | The friendly name of the App Control policy that caused the block event. A separate 3077 block event (or 3076 audit block event) is shown for each policy that blocks the file from running. |
| PolicyId | The friendly ID value of the App Control policy that caused the block event. |
| PolicyHash | The SHA256 Authenticode hash of the App Control policy binary that caused the block event. |
| OriginalFileName | The immutable file name set by the developer in the blocked file's resource header. This value is the one used when creating App Control file rules with `-Level FileName`. |
| InternalName | Another immutable value set by the developer in the blocked file's resource header. You can substitute this value for the OriginalFileName in file rules with `-Level FileName -SpecificFileNameLevel InternalName`. |
| FileDescription | Another immutable value set by the developer in the blocked file's resource header. You can substitute this value for the OriginalFileName in file rules with `-Level FileName -SpecificFileNameLevel FileDescription`. |
| ProductName | Another immutable value set by the developer in the blocked file's resource header. You can substitute this value for the OriginalFileName in file rules with `-Level FileName -SpecificFileNameLevel ProductName`. |
| FileVersion | The policy's VersionEx value used to enforce version control over signed policies. |
| PolicyGUID | The PolicyId of the WDAC policy that caused the block event. |
| PolicyGUID | The PolicyId of the App Control policy that caused the block event. |
| UserWriteable | A boolean value indicating if the file was in a user-writeable location. This information is useful for diagnosing issues when allowing by FilePath rules. |
| PackageFamilyName | The Package Family Name for the packaged app (MSIX) that includes the blocked file. |
#### Event 3089 - WDAC signature information event
#### Event 3089 - App Control signature information event
![Example 3089 signature information event for PowerShell.exe.](../images/event-3089.png)
| Element name | Description |
| ----- | ----- |
| System - Correlation - \[ActivityID\] | Use the correlation ActivityID to match a WDAC signature event with its block event. |
| System - Correlation - \[ActivityID\] | Use the correlation ActivityID to match a App Control signature event with its block event. |
| TotalSignatureCount | The total number of signatures detected for the blocked file. |
| Signature | The index count, starting at 0, of the current signature shown in this 3089 event. If the file had multiple signatures, you'll find other 3089 events for the other signatures. |
| Hash | The hash value that WDAC used to match the file. This value should match one of the four hashes shown on the 3077 or 3076 block event. If no signatures were found for the file (TotalSignatureCount = 0), then only the hash value is shown. |
| SignatureType | The [type of signature](/windows/security/threat-protection/windows-defender-application-control/event-tag-explanations#signaturetype). |
| ValidatedSigningLevel | The Windows signing authorization level the signature met. See [Requested and validated signing level](/windows/security/threat-protection/windows-defender-application-control/event-tag-explanations#requested-and-validated-signing-level). |
| VerificationError | The reason this particular signature failed to pass the WDAC policy. See [VerificationError](/windows/security/threat-protection/windows-defender-application-control/event-tag-explanations#verificationerror). |
| Hash | The hash value that App Control used to match the file. This value should match one of the four hashes shown on the 3077 or 3076 block event. If no signatures were found for the file (TotalSignatureCount = 0), then only the hash value is shown. |
| SignatureType | The [type of signature](event-tag-explanations.md#signaturetype). |
| ValidatedSigningLevel | The Windows signing authorization level the signature met. See [Requested and validated signing level](event-tag-explanations.md#requested-and-validated-signing-level). |
| VerificationError | The reason this particular signature failed to pass the App Control policy. See [VerificationError](event-tag-explanations.md#verificationerror). |
| PublisherName | The common name (CN) value from the leaf certificate. |
| IssuerName | The CN value from the highest available certificate in the certificate chain. This level is typically one certificate below the root. |
| PublisherTBSHash | The TBS hash of the leaf certificate. |
@ -166,7 +165,7 @@ Here's an example of detailed EventData from a typical WDAC enforcement mode blo
#### Step-by-step walkthrough of the example 3077 and 3089 events
Now let's walk through how to use the event data in the example 3077 and 3089 events to understand why the WDAC policy blocked this file.
Now let's walk through how to use the event data in the example 3077 and 3089 events to understand why the App Control policy blocked this file.
##### Understand what file is being blocked and the block context
@ -174,11 +173,11 @@ Referring to the 3077 event, locate the information that identifies the policy,
In the example, the file being blocked is PowerShell.exe, which is part of Windows and would normally be expected to run. However, in this case, the policy was based off of the Windows in S mode policy template, which doesn't allow script hosts to run as a way to limit the attack surface. For S mode, this block event is a success. But let's assume the policy author was unaware of that constraint when they chose the template, and treat this block as unexpected.
##### Determine why WDAC rejected the file
##### Determine why App Control rejected the file
Again referring to the 3077 event, we see the Requested Signing Level of 2 means the code must pass the WDAC policy. But the Validated Signing Level of 1 means the code was treated as though unsigned. "Unsigned" could mean the file was truly unsigned, signed but with an invalid certificate, or signed but without any certificates allowed by the WDAC policy.
Again referring to the 3077 event, we see the Requested Signing Level of 2 means the code must pass the App Control policy. But the Validated Signing Level of 1 means the code was treated as though unsigned. "Unsigned" could mean the file was truly unsigned, signed but with an invalid certificate, or signed but without any certificates allowed by the App Control policy.
Now, let's inspect the correlated 3089 event(s) for the blocked file. In the example, we're looking at only the first signature (Signature index 0) found on a file that had multiple signatures. For this signature, the ValidatedSigningLevel is 12, meaning it has a Microsoft Windows product signature. The VerificationError of 21 means that the signature didn't pass the WDAC policy.
Now, let's inspect the correlated 3089 event(s) for the blocked file. In the example, we're looking at only the first signature (Signature index 0) found on a file that had multiple signatures. For this signature, the ValidatedSigningLevel is 12, meaning it has a Microsoft Windows product signature. The VerificationError of 21 means that the signature didn't pass the App Control policy.
It's important to review the information for each correlated 3089 event as each signature may have a different ValidatedSigningLevel and VerificationError.
@ -191,11 +190,11 @@ It's important to review the information for each correlated 3089 event as each
## 3 - Resolve common problems
Having analyzed the WDAC diagnostic data, you can take steps to resolve the issue or do more debugging steps. Following are some common problems and steps you can try to resolve or further isolate the root issue:
Having analyzed the App Control diagnostic data, you can take steps to resolve the issue or do more debugging steps. Following are some common problems and steps you can try to resolve or further isolate the root issue:
### Issue: A file was blocked that you want to allow
- Use data from the core WDAC event logs to add rules to allow the blocked file.
- Use data from the core App Control event logs to add rules to allow the blocked file.
- Redeploy the file or app using a managed installer if your policy trusts managed installers.
### Issue: A policy is active that is unexpected
@ -208,51 +207,51 @@ This condition may exist if:
- A policy was incorrectly deployed to the device.
- An attacker with administrator access has applied a policy to cause denial of service for some critical processes.
To resolve such an issue, follow the instructions to [Remove WDAC policies](/windows/security/threat-protection/windows-defender-application-control/disable-windows-defender-application-control-policies) for the identified policy.
To resolve such an issue, follow the instructions to [Remove App Control policies](../deployment/disable-appcontrol-policies.md) for the identified policy.
### Issue: An unhandled app failure is occurring and no WDAC events are observed
### Issue: An unhandled app failure is occurring and no App Control events are observed
Some apps alter their behavior when a user mode WDAC policy is active, which can result in unexpected failures. It can also be a side-effect of script enforcement for apps that don't properly handle the enforcement behaviors implemented by the script hosts.
Some apps alter their behavior when a user mode App Control policy is active, which can result in unexpected failures. It can also be a side-effect of script enforcement for apps that don't properly handle the enforcement behaviors implemented by the script hosts.
Try to isolate the root cause by doing the following actions:
- Check the other event logs listed in section 1 of this article for events corresponding with the unexpected app failures.
- Temporarily replace the WDAC policy with another policy that [disables script enforcement](/windows/security/threat-protection/windows-defender-application-control/design/script-enforcement) and retest.
- Temporarily replace the WDAC policy with another policy that [allows all COM objects](/windows/security/threat-protection/windows-defender-application-control/allow-com-object-registration-in-windows-defender-application-control-policy) and retest.
- Temporarily replace the WDAC policy with another policy that relaxes other [policy rules](/windows/security/threat-protection/windows-defender-application-control/select-types-of-rules-to-create#windows-defender-application-control-policy-rules) and retest.
- Temporarily replace the App Control policy with another policy that [disables script enforcement](../design/script-enforcement.md) and retest.
- Temporarily replace the App Control policy with another policy that [allows all COM objects](../design/allow-com-object-registration-in-appcontrol-policy.md) and retest.
- Temporarily replace the App Control policy with another policy that relaxes other [policy rules](../design/select-types-of-rules-to-create.md#app-control-for-business-policy-rules) and retest.
### Issue: An app deployed by a managed installer isn't working
To debug issues using managed installer, try these steps:
- Check that the WDAC policy that is blocking the app includes the option to enable managed installer.
- Check that the effective AppLocker policy $env:USERPROFILE\AppData\Local\Temp\DiagOutputDir\CiDiag\AppLocker.xml is correct as described in [Automatically allow apps deployed by a managed installer](/windows/security/threat-protection/windows-defender-application-control/configure-authorized-apps-deployed-with-a-managed-installer#create-and-deploy-an-applocker-policy-that-defines-your-managed-installer-rules-and-enables-services-enforcement-for-executables-and-dlls).
- Check that the App Control policy that is blocking the app includes the option to enable managed installer.
- Check that the effective AppLocker policy $env:USERPROFILE\AppData\Local\Temp\DiagOutputDir\CiDiag\AppLocker.xml is correct as described in [Automatically allow apps deployed by a managed installer](../design/configure-authorized-apps-deployed-with-a-managed-installer.md#create-and-deploy-an-applocker-policy-that-defines-your-managed-installer-rules-and-enables-services-enforcement-for-executables-and-dlls).
- 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.
- Check that an AppLocker file exists called MANAGEDINSTALLER.APPLOCKER exists in the CiDiag folder created earlier. If not, repeat the steps to deploy and enable the managed installer AppLocker configuration.
- Restart the managed installer process and check that an 8002 event is observed in the **AppLocker - EXE and DLL** event log for the managed installer process with PolicyName = MANAGEDINSTALLER. If instead you see an event with 8003 or 8004 with PolicyName = MANAGEDINSTALLER, then check the ManagedInstaller rules in the AppLocker policy XML and ensure a rule matches the managed installer process.
- [Use fsutil.exe](/windows/security/threat-protection/windows-defender-application-control/configure-wdac-managed-installer#using-fsutil-to-query-extended-attributes-for-managed-installer-mi) to verify files written by the managed installer process have the managed installer origin extended attribute. If not, redeploy the files with the managed installer and check again.
- [Use fsutil.exe](configure-appcontrol-managed-installer.md#using-fsutil-to-query-extended-attributes-for-managed-installer-mi) to verify files written by the managed installer process have the managed installer origin extended attribute. If not, redeploy the files with the managed installer and check again.
- Test installation of a different app using the managed installer.
- Add another managed installer to your AppLocker policy and test installation using the other managed installer.
- Check if the app is encountering a [known limitation with managed installer](/windows/security/threat-protection/windows-defender-application-control/configure-authorized-apps-deployed-with-a-managed-installer#known-limitations-with-managed-installer). If so, you must authorize the app using other means.
- Check if the app is encountering a [known limitation with managed installer](../design/configure-authorized-apps-deployed-with-a-managed-installer.md#known-limitations-with-managed-installer). If so, you must authorize the app using other means.
### Issue: An app you expected the Intelligent Security Graph (ISG) to allow isn't working
To debug issues using ISG, try these steps:
- Check that the WDAC policy that is blocking the app includes the option to enable the intelligent security graph.
- Check that the App Control policy that is blocking the app includes the option to enable the intelligent security graph.
- 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).
- [Use fsutil.exe](configure-appcontrol-managed-installer.md#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](../design/use-appcontrol-with-intelligent-security-graph.md#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.
- All other customers can report issues directly to the App Control 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 App Control product team.
When reporting issues, be sure to provide the following information:
- All [WDAC diagnostic data](#1---gather-wdac-diagnostic-data) described earlier.
- All [App Control diagnostic data](#1---gather-app-control-diagnostic-data) described earlier.
- If possible, the blocked file(s).
- Clear instructions to reproduce the problem.

27
windows/security/application-security/application-control/app-control-for-business/operations/appcontrol-operational-guide.md
View File

@ -1,27 +1,26 @@
---
title: Managing and troubleshooting Windows Defender Application Control policies
description: Gather information about how your deployed Windows Defender Application Control policies are behaving.
title: Managing and troubleshooting App Control for Business policies
description: Gather information about how your deployed App Control for Business policies are behaving.
ms.localizationpriority: medium
ms.date: 03/30/2023
ms.topic: how-to
---
# Windows Defender Application Control operational guide
# App Control for Business operational guide
> [!NOTE]
> Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](../feature-availability.md).
[!INCLUDE [Feature availability note](../includes/feature-availability-note.md)]
You now understand how to design and deploy your Windows Defender Application Control (WDAC) policies. This guide explains how to understand the effects your policies have and how to troubleshoot when they aren't behaving as expected. It contains information on where to find events and what they mean, and also querying these events with Microsoft Defender for Endpoint Advanced Hunting feature.
You now understand how to design and deploy your App Control for Business policies. This guide explains how to understand the effects your policies have and how to troubleshoot when they aren't behaving as expected. It contains information on where to find events and what they mean, and also querying these events with Microsoft Defender for Endpoint Advanced Hunting feature.
## In this section
| Article | Description |
| - | - |
| [Debugging and troubleshooting](/windows/security/threat-protection/windows-defender-application-control/operations/wdac-debugging-and-troubleshooting) | This article explains how to debug app and script failures with WDAC. |
| [Understanding Application Control event IDs](/windows/security/threat-protection/windows-defender-application-control/event-id-explanations) | This article explains the meaning of different WDAC event IDs. |
| [Understanding Application Control event tags](/windows/security/threat-protection/windows-defender-application-control/event-tag-explanations) | This article explains the meaning of different WDAC event tags. |
| [Query WDAC events with Advanced hunting](/windows/security/threat-protection/windows-defender-application-control/querying-application-control-events-centrally-using-advanced-hunting) | This article covers how to view WDAC events centrally from all systems that are connected to Microsoft Defender for Endpoint. |
| [Admin Tips & Known Issues](/windows/security/threat-protection/windows-defender-application-control/operations/known-issues) | This article describes some WDAC Admin Tips & Known Issues. |
| [Managed installer and ISG technical reference and troubleshooting guide](/windows/security/threat-protection/windows-defender-application-control/configure-wdac-managed-installer) | This article provides technical details and debugging steps for managed installer and ISG. |
| [CITool.exe technical reference](/windows/security/threat-protection/windows-defender-application-control/operations/citool-commands) | This article explains how to use CITool.exe. |
| [Inbox WDAC policies](/windows/security/threat-protection/windows-defender-application-control/operations/inbox-wdac-policies) | This article describes the WDAC policies that ship with Windows and when they're active. |
| [Debugging and troubleshooting](appcontrol-debugging-and-troubleshooting.md) | This article explains how to debug app and script failures with App Control. |
| [Understanding Application Control event IDs](event-id-explanations.md) | This article explains the meaning of different App Control event IDs. |
| [Understanding Application Control event tags](event-tag-explanations.md) | This article explains the meaning of different App Control event tags. |
| [Query App Control events with Advanced hunting](querying-application-control-events-centrally-using-advanced-hunting.md) | This article covers how to view App Control events centrally from all systems that are connected to Microsoft Defender for Endpoint. |
| [Admin Tips & Known Issues](known-issues.md) | This article describes some App Control Admin Tips & Known Issues. |
| [Managed installer and ISG technical reference and troubleshooting guide](configure-appcontrol-managed-installer.md) | This article provides technical details and debugging steps for managed installer and ISG. |
| [CITool.exe technical reference](citool-commands.md) | This article explains how to use CITool.exe. |
| [Inbox App Control policies](inbox-appcontrol-policies.md) | This article describes the App Control policies that ship with Windows and when they're active. |

12
windows/security/application-security/application-control/app-control-for-business/operations/citool-commands.md
View File

@ -9,7 +9,7 @@ appliesto:
# CiTool technical reference
CiTool makes Windows Defender Application Control (WDAC) policy management easier for IT admins. You can use this tool to manage Windows Defender Application Control policies and CI tokens. This article describes how to use CiTool to update and manage policies. It's currently included as part of the Windows image in Windows 11, version 22H2.
CiTool makes App Control for Business policy management easier for IT admins. You can use this tool to manage App Control for Business policies and CI tokens. This article describes how to use CiTool to update and manage policies. It's currently included as part of the Windows image in Windows 11, version 22H2.
## Policy commands
@ -35,7 +35,7 @@ CiTool makes Windows Defender Application Control (WDAC) policy management easie
| Command | Description | Alias |
|--------|---------|---------|
| `--device-id` | Dump the code integrity device ID. | `-id` |
| `--refresh` | Attempt to refresh WDAC policies. | `-r` |
| `--refresh` | Attempt to refresh App Control policies. | `-r` |
| `--help` | Display the tool's help menu. | `-h` |
## Output attributes and descriptions
@ -69,25 +69,25 @@ CiTool makes Windows Defender Application Control (WDAC) policy management easie
## Examples
### Deploy a WDAC policy
### Deploy a App Control policy
```powershell
CiTool --update-policy "\Windows\Temp\{BF61FE40-8929-4FDF-9EC2-F7A767717F0B}.cip"
```
### Refresh the WDAC policies on the system
### Refresh the App Control policies on the system
```powershell
CiTool --refresh
```
### Remove a specific WDAC policy by its policy ID
### Remove a specific App Control policy by its policy ID
```powershell
CiTool --remove-policy "{BF61FE40-8929-4FDF-9EC2-F7A767717F0B}"
```
### List the actively enforced WDAC policies on the system
### List the actively enforced App Control policies on the system
```powershell
# Check each policy's IsEnforced state and return only the enforced policies

9
windows/security/application-security/application-control/app-control-for-business/operations/configure-appcontrol-managed-installer.md
View File

@ -8,8 +8,7 @@ ms.topic: troubleshooting
# Managed installer and ISG technical reference and troubleshooting guide
>[!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).
[!INCLUDE [Feature availability note](../includes/feature-availability-note.md)]
## Enabling managed installer and Intelligent Security Graph (ISG) logging events
@ -17,7 +16,7 @@ Refer to [Understanding Application Control Events](event-id-explanations.md#dia
## Using fsutil to query extended attributes for Managed Installer (MI)
Customers using Windows Defender Application Control (WDAC) with Managed Installer (MI) enabled can use fsutil.exe to determine whether a file was created by a managed installer process. This verification is done by querying the Extended Attributes (EAs) on a file using fsutil.exe and looking for the KERNEL.SMARTLOCKER.ORIGINCLAIM EA. Then, you can use the data from the first row of output to identify if the file was created by a managed installer. For example, let's look at the fsutil.exe output for a file called application.exe:
Customers using App Control for Business with Managed Installer (MI) enabled can use fsutil.exe to determine whether a file was created by a managed installer process. This verification is done by querying the Extended Attributes (EAs) on a file using fsutil.exe and looking for the KERNEL.SMARTLOCKER.ORIGINCLAIM EA. Then, you can use the data from the first row of output to identify if the file was created by a managed installer. For example, let's look at the fsutil.exe output for a file called application.exe:
**Example:**
@ -47,7 +46,7 @@ If there is "00" in the fifth position of the output (the start of the second UL
0000: 01 00 00 00 **`00` 00 00 00** 00 00 00 00 01 00 00 00
Finally, the two-character set in the ninth position of the output (the start of the third ULONG) indicates whether the file was created by a process running as managed installer. A value of "00" means the file was directly written by a managed installer process and will run if your WDAC policy trusts managed installers.
Finally, the two-character set in the ninth position of the output (the start of the third ULONG) indicates whether the file was created by a process running as managed installer. A value of "00" means the file was directly written by a managed installer process and will run if your App Control policy trusts managed installers.
0000: 01 00 00 00 00 00 00 00 **`00` 00 00 00** 01 00 00 00
@ -98,4 +97,4 @@ Both managed installer and the ISG depend on AppLocker to provide some functiona
Get-AppLockerPolicy -Effective -XML > $env:USERPROFILE\Desktop\AppLocker.xml
```
Then open the XML file created and confirm it contains the rules you expect. In particular, the policy should include at least one rule for each of the EXE, DLL, and MANAGEDINSTALLER RuleCollections. The RuleCollections can either be set to AuditOnly or Enabled. Additionally, the EXE and DLL RuleCollections must include the RuleCollectionExtensions configuration as shown in [Automatically allow apps deployed by a managed installer with Windows Defender Application Control](/windows/security/threat-protection/windows-defender-application-control/configure-authorized-apps-deployed-with-a-managed-installer#create-and-deploy-an-applocker-policy-that-defines-your-managed-installer-rules-and-enables-services-enforcement-for-executables-and-dlls).
Then open the XML file created and confirm it contains the rules you expect. In particular, the policy should include at least one rule for each of the EXE, DLL, and MANAGEDINSTALLER RuleCollections. The RuleCollections can either be set to AuditOnly or Enabled. Additionally, the EXE and DLL RuleCollections must include the RuleCollectionExtensions configuration as shown in [Automatically allow apps deployed by a managed installer with App Control for Business](../design/configure-authorized-apps-deployed-with-a-managed-installer.md#create-and-deploy-an-applocker-policy-that-defines-your-managed-installer-rules-and-enables-services-enforcement-for-executables-and-dlls).

36
windows/security/application-security/application-control/app-control-for-business/operations/event-id-explanations.md
View File

@ -1,6 +1,6 @@
---
title: Understanding Application Control event IDs
description: Learn what different Windows Defender Application Control event IDs signify.
description: Learn what different App Control for Business event IDs signify.
ms.localizationpriority: medium
ms.date: 03/24/2023
ms.topic: reference
@ -8,50 +8,50 @@ ms.topic: reference
# Understanding Application Control events
## WDAC Events Overview
## App Control Events Overview
WDAC logs events when a policy is loaded, when a file is blocked, or when a file would be blocked if in audit mode. These block events include information that identifies the policy and gives more details about the block. WDAC doesn't generate events when a binary is allowed. However, you can turn on allow audit events for files authorized by a managed installer or the Intelligent Security Graph (ISG) as described later in this article.
App Control logs events when a policy is loaded, when a file is blocked, or when a file would be blocked if in audit mode. These block events include information that identifies the policy and gives more details about the block. App Control doesn't generate events when a binary is allowed. However, you can turn on allow audit events for files authorized by a managed installer or the Intelligent Security Graph (ISG) as described later in this article.
### Core WDAC event logs
### Core App Control event logs
WDAC events are generated under two locations in the Windows Event Viewer:
App Control events are generated under two locations in the Windows Event Viewer:
- **Applications and Services logs - Microsoft - Windows - CodeIntegrity - Operational** includes events about Application Control policy activation and the control of executables, dlls, and drivers.
- **Applications and Services logs - Microsoft - Windows - AppLocker - MSI and Script** includes events about the control of MSI installers, scripts, and COM objects.
Most app and script failures that occur when WDAC is active can be diagnosed using these two event logs. This article describes in greater detail the events that exist in these logs. To understand the meaning of different data elements, or tags, found in the details of these events, see [Understanding Application Control event tags](event-tag-explanations.md).
Most app and script failures that occur when App Control is active can be diagnosed using these two event logs. This article describes in greater detail the events that exist in these logs. To understand the meaning of different data elements, or tags, found in the details of these events, see [Understanding Application Control event tags](event-tag-explanations.md).
> [!NOTE]
> **Applications and Services logs - Microsoft - Windows - AppLocker - MSI and Script** events are not included on Windows Server Core edition.
## WDAC block events for executables, dlls, and drivers
## App Control block events for executables, dlls, and drivers
These events are found in the **CodeIntegrity - Operational** event log.
| Event ID | Explanation |
|--------|-----------|
| 3004 | This event isn't common and may occur with or without an Application Control 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. <br><br> This event is also seen for kernel- or user-mode code that the developer opted-in to [/INTEGRITYCHECK](/cpp/build/reference/integritycheck-require-signature-check) but isn't signed correctly. |
| 3033 | This event may occur with or without an Application Control policy present and should occur alongside a 3077 event if caused by WDAC policy. It often means the file's signature is revoked or a signature with the Lifetime Signing EKU has expired. Presence of the Lifetime Signing EKU is the only case where WDAC blocks files due to an expired signature. Try using option `20 Enabled:Revoked Expired As Unsigned` in your policy along with a rule (for example, hash) that doesn't rely on the revoked or expired cert. <br><br> This event also occurs if code compiled with [Code Integrity Guard (CIG)](/microsoft-365/security/defender-endpoint/exploit-protection-reference#code-integrity-guard) tries to load other code that doesn't meet the CIG requirements. |
| 3033 | This event may occur with or without an Application Control policy present and should occur alongside a 3077 event if caused by App Control policy. It often means the file's signature is revoked or a signature with the Lifetime Signing EKU has expired. Presence of the Lifetime Signing EKU is the only case where App Control blocks files due to an expired signature. Try using option `20 Enabled:Revoked Expired As Unsigned` in your policy along with a rule (for example, hash) that doesn't rely on the revoked or expired cert. <br><br> This event also occurs if code compiled with [Code Integrity Guard (CIG)](/microsoft-365/security/defender-endpoint/exploit-protection-reference#code-integrity-guard) tries to load other code that doesn't meet the CIG requirements. |
| 3034 | This event isn't common. It's the audit mode equivalent of event 3033. |
| 3076 | This event is the main Application Control block event for audit mode policies. It indicates that the file would have been blocked if the policy was enforced. |
| 3077 | This event is the main Application Control block event for enforced policies. It indicates that the file didn't pass your policy and was blocked. |
| 3089 | This event contains signature information for files that were blocked or audit blocked by Application Control. One of these events is created for each signature of a file. Each event shows the total number of signatures found and an index value to identify the current signature. Unsigned files generate a single one of these events with TotalSignatureCount of 0. These 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. |
## WDAC block events for packaged apps, MSI installers, scripts, and COM objects
## App Control block events for packaged apps, MSI installers, scripts, and COM objects
These events are found in the **AppLocker - MSI and Script** event log.
| Event ID | Explanation |
|--------|-----------|
| 8028 | This event indicates that a script host, such as PowerShell, queried Application Control about a file the script host was about to run. Since the policy was in audit mode, the script or MSI file should have run, but wouldn't have passed the WDAC policy if it was enforced. Some script hosts may have additional information in their logs. Note: Most third-party script hosts don't integrate with Application Control. Consider the risks from unverified scripts when choosing which script hosts you allow to run. |
| 8029 | This event is the enforcement mode equivalent of event 8028. Note: While this event says that a script was blocked, the script hosts control the actual script enforcement behavior. The script host may allow the file to run with restrictions and not block the file outright. For example, PowerShell runs script not allowed by your WDAC policy in [Constrained Language Mode](/powershell/module/microsoft.powershell.core/about/about_language_modes). |
| 8036| COM object was blocked. To learn more about COM object authorization, see [Allow COM object registration in a Windows Defender Application Control policy](../design/allow-com-object-registration-in-appcontrol-policy.md). |
| 8037 | This event indicates that a script host checked whether to allow a script to run, and the file passed the WDAC policy. |
| 8028 | This event indicates that a script host, such as PowerShell, queried Application Control about a file the script host was about to run. Since the policy was in audit mode, the script or MSI file should have run, but wouldn't have passed the App Control policy if it was enforced. Some script hosts may have additional information in their logs. Note: Most third-party script hosts don't integrate with Application Control. Consider the risks from unverified scripts when choosing which script hosts you allow to run. |
| 8029 | This event is the enforcement mode equivalent of event 8028. Note: While this event says that a script was blocked, the script hosts control the actual script enforcement behavior. The script host may allow the file to run with restrictions and not block the file outright. For example, PowerShell runs script not allowed by your App Control policy in [Constrained Language Mode](/powershell/module/microsoft.powershell.core/about/about_language_modes). |
| 8036| COM object was blocked. To learn more about COM object authorization, see [Allow COM object registration in a App Control for Business policy](../design/allow-com-object-registration-in-appcontrol-policy.md). |
| 8037 | This event indicates that a script host checked whether to allow a script to run, and the file passed the App Control policy. |
| 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 generate a single 8038 event with TotalSignatureCount 0. These events are correlated with 8028 and 8029 events and can be matched using the `Correlation ActivityID` found in the **System** portion of the event. |
| 8039 | This event indicates that a packaged app (MSIX/AppX) was allowed to install or run because the WDAC policy is in audit mode. But, it would have been blocked if the policy was enforced. |
| 8040 | This event indicates that a packaged app was prevented from installing or running due to the WDAC policy. |
| 8039 | This event indicates that a packaged app (MSIX/AppX) was allowed to install or run because the App Control policy is in audit mode. But, it would have been blocked if the policy was enforced. |
| 8040 | This event indicates that a packaged app was prevented from installing or running due to the App Control policy. |
## WDAC policy activation events
## App Control policy activation events
These events are found in the **CodeIntegrity - Operational** event log.
@ -72,7 +72,7 @@ These events are found in the **CodeIntegrity - Operational** event log.
> [!NOTE]
> When Managed Installer is enabled, customers using LogAnalytics should be aware that Managed Installer may fire many 3091 events. Customers may need to filter out these events to avoid high LogAnalytics costs.
The following events provide helpful diagnostic information when a WDAC policy includes the ISG or MI option. These events can help you debug why something was allowed/denied based on managed installer or ISG. Events 3090, 3091, and 3092 don't necessarily indicate a problem but should be reviewed in context with other events like 3076 or 3077.
The following events provide helpful diagnostic information when a App Control policy includes the ISG or MI option. These events can help you debug why something was allowed/denied based on managed installer or ISG. Events 3090, 3091, and 3092 don't necessarily indicate a problem but should be reviewed in context with other events like 3076 or 3077.
Unless otherwise noted, these events are found in either the **CodeIntegrity - Operational** event log or the **CodeIntegrity - Verbose** event log depending on your version of Windows.
@ -81,7 +81,7 @@ Unless otherwise noted, these events are found in either the **CodeIntegrity - O
| 3090 | *Optional* This event indicates that a file was allowed to run based purely on ISG or managed installer. |
| 3091 | This event indicates that a file didn't have ISG or managed installer authorization and the Application Control policy is in audit mode. |
| 3092 | This event is the enforcement mode equivalent of 3091. |
| 8002 | This event is found in the **AppLocker - EXE and DLL** event log. When a process launches that matches a managed installer rule, this event is raised with PolicyName = MANAGEDINSTALLER found in the event Details. Events with PolicyName = EXE or DLL aren't related to WDAC. |
| 8002 | This event is found in the **AppLocker - EXE and DLL** event log. When a process launches that matches a managed installer rule, this event is raised with PolicyName = MANAGEDINSTALLER found in the event Details. Events with PolicyName = EXE or DLL aren't related to App Control. |
Events 3090, 3091, and 3092 are reported per active policy on the system, so you may see multiple events for the same file.

14
windows/security/application-security/application-control/app-control-for-business/operations/event-tag-explanations.md
View File

@ -1,6 +1,6 @@
---
title: Understanding Application Control event tags
description: Learn what different Windows Defender Application Control event tags signify.
description: Learn what different App Control for Business event tags signify.
ms.localizationpriority: medium
ms.date: 05/09/2023
ms.topic: conceptual
@ -8,7 +8,7 @@ ms.topic: conceptual
# Understanding Application Control event tags
Windows Defender Application Control (WDAC) events include many fields, which provide helpful troubleshooting information to figure out exactly what an event means. This article describes the values and meanings for a few useful event tags.
App Control for Business events include many fields, which provide helpful troubleshooting information to figure out exactly what an event means. This article describes the values and meanings for a few useful event tags.
## SignatureType
@ -33,7 +33,7 @@ Represents the signature level at which the code was verified.
|---|----------|
| 0 | Signing level hasn't yet been checked |
| 1 | File is unsigned or has no signature that passes the active policies |
| 2 | Trusted by Windows Defender Application Control policy |
| 2 | Trusted by App Control for Business policy |
| 3 | Developer signed code |
| 4 | Authenticode signed |
| 5 | Microsoft Store signed app PPL (Protected Process Light) |
@ -71,7 +71,7 @@ Represents why verification failed, or if it succeeded.
| 18 | Custom signing level not met; returned if signature fails to match `CISigners` in UMCI. |
| 19 | Binary is revoked based on its file hash. |
| 20 | SHA1 cert hash's timestamp is missing or after valid cutoff as defined by Weak Crypto Policy. |
| 21 | Failed to pass Windows Defender Application Control policy. |
| 21 | Failed to pass App Control for Business policy. |
| 22 | Not Isolated User Mode (IUM)) signed; indicates an attempt to load a standard Windows binary into a virtualization-based security (VBS) trustlet. |
| 23 | Invalid image hash. This error can indicate file corruption or a problem with the file's signature. Signatures using elliptic curve cryptography (ECC), such as ECDSA, return this VerificationError. |
| 24 | Flight root not allowed; indicates trying to run flight-signed code on production OS. |
@ -82,7 +82,7 @@ Represents why verification failed, or if it succeeded.
## Policy activation event Options
The Application Control policy rule option values can be derived from the "Options" field in the Details section for successful [policy activation events](event-id-explanations.md#wdac-policy-activation-events). To parse the values, first convert the hex value to binary. To derive and parse these values, follow the below workflow.
The Application Control policy rule option values can be derived from the "Options" field in the Details section for successful [policy activation events](event-id-explanations.md#app-control-policy-activation-events). To parse the values, first convert the hex value to binary. To derive and parse these values, follow the below workflow.
- Access Event Viewer.
- Access the Code integrity 3099 event.
@ -105,7 +105,7 @@ For a simple solution for converting hex to binary, follow these steps:
This view provides the hex code in binary form, with each bit address shown separately. The bit addresses start at 0 in the bottom right. Each bit address correlates to a specific event policy-rule option. If the bit address holds a value of 1, the setting is in the policy.
Next, use the bit addresses and their values from the following table to determine the state of each [policy rule-option](../design/select-types-of-rules-to-create.md#table-1-windows-defender-application-control-policy---policy-rule-options). For example, if the bit address of 16 holds a value of 1, then the **Enabled: Audit Mode (Default)** option is in the policy. This setting means that the policy is in audit mode.
Next, use the bit addresses and their values from the following table to determine the state of each [policy rule-option](../design/select-types-of-rules-to-create.md#table-1-app-control-for-business-policy---policy-rule-options). For example, if the bit address of 16 holds a value of 1, then the **Enabled: Audit Mode (Default)** option is in the policy. This setting means that the policy is in audit mode.
| Bit Address | Policy Rule Option |
|-------|------|
@ -157,7 +157,7 @@ The rule means trust anything signed by a certificate that chains to this root C
| 18 | Microsoft ECC Product Root CA 2018 |
| 19 | Microsoft ECC Devices Root CA 2017 |
For well-known roots, the TBS hashes for the certificates are baked into the code for Windows Defender Application Control. For example, they don't need to be listed as TBS hashes in the policy file.
For well-known roots, the TBS hashes for the certificates are baked into the code for App Control for Business. For example, they don't need to be listed as TBS hashes in the policy file.
## Status values

15
windows/security/application-security/application-control/app-control-for-business/operations/inbox-appcontrol-policies.md
View File

@ -1,24 +1,23 @@
---
title: Inbox WDAC policies
description: This article describes the inbox WDAC policies that may be active on a device.
title: Inbox App Control policies
description: This article describes the inbox App Control policies that may be active on a device.
ms.manager: jsuther
ms.date: 03/10/2023
ms.topic: conceptual
ms.localizationpriority: medium
---
# Inbox WDAC policies
# Inbox App Control policies
> [!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).
[!INCLUDE [Feature availability note](../includes/feature-availability-note.md)]
This article describes the Windows Defender Application Control (WDAC) policies that ship inbox with Windows and may be active on your devices. To see which policies are active on your device, use [citool.exe](/windows/security/threat-protection/windows-defender-application-control/operations/citool-commands) or check the *CodeIntegrity - Operational* event log for 3099 policy activation events.
This article describes the App Control for Business policies that ship inbox with Windows and may be active on your devices. To see which policies are active on your device, use [citool.exe](citool-commands.md) or check the *CodeIntegrity - Operational* event log for 3099 policy activation events.
## Inbox WDAC Policies
## Inbox App Control Policies
| **Policy Name** | **Policy ID** | **Policy Type** | **Description** |
|-----------|-----------|-----------|-----------|
| **Microsoft Windows Driver Policy** | {d2bda982-ccf6-4344-ac5b-0b44427b6816} | Kernel-only Base policy | This policy blocks known [vulnerable or malicious kernel drivers](/windows/security/threat-protection/windows-defender-application-control/microsoft-recommended-driver-block-rules). It's active by default on Windows 11 22H2, [Windows in S mode](https://support.microsoft.com/windows/windows-10-and-windows-11-in-s-mode-faq-851057d6-1ee9-b9e5-c30b-93baebeebc85), [Windows 11 SE](/education/windows/windows-11-se-overview), and anywhere [memory integrity](https://support.microsoft.com/windows/core-isolation-e30ed737-17d8-42f3-a2a9-87521df09b78) (also known as hypervisor-protected code integrity (HVCI)) is on. Its policy binary file is found at `%windir%\System32\CodeIntegrity\driversipolicy.p7b` and in the EFI system partition at `<EFI System Partition>\Microsoft\Boot\driversipolicy.p7b`. |
| **Microsoft Windows Driver Policy** | {d2bda982-ccf6-4344-ac5b-0b44427b6816} | Kernel-only Base policy | This policy blocks known [vulnerable or malicious kernel drivers](../design/microsoft-recommended-driver-block-rules.md). It's active by default on Windows 11 22H2, [Windows in S mode](https://support.microsoft.com/windows/windows-10-and-windows-11-in-s-mode-faq-851057d6-1ee9-b9e5-c30b-93baebeebc85), [Windows 11 SE](/education/windows/windows-11-se-overview), and anywhere [memory integrity](https://support.microsoft.com/windows/core-isolation-e30ed737-17d8-42f3-a2a9-87521df09b78) (also known as hypervisor-protected code integrity (HVCI)) is on. Its policy binary file is found at `%windir%\System32\CodeIntegrity\driversipolicy.p7b` and in the EFI system partition at `<EFI System Partition>\Microsoft\Boot\driversipolicy.p7b`. |
| **Windows10S_Lockdown_Policy_Supplementable** | {5951a96a-e0b5-4d3d-8fb8-3e5b61030784} | Base policy | This policy is active on devices running [Windows in S mode](https://support.microsoft.com/windows/windows-10-and-windows-11-in-s-mode-faq-851057d6-1ee9-b9e5-c30b-93baebeebc85). Its policy binary file is found in the EFI system partition at `<EFI System Partition>\Microsoft\Boot\winsipolicy.p7b`. |
| **WindowsE_Lockdown_Policy** | {82443e1e-8a39-4b4a-96a8-f40ddc00b9f3} | Base policy | This policy is active on devices running [Windows 11 SE](/education/windows/windows-11-se-overview). Its policy binary file is found in the EFI system partition at `<EFI System Partition>\Microsoft\Boot\CIPolicies\Active\{82443e1e-8a39-4b4a-96a8-f40ddc00b9f3}.cip`. |
| **WindowsE_Lockdown_Flight_Policy_Supplemental** | {5dac656c-21ad-4a02-ab49-649917162e70} | Supplemental policy | This policy is active on devices running [Windows 11 SE](/education/windows/windows-11-se-overview) that are enrolled in the [Windows Insider](https://insider.windows.com) program. Its policy binary file is found in the EFI system partition at `<EFI System Partition>\Microsoft\Boot\CIPolicies\Active\{5dac656c-21ad-4a02-ab49-649917162e70}.cip`. |

51
windows/security/application-security/application-control/app-control-for-business/operations/known-issues.md
View File

@ -1,47 +1,46 @@
---
title: WDAC Admin Tips & Known Issues
description: WDAC Known Issues
title: App Control Admin Tips & Known Issues
description: App Control Known Issues
ms.manager: jsuther
ms.date: 04/15/2024
ms.topic: troubleshooting
ms.localizationpriority: medium
---
# WDAC Admin Tips & Known Issues
# App Control Admin Tips & Known Issues
> [!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).
[!INCLUDE [Feature availability note](../includes/feature-availability-note.md)]
This article covers tips and tricks for admins and known issues with Windows Defender Application Control (WDAC). Test this configuration in your lab before enabling it in production.
This article covers tips and tricks for admins and known issues with App Control for Business. Test this configuration in your lab before enabling it in production.
## WDAC policy file locations
## App Control policy file locations
**Multiple policy format WDAC policies** are found in the following locations depending on whether the policy is signed or not, and the method of policy deployment that was used.
**Multiple policy format App Control policies** are found in the following locations depending on whether the policy is signed or not, and the method of policy deployment that was used.
- &lt;OS Volume&gt;\\Windows\\System32\\CodeIntegrity\\CiPolicies\Active\\*\{PolicyId GUID\}*.cip
- &lt;EFI System Partition&gt;\\Microsoft\\Boot\\CiPolicies\Active\\*\{PolicyId GUID\}*.cip
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 preceding locations, also look for a file called SiPolicy.p7b in the following locations:
For **single policy format App Control policies**, in addition to the two preceding locations, also look for a file called SiPolicy.p7b in the following locations:
- &lt;EFI System Partition&gt;\\Microsoft\\Boot\\SiPolicy.p7b
- &lt;OS Volume&gt;\\Windows\\System32\\CodeIntegrity\\SiPolicy.p7b
> [!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.
> A multiple policy format App Control 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.
When the App Control 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, App Control stops further processing.
1. Explicit deny rules - a file is blocked if any explicit deny rule exists for it, 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.
1. Explicit deny rules - a file is blocked if any explicit deny rule exists for it, even if other rules are created to try to allow it. Deny rules can use any [rule level](../design/select-types-of-rules-to-create.md#app-control-for-business-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 rule exists for the file, the file runs.
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.
3. App Control then checks for the [Managed Installer extended attribute (EA)](../design/configure-authorized-apps-deployed-with-a-managed-installer.md) or the [Intelligent Security Graph (ISG) EA](../design/use-appcontrol-with-intelligent-security-graph.md) 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.
4. Lastly, App Control makes a cloud call to the ISG to get reputation about the file, if the policy enables the ISG option.
5. Any file not allowed by an explicit rule or based on ISG or MI is blocked implicitly.
@ -49,32 +48,32 @@ When the WDAC engine evaluates files against the active set of policies on the d
### Boot stop failure (blue screen) occurs if more than 32 policies are active
Until you apply the Windows security update released on or after April 9, 2024, your device is limited to 32 active policies. If the maximum number of policies is exceeded, the device bluescreens 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. To remove the maximum policy limit, install the Windows security update released on, or after, April 9, 2024 and then restart the device. Otherwise, reduce the number of policies on the device to remain below 32 policies.
Until you apply the Windows security update released on or after April 9, 2024, your device is limited to 32 active policies. If the maximum number of policies is exceeded, the device bluescreens referencing ci.dll with a bug check value of 0x0000003b. Consider this maximum policy count limit when planning your App Control policies. Any [Windows inbox policies](inbox-appcontrol-policies.md) that are active on the device also count towards this limit. To remove the maximum policy limit, install the Windows security update released on, or after, April 9, 2024 and then restart the device. Otherwise, reduce the number of policies on the device to remain below 32 policies.
**Note:** The policy limit was not removed on Windows 11 21H2, and will remain limited to 32 policies.
### Audit mode policies can change the behavior for some apps or cause app crashes
Although WDAC audit mode is designed to avoid impact to apps, some features are always on/always enforced with any WDAC policy that turns on user mode code integrity (UMCI) with the option **0 Enabled:UMCI**. Here's a list of known system changes in audit mode:
Although App Control audit mode is designed to avoid impact to apps, some features are always on/always enforced with any App Control policy that turns on user mode code integrity (UMCI) with the option **0 Enabled:UMCI**. Here's a list of known system changes in audit mode:
- Some script hosts might block code or run code with fewer privileges even in audit mode. See [Script enforcement with WDAC](/windows/security/application-security/application-control/windows-defender-application-control/design/script-enforcement) for information about individual script host behaviors.
- Option **19 Enabled:Dynamic Code Security** is always enforced if any UMCI policy includes that option. See [WDAC and .NET](/windows/security/application-security/application-control/windows-defender-application-control/design/wdac-and-dotnet#wdac-and-net-hardening).
- Some script hosts might block code or run code with fewer privileges even in audit mode. See [Script enforcement with App Control](../design/script-enforcement.md) for information about individual script host behaviors.
- Option **19 Enabled:Dynamic Code Security** is always enforced if any UMCI policy includes that option. See [App Control and .NET](../design/appcontrol-and-dotnet.md#app-control-and-net-hardening).
### .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 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 regenerates the native image at its next scheduled maintenance window.
In some cases, the code integrity logs where App Control for Business 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 regenerates the native image at its next scheduled maintenance window.
### Signatures using elliptical curve cryptography (ECC) aren't supported
WDAC signer-based rules only work with RSA cryptography. ECC algorithms, such as ECDSA, aren't supported. If WDAC blocks a file based on ECC signatures, the corresponding 3089 signature information events show VerificationError = 23. You can authorize the files instead by hash or file attribute rules, or using other signer rules if the file is also signed with signatures using RSA.
App Control signer-based rules only work with RSA cryptography. ECC algorithms, such as ECDSA, aren't supported. If App Control blocks a file based on ECC signatures, the corresponding 3089 signature information events show VerificationError = 23. You can authorize the files instead by hash or file attribute rules, or using other signer rules if the file is also signed with signatures using RSA.
### 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 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 App Control policy.
### MSI Installations launched directly from the internet are blocked by WDAC
### MSI Installations launched directly from the internet are blocked by App Control
Installing .msi files directly from the internet to a computer protected by WDAC fails.
Installing .msi files directly from the internet to a computer protected by App Control fails.
For example, this command fails:
```console
@ -89,13 +88,13 @@ msiexec -i c:\temp\Windows10_Version_1511_ADMX.msi
### Slow boot and performance with custom policies
WDAC evaluates all processes that run, including inbox Windows processes. You can cause slower boot times, degraded performance, and possibly boot issues if your policies don't build upon the WDAC templates or don't trust the Windows signers. For these reasons, you should use the [WDAC base templates](../design/example-appcontrol-base-policies.md) whenever possible to create your policies.
App Control evaluates all processes that run, including inbox Windows processes. You can cause slower boot times, degraded performance, and possibly boot issues if your policies don't build upon the App Control templates or don't trust the Windows signers. For these reasons, you should use the [App Control base templates](../design/example-appcontrol-base-policies.md) whenever possible to create your policies.
#### AppId Tagging policy considerations
AppId Tagging policies that aren't built upon the WDAC base templates or don't allow the Windows in-box signers might cause a significant increase in boot times (~2 minutes).
AppId Tagging policies that aren't built upon the App Control base templates or don't allow the Windows in-box signers might cause a significant increase in boot times (~2 minutes).
If you can't allowlist the Windows signers or build off the WDAC base templates, add the following rule to your policies to improve the performance:
If you can't allowlist the Windows signers or build off the App Control base templates, add the following rule to your policies to improve the performance:
:::image type="content" source="../images/known-issue-appid-dll-rule.png" alt-text="Allow all dlls in the policy.":::

16
windows/security/application-security/application-control/app-control-for-business/operations/querying-application-control-events-centrally-using-advanced-hunting.md
View File

@ -1,6 +1,6 @@
---
title: Query Application Control events with Advanced Hunting
description: Learn how to query Windows Defender Application Control events across your entire organization by using Advanced Hunting.
description: Learn how to query App Control for Business events across your entire organization by using Advanced Hunting.
ms.localizationpriority: medium
ms.date: 03/01/2022
ms.topic: troubleshooting
@ -8,12 +8,12 @@ ms.topic: troubleshooting
# Querying Application Control events centrally using Advanced hunting
A Windows Defender Application Control (WDAC) policy logs events locally in Windows Event Viewer in either enforced or audit mode.
A App Control for Business policy logs events locally in Windows Event Viewer in either enforced or audit mode.
While Event Viewer helps to see the impact on a single system, IT Pros want to gauge it across many systems.
In November 2018, we added functionality in Microsoft Defender for Endpoint that makes it easy to view WDAC events centrally from all connected systems.
In November 2018, we added functionality in Microsoft Defender for Endpoint that makes it easy to view App Control events centrally from all connected systems.
Advanced hunting in Microsoft Defender for Endpoint allows customers to query data using a rich set of capabilities. WDAC events can be queried with using an ActionType that starts with "AppControl".
Advanced hunting in Microsoft Defender for Endpoint allows customers to query data using a rich set of capabilities. App Control events can be queried with using an ActionType that starts with "AppControl".
This capability is supported beginning with Windows version 1607.
## Action Types
@ -22,8 +22,8 @@ This capability is supported beginning with Windows version 1607.
| - | - | - |
| AppControlCodeIntegrityDriverRevoked | 3023 | The driver file under validation didn't meet the requirements to pass the application control policy. |
| AppControlCodeIntegrityImageRevoked | 3036 | The signed file under validation is signed by a code signing certificate that has been revoked by Microsoft or the certificate issuing authority. |
| AppControlCodeIntegrityPolicyAudited | 3076 | This event is the main Windows Defender Application Control block event for audit mode policies. It indicates the file would have been blocked if the WDAC policy was enforced. |
| AppControlCodeIntegrityPolicyBlocked | 3077 | This event is the main Windows Defender Application Control block event for enforced policies. It indicates the file didn't pass your WDAC policy and was blocked. |
| AppControlCodeIntegrityPolicyAudited | 3076 | This event is the main App Control for Business block event for audit mode policies. It indicates the file would have been blocked if the App Control policy was enforced. |
| AppControlCodeIntegrityPolicyBlocked | 3077 | This event is the main App Control for Business block event for enforced policies. It indicates the file didn't pass your App Control policy and was blocked. |
| AppControlExecutableAudited | 8003 | Applied only when the Audit only enforcement mode is enabled. Specifies the .exe or .dll file would be blocked if the Enforce rules enforcement mode were enabled. |
| AppControlExecutableBlocked | 8004 | The .exe or .dll file can't run. |
| AppControlPackagedAppAudited | 8021 | Applied only when the Audit only enforcement mode is enabled. Specifies the packaged app would be blocked if the Enforce rules enforcement mode were enabled. |
@ -45,7 +45,7 @@ Learn more about the [Understanding Application Control event IDs (Windows)](eve
Query Example 1: Query the application control action types summarized by type for past seven days
Here's a simple example query that shows all the Windows Defender Application Control events generated in the last seven days from machines being monitored by Microsoft Defender for Endpoint:
Here's a simple example query that shows all the App Control for Business events generated in the last seven days from machines being monitored by Microsoft Defender for Endpoint:
```
DeviceEvents
@ -55,7 +55,7 @@ ActionType startswith "AppControl"
| order by Machines desc
```
The query results can be used for several important functions related to managing Windows Defender Application Control including:
The query results can be used for several important functions related to managing App Control for Business including:
- Assessing the impact of deploying policies in audit mode
Since applications still run in audit mode, it's an ideal way to see the impact and correctness of the rules included in the policy. Integrating the generated events with Advanced Hunting makes it much easier to have broad deployments of audit mode policies and see how the included rules would influence those systems in real world usage. This audit mode data will help streamline the transition to using policies in enforced mode.

43
windows/security/application-security/application-control/introduction-to-device-guard-virtualization-based-security-and-windows-defender-application-control.md
View File

@ -1,43 +0,0 @@
---
title: Windows Defender Application Control and virtualization-based code integrity
description: Hardware and software system integrity-hardening capabilities that can be deployed separately or in combination with Windows Defender Application Control (WDAC).
ms.localizationpriority: medium
author: vinaypamnani-msft
ms.author: vinpa
manager: aaroncz
ms.date: 03/26/2024
ms.topic: conceptual
appliesto:
- ✅ <a href=\"https://learn.microsoft.com/windows/release-health/supported-versions-windows-client\" target=\"_blank\">Windows 11</a>
- ✅ <a href=\"https://learn.microsoft.com/windows/release-health/supported-versions-windows-client\" target=\"_blank\">Windows 10</a>
- ✅ <a href=\"https://learn.microsoft.com/windows/release-health/windows-server-release-info\" target=\"_blank\">Windows Server 2022</a>
- ✅ <a href=\"https://learn.microsoft.com/windows/release-health/windows-server-release-info\" target=\"_blank\">Windows Server 2019</a>
- ✅ <a href=\"https://learn.microsoft.com/windows/release-health/windows-server-release-info\" target=\"_blank\">Windows Server 2016</a>
---
# Windows Defender Application Control and virtualization-based protection of code integrity
Windows includes a set of hardware and OS technologies that, when configured together, allow enterprises to "lock down" Windows systems so they behave more like kiosk devices. In this configuration, [**Windows Defender Application Control (WDAC)**](/windows/security/threat-protection/windows-defender-application-control/windows-defender-application-control) is used to restrict devices to run only approved apps, while the OS is hardened against kernel memory attacks using [**memory integrity**](../../hardware-security/enable-virtualization-based-protection-of-code-integrity.md).
> [!NOTE]
> Memory integrity is sometimes referred to as *hypervisor-protected code integrity (HVCI)* or *hypervisor enforced code integrity*, and was originally released as part of *Device Guard*. Device Guard is no longer used except to locate memory integrity and VBS settings in Group Policy or the Windows registry.
WDAC policies and memory integrity are powerful protections that can be used separately. However, when these two technologies are configured to work together, they present a strong protection capability for Windows devices. Using WDAC to restrict devices to only authorized apps has these advantages over other solutions:
1. The Windows kernel handles enforcement of WDAC policy and requires no other services or agents.
1. The WDAC policy takes effect early in the boot sequence before nearly all other OS code and before traditional antivirus solutions run.
1. WDAC lets you set application control policy for any code that runs on Windows, including kernel mode drivers and even code that runs as part of Windows.
1. Customers can protect the WDAC policy even from local administrator tampering by digitally signing the policy. Changing signed policy requires both administrative privilege and access to the organization's digital signing process. Using signed policies makes it difficult for an attacker, including one who manages to gain administrative privilege, to tamper with WDAC policy.
1. You can protect the entire WDAC enforcement mechanism with memory integrity. Even if a vulnerability exists in kernel mode code, memory integrity greatly reduces the likelihood that an attacker could successfully exploit it. Without memory integrity, an attacker who compromises the kernel could normally disable most system defenses, including application control policies enforced by WDAC or any other application control solution.
There are no direct dependencies between WDAC and memory integrity. You can deploy them individually or together and there's no order in which they must be deployed.
Memory integrity relies on Windows Virtualization-based security, and has hardware, firmware, and kernel driver compatibility requirements that some older systems can't meet.
WDAC has no specific hardware or software requirements.
## Related articles
- [Windows Defender Application Control](app-control-for-business/appcontrol.md)
- [Memory integrity](../../hardware-security/enable-virtualization-based-protection-of-code-integrity.md)
- [Driver compatibility with memory integrity](https://techcommunity.microsoft.com/t5/windows-hardware-certification/driver-compatibility-with-device-guard-in-windows-10/ba-p/364865)

43
windows/security/application-security/application-control/introduction-to-virtualization-based-security-and-appcontrol.md Normal file
View File

@ -0,0 +1,43 @@
---
title: App Control for Businessand virtualization-based code integrity
description: Hardware and software system integrity-hardening capabilities that can be deployed separately or in combination with App Control for Business.
ms.localizationpriority: medium
author: vinaypamnani-msft
ms.author: vinpa
manager: aaroncz
ms.date: 09/11/2024
ms.topic: conceptual
appliesto:
- ✅ <a href=\"https://learn.microsoft.com/windows/release-health/supported-versions-windows-client\" target=\"_blank\">Windows 11</a>
- ✅ <a href=\"https://learn.microsoft.com/windows/release-health/supported-versions-windows-client\" target=\"_blank\">Windows 10</a>
- ✅ <a href=\"https://learn.microsoft.com/windows/release-health/windows-server-release-info\" target=\"_blank\">Windows Server 2022</a>
- ✅ <a href=\"https://learn.microsoft.com/windows/release-health/windows-server-release-info\" target=\"_blank\">Windows Server 2019</a>
- ✅ <a href=\"https://learn.microsoft.com/windows/release-health/windows-server-release-info\" target=\"_blank\">Windows Server 2016</a>
---
# App Control for Businessand virtualization-based protection of code integrity
Windows includes a set of hardware and OS technologies that, when configured together, allow enterprises to "lock down" Windows systems so they behave more like kiosk devices. In this configuration, [**App Control for Business**](app-control-for-business/appcontrol.md) is used to restrict devices to run only approved apps, while the OS is hardened against kernel memory attacks using [**memory integrity**](../../hardware-security/enable-virtualization-based-protection-of-code-integrity.md).
> [!NOTE]
> Memory integrity is sometimes referred to as **hypervisor-protected code integrity (HVCI)** or **hypervisor enforced code integrity**, and was originally released as part of **Device Guard**. Device Guard is no longer used except to locate memory integrity and VBS settings in Group Policy or the Windows registry.
App Control policies and memory integrity are powerful protections that can be used separately. However, when these two technologies are configured to work together, they present a strong protection capability for Windows devices. Using App Control to restrict devices to only authorized apps has these advantages over other solutions:
1. The Windows kernel handles enforcement of App Control policy and requires no other services or agents.
1. The App Control policy takes effect early in the boot sequence before nearly all other OS code and before traditional antivirus solutions run.
1. App Control lets you set application control policy for any code that runs on Windows, including kernel mode drivers and even code that runs as part of Windows.
1. Customers can protect the App Control policy even from local administrator tampering by digitally signing the policy. Changing signed policy requires both administrative privilege and access to the organization's digital signing process. Using signed policies makes it difficult for an attacker, including one who manages to gain administrative privilege, to tamper with App Control policy.
1. You can protect the entire App Control enforcement mechanism with memory integrity. Even if a vulnerability exists in kernel mode code, memory integrity greatly reduces the likelihood that an attacker could successfully exploit it. Without memory integrity, an attacker who compromises the kernel could normally disable most system defenses, including application control policies enforced by App Control or any other application control solution.
There are no direct dependencies between App Control and memory integrity. You can deploy them individually or together and there's no order in which they must be deployed.
Memory integrity relies on Windows Virtualization-based security, and has hardware, firmware, and kernel driver compatibility requirements that some older systems can't meet.
App Control has no specific hardware or software requirements.
## Related articles
- [App Control for Business](app-control-for-business/appcontrol.md)
- [Memory integrity](../../hardware-security/enable-virtualization-based-protection-of-code-integrity.md)
- [Driver compatibility with memory integrity](https://techcommunity.microsoft.com/t5/windows-hardware-certification/driver-compatibility-with-device-guard-in-windows-10/ba-p/364865)

2
windows/security/application-security/application-control/toc.yml
View File

@ -4,7 +4,7 @@ items:
- name: Windows Defender Application Control
href: app-control-for-business/appcontrol.md
- name: Windows Defender Application Control and virtualization-based protection of code integrity
href: introduction-to-device-guard-virtualization-based-security-and-windows-defender-application-control.md
href: introduction-to-virtualization-based-security-and-appcontrol.md
- name: User Account Control (UAC)
items:
- name: Overview

2
windows/security/hardware-security/system-guard-secure-launch-and-smm-protection.md
View File

@ -55,7 +55,7 @@ To verify that Secure Launch is running, use System Information (MSInfo32). Sele
![Verifying Secure Launch is running in the Windows Security settings.](images/secure-launch-msinfo.png)
> [!NOTE]
> To enable System Guard Secure launch, the platform must meet all the baseline requirements for [System Guard](how-hardware-based-root-of-trust-helps-protect-windows.md), [Device Guard](../application-security/application-control/introduction-to-device-guard-virtualization-based-security-and-windows-defender-application-control.md), [Credential Guard](../identity-protection/credential-guard/index.md), and [Virtualization Based Security](/windows-hardware/design/device-experiences/oem-vbs).
> To enable System Guard Secure launch, the platform must meet all the baseline requirements for [System Guard](how-hardware-based-root-of-trust-helps-protect-windows.md), [Device Guard](../application-security/application-control/introduction-to-virtualization-based-security-and-appcontrol.md), [Credential Guard](../identity-protection/credential-guard/index.md), and [Virtualization Based Security](/windows-hardware/design/device-experiences/oem-vbs).
> [!NOTE]
> For more information around AMD processors, see [Microsoft Security Blog: Force firmware code to be measured and attested by Secure Launch on Windows 10](https://www.microsoft.com/security/blog/2020/09/01/force-firmware-code-to-be-measured-and-attested-by-secure-launch-on-windows-10/).

2
windows/security/threat-protection/index.md
View File

@ -19,7 +19,7 @@ See the following articles to learn more about the different areas of Windows th
- [Controlled Folder Access](/microsoft-365/security/defender-endpoint/controlled-folders)
- [Exploit Protection](/microsoft-365/security/defender-endpoint/exploit-protection)
- [Microsoft Defender Application Guard](../application-security/application-isolation/microsoft-defender-application-guard/md-app-guard-overview.md)
- [Microsoft Defender Device Guard](../application-security/application-control/introduction-to-device-guard-virtualization-based-security-and-windows-defender-application-control.md)
- [Microsoft Defender Device Guard](../application-security/application-control/introduction-to-virtualization-based-security-and-appcontrol.md)
- [Microsoft Defender SmartScreen](/windows/security/operating-system-security/virus-and-threat-protection/microsoft-defender-smartscreen/)
- [Network Protection](/microsoft-365/security/defender-endpoint/network-protection)
- [Virtualization-Based Protection of Code Integrity](../hardware-security/enable-virtualization-based-protection-of-code-integrity.md)