More on Data Breaches

Beware...here's your warning: This post is NOT specifically about Windows incident response or forensic analysis. Okay. There. You've been warned.

Brian Krebs of the SecurityFix blog posted recently that data breaches are more costly than ever. I can't say as I'm surprised...security folks have known for a long time that the cost of cleaning up a mess is much, much more than the cost of finding and fixing the issues before an incident happens (ie, how much does it really cost to put a password on that 'sa' account?). In some ways, this is common sense, but apparently, not "common" enough.

Look at the first sentence of Brian's post: Organizations that experienced a data breach paid an average of $6.6 million last year to rebuild their brand image and retain customers following public disclosures of the incidents...

I think that this makes a couple of key points...

I found a similar article on DarkReading, as well. Both articles reference the Ponemon Institute study, the US Cost of Data Breach Study. A couple excerpts from the articles that I found interesting:

Data breaches experienced by "first timers" are more expensive than those experienced by organizations that have had previous data breaches....

No kidding. You get caught with your pants down (I wish I had a graphic, but hey, this is a PG-13 blog), and that's what happens. You don't know enough about your architecture or infrastructure, about where sensitive data is stored or processed...and then someone intrudes into your network and figures it out...but not for you. For themselves. And takes stuff.

Also, Brian pointed out hard costs associated with breaches, such as hiring forensic analyst and responder firms, setting up call centers, and discounts on future products. These all go beyond the other hard costs, such as notification (estimated now at ~ $100 per record), law suits (don't believe me? Check out this article...), etc.

The fact of the matter is that breaches themselves are far less expensive than the cost of preparation. There's no question...incidents WILL happen. We've seen the surveys, and we've seen this in the media. So why wait for a breach to happen in order to justify spending to prevent or detect security incidents? I mean, seriously...do companies hire employees and wait until someone brings a law suit to start paying them? Do companies offer a product without sales, marketing, maintenance, and some way of billing customers (invoice, collections, etc.)?

So where most organizations are right now is that they're likely sitting at a table with someone who wants to sell them services of some kind that have to do with security. The decision point is the certainty of the purchase order that the sales guy is pushing across the table versus the possibility of a major data breach occurring at some point in the future. I understand this. However, what I do not understand is why organizations that store and process MY sensitive data do not recognize that that possibility or probability is rapidly approaching certainty. If you cannot clearly demonstrate your controls and you have no visibility into your infrastructure, the I would suggest that it's already there.

Despite their experiences, however, most companies still don't plan financially for data breaches.
Now, see this is the part I don't get. It's one thing to look at the Hannafords and the Heartlands, and to think, hey, it won't happen to ME. However, it's another thing entirely for it to happen to you, for you to be informed as to just how vulnerable you really are, and then for you to think, hey, it won't happen to me AGAIN.

The study also does not measure the cost of intellectual property that is lost or stolen as a result of a data breach.

Ugh. How many organizations out there are smuggly grinning ear-to-ear, because they don't store or process "sensitive data", as defined by PCI, NCUA, or any of the abundant state legislation, all while their intellectual property is being siphoned off? "No, we don't have to meet compliance because we're not required to." Well, don't you want to...you know...protect your intellectual property (R&D, manufacturing process specs, new drug/medication design specs, etc.) just because its the RIGHT THING to do? Well, no...where's the ROI in that?

Oh, and since I mentioned Heartland, I simply can't let this pass without mentioning Cory's comments on this recent StoreFrontBackTalk article. To me, as an experienced responder, this is a great example of "denial isn't just a river in Egypt". Yeah, it's also a great example of how these things get wildly miscommunicated through Public Relations or Corporate Communications, and then on to the media, but it also reminds me that folks are more likely to tell their friends, "hey, I got mugged on the way home from work and beat up by the Pittsburgh Steeler's defensive line", when in fact the truth is that a 12 yr old girl took your wallet. Another way to say it is, make the story sound a lot better than it really is...don't let the facts get in the way of a good story.

IR Immediate Actions

As you may remember, in December 2007 I presented at the HTCIA conference in Hong Kong, the first HTCIA conference for this chapter. It was a great conference, and a great opportunity to meet a lot of folks in this field (see the Speaker's page).

While there, I presented on Registry Analysis and Windows Memory Analysis, both of which seemed to be well received. One question came up during discussions of Windows Memory Analysis...during the presentation, I talk about different tools and techniques that are available for extracting the contents of RAM, and also talk about the difference between tools I can use as a private individual and those I can use as a consultant. At one point, someone asked me which tools and techniques I use most often as a consultant...and my response was simply "none of them". The reason for this is that in most all of the responses I've dealt with, the system (or systems) have already been turned off, rebooted, or sufficiently imposed upon by others (AV scans, running multiple tools, etc.) that even if I did, as a consultant, have an option available for collecting the contents of RAM available to me, doing so would be of little benefit to either my analysis, or any information I could provide to the customer.

Part of the issue is that as a consultant, I am extremely limited in the tools I can use to collect the contents of physical memory from a system, not so much due to the availability of a particular tool, but more so due to the license agreement associated with that tool.

However, a bigger issue is that the immediate actions performed by most first responders on-site are to take systems offline, shutdown them down, or "clean" and reboot them prior to any calls for outside assistance being made. While this may be pertinent for business preservation and continuity, it most often has a detrimental impact on any follow-on analysis that may take place.

If there is data leakage due to an intrusion (or this is suspected, or this is just a question that needs to be answered...), then the immediate reaction is (apparently) to shut the system down. This may be pertinent, particularly if there is no incident response plan in place that lets people know what they need to do, and time is required to notify and get approval for follow-on activities (such as calling consultants). This reaction appears to be fairly ingrained, and I'm not suggesting that we change it by saying DO NOT shut systems down. What I am going to suggest is that we modify those immediate actions such that pertinent information is collected from systems before they are shut down.

Wait...what? It looks like what I am saying is, go ahead and shut the systems down, or reboot them, or "clean" them...and I am. This is going to happen anyway. There's nothing I can say or do, either on this blog or as a paid consultant, to change that. In order to change that behavior, there has to be an incident response plan (CSIRP) in place that tells people what to do, and when someone shuts a system off inappropriately or incorrectly, that issue needs to be addressed. The issue is that some kind of overwhelming stimulus needs to be put in place to change this behavior, and until this happens, nothing anyone can say or do is going to change that. So...it's gonna happen anyway, and instead of changing it, let's go ahead and go with it...but throw something else in there along the way.

What can we do? Well, one thing is to put tools on systems (for a list of tools, check out my book) when they are set up, or at least at some point prior to an incident occurring. If you can't put tools and a simple batch file on systems (for whatever reason...the most common of which seems to be, "...we don't know how..."), then issue each admin/responder a CD with tools, and a thumb drive. Then make it a policy within the organization that a batch file (could be a DOS batch file, or WMI script, etc.) be run and the output saved to a thumb drive, shared drive, etc., prior to the system being taken offline.