Once more into the breach report.
So Verizon Business released one of the hottest breach reports in the industry—and by hot, I don’t mean just that it’s in that cool black and red and has bubble charts galore. No, I mean that their executives can travel to conferences on it for the whole YEAR and if they play their cards right, nobody will get tired of hearing about it. I’m looking forward to seeing what the pundits say about the conclusions.
There are some awesome data points here, ones that puncture the conventional wisdom:
- A big majority of the breaches resulted from outsider attacks.
- You can prevent most of these breaches by doing really simple and cheap things, like CHANGING DEFAULT PASSWORDS (more on that later).
- 81% of the victims were not PCI compliant (ouch!).
- Nearly half their caseload comprised interrelated incidents (different parts of the same organization, committed by the same individual, etc.).
Now, let’s look at the visualization, which is really half the appeal of the report. There was a gratuitous use of bubble charts; most of these could easily have been depicted by bar charts, but I guess they wanted some variety in their geometric shapes (this led to my frequent impression that the data breaches were all coming from Jupiter). The only really stellar (heh) use of the bubble chart was figure 31, showing the different time spans for breaches, in which you could get an overall feel for the proportions of a complex data set at a glance. That one and the line chart showing threat categories were worth spending a lot of color on.
They mostly did a good job slicing and dicing the numbers, but they went a bridge too far when they trotted out their “pseudo risk calculation.” First of all, I’ve never liked the variations on “frequency x impact = risk” because I always ended up with a number in the “risk” category that sat in my hand like a Japanese vending machine snack: I had no idea what it was, didn’t want to consume it, and certainly didn’t want to foist it off on anyone else because I couldn’t vouch for it. In this case, the mystery gelatinous mass is still the “risk” column in their chart, which is simply a blending of their historical data—NOT likelihood—and the number of records breached, which gives you 28,000 Somethings. Now, I’m always suspicious when two columns of a chart have units specified and the grand finale column doesn’t. Is that supposed to be the average number of records someone can expect to lose next year with a probability of 1.00? They don’t SAY it’s the number of records, but that’s the most likely candidate, given the scale. Is this supposed to be a substitute for annualized loss measured in dollars?
Guys, if you have to call it “pseudo,” you’re already backing away from it yourselves. If you can’t vouch for it and tell me exactly what’s in it, I ain’t eating it.
On the upside, I was glad to see some other things confirmed, such as my belief that database encryption really doesn’t buy you a whole lot in terms of protection, because the attack pathways are the same ones that belong to legitimate users. (Encryption at rest is for protecting data that is TRULY at rest, i.e., the server is turned off.) It is depressing, but utterly believable, to see that the vast majority of breaches are aided by “errors and omissions,” also known as system administration FAIL.
Looking at the commonalities, we see the very elementary errors and misconfigurations, the lack of PCI compliance, and the fact that most of the breaches were detected by a third party. If you roll this all together, you could plausibly assume that the victims were all generally lackadaisical about managing their systems. This could be attributed to a lack of skilled resources—and by that, I mean that either they didn’t have sufficiently knowledgeable resources, or they had skilled ones but way too few of them to get the work done. You might be able to infer that these folks didn’t want IT management cramping their style; that would also explain why very basic security measures weren’t properly implemented. And finally, we see that third parties and their interconnectedness play a significant role, in that mergers and acquisitions make an IT environment more complex than it already was, and trusted third parties really shouldn’t be trusted when their own security house isn’t in order either.
All in all, there were enough interesting data sets in here to keep it from being another standard industry FUD piece. I actually learned some things from it, so color this one a winner.
on 04/20 at 07:17 AM:
) by more difficult attacks. That being the case, what do we infer about reducing the number of loss events as opposed to the amount of loss? The other question is what Verizon defined as “difficult”—does that include SQL injection? They show that the vast majority of records were affected in attacks that included “hacking” that were “aided” by these “configuration errors.” Look at this last sentence carefully, and you’ll see that there’s a lot of ambiguity and imprecision there. 
on 04/21 at 01:39 AM:
Hi Shrdlu,
I agree that there’s some very good data in the Verizon report. That said, Brooke made some observations about it that I believe are worthwhile for people to consider.
http://newschoolsecurity.com/2009/04/a-curmudgeon-is-a-little-confused-by-the-2009-dbir/#comments
Cheers,
Jack