BigFix Application Control v2.x: Best Practices

Best Practices for WDAC Policy Deployment

To ensure robust endpoint security without disrupting business operations or user productivity, adhere to these core deployment principles, architectural guidelines, validation workflows, and operational procedures across all managed environments:

Core Principles:

• Validate Before Enforcement: Always deploy new policies, policy changes, or supplemental rules in Audit Mode within a designated User Acceptance Testing (UAT) environment before enforcing them.
• Data-Driven Rule Creation: Use Code Integrity event logs (3076, 3034) collected during UAT to identify required application components and select the most maintainable rule criteria — prioritizing Publisher/Signer rules over Hash or Path rules where feasible.
• Zero-Impact Promotion: Promote a policy to Enforcement Mode only after iterative UAT testing confirms all core application features, background tasks, dependent modules, and update workflows execute without generating audit events.
• Controlled Phased Rollout: Following successful UAT sign-off, deploy validated policies to production endpoints in progressive rollout rings adhering to your organization's standard change management process and Change Advisory Board (CAB) approval guidelines.
• Emergency Break-Glass & Dual-Node Provisioning: Pre-establish a dual-node emergency signing lifecycle (Node I Primary, Node II Emergency) to guarantee policy administration continuity, seamless failover, and certificate rotation without breaking kernel enforcement on managed endpoints.

Important Advisory: Policy Naming and Overwrite Behavior

• Base and Supplemental Policy Overwrites: Creating a new Base or Supplemental policy using an existing policy name will permanently overwrite the original XML policy file.
• Deployment Site Impact: Publishing a policy with a duplicate name overwrites the existing files in the Deployed site. Deploying this updated policy to endpoints will immediately apply the new policy rules, potentially altering or reverting active enforcement on target endpoints.
• Web Reports & History Tracking: Overwriting a Supplemental policy bypasses the Fixlet purge mechanism. As a result, Web Reports will not track historical changes or show active/inactive states for overwritten policies.

Recommendations to Preserve Change Tracking

• Assign Unique Names: Always assign unique names when creating new Base or Supplemental policies unless you explicitly intend to replace the existing policy and overwrite its history.
• Preserving Web Reports History: To block a previously allowed rule while keeping full historical records in Web Reports, use the Purge Supplemental Policy Rule Fixlet instead of overwriting the policy. This preserves the old policy file and displays the historical record in Web Reports.

Emergency Signing and Certificate Rotation Synchronization Process

This lifecycle governs policy administration when the Primary Signing Certificate expires, rotates, or fails due to infrastructure issues. Emergency signing is strictly audited and restricted to authorized recovery procedures.

Dual-Node Emergency Signing and Rotation Flow

• Mutual Trust Baseline: Public certificates (.cer) for Node I (Primary) and Node II (Emergency) are defined as authorized signers in the Base Policy XML, allowing endpoints to accept signed updates from either node without breaking kernel enforcement.
• Emergency Authorization: An administrator detects primary signing failure or certificate expiration and formally authorizes emergency protocol execution per security governance.
• Emergency Signing (Node II): Node II is temporarily subscribed to the Central Custom Site Repository, signs the active policy XML using its local hardware-protected Emergency Signing Certificate, and unsubscribes to minimize attack surface boundaries.
• Deployment Handoff: The emergency-signed .cip binary routes through the Upload Manager and Root Server to the Custom Site for continuous fleet deployment.
• Primary Certificate Re-provisioning: A new Primary Signing Certificate is generated, bound to TPM 2.0 on Node I, and its public key is shared with Node II for trust synchronization.
• State Sync & Failback (Node I): Node I temporarily subscribes to the Central Repository to pull the latest policy state, updates its definitions to trust the new primary certificate while retaining Node II's emergency certificate, re-signs the policy via TPM, and unsubscribes.
• Fleet Re-alignment: BigFix® Agents deploy the newly signed Base policy to managed endpoints, restoring primary governance without interrupting kernel enforcement. Compliance is verified via BigFix® Web Reports.

Co-located Management Node Setup (Not Recommended)

