Best Practices: Endpoint Standard Blocking & Isolation Rules

Introduction

As with many security products, VMware Carbon Black Endpoint Standard (formerly known as CB Defense) allows for granular control of its behavior. The major ways Endpoint Standard accomplishes this is through the use of two types of rules: Permission Rules and Blocking & Isolation rules. These rule sets are configurable on a per-policy basis. Given that endpoints are assigned to policies this allows for your environment to be granularly managed. This whitepaper covers Blocking & Isolation Rules while another whitepaper covers Permission Rules.

This whitepaper is intended to relay practical knowledge that you can apply in your day-to-day usage of VMware Carbon Black Endpoint Standard.

Cyber Security Methodology

Cyber security isn’t a “set it and forget it” kind of thing. Cyber security is a constant iterative process. With that in mind, it is imperative that Carbon Black Cloud administrators and analysts occasionally review rules for adequacy and effectiveness. With a changing customer environment and the changing threat landscape, rules of any type should not be considered static.

Standards Used in this Resource

Throughout this whitepaper different typeface standards will be utilized as follows:

Underlined text is intended to call out items an administrator will see verbatim within the Carbon Black Cloud console.

Monospaced text is intended to call out items where text entry is needed or highlighted, such as entering file paths.
Highlighted text is intended to call out best practice or very important information that an administrator should keep in mind going forward. re Carbon Black Cloud Endpoint Standard – Blocking & Isolation Rules Best Practice

Key Concepts

One of the key concepts of the VMware Carbon Black Cloud platform is understanding an executable’s reputation. Where did it come from? How often has this file been seen across customer installations? How does it behave? Does it change frequently? These attributes (and many more) allow VMware Carbon Black to assign a reputation to file. Keep in mind that a reputation is not static – it can change over time for better or for worse and there are options for a Carbon Black Cloud administrator to override the reputation VMware Carbon Black assigns to an executable. The following table describes the various reputation levels a file may have: Carbon Black Cloud Endpoint Standard – Blocking & Isolation Rules Best Practice

Priority	Reputation	Description
1	Ignore	Highest priority. Files have full permissions to run without observance. Applies to Allow, Allow & Log, and Bypass rules.
2	Company White	Hashes manually added into Company allowlist.​
3	Company Black	Hashes manually added into Company denylist.​
4	Trusted White	Known good by Carbon Black from the cloud or/and local scanner.​
5	Known Malware	Known bad by Carbon Black from the cloud or/and local scanner.​
6	Suspect/Heuristic Malware	Suspect malware detected by Carbon Black, but not necessarily malicious.​
7	Adware/PUP Malware	Adware and Potential Unwanted Programs detected by Carbon Black.​
8	Local White	Any of the following conditions: pre-existing file, allowlisted by IT Tools, allowlisted by Certificate.​
9	Common White	Any of the following conditions: hash not on any known good or bad list AND file is signed, hash previously analyzed AND not on any known good or bad lists.​
10	Not Listed / Adaptive White	Cloud: hash not previously seen and local scanner: no known bad​
11	Unknown	Lowest priority. Sensor observes file drop, but does not yet have reputation from the cloud or local scanner.​

An executable’s reputation is a core component to Blocking & Isolation Rules

Policies are set to allow, deny, or terminate based upon an executable’s reputation from the table above. Surely an organization does not want to allow files with an “Unknown” reputation to perform actions such as code injection behavior. However, there may be software with legitimate purposes with a higher reputation that should be allowed to perform code injection, memory scraping, or other actions.

IT Tools or Certificate allow-listing can be used to manually override low reputation files

If a process is generating files with UNKNOWN or NOT_LISTED reputation, the Carbon Black Cloud administrator has a level of trust in the files, the process generating those files can be added to the IT Tools list. This will raise the reputation of the UNKNOWN or NOT_LISTED files generated by that executable to the ADAPTIVE_WHITE_LIST status automatically.

For example, Google Chrome is frequently updated. Due to where an endpoint may be on the Internet (Content Distribution Networks etc) compared to the Carbon Black Cloud, an endpoint could see a Google Chrome update before the Carbon Black Cloud. At that point, the Carbon Black Cloud would have very little reputation data about these new files, even though they come from Google – a source where a high level of trust can be placed in the legitimacy of the files.

Depending upon policy settings, a customer may have all UNKNOWN files set to terminate or deny, which could cause a business impact if Google Chrome itself is marked with an UNKNOWN reputation.

To alleviate this block situation, a Carbon Black Cloud Administrator could add the Google Chrome updater process to the IT Tools allow list which would automatically elevate any files the Google Chrome updater lays on disk to the ADAPTIVE_WHITE_LIST status. This should prevent a policy from blocking the execution of Google Chrome in the future. As the Carbon Black cloud gained additional visibility into these files, the reputation could be further elevated.

Alternatively, the certificate used to sign Google Chrome could be added to the certificate allow list which achieves the same goal of elevating reputation due to known trust in the source of the executables.

File reputation levels higher in the table override those below it

IT Tools or Certificate allow-listing is a highly recommended method to alleviate blocks of known-good software. The reason for this is that should a piece of software be compromised VMware Carbon Black could designate those file hashes as SUSPECT_MALWARE or KNOWN_MALWARE. Because these reputations are higher in the list than ADAPTIVE_WHITE_LIST the new reputations would override the ADAPTIVE_WHITE_LIST reputation and prevent that malicious software from execution.

