I suspect some of the most discussed pages of the Verizon DBIR were 41-43: PCI. I’m going to add to it, while keeping in mind these cases were all breaches which most likely occurred in companies lacking high levels of security controls and awareness, probably lacking PCI initiatives, with a couple highly targeted victims. I’m also going to assume every breach victim is supposed to be meeting every PCI requirement equally, though this may not be the case.
1. 19% claims/found compliant, yet had breaches. Doh. More on this later in bullet 5.
2. If 19% were PCI compliant, I would expect Table 10 on page 42 to have no number less than 19% for each PCI requirement. Oops, 5 requirements are below 19%. It’s possible I’m misinterpreting.
3. No PCI requirement over 68%! Ok, I know this data is going to trend very low because they’re breach victims who sought external help, but only 30% utilize a firewall (maybe lack of internal firewalls?) and only 62% use/update AV (the rest Linux?). Some of these other requirements I can understand since, strictly speaking, they can be hellish to meet: Req 6 (dev/maintain secure systems/apps), Req 10 (track and monitor access), Req 7 (restrict to need-to-know [I think few are fully honest on this one, or just say everyone needs to know]), Req 8 (unique ID [does using service accounts to connect to the database from the apps count?]). Seriously, those four requirements are a potential nightmare depending on how strictly you scope them. They are necessary, don’t get me wrong, just nightmares, so I’m not surprised how low they score.
3.5 I’m going to go out on a small limb here and say thank you for these numbers in Table 10! First, I don’t think we get a good enough picture anywhere about how compliance really appears, especially when it’s in someone’s best interest (they’re paying you to pass them) to go easy. And I would suspect that the Verizon investigative team is more thorough and more technical than most auditors (sorry, but I gotta say it!). This might be because auditors can only see what they’re shown, but investigators get to see what they’re shown and where they follow the trails. Sadly, this doesn’t get it’s own point in my list because these are just numbers from victimized companies; not necessarily indicative of the average company who may be more PCI-aware.
4. “…these breaches, in general, did not occur in organizations that were highly compliant with PCI DSS.” (pg 43) I’m not sure I could really make this statement based on the data in the report. Yes, of the victims it looks like there may be a correlation between PCI compliancy and being victimized, but I’m not sure you can conclude that without knowing the full measure of how many companies are compliant and how many are not. By the way, I think it really should be obvious on it’s own that lack of PCI compliance indicates crappy security; I just don’t think the data necessarily backs this.
5. I shouldn’t include this, but I’ll briefly rant that PCI has an image issue, one they maybe didn’t create, but they’ve done little to fix it: the perception that PCI = secure. In this perception, this report is a dagger in the side: 19% were (supposedly) compliant yet suffered a breach. CSOs collectively groaned at that mark, especially those that raised PCI up on that too-high pedastal to
cthulu their budget gods.