Endpoint Standard: Approval Mechanisms and Their Use Cases

Issue

What are the different approval mechanisms in Endpoint Standard and when are they used?

Environment

Carbon Black Cloud

Endpoint Standard

Resolution

Hash Approval

Approving a SHA256 hash will assign that file the Company Approved List reputation, which takes priority over all other reputation values. Generally, this is most useful in manually overriding false positives due to a Not Listed or malicious (Known Malware, Suspect Malware, Heuristic, Adware, PUP) reputation being assigned to a known-good file. It can also be used to remediate events where a process is blocked by an “Invokes an untrusted process” rule due to the known-good target child process being assigned an untrusted reputation (Not Listed, Adaptive Approved List, Unknown).

Hash approvals are a global approval mechanism and will apply to all endpoints and policies. As the Company Approved List reputation is based on the SHA256 hash, any update or modification to an approved file that results in a change in SHA2556 hash results in the previous approval no longer applying.

Cert Approval

Approving a certificate assigns all files validly signed with that cert the Local White reputation, which takes priority over untrusted reputations (Not Listed, Adaptive Approved List, Unknown). This makes certificate approvals an effective tool in remediating blocks on multiple known-good files by the same publisher that are assigned an untrusted reputation and are A) blocked after violating Blocking & Isolations rules for “Not listed applications” or B) processes targeting these known-good files are being blocked by an “Invokes an untrusted process” rule.

Cert approvals are a global approval mechanism and will apply to all endpoints and policies. The Local White reputation issued by an approved cert does not take priority over malicious reputations (Known Malware, Suspect Malware, Heuristic, Adware, PUP), meaning false positive blocks on known-good files assigned a malicious reputation cannot be remediated by approving the certificate.

IT Tool

Approving a process as an IT Tool ensures all files written by that process will be assigned the Local White reputation, which takes priority over untrusted reputations (Not Listed, Adaptive Approved List, Unknown). Additionally, files written by an IT Tool will not have analysis or an initial reputation lookup performed as they are being created, making it an effective tool when frequent sensor operations performed on a large number of file writes impact endpoint performance. The IT Tool feature's use case is most often associated with software deployment tools, compilers, and other processes that write a large number of files.

This feature does not alter the reputation of the process specified as an IT Tool, nor does it impact the reputation of child processes that are not written by it. The Local White reputation assigned to written files does not take priority over any malicious reputations (Known Malware, Suspect Malware, Heuristic, Adware, PUP). If files written by an IT Tool are Known Malware, configured policy enforcement rules would act on them after execution.

As an optional setting, “Include all child processes” can be enabled to allow an IT Tool’s child processes to also function as IT Tools themselves. This is useful when an IT Tool creates a child process to delegate file creation to. Adding a process as an IT Tool is a global mechanism which applies to all endpoints and policies.

Permission Rules

While not explicitly an approval mechanism, path-based Permission Rules can be used to resolve block events on known-good, trusted processes by allowing behavior, or bypassing a path entirely. Both Permission and Blocking & Isolation rules are applied per-policy, which is useful for limiting rules to desired endpoints. There are two key pieces of logic to path-based rules.

First, path-based rules do not take into account file reputation of the specified process, including malicious and untrusted reputations. Instead, these rules will allow or disallow the attempted file operation based on behavior and path alone. This means a Permission rule, if used incorrectly, can allow malware to run despite being assigned the Known Malware reputation.

In situations where a hash or cert approval cannot be used to resolve a false positive block (e.g. an unsigned, trusted developer script that gets modified frequently), a path-based Permission rule could be used to allow the desired behavior. Example:

A Permission rule for:
• C:\Dev\Scripts\TrustedDevScript.ps1 > Scrapes memory of another process > Allow

Takes priority over the following Blocking & Isolation rule:
• Not listed applications > Scrapes memory of another process > Deny operation

In this example configuration, TrustedDevScript.ps1 would be allowed to perform memory scraping operations, despite being a Not Listed file. Other files with Not Listed or Adaptive Approved List reputations cannot perform memory scraping operations.

Path-based Blocking & Isolation rules for the “Invokes an untrusted process” operation do consider file reputation, but only of the child process. Any primary process is considered to invoke an untrusted process when the targeted child process is assigned the Not Listed, Adaptive Approved List, or Resolving reputation. Reputation-based rules for the same operation will consider file reputation of both the primary and child processes.

The second key point is Permission rules supersede all Blocking & Isolation rules. In situations where a broad path-based Blocking & Isolation rule is blocking a known-good process, a specific Permission can be created for the desired process and operation. Example:

A Permission rule for:
• C:\Dev\Scripts\TrustedDevScript.ps1 > Scrapes memory of another process > Allow

Takes priority over the following Blocking & Isolation rule:
• **\*.ps1 > Scrapes memory of another process > Deny operation

In this example configuration, the Blocking & Isolation rule is using wildcards to deny memory scraping operations made by any file with a .ps1 extension at any path. This means a hash or cert approval for TrustedDevScript.ps1 would not take priority, even if the script was validly signed and never changed hash, because path-based rules do not take into account file reputation. However, the path-based Permission will allow TrustedDevScript.ps1 to perform memory scraping operations when executed out of C:\Dev\Scripts\, as the Permission takes priority over the Blocking & Isolation rule.