Watching my miniature schnauzer, Raven, explore my backyard, I’m reminded of the importance of having a clear set of rules and guidelines. Just like Raven has her own schema to navigate her environment—knowing where she can wander, where she shouldn't venture, and how to interact. Application Control for Business (ACfB) provides a robust schema to help organizations manage and secure their digital landscapes.
Note: ACfB has also been known as Windows Defender Application Control (WDAC), Application Control for Windows and Code Integrity.
Application Control for Windows | Microsoft Learn
In Raven's serene world, her schema might look something like this:
- Safe Zones: The grassy lawn where she can leisurely sniff around and her favorite shady spot under the tree.
- Restricted Zones: The delicate garden beds and the tempting koi pond, which are off-limits to her curious paws.
- Behavior Rules: Guidelines for greeting other animals and people, ensuring she remains the friendly neighborhood pup.
Similarly, ACfB's schema defines the rules and guidelines for managing applications and code within an organization:
- Approved Applications: Software that is allowed to run, ensuring it is safe and trusted.
- Restricted Applications: Programs that are blocked from execution to prevent potential security threats.
- Execution Rules: Policies that dictate how applications can interact with the system, ensuring a secure and controlled environment.
For Raven, following her schema with precision is key. It keeps her out of trouble and ensures she enjoys her outdoor time without any mishaps. The order of her schema is equally important. She needs to know the safe zones before understanding the restricted ones, and she must learn the behavior rules to interact safely with others.
Similarly, for organizations, adhering to ACfB's schema is crucial. It ensures that only approved applications run, restricted applications are blocked, and execution rules are followed, maintaining a secure and efficient digital landscape.
Similarly, ACfB's schema defines precise rules for applications, ensuring that only trusted software runs on your systems, protecting against malicious code and unauthorized access. The order in which these rules and policies are defined is critical. Just as Raven's schema order helps her navigate her environment effectively, the correct order of elements in the ACfB schema ensures that the policy is correctly interpreted and enforced.
Application Control for Business - Schema Overview
The ACfB schema provides a comprehensive framework for defining rules and policies that control which applications are allowed to run on your systems. It ensures that only trusted applications are executed, enhancing security and compliance.
XML Structure Overview
The XML structure used in the schema provides a high-level view of how the elements and attributes are organized. This structure ensures that the policy is correctly interpreted and enforced by Application Control for Business.
Policy Information
This section includes metadata about the policy, such as its name, ID, version, and description. It provides essential information for identifying and managing different policies.
SiPolicy Elements (Policy controls)
Detailed descriptions of the elements that control the policy, such as rules for allowing or blocking applications. These elements define the core functionality of the policy.
Rules
Definitions of the various rules that can be applied within the policy, specifying what is allowed or denied. These rules are crucial for controlling application behavior.
FileRules
Specific rules related to files, including how they are identified and controlled. This section ensures that only trusted files are allowed to execute.
Signers
Information about the entities that sign the applications, ensuring they are trusted. This section is crucial for maintaining the integrity and trustworthiness of applications.
SigningScenarios
Different scenarios in which signing is used, providing context for when and how applications should be signed. This section helps ensure that signing practices are consistently applied.
CiSigners
Information about code integrity signers, who are responsible for ensuring the integrity of the code. This section is crucial for maintaining code integrity.
Settings
General settings for the policy, including various configuration options. These settings control the overall behavior of the policy.
EKUs
Extended Key Usages, which specify the purposes for which a certificate can be used. This section ensures that certificates are used appropriately.
UpdatePolicySigners
Information about the signers who are authorized to update the policy. This section ensures that only trusted entities can modify the policy.
HVCIOptions
Detailed descriptions of the hypervisor-protected code integrity options. These details define the characteristics and configurations of each option.
Macros
Definitions of macros used within the policy, allowing for reusable configurations. This section provides flexibility and efficiency in policy management.
SupplementalPolicySigners
Information about additional signers who can supplement the main policy. This section ensures that the policy can be extended and updated as needed.
SupplementalPolicySigners Elements and Attributes
Application Control for Business Schema
The ACfB schema, as defined in the provided file (CiPolicy.xsd), is a comprehensive XML schema that outlines the structure and rules for creating and managing security policies within the Application Control for Business framework. This schema includes various elements and attributes that specify how policies are constructed, validated, and enforced. Key components of the schema include definitions for file rules, signers, signing scenarios, and policy settings, each with specific attributes and nested elements that provide detailed control over the security configurations.
The primary purpose of the ACfB schema is to enhance the security posture of Windows environments by ensuring that only trusted and verified code is allowed to execute. By defining rules for allowing or denying specific files, managing trusted signers, and specifying conditions under which certain policies apply, the ACfB schema helps administrators create granular and flexible security policies. These policies protect against unauthorized code execution, maintain system integrity, and ensure compliance with organizational security standards.
Application Control Bypass
ACfB provides the ability to lock down endpoints effectively, but there are some potential bypasses that need to be addressed. Certain legitimate applications, such as powershell.exe, msbuild.exe, and wscript.exe, can be exploited by attackers to circumvent these controls. Blocking these applications is recommended unless they are absolutely necessary for business operations.
Additionally, keeping software up to date is crucial to mitigate vulnerabilities. For instance, older versions of BGInfo are vulnerable and should be blocked, while the latest version has resolved these security issues. The security community has been instrumental in identifying these vulnerabilities and helping to protect users. Following these recommendations is vital to ensure our systems remain secure.
For complete details, please refer to the full article on Microsoft's website:
Applications that can bypass App Control and how to block them | Microsoft Learn
XML Structure Overview
An ACfB policy XML file consists of several key sections:
- Policy Information: Metadata about the policy.
- Rules: Definitions of what is allowed or denied.
- File Rules: Specific rules for files and applications.
- Signing Rules: Rules for signed applications and drivers.
Policy Information
The <SiPolicy> Root Element is used to define the overall security policy for the system. This element encompasses various configurations and settings that dictate how the security policy is enforced. It includes details such as policy type, policy rules, and other critical parameters that ensure the integrity and security of the system. By configuring <SiPolicy>, organizations can establish a comprehensive security framework that governs the behavior of applications and code execution on the system.
SiPolicy | |||
|----- |
Attributes | ||
| |
|----- |
FriendlyName | |
| |
|----- |
PolicyType | |
| |
|------------------------ |
"Base Policy" | |
| |
|------------------------ |
"Supplemental Policy" | |
| |
|------------------------ |
"AppID Tagging Policy" | |
| | |||
|----- |
Elements | ||
|----- |
VersionEx *1, *2 | ||
|----- |
PolicyTypeID *2 | ||
|----- |
PlatformID *1, *2 | ||
|----- |
PolicyID * 2 | ||
|----- |
BasePolicyID *2 | ||
|----- |
Rules | ||
|----- Rule | |||
|----- |
EKUs | ||
|----- |
FileRules | ||
|----- |
Signers | ||
|----- |
SigningScenarios | ||
|----- |
UpdatePolicySigners | ||
|----- |
CiSigners | ||
|----- |
HvciOptions | ||
|----- |
Settings | ||
|----- |
Macros | ||
|----- |
SupplementalPolicySigners | ||
|----- |
AppSettings | ||
*1 - Required | |||
*2 - These elements are used for defining and managing the ACfB policies on an endpoint. |
SiPolicy Elements (Policy controls)
Element Names |
Description |
VersionEx |
Specifies the extended version of the policy. |
PolicyTypeID |
Used to uniquely identify and manage different types of polices |
PolicyID |
The unique identifier for the policy. |
BasePolicyID |
The GUID of the base policy, if applicable. |
PlatformID |
The identifier for the platform the policy applies to. |
<SiPolicy>
<VersionEx>1.0.3.0</VersionEx>
<PolicyID>{31351756-3F24-4963-8380-4E7602335AAE}</PolicyID>
<BasePolicyID>{31351756-3F24-4963-8380-4E7602335AAE}</BasePolicyID>
<PlatformID>{2E07F7E4-194C-4D20-B7C9-6F44A6C5A234}</PlatformID>
<!-- Other policy elements here -->
</SiPolicy>
There are a total of 17 sub-elements available under <SiPolicy> in a ACfB policy XML file.
Element Names |
Description |
Notes |
---|---|---|
<VersionEx> |
Specifies the version of the System Integrity policy. |
Required |
<PolicyTypeID> |
Unique identifier for the policy type. | |
<PlatformID> |
Unique identifier for the platform. |
Required |
<PolicyID> |
Unique identifier for the policy. | |
<BasePolicyID> |
Unique identifier for the base policy. | |
<Rules> |
The <Rules> sub-element is used to define various options and settings related to the rules enforced by the policy. These options can include configurations such as enabling or disabling specific rule types, setting enforcement levels, and other parameters that control how the rules are applied. By configuring <RulesOptions>, organizations can fine-tune the behavior of their security policies to meet specific requirements and ensure that the rules are enforced in a manner that aligns with their security objectives. |
Contains a sequence of <Rule> elements defining various policy rules. |
<EKUs> |
The <EKUs> element defines Extended Key Usage (EKU) settings for the ACfB policy. EKUs specify the purposes for which a certificate can be used, such as code signing or server authentication. This element can include multiple EKU definitions, each specified within an <EKU> element. By defining EKUs, administrators can ensure that only certificates with the appropriate usage attributes are trusted, providing an additional layer of security for the system. |
Collection of Extended Key Usage (EKU) elements. |
FileRules |
The <FileRules> element specifies how applications and drivers are identified and allowed or denied. This element can include rules based on file attributes, hashes, paths, publishers, and certificates. For example, you can allow a specific file by its hash or allow all files in a particular directory. The flexibility of <FileRules> allows administrators to create granular policies that precisely control which files are permitted to execute, enhancing the security posture of the system. |
Collection of file rules. |
Signers |
The <Signers> element defines trusted signers for applications and drivers. This element can include various types of signers, such as FilePublisher, LeafCertificate, PcaCertificate, and RootCertificate. Each signer type specifies different levels of trust, from individual files to entire certificate chains. By defining trusted signers, administrators can ensure that only applications and drivers signed by recognized entities are allowed to run, reducing the risk of malware and unauthorized software. |
Collection of signers. |
SigningScenarios |
The <SigningScenarios> element specifies different scenarios under which signing rules apply. This element can include scenarios for drivers, Windows components, and other specific use cases. Each scenario is defined within a <SigningScenario> element, which includes details such as the scenario value, ID, and friendly name. By defining signing scenarios, administrators can create policies that apply different rules based on the context in which an application or driver is executed, providing more nuanced control over software execution. |
Collection of signing scenarios. |
UpdatePolicySigners |
The <UpdatePolicySigners> element defines signers that are trusted to update the ACfB policy. This element can include various types of signers, such as FilePublisher, LeafCertificate, PcaCertificate, and RootCertificate. By specifying trusted update policy signers, administrators can ensure that only authorized entities can modify the ACfB policy, preventing unauthorized changes that could compromise the security of the system. |
Collection of signers for system integrity policy updating. |
CiSigners |
The <CiSigners> element defines Code Integrity signers that are trusted for all builds, including retail builds. This element is typically used to include enterprise signers or production signers that are trusted across the organization. By specifying trusted Code Integrity signers, administrators can ensure that only code signed by recognized entities is allowed to run, enhancing the overall security of the system. |
Collection of signers trusted for CI signing levels. |
HvciOptions |
Hypervisor-Protected Code Integrity (HVCI) leverages virtualization-based security (VBS) to ensure that only trusted code runs in kernel mode |
Specifies (HVCI) settings. |
Settings |
The <Settings> element includes additional settings for the ACfB policy. This element can define various configuration options, such as policy information, enterprise-defined settings, and other custom settings. Each setting is specified within a <Setting> element, which includes details such as the provider, key, value name, and value. By configuring these settings, administrators can customize the behavior of the ACfB policy to meet the specific needs of their organization. |
Collection of setting elements. |
Macros |
The <Macros> element defines a collection of macro definitions that can be used throughout the policy. Macros allow for text substitution, making it easier to manage and update policy configurations. Each macro is defined within a <Macro> element, which includes an ID and a value. By using macros, administrators can simplify the policy management process and ensure consistency across different policy elements. |
Collection of macro definitions. |
SupplementalPolicySigners |
The <SupplementalPolicySigners> element defines a collection of signers for supplemental policies. These signers are trusted to sign additional policies that extend or modify the base policy. By specifying supplemental policy signers, administrators can ensure that only authorized entities can create or update supplemental policies, maintaining the integrity and security of the overall policy framework. |
Collection of signers for supplemental policies. |
AppSettings |
The <AppSettings> element defines a collection of application settings. These settings can include various configuration options specific to applications, such as manifest paths and custom settings. Each application setting is defined within an <App> element, which includes details such as the manifest path and individual settings. By configuring application settings, administrators can tailor the behavior of specific applications to meet organizational requirements. |
Collection of application settings. |
The <Rules> sub-element is used to organize and manage various rules within the policy. It contains a sequence of <Rule> elements, each defined by the Rules complex type. These rules specify configurations such as enabling or disabling specific options, setting enforcement levels, and other parameters that control how the rules are applied. By configuring the <Rules> sub-element, organizations can fine-tune the behavior of their security policies to meet specific requirements and ensure that the rules are enforced in a manner that aligns with their security objectives.
Rules | ||||
|------ |
Rule | |||
|------ |
RuleType | |||
|------ |
Option | |||
|------ |
Enabled:UMCI | |||
|------ |
Enabled:Boot Menu Protection | |||
|------ |
Enabled:Intelligent Security Graph Authorization | |||
|------ |
Enabled:Invalidate EAs on Reboot | |||
|------ |
Required:WHQL | |||
|------ |
Enabled:Developer Mode Dynamic Code Trust | |||
|------ |
Enabled:Allow Supplemental Policies | |||
|------ |
Disabled:Runtime FilePath Rule Protection | |||
|------ |
Enabled:Revoked Expired As Unsigned | |||
|------ |
Enabled:Audit Mode | |||
|------ |
Disabled:Flight Signing | |||
|------ |
Enabled:Inherit Default Policy | |||
|------ |
Enabled:Unsigned System Integrity Policy | |||
|------ |
Enabled:Dynamic Code Security | |||
|------ |
Required:EV Signers | |||
|------ |
Enabled:Boot Audit On Failure | |||
|------ |
Enabled:Advanced Boot Options Menu | |||
|------ |
Disabled:Script Enforcement | |||
|------ |
Required:Enforce Store Applications | |||
|------ |
Enabled:Secure Setting Policy | |||
|------ |
Enabled:Managed Installer | |||
|------ |
Enabled:Update Policy No Reboot | |||
|------ |
Enabled:Conditional Windows Lockdown Policy |
Rules Options
Option Types |
Description |
---|---|
Enabled:UMCI |
Enables User Mode Code Integrity (UMCI), ensuring that only trusted code runs in user mode. |
Enabled:Boot Menu Protection |
Enables protection for the boot menu, preventing unauthorized changes to boot configurations. |
Enabled:Intelligent Security Graph Authorization |
Utilizes the Intelligent Security Graph to authorize applications, enhancing security by leveraging Microsoft's threat intelligence. |
Enabled:Invalidate EAs on Reboot |
Invalidates Extended Attributes (EAs) on reboot, ensuring that any changes to EAs are not persistent across reboots. |
Required:WHQL |
Requires that drivers are Windows Hardware Quality Labs (WHQL) certified, ensuring they meet Microsoft's quality standards. |
Enabled:Developer Mode Dynamic Code Trust |
Enables dynamic code trust for developer mode, allowing developers to run and test code that may not be signed. |
Enabled:Allow Supplemental Policies |
Allows the use of supplemental policies, which can extend or modify the base policy. |
Disabled:Runtime FilePath Rule Protection |
Disables runtime protection for file path rules, potentially reducing security but allowing more flexibility. |
Enabled:Revoked Expired As Unsigned |
Treats revoked or expired certificates as unsigned, preventing code signed with such certificates from running. |
Enabled:Audit Mode |
Enables audit mode, which logs policy violations without enforcing them, useful for testing and monitoring. |
Disabled:Flight Signing |
Disables flight signing, which is used for pre-release software testing. |
Enabled:Inherit Default Policy |
Allows the policy to inherit settings from the default policy, ensuring consistency and reducing configuration effort. |
Enabled:Unsigned System Integrity Policy |
Enables the use of unsigned system integrity policies, which can be useful in certain testing or development scenarios. |
Enabled:Dynamic Code Security |
Enhances security by enabling dynamic code security measures, which help protect against runtime code modifications. |
Required:EV Signers |
Requires Extended Validation (EV) certificates for code signing, providing a higher level of trust. |
Enabled:Boot Audit On Failure |
Enables auditing of boot failures, helping to diagnose and troubleshoot boot issues. |
Enabled:Advanced Boot Options Menu |
Enables the advanced boot options menu, providing additional boot options for troubleshooting and recovery. |
Disabled:Script Enforcement |
Disables enforcement of script policies, allowing scripts to run without being subject to policy restrictions. |
Required:Enforce Store Applications |
Requires that only applications from the Microsoft Store are allowed to run, enhancing security by restricting software sources. |
Enabled:Secure Setting Policy |
Enables secure setting policies, which enforce additional security settings. |
Enabled:Managed Installer |
Allows the use of a managed installer, which can install and manage applications according to policy. |
Enabled:Update Policy No Reboot |
Enables policy updates without requiring a reboot, reducing downtime and improving user experience. |
Enabled:Conditional Windows Lockdown Policy |
Enables conditional lockdown policies, which can enforce stricter security measures based on certain conditions. |
<!-- Other policy elements here -->
<Rules>
<Rule>
<Option>Enabled:Unsigned System Integrity Policy</Option>
</Rule>
<Rule>
<Option>Enabled:Advanced Boot Options Menu</Option>
</Rule>
Rule>
<Option>Disabled:Script Enforcement</Option>
</Rule>
</Rules>
<!-- Other policy elements here -->
The <FileRules> sub-element is used to define various options and settings related to file rules enforced by the policy. These options can include configurations such as specifying file types to be monitored, setting enforcement levels for different file operations, and other parameters that control how file rules are applied. By configuring <FileRules>, organizations can customize the behavior of their file security policies to meet specific requirements and ensure that file operations are monitored and controlled in a manner that aligns with their security objectives.
FileRules | |||
|------ |
Allow | ||
| |
|-------- |
ID *1 | |
| |
|-------- |
FriendlyName | |
| |
|-------- |
FileName | |
| |
|-------- |
InternalName | |
| |
|-------- |
FileDescription | |
| |
|-------- |
ProductName | |
| |
|-------- |
PackageFamilyName | |
| |
|-------- |
PackageVersion | |
| |
|-------- |
MinimumFileVersion | |
| |
|-------- |
MaximumFileVersion | |
| |
|-------- |
Hash | |
| |
|-------- |
AppIDs | |
| |
|-------- |
FilePath | |
| | |||
|------ |
Deny | ||
| |
|-------- |
ID *1 | |
| |
|-------- |
FriendlyName | |
| |
|-------- |
FileName | |
| |
|-------- |
InternalName | |
| |
|-------- |
FileDescription | |
| |
|-------- |
ProductName | |
| |
|-------- |
PackageFamilyName | |
| |
|-------- |
PackageVersion | |
| |
|-------- |
MinimumFileVersion | |
| |
|-------- |
MaximumFileVersion | |
| |
|-------- |
Hash | |
| |
|-------- |
AppIDs | |
| |
|-------- |
FilePath | |
| | |||
|------ |
FileAttrib | ||
| |
|-------- |
ID *1 | |
| |
|-------- |
FriendlyName | |
| |
|-------- |
FileName | |
| |
|-------- |
InternalName | |
| |
|-------- |
FileDescription | |
| |
|-------- |
ProductName | |
| |
|-------- |
PackageFamilyName | |
| |
|-------- |
PackageVersion | |
| |
|-------- |
MinimumFileVersion | |
| |
|-------- |
MaximumFileVersion | |
| |
|-------- |
Hash | |
| |
|-------- |
AppIDs | |
| |
|-------- |
FilePath | |
| | |||
|------ |
FileRule | ||
|-------- |
ID *1 | ||
|-------- |
FriendlyName | ||
|-------- |
FileName | ||
|-------- |
InternalName | ||
|-------- |
FileDescription | ||
|-------- |
ProductName | ||
|-------- |
PackageFamilyName | ||
|-------- |
PackageVersion | ||
|-------- |
MinimumFileVersion | ||
|-------- |
MaximumFileVersion | ||
|-------- |
Hash | ||
|-------- |
AppIDs | ||
|-------- |
FilePath | ||
|-------- |
Type *1 | ||
|------------------- |
"Match" | ||
|------------------- |
"Exclude" | ||
|------------------- |
"Attribute" | ||
*1 = Required | |||
FileRules Elements and Attributes
There are 4 elements and 13 attributes available for FileRules. The elements specify how applications and drivers are identified and allowed or denied based on various attributes within the ACfB policy. The attributes allow administrators to specify criteria based on various properties of files, such as their cryptographic hash, file name, file path, publisher's certificate, and more. This ensures that only trusted and verified files are permitted to execute
Element Names |
Attribute Names |
Description |
---|---|---|
Allow Deny FileAttrib FileRule |
AppIDs |
Application IDs associated with the file, used for additional identification and management. |
FileDescription |
A description of the file, providing more context about its purpose and usage. | |
FileName |
Specifies the name of the file to allow. Ensures that only files with this exact name are permitted to run. | |
FilePath |
Specifies the path of the file to allow. Ensures that only files located in this specific path are permitted to run. | |
FriendlyName |
A user-friendly name for the rule, making it easier to identify and manage. | |
Hash |
Specifies the cryptographic hash of the file to allow. Provides a high level of security by ensuring that only the exact file with this hash is permitted to run. | |
ID |
Unique identifier for the rule. (Required) | |
InternalName |
The internal name of the file, often used for additional verification. | |
MaximumFileVersion |
Specifies the maximum version of the file to allow. Prevents the execution of potentially outdated or insecure versions. | |
MinimumFileVersion |
Specifies the minimum version of the file to allow. Ensures that only updated and secure versions are permitted. | |
PackageFamilyName |
The package family name for the file, used to group related files together. | |
PackageVersion |
The version of the package that the file belongs to, ensuring compatibility and version control. | |
ProductName |
The name of the product associated with the file, helping to identify the software it belongs to. | |
FileRule (only) |
Type |
Specifies the type of rule being applied, such as Match, Exclude, or Attribute. This attribute defines the condition under which the rule applies, allowing for precise control over how files are identified and managed. (Required) |
<!-- Other policy elements here -->
<FileRules>
<FileAttrib ID="ID_FILEATTRIB_A_1" FriendlyName="Allow files based on file attributes: 16.0.18429.20114 and WinWord.exe" FileName="*" MinimumFileVersion="16.0.18429.20114"/>
<Allow ID="ID_ALLOW_PATH_0_1_0" FriendlyName="Allow by path: %OSDRIVE%\Program Files\PuTTY\putty.exe" FilePath="%OSDRIVE%\Program Files\PuTTY\putty.exe"/>
<Deny ID="ID_DENY_PATH_0_1_0" FriendlyName="Deny by path: %OSDRIVE%\Program Files\Notepad++\notepad++.exe" FilePath="%OSDRIVE%\Program Files\Notepad++\notepad++.exe"/>
<Allow ID="ID_ALLOW_A_1_1_0" FriendlyName="Allow files based on file attributes: Google Chrome" FileDescription="Google Chrome"/>
</FileRules>
<!-- Other policy elements here -->
Signers
The <Signers> sub-element is a collection of <Signer> elements that are trusted to sign applications and drivers. It includes various sub-elements that define the details of each signer. These options can include configurations such as specifying the criteria for trusted signers, setting validation levels for signer certificates, and other parameters that control how signers are managed and verified. By configuring <Signers>, organizations can ensure that only authorized and trusted signers are allowed, enhancing the security and integrity of the system by preventing unauthorized code from being executed.
Sub-element:<Signer> of <Signers>
The <Signer> sub-element defines an individual signer and includes several attributes and nested elements that specify the details of the signer's certificate and other relevant information.
Signers | |||||
|------ |
Signer | ||||
|------ |
Attributes | ||||
| |
|------ |
Name | |||
| |
|------ |
ID | |||
| |
|------ |
SignTimeAfter | |||
| | |||||
|------ |
Certroot *1 | ||||
| |
|------ |
Attribute | |||
| |
|------ |
Type *1 | |||
| |
|----- |
"TBS" | |||
| |
|----- |
"WellKnown" | |||
| | |||||
| |
|------ |
Value *1 | |||
|------ |
CertEKU | ||||
| |
|------ |
Attribute | |||
| |
|------ |
ID *1 | |||
|------ |
CertIssuer | ||||
| |
|------ |
Attribute | |||
| |
|------ |
Value *1 | |||
|------ |
CertPublisher | ||||
| |
|------ |
Attribute | |||
| |
|------ |
Value *1 | |||
|------ |
CertOemID | ||||
| |
|------ |
Attribute | |||
| |
|------ |
Value *1 | |||
|------ |
FileAttribRef | ||||
|------ |
Attribute | ||||
|------ |
RuleID *1 | ||||
*1 = Required |
Signers Elements and Attributes
Element Names |
Attribute Names |
Description |
---|---|---|
Signers |
A collection of Signer elements that define individual signers trusted to sign applications and drivers. | |
Signer |
Name |
Specifies the name of the signer. |
ID |
Unique identifier for the signer. | |
SignTimeAfter |
Specifying the time after which the signer's certificate is valid. | |
CertRoot |
Type |
Specifies the root certificate for a signer. (Required) |
Value |
Specifies the value of the root certificate in hexBinary form. | |
CertEKU |
ID |
Specifies the EKU ID. |
CertIssuer |
Value |
Specifies the value of the issuer certificate. |
CertPublisher |
Value |
Specifies the value of the publisher certificate. |
CertOemID |
Value |
Specifies the value of the OEM ID. |
FileAttribRef |
RuleID |
References a file attribute rule through its ID. |
<!-- Other policy elements here -->
<FileRules>
<FileAttrib ID="ID_FILEATTRIB_A_2" FriendlyName="Allow files based on file attributes: 132.0.6834.111 and chrome.exe" FileName="*" MinimumFileVersion="132.0.6834.111"/>
<FileAttrib ID="ID_FILEATTRIB_A_1_1_0" FriendlyName="Deny files based on file attributes: 21.4.7.25431 and SNAGIT32.EXE" FileName="*" MinimumFileVersion="21.4.7.25431"/>
</FileRules>
<Signers>
<Signer Name="DigiCert Trusted Root G4" ID="ID_SIGNER_S_1_0_0">
<CertRoot Type="TBS" Value="11533EFD6B326A4E065A936DE300FE0586A479F93D569D2403BD62C7AD35F1B2199DAEE3ADB510F429C4FC97B4B024E3"/>
<CertPublisher Value="Google LLC"/>
<FileAttribRef RuleID="ID_FILEATTRIB_A_2"/>
</Signer>
<Signer Name="DigiCert EV Code Signing CA (SHA2)" ID="ID_SIGNER_S_1_1_0">
<CertRoot Type="TBS" Value="EEC58131DC11CD7F512501B15FDBC6074C603B68CA91F7162D5A042054EDB0CF"/>
<CertPublisher Value="TechSmith Corporation"/>
<FileAttribRef RuleID="ID_FILEATTRIB_A_1_1_0"/>
</Signer>
</Signers>
<!-- Other policy elements here -->
SigningScenarios
The <SigningScenarios> element is used to define the different scenarios in which code signing is required or trusted. These scenarios specify the conditions under which code must be signed to be considered valid and executable. By configuring <SigningScenarios>, organizations can enforce code signing policies that ensure only authorized and trusted code is allowed to run. This helps in maintaining the integrity and security of the system by preventing the execution of unauthorized or malicious code.
SigningScenarios | |||||||
| | |||||||
SigningScenario | |||||||
|---------- |
Attributes | ||||||
| |
|---------- |
ID *1 | |||||
| |
|---------- |
FriendlyName | |||||
| |
|---------- |
Value *1 | |||||
| |
|---------- |
InheritedScenarios | |||||
| |
|---------- |
MinimumHashAlgorithm | |||||
| |
|
|
|
|
| ||
|---------- |
ProductSigners *1 | ||||||
| |
|---------- |
AllowedSigners | |||||
| |
| |
|--------------- |
Attributes | ||||
| |
| |
| |
|--------- |
Workaround | |||
| |
| |
| | |||||
| |
| |
|--------------- |
AllowedSigner | ||||
| |
| |
|--------- |
Attributes | ||||
| |
| |
| |
|------- |
SignerId | |||
| |
| |
| | |||||
| |
| |
|--------- |
ExceptDenyRule | ||||
| |
| |
|------- |
Attributes | ||||
| |
|---------- |
DeniedSigners |
|------- |
DenyRuleId | |||
| |
| |
|--------------- |
Attributes | ||||
| |
| |
| |
|--------- |
Workaround | |||
| |
| |
| | |||||
| |
| |
|--------------- |
DeniedSigner | ||||
| |
| |
|--------- |
Attributes | ||||
| |
| |
| |
|------- |
SignerId | |||
| |
| |
| | |||||
| |
| |
|--------- |
ExceptAllowRule | ||||
| |
| |
|------- |
Attributes | ||||
| |
|---------- |
FileRulesRef |
|------- |
AllowRuleId | |||
| |
|--------------- |
Atributes | |||||
| |
| |
|--------- |
Workaround | ||||
| |
| | ||||||
| |
|--------------- |
FileRuleRef | |||||
| |
|--------- |
RuleId | |||||
| |
|
|
|
|
| ||
|---------- |
TestSigners | ||||||
| |
|---------- |
AllowedSigners | |||||
| |
| |
|--------------- |
Attributes | ||||
| |
| |
| |
|--------- |
Workaround | |||
| |
| |
| | |||||
| |
| |
|--------------- |
AllowedSigner | ||||
| |
| |
|--------- |
Attributes | ||||
| |
| |
| |
|------- |
SignerId | |||
| |
| |
| | |||||
| |
| |
|--------- |
ExceptDenyRule | ||||
| |
| |
|------- |
Attributes | ||||
| |
|---------- |
DeniedSigners |
|------- |
DenyRuleId | |||
| |
| |
|--------------- |
Attributes | ||||
| |
| |
| |
|--------- |
Workaround | |||
| |
| |
| | |||||
| |
| |
|--------------- |
DeniedSigner | ||||
| |
| |
|--------- |
Attributes | ||||
| |
| |
| |
|------- |
SignerId | |||
| |
| |
| | |||||
| |
| |
|--------- |
ExceptAllowRule | ||||
| |
| |
|------- |
Attributes | ||||
| |
|---------- |
FileRulesRef |
|------- |
AllowRuleId | |||
| |
|--------------- |
Atributes | |||||
| |
| |
|--------- |
Workaround | ||||
| |
FileRuleRef | ||||||
| |
|--------------- |
Atributes | |||||
| |
| |
|--------- |
Workaround | ||||
| |
| | ||||||
| |
|--------------- |
FileRuleRef | |||||
| |
|--------- |
RuleId | |||||
| |
|
|
|
|
| ||
|---------- |
TestSigningSigners | ||||||
| |
|---------- |
AllowedSigners | |||||
| |
| |
|--------------- |
Attributes | ||||
| |
| |
| |
|--------- |
Workaround | |||
| |
| |
| | |||||
| |
| |
|--------------- |
AllowedSigner | ||||
| |
| |
|--------- |
Attributes | ||||
| |
| |
| |
|------- |
SignerId | |||
| |
| |
| | |||||
| |
| |
|--------- |
ExceptDenyRule | ||||
| |
| |
|------- |
Attributes | ||||
| |
|---------- |
DeniedSigners |
|------- |
DenyRuleId | |||
| |
| |
|--------------- |
Attributes | ||||
| |
| |
| |
|--------- |
Workaround | |||
| |
| |
| | |||||
| |
| |
|--------------- |
DeniedSigner | ||||
| |
| |
|--------- |
Attributes | ||||
| |
| |
| |
|------- |
SignerId | |||
| |
| |
| | |||||
| |
| |
|--------- |
ExceptAllowRule | ||||
| |
| |
|------- |
Attributes | ||||
| |
|---------- |
FileRulesRef |
|------- |
AllowRuleId | |||
| |
|--------------- |
Atributes | |||||
| |
| |
|--------- |
Workaround | ||||
| |
FileRuleRef | ||||||
| |
|--------------- |
Atributes | |||||
| |
| |
|--------- |
Workaround | ||||
| |
| | ||||||
| |
|--------------- |
FileRuleRef | |||||
| |
|--------- |
RuleId | |||||
| |
|
|
|
|
| ||
|---------- |
AppIDTags | ||||||
|---------- |
Attributes | ||||||
| |
|--------------- |
EnforceDLL | |||||
| | |||||||
|---------- |
AppIDTag | ||||||
|--------------- |
Attributes | ||||||
|--------- |
Key | ||||||
|--------- |
Value | ||||||
*1 = Required |
SigningScenarios Elements and Attributes
Element Names |
Nested Elements |
Attribute Name |
Description |
---|---|---|---|
SigningScenarios |
ID |
A unique identifier for the signing scenario. | |
FriendlyName |
Helps in easily identifying and managing the signing scenario. | ||
InheritedScenarios |
Allows the signing scenario to inherit rules and settings from other defined scenarios, promoting reuse and consistency. | ||
MinimumHashAlgorithm |
Ensures that only cryptographic hashes meeting the specified algorithm criteria are considered valid. | ||
Value |
Required and defines the specific context or condition under which the signing scenario applies. | ||
ProductSigners, TestSigners, |
AllowedSigners |
WorkAround |
Provides flexibility in handling specific scenarios or exceptions that may not be directly addressed by the standard schema definitions, allowing for customized solutions to unique challenges. |
AllowedSigner |
SignerId |
Each signer can be distinctly recognized and referenced within the ACfB policy, allowing for precise control over which signers are trusted or denied. | |
AllowedSigner/ExceptDenyRule |
DenyRuleId |
Used in the ExceptDenyRule element to reference a specific deny rule, making the allow rule conditional based on the deny rule. | |
DeniedSigners |
WorkAround |
Provides flexibility in handling specific scenarios or exceptions that may not be directly addressed by the standard schema definitions, allowing for customized solutions to unique challenges. | |
DeniedSigner |
SignerId |
Used in the AllowedSigner and DeniedSigner elements to distinctly recognize and reference each signer. | |
DeniedSigner/ExceptAllowRule |
AllowRuleId |
Specification of the AllowRuleId. | |
FileRulesRef |
Workaround |
Provides flexibility in handling specific scenarios or exceptions that may not be directly addressed by the standard schema definitions, allowing for customized solutions to unique challenges. | |
FileRuleRef |
RuleId |
Specifies the ID of the file rule. | |
AppIDTags |
EnforceDLL |
If enabled ensures that only trusted DLLs are allowed to load. | |
AddIDTag |
Key |
Specifies the key for the application ID tag. | |
Value |
Specifies the value for the application ID tag. |
CiSigners
<CiSigners> are signers that ConfigCI asks CI to trust for all builds, including retail builds.
Normally CiSigners is empty or only includes production signers. For enterprise ConfigCI policy, you may need to include enterprise signers. Just make sure it is understood that CiSigners will be trusted by CI for ALL builds.
CiSigners | |||
|------ |
CiSigner *1 | ||
|------ |
Attribute | ||
|------ |
SignerId | ||
*1 = Required |
Element Names |
Attribute Names |
Description |
---|---|---|
CiSigners |
A collection of CiSigner elements. | |
CiSigner |
SignerId |
To distinctly recognize and reference each signer within the ACfB policy. <cisigner /> |
CiSigners Elements and Attributes
<!-- Other policy elements here -->
<CiSigners>
<CiSigner SignerId="ID_SIGNER_STORE"/>
</CiSigners>
<!-- Other policy elements here -->
The <Settings> sub-element is used to define various configuration settings for the policy. These settings can include options such as enabling or disabling specific features, setting enforcement levels, and other parameters that control the behavior of the policy. By configuring <Settings>, organizations can customize the policy to meet their specific security requirements and operational needs. This helps in ensuring that the policy is applied in a manner that aligns with the organization's security objectives and operational practices.
Settings | ||||
|----- |
Setting | |||
|----- |
Attribute | |||
| |
|----- |
Provider *1 | ||
| |
|----- |
Key *1 | ||
| |
|----- |
ValueName *1 | ||
| | ||||
|----- |
Value | |||
|----- |
SettingValueType *1 | |||
|------------ |
BooleanType | |||
|------------ |
DWordType | |||
|------------ |
xs:hexBinary | |||
|------------ |
xs:string | |||
*1 = Required |
Settings, Elements, Attributes and SettingValueType
Element Names |
Attribute Names |
Description |
---|---|---|
Settings |
Collection of Setting(s). | |
Setting |
Provider |
Specifies the source or context of the setting. Required |
Key |
Defines the category or type of information the setting pertains to. Required | |
ValueName |
Specifies the name of the specific value being set. Required | |
Setting/Value/SettingValueType Required |
BooleanType |
Represents a Boolean value, which can be either true or false. |
DWordType |
Represents a double word (32-bit unsigned integer) value. | |
xs:hexBinary |
Represents binary data encoded as hexadecimal. | |
xs:string |
Represents a sequence of characters. |
<!-- Other policy elements here -->
<Settings>
<Setting Provider="AllHostIds" Key="{0468C085-CA5B-11D0-AF08-00609797F0E0}" ValueName="EnterpriseDefinedClsId">
<Value>
<Boolean>true</Boolean>
</Value>
</Setting>
<Setting Provider="PolicyInfo" Key="Information" ValueName="Name">
<Value>
<String>DefaultMicrosoftEnforced</String>
</Value>
</Setting>
<Setting Provider="PolicyInfo" Key="Information" ValueName="Id">
<Value>
<String>022422</String>
</Value>
<!-- Other policy elements here -->
EKUs
The <EKUs> sub-element is used to define the Extended Key Usage (EKU) attributes for certificates. EKUs specify the purposes for which the certificate's public key can be used, such as code signing, server authentication, and client authentication. By specifying EKUs, organizations can ensure that certificates are only used for their intended purposes, enhancing security and trust in digital communications.
EKUs | |||
|---- |
EKU | ||
|---- |
Attributes | ||
|------ |
ID *1 | ||
|------ |
Value *1 | ||
|------ |
FriendlyName | ||
*1 = Required |
EKUs Elements and Attributes
Element Names |
Attribute Names |
Description |
---|---|---|
EKUs |
Collection of EKU(s) | |
EKU |
ID |
A unique identifier for the Extended Key Usage. Required |
Value |
Specifies the value of the EKU in hexBinary form. Required | |
FriendlyName |
An optional user-friendly name for the EKU. |
<!-- Other policy elements here -->
<EKUs>
<EKU ID="ID_EKU_STORE" FriendlyName="Windows Store EKU - 1.3.6.1.4.1.311.76.3.1 Windows Store" Value="010a2b0601040182374c0301"/>
</EKUs>
<!-- Other policy elements here -->
UpdatePolicySigners
The <UpdatePolicySigners> sub-element is used to define the code signing certificates that are trusted for updating policy files. This ensures that only authorized entities can make changes to the policy, enhancing the security and integrity of the system. By specifying trusted signers, organizations can prevent unauthorized modifications and maintain control over policy updates.
updatepolicysigners | |||
|--------- |
updatepolicysigner | ||
|--------- |
Attribute | ||
|----- |
SignerId |
UpdatePolicySigner Elements and Attributes
Element Names |
Attribute Names |
Description |
---|---|---|
UpdatePolicySigners |
Collection of UpdatePolicySigner(s) | |
UpdatePolicySigner |
SignerId |
A unique identifier for the signer. This attribute ensures that each signer authorized to update the ACfB policy can be distinctly recognized and referenced, allowing for precise control over which signers are trusted to make policy updates. |
<!-- Other policy elements here -->
<UpdatePolicySigners>
<UpdatePolicySigner>
<SignerId>Example SignerId</SignerId>
</UpdatePolicySigner>
</UpdatePolicySigners>
<!-- Other policy elements here -->
The <HvciOptions> sub-element is used to define the Hypervisor-protected Code Integrity (HVCI) settings. Hypervisor-Protected Code Integrity (HVCI) leverages virtualization-based security (VBS) to ensure that only trusted code runs in kernel mode, providing an additional layer of protection against malware and other threats. HVCI uses the Windows hypervisor to create an isolated virtual environment that becomes the root of trust for the operating system. This isolated environment ensures that kernel mode code integrity checks are performed within a secure context, preventing unauthorized code from executing. This helps in preventing unauthorized code from executing, thereby maintaining the integrity and security of the operating environment.
HVCIOptions
Element Name |
Description |
HVCIOptions |
A friendly name for the HVCI option. |
The <HvciOptions> element expects a numeric value that represents the specific configuration settings. Here’s a detailed explanation:
Possible Values for HvciOptions
- Enabled (Value: 1): Turns on HVCI, ensuring that only trusted code can run at the hypervisor level.
- Strict (Value: 2): Enforces stricter code integrity checks, providing an additional layer of security.
- DebugMode (Value: 4): Enables debugging features for HVCI, useful for development and troubleshooting.
- DisableAllowed (Value: 8): Allows HVCI to be disabled by the user outside of the Code Integrity policy enablement method.
These values can be combined using bitwise OR operations to enable multiple settings simultaneously.
<!-- Other policy elements here -->
<HvciOptions>2</HvciOptions>
<!-- Other policy elements here -->
Macros
A collection of macro definitions that can be used throughout the policy. Macros allow for text substitution, making it easier to manage and update policy configurations by using predefined values. Each macro is defined within a Macro element, which includes an ID and a value. By using macros, administrators can simplify the policy management process and ensure consistency across different policy elements.
Macros | ||||
|----- |
Macro | |||
| |
|----- |
Attributes | ||
| |
| |
|----- |
Id *1 | |
| |
| |
|----- |
Value *1 | |
| |
| | |||
| |
|----- |
Annotations | ||
| |
|------- |
Documentation | ||
| |
|--------- |
(A Macro element defines a text substitution macro that can be used in other elements. Macros are referenced using NMAKE syntax, i.e. $(runtime.windows).) | ||
| |
|--------- |
(Required. The Id for this macro, used in macro references. For example, if the Id for this macro is "runtime.windows", the macro would be referenced as $(runtime.windows).) | ||
| |
|--------- |
(Required. The value that will be substituted for macro references in macro-enabled XML attributes.) | ||
| | ||||
|----- |
UniqueMacroId | |||
|---------------- |
Selector (xpath="ps:Macro") | |||
|---------------- |
Field (xpath="@Id") | |||
*1 = Required |
Macros Elements and Constraints
Element Names |
Attribute Names |
Description |
---|---|---|
Macro | ||
Id |
Used in macro references, allowing the macro to be called by its ID in other elements, ensuring consistency and ease of management. Required | |
Value |
Specifies the text to be substituted for macro references. This ensures that the defined value is consistently used wherever the macro is referenced, simplifying updates and maintenance. Required | |
“Macros” Constraints UniqueMacroId |
Specifies the unique constraint's name, which in this case is UniqueMacroId. It ensures that each macro ID within the Macros element is unique, preventing duplication. | |
Selector |
Defines the XPath expression used to select the elements to which the unique constraint applies. In this case, it selects the Macro elements within the Macros element. | |
Field |
Specifies the field within the selected elements that must be unique. Here, it ensures that the Id attribute of each Macro element is unique within the Macros element. |
SupplementalPolicySigners
The <SupplementalPolicySigners> element defines a collection of signers that are trusted to sign supplemental policies. Supplemental policies are additional policies that extend or modify the base policy, allowing for more granular and flexible control over application execution. The <SupplementalPolicySigners> element ensures that only authorized entities can create or update these supplemental policies, maintaining the integrity and security of the overall policy framework
SupplementalPolicySigners | |||
|---------------- |
SupplementalPolicySigner | ||
|---------------- |
Attributes | ||
|------- |
SignerId *1 | ||
*1 = Required |
SupplementalPolicySigners Elements and Attributes
Element Names |
Attribute Names |
Description |
---|---|---|
SupplementalPolicySigner |
Collection of Collection of SupplementalPolicySigner(s) | |
SignerId |
A unique identifier for the signer. Ensures that each signer authorized to sign supplemental policies can be distinctly recognized and referenced, allowing for precise control over which signers are trusted to create or update supplemental policies Required |
Schema Definition (CiPolicy.xsd - 1/27/2025) and location
The current schema definition can be found on a Windows 11 device at:
- C:\Windows\schemas\CodeIntegrity\cipolicy.xsd
ACfB Example Policy locations
On Windows 11, ACfB example policies are saved in the following locations:
DefaultWindows_*.xml:
- %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies\DefaultWindows_*.xml
- %ProgramFiles%\WindowsApps\Microsoft.AppControl.WDACWizard*\DefaultWindows_Audit.xml
AllowMicrosoft.xml:
- %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies\AllowMicrosoft.xml
- %ProgramFiles%\WindowsApps\Microsoft.AppControl.WDACWizard*\AllowMicrosoft.xml
AllowAll.xml:
- %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies\AllowAll.xml
AllowAll_EnableHVCI.xml:
- %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies\AllowAll_EnableHVCI.xml
DenyAllAudit.xml:
- %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies\DenyAllAudit.xml
SmartAppControl.xml:
- %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies\SmartAppControl.xml
These example policies can be used as a starting point to create custom policies for your organization's needs.
By implementing a well-structured and ordered schema, organizations can create a secure and efficient environment, much like how Raven's schema keeps her safe and happy in our backyard.
Updated Mar 18, 2025
Version 1.0paulberg
Microsoft
Joined October 30, 2017
Core Infrastructure and Security Blog
Follow this blog board to get notified when there's new activity