The Strength Of Signed App Control Policies

Before delving into the topic, let’s first clarify the role of an Administrator within the operating system. An Administrator is a user with the highest level of access to the OS, possessing the authority to make system-wide changes that impact all users.

Administrators are responsible for managing system security, modifying security settings, installing software and hardware, and accessing all files on the computer.

Notably, an Administrator can seamlessly elevate privileges to SYSTEM, Managed Installer, or other access levels due to the absence of security boundaries between them. Equivalent roles in other operating systems include Root, SuperUser, and similar designations.

Implementing an Application Control policy requires Administrator privileges. Without these elevated permissions, it is impossible to deploy, remove, or alter any App Control policies.

Deploying an unsigned App Control policy leaves it vulnerable to removal or modification by any user with Administrator privileges.

But what if you need your App Control policy to be so tamper-resistant that even an Administrator cannot alter or remove it? This is where signing comes into play.

App Control policies, authored in XML format, must be converted into .cip binary files before deployment. To enhance security and ensure tamper resistance, the .cip file can be signed with a code signing certificate prior to deployment.

This signing process effectively fortifies the policy, making it impervious to unauthorized modifications or removal.

Signed App Control policies offer a formidable defense, they significantly hinder adversaries from achieving initial access to the system, a critical juncture in any attack.

The importance of preventing initial access cannot be overstated. Once an attacker gains Administrator privileges, they inherently acquire the capability to manipulate the system.

For example, although a signed App Control policy cannot be removed, an attacker with Administrator rights could still deploy a new policy designed to block essential Endpoint Detection and Response (EDR) sensors or data collection agents.

This could include tools like Azure Monitor Agent for Microsoft Sentinel or Microsoft Defender for Endpoint, effectively disrupting telemetry and impeding security monitoring.

Despite this potential for disruption, attackers are still constrained by the integrity of signed policies, which prohibit unauthorized programs from executing.

Consequently, engineering robust defenses to prevent initial access, particularly access that elevates privileges to Administrator, remains paramount in securing modern systems.

System Behavior After Deploying A Signed Application Control Policy

After a signed App Control policy .cip is copied to the EFI partition as part of the deployment process, we can see in System Information that Application Control User-Mode is being enforced and when you try to install an application not permitted by the deployed policy, it will be successfully blocked.

At this point, a system restart is required. Since UEFI Secure Boot is enabled, the anti-tampering protection of the Signed App Control policy is activated, safeguarding the policy from any modifications.

Deploying a Signed App Control policy without restarting is the same as deploying Unsigned policies, because the Signed policy can be easily removed just like an Unsigned policy. So always make sure you restart at least once after deploying a Signed App Control policy.

For more information click here.