BigFix Application Control v2.x: Policy Behavior and Deployment Considerations
BigFix Application Control v2.x enforces application execution through a defined set of behavioral rules governing Base and Supplemental Policy interaction, explicit Deny rule precedence, multiple Base Policy evaluation (logical AND), script enforcement under UMCI, FilePath rule security, signed policy protection, application dependency enforcement, and signing certificate requirements. Understanding these 16 behaviors is essential before designing, deploying, or updating Application Control policies in BigFix-managed environments.
Base and Supplemental Policy Behavior
Supplemental Policies extend the trust established by their associated Base Policy and can be used to allow additional applications without modifying the Base Policy.
Base Policy Deny
An application explicitly denied by a Base Policy cannot be allowed through a Supplemental Policy. To permit the application, the Base Policy must be updated to remove the Deny and provide the required Allow rule.
Multiple Base Policies
Multiple active Base Policies are evaluated using an intersection (logical AND). An application must be allowed by all active Base Policies to execute. If any active Base Policy does not allow the application, execution is blocked.
Base Policy Updates
An existing Base Policy can be updated to change the authorization of an application. An explicit Allow or Deny can be changed by updating and redeploying the Base Policy.
Microsoft Windows Baseline
A Microsoft-provided policy template or appropriate Windows baseline should be used as the foundation for the Base Policy to help ensure required Windows components remain trusted and the operating system operates normally.
PowerShell and Script Enforcement
When UMCI is enabled and Option 11 (Disabled: Script Enforcement) is not enabled, script enforcement is active. Interactive PowerShell operates in Constrained Language Mode (CLM). Script execution depends on whether the script is trusted by the App Control policy and the applicable PowerShell configuration.
FilePath Rules
FilePath rules are subject to runtime protection based on the security of the target path. Applications located in paths that can be modified by standard users may not satisfy the default FilePath protection requirements.
Signed Policy Protection
Signed App Control policies provide protection against unauthorized modification or removal when Secure Boot is enabled. Customers should use supported policy update and removal procedures rather than manually modifying policy files.
Application Dependencies
Allowing an application's main executable may not be sufficient for the application to function. Required supporting executables, DLLs, or other components may also need to satisfy the App Control policy.
Publisher and Signer Rules
Publisher- and signer-based authorization depends on Windows Code Integrity being able to validate the application's supported signing information. Hash or file-based rules can be used when signer-based authorization is not suitable.
Policy-Signing Certificate
The certificate used to sign an App Control policy must meet the requirements of the policy-signing workflow, including the required Code Signing EKU.
Policy Signing
Signed App Control policies support RSA 2048-, 3072-, and 4096-bit keys. ECDSA is not supported for signed App Control policies.
Application Signer Rules
Application signer-based rules support RSA keys up to 4096 bits. ECC/ECDSA-based signer rules are not supported.
TPM-Based Policy Signing
A TPM-backed, non-exportable private key can be used to protect the policy-signing key. TPM availability is required when this signing approach is used.
User-Mode Enforcement
UMCI must be enabled when Application Control is intended to enforce policy on user-mode applications and scripts.
Windows Platform Support
Application Control capabilities and policy-management functionality depend on the supported Windows version, build, and edition. Policies and required features should be validated against the specific Windows platforms targeted for deployment.
DefaultWindows Policy EKU Differences
The EKU entries in the DefaultWindows policy can vary across Windows versions and builds. Customers should validate the policy contents against the specific Windows releases targeted for deployment.
Publisher Rule Size Constraint
Publisher rule generation is subject to a 4096-byte limit for application signing information. If exceeded, a Hash rule may be required.
Publisher Rule – DLL Dependencies
Publisher rules for an application executable do not necessarily allow its dependent DLLs. Unsigned DLLs may require File Path or Hash-based rules for enforcement.
File Attribute – OriginalFilename Dependency
File Attribute rules based on OriginalFilename require the attribute to be present in the application binary. If missing or unavailable, the rule may not match the application.