The same could be said for the TRUSTED_WHITE_LIST status. A piece of software may be set by VMware Carbon Black to this status that has no legitimate business use for a customer. It could be given a COMPANY_BLACK_LIST reputation by adding it to the Company Banned List. It would then be blocked due to COMPANY_BLACK_LIST having a higher priority reputation than TRUSTED_WHITE_LIST.

Use Hash-based allow-listing cautiously

Observe that the COMPANY_WHITE_LIST status is at the top of the reputation table. (The IGNORE status is only used by VMware Carbon Black and is not customer usable.) A file with COMPANY_WHITE_LIST reputation overrides every reputation below it, including KNOWN_MALWARE. It is for this reason that a Carbon Black Cloud administrator must be judicious when adding a hash to the allow-list.

Permission Rules Override Blocking & Isolation Rules

While this whitepaper does not cover Permission Rules (see separate whitepaper on that topic) it is important to understand that Blocking & Isolation rules are overridden by Permission Rules. This gives an administrator the flexibility to explicitly allow executables that may normally be blocked by a Blocking & Isolation Rule.

Terminate Process versus Deny Operation

Within policies a Carbon Black Cloud administrator can set what the Carbon Black Cloud sensor will do when it encounters a policy violation – terminate the process or simply deny operation. It is important to understand that setting a behavior to “Terminate Process” can have an impact on users. “Terminate Process” will do just that – ungraciously terminate an offending process. If a policy was set to Terminate process if winword.exe invoked a command interpreter a user could potentially lose work. Instead, by setting to Deny operation the command interpreter would be stopped from opening and the user’s work would not be lost.

However, there are actions where Terminate process is desired. For instance, when performing ransomware-like behavior, the only option for a policy action available is Terminate process. Ransomware is such a serious issue and can deploy so quickly Terminate process is really the only viable option.

If a hash added to the allow-list is later determined to be malicious and a KNOWN_MALWARE or SUSPECT_MALWARE reputation assigned by VMware Carbon Black, the file will still execute as its COMPANY_WHITE_LIST reputation overrides those below.

Permission Rules Override Blocking & Isolation Rules

While this whitepaper does not cover Permission Rules (see separate resource on that topic) it is important to understand that Blocking & Isolation rules are overridden by Permission Rules. This gives an administrator the flexibility to explicitly allow executables that may normally be blocked by a Blocking & Isolation Rule.

It is important to understand that a poorly crafted, too permissive, permission rule could allow malware or ransomware to execute successfully, even though a Blocking & Isolation rule would normally stop it. ng & Isolatik Cloud Endpoint Standard – Blocking & Isolation Rules Best Practice

Best Practices

Test Rule

Using the Test rule button to run a query against your organization’s most recent 30 days of data to see if this rule change would cause alerts and blocks. If there are no events, typically this means the rule is safe to implement. (e.g. If there were no ransomware events.) If the Test rule function shows potential blocks, an analyst will need to determine if blocks were legitimate or false positive. False positive blocks may need a Permission rule in order to p revent legitimate software from being blocked. (See associated white paper.)

It is advised to pilot major changes to rules within a new policy on a subset of endpoints to ensure that if there are unexpe cted blocks they will not affect large populations of users. The timeline for testing the new rule and deploying to the remaining endpoints is at the CB Cloud Administrator’s discretion.

Move Like Endpoints

It is advisable to move endpoints that are similar together from a less strict (Standard) policy to a more strict (Advanced) policy. The reason for this is that by moving to a more strict policy there is the potential to generate alerts and blocks. By limiting the alerts and blocks to similar systems, the tuning of policy Blocking & Isolation and Permissions rules is more straightforward.

Do not use “Application(s) at path” as a ban list

When malware is found in an environment, it can be tempting to implement a Blocking & Isolation rule as follows:

However, this will only terminate the process at this specific path. File path obfuscation is a very common defense evasion practice and the above rule would not cover c:\path\to\this\malware.exe, for instance. A wildcard rule (**\malware.exe) could account for this however file name obfuscation is also very common and the above malware.exe could very easily be renamed something completely random on every endpoint, rendering this kind of rule useless.

Instead, best practice is to ban this executable by file hash and ensure the appropriate rule is set in your policy:

This rule would block the banned file irrespective of where it is located on disk and what the file is named. Referring to our reputation table above, recall that a file placed on the company banned list only has one reputation with higher priority – the company allow list. ck Cloud Endpoint Standard – Blocking & Isolation Rules Best Practice

Policy Enhancements

As stated earlier cyber security is not “set it and forget it”. Cyber security is a constant iterative process. It is recommended to follow Good, Better, Best for a policy enhancement strategy, and frequently check TAU-TIN (Threat Analysis Unit - Threat Intelligence Notifications) research.

TAU- TIN Research

VMware Carbon Black Threat Analysis Unit (TAU) analyzes new and emerging malware, threats, and trends and provides in-depth summaries in the form of a Threat Intelligence Notification (TIN).

We recommend following new TAU-TINs released to help increase the overall security beyond the default standard and advanced policies and ensure you have the right rules to prevent against new threats or at the very least detect the attack

The TAU TIN reports are integrated in the Carbon Black Cloud dashboard and built-in queries are provided for detecting new and emerging threats within the environment. Click full report to read the full analysis in the VMware Carbon Black User Exchange.

Each report includes a customer protection section, with recommended Blocking and Isolation rules to protect against that threat. Use the test rule functionality within policies and suggested queries in the Investigate tab to baseline the environment events and determine if the suggested rules are safe to apply or will it cause blocks on legitimate processes. As always, test new rules on a pilot policy prior to applying to all endpoints.