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

Merge pull request #10667 from jsuther1974/WDAC-Docs

Browse Source 
App control updates to support WRI
This commit is contained in:
Aditi Srivastava 2025-03-10 12:37:21 +05:30 committed by GitHub
commit 45f2dd2230
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
9 changed files with 185 additions and 201 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -2,7 +2,7 @@
title: App Control and AppLocker Overview
description: Compare Windows application control technologies.
ms.localizationpriority: medium
ms.date: 09/11/2024
ms.date: 03/09/2025
ms.topic: concept-article
---
@ -18,21 +18,21 @@ App Control was introduced with Windows 10 and allows organizations to control w
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 codesigning certificate used to sign an app and its binaries
- Attributes of the app's binaries that come from the signed metadata for the files, such as Original Filename and version, or the hash of the file
- The reputation of the app as determined by Microsoft's [Intelligent Security Graph](design/use-appcontrol-with-intelligent-security-graph.md)
- The identity of the process that initiated the installation of the app and its binaries ([managed installer](design/configure-authorized-apps-deployed-with-a-managed-installer.md))
- The [path from which the app or file is launched](design/select-types-of-rules-to-create.md#more-information-about-filepath-rules) (beginning with Windows 10 version 1903)
- The [path where the app or file exists on disk](design/select-types-of-rules-to-create.md#more-information-about-filepath-rules) (beginning with Windows 10 version 1903)
- The process that launched the app or binary
> [!NOTE]
> 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.
> App Control for Business was originally released as part of Device Guard and called configurable code integrity. The terms "Device Guard" and "configurable code integrity" are no longer used with App Control except when deploying policies through Group Policy.
### App Control System Requirements
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 App Control features are available on specific App Control builds, see [App Control feature availability](feature-availability.md).
For more information on which individual App Control features are available on your version of Windows, see [App Control feature availability](feature-availability.md).
## AppLocker
@ -40,9 +40,9 @@ AppLocker was introduced with Windows 7, and allows organizations to control whi
AppLocker policies can apply to all users on a computer, or to individual users and groups. AppLocker rules can be defined based on:
- Attributes of the codesigning certificate(s) used to sign an app and its binaries.
- Attributes of the codesigning certificate used to sign an app and its binaries.
- Attributes of the app's binaries that come from the signed metadata for the files, such as Original Filename and version, or the hash of the file.
- The path from which the app or file is launched.
- The path where the app or file exists on disk.
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).
@ -59,6 +59,11 @@ However, in some cases, AppLocker might be the more appropriate technology for y
- You have a mixed Windows operating system (OS) environment and need to apply the same policy controls to Windows 10 and earlier versions of the OS.
- You need to apply different policies for different users or groups on shared computers.
- You don't want to enforce application control on application files such as DLLs or drivers.
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.
## What you should read next
- If you want to use App control, one of the most powerful security features in Windows, you must plan and prepare if you want to succeed. Start that by exploring the [App Control for Business Design Guide](design/appcontrol-design-guide.md).
- If you're ready to jump in and start creating policies, revisit Smart App Control and [Use the Smart App Control policy to build your own starter policy](design/create-appcontrol-policy-for-lightly-managed-devices.md).

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

@ -4,7 +4,7 @@ description: Application Control restricts which applications users are allowed
ms.localizationpriority: medium
ms.collection:
- tier3
ms.date: 10/25/2024
ms.date: 03/09/2025
ms.topic: overview
---
@ -12,27 +12,27 @@ ms.topic: overview
[!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.
Your organization's data is one of its most valuable assets... and adversaries want it. No matter what security controls you apply over your data, there are no controls to fully protect your most vulnerable target: the trusted user sitting at the keyboard. When a user runs a process, that process shares the same access to your data that the user has. So your sensitive information is easily transmitted, modified, deleted, or encrypted when a user, intentionally or not, runs malicious software. And with thousands of new malicious files created every day, relying solely on traditional methods like antivirus (AV) solutions gives you an inadequate defense against new attacks.
In most organizations, information is the most valuable asset, and ensuring that only approved users have access to that information is imperative. However, when a user runs a process, that process has the same level of access to data that the user has. As a result, sensitive information could easily be deleted or transmitted out of the organization if a user knowingly or unknowingly runs malicious software.
Application control changes Windows from a place where all code runs unless your AV solution confidently predicts it's bad, to one where code runs only if your policy says so. The cyber threats you face change rapidly, and your defenses need to change too. Government and security organizations, like the Australian Signals Directorate, frequently cite application control as one of the most effective ways to address the threat of executable file-based malware (.exe, .dll, etc.). It works alongside your AV solution to help mitigate security threats by restricting the apps that users can run and even what code runs in the System Core (kernel).
Application control can help mitigate these types of security threats by restricting the applications that users are allowed to run and the code that runs in the System Core (kernel). Application control policies can also block unsigned scripts and MSIs, and restrict Windows PowerShell to run in [Constrained Language Mode](/powershell/module/microsoft.powershell.core/about/about_language_modes).
> [!IMPORTANT]
> Although application control can significantly harden your computers against malicious code, it's not a replacement for antivirus. You should continue to maintain an active antivirus solution alongside App Control for a well-rounded enterprise security portfolio.
Application control is a crucial line of defense for protecting enterprises given today's threat landscape, and it has an inherent advantage over traditional antivirus solutions. Specifically, application control moves away from an application trust model where all applications are assumed trustworthy to one where applications must earn trust in order to run. Many organizations, like the Australian Signals Directorate, understand the significance of application control and frequently cite application control as one of the most effective means for addressing the threat of executable file-based malware (.exe, .dll, etc.).
Although we call it application control, the code running on your system isn't always an app. Application control extends beyond apps to also cover scripts and Microsoft installers (MSI), command-line batch files, and even interactive sessions of Windows PowerShell, which run in [Constrained Language Mode](/powershell/module/microsoft.powershell.core/about/about_language_modes).
> [!NOTE]
> Although application control can significantly harden your computers against malicious code, we recommend that you continue to maintain an enterprise antivirus solution for a well-rounded enterprise security portfolio.
Windows includes two application control technologies you can use depending on your organization's specific scenarios and requirements:
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
- **App Control for Business (app control)**; and
- **AppLocker**
## 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 App Control. App control enables enterprise customers to create a policy that offers the same security and compatibility as Smart App Control with the capability to customize policies to run line-of-business (LOB) apps. To make it easier to implement 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).
Starting in Windows 11 version 22H2, [Smart App Control](https://support.microsoft.com/topic/what-is-smart-app-control-285ea03d-fa88-4d56-882e-6698afdb7003) brings robust application control to consumers and to some small businesses with simpler app portfolios. Smart App Control ensures only signed code runs or code predicted to be safe by our intelligent cloud-powered security service. When code is unsigned and the service is unable to predict with confidence that it's safe to run, then we block it. Over time, the code's reputation might change as the service processes new signals it receives. Meanwhile, code determined to be unsafe is always blocked.
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 use [CiTool.exe -r](operations/citool-commands.md#refresh-the-app-control-policies-on-the-system) for the change to take effect.
While Smart App Control is designed for consumers, we believe it's the ideal starting point for most organizations. And since we built it entirely upon App Control for Business, you can create a policy with the same security and compatibility as Smart App Control that also trusts the line-of-business (LOB) apps your organization needs. The service Smart App Control uses to predict what code is safe to run is also available in App Control for Business and called the Intelligent Security Graph (ISG).
Smart App Control starts in evaluation mode and switches off within 48 hours for enterprise managed devices unless the user turns it on first. If you want to proactively turn off Smart App Control across your organization's endpoints, 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 run [CiTool.exe -r](operations/citool-commands.md#refresh-the-app-control-policies-on-the-system) for the change to take effect.
| Value | Description |
|-------|-------------|
@ -43,11 +43,12 @@ Smart App Control is only available on clean installation of Windows 11 version
> [!IMPORTANT]
> Once you turn Smart App Control off, it can't be turned on without resetting or reinstalling Windows.
The App Control policy used for Smart App Control comes bundled with the [App Control Wizard](design/appcontrol-wizard.md) policy authoring tool and is also found as an [example policy](design/example-appcontrol-base-policies.md) at *%windir%/schemas/CodeIntegrity/ExamplePolicies/SmartAppControl.xml*. To use this example policy as a starting point for your own policy, see [Use the Smart App Control Policy to build your own base policy](design/create-appcontrol-policy-for-lightly-managed-devices.md#use-the-smart-app-control-policy-to-build-your-starter-policy). When using the Smart App Control example policy as the basis for your own custom policy, you must remove the option **Enabled:Conditional Windows Lockdown Policy** so it's ready for use as an App Control for Business policy.
[!INCLUDE [windows-defender-application-control-wdac](../../../../../includes/licensing/windows-defender-application-control-wdac.md)]
## Related articles
## What you should read next
- [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)
- To learn more about the two application control technologies available in Windows, read [App Control for Business and AppLocker Overview](./appcontrol-and-applocker-overview.md).
- To jump right in and get started creating policies, go revisit Smart App Control and [Use the Smart App Control policy to build your own starter policy](design/create-appcontrol-policy-for-lightly-managed-devices.md).

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

@ -2,7 +2,7 @@
title: Allow COM object registration in an App Control policy
description: You can allow COM object registration in an App Control for Business policy.
ms.localizationpriority: medium
ms.date: 09/11/2024
ms.date: 02/01/2025
ms.topic: how-to
---
@ -14,13 +14,10 @@ The [Microsoft Component Object Model (COM)](/windows/desktop/com/the-component-
## COM object configurability in App Control policy
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.
App Control for Business enforces a built-in allowlist for COM object registration. While this list works for most common application usage scenarios, you might 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.
- [Windows 10, 1809 June 18, 2019-KB4501371 (OS Build 17763.592)](https://support.microsoft.com/help/4501371/windows-10-update-kb4501371)
- [Windows 10, 1607 June 18, 2019-KB4503294 (OS Build 14393.3053)](https://support.microsoft.com/help/4503294/windows-10-update-kb4503294)
> [!WARNING]
> When App Control is enforced, .NET doesn't load certain COM objects if their registration GUID doesn't match the one calculated by the system at runtime. When that happens, the user sees a general COM load error dialog, but no events or other information is logged to the system. The COM allowlist mechanism described in this article **doesn't affect .NET's GUID validation check for COM objects** leaving those .NET apps incompatible with App Control at this time. For more information, see [App Control Admin Tips & Known Issues: .NET doesn't load COM objects with mismatched GUIDs](../operations/known-issues.md#net-doesnt-load-component-object-model-com-objects-with-mismatched-guids).
### Get COM object GUID
@ -131,7 +128,7 @@ To add this CLSID to the existing policy, follow these steps:
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.
Once the command runs, find the following section added to the policy XML.
```XML
<Settings>

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

@ -2,43 +2,46 @@
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: 09/11/2024
ms.date: 02/13/2025
ms.topic: article
---
# App Control for Business and .NET
> [!WARNING]
> When App Control is enforced, .NET doesn't load certain Component Object Model (COM) objects if their registration GUID doesn't match the one calculated by the system at runtime. When that happens, the user sees a general COM load error dialog, but no events or other information is logged to the system. For more information, see [App Control Admin Tips & Known Issues: .NET doesn't load COM objects with mismatched GUIDs](../operations/known-issues.md#net-doesnt-load-component-object-model-com-objects-with-mismatched-guids).
.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 an 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 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.
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 issue. Since the IL is now being compiled at runtime, you might notice a slight reduction in 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 [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 App Control EA isn't valid or missing:
To mitigate any performance reduction caused when the App Control EA isn't valid or is missing:
- 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).
## App Control and .NET hardening
## App Control and .NET Dynamic Code Security 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 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.
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. 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, the App 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.
When Dynamic Code Security is enabled, your App Control policy is applied to libraries that .NET loads from external or remote sources, like the internet or a network share. It also detects tampering in code generated to disk by .NET and blocks loading code that is tampered. Additionally, some .NET loading features not supported with Dynamic Code Security, including loading unsigned assemblies built with System.Reflection.Emit, are always blocked.
Usually, when dynamic code is blocked, its parent process is stopped or crashes. To prevent this using ASP.NET, you can precompile the dynamic code for deployment only. See ["Precompiling for Deployment Only" in the ASP.NET Precompilation Overview](/previous-versions/aspnet/bb398860(v=vs.100)#precompiling-for-deployment-only).
> [!IMPORTANT]
> .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.
> .NET Dynamic Code Security works in audit mode only on Windows 11 24H2 and later, and Windows Server 2025 and later. There's no audit mode for Dynamic Code Security on Windows 10, or on earlier versions of Windows 11 and Windows Server. If any App Control policy sets option **19 Enabled:Dynamic Code Security** on those earlier versions, then dynamic code security hardening is *turned on and enforced* even if the policy is in audit mode. Always test your apps thoroughly and use safe deployment practices when deploying app control policies to production.
Additionally, it detects tampering in code generated to disk by .NET and blocks loading code that was tampered with.
Dynamic Code Security mitigates potential attack techniques often referred to as "second order" attacks. That means that the attacker has access to the system and is able to run code. The second order attacks might be attempts to gain persistence or further obscure the attackers activities. Although Dynamic Code Security is important and recommended, Microsoft also recommends testing the policy in audit mode on systems running Windows 11 24H2 and later, or Windows Server 2025 and later before you enforce it.
Dynamic Code Security isn't enabled by default because existing policies might not account for externally loaded libraries.
Additionally, a few .NET loading features, including loading unsigned assemblies built with System.Reflection.Emit, aren't currently supported with Dynamic Code Security enabled.
Microsoft recommends testing Dynamic Code Security in audit mode before enforcing it to discover whether any new libraries should be included in the policy.
Code blocked by Dynamic Code Security is logged using event ID 3114 in the **CodeIntegrity - Operational** event log. Except for code loaded using one of the unsupported .NET features like System.Reflection.Emit, you can create rules to allow blocked dynamic code using information from the events. See [Use the App Control Wizard to create rules from the App Control Event Logs](./appcontrol-wizard-parsing-event-logs.md).
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.
> [!NOTE]
> .NET attempts two different methods to run dynamically generated code. If your App Control policy blocks the first method, .NET tries the second one. Each of the two attempts raises a distinct 3114 event. When a 3114 event occurs in isolation, it's safe to ignore as a "false positive" because it only covers the first attempt by .NET to run the code. Only when you see two 3114 events back-to-back within milliseconds for the same code does it indicate an actual issue to review.
To enable Dynamic Code Security, add the following option to the `<Rules>` section of your App Control policy:
To enable Dynamic Code Security, add option **19 - Enabled:Dynamic Code Security** to your App Control policy using the App Control Wizard, the set-ruleoption PowerShell cmdlet, or by adding the following to the `<Rules>` section of your App Control policy XML:
```xml
<Rule>

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

@ -2,7 +2,7 @@
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: 09/11/2024
ms.date: 02/23/2025
ms.topic: reference
---
@ -36,7 +36,6 @@ Unless your use scenarios explicitly require them, Microsoft recommends that you
- lxssmanager.dll
- lxrun.exe
- Microsoft.Build.dll
- Microsoft.Build.Framework.dll
- Microsoft.Workflow.Compiler.exe
- msbuild.exe<sup>2</sup>
- msbuild.dll
@ -101,7 +100,7 @@ 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 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.
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 formats 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.
**App Control policy XML**:
@ -168,7 +167,6 @@ The blocklist policy that follows includes "Allow all" rules for both kernel and
<Deny ID="ID_DENY_INTUNE_AGENT" FriendlyName="IntuneWindowsAgent.exe" FileName="Microsoft.Management.Services.IntuneWindowsAgent.exe" MinimumFileVersion="1.46.204.0" />
<Deny ID="ID_DENY_MFC40" FriendlyName="mfc40.dll" FileName="mfc40.dll" MinimumFileVersion="0.0.0.0" MaximumFileVersion="65355.65355.65355.65355" />
<Deny ID="ID_DENY_MS_BUILD" FriendlyName="Microsoft.Build.dll" FileName="Microsoft.Build.dll" MinimumFileVersion="0.0.0.0" MaximumFileVersion="65355.65355.65355.65355" />
<Deny ID="ID_DENY_MS_BUILD_FMWK" FriendlyName="Microsoft.Build.Framework.dll" FileName="Microsoft.Build.Framework.dll" MinimumFileVersion="0.0.0.0" MaximumFileVersion="65355.65355.65355.65355" />
<Deny ID="ID_DENY_MWFC" FriendlyName="Microsoft.Workflow.Compiler.exe" FileName="Microsoft.Workflow.Compiler.exe" MinimumFileVersion="0.0.0.0" MaximumFileVersion="65355.65355.65355.65355" />
<Deny ID="ID_DENY_MSBUILD" FriendlyName="MSBuild.exe" FileName="MSBuild.exe" MinimumFileVersion="0.0.0.0" MaximumFileVersion="65355.65355.65355.65355" />
<Deny ID="ID_DENY_MSBUILD_DLL" FriendlyName="MSBuild.dll" FileName="MSBuild.dll" MinimumFileVersion="0.0.0.0" MaximumFileVersion="65355.65355.65355.65355" />
@ -871,7 +869,6 @@ The blocklist policy that follows includes "Allow all" rules for both kernel and
<FileRuleRef RuleID="ID_DENY_INTUNE_AGENT" />
<FileRuleRef RuleID="ID_DENY_MFC40" />
<FileRuleRef RuleID="ID_DENY_MS_BUILD" />
<FileRuleRef RuleID="ID_DENY_MS_BUILD_FMWK" />
<FileRuleRef RuleID="ID_DENY_MWFC" />
<FileRuleRef RuleID="ID_DENY_MSBUILD" />
<FileRuleRef RuleID="ID_DENY_MSBUILD_DLL" />

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

@ -2,7 +2,7 @@
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: 09/11/2024
ms.date: 01/31/2025
ms.topic: install-set-up-deploy
---
@ -10,20 +10,24 @@ ms.topic: install-set-up-deploy
[!INCLUDE [Feature availability note](../includes/feature-availability-note.md)]
Whenever possible, App Control for Business (app control) should be enabled when setting up a device for the first time and before installing any apps. This ensures the system is in a "clean" state when App Control starts, and is especially important for apps allowed because they were installed by a managed installer or because the Intelligent Security Graph (ISG) determined that the app was safe to run.
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
## Common use cases
| Type of device | How App Control relates to this type of device |
| Use case | How App Control relates to this use case |
|------------------------------------|------------------------------------------------------|
| **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. |
| **Block undesirable apps**: Few companies manage all apps centrally, needing a long discovery period before they can even begin to decide what to allow. <BR> Instead, the IT department's focus shifts to block a set of apps they consider problems, while they build their inventory of apps. | Using App Control, deploy a blocklist-only policy alongside an audit allowlist policy to gather information about the apps and processes running on your devices. |
| **Lightly managed devices**: Company-owned, but users are free to install software.<br>Devices are required to run specific apps, like the organization's antivirus solution or its helpdesk client management tools. | App Control for Business can be used to help protect the kernel, and to let users run apps that are signed, are installed by the company's app deployment solution like Intune, were installed to locations where only an admin can write files, and any app with good reputation. |
| **Fully managed devices**: Allowed software is restricted by your IT department.<br>Users can request for more software, or install from a list of applications provided by the 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, they may update the App Control policy as part of their app packaging and deployment processes. Alternatively, they may create and sign app catalog files that are then distributed as a dependency of the app. |
| **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. |
| **"Dirty" systems**: Introducing an app control solution on systems that are already in use is much more challenging than when you apply it to a new device that hasn't installed any apps yet. Sometimes, trade-offs must be made to maintain productivity even if some apps might be unwanted by the organization. | Using a script to apply App Control policies, organizations can create a policy by scanning each device and creating rules for every binary or script file observed. This set of rules is used to supplement the more restrictive Base policy applied to fresh devices, newly configured. This way, any previously installed app keeps working, but all future installs must pass the organizations newly enforced app control rules. |
## An introduction to Lamna Healthcare Company
In the next set of articles, we'll explore each of the above scenarios using a fictional organization called Lamna Healthcare Company.
In the next set of articles, we'll explore policies to handle scenarios like the ones in the table using a fictional company called Lamna Healthcare Company.
Lamna Healthcare Company (Lamna) is a large healthcare provider operating in the United States. Lamna employs thousands of people, from doctors and nurses to accountants, in-house lawyers, and IT technicians. Their device use cases are varied and include single-user workstations for their professional staff, shared kiosks used by doctors and nurses to access patient records, dedicated medical devices such as MRI scanners, and many others. Additionally, Lamna has a relaxed, bring-your-own-device policy for many of their professional staff.
@ -33,4 +37,10 @@ Recently, Lamna experienced a ransomware event that required an expensive recove
## Up next
- [Create an App Control for Business policy for lightly managed devices](create-appcontrol-policy-for-lightly-managed-devices.md)
Now, let's create our initial policy using the [Smart App Control](../appcontrol.md#app-control-and-smart-app-control) "circle of trust" as our starting point.
- [Use the Smart App Control policy to build your starter base policy](./create-appcontrol-policy-for-lightly-managed-devices.md).
Or, if you prefer:
- [Use an App Control policy to block specific apps](./create-appcontrol-deny-policy.md).

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

@ -1,146 +1,106 @@
---
title: Create an App Control policy for lightly managed devices
title: Use the Smart App Control policy to build your starter base policy
description: App Control for Business restricts which applications users are allowed to run and the code that runs in the system core.
ms.topic: how-to
ms.localizationpriority: medium
ms.date: 09/11/2024
ms.date: 03/09/2025
---
# Create an App Control policy for lightly managed devices
# Use the Smart App Control policy to build your starter policy
[!INCLUDE [Feature availability note](../includes/feature-availability-note.md)]
This section outlines the process to create an App Control for Business policy for **lightly managed devices** within an organization. Typically, organizations that are new to App 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.
This article describes how to create an App Control for Business policy using the Smart App Control policy as a template. [Smart App Control](https://support.microsoft.com/topic/what-is-smart-app-control-285ea03d-fa88-4d56-882e-6698afdb7003) is an app control-based security solution designed for consumer users. It uses the same technology as App Control for Business so it's easy to use as the basis for an equally robust but flexible enterprise policy.
> [!NOTE]
> 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.
> [!TIP]
> Microsoft recommends the policy created in this article as the ideal starter policy for most App Control deployments to end users' devices. Typically, organizations new to App Control are most successful if they start with a permissive policy like the one described in this article. You can harden the policy over time to achieve a stronger overall security posture on your App Control-managed devices as described in later articles.
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 App Control to prevent unwanted or unauthorized applications from running on their managed devices.
As we did in [App Control for Business deployment in different scenarios](common-appcontrol-use-cases.md), let's use the fictional example of **Lamna Healthcare Company (Lamna)** to illustrate this scenario. Lamna intends to adopt stronger application policies, including the use of App 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 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 App Control and use different policies for different workloads.
**Alice Pena (she/her)** is the IT team lead tasked with the rollout of App Control. Lamna currently has relaxed application usage policies and a culture of maximum app flexibility for users. So, Alice knows they need to take an incremental approach to App Control and likely use different policies for different user segments. But for now, Alice wants a policy that can cover most users without any modifications, Smart App Control's "Signed & Reputable" policy adapted for Lamna.
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.
## Analyze how Smart App Control's "circle-of-trust" fits for you
Alice follows the guidance from the article [Plan for app control policy lifecycle management](./plan-appcontrol-management.md#policy-xml-lifecycle-management), and starts by analyzing the "circle-of-trust" for Smart App Control's policy. Alice reads Microsoft's online help articles about Smart App Control to understand it well. From that reading, Alice learns that Smart App Control allows only publicly trusted signed code or unsigned code that the [Intelligent Security Graph (ISG)](./use-appcontrol-with-intelligent-security-graph.md) predicts to be safe. Publicly trusted signed code means the signing certificate's issuer is one of the certificate authorities (CA) in Microsoft's Trusted Root Program. Unsigned code is blocked from running if the ISG can't predict that the code is safe to run. And code determined to be unsafe is always blocked.
Now Alice considers how to adapt the policy for Lamna's use. Alice wants to create an initial policy that is as relaxed as possible, but still provides durable security value. Some within Lamna advocate a more aggressive approach than Alice plans. They want to immediately lockdown end users' devices and hope for limited fallout. But the leadership team agrees with Alice that Lamna's app culture, formed slowly over time, won't just go away overnight and so the initial policy needs much flexibility.
### Consider the key factors about your organization
Alice next identifies the key factors about Lamna's environment that affect the company's "circle-of-trust." The policy must be flexible to meet the needs of the business in the short- and medium-term. That gives Lamna time to introduce new app management processes and policies to make it practical for a more restrictive app control policy in the future. The key factors also help Alice choose which systems to include in the first deployment. Alice writes down these factors in the planning document:
- **User privileges:** Most users are standard user, but nearly a quarter have local admin rights on their devices and the option to run any app they choose is a major contributing factor.
- **Operating Systems:** Windows 11 runs most user devices, but Lamna expects ~10% of clients to remain on Windows 10 through the next fiscal year, particularly in smaller satellite offices. Lamna's servers and specialized equipment are out of scope at this time.
- **Client management:** Lamna uses Microsoft Intune for all Windows 11 devices, deployed as Microsoft Entra cloud-native. They continue to use Microsoft Endpoint Configuration Manager (MEMCM) for most Windows 10 devices, deployed as Microsoft Entra hybrid join.
- **App management:** Lamna has hundreds of line-of-business (LOB) apps across its business units. Alice's team deploys most, but not all, of these apps using Intune. And there's a long tail of apps used by smaller teams, including many "Shadow IT" apps, that have no official charter, but are critical to the employees who use them.
- **App development and code signing:** Lamna business units aren't standardized on development platforms and frameworks, so significant variability and complexity is likely. Almost all of the apps use unsigned, or mostly unsigned, code. Although the company now requires codesigning, Lamna's codesigning certificates come from its corporate Public Key Infrastructure (PKI), and require custom rules in the policy.
## Define the "circle-of-trust" for lightly managed devices
Alice identifies the following key factors to arrive at the "circle-of-trust" for Lamna's lightly managed devices, which currently include most end-user devices:
Based on these factors, Alice writes the pseudo-rules for the Lamna version of Microsoft's Signed & Reputable policy:
- All clients are running Windows 10 version 1903 and above, or Windows 11;
- All clients are managed by Configuration Manager or with Intune.
- Some, but not all, apps are deployed using Configuration Manager;
- Most users are local administrators on their devices;
- Some teams may need more rules to authorize specific apps that don't apply generally to all other users.
1. **"Windows and Microsoft-certified kernel drivers"** One or more signer rules allowing:
- Windows and its components.
- Kernel drivers signed by the Windows Hardware Quality Labs (WHQL) certificate authority.
Based on the above, Alice defines the pseudo-rules for the policy:
2. **"Publicly-trusted signed code"** One or more signer rules allowing:
- Code signed with certificates issued from any certificate authority participating in the [Microsoft Trusted Root Program ("AuthRoot")](/security/trusted-root/program-requirements) or non-OS code signed by Microsoft.
1. **"Windows works"** rules that authorize:
- Windows
- WHQL (third-party kernel drivers)
- Windows Store signed apps
3. **Lamna signed code** One or more signer rules allowing:
- Code signed by certificates issued from Lamna Codesigning private certificate authority (PCA), the intermediate cert issued from their own internal PKI.
1. **"ConfigMgr works"** rules that include:
- Signer and hash rules for Configuration Manager components to properly function.
- **Allow Managed Installer** rule to authorize Configuration Manager as a managed installer.
4. **Allow apps based on their "reputation"** A policy option allowing:
- Apps predicted to be "safe" by the ISG.
1. **Allow Intelligent Security Graph (ISG)** (reputation-based authorization)
5. **Allow Managed Installer** A policy option allowing:
- Code written to the system by a process designated by policy as a managed installer. For Lamna's managed installer policy, Alice includes the Intune Management Extension, and also well-known autoupdater processes for widely used apps. Alice also includes a filepath rule, "D:\ Lamna Helpdesk\*" where Lamna's helpdesk admins are trained to copy the app installers and scripts they use to repair user's apps and systems.
1. **Signed apps** using a certificate issued by a Windows Trusted Root Program certificate authority
6. **Admin-only path rules** One or more filepath rules for the following locations:
- "C:\Program Files\*"
- "C:\Program Files (x86)\*"
- "%windir%\*"
- "D:\Lamna Helpdesk\*"
1. **Admin-only path rules** for the following locations:
- C:\Program Files\*
- C:\Program Files (x86)\*
- %windir%\*
## Modify the "Signed & Reputable" policy template for your organization
## Create a custom base policy using an example App Control base policy
Alice downloads the App Control Policy Wizard from https://aka.ms/appcontrolwizard and runs it.
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.
1. On the **Welcome** page, Alice sees three options: **Policy Creator**, **Policy Editor**, and **Policy Merger**. Alice selects **Policy Creator** which takes her to the next page.
Alice follows these steps to complete this task:
2. On **Select a Policy Type**, Alice must choose whether to create a *Multiple Policy Format* or *Single Policy Format* policy. Since all of the end users' devices run Windows 11 or current versions of Windows 10, Alice leaves the default *Multiple Policy Format*. Similarly, the choice between *Base Policy* and *Supplemental Policy* is straightforward and, here too, leaves the default *Base Policy* selected. Alice selects **Next** to continue.
1. On a client device, run the following commands in an elevated Windows PowerShell session to initialize variables:
3. The next page is where Alice will **Select a Base Template for the Policy**. The App Control Wizard offers three template policies to use when creating a new Base Policy. Each template policy applies slightly different rules to alter its circle-of-trust and security model of the policy. The three template policies are:
> [!NOTE]
> 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.
[![Screenshot that shows selecting a base template for the policy.](../images/appcontrol-wizard-template-selection.png)](../images/appcontrol-wizard-template-selection.png#lightbox)
```powershell
$PolicyPath = $env:userprofile+"\Desktop\"
$PolicyName= "Lamna_LightlyManagedClients_Audit"
$LamnaPolicy=Join-Path $PolicyPath "$PolicyName.xml"
$ExamplePolicy=$env:windir+"\schemas\CodeIntegrity\ExamplePolicies\SmartAppControl.xml"
```
| Template Base Policy | Description |
|---------------------------------|-------------------------------------------------------------------|
| **Default Windows mode** | Default Windows mode authorizes the following components: </br><ul><li>Windows operating system components - any binary installed by a fresh install of Windows</li><li>MSIX packaged apps signed by the Microsoft Store MarketPlace signer</li><li>Microsoft Office365 apps, OneDrive, and Microsoft Teams</li><li>[WHQL signed drivers](/windows-hardware/drivers/install/whql-release-signature)</li></ul>|
| **Allow Microsoft mode** | Allow Microsoft mode authorizes the following components: </br><ul><li>All code allowed by Default Windows mode, plus...</li><li>*All Microsoft-signed software*</li></ul>|
| **Signed and Reputable mode** | Signed and Reputable mode authorizes the following components: </br><ul><li>All code allowed by Allow Microsoft mode, plus...<</li><li>*Files created or installed by a process configured as a [managed installer](./configure-authorized-apps-deployed-with-a-managed-installer.md)*</li><li>*Files with good reputation per [Microsoft Defender's Intelligent Security Graph technology](use-appcontrol-with-intelligent-security-graph.md)*</li></ul>|
Alice selects the **Signed and Reputable mode** template and then **Next**, accepting the defaults for the policy filename and location.
1. Copy the example policy to the desktop:
4. On **Configure Policy Template - Policy rules**, Alice reviews the set of options enabled for the policy. The template already has most options set as recommended by Microsoft. The only changes Alice makes are to check the options for **Managed Installer** and **Require WHQL**. This way apps installed by Intune or any of the other managed installers are automatically allowed, and only kernel drivers built for Windows 10 or higher can run. Selecting **Next** advances the wizard.
```powershell
Copy-Item $ExamplePolicy $LamnaPolicy
```
> [!div class="mx-imgBorder"]
> [![Screenshot that shows rule options UI for Windows Allowed mode policy.](../images/appcontrol-wizard-rule-options-UI-advanced-collapsed.png)](../images/appcontrol-wizard-rule-options-UI-advanced-collapsed.png#lightbox)
1. Modify the policy to remove unsupported rule:
5. The **File Rules** page shows the rules from the Signed and Reputable mode template policy. Alice adds the Signer rule to trust Lamna-signed code, and the filepath rules to allow code in admin-writable-only locations under the two Program Files directories, the Windows directory, and Lamna's Helpdesk folder.
> [!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 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.
To create each rule, Alice selects **+ Add Custom** which opens the **Custom Rules** dialog where the conditions for the rule are defined. For the first rule, the default selections for **Rule Scope** and **Rule Action** are correct. For the **Rule Type** dropdown, the **Publisher** option is the correct choice to create a Signer rule. Alice then selects **Browse** and picks a file signed by a cert issued by the Lamna Codesigning PCA. The Wizard shows the signature information and information pulled from the resource header section (RSRC) of the file, like ***product name*** and the ***original file name*** with checkboxes by each element. In this case, since they intend to allow everything signed with Lamna's internal codesigning certs, Alice leaves only ***Issuing CA*** and ***Publisher*** checked. With the rule conditions for the Lamna Codesigning PCA rule set, Alice selects **Create Rule** and sees the rule is included in the list. Alice repeats these steps for the rest of Lamna's custom rules.
```powershell
[xml]$xml = Get-Content $LamnaPolicy
$ns = New-Object System.Xml.XmlNamespaceManager($xml.NameTable)
$ns.AddNamespace("ns", $xml.DocumentElement.NamespaceURI)
$node = $xml.SelectSingleNode("//ns:Rules/ns:Rule[ns:Option[.='Enabled:Conditional Windows Lockdown Policy']]", $ns)
$node.ParentNode.RemoveChild($node)
$xml.Save($LamnaPolicy)
```
[![Screenshot that shows custom filepublisher file rule creation.](../images/appcontrol-wizard-custom-publisher-rule.png)](../images/appcontrol-wizard-custom-publisher-rule.png#lightbox)
1. Give the new policy a unique ID, descriptive name, and initial version number:
6. Now that all of the edits described in the pseudo-rules are done, Alice selects **Next** and the wizard creates the App Control policy files. The output files include an XML form and a compiled binary form of the policy. Alice does a cursory review of the XML policy file to confirm the result looks good and then closes the wizard.
```powershell
Set-CIPolicyIdInfo -FilePath $LamnaPolicy -PolicyName $PolicyName -ResetPolicyID
Set-CIPolicyVersion -FilePath $LamnaPolicy -Version "1.0.0.0"
```
Alice uploads both files to a GitHub repository created specifically for Lamna's app control policy files.
1. [Use Configuration Manager to create and deploy an audit policy](/configmgr/protect/deploy-use/use-device-guard-with-configuration-manager) to the client device running Windows 10 version 1903 and above, or Windows 11. Merge the Configuration Manager policy with the example policy.
Alice's starter policy is now ready to deploy in audit mode to Lamna's managed devices.
> [!NOTE]
> If you do not use Configuration Manager, skip this step.
## Security considerations of this policy
```powershell
$ConfigMgrPolicy=$env:windir+"\CCM\DeviceGuard\MergedPolicy_Audit_ISG.xml"
Merge-CIPolicy -OutputFilePath $LamnaPolicy -PolicyPaths $LamnaPolicy,$ConfigMgrPolicy
Set-RuleOption -FilePath $LamnaPolicy -Option 13 # Managed Installer
```
1. Modify the policy to set additional policy rules:
```powershell
Set-RuleOption -FilePath $LamnaPolicy -Option 3 # Audit Mode
Set-RuleOption -FilePath $LamnaPolicy -Option 12 # Enforce Store Apps
Set-RuleOption -FilePath $LamnaPolicy -Option 19 # Dynamic Code Security
```
1. Add rules to allow the Windows and Program Files directories:
```powershell
$PathRules += New-CIPolicyRule -FilePathRule "%windir%\*"
$PathRules += New-CIPolicyRule -FilePathRule "%OSDrive%\Program Files\*"
$PathRules += New-CIPolicyRule -FilePathRule "%OSDrive%\Program Files (x86)\*"
Merge-CIPolicy -OutputFilePath $LamnaPolicy -PolicyPaths $LamnaPolicy -Rules $PathRules
```
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 App Control for Business policy to a binary format:
```powershell
[xml]$PolicyXML = Get-Content $LamnaPolicy
$LamnaPolicyBin = Join-Path $PolicyPath "$($PolicyXML.SiPolicy.PolicyID).cip"
ConvertFrom-CIPolicy $LamnaPolicy $LamnaPolicyBin
```
1. Upload your base policy XML and the associated binary to 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).
At this point, Alice now has an initial policy that is ready to deploy in audit mode to the managed clients within Lamna.
## Security considerations of this lightly managed policy
In order to minimize user productivity impact, Alice has defined a policy that makes several trade-offs between security and user app flexibility. Some of the trade-offs include:
In order to minimize the potential to negatively affect user productivity, Alice defined a policy that makes several trade-offs between security and user app flexibility. Some of the trade-offs include:
- **Users with administrative access**
@ -148,18 +108,18 @@ In order to minimize user productivity impact, Alice has defined a policy that m
Possible mitigations:
- 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 App Control at boot time and use that information to condition access to sensitive corporate resources.
- To prevent tampering of App Control policies, use signed App Control policies on systems running Unified Extensible Firmware Interface (UEFI) firmware.
- To remove the need for trusting managed installer, create and deploy signed catalog files or deploy updated policies as part of your regular app deployment and app updating procedures.
- To control access to other corporate resources and data, use the boot time measurement of App Control configuration state from the Trusted Computing Group (TCG) log with device attestation.
- **Unsigned policies**
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.
Any process running as administrator can replace or remove unsigned policies without consequence. Similarly, unsigned supplemental policies can alter the "circle-of-trust" for an unsigned base policy that includes option **17 Enabled:Allow Supplemental Policies**.
Possible mitigations:
- 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.
- To prevent tampering of App Control policies, use signed App Control policies on systems running UEFI firmware.
- To minimize the risk, limit who can elevate to administrator on the device.
- **Managed installer**
@ -167,8 +127,8 @@ In order to minimize user productivity impact, Alice has defined a policy that m
Possible mitigations:
- To remove the requirement for managed installer, create and deploy signed catalog files as part of the app deployment process.
- Limit who can elevate to administrator on the device.
- To remove the need for trusting managed installer, create and deploy signed catalog files or deploy updated policies as part of your regular app deployment and app updating procedures.
- To minimize the risk, limit who can elevate to administrator on the device.
- **Intelligent Security Graph (ISG)**
@ -176,12 +136,12 @@ In order to minimize user productivity impact, Alice has defined a policy that m
Possible mitigations:
- Implement policies that require apps be managed by IT. Audit existing app usage and deploy authorized apps using a software distribution solution, like Microsoft Intune. Move from ISG to managed installer or signature-based rules.
- Use a restrictive audit mode policy to audit app usage and augment vulnerability detection.
- To remove the need for trusting ISG, perform a comprehensive audit of existing app usage and installation. Onboard any apps you find that aren't currently managed to your software distribution solution, like Microsoft Intune. Implement policies to require apps become managed by IT. Then transition from ISG to managed installer, signed catalog files and/or updated policy rules and deploy them as part of your regular app deployment and app updating procedures.
- To collect more data for use in security incident investigations and post-incident reviews, deploy a highly restrictive app control policy in audit mode. The data captured in the App Control event logs contains useful information about all code that runs that isn't Windows signed. To prevent your policy from impacting your device performance and functionality, be sure it minimally allows Windows code that runs as part of the boot process.
- **Supplemental policies**
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.
Supplemental policies are designed to expand the "circle-of-trust" defined by the base policy. If the base policy is also unsigned, then any process running as administrator can place an unsigned supplemental policy and expand the "circle-of-trust" of the base policy without restriction.
Possible mitigations:
@ -195,17 +155,18 @@ In order to minimize user productivity impact, Alice has defined a policy that m
Possible mitigations:
- Limit who can elevate to administrator on the device.
- Migrate from filepath rules to managed installer or signature-based rules.
- Transition from filepath rules to managed installer or signature-based rules.
- **Signed files**
- **Signed malware**
Although files that are code-signed verify the author's identity and ensures that the code hasn't been altered by anyone other than the author, it doesn't guarantee that the signed code is safe.
Code signing alone isn't a security solution, but it does provide two critical building blocks that make security solutions like App Control possible. First, code signing strongly associates code with a real-world identity... and a real world identity can face consequences that a nameless, shadowy figure responsible for unsigned malware doesn't. Second, code signing provides cryptographic proof that the code running remains untampered since the publisher signed it. An app control policy that requires all code is signed, or the policy explicitly allows it, raises the stakes and the costs for an attacker. But there remain ways for a motivated attacker to get their malicious code signed and trusted, at least for a while. And even when software comes from a trustworthy source, it doesn't mean it's safe to run. Any code can expose powerful capabilities that a malicious actor could exploit for their own ill-intent. And vulnerabilities can turn the most benign code into something truly dangerous.
Possible mitigations:
- Use a reputable antimalware or antivirus software with real-time protection, such as Microsoft Defender, to protect your devices from malicious files, adware, and other threats.
- Use a reputable anti-malware or antivirus software with real-time protection, such as Microsoft Defender, to protect your devices from malicious files, adware, and other threats.
## Up next
## What you should read next
- [Create an 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)
- Learn more about managed installers: how they work, how to set them up, and what are their limitations in [Automatically allow apps deployed by a managed installer](./configure-authorized-apps-deployed-with-a-managed-installer.md).
- Learn how to deploy your starter policy and see it in action in [Deploying App Control for Business policies](../deployment/appcontrol-deployment-guide.md).

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

@ -3,7 +3,7 @@ title: Example App Control for Business base policies
description: When creating an 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: 09/11/2024
ms.date: 03/09/2025
---
# App Control for Business example base policies
@ -14,18 +14,18 @@ When you create policies for use with App Control for Business, start from an ex
| 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.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 |
| **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*\Templates\DefaultWindows_\*.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*\Templates\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 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 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 |
| **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 [Use the Smart App Control policy to build your starter Base policy](create-appcontrol-policy-for-lightly-managed-devices.md#use-the-smart-app-control-policy-to-build-your-starter-policy). | %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies\SmartAppControl.xml <br>%ProgramFiles%\WindowsApps\Microsoft.WDAC.WDACWizard*\Templates\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 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 |
| **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.WDAC.WDACWizard*\Templates\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.WDAC.WDACWizard*\Templates\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*\Templates\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*\Templates\WinSEPolicy.xml.xml |
> [!NOTE]
> Not all policies shown available at %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies can be found on all versions of Windows.

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

@ -2,7 +2,7 @@
title: App Control Admin Tips & Known Issues
description: App Control Known Issues
ms.manager: jsuther
ms.date: 09/11/2024
ms.date: 02/13/2025
ms.topic: troubleshooting
ms.localizationpriority: medium
---
@ -28,21 +28,21 @@ For **single policy format App Control policies**, in addition to the two preced
- &lt;OS Volume&gt;\\Windows\\System32\\CodeIntegrity\\SiPolicy.p7b
> [!NOTE]
> 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.
> A multiple policy format App Control policy using the single policy format GUID `{A244370E-44C9-4C06-B551-F6016E563076}` might exist under any of the policy file locations.
## File Rule Precedence Order
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](../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.
1. Any file matching an explicit deny rule is blocked, even if you create other rules 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.
2. Any file matching an explicit allow rule runs.
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.
3. Any file that has a [Managed Installer](../design/configure-authorized-apps-deployed-with-a-managed-installer.md) or [Intelligent Security Graph (ISG)](../design/use-appcontrol-with-intelligent-security-graph.md) extended attribute (EA) runs if the policy enables the matching option (managed installer or ISG).
4. Lastly, App Control makes a cloud call to the ISG to get reputation about the file, if the policy enables the ISG option.
4. Any file that isn't allowed based on the preceding conditions, is checked for reputation using the ISG when that option is enabled in the policy. The file runs if the ISG decides that it's safe and a new ISG EA is written on the file.
5. Any file not allowed by an explicit rule or based on ISG or MI is blocked implicitly.
5. Any file not allowed by an explicit rule, or based on ISG or managed installer, is blocked implicitly.
## Known issues
@ -51,19 +51,29 @@ When the App Control engine evaluates files against the active set of policies o
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.
> The policy limit wasn't removed on Windows 11 21H2, and remains limited to 32 policies.
### Audit mode policies can change the behavior for some apps or cause app crashes
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:
Although App Control audit mode is designed to avoid any effect on 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 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).
- Option **19 Enabled:Dynamic Code Security** is always enforced if any UMCI policy includes that option on some versions of Windows and Windows Server. See [App Control and .NET](../design/appcontrol-and-dotnet.md#app-control-and-net-dynamic-code-security-hardening).
### .NET native images may generate false positive block events
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. To prevent that, consider compiling your .NET application ahead of time using the [Native AOT](/dotnet/core/deploying/native-aot) feature.
### .NET doesn't load Component Object Model (COM) objects with mismatched GUIDs
COM objects make it easy for different software components to communicate and work together. To be used by another component, COM objects must be registered with the operating system. The registration includes a GUID that is calculated based on the object's code. Loading and activation of the COM object is done using another part of the registration called the type name. Sometimes a mismatch exists between the registered GUID and the actual GUID of the activated COM object's code. Mismatches might come from bugs in the app's COM object registration code or if the COM object's code is changed in a way that affects the GUID. Normally, Windows and .NET are forgiving about this condition and runs the COM object’s code regardless. But allowing COM objects to load where there are GUID mismatches leaves the system vulnerable to attackers who can exploit the GUID confusion to run unintended code.
To increase App Control's protective effectiveness on a system vulnerable to this attack technique, .NET applies an extra validation to check that the registered COM object GUID matches the system calculated one. If a mismatch is found, .NET doesn't load the COM object and a general COM load error is raised. Apps using COM objects with this condition might behave in unexpected ways and must be updated to fix issues with the app's COM object registration code.
Since this behavior only occurs when App Control policy is enforced on user mode code, you can't detect it while in audit mode. There's no logging or other events when a COM object fails to load due to the extra validation check. Repairing or reinstalling the app can resolve the issue temporarily, but an app update is needed to fix the COM registration issue and prevent future instances of the problem.
There are no policy control options to manage .NET's GUID verification check, meaning the check is always performed. If you see COM object failures after an App Control policy is deployed, contact the software developer or the Independent Software Vendor (ISV) who produces the app to request a fix for the issue.
### Signatures using elliptical curve cryptography (ECC) aren't supported
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.