I was reading Richard Bejtlich’s blog today on Computer Security Incident Response Teams and he quoted the following from Gartner’s report “How to Build a Computer Security Incident Response Team”:

“A competent and adequately resourced CSIRT is an important part of an organization’s information security program. Many organizations either have nothing in place or follow inconsistent procedures. In many organizations, the goal is to recover from an incident and get back up and running with minimal attention being paid to evidence collection, analysis or postmortem reporting. Over the long term, this approach results in more security events, not fewer, as the organization is unable to discern the root causes of incidents and incorporate these lessons learned into improvements in infrastructure and process management.”

We wholeheartedly agree.  In fact, this is EXACTLY why we released the Verizon Enterprise Risk and Incident Sharing framework(pdf) for you to use.  Our hope is that the VERIS framework(1) and our Data Breach Investigations Report(2) is just what you need to mature incident analysis and post-incident reporting.   (more…)

by Dave Hylender and Christopher Porter

A week or so ago, we posted a quick heads up about the UK Security Breach Investigations Report. Although several others have been released since then (Mandiant and Trustwave), this one is particularly interesting for comparison to our DBIR because it focuses on breaches in the UK (Note – the DBIR caseload has a US-based majority but a sizeable (growing) number of European (and other global) breaches). Although we often hear comments that suggest that breaches in the US are radically different and thus not comparable to those elsewhere, this report seems to suggest otherwise. The following is a high-level comparison of DBIR findings to the 7Safe report from the UK.

As an FYI, the scope of the 7Safe report is 62 cases over a time period of the last 18 months.

(more…)

In the last day or so, we’ve seen several articles and web chatter on RAM scraping malware as described in our 2009 Data Breach Investigations Supplemental Report. Some of this discussion seems to be heading in a bit of a sensationalist direction. Others suggest that some of the information we present is inaccurate. We’d like to head this off with some quick Q&A for clarification.

Q: Why do we say RAM scrapers are “a fairly new form of malware”?
A: Because their occurrence is fairly new among breach investigations in our caseload. We aren’t suggesting the concept itself is new.

Q: Is this the end of the Internet or data security as we know it?
A: No, of course not.

(more…)

Verizon Business released the 2009 Data Breach Investigations Supplemental Report today. As you may know, the supplemental report addresses requests, issues, and questions that arise from our readers regarding the annual Data Breach Investigations Report (April, 2009). This year’s model is a catalogue of attacks that occurred most frequently in the data set used for the 2009 DBIR.

It is, in large part, a divergence from previous reports in that it provides a more in-depth and wider view of a data breach, and is not solely statistics driven. The aim of the report is to provide both technical personnel and managers with a one-stop compendium of pertinent details on the widespread threats within our caseload. It is our hope that readers can directly utilize the information provided to prepare for, detect and, ideally, prevent these types of attacks.

(more…)

Despite the release of numerous tools intended to make things easier for forensic investigators, there’s also development on the other side of the law. I’ve personally given multiple presentations on the topic of anti-forensics at various conferences and have also attended my fair share as well. No matter where you go, it always seems to be a very polarized discussion.

You have the folks on one side of the room that go to the presentations seemingly just to heckle the speakers. They claim that anti-forensics doesn’t exist, and that it’s a myth propagated by the companies that do investigations. Let’s just say for argument’s sake they’re right. Can anybody out there prove that it’s not happening?

Now let’s look at it from the other side. Do we have cases where we have confirmed that anti-forensics was in use? Yes – and we’re not talking about a meager amount either. Based on just our metrics, we see anti-forensics is involved in more than a third of our caseload. And considering that, by its very nature, it’s designed to never be found, we can reasonably assume that the actual presence of anti-forensics is probably much higher.

On what side of the room are you? Any experiences you wish to share regarding AF?

One of the most common questions/criticisms we get regarding the Data Breach Investigations Report is the lack of data on financial losses experienced by organizations in our sample. We can understand the frustration. There are, however, several reasons that the report does not contain such information:

1) A breach investigation focuses on the collection of evidence related to who did it, how, when, what was compromised, etc. Analyzing and quantifying financial losses to the victim organization is simply not what we’re paid to do. Although we do occasionally gather information relevant to the impact of a breach, we do not gather near enough pieces to complete the puzzle. Nor are we on the ground long enough after the breach to truly study the long-term consequences.

2) While we could include the bits and pieces that we collect on losses, we made a decision at the very beginning not to do so. One of the aspects of the DBIR that we (and we hope many others) like is that, from cover to cover, it is filled with objective, credible, factual information. Since we do not collect data of that caliber on losses during an investigation, we do not feel it fits with the rest of the report.

That said, we’re not blind. We realize that breach details along with a credible account of financial losses is the “Holy Grail” of our field. I won’t give away too much now, but let’s just say that we’re actively working on something that may please the masses.

Get it free of charge with no sign-up requirements here.

Creating the single-year sequel to a four-year report on over 500 breach investigations is a daunting prospect. While it would be impossible to trump the sheer scope of the original 2008 DBIR, we’ve sought to preserve its strengths and introduce some key enhancements for 2009. Here is some of what you can expect in this release:

First, you’ll notice the report is quite a bit larger than last year. Hopefully it’s worth the extra disk space (which isn’t saying much given current prices) and/or toner (which *is* saying a lot given current prices). Rather than platitudes and pitches, we’ve worked to fill those extra pages with real substance. Everyone loves data.

(more…)

I’ve been reading reviews of the 2009 DBIR today and I gotta say – I’m surprised at the lack of snarling and teeth gnashing over our stats on who’s behind all these breaches and lost records. Last year, we received no shortage of comments (positive and negative) about insiders causing the fewest breaches. I won’t go into all the various reasons behind our findings here since that is done in the report. I would like to say that I was surprised at the disproportionality of Fig 8.

(more…)

by Chris Porter

The relative difficulty of attacks leading to data compromise is an excellent indicator of both the current threat environment and the state of modern security programs. After each forensic investigation, our VzB investigators assess the attack and classify the difficulty into the following categories: None, Low, Moderate and High.

There are several rather interesting finds within the data this year. One is that attackers used simple methods of attack in over 50% of the breaches. The basic conclusion from this is that attackers still do not have to work very hard to get the data they desire.

Another interesting find in this data set is related to a new metric that we have added. This year the attacks have also been analyzed for the number of records breached. If you look at the highly difficult attacks in this data set, they are responsible for 95% of the 285 million records breached.

I also found it interesting that when you look at an attack from end to end, the difficult part typically occurs after the criminal penetrates the perimeter. Most highly difficult attacks were given that classification because of the elaborate nature of the malware used to capture data rather than the hack used to get in the door. The latter is usually involves more run-of-the-mill techniques.

What did you find interesting? Please share in the comments section below.

In our report we found it helpful to further break down the standard classifications of attacks, opportunistic and targeted, into three categories:
Random opportunistic – victim randomly selected
Directed opportunistic – victim selected, but only because they were known to have a particular exploitable weakness
Fully targeted – victim was chosen and then attack planned

In 2008, fully targeted attacks rose to a 5 year high, and accounted for 90% of total records compromised in 2008 (by comparison, it was 14% in last years model).  We have said in the past that if criminals (particularly organized crime with its vast resources) take aim at your organization and attack you with enough intensity over a long enough time span it is likely that they will breach your perimeter.  The caseload for this report seems to go a long way toward proving this to be true.
At the same time, the majority of attacks were not fully targeted, but were of the more opportunistic variety.  The old adage of the deer and the bear applies here.  When being chased by a bear you don’t have to be the fastest deer, you just have to be faster than the one next to you.  In other words, set up your defenses in such a way as to minimize your chances of being the target for these kinds of attacks.  This can be attempted in a variety of ways.  One important element is to retain as little data as possible in the first place. If you don’t absolutely have to have if for business reasons, or if your legal department doesn’t insist on it (good luck), then get rid of it.   Also, know where your critical information resides at all times, and who has access to it.  You may feel that you don’t have the time or resources to do this.  Relax, if you don’t find it the criminals will do it for you for free.