Architectural Recommendation: Deploying a dedicated, isolated WDAC Management Node is strongly recommended to keep policy-signing capabilities separated from general endpoints. Co-locating management components on an enforced endpoint introduces significant operational risk and is not advisable.

If operational constraints strictly require applying policy enforcement on the same host running the WDAC Management components, follow this mandatory workflow:

• Keep Base Policies Clean: Never add allow rules for signtool.exe or wdacmanager.exe to the global enterprise Base Policy, as this exposes code-signing capabilities fleet-wide.
• Pre-compile the Supplemental Policy: Create, compile, and sign the WDAC Management Supplemental Policy (authorizing wdacmanager.exe and signtool.exe) before applying a restrictive Base Policy to the host.
• Stage to Both Active Paths: Ensure both .cip policy binaries are deployed to both required storage locations:
  • OS Drive: %OSDrive%\Windows\System32\CodeIntegrity\CiPolicies\Active\{PolicyID}.cip
  • EFI Partition: <EFI Partition System>\Microsoft\Boot\CiPolicies\Active\{PolicyID}.cip

Recommended Rule Validation Approach

Follow this validation process when deploying an Application Control policy, onboarding a new application into WDAC, or determining the appropriate rule criteria for application dependencies.

Validation Workflow:

• Deploy in Audit Mode: Apply the WDAC policy in Audit Mode on designated UAT test endpoints.
• Execute Workflows: Run the application and perform all standard business workflows in UAT, including background services, secondary modules, and update routines.
• Monitor Code Integrity Events: Track generated WDAC/Code Integrity events to identify audited execution attempts.
• Aggregate & Review Events: Review and analyze collected event logs using BigFix® Web Reports or your enterprise reporting framework.
• Adjust & Refine Rules: Evaluate observed file attributes (Publisher, Hash, Path, or File Name) and generate required supplemental rules or adjust rule types accordingly (detailed in Annexure 1).
• Iterative Verification: Repeat steps 1—5 until all application functionality executes in UAT without generating audit events.
• Verify in Enforcement Mode: Apply the updated policy in Enforcement Mode on the UAT machine to confirm full operational capability under active enforcement.
• Production Rollout: Upon successful UAT sign-off, deploy the finalized policy to production endpoints according to your organization's standard change management process.

Annexure 1: Creating a Supplemental Policy via App Control Policy Wizard

When WDAC policy events occur, details are captured in the target endpoint's Windows Event Viewer under Applications and Services Logs > Microsoft > Windows > CodeIntegrity > Operational.

Key Code Integrity Event IDs:

• Audit Mode Events (used during validation):
  • 3076 — User-mode Audit event (indicates an executable or DLL would have been blocked in Enforcement Mode).
  • 3034 — Kernel-mode / Driver Audit event (indicates a driver would have been blocked in Enforcement Mode).
• Enforcement Mode Block Events (active policy enforcement):
  • 3077 — User-mode Block event (indicates an executed file was blocked by policy).
  • 3033 — Kernel-mode / Driver Block event (indicates a driver was blocked by policy).

Export Event Logs from UAT Endpoint

1. Open Event Viewer (eventvwr.msc) on the UAT test machine.
2. Navigate to Applications and Services Logs > Microsoft > Windows > CodeIntegrity > Operational.
3. Filter or select the relevant logs (Event IDs 3076 and 3034 for Audit Mode).
4. Right-click Operational and select Save All Events As... to export the .evtx log file.

Import Logs into App Control Policy Wizard

1. Launch the App Control Policy Wizard (see Microsoft App Control Policy Wizard from the Related Links section below).
2. Select Policy Editor on the home screen.
3. Select Convert Policy Logs to a Policy (or Supplemental Policy from Event Log).
4. Browse and select the exported .evtx log file.

Configure Supplemental Rules and Export

1. Review the list of audited/blocked files parsed by the wizard.
2. Assign the appropriate Rule Type (for example, Publisher, File Publisher, Hash, or Path) for each file entry based on organizational security guidelines.
3. Proceed through the wizard to build and output the supplemental policy XML.
4. Deploy the supplemental XML policy using the Generate Custom WDAC Policy XML task.