This is page 3 of:
Is It Time To Eliminate Shortened SAQs?
If that isn’t enough, each of the shortened SAQs comes with this statement: “If there are PCI DSS requirements applicable to your environment that are not covered in this SAQ, it may be an indication that this SAQ is not suitable for your environment. Additionally, you must still comply with all applicable PCI DSS requirements in order to be PCI compliant.”
These provisions mean that regardless of whether merchants answer just 12, 25 or 80 questions, they still are expected to comply with “PCI DSS in its entirety.” That was the point the compliance officer was making when he told those merchants they should use SAQ D regardless of their payment environment. The Council has always held this position, and it repeats it (at least to us QSAs) whenever the subject of a shortened SAQ comes up.
Do I think the shortened SAQs will go away? No, or at least not soon. Literally millions of merchants are eligible to use a shortened SAQ. One option might be to use the shortened SAQs as compliance guides. The merchant would still need to go through the entire PCI DSS, but it would be up to them to identify the “additional requirements applicable” to their environment. Requiring everyone to use SAQ D would force merchants to consider explicitly each requirement and mark “N/A” where they think it is appropriate and considering their particular card-processing environment. This approach is consistent with the instructions for each simplified SAQ.
The alternative is to revise the shortened SAQs to more closely reflect the technical and business realities of the merchant and processor environment. For example, SAQs A and C-VT merchants access the Internet, but neither requires vulnerability scans; SAQ C requires the payment application be behind a firewall, but the critical requirements to log administrative access to that firewall or have file integrity monitoring on the application are missing.
Maybe the answer is to take a fresh look at each shortened SAQ to identify the “additional requirements applicable” in the real world. I’ll take a shot at that in a follow-up column.
In the meantime, what do you think? Should every merchant have to address the full PCI DSS? Do the shortened SAQs pose too much risk for the benefits of simplified compliance? Should they be downgraded to templates or guidelines rather than SAQs? Or should they be revised to reflect better how merchants operate?
I’d like to hear your thoughts. Either leave a comment or email me at wconway@403labs.com.
-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.