Best Practices: Endpoint Standard Permission 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 resource covers Permission Rules while another resource covers Blocking & Isolation Rules.
This resource 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. Cloud Endpoint Standard - Permission Rules Best Practices
Permission Rules
All security products have within its core product design certain operational assumptions about how a device should behave. There are times, however, when operational reality is out of sync with operational design. This is where permission rules enter and give an administrator the ability to tune the behavior of the security product.
Examples where permission rules are often required:
– Ensuring other security tools do not have their functionality impeded
– Tools used for administration of endpoints such as SCCM, BigFix, PowerShell etc.
– Custom or niche software VMware Carbon Black has little reputation information on due to low prevalence in customer environments
When a permission rule is required, the goal of the permission rule’s structure is similar to the least-privilege access model: Only allow just enough to get the job done. No more, no less. This is accomplished by allowing behavior for a specific or wildcarded executable path. The danger with permission rules is that if they are too permissive, attackers can exploit them.
Permission Rules Override Blocking & Isolation Rules
Visit the previous resource to review Blocking & Isolation rules. It is important to be aware that Permission Rules override Blocking & Isolation rules.
Blocking & Isolation rules generally function based upon an executable’s reputation and the associated behavior it is trying to accomplish. Within a policy a Blocking & Isolation rule may be set such that if an Unknown application or process Runs or is running the CB Cloud sensor will Terminate process. This is a very common out of the box configuration. An organization typically only wants to allow trusted software to run. Unknown software should be stopped.
Let’s take as an example Acme Inc which is a manufacturing company. Acme has custom in-house created software used on a manufacturing line. Being custom software, VMware Carbon Black will have no knowledge about this executable and it would have an unknown reputation. The out of the box blocking rule above will terminate the process and could cause a business impact to manufacturing.
By adding a specific permission rule that allows this executable to do its job, an administrator can override the default blocking behavior for just this “unknown” software while still protecting the environment against other software with unknown reputation.
Types of Permission Rules
If there is one section of this resource that an administrator pays close attention to it’s this one. For the specified file path - explicit or wildcarded (more on wildcards later) - permission rules have 3 major categories, some with granularity:
Allow
An Allow permission is the simplest of the 3 categories. It simply allows the behavior enabled with no logging. An administrator can allow the following kinds of behavior:
- Runs or is running – Simply allow the executable (or wildcarded path) to execute
- Communicates over the network – Allow the executable to open and use network connections
- Scrapes memory of another process – Allow memory scraping
- Executes code from memory – Allow code execution from memory
- Invokes a command interpreter – Allow the process to call another process classified as a command interpreter. For instance, PowerShell, cmd.exe, python, wscript, cscript, bash, etc.
- Performs ransomware-like behavior – Ideally this is never allowed for obvious reasons, however some utilities that manage disk partitioning, mounting/unmounting, user-land file modifications etc. may appear to be ransomware-like to the CB Cloud sensor. Use this allowance with exceptional rarity.
- Executes a fileless script – Allow script execution from in-memory.
- Injects code or modifies memory of another process – Commonly called “process hollowing.”
Clearly, some of the behavior above is more benign than others. For this reason, an administrator should determine the level of risk posed by an executable that requires a permission rule. If the executable requires permissions that are higher risk (such as invoking command interpreters, executing fileless scripts etc.) an administrator may want to consider an Allow & Log permission instead.
Allow & Log
An Allow & Log permission rule affords all the same allowances as the Allow permission rule above. However, any allowed behavior is logged within the CB Cloud console. “Trust but verify” is the theme here. When an administrator requires a permission rule with more risky behavior or for tools that can be utilized for both good and evil, an Allow & Log rule is advisable.
Bypass
There may be cases where Allow or Allow & Log is insufficient. The fact that the CB Cloud sensor is hooking into the process may be enough to disrupt it and cause interoperability problems. Other security software is a common situation requiring a bypass rule. There are 2 bypass rule types:
Performs any API operation
Commonly this is called an “API Bypass,” and it will allow certain functions but still protect against more nefarious behavior such as ransomware. An API Bypass is always the first type of bypass rule to test.
An API Bypass will allow:
- Scrapes memory of another process
- Executes code from memory
- Injects code or modifies memory of another process – Writing to a disk’s primary boot record
An API Bypass will still allow for network and file visibility:
- Communicates over the network
- Runs or is running
- Invokes a command interpreter – Executes a fileless script
Performs any operation
Commonly this is called a “Full Bypass” permission rule and should be used as sparingly as possible. For the specified path (explicit or wildcarded) the sensor is effectively disabled. There is no prevention, no visibility, no logging. As a result, a Full Bypass rule is the permission rule of last resort.
To be fully explicit:
A poorly crafted Full Bypass permission rule could allow malware or ransomware to execute successfully.
It is also important to note that a child process can inherit full bypass if its parent process is within the scope of a full bypass permission rule. VMware Carbon Black Cloud Endpoint Standard - Permission Rules Best Practices
File Paths and Wildcards
For each of the types of permissions (Allow, Allow & Log, Bypass) a file path must be specified. Because Permission Rules are allowing behavior outside of the norm, best practice is to specify the most specific file path possible.
For example, c:\program files\my_product\widget.exe is an explicit file path. There may be cases, however, when wildcards are needed. Wildcards can be used as follows:
|
Wildcard |
Description |
Example |
|
* |
Matches 0 or more consecutive characters up to a single subdirectory level |
All files within my_product would receive the associated permission. (Allow, Allow & Log, Bypass) |
|
** |
Matches a partial path across all subdirectory levels and is recursive. Can be used in both leading and trailing file paths |
All files and all recursive subdirectories within my_product would receive the associated permission. (Allow, Allow & Log, Bypass)
Anywhere on in any file path where |
|
? |
Matches 0 or 1 character in that position |
Matches any files in for MS Visual Studio version 10-19.
Matches the specified file path on any disk. |
The wildcards in the table above can also be combined. For example:
c:\program files\Microsoft Visual Studio 1?.0\* would receive the permission rule (Allow, Allow & Log, Bypass) for any MS Visual Studio version 10-19 within the single directory.
Environment Variables
What is not often discussed is that environment variables can also be used in file paths on Permission Rules. If the environment variable is defined on the local endpoint, the CB Cloud sensor will resolve it. This can be helpful if an administrator knows locations such as the Windows or Program Files directories could be located on disks that are not C.
Instead of necessitating a ?:\Windows\system32\... wildcard which would open up a file path for any disk an administrator could instead specify %SYSTEM%\... in the file path which would instead resolve to the specific file path on that local endpoint. Standard - Permission Rules Best Practices
Permission Rule Creation Steps, Examples & Best Practices
The first indication that a permission rule may be required is if a piece of software is being blocked from executing in an alert. Via the alert triage process an analyst would determine the endpoint(s) the block occurred on, the file paths of the affected executables, and which policy performed the block.
An administrator would then set about crafting a permission rule that would allow the given executable the ability to run but nothing else. But, where to start?
Above, the administrator has specified an exact file path and an Allow & Log permission. For this executable, that may be all that is required in order to prevent further blocks. Depending, the executable may also need network communication, command interpreters etc. Allow / Allow & Log is always the first type of permission an administrator should try.
Note the Test rule link next to each of the permissions. An administrator can utilize this test to get an indication of whether the allowance would allow the desired behavior for the specified file path.
on Black Cloud Endpoint Standard - Permission Rules Best Practices
If, for instance, this executable is now able to run, however other executables within this file path are subsequently blocke d – for example widget.exe has child processes within the same directory – a wildcard may be in order. For instance:
The rule as written above would allow any .exe file within c:\program files\my_product to run and communicate over the network. There may be other files within the file path such as DLLs. They could be specifically listed or further wildcarded:
A more permissive wildcard could be used:
However, this would allow any file within c:\program files\my_product to execute with the given permission. If there are many files within this directory that would need specific allowances, this may be desired.
d Endpoint Standard - Permission Rules Best Practices
In our example, should the above Allow or Allow & Log permissions still cause interoperability issues with our executables, the ne xt step would be to move to an API Bypass:
Given the necessity in our example to move up to a Bypass rule, best practice is to be as explicit as possible with file paths. Avoid wildcards in Bypass rules
whenever possible.
Should the CB Cloud sensor still cause interoperability issues on an API Bypass, a Full Bypass would be the permission rule o f last resort:
n Black Cloud Endpoint Standard - Permission Rules Best Practices
Examples of Poor Rules
The following are all real-world examples of bypass rules that have been present in customer environments:
- **\powershell.exe – Full Bypass
- %userprofile%\** - Full Bypass
- **\Advance_* - Full Bypass
- C:\Inetpub\logs\logfiles\w3svc** - Full Bypass
Think about why these are dangerous!
Conclusion
Permission Rules are a method for tuning the behavior of the CB Cloud sensor on a per-policy basis. It is important to remember that a permission rule can resolve interoperability issues however a too-permissive rule will allow daylight for attackers to operate. The goal of the CB Cloud administrator is to give executables that require a permission rule just enough permission to alleviate the interoperability issue while leaving visibility into what the executable is doing such that an attacker cannot take advantage.
Best Practices
- Permission rule file paths should be as explicit as possible
- Understand the impact of using wildcards, think about their use from an attacker’s perspective.
- Minimize the use of trailing ** wildcards as they are recursive!
- In order, test Allow/Allow & Log, then API Bypass, and only as a last resort Full Bypass