This is page 2 of:
Is It Time To Eliminate Shortened SAQs?
A few years ago, the PCI Council devoted a lot of time and effort to come up with three shortened SAQs. The Council created these SAQs by looking at the respective merchant environments and, in effect, marking “Not Applicable” for those PCI requirements that did not seem to apply. What remained became the SAQ.
The one common thread in each shortened SAQ is that the merchant cannot store electronic cardholder data. The simplest is SAQ A, designed for merchants who outsource their card processing. It addresses only two PCI Requirements and has just 13 questions. SAQ B is for POS terminal merchants. It address five PCI Requirements and has 25 questions. SAQ C is for merchants with a payment application connected to the Internet. This one addresses almost all PCI Requirements (11 out of 12), and we are now up to 80 questions. The new SAQ C-VT is aimed at virtual terminal merchants. It addresses only nine PCI Requirements—fewer than SAQ C—and has 51 questions.
Compared to SAQ D’s 280 items, any one of the shortened SAQs lives up to its name and is, therefore, attractive to any merchant who qualifies. My experience is that many merchants adopt the mantra “anything but SAQ D.” They review their business processes, eliminate storing electronic cardholder data, segment their networks and adopt any number of good security practices that reduce their risk and ease their PCI compliance work.
These are all good results, and I’m sure it is exactly what the PCI Council had in mind when it created the shortened SAQs. Nevertheless, it may be time to ask if we still need the shortened SAQs. After all, PCI has been around for a number of years, and evidence on recent data compromises indicates that the bad guys are targeting many small and midsize businesses—the very ones who could qualify for a shortened SAQ. Therefore, should not these merchants want to be secure and avoid a data compromise?
There is, however, one overarching argument to support requiring every merchant to use SAQ D: It is effectively required already, and mandating SAQ D would resolve the inherent hypocrisy in the whole shortened SAQ process. Here is what I mean.
The Council states in the SAQ Instructions and Guidelines: “According to payment brand rules, all merchants and service providers are required to comply with the PCI DSS in its entirety.” If that isn’t enough, each of the shortened SAQs comes with this statement:
-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.