This is page 2 of:
PCI Strategy: Avoiding The “Anything But SAQ D” Dilemma
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 wconway@403labs.com.
Cards issued by European banks when used online cross border don't usually support AVS checks. So, when a European card is used with a billing address that's in the US, an ecom merchant wouldn't necessarily know that the shipping zip code doesn't match the billing code.
-Marc
