3 common misconceptions about PCI compliance
Being the PCI guy at my company carries a certain amount of burden. Not only am I responsible for all of the ongoing compliance and yearly assessments, but I also have to interpret the PCI DSS scriptures on how PCI affects products, initiatives, and platform decisions.
Anyone closely involved with PCI recognizes that our mission tends to be of a holy order. And it’s often a lonely and monastic order: we read the arcane words and interpret them for the common layperson to understand.
What you don’t know could hurt you
If you’ve been the arbiter of PCI for your company, you’ve probably run into a variety of misunderstandings, long-held misconceptions, and just weird ideas. (Nodding your head?) These aren’t limited to occasional questions from co-workers—they also happen with many vendors. I’m honestly surprised that so many vendors operating in areas that impact PCI compliance have virtually no clue about how their products affect or are affected by PCI.
After all, there’s no excuse to be clueless. One of the great things about PCI is that the rules are available for anyone to peruse. That’s why many discussions about PCI end pretty quickly when you simply ask someone to point to the PCI DSS guidelines to support their argument. I can usually tell I’m working with a seasoned professional if they can quote chapter and verse. I can also tell when someone hasn’t done their homework.
Having worked in the PCI world for several years, I’ve seen a lot of good and a lot of bad. Here are three of the biggest misconceptions and misunderstandings I tend to run into.
Misconception #1: You believe a certain product or system is out of PCI scope
The first misconception primarily impacts vendors. It’s the misconception that just because a piece of equipment doesn’t process or transmit credit card data, it’s not in the scope of PCI. This simply isn’t true.
There are essentially two types of systems in scope. One type is any system that directly touches credit card information. The second is any outlying larger connected systems that touch the first type of system.
Vendors tend to get into trouble when they have a device that directly talks to a POS or similar credit card processing system. The moment that device can talk to the POS that’s in scope, it’s basically a given that it (and whatever it touches) is also in scope as a connected system. It’s not always a black-and-white distinction, but you must have very tight firewall rules to make your case.
Misconception #2: You’ve accurately scoped your CDE
The second misconception involves what PCI compliance fundamentally tries to protect. While the PCI DSS guidelines have good recommendations for general security, they’re specifically trying to protect payment-related information. If you’re implementing the controls well, they do a solid job of increasing overall security. But at the end of the day, the scope is intentionally narrow.
That’s why one of the biggest issues I see companies struggling with is how to adequately define their card data environment (CDE). Getting the scope right for CDE is the most essential thing you can do, and everything else builds on top of that.
This is where understanding the card data flow comes into play. You must be able to articulate how a credit card transaction is created and transmitted from beginning to end. This understanding forms the basis of what is in scope and what is not. Because the precise goal of PCI is to protect card data, you should almost always try to reduce scope.
Misconception #3: Not recognizing the differences between PA-DSS and PCI DSS
The third misconception is about the differences between the PA-DSS (which is used to certify payment solutions) and the PCI DSS (which is used to assess adherence to the data security standard). This might seem contradictory, and it probably should be, but there are many cases where you can have a system that has a PA-DSS certification that will not meet PCI DSS compliance.
Again, this goes back to the problems that vendors face in these situations. More than a few times I’ve seen a company get surprised during an assessment when the QSA asked to see the updates to fix vulnerabilities in Windows systems upon which a vendor has built their POS solution. Usually the customer has no control over those updates—they’re typically bundled with a vendor’s application update. I’ve witnessed some pretty hairy phone calls between a QSA, store operator, and vendor trying to sort out why a POS hasn’t been patched in a few years to fix known Windows vulnerabilities.
You can’t outsource ownership
One critical aspect to remember is that if you’re subject to PCI compliance, you’re ultimately responsible for everything. No matter how much you outsource, you can’t outsource ownership. That includes depending on a PA-DSS. I’ve actually worked with vendors to roll out systems that their own techs have installed—only to discover that the installation doesn’t even meet the vendors’ own PA-DSS standards.
As a bonus tip, if you’re working with vendors to select a new payment solution, read through their PA-DSS before making any decisions. Ask hard questions about how their rollout, installation, and real-world management matches up to their PA-DSS. Test the PA-DSS configuration first. I’ve had PA-DSS guides include language and features that aren’t actually built into the solution. It honestly makes me wonder how they got a PA-DSS certification to begin with, but that’s another topic of discussion for later.