deepblue/windows-itpro-docs
1
0
Fork 0
mirror of https://github.com/MicrosoftDocs/windows-itpro-docs.git synced 2025-06-19 20:33:42 +00:00
Code Issues Actions 3 Packages Projects Releases Wiki Activity

Update wording in App Control for Business deployment guide

Browse Source
This commit is contained in:
Vinay Pamnani (from Dev Box)
2024-09-11 14:00:18 -06:00
parent 2ecfc7e352
commit 1c3b2da041
35 changed files with 78 additions and 78 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@ -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)]

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

@ -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.

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

@ -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)

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

@ -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)

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

@ -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
> [![Export the MDE Advanced Hunting results to CSV](../images/appcontrol-wizard-event-log-mde-ah-export.png)](../images/appcontrol-wizard-event-log-mde-ah-export-expanded.png)
3. Select **Policy Editor** from the main page.
4. Select **Convert Event Log to a 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.

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

@ -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)

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

@ -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"

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

@ -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)

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

@ -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)

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

@ -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.

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

@ -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

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

@ -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.

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

@ -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.

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

@ -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.

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

@ -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 |

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

@ -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

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

@ -1,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'

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

@ -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.