As we brace ourselves for the release of PCI DSS (Payment Card Industry Data Security Standards) 1.2, 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.
Have you read these related articles?
Newsletter:
