Carbon Black & VMware Announce Expanded Partnership to Secure the Software-Defined Data Center (SDDC) Learn more

Embracing Your Organization’s Inner “Low Enforcement”

Introducing .NET Client for Carbon Black API bit9 carbon black logo
Hex_Dots_40pct
August 24, 2015 / Dave Brown

Bit9 in high enforcement is an outstanding component of the security stack. There is no better security posture than having the executions of all unapproved binaries blocked by default. But it is not always practical for all organizations to put all of their endpoints into high enforcement, which is why we also offer a low-enforcement option.

Perhaps a company’s culture is too “open” or its security staff too limited to accommodate the number of approval requests. Or maybe the SOC has made a deliberate choice to allow attacks on a certain subset of endpoints in order to strengthen their ability to respond to future attacks. Some companies will simply never be able to get 100 percent of their machines into high enforcement. And that’s OK!

Even for organizations that do put all of their endpoints into high enforcement, it doesn’t happen overnight. In the best of circumstances, there is a period when they have to define trust—where at least some of their endpoints will remain in low enforcement. This is not a bad thing!

On a very real level, the differences between low enforcement and high enforcement could be summed up as the latter’s ability to block unapproved executables. All of the other prevention measures in Bit9 are just as valid in low enforcement as they are in high.

Let’s review:

Active Banning

When a binary is identified as malicious, a ban can be enforced across all policies, providing you with immediate protection against that malware across your entire Bit9 environment, regardless of how many machines are in high or low enforcement. Moreover, by using event rules (described below), bans can be applied automatically on the basis of detection events or other conditions.

Device Control

Device control can be enforced on any policy whether in high or low enforcement. This will, by default, prevent writes to, and executions from, any unapproved devices. As with files, devices can be approved individually (even using serial numbers) or in groups, either globally or by policy.

Memory Rules

Memory rules are also independent of enforcement level and can be applied to all machines or by policy. Memory rules can be used to prevent (or allow) modifications—or even access—to specified processes. This enables users to prevent the disabling of security-related processes such as antivirus or known malicious behaviors such as cross-process injections or dynamic executions.

Registry Rules

Even in low enforcement, Bit9 can be used to prevent (or allow) changes to specified keys in Windows registries. In fact, Bit9 customers have been able to use registry rules to protect themselves against CryptoLocker—even in low enforcement—by blocking specific registry changes that were known to be caused by the malware.

File-Integrity Monitoring/Control (FIM/FIC)

If there are files or folders in your network that need to be protected against change by unauthorized users/processes, Bit9 can provide protection in the form of a file-integrity control rule. Internal or external users who are not authorized will not be able to make changes to protected files or folders, regardless of the enforcement level of either the users or the machines on which the files reside. This is a common requirement for organizations required to be compliant with the likes of PCI DSS, HIPAA, Sarbanes Oxley (SOX), etc.

Other Custom Rules and Event Rules

Other prevention measures can be invoked via either custom rules or event rules. Custom rules can allow, approve, block or report on the basis of filename, path, installer, user, or parent process. Event rules expand on these capabilities by adding a slew of event properties (including threat feeds and indicators), file properties, and process properties to the list of conditions and an expanded list of possible actions. These rules can add a significant level of automation to your prevention measures across your entire Bit9 environment, regardless of enforcement level.

Integrations

Bit9’s RESTful API provides an open platform providing integrations (many already built in to the product) with a wide array of security products such as SIEMs, network tools, as well as other endpoint tools. Because of its open APIs, it’s highly likely that Bit9 will integrate with the products already in your security stack (assuming they, too, are open), providing you even more value from the investments you already have made. Perhaps the best part is that these integrations are just as effective in low enforcement!

Threat Intelligence Cloud

Being able to correlate dynamic threat intelligence with your endpoint data is a significant part of Bit9’s value. Not only does Bit9 assign a trust and threat rating to every known file in your environment but, by monitoring file-related activity on all of your endpoints, it can detect (and alert on) suspicious activities on your network. And again, this capability works just as well in low enforcement.

Bonus: Visibility!

Low enforcement provides some very real benefits around visibility. Some organizations with very mature security programs, for instance, have implemented Bit9 in low enforcement to they can view the entire scope of a possible attack (versus simply banning from the start.)

Organizations considering Bit9 should not be put off by the perceived challenge of getting all of their endpoints into high enforcement. Even if it that goal is never fully attained, Bit9 in low enforcement still provides much of the same protection value.

 

TAGS: banning / bit9 / Carbon Black / high enforcement / low enforcement / Prevention / protection

Related Posts