PCI Compliance Is Good; Data Security Is Better
Written by Walter ConwayA 403 Labs QSA, PCI Columnist Walt Conway has worked in payments and technology for more than 30 years, 10 of them with Visa.
If you are like many CIOs, a lot of your security budget is driven by compliance requirements, including PCI DSS. Although many merchants feel they are secure once they achieve PCI compliance, that is not necessarily true.
For example, a janitor can walk out the door with files of sensitive data, your shredding vendor may determine it gets a better price for the paper when it’s not shredded or a staff member may decide he really does need to click on that infected e-mail attachment telling him he won a lottery.
To be secure, you need to go further. But what does it mean to go beyond PCI compliance? What are some ideas and suggestions you might consider? The idea is that you should not only be compliant; you should be more secure, too.
Just validating its PCI compliance does not mean a retailer is actually compliant.
To put it simply, validation (which is a one-time event) does not make you compliant (which is a continuous state). We now need to take it a step further, and observe that compliance does not equal security. Security means going beyond compliance. What follows are one QSA’s examples for going beyond PCI to improve your security.
Let’s start with vulnerability scanning. PCI requires you to pass both internal and external vulnerability scans quarterly. Increasing to monthly scanning detects issues sooner at relatively little additional cost. If you run a Web-based payment app, think about even more frequent scanning–maybe daily.
The same advice goes for penetration testing. PCI requires a penetration test annually and after “any significant infrastructure or application upgrade or modification.” I’d give serious consideration to a full-scale social engineering penetration test sometime. You may be surprised at what the testers discover about your security. And the results can point to some needed improvements. (Full disclosure: My company is an ASV and we conduct penetration tests.)
Restricting today’s unlimited employee Internet access is another good place to start. Getting that genie back into its bottle is not going to be easy, but maybe you can at least partially contain the situation. PCI Requirement 8 tells you to restrict data access based on a business need to know.
Taking a parallel approach, can you restrict Web access by job function or need? For example, some of your marketing staff needs to access to social networking sites, but does everybody in the company? Does every employee need to check auction sites, update their Facebook pages or plan their vacation while at work? A policy of restricting Web access by job function, together with some Web site whitelisting, can go a long way toward reducing the risk of your users downloading malware that compromises your network.
-Marc
April 7th, 2010 at 3:19 pm
Walt,
Very well written. One of the biggest challenges that I face is the concept that my executives and my franchisees believe that being compliant is the goal, rather than being secure. When justifying the costs of “security”, the response is WIFM? The answer, a poor one, is “That we hope to protect you from a fate similar to so-and-so”. It’s never a good argument when you use “hope” and “them” in a justification.
I’m tired of the standards being so broad. It’s time that the council set out very specific standards about what needs to be implemented and how. No more of this, “If you have this, than prove to me it doesn’t do that”.
For all the griping that people did about the MA data privacy law, it resulted in action. “You must implement intrusion detection systems” is far more concrete than “You must protect card holder data.”
April 7th, 2010 at 3:44 pm
Walt, great article. I agree with your professor: Validation doesn’t equal compliance, and compliance doesn’t equal security. And of course,there is no such a thing as 100% security.
Compliance should be the starting point, not your end goal. Even as more organizations are shifting their thinking to more security, they know that data breaches are bound to happen. That’s why it’s important to act quickly once they’ve discovered that a breach has happened. Stop the bleeding as fast as you can to avoid it becoming a bigger problem.
PCI DSS is one of the most prescriptive standards, which provides very specific guidance for how to protect cardholder data. The intent of the standards is NOT to make organizations comply with it, but rather to create a more secure environment where sensitive data can be protected.
Thanks for sharing your insights.
April 7th, 2010 at 7:44 pm
@Todd,
Thanks for the comment. The specificity of, say, the MA privacy law you cited is great today, but what if a new, better, cheaper, easier technology comes along tomorrow? Do we change the law? By specifying the objective, PCI (and the Council) stays agnostic on any particular technology and allows merchants to meet the goal in whatever ways fit their business model and budget. I’d hate to see PCI without the option of compensating controls, for example. Unfortunately, we’ll probably never reach that perfect balance between specificity and flexibility.
@ Cindy,
Thanks for your comment an the kind words. We agree on the need to act quickly in a breach situation. The unfortunate reality is that most of the time the merchant only finds out they’ve been breached when a card brand or their acquirer calls them with the bad news. Yet more reason to go those extra steps from compliance to security.
April 15th, 2010 at 7:50 pm
I love this paragraph – “PCI compliance requires, among other things, that you know where your cardholder data is stored, understand how that data is used and manage the partners with whom you share it. Data security requires you to go further and take responsibility for your users, protect the data in transit and at rest, and prevent the data from leaving your network without your knowing about it.”
I am sure many readers here know this, but the cardholder data is effectively “in-the-clear” on the approximately 2.7 billion payment cards. It is encoded data, not encrypted data. So it’s the merchant’s responsibility to protect that data? That is a sad joke and it’s unfortunate the issuers are getting away with it.
If protecting the data helps us all sleep better, then great! Does it really stop the fraud? Not one bit. As long as the data is “in-the-clear”, the bad guys can and will get it. They will only stop trying to steal the data when it has NO more value and they can’t use the data to make counterfeit cards. Adding Encryption + Tokenization + Authentication + Dynamic payment card data will make it much more difficult for the bad guys to commit fraud and it’s the fraud that costs billions each year. Protecting the data without authentication will not stop fraud, so where is the ROI on security if the fraud and chargebacks do not go away?