Figure 25 in the 2009 Data Breach Investigations Report (p30) shows that for the big computer crime cases in 2008, the vast majority involved data from servers (Online Data 94% of cases).  In only 17% of all cases were End-User Systems involved in any part of a target.  In only about 1% of cases (one case out of 90, Figure 16) were End-User Systems part of the attack pathway.  The very same data, when viewed by the percent of records lost, shows that 99.9% of records were taken from servers, while just 0.01% of the records were taken from End-User systems.  Wow!

(more…)

To my mind, this section included several areas of interest. The sheer number of compromised records we investigated in 2008 is surprising – even to us. Only time will tell how the numbers will stack up in 2009 but we’ve already worked several large cases this year.

One of the things we discussed internally when analyzing the data from 2008 was how useful the “% of records” statistics would be since it was so dominated by a few large breaches (the largest 4 or 5 breaches exceed 90% of all 285 million records). We thought about removing them. We thought about pulling them out and presenting them separately alongside the smaller yet more numerous breaches. In the end, we decided keep everything together and provide distributions, measures of central tendency, etc to describe the data set.

The breakdown of data types shown in Figure 29 of the report was not unexpected and probably not surprising to many. However, I have fielded a huge amount of questions and interest with respect to the discussion around PIN data. In retrospect, it would have been wise to call this out separately and we will do so in the next report. Attacks targeting this type of data were, without a doubt, one the defining developments in the world of cybercrime in 2008. Unfortunately, I feel we will be dealing with it for some time to come.

I am totally fascinated that, as sophisticated as our enterprises are, computer crime follows the same basics as water (seeks the lowest point, leaks from the softest spot) and chains (that break at their weakest link). We chant and rant these sort of ditties endlessly, yet our spending and protection strategies often make security stronger where it is already strong, and ignore, or don’t even look for, the weak spots.

Figure 30 in this year’s study shows that in over half of all cases (and a much higher percent of records lost) the data that was breached involved relatively simple things that took the victim company by complete surprise. In Figure 30 (pg 34), “Unknown Data” was a problem in over 1/3 of cases and about 2/3 of all records lost.

When we get called in to handle a case we typically meet with the IT staff on the first morning to reassure them and to get some basic information so that we can quickly diagnose the issue. Usually someone knows that records were lost, but doesn’t know how. We ask: “Where would records like those be stored and processed??” The staff answers something like “over there on machines A, B, C and D.” We ask if we can put a sniffer on the network among machines A, B, C, and D. When we do, we typically see 95%+ of the traffic moving among these devices, but we often see a small percent of traffic also going to machines “P,Q, R, S, and T.” (more…)

The Time Span of Breach Events section is particularly interesting to me because there is a significant applicability of this sort of information to threat, control, and risk modeling/analysis (I think time-framing is a critical element that many models tend to overlook or minimize the importance of).

So let’s take a quick look at Time Span of Breach Events and what we might do with this information. We’ve broken Time Span of Breach Events into what might be called the four stages of an attack (rather than re-hash their definitions here, I’ll refer you to p 36-37 of the report). They are:

• Pre-Attack Research
• Point of Entry to Compromise
• Compromise to Discovery
• Discovery to Containment

(more…)

Start or join a conversation about the PCI DSS and you’re going to get a broad range of opinions on the subject. It can be a sensitive topic that people tend to get very passionate about.

We were glad to be able to include a section in this year’s report and we hope you are finding the results informative and useful.

We’ve put up this blog post for your opinions on the data and questions concerning the data. You might also want to check out what others have been writing about the PCI information in the DBIR. A couple that I enjoyed:

Anton Chuvakin on his blog >>here<<

and

Martin Mckeay (of the excellent Network Security Podcast fame) on his blog >>here<<.