Authorize reputable apps with the Intelligent Security Graph (ISG)

App Control can be difficult to implement in organizations that don't deploy and manage applications through an IT-managed system. In such environments, users can acquire the applications they want to use for work, making it hard to build an effective App Control policy.

To reduce end-user friction and helpdesk calls, you can set App Control for Business to automatically allow applications that Microsoft's Intelligent Security Graph (ISG) recognizes as having known good reputation. The ISG option helps organizations begin to implement App Control even when the organization has limited control over their app ecosystem. To learn more about the ISG, see the Security section in Major services and features in Microsoft Graph.

How does App Control work with the ISG?

The ISG isn't a "list" of apps. Rather, it uses the same vast security intelligence and machine learning analytics that power Microsoft Defender SmartScreen and Microsoft Defender Antivirus to help classify applications as having "known good", "known bad", or "unknown" reputation. This cloud-based AI is based on trillions of signals collected from Windows endpoints and other data sources, and processed every 24 hours. As a result, the decision from the cloud can change.

App Control only checks the ISG for binaries that aren't explicitly allowed or denied by your policy, and that weren't installed by a managed installer. When such a binary runs on a system with App Control enabled with the ISG option, App Control will check the file's reputation by sending its hash and signing information to the cloud. If the ISG reports that the file has a "known good" reputation, then the file will be allowed to run. Otherwise, it will be blocked by App Control.

If the file with good reputation is an application installer, the installer's reputation will pass along to any files that it writes to disk. This way, all the files needed to install and run an app inherit the positive reputation data from the installer. Files authorized based on the installer's reputation will have the $KERNEL.SMARTLOCKER.ORIGINCLAIM kernel Extended Attribute (EA) written to the file.

App Control periodically requeries the reputation data on a file. Additionally, enterprises can specify that any cached reputation results are flushed on reboot by using the Enabled:Invalidate EAs on Reboot option.

Understand origin claims

When managed installer or the Intelligent Security Graph (ISG) authorizes a file, App Control records why that file is trusted by adding a kernel-managed extended attribute (EA) to the file. Known as its origin claim, the EA captures the source of the file's reputation, so that Code Integrity can later evaluate the file without re-checking its original source. The origin claim is called $KERNEL.SMARTLOCKER.ORIGINCLAIM. An origin claim records what wrote the file, indicates that the process that wrote the file was trusted as either a managed installer or based on reputation, and whether the trust was inherited from a parent. You can use the fsutil command to view this EA on a file. For the exact steps, see Using fsutil to query extended attributes for managed installer (MI).

• Managed installer origin: The file was written by a process that your policy trusts as a managed installer (for example, a deployment tool like Microsoft Configuration Manager or Microsoft Intune). This trust is based on how the file arrived on the device, not on the file's properties, signatures, or hash value. For more information, see Security considerations with managed installer.
• Intelligent Security Graph (ISG) origin: The file received a favorable reputation response or it inherited the favorable reputation response from the parent process which was an installer that created the file. These reputation responses come from Microsoft's security intelligence services called the Intelligent Security Graph. Reputation is tied to the specific file, so if the file is modified, the reputation no longer applies and the origin claim is no longer honored. If that happens, the file is reevaluated by App Control the next time it runs. For more information, see Authorize reputable apps with the Intelligent Security Graph (ISG).

Origin claims propagate down a process tree. When a managed installer runs, or when an installer receives a trusted-installer reputation response from the ISG, it passes equivalent trust to the files it writes and to the child processes it starts. That trust continues to flow down the live process tree through child processes, their children, and later generations, so that all the files an installer needs to install and run an app are authorized.

Propagation isn't unlimited. It ends when the trusted process tree breaks, including in these cases:

• The original installer process ends. Trust is scoped to the lifetime of the trusted process tree. A file created after the original managed installer or ISG-trusted installer process exits doesn't inherit its origin claim. In the extended-attribute data, such a file is marked as a "child of a child" and isn't authorized to run on its own—it must be allowed by other means, such as an explicit rule, managed installer origin, or ISG reputation.
• A process crosses a security boundary. If a process is spawned under a different user or security context, the parent process can pass along its origin claim to the child process. If it doesn't, then the process tree is broken and any files created by the child process or its children aren't authorized based on the initial process's origin claim.

