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_
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_
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_
The same could be said for the TRUSTED_
Use Hash-based allow-listing cautiously
Observe that the COMPANY_
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_
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.