looking at pci stats from 2010 verizon dbir

I mentioned previously that I didn’t have much to add to this year’s DBIR. That’s not entirely true, but the thoughts below are definitely not a big deal. The DBIR already spent several pages on PCI-related material, and certainly didn’t (or shouldn’t) need to spend much more on it at this time.

But I still found some of the data interesting.

Which requirements have the best adoption? I’m not surprised by these results all that much. Encrypting transmission (Req 4) is an easy win* when you just look at SSL. Restricting physical access (Req 9) is also an easy win* if you lock your doors (please read the * down below before I raise your hackles too far!). Using and updating Anti-virus (Req 5) is likewise easy, although I’d question how many enterprises are actually validating that updating procedure! And policies (Req 12) are highly adopted, most likely because they tend to be fire and forget. Ideally, I’d like to see policies be the most adopted simply because they should be some of the first check boxes accomplished and/or the quickest to wrap up. (Then again, few people enjoy writing them…)

It is no secret that these particular requirements read quickly as the more clear and easier requirements.

Which requirements have the worst adoption? Developing secure systems (Req 6) is consistently pretty low, and not surprising: it is one of the crappiest single requirements in the PCI DSS. It is vague and downright huge. Regular testing (Req 11) is next, which again is not surprising (vuln scans, IDS/IPS, pen tests), although I think that is usually due to costs as much as anything, both in terms of human hours spent attending to those technologies as well as the capital costs of external pen tests or hardware to satisfy the requirement. I also find that Req 11 is one of the bigger “security geek” items in the list, that really doesn’t even involve general IT operations staff competencies.

As the DBIR rightly points out, the requirements with the most ongoing tasks associated with them are the ones least adopted.

Wait, 2 of them decreased?! – The DBIR mentioned, but I don’t recall it discussing any reason why the anti-virus (Req 5) requirement and vendor-supplied defaults (Req 2) actually decreased 9% and 19%, respectively. AV, as mentioned above, is one of the higher adopted items, yet it decreased; and removing vendor defaults should be a slam-dunk for operations. Maybe the problem, like so many things that are shoddy with security in enterprises, is in the on-going verification of updated AV and validation that vendor-defaults are changed. Or maybe some breaches this past year took advantage of passwords that got reverted back or the attackers removed AV and nothing threw alarms about those systems being unprotected. Who knows…

Like I said, the DBIR didn’t need to spend even more time on PCI, but I found Table 9 (pg 54) to be pretty interesting…just like I had last year.

* By “easy win” I mean these *can* be easily met in limited circumstances. Reality for someone serious about security can still make these items strangely difficult and open to interpretation.

2 thoughts on “looking at pci stats from 2010 verizon dbir

  1. Enjoyed the write-up Michael. You may want to keep an eye out for a related something we’ll be releasing in a couple weeks. Cheers,

Comments are closed.