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

Carbon Black 5.1 Demo: Understand How an Attack Started and Then Fix the Problem

Carbon Black 5.1 Understand How an Attack Started and Then Fix the Problem carbon black logo
benweb
April 15, 2015 / Ben Johnson

Data breaches unfold at a maddening pace. Organizations that are able to keep pace with an attack–or even stay ahead of it–are exponentially better at preventing the bad guys from getting out with anything valuable once they’ve gotten in. And that’s the goal, right? Protect the critical information at all costs.

So, how is it that some organizations are able to keep pace with an attack while others quickly fall behind, forced to play catch up and pick up the pieces retroactively?

There’s no major secret. Simply put, the organizations that keep pace are able to see.

Detection and incident response are no longer about calling an emergency number after an attack has occurred. They are about staying on top of your environment and understanding that attackers are going after the most critical assets in your company–the endpoints.

Virtually every major attack you’ve read about it the news during the last year has been the result of a compromised endpoint. The good news? Defenders are adapting. They are coming to realize that visibility–the ability to see everything in their environment before, during and after an attack–is key to staying ahead of an attack, understanding it, and then fixing the problem.

With Carbon Black 5.1, announced today, you will have the ability to see everything executing in your environment to answer such questions as:

• What binaries are being written?
• What processes are making network connections or spawning child processes?
• Who’s saving attachments from email?
• Who’s running outdated software?

Additionally, you will be able to automatically apply the threat intelligence you subscribe to – various domains, IPs, hashes, etc. — to look for behavioral patterns common to attacks, both by malware and by malicious actors. This will enable you to hunt strange behavior and be alerted when that behavior occurs.

Best of all, when you conduct incident response, you can “rewind the tape” to find the root cause. With that information you can figure out how an attack started and then actually fix the problem.

That all sounds great, right? But I know that you want more. You want to do more investigation and more analysis, and while doing so you want to stop the bleeding.

Enter the new features of Carbon Black 5.1:

If you’ve read the Carbon Black 5.0 blog post from January, you know how to respond to the thread you are pulling, conduct your recovery, and then drive further detection.

Today, let’s see how you will be able to do two very cool new things in Carbon Black 5.1: integrate with Microsoft’s Enhanced Mitigation Experience Toolkit (EMET) and ban executables from running.

1 – Microsoft’s Enhanced Mitigation Experience Toolkit (EMET) enables you to harden specific applications. This hardening makes it harder for exploits to work because aspects of the target process are changed, randomized, etc. So, if you apply your configurations properly, you’re immediately in a better spot than if you didn’t have EMET. But one thing we sometimes hear about this free (yes, free) tool is that it isn’t entirely optimized for the enterprise. That’s where Carbon Black 5.1 comes in. Carbon Black can see the configurations you have applied and make that information searchable in our powerful management console.

Remember feedback loops? Well that’s another way to think about it: “I think I’m protected with EMET, but I want to see where I’m actually misconfigured or missing something.”

To give you a concrete example, say you believe all Microsoft Word instances should have EMET enabled. I can easily search for any instances that don’t have the config enabled in Carbon Black:

511

Based on the response, I have instances where EMET is not enabled for Word (winword.exe), but it’s only two instances, and I happen to know why these ran without EMET enabled. However, I may one day have more than just two instances and that concerns me. With Carbon Black, I can create a watchlist (a saved search) and then receive an alert every time this (instance executing without EMET protection) occurs.

(This is similar to other functionalities that Carbon Black has. For example, being alerted when vulnerable java executes. But I digress.)

Ok, so we can see where we have EMET enabled (or maybe more importantly, disabled.) But I want to know when EMET sees stuff. Where are vulnerabilities being mitigated?

EMET alerts get picked up by Carbon Black and are shown in the console. So, not only can you search for these alerts, you can see them in the larger kill chain (and subsequently take action, isolate, and all that fun stuff).

Let’s see an EMET event for WinWord (we see this started from outlook.exe on the left):

512

You can see via this screenshot that the integration is powerful. It provides new capabilities while staying in the same pane of glass you’ve come to love inside Carbon Black. With Carbon Black 5.1 you see the EMET event AND all the typical Carbon Black events you’re used to.

Back to the watchlists, I can easily have a watchlist that just alerts me when EMET mitigates an attack. Simple, right?

513

2 –Banning binaries so they cannot run

In the example below, we see an attack and find some binaries we don’t want to run ever again. Heck, we don’t even need it to be an attack – maybe I want to ban old versions of Acrobat or Java from running (probably the fastest way to improve your posture, by the way.)

Here, we see a tree with a bad binary. I click “BAN” so that no Carbon Black-enabled system will be able to run this executable again:

514

And, of course, there’s a way to manage what hashes are banned:

515

So I can now stop the bleeding with isolation and then, when I decide an executable is worthy of being banned (possibly through collecting more data using live response), I can kill processes and ban the hash so that it cannot execute ever again.

With Carbon Black, it’s all about fast response, effective recovery, and learning root cause to drive detection. Your posture improves with each pass through the incident management lifecycle.

Phew. That was quite a blog post. But I’d humbly say that Carbon Black is quite a solution, which, in 5.1 also includes other cool stuff: our new integration with Cyphort and native memory-dumping as an addition to “Live Response,” among other key features.

One final thing I wanted to touch on is the power of our APIs. Subscribe to events and, based on those events, isolate machines from the network, automatically grab memory, kill processes and talk to other defenses in your environment. Do all of this with small amounts of code and truly be off to the races.

Our most advanced customers and partners are currently doing incredible things with our messaging bus for streaming-based detection. But that’s for another post.

Until then, I hope you’re saving lots of time with Carbon Black 5.1!

TAGS: bit9 / Carbon Black / Carbon Black 5.1 / demo / endpoint security / security

Related Posts