PCI Strategy: Avoiding The "Anything But SAQ D" Dilemma

A 403 Labs QSA, PCI Columnist Walt Conway has worked in payments and technology for more than 30 years, 10 of them with Visa.

As I noted in last week's column, there is only one problem with the shortened versions of the Self-Assessment Questionnaire (SAQ): They are incomplete. Merchants who qualify for SAQ C process payments on a payment application connected to the Internet. The target audience for SAQ C is small merchants with a payment application on their personal computer, which connects to the Internet to process card transactions. Other requirements are that the merchants store no electronic cardholder data and that their computer is not "connected to any other systems in your environment."

In the real world, many retailers and franchisors (and franchisees) try to qualify to use SAQ C. I call this the "anything but SAQ D" approach. In my experience, the biggest challenge of SAQ C is isolating the application server(s) from the rest of the merchant environment. I know merchants who have devoted a lot of effort and changed their network so they can qualify for SAQ C. A recent clarification by the PCI Council, however, limits the ability of many retailers and franchisors to use this SAQ.

SAQ C contains 80 questions that cover parts of 11 of the 12 PCI requirements. The sole missing requirement is Requirement 10, informally known as the logging requirement. Allowing a merchant to host a payment application and not requiring logging seems to be a major oversight. I imagine the rationale is that because SAQ C merchants do not store electronic cardholder data, they have no need for audit logs. Maybe this situation goes back to the Council's original intent that SAQ C would apply to a single person running a payment application on his or her personal computer.

But the reality today is that many sizeable retailers and corporations (i.e., Level 2, 3 and 4 merchants with millions of transactions a year) are using, or trying to qualify for, SAQ C. In my opinion, SAQ C merchants should implement all of PCI's logging requirements even if they don't store electronic cardholder data. For example, without logging a merchant would not be alerted if an admin changed the application configuration to store cardholder data or copied that data to his or her laptop.

Another item I would add to my SAQ C list is Requirement 11.5, file integrity monitoring (FIM). Without FIM, merchants hosting a payment application won't know if a system or application file on one of their POS systems has been compromised. This is critical information needed to achieve a secure operation.

Lastly, although SAQ C includes internal and external vulnerability scanning, it is silent on penetration testing. A security-conscious merchant should include this requirement even though it does not appear on the SAQ. The bad guys are regularly scanning and testing merchants' systems. At least with a pen test those merchants get to see the report of their vulnerabilities and, hopefully, correct them.

SAQ C-VT (the VT stands for "virtual terminal") is new in PCI 2.0. It includes 51 questions covering parts of nine of the 12 PCI requirements.SAQ C-VT (the VT stands for "virtual terminal") is new in PCI 2.0. It includes 51 questions covering parts of nine of the 12 PCI requirements.

It is a variant on SAQ C, and it applies to merchants who process transactions on an isolated computer (not a laptop) connected to the Internet. Eligible merchants use a browser on the computer (the virtual terminal) and connect to their processor or a PCI-compliant third-party Web site where they manually (no magstripe reader!) enter transactions one at a time.

The intent is that the merchants isolate the virtual terminal (i.e., it is not connected to any other system in their environment, even through a firewall) and use it solely to process payment-card transactions (i.e., it is a one-trick pony). If I were advising merchants eligible to use SAQ C-VT, I would advise them to go beyond its minimal requirements in several areas. I would enforce strong passwords (Requirement 8, missing in its entirety), and I would want FIM (Requirement 11.5) on the computer as suggested for SAQ C merchants.

Perhaps my biggest surprise is that there is not a requirement for vulnerability scanning (Requirement 11). Although there are some firewall requirements, these merchants (like their SAQ C brethren) should perform internal scans on the network and computer, in addition to having external vulnerability scans performed by an ASV. I am not quite sure why the Council left out these requirements, and I'm sure it had good reasons. Nevertheless, I suggest that in the interest of security, merchants include scanning even though it is not required.

As I noted last time, all these suggestions are based on one QSA's experience and opinion. Every merchant should look at their particular situation, network and infrastructure, and then determine what steps will make their payment environment secure. Should the Council revise the SAQs to reflect some of these additional requirements? I'll leave that decision to the PCI Council and the card brands. The simplified SAQs are collectively a great innovation, and they have helped make PCI compliance more approachable for many small and midsize businesses. By offering an incentive (easy validation), the Council has also caused many merchants to stop storing electronic cardholder data. This result alone greatly reduces the chance of a data breach.

My only regret is that the SAQs are not positioned as guidance or a compliance starting point. Instead, too many retailers and merchants use the SAQ as the limit of their PCI compliance effort. Validation is not the same as compliance. At one level, validation is once a year and compliance is what you do every day. At another level—and that is what this column is about—validation with a shortened SAQ may look good on paper, but compliance has always meant complying with all of PCI DSS.

Just because the Council may not include some PCI requirements in a particular SAQ does not mean merchants get a free pass on PCI. If a merchants suffers a data breach, I would not plan on the "but that requirement wasn't in my SAQ" defense being very effective.

What do you think? Do you use a shortened SAQ? Does your company look beyond the SAQ or is that all you do for PCI compliance? I'd like to hear your thoughts. Either leave a comment or E-mail me at [email protected].