PCI is everywhere. You basically need to bring an umbrella with you to make sure PCI doesn't fall on your head. Of course, I'm being a bit tongue-in-cheek, but the Payment Card Industry Data Security Standard (PCI DSS) is the biggest thing to hit security people since Sarbanes-Oxley did a dance on our heads a few years ago.
To be clear, the intent of PCI -- which is to protect private payment information while reducing fraud and providing more confidence in the global credit issuance business -- is meant to be positive. But now that we've had some time to let the original standard and a first revision (PCI DSS 1.1 hit in September 2006) sink in, it's questionable whether PCI is even achievable and if its defenses will help secure your environment.
The catalyst for this discussion was an April SearchSecurity.com interview in which Phil Mellinger -- who had a hand in building the original PCI DSS specification -- was questioning whether the rules should be loosened to make PCI more "achievable", beyond the "compensating controls" loophole that was added in PCI 1.1.
My first thought on easing up the standard was a resounding no. I didn't see the use in relaxing the requirements simply because they're hard. Should smoking be allowed in restaurants again because it's hard to quit? Of course not, but after thinking about the question, it's obvious that a simple yes or no answer won't suffice.
To be clear, I pride myself on being a "yes or no" type of guy. There isn't much gray in my world (besides my hair), so this issue is pretty muddled for me to be looking at both sides of the discussion. So let's address the issue from two perspectives:
Does PCI help with security, and if so, what works and what doesn't?
What would be hard for merchants to do?
As a little reminder, PCI is made up of 12 requirements, ranging from maintaining an information security policy (No. 12) to having a firewall configuration to protect cardholder data (No. 1). Looking over the 12 requirements, there aren't many bones to pick with the generic advice: changing default passwords, regularly testing security systems and processes and encrypting network traffic. These are all good ideas relative to protecting data.
What doesn't work? Some of the techniques seem a bit archaic, such as requiring antivirus (No. 5). Antivirus is simple table stakes, but if you are thinking AV provides a comprehensive endpoint protection posture, I have a bridge to sell you. The idea of restricting cardholder data on a "business need-to-know" basis – as it is stated in requirement five -- is a bit wacky. How is "need to know" defined? This requirement mandates a default/deny approach, which restricts access unless specifically authorized, but that leaves a lot of subjectivity to the audit/examination.
But there is clearly one requirement that is keeping Tums in business. Lots of security professionals have perpetual heartburn from requirement No. 3: "protect cardholder data." This requirement calls for encryption, which is difficult to achieve and is in need of a compensating control.
Based upon typical attack vectors where data is compromised, it's not clear that encrypting the database would help. If the application is broken, the attacker will have authorized access to the encrypted database and the decryption keys, which is a "game over" situation. So not only is this requirement hard to meet, but it also may not even help.
Which brings us to the second part of the discussion – what is hard to do? The most difficult parts of the PCI requirements involve the additional processes required. Many organizations, especially the smaller ones, don't have a process to ensure that applications and systems are secure (No. 6). They should, of course, but they don't. Merchants should start scanning applications, looking into source code analysis and embracing a secure development process to achieve compliance.
Embracing the identity requirement, which is PCI DSS requirement No. 8, can be difficult if the merchant doesn't have a central provisioning infrastructure. These are all problems that can and should be solved, but require a lot of work. Another aspect that requires a lot of work is tracking and monitoring access to network resources (No. 10). This involves a significant amount of data collection, so bring your checkbook -- the collectors, storage and analysis engines needed aren't cheap.
So what's the bottom line? Basically, there is nothing required in the PCI DSS that is overly onerous. Any organization that has been taking security seriously for the past few years should be in pretty good shape. A well-run security program will put a corporation in a strong position to be compliant with most regulations, including PCI DSS.
On the contrary, if an organization has ignored security for years, it's likely in for a world of hurt; candidly, no organization should be in that position.
Thus, I don't think the PCI DSS requirements should be loosened. Maybe the timeframes could be extended a bit, but just because it's hard, doesn't mean it shouldn't be done.
About the author:
Mike Rothman is president and principal analyst of Security Incite, an industry analyst firm in Atlanta, and the author of The Pragmatic CSO: 12 Steps to Being a Security Master. Rothman is also SearchSecurity.com's expert-in-residence on information security management. Get more information about the Pragmatic CSO at http://www.pragmaticcso.com, read his blog at http://blog.securityincite.com, or reach him via e-mail at mike.rothman (at) securityincite (dot) com.
