Saturday, August 20, 2011

Carbon Black

I was recently afforded an opportunity to download and install the Carbon Black (Cb) standalone server; for testing purposes, I installed it on a Windows 7 host system, and got it up and running right away. 

If you're not aware, Cb is a small sensor that you can load on a Windows system, and it monitors executables being launched.   When a new process is started, information about that process is monitored by the sensor, and sent to the server for correlation and presentation.  The server can be maintained by the Kyrus guys, or it can be maintained within your infrastructure.  If you choose to maintain the server yourself, that's fine...it just means that you're going to need to have someone work with the tool, get familiar with it, and monitor it.

Getting Cb set up is easy.  The process of generating a license and getting the necessary sensor from the guys at Kyrus was simple, straightforward, and very quick.  From there, I rolled out the first sensor to a Windows XP VM that I set up as a guest on the Windows 7 host system via VMPlayer.  Shortly after installing the sensor on the target system, I began seeing events populating the dashboard, just like what I saw in the demo I attended in July.  I even began doing things on the system that one might expect to see being done during the recon phase of an incident, such as running some native tools to start mapping the network just a bit.  My "infrastructure" is a bit limited, but I got to see the Cb functionality first hand.

It's clear that a great deal of thought and effort has gone into the creating Cb, as well as structuring the interface, which is accessible via a browser.  I found that the interface and functionality is far more intuitive that other, similar tools I've seen, and in very short order, I was able to narrow down the information I wanted, based on my experience as an incident responder.

That's another thing I like about Cb...I can use the experience I've developed as an incident responder to get timely answers, and I don't have to learn someone else's framework or methodology.  For example, I look at the dashboard and see a "suspicious" process...in this case, I'd run "ipconfig /all" on the XP VM system...and all I have to do is click on an icon to see the parent process (in this case, cmd.exe).  I could also see loaded modules and files that had been modified.  I could even get a copy of the new executable that was 'seen' by the sensor.  Future enhancements to the sensor include monitoring of network connections and Registry keys.

All of this is very reminiscent of the demo...consider a "normal" incident involving a browser drive-by or some phishing attack against an employee.  Having Cb installed before an incident is the key, as it would allow a responder to very quickly navigate through the interface and once a suspicious process is located (based on a time hack, process name, or in the near future, network connection...), the responder can quickly identify the parent process or any child processes.  So why is this so special?  Well, most times for me, as a responder, I don't get called until after an incident occurs...which means processes have long since run and exited, and there may even have been efforts to clean up (ie, files deleted, etc.).  However, with Cb, there would still be a history of process execution, copies of the EXEs, etc.  In the case of July's demo, there were three stages to the attack, the first two of which launched and exited once their work was complete.  Further, of the three EXEs, AV detection of each was spotty, at best.

Having something like Cb deployed in your environment before an incident occurs is really the best way to approach not just using tools like this, but incident response in general.  In addition, Cb has a range of other uses...just ask the Kyrus guys for their case studies and stories, particularly the one about the CIO who used Cb to save thousands of dollars on Office licenses, based on actual, hard data (Deming, anyone?).

Cb is also a valuable tool to deploy during an incident...it's like sending out a bunch of lightweight little LP/OPs (listening or observation posts) to cast a wide net for data collection and correlation.  Under normal conditions, responders need to start taking systems down or performing live acquisitions, and then start analyzing those acquisitions, along with log files, network captures, etc., in order to begin scoping the incident and identify other systems that need to be acquired and analyzed.  Deploying Cb could (depending upon the type of incident) provide more information in a quicker manner, and require fewer resources (ie, fewer analysts/responders to send on-site, pay for travel, lodging, etc.), and reduce the overall impact on your infrastructure.  Deploying Cb in conjunction with F-Response would REALLY up your game to a whole new level.

Carbon Black is a tool that should be in your arsenal, as it changes the dynamics of incident response, in favor of the targets and responders, and takes away a lot of the advantages currently enjoyed by intruders.  If you have an infrastructure of any size, you should be calling the Kyrus guys.  It's not just large infrastructures that are being targeted...don't believe me?  Spend a rainy Sunday reading through Brian Krebs' blog, and then, if you can stop crying, look me straight in the eye and tell me sincerely that you're below the bad guy's radar.

In my experience as a responder, when a call came in, we'd start collecting information, not only about the incident, but we'd also have to get information from the customer that we'd use to populate the contract, so we'd have a couple of things going on in parallel.  Even so, it would still take us some time to get on-site (6 hrs, sometimes out to 3 or more days...), and then we'd have to start collecting data.  Even though we'd asked for network device and firewall logs to be collected, in some cases, it was only as a result of the incident itself that the customer found out that, "hey, wait a minute, what do you mean we aren't logging on the firewall (or web server)?"  I've had only one instance where I showed up and some data had actually been collected...in every other instance, when an incident occurred, the customer was completely unprepared and we didn't start collecting data until someone got on-site. 

Think about that, as well as any other incidents you may have encountered, for just a moment.  Now, imagine what it would be like if the customer who called you already had a contract and a relationship in place, and you'd helped them install Cb.  With the contract already set up, that's one thing you don't have to deal with...and with Cb rolled out, data is already being collected.  So, while they're on the phone, you can begin to assist them, or you could VPN into their infrastructure and access the Cb server yourself.  If a team needs to be deployed to assist, then you're already collecting information (if you have F-Response rolled out or the local IT staff has the training, memory and images may also be collected) even before the responders are able to get airline tickets!

Cb is like Burger King for IR...have it your way!

10 comments:

Anonymous said...

