Bit9, now called Carbon Black (Cb) Protection Enterprise is a utility that will intentionally block any application that has not been authorized to execute on the system. Carbon Black protection is a tool for whitelisting, and allows the creation of rules to control file executions on monitored systems. Stanford University IT is actively working on implementing Carbon black Protection in our environment. This is an additional security tool along with Firewalls and anti-virus applications.
Carbon black works by continuously monitoring all file system activities happening on the server and provides a real-time response and blocks potential threats. We can whitelist applications by creating event rules and custom rules, and in this article we will be elaborating on best practices for creating custom rules, and why and when we need them.
Stanford University uses a distributed model for Bit9, the ability to create event rules is limited to ISO (Information Security Office) (globally) and the Bit9 admins of their distributed groups (like TCG, Technology Consulting Group) who have the ability to create custom rules for their environment. If you expect the rule should be doing what it should do and reduce the workload of a Bit9 admin, make sure that the rules you write are neither too complex nor less complex or too broad or specific. Rules should be designed to reduce the workload on Bit9 admins, and should be relatively simple.
Custom rules are explicit rules you write for file writes/executions. You write custom rules when you want granular control of the rules, when the Global or Local approvals cannot perform finer controls on file write/execution for specific endpoints, users, processes or policies. We must write custom rules in a scenario where things are changing constantly or dynamically. There are certain applications that drop files quickly, or create new DLLs every time an application starts up, and whose names cannot be predicted or they disappear quickly. Dynamic files may have new hashes, so it is best if you create a custom rule to approve that application or file instead of approving that file by hash. Custom rules can also be created when you want certain applications to be run from a network share, from a specific path/process/user, or a group (like the AD logon/logoff scripts). The Execute action option is only available to custom rules, and takes precedence over all the other rules.
For instance, a custom rule that allows a file to execute will override the banning of a file. Custom rules supersede bans and approvals of files. Custom rules supersede any other rules.
The way Cb Protection processes Custom rules is by doing a string comparison between the file name and the specification in the rule. It does not use hash values.
If you wonder why a particular file was approved, it could be due to Approval by File Reputation set by Carbon Black, or approved by Trusted Publisher (manual), or approved by Certificate.
Approving files by hash is not as effective as writing custom rules to approve the kind of activities in your workflows. Custom rules can allow the approval of all software installed by a trusted installer, leaving admins the time to handle less common file activity events manually, in the admin console.