I have a little game I like to play when meeting QSAs. It's called "Is It Compliant?" In this game I provide the QSAs with a fairly common situation in my restaurants and ask them to tell me if they think it is compliant or not. It doesn't matter if these QSAs are under contract (paid) or if I just bumped into them at an industry event. They could be doing a full audit or an assessment, providing paid-for advice or shooting the bull over a beer. To date, I have not received three answers in a row that match.
I encourage StorefrontBacktalk readers to play my game at home. After all, why should I have all the fun? Find a few different QSAs and ask them some tough questions. Here are some fun ones to get you started:
- Is a retailer allowed to run other applications on the POS server if that server processes integrated credit card transactions with PA-DSS certified software?
- If a retailer processes credit cards on a terminal-capture system (versus host-capture), does it automatically mean that merchant is required to complete a SAQ-D (if not required to do an audit)?
- Is a retailer required to change the password on the POS each time it gives its POS provider access to the system and then to change it again when the "incident" is over?
- Is high-definition video of the front of a credit card from a video surveillance system considered cardholder data?
Millions of dollars are wasted every year because there is no clear meaning of the PCI-DSS standard. By trying to create a standard that is ubiquitous to all situations, the PCI Council has created a standard that largely depends on the mood of the individual who is interpreting it. I struggle to understand why clarifications cannot be made and why the cycle of updates takes so long.
Let me explain how broken this state of affairs is. I have one concept that uses integrated credit card processing on its POS server. The POS server has no monitor, keyboard or mouse, and it is mounted to the wall in the office. The only functions of that server are the POS software and the integrated credit and gift card processing. The QSA for that concept told me that to be compliant we needed to make sure the server did not boot directly into Windows (at the time, it did). Rather, it must boot directly into the POS software and require an administrator password to get to the operating system.
I have another concept that also uses a POS with integrated credit card processing. The QSA for this concept (different company, different person) told me that we were compliant even though this computer has a keyboard, monitor and mouse and is used by the employees for E-mail, surfing the Web and who knows what else. At least we have up-to-date antivirus software.After my first encounter, I have informed all of my franchisees that they must have a separate PC for administrative purposes other than the POS server (when it is running integrated credit). A large portion of them have come back to me and told me that I am basically an idiot and that their merchant bank/scanning vendor/POS provider told them such a requirement is not true. Some have already been certified compliant without the second machine. What's with that?
First let's look at PCI-DSS 2.2.
Requirement: Develop configuration standards for all system components. Assure that these standards address all known security vulnerabilities and are consistent with industry-accepted system hardening standards.
Test: Examine the organization's system configuration standards for all types of system components and verify the system configuration standards are consistent with industry-accepted hardening standards--for example, SysAdmin Audit Network Security (SANS), National Institute of Standards Technology.
Anyone have any suggestions on how I use this to help justify the "locked down, single function POS server?" Does anyone carry around a pocket-version of the industry-accepted system hardening guide? No? Let's go deeper.
Here's PCI-DSS 2.2.1: "Implement Only One Primary Function Per Server." How awesomely clear is that?!
First, most of my franchisees don't think of their back-office PC as a "server." Second, who defines what is "primary" versus what is not? ("It's primarily a POS server, but it also serves as my Facebook Central.") The testing procedures call out obvious E-Commerce systems of DNS, Web servers, etc., none of which applies to a POS environment. But this is the Requirement I have been pointed to. Does it apply or not?
What really bugs me, if I'm being honest, is that it makes me look like an idiot. "Todd doesn't know what he's talking about." "Todd is telling me to spend money that I don't need to spend." "My bank has already told me I am compliant and Todd is telling me I need to purchase more equipment and services."
Now EVERYONE who I have ever spoken to about this topic agrees that the absolute worse sin a merchant can commit, regardless of compliance, is to use the POS server for Web surfing when performing integrated credit. Still, I am guessing that dozens or maybe hundreds of merchants each day are told it is okay.
Why can't the PCI-DSS standard and the SAQ clearly call out what needs to be done? Why can't it clearly state the different requirements of integrated credit versus standalone credit versus PED credit devices? If everyone agrees that surfing the Web on a server that is running credit software is a bad idea, why can't we just come out and make a very clear requirement stating that you can't do it?
It seems that a lot of conversations are about advanced items like encryption and tokenization or Chip-and-PIN. How about we start with the basics, like no surfing porn near your customer's credit card data?
Any QSAs out there care to weigh in? Leave a comment, or E-mail me at [email protected]. You can also follow me on Twitter: @todd_michaud.
As I struggled for breath, I watched a 60-year-old man with some bad-ass looking Blue Blockers power-walk his way past me to the finish line in my first triathlon. Read more at www.irongeek.me.