The big issue with Carbon black is you have to upload your data to a remote server that Kyrus controls. This not only provides a security risk, but it is simply a very poor idea. I read that it is encrypted and only the correct accounts can get access to it, but honestly in the days of HBGary and Anonymous compromising anyone they desire, this simply places your organization at risk. Until they fix this, CB is a cool concept, but not anything I would use on a real case due to their business model.

Keydet89 said...

Anonymous,

...you have to upload your data to a remote server that Kyrus controls.

What data are you referring to? If you're referring to the actual log data, what about ...I installed it on a Windows 7 host system...?

None of the data I was looking at was on any server or system owned by Kyrus.

McClintock said...

I'm also curious what data is actually sent to them. I really don't see myself using anything but the standalone server version. Can it work on a non-internet connected network? Do you know when they're adding registry and network connection information?

Keydet89 said...

McClintock,

I'm also curious what data is actually sent to them.

I don't follow your question...if you're having the sensors send data to Kyrus (or any other off-site location for that matter) then the data being monitored is what is sent. In this case, it's the executable, loaded modules, etc.

I really don't see myself using anything but the standalone server version. Can it work on a non-internet connected network?

Again, I don't really follow. A standalone server on your infrastructure doesn't require an Internet connected network...I can still get data on the server without having the systems connected to the Internet.

Do you know when they're adding registry and network connection information?

No, I don't, sorry.

Anonymous said...

First of all, I am quite surprised to see you endorse this commercial product so much. Based on your responses, you clearly are discussing setting up a server internally to view the data which is their paid version.

Their "free" version, requires you to send the data to Kyrus servers. It is apparent either you were not aware of this or you haven't used their free version of the product. Clearly, there are some privacy concerns by using their free version of the product.

Not slamming this post but I want to make sure that it is done with the right intentions. To help answer this, a key question would be: Are you benefiting in any way from pushing the sales of the product? Could you benefit in anyway from CB being sold?

Keydet89 said...

I am quite surprised to see you endorse this commercial product so much.

Why? It works, it works very well, and if folks had it, it would really make their (and my) work SO much more efficient.

Based on your responses, you clearly are discussing setting up a server internally to view the data which is their paid version.

Yes, I'm not hiding that at all. However, regardless of which version you're using, the same data will be seen in the server.

Also, I wouldn't suggest poo-poo'ing the paid version until you give the Kyrus guys a call and see what the pricing model looks like.

It is apparent either you were not aware of this or you haven't used their free version of the product.

Very interesting assumptions...I'm not sure where these are coming from. I'm completely aware of this, however.

Clearly, there are some privacy concerns by using their free version of the product.

I'm sure there are...but the issue of having someone else monitoring the data is the same as any other managed security service...in fact, I would suggest that given the data that is sent to Kyrus, even less so that a more traditional SOC.

Are you benefiting in any way from pushing the sales of the product? Could you benefit in anyway from CB being sold?

A very interesting set of questions from someone who refuses to add their name or any other identifying information to their comments. I don't see why it matters, but the answer to both questions is "it depends". I would benefit from the sales of this product if an organization purchased and deployed it, and then I were called to respond to an incident and could have access to the log data.

Aside from that, do I gain or benefit from endorsing it? Only in that you're reading the post and thinking about it enough to comment. Beyond that, no, I do not receive an remuneration for my comments. In fact, at the demo in July, I did not partake in any of the snacks or beer provided.

I sincerely hope that helps. I do find it very interesting though that someone who refuses to identify him or herself has so much interest in the reasons for me commenting, and so little apparent interest in what I'm commenting on...

jimmy_weg said...

Harlan, I don't know why you dignified Anonymous' comments with any response, let alone one that more than adequately addressed his unsupported remarks. Frankly, I would block all anonymous replies, as it smply provides the cowardly and uniformed a soapbox; a soapbox that they hide behind as opposed to standing upon. Your blog was informative, well reasoned, and should be a starting point for those with opposing veiws or truly knowledgable practitioners to provide valid criticism so that we all can learn.

Keydet89 said...

Jimmy,

Thanks. I thought that there were some valid issues to point out in Anonymous's post.

One was the issue of privacy...the assumption is clearly that if you're sending anything to Kyrus, your privacy is being violated somehow. Nothing could be further from the truth...after all, if you're sending your monitored data to Kyrus, where is the issue of privacy?

In addition, there's the question of what is being sent. Cb monitors execution events and paths, and what gets sent is some of the information from the EProcess block, and the executable itself. No raw contents of virtual memory are apparently sent...so if a system on your infrastructure gets hit by a browser drive-by, the parent process would be the browser, and child process information would appear in the logs, but NOT browser history, passwords from form fields, etc.

Then there's the issue of the free version vs the for-pay version. So what? Just because there's a fee associated with something, is that necessarily a bad thing? And before someone starts making comments about free vs for-fee, at least do a little research and find out what that fee or pricing model is...

...I want to make sure that it is done with the right intentions. Fine...go do your own research and testing. I mean, really...what makes your intentions the right ones?

Besides, I recognize the rhetoric...it's a signature, like a tattoo, a hat or a pair of shoes someone wears all the time.

McClintock said...

@Harlan,
Ah I get it now. Only the free version sends data to Kyrus. The standalone version is truly standalone. I was thinking their standalone version of CB was similar to Secunia's "standalone" server that still has to be connected to the internet to work.

If there enterprise standalone version really is 24/yr per computer then that's awesome. Who wouldn't get it for that price. I watched some of their recent videos and it seems pretty good.

Hopefully their network connection reporting includes DNS too.

Keydet89 said...

McClintock,

I don't have any information regarding pricing, free or otherwise, sorry.