Kernel Exclusions for Security Products

Products

• Carbon Black App Control (formerly Cb Protection)

Issue/Introduction

What steps should be taken to properly exclude other products in the Security Stack such as McAfee, Symantec, Tanium, Windows Defender or otherwise?

Environment

• App Control Agent: All Supported Versions
• App Control Console: All Supported Versions

Resolution

Reasons To Avoid Kernel Exclusions

Kernel Exclusions not only impact the Security Posture of the Agent, but they also are not a 1:1 performance improvement. In some instances Kernel Exclusions could negatively impact performance or cause unexpected blocks. Typically this happens due to overuse, improper targeting or when files are ignored during write operations and some other tracked process attempts to execute those files.

Example One: Performance Impacts

1. The Agent has been given a Kernel Exclusion on some process related to the security stack.
   • This Kernel Exclusion instructs the Agent to ignore file modifications and executions by that process.
2. Later, that process writes files that are executed by an unrelated process that is tracked (ex cmd.exe or cscript.exe) and the security stack relies on some response or output after the execution.
3. Because the Kernel Exclusion prevented the Agent from issuing a Local Approval on the new file(s), they are then blocked by cmd.exe or cscript.exe
   • Operations are stalled to analyze these "new" files on execution and performance impacts are observed due to the stalling.
   • The security stack (Defender) now encounters an error due to the enforcement and either crashes or otherwise fails to properly operate.

Example Two: Unexpected Blocks

1. The Agent has been given a Kernel Exclusion on some process related to the security stack.
   • This Kernel Exclusion instructs the Agent to ignore all operations by some process.
2. Later, that process quarantines some file in the Agent's directory due to a false positive/routine operation.
   • The Kernel Exclusion instructed the Agent to ignore the process.
   • The Agent honored this, and allowed the quarantine to take place despite Tamper Protection being enabled.
3. This causes the Agent to crash or otherwise become inoperable/corrupted.
   • Because the Kernel Exclusion was applied to all Agents in the environment, all Agents may need to be repaired or reinstalled now.

 

Kernel Exclusions should be always be a "last resort" and only when recommended/as provided by Support. Typically they're most commonly used when an interoperability issue exists and no other option is available. 

In most circumstances the following workflow will prevent most interoperability issues from the Agent and reduce file analysis:

• Initial install via Microsoft SCCM (or similar)
• Updates handled through some pre-approval method, if not SCCM, examples:
  • Updaters and Rapid Configs have some options already.
  • File Creation Control (Approve) to help fill in the gaps.
  • Publisher Approvals if endpoints can communicate with remote Certificate Authorities.
• Avoid overly broad/non-specific Performance Optimization Rules
  • Similar to some Kernel Exclusions, this will instruct the Agent to ignore file modifications.
  • Ignoring file modifications of executable files is not recommended.

 

Obtaining Specific Kernel Exclusions

Due to a variety of environmental differences, a specific set of logs and details will be required to validate the paths/operations necessary:

1. Verify all items in the Security Stack have all Agent Exclusions entered.
2. Collect specific details about the reason(s) for the Security Stack
   • Ex: specifics on performance impact, interoperability issues or otherwise
3. Collect Agent Historical logs from an endpoint with the Agent and the related application installed.
4. Open a case with Support and provide the requested information and logs.