mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-06-17 19:33:37 +00:00
Merge branch 'public' into patch-4
This commit is contained in:
Violet Hansen
GitHub
@ -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>
|
||||
|
||||
@ -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) and enable [Native AOT](/dotnet/core/deploying/native-aot).
|
||||
|
||||
## 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>
|
||||
|
||||
@ -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" />
|
||||
|
||||
@ -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).
|
||||
|
||||
@ -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.
|
||||
[](../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"]
|
||||
> [](../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)
|
||||
```
|
||||
[](../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).
|
||||
|
||||
@ -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.
|
||||
|
||||
Reference in New Issue
Block a user