After the process tree breaks for any reason, any files created must be authorized by other means, including if they run as a managed installer or receive a trusted-installer reputation response from the ISG.

Configuring ISG authorization for your App Control policy

Setting up the ISG is easy using any management solution you wish. Configuring the ISG option involves these basic steps:

• Ensure that the Enabled:Intelligent Security Graph authorization option is set in the App Control policy XML
• Enable the necessary services to allow App Control to use the ISG correctly on the client

Ensure that the ISG option is set in the App Control policy XML

To allow apps and binaries based on the Microsoft Intelligent Security Graph, the Enabled:Intelligent Security Graph authorization option must be specified in the App Control policy. This step can be done with the Set-RuleOption cmdlet. You should also set the Enabled:Invalidate EAs on Reboot option so that ISG results are verified again after each reboot. The ISG option isn't recommended for devices that don't have regular access to the internet. The following example shows both options set.

<Rules>
    <Rule>
      <Option>Enabled:Unsigned System Integrity Policy</Option>
    </Rule>
    <Rule>
      <Option>Enabled:Advanced Boot Options Menu</Option>
    </Rule>
    <Rule>
      <Option>Required:Enforce Store Applications</Option>
    </Rule>
    <Rule>
      <Option>Enabled:UMCI</Option>
    </Rule>
    <Rule>
      <Option>Enabled:Managed Installer</Option>
    </Rule>
    <Rule>
      <Option>Enabled:Intelligent Security Graph Authorization</Option>
    </Rule>
    <Rule>
      <Option>Enabled:Invalidate EAs on Reboot</Option>
    </Rule>
</Rules>

Enable the necessary services to allow App Control to use the ISG correctly on the client

In order for the heuristics used by the ISG to function properly, other components in Windows must be enabled. You can configure these components by running the appidtel executable in c:\windows\system32.

appidtel start

This step isn't required for App Control policies deployed over MDM, as the CSP will enable the necessary components. This step is also not required when the ISG is configured using Configuration Manager's App Control integration.

Security considerations with the ISG option

Since the ISG is a heuristic-based mechanism, it doesn't provide the same security guarantees as explicit allow or deny rules. It's best suited where users operate with standard user rights and where a security monitoring solution like Microsoft Defender for Endpoint is used.

Rule precedence with ISG

When you combine the ISG option with explicit allow or deny rules, App Control evaluates the explicit rules before it uses reputation. An explicit deny rule always takes precedence over ISG reputation, so App Control blocks a denied file regardless of its reputation. An explicit allow rule also takes precedence over reputation. The ISG only influences files that no explicit allow or deny rule covers.

You can create any static rule in your policy that reliably can authorize boot-critical binaries, because Code Integrity evaluates it locally from the policy during boot with no cloud or runtime dependency available. This includes AllowAll rules, wildcard FileName='*' rules, signer rules, file attribute rules, and hash rules. Never rely on the ISG or a managed installer to authorize boot-critical files: their decisions depend on cloud reputation or kernel extended attributes that aren't always available early in the boot path, which can block those files or cause boot or service-start timeouts.

If you use an AllowAll template with explicit deny rules, the explicit deny rules still take precedence. For more information, see Create an App Control policy to block drivers or apps. For more information about managed installer and ISG behavior, see Managed installer and ISG technical reference and troubleshooting guide.

Processes running with kernel privileges can circumvent App Control by setting the ISG extended file attribute to make a binary appear to have known good reputation.

Also, since the ISG option passes along reputation from app installers to the binaries they write to disk, it can over-authorize files in some cases. For example, if the installer launches the app upon completion, App Control also allows any files the app writes during that first run.

Known limitations with using the ISG

Since the ISG only allows binaries that are "known good", there are cases where the ISG may be unable to predict whether legitimate software is safe to run. If that happens, the software will be blocked by App Control. In this case, you need to allow the software with a rule in your App Control policy, deploy a catalog signed by a certificate trusted in the App Control policy, or install the software from an App Control managed installer. Installers or applications that dynamically create binaries at runtime, and self-updating applications, may exhibit this symptom.

Packaged apps aren't supported with the ISG and will need to be separately authorized in your App Control policy. Since packaged apps have a strong app identity and must be signed, it's straightforward to authorize packaged apps with your App Control policy.

The ISG doesn't authorize kernel mode drivers. The App Control policy must have rules that allow the necessary drivers to run.