mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-05-12 13:27:23 +00:00
Update wording in App Control for Business deployment guide
This commit is contained in:
Vinay Pamnani (from Dev Box)
parent
2ecfc7e352
commit
1c3b2da041
@ -11,7 +11,7 @@ ms.date: 01/31/2024
|
||||
|
||||
<!-- ApplicationControl-Editable-Begin -->
|
||||
<!-- Add any additional information about this policy here. Anything outside this section will get overwritten. -->
|
||||
App Control for Business policies can be managed from an MDM server, or locally by using PowerShell via the WMI Bridge through the ApplicationControl configuration service provider (CSP). The ApplicationControl CSP was added in Windows 10, version 1903. This CSP provides expanded diagnostic capabilities and support for [multiple policies](/windows/security/threat-protection/windows-defender-application-control/deploy-multiple-windows-defender-application-control-policies) (introduced in Windows 10, version 1903). It also provides support for policy deployment (introduced in Windows 10, version 1709) without reboot. Unlike the [AppLocker CSP](applocker-csp.md), the ApplicationControl CSP correctly detects the presence of no-reboot option and consequently doesn't schedule a reboot.
|
||||
App Control for Business policies can be managed from an MDM server, or locally by using PowerShell via the WMI Bridge through the ApplicationControl configuration service provider (CSP). The ApplicationControl CSP was added in Windows 10, version 1903. This CSP provides expanded diagnostic capabilities and support for [multiple policies](/windows/security/application-security/application-control/app-control-for-business/design/deploy-multiple-appcontrol-policies.md) (introduced in Windows 10, version 1903). It also provides support for policy deployment (introduced in Windows 10, version 1709) without reboot. Unlike the [AppLocker CSP](applocker-csp.md), the ApplicationControl CSP correctly detects the presence of no-reboot option and consequently doesn't schedule a reboot.
|
||||
|
||||
Existing App Control for Business policies deployed using the AppLocker CSP's CodeIntegrity node can now be deployed using the ApplicationControl CSP URI. Although App Control policy deployment using the AppLocker CSP will continue to be supported, all new feature work will be done in the ApplicationControl CSP only.
|
||||
<!-- ApplicationControl-Editable-End -->
|
||||
@ -861,7 +861,7 @@ The following table provides the result of this policy based on different values
|
||||
|
||||
## Microsoft Intune Usage Guidance
|
||||
|
||||
For customers using Intune standalone or hybrid management with Configuration Manager to deploy custom policies via the ApplicationControl CSP, refer to [Deploy App Control for Business policies by using Microsoft Intune](/windows/security/application-security/application-control/app-control-for-business/deployment/deploy-wdac-policies-using-intune).
|
||||
For customers using Intune standalone or hybrid management with Configuration Manager to deploy custom policies via the ApplicationControl CSP, refer to [Deploy App Control for Business policies by using Microsoft Intune](/windows/security/application-security/application-control/app-control-for-business/deployment/deploy-appcontrol-policies-using-intune).
|
||||
|
||||
## Generic MDM Server Usage Guidance
|
||||
|
||||
|
||||
@ -47,13 +47,13 @@
|
||||
- name: Policy creation for common App Control usage scenarios
|
||||
href: design/common-appcontrol-use-cases.md
|
||||
items:
|
||||
- name: Create a App Control policy for lightly managed devices
|
||||
- name: Create an App Control policy for lightly managed devices
|
||||
href: design/create-appcontrol-policy-for-lightly-managed-devices.md
|
||||
- name: Create a App Control policy for fully managed devices
|
||||
- name: Create an App Control policy for fully managed devices
|
||||
href: design/create-appcontrol-policy-for-fully-managed-devices.md
|
||||
- name: Create a App Control policy for fixed-workload devices
|
||||
- name: Create an App Control policy for fixed-workload devices
|
||||
href: design/create-appcontrol-policy-using-reference-computer.md
|
||||
- name: Create a App Control deny list policy
|
||||
- name: Create an App Control deny list policy
|
||||
href: design/create-appcontrol-deny-policy.md
|
||||
- name: Applications that can bypass App Control and how to block them
|
||||
href: design/applications-that-can-bypass-appcontrol.md
|
||||
@ -66,7 +66,7 @@
|
||||
href: design/appcontrol-wizard-create-base-policy.md
|
||||
- name: Create a supplemental App Control policy with the Wizard
|
||||
href: design/appcontrol-wizard-create-supplemental-policy.md
|
||||
- name: Editing a App Control policy with the Wizard
|
||||
- name: Editing an App Control policy with the Wizard
|
||||
href: design/appcontrol-wizard-editing-policy.md
|
||||
- name: Creating App Control Policy Rules from App Control Events
|
||||
href: design/appcontrol-wizard-parsing-event-logs.md
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
---
|
||||
title: Deploying App Control for Business policies
|
||||
description: Learn how to plan and implement a App Control deployment.
|
||||
description: Learn how to plan and implement an App Control deployment.
|
||||
ms.localizationpriority: medium
|
||||
ms.date: 01/23/2023
|
||||
ms.topic: overview
|
||||
|
||||
@ -12,14 +12,14 @@ ms.topic: conceptual
|
||||
|
||||
Running Application Control in audit mode lets you discover applications, binaries, and scripts that are missing from your App Control policy but should be included.
|
||||
|
||||
While a App Control policy is running in audit mode, any binary that runs but would have been denied is logged in the **Applications and Services Logs\\Microsoft\\Windows\\CodeIntegrity\\Operational** event log. Script and MSI are logged in the **Applications and Services Logs\\Microsoft\\Windows\\AppLocker\\MSI and Script** event log. These events can be used to generate a new App Control policy that can be merged with the original Base policy or deployed as a separate Supplemental policy, if allowed.
|
||||
While an App Control policy is running in audit mode, any binary that runs but would have been denied is logged in the **Applications and Services Logs\\Microsoft\\Windows\\CodeIntegrity\\Operational** event log. Script and MSI are logged in the **Applications and Services Logs\\Microsoft\\Windows\\AppLocker\\MSI and Script** event log. These events can be used to generate a new App Control policy that can be merged with the original Base policy or deployed as a separate Supplemental policy, if allowed.
|
||||
|
||||
## Overview of the process to create App Control policy to allow apps using audit events
|
||||
|
||||
> [!Note]
|
||||
> You must have already deployed a App Control audit mode policy to use this process. If you have not already done so, see [Deploying App Control for Business policies](appcontrol-deployment-guide.md).
|
||||
> You must have already deployed an App Control audit mode policy to use this process. If you have not already done so, see [Deploying App Control for Business policies](appcontrol-deployment-guide.md).
|
||||
|
||||
To familiarize yourself with creating App Control rules from audit events, follow these steps on a device with a App Control audit mode policy.
|
||||
To familiarize yourself with creating App Control rules from audit events, follow these steps on a device with an App Control audit mode policy.
|
||||
|
||||
1. Install and run an application not allowed by the App Control policy but that you want to allow.
|
||||
|
||||
@ -28,7 +28,7 @@ To familiarize yourself with creating App Control rules from audit events, follo
|
||||
**Figure 1. Exceptions to the deployed App Control policy**
|
||||
|
||||
|
||||
3. In an elevated PowerShell session, run the following commands to initialize variables used by this procedure. This procedure builds upon the **Lamna_FullyManagedClients_Audit.xml** policy introduced in [Create a App Control policy for fully managed devices](../design/create-appcontrol-policy-for-fully-managed-devices.md) and will produce a new policy called **EventsPolicy.xml**.
|
||||
3. In an elevated PowerShell session, run the following commands to initialize variables used by this procedure. This procedure builds upon the **Lamna_FullyManagedClients_Audit.xml** policy introduced in [Create an App Control policy for fully managed devices](../design/create-appcontrol-policy-for-fully-managed-devices.md) and will produce a new policy called **EventsPolicy.xml**.
|
||||
|
||||
```powershell
|
||||
$PolicyName= "Lamna_FullyManagedClients_Audit"
|
||||
|
||||
@ -20,11 +20,11 @@ Single-policy format App Control for Business policies (pre-1903 policy schema)
|
||||
> [!IMPORTANT]
|
||||
> Group Policy-based deployment of App Control for Business policies only supports single-policy format App Control policies. To use App Control on devices running Windows 10 1903 and greater, or Windows 11, we recommend using an alternative method for policy deployment.
|
||||
|
||||
You should now have a App Control policy converted into binary form. If not, follow the steps described in [Deploying App Control for Business policies](appcontrol-deployment-guide.md).
|
||||
You should now have an App Control policy converted into binary form. If not, follow the steps described in [Deploying App Control for Business policies](appcontrol-deployment-guide.md).
|
||||
|
||||
The following procedure walks you through how to deploy a App Control policy called **SiPolicy.p7b** to a test OU called *App Control Enabled PCs* by using a GPO called **Contoso GPO Test**.
|
||||
The following procedure walks you through how to deploy an App Control policy called **SiPolicy.p7b** to a test OU called *App Control Enabled PCs* by using a GPO called **Contoso GPO Test**.
|
||||
|
||||
To deploy and manage a App Control for Business policy with Group Policy:
|
||||
To deploy and manage an App Control for Business policy with Group Policy:
|
||||
|
||||
1. On a client computer on which RSAT is installed, open the GPMC by running **GPMC.MSC**
|
||||
|
||||
|
||||
@ -24,11 +24,11 @@ Configuration Manager includes native support for App Control, which allows you
|
||||
|
||||
Configuration Manager doesn't remove policies once deployed. To stop enforcement, you should switch the policy to audit mode, which will produce the same effect. If you want to disable App Control for Business altogether (including audit mode), you can deploy a script to delete the policy file from disk, and either trigger a reboot or wait for the next reboot.
|
||||
|
||||
### Create a App Control Policy in Configuration Manager
|
||||
### Create an App Control Policy in Configuration Manager
|
||||
|
||||
1. Select **Asset and Compliance** > **Endpoint Protection** > **App Control for Business** > **Create Application Control Policy**
|
||||
|
||||
|
||||
|
||||
|
||||
2. Enter the name of the policy > **Next**
|
||||
3. Enable **Enforce a restart of devices so that this policy can be enforced for all processes**
|
||||
@ -39,7 +39,7 @@ Configuration Manager doesn't remove policies once deployed. To stop enforcement
|
||||
|
||||
6. Select **Add** to begin creating rules for trusted software
|
||||
|
||||
|
||||
|
||||
|
||||
7. Select **File** or **Folder** to create a path rule > **Browse**
|
||||
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
---
|
||||
title: Deploy catalog files to support App Control for Business
|
||||
description: Catalog files simplify running unsigned applications in the presence of a App Control for Business policy.
|
||||
description: Catalog files simplify running unsigned applications in the presence of an App Control for Business policy.
|
||||
ms.localizationpriority: medium
|
||||
ms.topic: how-to
|
||||
ms.date: 11/30/2022
|
||||
@ -14,7 +14,7 @@ ms.date: 11/30/2022
|
||||
|
||||
You need to [obtain a code signing certificate for your own use](use-code-signing-for-better-control-and-protection.md#obtain-code-signing-certificates-for-your-own-use) and use it to sign the catalog file. Then, distribute the signed catalog file using your preferred content deployment mechanism.
|
||||
|
||||
Finally, add a signer rule to your App Control policy for your signing certificate. Then, any apps covered by your signed catalog files are able to run, even if the apps were previously unsigned. With this foundation, you can more easily build a App Control policy that blocks all unsigned code, because most malware is unsigned.
|
||||
Finally, add a signer rule to your App Control policy for your signing certificate. Then, any apps covered by your signed catalog files are able to run, even if the apps were previously unsigned. With this foundation, you can more easily build an App Control policy that blocks all unsigned code, because most malware is unsigned.
|
||||
|
||||
## Create catalog files using Package Inspector
|
||||
|
||||
@ -300,7 +300,7 @@ At the time of the next software inventory cycle, when the targeted clients rece
|
||||
|
||||
## Allow apps signed by your catalog signing certificate in your App Control policy
|
||||
|
||||
Now that you have your signed catalog file, you can add a signer rule to your policy that allows anything signed with that certificate. If you haven't yet created a App Control policy, see the [App Control for Business design guide](../design/appcontrol-design-guide.md).
|
||||
Now that you have your signed catalog file, you can add a signer rule to your policy that allows anything signed with that certificate. If you haven't yet created an App Control policy, see the [App Control for Business design guide](../design/appcontrol-design-guide.md).
|
||||
|
||||
On a computer where the signed catalog file has been deployed, you can use [New-CiPolicyRule](/powershell/module/configci/new-cipolicyrule) to create a signer rule from any file included in that catalog. Then use [Merge-CiPolicy](/powershell/module/configci/merge-cipolicy) to add the rule to your policy XML. Be sure to replace the path values in the following sample:
|
||||
|
||||
|
||||
@ -32,7 +32,7 @@ To make a policy effectively inactive before removing it, you can first replace
|
||||
1. Replace the policy rules with "Allow *" rules;
|
||||
2. Set option **3 Enabled:Audit Mode** to change the policy to audit mode only;
|
||||
3. Set option **11 Disabled:Script Enforcement**;
|
||||
4. Allow all COM objects. See [Allow COM object registration in a App Control policy](../design/allow-com-object-registration-in-appcontrol-policy.md#examples);
|
||||
4. Allow all COM objects. See [Allow COM object registration in an App Control policy](../design/allow-com-object-registration-in-appcontrol-policy.md#examples);
|
||||
5. If applicable, remove option **0 Enabled:UMCI** to convert the policy to kernel mode only.
|
||||
|
||||
> [!IMPORTANT]
|
||||
@ -54,7 +54,7 @@ You can use a Mobile Device Management (MDM) solution, like Microsoft Intune, to
|
||||
|
||||
<!-- Waiting for information from Intune team on specific steps...
|
||||
|
||||
The steps to use Intune's custom OMA-URI functionality to remove a App Control policy are:
|
||||
The steps to use Intune's custom OMA-URI functionality to remove an App Control policy are:
|
||||
|
||||
1. Open the Microsoft Intune portal and [create a profile with custom settings](/mem/intune/configuration/custom-settings-windows-10).
|
||||
|
||||
@ -141,7 +141,7 @@ mountvol $MountPoint /D
|
||||
|
||||
## Remove App Control policies causing boot stop failures
|
||||
|
||||
A App Control policy that blocks boot critical drivers can cause a boot stop failure (BSOD) to occur, though this can be mitigated by setting option **10 Enabled:Boot Audit On Failure** in your policies. Additionally, signed App Control policies protect the policy from administrative manipulation and malware that has gained administrative-level access to the system. For this reason, signed App Control policies are intentionally more difficult to remove than unsigned policies even for administrators. Tampering with or removing a signed App Control policy will cause a BSOD to occur.
|
||||
an App Control policy that blocks boot critical drivers can cause a boot stop failure (BSOD) to occur, though this can be mitigated by setting option **10 Enabled:Boot Audit On Failure** in your policies. Additionally, signed App Control policies protect the policy from administrative manipulation and malware that has gained administrative-level access to the system. For this reason, signed App Control policies are intentionally more difficult to remove than unsigned policies even for administrators. Tampering with or removing a signed App Control policy will cause a BSOD to occur.
|
||||
|
||||
To remove a policy that is causing boot stop failures:
|
||||
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
---
|
||||
title: Enforce App Control for Business policies
|
||||
description: Learn how to switch a App Control policy from audit to enforced mode.
|
||||
description: Learn how to switch an App Control policy from audit to enforced mode.
|
||||
ms.manager: jsuther
|
||||
ms.date: 04/22/2021
|
||||
ms.topic: how-to
|
||||
|
||||
@ -29,7 +29,7 @@ To learn how to create and manage catalog files for existing apps, see [Deploy c
|
||||
|
||||
## Signed App Control policies
|
||||
|
||||
While a App Control policy begins as an XML document, it's then converted into a binary-encoded file before deployment. This binary version of your policy can be code signed like any other application binary, offering many of the same benefits as described above for signed code. Additionally, signed policies are treated specially by App Control and help protect against tampering or removal of a policy even by an admin user.
|
||||
While an App Control policy begins as an XML document, it's then converted into a binary-encoded file before deployment. This binary version of your policy can be code signed like any other application binary, offering many of the same benefits as described above for signed code. Additionally, signed policies are treated specially by App Control and help protect against tampering or removal of a policy even by an admin user.
|
||||
|
||||
For more information on using signed policies, see [Use signed policies to protect App Control for Business against tampering](use-signed-policies-to-protect-appcontrol-against-tampering.md)
|
||||
|
||||
|
||||
@ -37,7 +37,7 @@ Before you attempt to deploy a signed policy, you should first deploy an unsigne
|
||||
```
|
||||
|
||||
> [!NOTE]
|
||||
> This example uses an enforced version of the App Control policy that you created in [Create a App Control for Business policy from a reference computer](../design/create-appcontrol-policy-using-reference-computer.md) article. If you sign another policy, be sure to update the **$PolicyPath** and **$PolicyName** variables with the correct information.
|
||||
> This example uses an enforced version of the App Control policy that you created in [Create an App Control for Business policy from a reference computer](../design/create-appcontrol-policy-using-reference-computer.md) article. If you sign another policy, be sure to update the **$PolicyPath** and **$PolicyName** variables with the correct information.
|
||||
|
||||
2. Navigate to your desktop as the working directory:
|
||||
|
||||
|
||||
@ -1,12 +1,12 @@
|
||||
---
|
||||
title: Allow COM object registration in a App Control policy
|
||||
description: You can allow COM object registration in a App Control for Business policy.
|
||||
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: 04/05/2023
|
||||
ms.topic: how-to
|
||||
---
|
||||
|
||||
# Allow COM object registration in a App Control for Business policy
|
||||
# Allow COM object registration in an App Control for Business policy
|
||||
|
||||
[!INCLUDE [Feature availability note](../includes/feature-availability-note.md)]
|
||||
|
||||
|
||||
@ -8,7 +8,7 @@ ms.topic: conceptual
|
||||
|
||||
# App Control for Business and .NET
|
||||
|
||||
.NET apps (as written in a high-level language like C#) are compiled to an Intermediate Language (IL). IL is a compact code format that can be supported on any operating system or architecture. Most .NET apps use APIs that are supported in multiple environments, requiring only the .NET runtime to run. IL needs to be compiled to native code in order to execute on a CPU, for example Arm64 or x64. When .NET compiles IL to native image (NI) on a device with a 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.
|
||||
.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.
|
||||
|
||||
|
||||
@ -117,4 +117,4 @@ The policy signing rules list table on the left of the page documents the allow
|
||||
|
||||
## Up next
|
||||
|
||||
- [Editing a App Control for Business policy using the Wizard](appcontrol-wizard-editing-policy.md)
|
||||
- [Editing an App Control for Business policy using the Wizard](appcontrol-wizard-editing-policy.md)
|
||||
|
||||
@ -90,4 +90,4 @@ The table on the left of the page documents the allow and deny rules in the temp
|
||||
|
||||
## Up next
|
||||
|
||||
- [Editing a App Control for Business policy using the Wizard](appcontrol-wizard-editing-policy.md)
|
||||
- [Editing an App Control for Business policy using the Wizard](appcontrol-wizard-editing-policy.md)
|
||||
|
||||
@ -21,7 +21,7 @@ As of [version 2.2.0.0](https://webapp-wdac-wizard.azurewebsites.net/archives.ht
|
||||
To create rules from the App Control event logs on the system:
|
||||
|
||||
1. Select **Policy Editor** from the main page.
|
||||
2. Select **Convert Event Log to a App Control Policy**.
|
||||
2. Select **Convert Event Log to an App Control Policy**.
|
||||
3. Select the **Parse Event Logs** button under the **Parse Event Logs from the System Event Viewer to Policy** header.
|
||||
|
||||
The Wizard parses the relevant audit and block events from the CodeIntegrity (App Control) Operational and AppLocker MSI and Script logs. You see a notification when the Wizard successfully finishes reading the events.
|
||||
@ -37,7 +37,7 @@ To create rules from the App Control event logs on the system:
|
||||
To create rules from the App Control `.EVTX` event logs files on the system:
|
||||
|
||||
1. Select **Policy Editor** from the main page.
|
||||
2. Select **Convert Event Log to a App Control Policy**.
|
||||
2. Select **Convert Event Log to an App Control Policy**.
|
||||
3. Select the **Parse Log File(s)** button under the **Parse Event Log evtx Files to Policy** header.
|
||||
4. Select the App Control CodeIntegrity Event log EVTX file(s) from the disk to parse.
|
||||
|
||||
@ -84,7 +84,7 @@ To create rules from the App Control events in [MDE Advanced Hunting](../operati
|
||||
> [](../images/appcontrol-wizard-event-log-mde-ah-export-expanded.png)
|
||||
|
||||
3. Select **Policy Editor** from the main page.
|
||||
4. Select **Convert Event Log to a App Control Policy**.
|
||||
4. Select **Convert Event Log to an App Control Policy**.
|
||||
5. Select the **Parse Log File(s)** button under the "Parse MDE Advanced Hunting Events to Policy" header.
|
||||
6. Select the App Control MDE Advanced Hunting export CSV files from the disk to parse.
|
||||
|
||||
|
||||
@ -33,4 +33,4 @@ Recently, Lamna experienced a ransomware event that required an expensive recove
|
||||
|
||||
## Up next
|
||||
|
||||
- [Create a App Control for Business policy for lightly managed devices](create-appcontrol-policy-for-lightly-managed-devices.md)
|
||||
- [Create an App Control for Business policy for lightly managed devices](create-appcontrol-policy-for-lightly-managed-devices.md)
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Allow apps deployed with a App Control managed installer
|
||||
title: Allow apps deployed with an App Control managed installer
|
||||
description: Explains how to configure a custom Managed Installer.
|
||||
ms.localizationpriority: medium
|
||||
ms.date: 02/02/2023
|
||||
@ -193,7 +193,7 @@ The AppLocker policy creation UI in GPO Editor and the AppLocker PowerShell cmdl
|
||||
In order to enable trust for the binaries laid down by managed installers, the "Enabled: Managed Installer" option must be specified in your App Control policy.
|
||||
This setting can be defined by using the [Set-RuleOption cmdlet](/powershell/module/configci/set-ruleoption) with Option 13.
|
||||
|
||||
Below are steps to create a App Control policy that allows Windows to boot and enables the managed installer option.
|
||||
Below are steps to create an App Control policy that allows Windows to boot and enables the managed installer option.
|
||||
|
||||
1. Copy the DefaultWindows_Audit policy into your working folder from "C:\Windows\schemas\CodeIntegrity\ExamplePolicies\DefaultWindows_Audit.xml"
|
||||
|
||||
|
||||
@ -1,16 +1,16 @@
|
||||
---
|
||||
title: Create a App Control policy for fully managed devices
|
||||
title: Create an App Control policy for fully managed devices
|
||||
description: App Control for Business restricts which applications users are allowed to run and the code that runs in system core.
|
||||
ms.topic: conceptual
|
||||
ms.localizationpriority: medium
|
||||
ms.date: 11/07/2022
|
||||
---
|
||||
|
||||
# Create a App Control policy for fully managed devices
|
||||
# Create an App Control policy for fully managed devices
|
||||
|
||||
[!INCLUDE [Feature availability note](../includes/feature-availability-note.md)]
|
||||
|
||||
This section outlines the process to create a App Control for Business policy for **fully managed devices** within an organization. The key difference between this scenario and [lightly managed devices](create-appcontrol-policy-for-lightly-managed-devices.md) is that all software deployed to a fully managed device is managed by IT and users of the device can't install arbitrary apps. Ideally, all apps are deployed using a software distribution solution, such as Microsoft Intune. Additionally, users on fully managed devices should ideally run as standard user and only authorized IT pros have administrative access.
|
||||
This section outlines the process to create an App Control for Business policy for **fully managed devices** within an organization. The key difference between this scenario and [lightly managed devices](create-appcontrol-policy-for-lightly-managed-devices.md) is that all software deployed to a fully managed device is managed by IT and users of the device can't install arbitrary apps. Ideally, all apps are deployed using a software distribution solution, such as Microsoft Intune. Additionally, users on fully managed devices should ideally run as standard user and only authorized IT pros have administrative access.
|
||||
|
||||
> [!NOTE]
|
||||
> Some of the 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.
|
||||
@ -144,5 +144,5 @@ Alice has defined a policy for Lamna's fully managed devices that makes some tra
|
||||
|
||||
## Up next
|
||||
|
||||
- [Create a App Control for Business policy for fixed-workload devices using a reference computer](create-appcontrol-policy-using-reference-computer.md)
|
||||
- [Create an App Control for Business policy for fixed-workload devices using a reference computer](create-appcontrol-policy-using-reference-computer.md)
|
||||
- [Prepare to deploy App Control for Business policies](../deployment/appcontrol-deployment-guide.md)
|
||||
|
||||
@ -1,16 +1,16 @@
|
||||
---
|
||||
title: Create a App Control policy for lightly managed devices
|
||||
title: Create an App Control policy for lightly managed devices
|
||||
description: App Control for Business restricts which applications users are allowed to run and the code that runs in the system core.
|
||||
ms.topic: conceptual
|
||||
ms.localizationpriority: medium
|
||||
ms.date: 11/07/2022
|
||||
---
|
||||
|
||||
# Create a App Control policy for lightly managed devices
|
||||
# Create an App Control policy for lightly managed devices
|
||||
|
||||
[!INCLUDE [Feature availability note](../includes/feature-availability-note.md)]
|
||||
|
||||
This section outlines the process to create a App Control for Business policy for **lightly managed devices** within an organization. Typically, organizations that are new to application control will be most successful if they start with a permissive policy like the one described in this article. Organizations can choose to harden the policy over time to achieve a stronger overall security posture on their App Control-managed devices as described in later articles.
|
||||
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 application control will be most successful if they start with a permissive policy like the one described in this article. Organizations can choose to harden the policy over time to achieve a stronger overall security posture on their App Control-managed devices as described in later articles.
|
||||
|
||||
> [!NOTE]
|
||||
> Some of the 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.
|
||||
@ -207,5 +207,5 @@ In order to minimize user productivity impact, Alice has defined a policy that m
|
||||
|
||||
## Up next
|
||||
|
||||
- [Create a App Control for Business policy for fully managed devices](create-appcontrol-policy-for-fully-managed-devices.md)
|
||||
- [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)
|
||||
|
||||
@ -1,16 +1,16 @@
|
||||
---
|
||||
title: Create a App Control policy using a reference computer
|
||||
description: To create a App Control for Business policy that allows all code installed on a reference computer within your organization, follow this guide.
|
||||
title: Create an App Control policy using a reference computer
|
||||
description: To create an App Control for Business policy that allows all code installed on a reference computer within your organization, follow this guide.
|
||||
ms.localizationpriority: medium
|
||||
ms.date: 08/08/2022
|
||||
ms.topic: how-to
|
||||
---
|
||||
|
||||
# Create a App Control policy using a reference computer
|
||||
# Create an App Control policy using a reference computer
|
||||
|
||||
[!INCLUDE [Feature availability note](../includes/feature-availability-note.md)]
|
||||
|
||||
This section outlines the process to create a App Control for Business policy **using a reference computer** that is already configured with the software you want to allow. You can use this approach for fixed-workload devices that are dedicated to a specific functional purpose and share common configuration attributes with other devices servicing the same functional role. Examples of fixed-workload devices may include Active Directory Domain Controllers, Secure Admin Workstations, pharmaceutical drug-mixing equipment, manufacturing devices, cash registers, ATMs, etc. This approach can also be used to turn on App Control on systems "in the wild" and you want to minimize the potential impact on users' productivity.
|
||||
This section outlines the process to create an App Control for Business policy **using a reference computer** that is already configured with the software you want to allow. You can use this approach for fixed-workload devices that are dedicated to a specific functional purpose and share common configuration attributes with other devices servicing the same functional role. Examples of fixed-workload devices may include Active Directory Domain Controllers, Secure Admin Workstations, pharmaceutical drug-mixing equipment, manufacturing devices, cash registers, ATMs, etc. This approach can also be used to turn on App Control on systems "in the wild" and you want to minimize the potential impact on users' productivity.
|
||||
|
||||
> [!NOTE]
|
||||
> Some of the 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.
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
---
|
||||
title: Example App Control for Business base policies
|
||||
description: When creating a App Control for Business policy for an organization, start from one of the many available example base policies.
|
||||
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: 03/31/2023
|
||||
|
||||
@ -66,7 +66,7 @@ Then use the [Merge-CIPolicy](/powershell/module/configci/merge-cipolicy) PowerS
|
||||
|
||||
##### Create PFN rule from an installed MSIX app
|
||||
|
||||
Use the following steps to create a App Control PFN rule for an app that is installed on the system:
|
||||
Use the following steps to create an App Control PFN rule for an app that is installed on the system:
|
||||
|
||||
1. From the **Policy Signing Rules** page of the [App Control Wizard](https://aka.ms/wdacwizard), select **Add Custom Rule**.
|
||||
2. Check **Usermode Rule** as the Rule Scope, if not checked.
|
||||
|
||||
@ -71,7 +71,7 @@ To check that the policy was successfully applied on your computer:
|
||||
## Vulnerable driver blocklist XML
|
||||
|
||||
> [!IMPORTANT]
|
||||
> The following policy contains **Allow All** rules. If your version of Windows supports App Control multiple policies, we recommend deploying this policy alongside any existing App Control policies. If you do plan to merge this policy with another policy, you may need to remove the **Allow All** rules before merging it if the other policy applies an explicit allow list. For more information, see [Create a App Control Deny Policy](create-appcontrol-deny-policy.md#guidance-on-creating-app-control-deny-policies).
|
||||
> The following policy contains **Allow All** rules. If your version of Windows supports App Control multiple policies, we recommend deploying this policy alongside any existing App Control policies. If you do plan to merge this policy with another policy, you may need to remove the **Allow All** rules before merging it if the other policy applies an explicit allow list. For more information, see [Create an App Control Deny Policy](create-appcontrol-deny-policy.md#guidance-on-creating-app-control-deny-policies).
|
||||
|
||||
> [!NOTE]
|
||||
> To use this policy with Windows Server 2016, you must convert the policy XML on a device running a newer operating system.
|
||||
|
||||
@ -25,7 +25,7 @@ App Control shares the *AppLocker - MSI and Script* event log for all script enf
|
||||
> [!NOTE]
|
||||
> When a script runs that is not allowed by policy, App Control raises an event indicating that the script was "blocked." However, the actual script enforcement behavior is handled by the script host and may not actually completely block the file from running.
|
||||
>
|
||||
> Also be aware that some script hosts may change how they behave even if a App Control policy is in audit mode only. You should review the script host specific information in this article and test thoroughly within your environment to ensure the scripts you need to run are working properly.
|
||||
> Also be aware that some script hosts may change how they behave even if an App Control policy is in audit mode only. You should review the script host specific information in this article and test thoroughly within your environment to ensure the scripts you need to run are working properly.
|
||||
|
||||
## Enlightened script hosts that are part of Windows
|
||||
|
||||
@ -57,6 +57,6 @@ App Control additionally enforces a restricted allowlist for COM objects that yo
|
||||
|
||||
## Scripts that aren't directly controlled by App Control
|
||||
|
||||
App Control doesn't directly control code run via the Windows Command Processor (cmd.exe), including .bat/.cmd script files. However, anything that such a batch script tries to run is subject to App Control control. If you don't need to run cmd.exe, it's recommended to block it outright or allow it only by exception based on the calling process. See [Use a App Control for Business policy to control specific plug-ins, add-ins, and modules](use-appcontrol-policy-to-control-specific-plug-ins-add-ins-and-modules.md).
|
||||
App Control doesn't directly control code run via the Windows Command Processor (cmd.exe), including .bat/.cmd script files. However, anything that such a batch script tries to run is subject to App Control control. If you don't need to run cmd.exe, it's recommended to block it outright or allow it only by exception based on the calling process. See [Use an App Control for Business policy to control specific plug-ins, add-ins, and modules](use-appcontrol-policy-to-control-specific-plug-ins-add-ins-and-modules.md).
|
||||
|
||||
App Control doesn't control scripts run through an unenlightened script host, such as many 3rd-party Java or Python engines. If your App Control policy allows an unenlightened script host to run, then you implicitly allow all scripts run through that host. For non-Microsoft script hosts, you should check with the software vendor whether their script hosts are enlightened to App Control policy.
|
||||
|
||||
@ -16,7 +16,7 @@ App Control for Business can control what runs on your Windows devices by settin
|
||||
|
||||
To modify the policy rule options of an existing App Control policy XML, use the [App Control Policy Wizard](appcontrol-wizard.md) or the [Set-RuleOption](/powershell/module/configci/set-ruleoption) PowerShell cmdlet.
|
||||
|
||||
You can set several rule options within a App Control policy. Table 1 describes each rule option, and whether supplemental policies can set them. Some rule options are reserved for future work or not supported.
|
||||
You can set several rule options within an App Control policy. Table 1 describes each rule option, and whether supplemental policies can set them. Some rule options are reserved for future work or not supported.
|
||||
|
||||
> [!NOTE]
|
||||
> We recommend that you use **Enabled:Audit Mode** initially because it allows you to test new App Control policies before you enforce them. With audit mode, applications run normally but App Control logs events whenever a file runs that isn't allowed by the policy. To allow these files, you can capture the policy information from the event log, and then merge that information into the existing policy. When the **Enabled:Audit Mode** is deleted, the policy runs in enforced mode.
|
||||
@ -30,7 +30,7 @@ You can set several rule options within a App Control policy. Table 1 describes
|
||||
| **0 Enabled:UMCI** | App Control policies restrict both kernel-mode and user-mode binaries. By default, only kernel-mode binaries are restricted. Enabling this rule option validates user mode executables and scripts. | No |
|
||||
| **1 Enabled:Boot Menu Protection** | This option isn't currently supported. | No |
|
||||
| **2 Required:WHQL** | By default, kernel drivers that aren't Windows Hardware Quality Labs (WHQL) signed are allowed to run. Enabling this rule requires that every driver is WHQL signed and removes legacy driver support. Kernel drivers built for Windows 10 should be WHQL certified. | No |
|
||||
| **3 Enabled:Audit Mode (Default)** | Instructs App Control to log information about applications, binaries, and scripts that would have been blocked, if the policy was enforced. You can use this option to identify the potential impact of your App Control policy, and use the audit events to refine the policy before enforcement. To enforce a App Control policy, delete this option. | No |
|
||||
| **3 Enabled:Audit Mode (Default)** | Instructs App Control to log information about applications, binaries, and scripts that would have been blocked, if the policy was enforced. You can use this option to identify the potential impact of your App Control policy, and use the audit events to refine the policy before enforcement. To enforce an App Control policy, delete this option. | No |
|
||||
| **4 Disabled:Flight Signing** | If enabled, binaries from Windows Insider builds aren't trusted. This option is useful for organizations that only want to run released binaries, not prerelease Windows builds. | No |
|
||||
| **5 Enabled:Inherit Default Policy** | This option is reserved for future use and currently has no effect. | Yes |
|
||||
| **6 Enabled:Unsigned System Integrity Policy (Default)** | Allows the policy to remain unsigned. When this option is removed, the policy must be signed and any supplemental policies must also be signed. The certificates that are trusted for future policy updates must be identified in the UpdatePolicySigners section. Certificates that are trusted for supplemental policies must be identified in the SupplementalPolicySigners section. | Yes |
|
||||
@ -40,7 +40,7 @@ You can set several rule options within a App Control policy. Table 1 describes
|
||||
| **10 Enabled:Boot Audit on Failure** | Used when the App Control policy is in enforcement mode. When a boot-critical driver fails during startup, the App Control policy is placed in audit mode so that Windows loads. Administrators can validate the reason for the failure in the CodeIntegrity event log. | No |
|
||||
| **11 Disabled:Script Enforcement** | This option disables script enforcement options, covering PowerShell, Windows Based Script Host (wscript.exe), Windows Console Based Script Host (cscript.exe), HTA files run in Microsoft HTML Application Host (mshta.exe), and MSXML. Some script hosts may behave differently even when your policy is in audit mode. For more information on script enforcement, see [Script enforcement with App Control](script-enforcement.md). <br/> NOTE: This option isn't supported on Windows Server 2016 or Windows 10 1607 LTSB and shouldn't be used on those operating systems. | No |
|
||||
| **12 Required:Enforce Store Applications** | If this rule option is enabled, App Control policies also apply to Universal Windows applications. | No |
|
||||
| **13 Enabled:Managed Installer** | Use this option to automatically allow applications installed by a managed installer. For more information, see [Authorize apps deployed with a App Control managed installer](configure-authorized-apps-deployed-with-a-managed-installer.md) | Yes |
|
||||
| **13 Enabled:Managed Installer** | Use this option to automatically allow applications installed by a managed installer. For more information, see [Authorize apps deployed with an App Control managed installer](configure-authorized-apps-deployed-with-a-managed-installer.md) | Yes |
|
||||
| **14 Enabled:Intelligent Security Graph Authorization** | Use this option to automatically allow applications with "known good" reputation as defined by Microsoft's Intelligent Security Graph (ISG). | Yes |
|
||||
| **15 Enabled:Invalidate EAs on Reboot** | When the Intelligent Security Graph option (14) is used, App Control sets an extended file attribute that indicates that the file was authorized to run. This option causes App Control to periodically revalidate the reputation for files previously authorized by the ISG.| No |
|
||||
| **16 Enabled:Update Policy No Reboot** | Use this option to allow future App Control policy updates to apply without requiring a system reboot.<br/> NOTE: This option is only supported on Windows 10, version 1709 and later, or Windows Server 2019 and later.| No |
|
||||
|
||||
@ -10,7 +10,7 @@ ms.topic: conceptual
|
||||
|
||||
App Control for Business policies expose a Settings section where policy authors can define arbitrary secure settings. Secure Settings provide local admin tamper-free settings for secure boot enabled systems, with policy signing enabled. Settings consist of a Provider, Key, ValueName, and a setting value. Setting values can be of type boolean, ulong, binary, and string. Applications can query for policy settings using WldpQuerySecurityPolicy.
|
||||
|
||||
An example settings section of a App Control for Business policy:
|
||||
An example settings section of an App Control for Business policy:
|
||||
|
||||
```xml
|
||||
<Settings>
|
||||
@ -24,11 +24,11 @@ An example settings section of a App Control for Business policy:
|
||||
|
||||
## Example Scenario
|
||||
|
||||
An application that may want to restrict its capabilities, when used on a system with an active App Control for Business policy. Application authors can define a App Control policy, setting their application queries, in order to disable certain features. For example, if Contoso's Foo Application wants to disable a risky feature, such as macro execution, they can define a App Control policy setting, and query for it at runtime. Contoso can then instruct IT administrators to configure the setting in their App Control policy, if they don't want Foo Application to execute macros on a system with a App Control policy.
|
||||
An application that may want to restrict its capabilities, when used on a system with an active App Control for Business policy. Application authors can define an App Control policy, setting their application queries, in order to disable certain features. For example, if Contoso's Foo Application wants to disable a risky feature, such as macro execution, they can define an App Control policy setting, and query for it at runtime. Contoso can then instruct IT administrators to configure the setting in their App Control policy, if they don't want Foo Application to execute macros on a system with an App Control policy.
|
||||
|
||||
## WldpQuerySecurityPolicy
|
||||
|
||||
API that queries the secure settings of a App Control for Business policy.
|
||||
API that queries the secure settings of an App Control for Business policy.
|
||||
|
||||
### Syntax
|
||||
|
||||
|
||||
@ -1,12 +1,12 @@
|
||||
---
|
||||
title: Use a App Control for Business policy to control specific plug-ins, add-ins, and modules
|
||||
title: Use an App Control for Business policy to control specific plug-ins, add-ins, and modules
|
||||
description: App Control policies can be used not only to control applications, but also to control whether specific plug-ins, add-ins, and modules can run from specific apps.
|
||||
ms.localizationpriority: medium
|
||||
ms.date: 11/02/2022
|
||||
ms.topic: how-to
|
||||
---
|
||||
|
||||
# Use a App Control for Business policy to control specific plug-ins, add-ins, and modules
|
||||
# Use an App Control for Business policy to control specific plug-ins, add-ins, and modules
|
||||
|
||||
[!INCLUDE [Feature availability note](../includes/feature-availability-note.md)]
|
||||
|
||||
@ -17,14 +17,14 @@ You can use App Control for Business policies to control applications and also t
|
||||
| You can work from a list of plug-ins, add-ins, or modules that you want only a specific application to be able to run. Other applications would be blocked from running them. | Use `New-CIPolicyRule` with the `-AppID` option. |
|
||||
| In addition, you can work from a list of plug-ins, add-ins, or modules that you want to block in a specific application. Other applications would be allowed to run them. | Use `New-CIPolicyRule` with the `-AppID` and `-Deny` options. |
|
||||
|
||||
For example, to add rules to a App Control policy called "Lamna_FullyManagedClients_Audit.xml" that allow **addin1.dll** and **addin2.dll** to be run by **ERP1.exe**, Lamna's enterprise resource planning (ERP) application, run the following commands. In the second command, **+=** is used to add a second rule to the **$rule** variable:
|
||||
For example, to add rules to an App Control policy called "Lamna_FullyManagedClients_Audit.xml" that allow **addin1.dll** and **addin2.dll** to be run by **ERP1.exe**, Lamna's enterprise resource planning (ERP) application, run the following commands. In the second command, **+=** is used to add a second rule to the **$rule** variable:
|
||||
|
||||
```powershell
|
||||
$rule = New-CIPolicyRule -DriverFilePath '.\temp\addin1.dll' -Level FileName -AppID '.\ERP1.exe'
|
||||
$rule += New-CIPolicyRule -DriverFilePath '.\temp\addin2.dll' -Level FileName -AppID '.\ERP1.exe'
|
||||
```
|
||||
|
||||
As another example, to create a App Control for Business policy that blocks **addin3.dll** from running in Microsoft Word, run the following command. You must include the `-Deny` option to block the specified add-ins in the specified application. Once you have all the rules you want, you can merge them into an existing App Control policy using the Merge-CIPolicy cmdlet as shown here:
|
||||
As another example, to create an App Control for Business policy that blocks **addin3.dll** from running in Microsoft Word, run the following command. You must include the `-Deny` option to block the specified add-ins in the specified application. Once you have all the rules you want, you can merge them into an existing App Control policy using the Merge-CIPolicy cmdlet as shown here:
|
||||
|
||||
```powershell
|
||||
$rule += New-CIPolicyRule -DriverFilePath '.\temp\addin3.dll' -Level FileName -Deny -AppID '.\winword.exe'
|
||||
|
||||
@ -86,7 +86,7 @@ Also, since the ISG option passes along reputation from app installers to the bi
|
||||
|
||||
## Known limitations with using the ISG
|
||||
|
||||
Since the ISG only allows binaries that are "known good", there are cases where the ISG may be unable to predict whether legitimate software is safe to run. If that happens, the software will be blocked by App Control. In this case, you need to allow the software with a rule in your App Control policy, deploy a catalog signed by a certificate trusted in the App Control policy, or install the software from a App Control managed installer. Installers or applications that dynamically create binaries at runtime, and self-updating applications, may exhibit this symptom.
|
||||
Since the ISG only allows binaries that are "known good", there are cases where the ISG may be unable to predict whether legitimate software is safe to run. If that happens, the software will be blocked by App Control. In this case, you need to allow the software with a rule in your App Control policy, deploy a catalog signed by a certificate trusted in the App Control policy, or install the software from an App Control managed installer. Installers or applications that dynamically create binaries at runtime, and self-updating applications, may exhibit this symptom.
|
||||
|
||||
Packaged apps aren't supported with the ISG and will need to be separately authorized in your App Control policy. Since packaged apps have a strong app identity and must be signed, it's straightforward to [authorize packaged apps](manage-packaged-apps-with-appcontrol.md) with your App Control policy.
|
||||
|
||||
|
||||
@ -41,13 +41,13 @@ landingContent:
|
||||
url: design/deploy-multiple-appcontrol-policies.md
|
||||
- linkListType: how-to-guide
|
||||
links:
|
||||
- text: Create a App Control policy for a lightly managed device
|
||||
- text: Create an App Control policy for a lightly managed device
|
||||
url: design/create-appcontrol-policy-for-lightly-managed-devices.md
|
||||
- text: Create a App Control policy for a fully managed device
|
||||
- text: Create an App Control policy for a fully managed device
|
||||
url: design/create-appcontrol-policy-for-fully-managed-devices.md
|
||||
- text: Create a App Control policy for a fixed-workload
|
||||
- text: Create an App Control policy for a fixed-workload
|
||||
url: design/create-appcontrol-policy-using-reference-computer.md
|
||||
- text: Create a App Control blocklist policy
|
||||
- text: Create an App Control blocklist policy
|
||||
url: design/create-appcontrol-deny-policy.md
|
||||
- text: Deploying catalog files for App Control management
|
||||
url: deployment/deploy-catalog-files-to-support-appcontrol.md
|
||||
|
||||
@ -123,7 +123,7 @@ Here's an example of detailed EventData from a typical App Control enforcement m
|
||||
|
||||
| Element name | Description |
|
||||
| ----- | ----- |
|
||||
| System - Correlation - \[ActivityID\] | **Not shown in screenshot** <br> Use the correlation ActivityID to match a App Control block event with one or more 3089 signature events. |
|
||||
| System - Correlation - \[ActivityID\] | **Not shown in screenshot** <br> Use the correlation ActivityID to match an App Control block event with one or more 3089 signature events. |
|
||||
| File Name | The file's path and name on disk that was blocked from running. Since the name on disk is mutable, this value **isn't** the one used when creating App Control file rules with `-Level FileName`. Instead, see the OriginalFileName element later in this table. |
|
||||
| Process Name | The path and name of the file that attempted to run the blocked file. Also called the parent process. |
|
||||
| Requested Signing Level | The Windows signing authorization level the code needed to pass in order to run. See [Requested and validated signing level](event-tag-explanations.md#requested-and-validated-signing-level). |
|
||||
@ -151,7 +151,7 @@ Here's an example of detailed EventData from a typical App Control enforcement m
|
||||
|
||||
| Element name | Description |
|
||||
| ----- | ----- |
|
||||
| System - Correlation - \[ActivityID\] | Use the correlation ActivityID to match a App Control signature event with its block event. |
|
||||
| System - Correlation - \[ActivityID\] | Use the correlation ActivityID to match an App Control signature event with its block event. |
|
||||
| TotalSignatureCount | The total number of signatures detected for the blocked file. |
|
||||
| Signature | The index count, starting at 0, of the current signature shown in this 3089 event. If the file had multiple signatures, you'll find other 3089 events for the other signatures. |
|
||||
| Hash | The hash value that App Control used to match the file. This value should match one of the four hashes shown on the 3077 or 3076 block event. If no signatures were found for the file (TotalSignatureCount = 0), then only the hash value is shown. |
|
||||
|
||||
@ -69,7 +69,7 @@ CiTool makes App Control for Business policy management easier for IT admins. Yo
|
||||
|
||||
## Examples
|
||||
|
||||
### Deploy a App Control policy
|
||||
### Deploy an App Control policy
|
||||
|
||||
```powershell
|
||||
CiTool --update-policy "\Windows\Temp\{BF61FE40-8929-4FDF-9EC2-F7A767717F0B}.cip"
|
||||
|
||||
@ -45,7 +45,7 @@ These events are found in the **AppLocker - MSI and Script** event log.
|
||||
|--------|-----------|
|
||||
| 8028 | This event indicates that a script host, such as PowerShell, queried Application Control about a file the script host was about to run. Since the policy was in audit mode, the script or MSI file should have run, but wouldn't have passed the App Control policy if it was enforced. Some script hosts may have additional information in their logs. Note: Most third-party script hosts don't integrate with Application Control. Consider the risks from unverified scripts when choosing which script hosts you allow to run. |
|
||||
| 8029 | This event is the enforcement mode equivalent of event 8028. Note: While this event says that a script was blocked, the script hosts control the actual script enforcement behavior. The script host may allow the file to run with restrictions and not block the file outright. For example, PowerShell runs script not allowed by your App Control policy in [Constrained Language Mode](/powershell/module/microsoft.powershell.core/about/about_language_modes). |
|
||||
| 8036| COM object was blocked. To learn more about COM object authorization, see [Allow COM object registration in a App Control for Business policy](../design/allow-com-object-registration-in-appcontrol-policy.md). |
|
||||
| 8036| COM object was blocked. To learn more about COM object authorization, see [Allow COM object registration in an App Control for Business policy](../design/allow-com-object-registration-in-appcontrol-policy.md). |
|
||||
| 8037 | This event indicates that a script host checked whether to allow a script to run, and the file passed the App Control policy. |
|
||||
| 8038 | Signing information event correlated with either an 8028 or 8029 event. One 8038 event is generated for each signature of a script file. Contains the total number of signatures on a script file and an index as to which signature it is. Unsigned script files generate a single 8038 event with TotalSignatureCount 0. These events are correlated with 8028 and 8029 events and can be matched using the `Correlation ActivityID` found in the **System** portion of the event. |
|
||||
| 8039 | This event indicates that a packaged app (MSIX/AppX) was allowed to install or run because the App Control policy is in audit mode. But, it would have been blocked if the policy was enforced. |
|
||||
@ -72,7 +72,7 @@ These events are found in the **CodeIntegrity - Operational** event log.
|
||||
> [!NOTE]
|
||||
> When Managed Installer is enabled, customers using LogAnalytics should be aware that Managed Installer may fire many 3091 events. Customers may need to filter out these events to avoid high LogAnalytics costs.
|
||||
|
||||
The following events provide helpful diagnostic information when a App Control policy includes the ISG or MI option. These events can help you debug why something was allowed/denied based on managed installer or ISG. Events 3090, 3091, and 3092 don't necessarily indicate a problem but should be reviewed in context with other events like 3076 or 3077.
|
||||
The following events provide helpful diagnostic information when an App Control policy includes the ISG or MI option. These events can help you debug why something was allowed/denied based on managed installer or ISG. Events 3090, 3091, and 3092 don't necessarily indicate a problem but should be reviewed in context with other events like 3076 or 3077.
|
||||
|
||||
Unless otherwise noted, these events are found in either the **CodeIntegrity - Operational** event log or the **CodeIntegrity - Verbose** event log depending on your version of Windows.
|
||||
|
||||
|
||||
@ -8,7 +8,7 @@ ms.topic: troubleshooting
|
||||
|
||||
# Querying Application Control events centrally using Advanced hunting
|
||||
|
||||
A App Control for Business policy logs events locally in Windows Event Viewer in either enforced or audit mode.
|
||||
an App Control for Business policy logs events locally in Windows Event Viewer in either enforced or audit mode.
|
||||
While Event Viewer helps to see the impact on a single system, IT Pros want to gauge it across many systems.
|
||||
|
||||
In November 2018, we added functionality in Microsoft Defender for Endpoint that makes it easy to view App Control events centrally from all connected systems.
|
||||
|
||||
@ -50,7 +50,7 @@ In either of these scenarios, once the rules are added, they must be deleted to
|
||||
|
||||
Windows Firewall supports the use of App Control for Business Application ID (AppID) tags in firewall rules. With this capability, Windows Firewall rules can be scoped to an application or a group of applications by referencing process tags, without using absolute path or sacrificing security. There are two steps for this configuration:
|
||||
|
||||
1. Deploy *App Control AppId tagging policies*: a App Control for Business policy must be deployed, which specifies individual applications or groups of applications to apply a *PolicyAppId tag* to the process token(s). Then, the admin can define firewall rules that are scoped to all processes tagged with the matching *PolicyAppId*. For more information, see the [App Control AppId tagging guide](../../../application-security/application-control/app-control-for-business/AppIdTagging/appcontrol-appid-tagging-guide.md) to create, deploy, and test an AppID policy to tag applications.
|
||||
1. Deploy *App Control AppId tagging policies*: an App Control for Business policy must be deployed, which specifies individual applications or groups of applications to apply a *PolicyAppId tag* to the process token(s). Then, the admin can define firewall rules that are scoped to all processes tagged with the matching *PolicyAppId*. For more information, see the [App Control AppId tagging guide](../../../application-security/application-control/app-control-for-business/AppIdTagging/appcontrol-appid-tagging-guide.md) to create, deploy, and test an AppID policy to tag applications.
|
||||
1. Configure firewall rules using *PolicyAppId tags* using one of the two methods:
|
||||
- Using the [PolicyAppId node of the Firewall CSP](/windows/client-management/mdm/firewall-csp#mdmstorefirewallrulesfirewallrulenamepolicyappid) with an MDM solution like Microsoft Intune. If you use Microsoft Intune, you can deploy the rules from Microsoft Intune Admin center, under the path **Endpoint security** > **Firewall** > **Create policy** > **Windows 10, Windows 11, and Windows Server** > **Windows Firewall Rules**. When creating the rules, provide the *AppId tag* in the **Policy App ID** setting
|
||||
- Create local firewall rules with PowerShell: use the [`New-NetFirewallRule`](/powershell/module/netsecurity/new-netfirewallrule) cmdlet and specify the `-PolicyAppId` parameter. You can specify one tag at a time while creating firewall rules. Multiple User Ids are supported
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user