Is It Time To Eliminate Shortened SAQs?
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.
Is it time to require every merchant to validate compliance against every single PCI requirement? That is, does it make sense to eliminate self-assessment questionnaires (SAQs) A, B, C and even the new C-VT and to require every merchant to use SAQ D? Doing this may seem dramatic, and it certainly would be a shock to many small and midsize merchants. But it only reflects the PCI Council’s own position that every merchant needs to comply with all of PCI.
I am not convinced that requiring every merchant to use SAQ D, with its 280-plus requirements, makes sense. It is just too daunting for a small or midsize merchant. On the other hand, we see increasing numbers of hacking attacks on these same merchants who use these shortened SAQs, so they need to be more secure. Maybe a better course is to upgrade the shortened SAQs or even change them into “guidance” documents.
At a PCI expert panel I recently led, the discussion moved to compliance validation. The senior PCI compliance officer for one of the largest card acquirers told the audience of about 150 Level 2, 3 and 4 merchants that they all should use SAQ D and forget about the shortened SAQs. His reasoning was that such a move made sense from both a security and a business perspective.
My initial reaction—and that of most of the audience—was to reject the recommendation out of hand. After all, didn’t the PCI Council itself develop the shortened SAQs to help small and midsize merchants validate their compliance? Haven’t the shortened SAQs encouraged many merchants to stop storing cardholder data? Didn’t the Council just introduce a fourth shortened SAQ for virtual terminal merchants? And didn’t the shortened SAQs make validation easier and cheaper for all the merchants sitting in this audience?
On reflection, though, his recommendation makes a lot of sense. That is, perhaps the issue is not the SAQs themselves but how retailers and other merchants use them.
Readers of this column will know that all but the largest (Level 1) merchants and service providers can self-assess their PCI compliance using an SAQ. The one we know as SAQ D addresses each requirement and sub-requirement of the PCI DSS, which totals about 280 items.
-Marc
July 6th, 2011 at 11:46 pm
I’m all for good security all around but as long as we have serious problems with the big guns like Citibank and the others, I see no point in wasting time tightening up the requirements for small merchants.
It’s like trying to patch a pinhole in the hull while the ship sinks from the iceberg damage. I find it rather distaseful that it would even become an issue.
Tom Mahoney, Director
Merchant911/Cardholder911
July 7th, 2011 at 8:45 am
Personally I think the reasoning behind this is to eliminate training of people assisting merchants in determing which SAQ is appropriate and filling one out. For a merchant with a Dial Terminal either it is compliant or not, what does he need to know about firewalls, networks, storing of data in a database, security polices and user procedures.
Give me a break. Go after the guys that are being compromised where there are issues and do it regardless if they are members of the vaunted PCI Consol.
July 7th, 2011 at 9:01 am
The SAQ mechanism and its multiple options is a prime example of putting compliance over security. If we want to be serious about reducing the frequency of breaches, at least of the type occurring today, we need to put security first and compliance second. It’s a 7 point plan instead of a 280 point one.
1. Run a PA-DSS validated application
2. Patch your PA-DSS validated application
3. Install a hardware firewall with segmentation
4. Use only secure, two-factor authenticated remote access
5. Change default passwords and have unique accounts for each user
6. Run anti-virus or whitelisting
7. Don’t surf the web from your payment environment, not possible if point 3 is done correctly
Level 4 merchants can do these 7 things, and the VAR’s who perform the implementations for them can grasp this. Just about every one of the level 4 breaches in Trustwave’s and Verizon’s annual reports would have been thwarted had the merchants done these 7 things. Security is the foundation of compliance. The reverse is not true.
July 7th, 2011 at 1:38 pm
If a merchant cannot be trusted to honestly fill out the short-form, what makes anyone believe the same merchant will all of a sudden be trustable filling out the long-form just because it is longer?
July 8th, 2011 at 6:12 pm
I actually had one of our merchant members tell me that their Approved Scanning Vendor insist that they disable their firewall so they could be scanned. This was a few years ago so hopefully the vendor has gotten smarter or lost their approval. In either event, it’s a perfect example of compliance over security.
July 12th, 2011 at 11:04 am
Walt,
Where to begin.
Regardless of the intent, I think that we all know that in the real world, that 99 of those asked to attest to a subset will only manage that subset.
I sat an industry meeting, involved in a heated debate about logging. Since the shortened SAQs do not mention the requirement to retain logs, the industry reps were recommending that they not bring logging into scope their program that they were creating for merchants. Even though the QSAs in the room pleaded that logs are the only defense in the case of a breach, the general consensus in the room was it was out of scope” because it “is to complex for the smaller merchant to understand, never mind do, and the ‘SAQ DOESN’T REQUIRE IT'”
This example alone speaks volumes about why the shortened SAQs are broken.
July 12th, 2011 at 10:27 pm
Many thanks for the great comments. I wrote the column hoping to generate discussion from StorefrontBacktalk readers, and you didn’t let me down.
To me, the comments about “compliance over security” capture the theme I was trying to get at, maybe better than I said it myself. And Todd’s comment about “the SAQ doesn’t require it” is so painfully true. I, too, have heard that same statement made at industry workshops. Unfortunately, the SAQs are what we have, so I think it is important for QSAs and others to make it clear that maybe the SAQs are not the be-all and end-all of compliance, and PCI is not the be-all and end-all of security.
Thanks to all for the comments (and emails…yes, I read them). I’ll be following-up on this theme in a week or so. Meanwhile, keep the comments coming.