2009 DBIR: Conclusions and recommendations
adminApril 14th, 2009
By Chris Porter
Take care of the low hanging fruit! That seems to be the concluding mantra of analysis of over 600 cases from 2004-2008.
At the conclusion of the original DBIR, we made a number of recommendations based on the findings from the 2004-2007 breach investigations. All of these recommendations are still pertinent to the 2008 caseload, and we have kept an abbreviated version in this year’s report. 2008 Recommendations can be found on pages 26-27 of the 2008 DBIR.
In addition to these “oldies but goodies,” we offer the following new or expanded recommendations based on our analysis of 2008 data. None are revolutionary but they are based on the failings of many organizations. It’s often the ordinary that we neglect (to our harm). Looking back on years of data, we’ve found that the simple things, done consistently and comprehensively, are very effective at keeping companies out of the headlines. Below are the recommendations from the 2009 Data Breach Investigations Report:
• Changing default credentials is key
• Avoid shared credentials
• User Account Review
• Application Testing and Code Review
• Smarter Patch Management Strategies (see previous post on this topic)
• Human Resources Termination Procedures
• Enable Application Logs and Monitor
• Define “Suspicious” and “Anomalous” (then look for whatever “It” is)
What did you find interesting? What conclusions did you draw? What other controls would you recommend based on our findings and/or your own experience? Please share in the comments section below.
Tags: Computer Crime, Cybercrime, Data Breach Report, Data Breaches, Data Compromise, forensics, Information Security
All of these recommendations are reasonable and prudent, but are they really supported by your data?
If you are a financial services company, it may be that nothing is going to help you much at all, except for a complete overhaul of the international payments and credit card systems.
Given the number of targeted and highly difficult attacks you have reported against these entities, and given the fact that no upper bound on the motivaton, skill, and resources of the bad guys has been or can be established, it seems to me that the best one can hope for is to make things a bit more difficult for an attacker than at one’s competitors (low hanging fruit argument).
If you are not a financial services company, then the question for me becomes “Why not play the odds?” Per your report, only 5% of records breached occurred at non-financial sector companies.
So why spend all of the money on expensive security stuff, which, in the final analysis may not and probably will not protect you?
Do you suppose that non-tech executives understand this, and that’s the real reason why PCI compliance is as low as you report?
In general, the 2009 report is, in my view, much more useful than the 2008 report, but it still suffers a bit from reporting what you have vs reporting what people might really like to know. And, there are so many other useful correlations that you could present (Alex, are you listening?)
The most important, and certainly the most difficult metric, would be, what’s the impact ($$$) of a given attack? And what’s the correlation between things that are known, like industry segment, attack vector, attack difficulty, number of records, etc. and that impact.
It also appears to me that there must be at least one or two huge financial services breaches that are overwhelming everything else in this data set – I know that you cannot name names, but I have a pretty good idea who it might be. It would be nice to see some numbers that have these outliers removed – such an analysis might have more relevance to the average company out there.
Best regards,
Patrick Florer
Dallas, Texas
In general, the 2009 report is, in my view, much more useful than the 2008 report, but it still suffers a bit from reporting what you have vs reporting what people might really like to know.
The most important, and certainly the most difficult metric, would be, what’s the impact of a given attack? And what’s the correlation between things that are known, like industry segment, attack vector, attack difficulty, number of records, etc. and that impact.
It also appears to me that there must be at least one huge financial services breach that is overwhelming everything else in this data set -
Posted by: Patrick Florer on April 17th, 2009 at 2:26 pmHey Patrick!
“If you are not a financial services company, then the question for me becomes “Why not play the odds?” Per your report, only 5% of records breached occurred at non-financial sector companies.”
C’mon now, after all the time we’ve spent together I know you know better. That number isn’t number of breaches, it is number of records – and the risk tolerance of an organization isn’t set on just number of records (although record number is one informative prior in my mind) it’s every bucket of probable losses (back to FAIR training). That said, further analysis might warrant “playing the odds” (though I’m guessing fines/judgments might convince you otherwise).
“And, there are so many other useful correlations that you could present (Alex, are you listening?”
I assure you I’m listening. And I agree that there should be more fun to follow. But we have multiple factors to weigh here, not the least of which is releasing a report that is digestible in length. Nobody wants a TLDNR tome of arcane statistical analysis, but the depth of the initial (there I said it, initial) analysis had to be established at some level – we chose the one you see in the report. My goal is to develop subsequent analysis that goes deeper where we can find useful information (see my upcoming post on Timespan of Breach Events as an example).
That said we can’t make some numbers appear out of thin air (nor would you want us to). “The most important, and certainly the most difficult metric, would be, what’s the impact ($$$) of a given attack?” Impact measurements, for example, are not in scope for Incident response engagements (the data this report is drawn from). I would like to do something there, and hope to someday, but for now we just don’t have that level of information. You could pull other data sources in that use Activity Based Cost accounting to set numbers around cost-per-record, but even then you’ll likely want to use probabilistic methods to establish an acceptable range for use in risk analysis rather than a static, precise number.
Hope you’re well. Haven’t had a chance to play much tennis so far this year.
Posted by: Alex Hutton on April 17th, 2009 at 6:54 pmNice to hear from you, Alex!
Two follow-up questions:
1) Are there any large outliers skewing the financial services data? If so, can you reveal how big they are in terms of breached records? Would you consider doing a follow-up analysis that excluded these outliers, if they exist?
2) The report states that 81% of breached companies were not PCI compliant. Maybe it’s in the report, but I don’t remember seeing it, so can you provide the denominator for PCI related breaches? all 90? or something less, as I expect.
I am well – playing too much tennis – the weather in Dallas, though extremely windy at times, is starting to be very nice.
Patrick
Posted by: Patrick Florer on April 19th, 2009 at 1:05 am