PCI 2.0: Secure Cardholder *Data*

As we brace ourselves for the release of PCI 1.2 (see a TechTarget story here and a Rothman blog entry here) it is as good a time as any to think about how PCI could be improved. 

I bet a lot of you have mixed feelings about PCI just like I do. Don't get me wrong -- there is a lot to like about PCI.  The standard is desperately needed, its motives are noble, and it is one of the most prescriptive security standards out there (even accounting for the compensating controls black hole). In contrast to other security standards, most of PCI’s dirty dozen requirements make it pretty clear what you need to do. But looking back it is clear that in an attempt to be holisitic - offering a fairly complete set of security best practices - PCI started out bloated and has gone downhill from there. Over time, new requirements have been tacked on to address emerging security threats, like wireless and Web applications.  If that weren't bad enough, legacy requirements have gotten more complicated to address new permutations.  

 

PCI has lost its way. The combination of bloat with ample room for interpretation by assessors has weakened the standard’s effectiveness and frustrated the merchants and financial institutions that are critical to its success. A continuation of these trends – further expanded scope and continued room for interpretation – is not likely to yield rapid improvement in cardholder data security. 

 

To solve this problem as we look toward PCI 2.0, I propose we get back to our roots and focus on what the standard is all about. After all, unlike broad standards such as COBIT 27001, PCI is relatively bounded. It’s all about card holder data. It’s not about rock-solid wireless security or next-generation host security. It’s not about vulnerability-free application development or holistic security management. As an industry we have run ourselves ragged trying to secure all the conduits to the data: PCs, wired networks, wireless networks, web applications, etc. And from a cardholder data security perspective, let’s face it – it hasn’t worked. More of the same, can’t be the answer. 

 

So, for PCI 2.0 I propose that rather than adding a 13^th requirement we bring it down to one (maybe with a few subheads ;-). Secure cardholder data where it lives: in the database. The solution is certainly broader than database security. And since I work at a database security vendor, I’m certainly biased as could be. But bear with me... 

 

Let’s say Retailer X has done a solid job securing the databases that house cardholder data. They regularly scan for databases with credit card numbers in them and test those databases for misconfigurations and known security vulnerabilities. While it’s impossible to keep them all up to current patch levels, they generally stick to their policy of within a few patch levels of current. As a result, the attack surface is well managed, bad guys don’t have a lot to hold on to.  Better still, the regular scan reports document their hard work and compliance with the standard while also allowing them to demonstrate continuous improvement to management and auditors.  Next, they monitor the activity on these databases. Not only does this help them flag insider misuse and abuse (ex. the admin trying to run off with all the credit card numbers), but tied to their scanning process it allows them to intelligently monitor those databases they haven’t yet been able to patch. And finally, they are encrypting credit card data in those databases to the greatest degree possible. 

In short, thanks to vulnerability assessment they’ve locked down those databases pretty tight to manage the risk of a breach and document that their stated controls are in place (here are your reports Mr. PCI auditor :-).  Thanks to monitoring, in the event of an attempted breach they are likely to know prior to major data loss during early reconnaisance (ex. an attempted exploit by an outsider or an insider grabbing a couple numbers to test if they're valid). Though not full-proof, encryption provides a great fail safe: if all else fails the data is unusuable. 

 

In this scenario, and relative to protecting cardholder data, why do they need a firewall? Anti-virus? Web application firewalls? Wireless security? They don’t. With a solid data security strategy rooted in database security best practices, all of those other security measures could be compromised and the data would still likely be safe.

Comments

[Mike Rothman]

You forgot to mention the most important aspect of PCI 2.0. The requirement for DB scanning and monitoring. :-)

You need a little standards council love like the WAF guys got...

Mike Rothman
http://www.pragmaticcso.com

[Mike Rothman]

You forgot to mention the most important aspect of PCI 2.0. The requirement for DB scanning and monitoring. :-)

You need a little standards council love like the WAF guys got...

Mike Rothman
http://www.pragmaticcso.com

[Max]

well.. tehy "just" might need them for "business security"???
i think that as it was wrong leaving "ample room for interpretation by assessors" so it is to "limit" the scope of security...
if you talked about "certification" i would have agreed though.....
you secure the whole and "certify" within your scope
security for business, certification... as well...