Events
May 19, 6 PM - May 23, 12 AM
Calling all developers, creators, and AI innovators to join us in Seattle @Microsoft Build May 19-22.
Register todayPlan for App Control for Business lifecycle policy management
Note
Some capabilities of App Control for Business are only available on specific Windows versions. Learn more about App Control feature availability.
This article describes the decisions you need to make to establish the processes for managing and maintaining App Control for Business policies.
The first step in implementing App Control is to consider how your policies will be managed and maintained over time. Developing a process for managing App Control for Business policies helps ensure that App Control continues to effectively control how applications are allowed to run in your organization.
Most App Control for Business policies will evolve over time and proceed through a set of identifiable phases during their lifetime. Typically, these phases include:
- Define (or refine) the "circle-of-trust" for the policy and build an audit mode version of the policy XML. In audit mode, block events are generated but files aren't prevented from executing.
- Deploy the audit mode policy to intended devices.
- Monitor audit block events from the intended devices and add/edit/delete rules as needed to address unexpected/unwanted blocks.
- Repeat steps 2-3 until the remaining block events meet expectations.
- Generate the enforced mode version of the policy. In enforced mode, files that the policy doesn't allow are prevented from running and corresponding block events are generated.
- Deploy the enforced mode policy to intended devices. We recommend using staged rollouts for enforced policies to detect and respond to issues before deploying the policy broadly.
- Repeat steps 1-6 anytime the desired "circle-of-trust" changes.
To effectively manage App Control for Business policies, you should store and maintain your policy XML documents in a central repository that is accessible to everyone responsible for App Control policy management. We recommend a source control solution such as GitHub or a document management solution such as Office 365 SharePoint, which provide version control and allow you to specify metadata about the XML documents.
Use the Set-CIPolicyIDInfo cmdlet to give each policy a descriptive name and set a unique policy ID. These unique attributes help you differentiate each policy when reviewing App Control for Business events or when viewing the policy XML document. Although you can specify a string value for PolicyId, for policies using the multiple policy format we recommend using the -ResetPolicyId switch to let the system autogenerate a unique ID for the policy.
Note
PolicyID only applies to policies using the multiple policy format on computers running Windows 10, version 1903 and above, or Windows 11. Running -ResetPolicyId on a policy created for pre-1903 computers will convert it to multiple policy format and prevent it from running on those earlier versions of Windows 10. PolicyID should be set only once per policy and use different PolicyID's for the audit and enforced mode versions of each policy.
In addition, we recommend using the Set-CIPolicyVersion cmdlet to increment the policy's internal version number when you make changes to the policy. The version must be defined as a standard four-part version string (for example, "1.0.0.0").
You might need to revise your policy when new apps are deployed or existing apps are updated by the software publisher to ensure that apps run correctly. Whether policy rule updates are required will depend significantly on the types of rules your policy includes. Rules based on codesigning certificates provide the most resiliency against app changes while rules based on file attributes or hash are most likely to require updates when apps change. Alternatively, if you use App Control managed installer functionality and consistently deploy all apps and their updates through your managed installer, then you're less likely to need policy updates.
Each time that App Control blocks a process, events are written to either the CodeIntegrity\Operational or the AppLocker\MSI and Script Windows event logs. The event describes the file that tried to run, the attributes of that file and its signatures, and the process that attempted to run the blocked file.
Collecting these events in a central location can help you maintain your App Control for Business policy and troubleshoot rule configuration problems. You can use the Azure Monitor Agent to automatically collect your App Control events for analysis.
Additionally, Microsoft Defender for Endpoint collects App Control events which can be queried using the advanced hunting feature.
Considerations include:
- What type of end-user support is provided for blocked applications?
- How are new rules added to the policy?
- How are existing rules updated?
- Are events forwarded for review?
If your organization has an established help desk support department in place, consider the following points when deploying App Control for Business policies:
- What documentation does your support department require for new policy deployments?
- What are the critical processes in each business group both in work flow and timing that will be affected by App Control policies and how could they affect your support department's workload?
- Who are the contacts in the support department?
- How will the support department resolve App Control issues between the end user and those resources who maintain the App Control for Business rules?
Because App Control for Business is preventing unapproved apps from running, it's important that your organization carefully plans how to provide end-user support. Considerations include:
- Do you want to use an intranet site as a frontline of support for users who try to run a blocked app?
- How do you want to support exceptions to the policy? Will you allow users to run a script to temporarily allow access to a blocked app?
After deciding how your organization will manage your App Control for Business policy, record your findings.
- End-user support policy. Document the process that you'll use for handling calls from users who have attempted to run a blocked app, and ensure that support personnel have clear escalation steps so that the administrator can update the App Control for Business policy, if necessary.
- Event processing. Document whether events will be collected in a central location called a store, how that store will be archived, and whether the events will be processed for analysis.
- Policy management. Detail what policies are planned, how they'll be managed, and how rules will be maintained over time.