Why The SAQs Will Change This Year
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.
October is likely to see significantly revised Self-Assessment Questionnaires (SAQs) from the PCI Council. Few merchants will be more surprised than those E-Commerce merchants who have outsourced their card processing. Effective with PCI DSS version 3.0, many E-Commerce merchants will learn that their Web servers are in scope for PCI compliance and that SAQ A got a bit longer and a bit more complicated.
These merchants typically use the simplest SAQ, SAQ A. They also always (in my experience) consider their Web server out of their PCI scope, because that server does not “store process, or transmit” cardholder data. Instead, the server redirects the user to a PCI-compliant third-party service provider that processes the card transaction for the merchant. The conclusion is understandable. An E-Commerce merchant’s SAQ A addresses a very small subset of PCI DSS. It includes parts of only two requirements: physical security of backups and paper records that may contain cardholder data; and managing the PCI service provider.
Processing is outsourced, and it is outsourced to a PCI-compliant service provider. What could be simpler? Oh, and I should add: What could be more wrong with that conclusion?
This fall will see the release of PCI DSS version 3.0. I expect to see (finally) a recognition that an E-Commerce merchant’s server will be officially declared to be in PCI scope, even if it never stores, processes or transmits a single payment card.
At the recently completed RSA Conference, the PCI Council staff presented a session describing how merchants should determine which people, processes and systems are in their PCI scope. The PCI Council staff explored the outsourcing scenario described above. They then described a “redirection mechanism compromise,” whereby the bad guys compromise the merchant’s Web server. They either redirect the customer to a different site or intercept the cardholder data as it is passing through to the service provider.
Regular readers of this column know I have hoped the PCI Council would update SAQ A to reflect precisely the type of compromise described by the Council’s staff and by Visa Europe. In truth, all the SAQs are due for an overhaul, and I expect they will receive that treatment.
I am not privy to any PCI Council or card brand discussions of how SAQ A or any of the SAQs will change. Looking at the slide deck the PCI Council presented at RSA and the recently released E-Commerce Guidelines, it may be that at least parts of several PCI DSS Requirements will be added, for example:
- Requirement 6 (Develop and Maintain Secure Systems and Applications), for the shopping cart (and maybe require it to be PA-DSS validated).
- Requirement 7 (Restrict Access to Cardholder Data by Business Need to Know), applied to the merchant’s Web servers and network.
- Requirement 8 (Assign a Unique ID to Each Person with Computer Access), especially 8.3 governing remote access.
- Requirement 11 (Regularly Test Security Systems and Processes), especially 11.2, which requires passing both internal and external vulnerability scans quarterly.
What do you think? I’d like to hear your thoughts. Either leave a comment or E-mail me.
-Marc
April 2nd, 2013 at 8:54 am
Thanks for bringing this topic to the forefront. I often hear ecommerce merchants say that because they use a transparent redirect or direct post method that tokenizes in the browser that they are totally compliant. And when I ask about securing their web servers that originate the payment form, there is usually a long pause, followed by “oh yeah, but we’re still compliant”. With the growing number of insecure sources pushing content to the browser, like ad servers, chat, and analytics modules, the number of attack vectors increase BEFORE the PAN is even input by the cardholder. Maybe in the new mandate, ‘capture, transport or process’ can be preceded by a word like ‘isolate, prevent, segment, harden or protect’ when it comes to the merchant web servers that get the payment acceptance party started in the first place.
April 2nd, 2013 at 11:48 am
Better clarification by the PCI council is good. It is still unclear to me how to deal with multiple vendors supporting the website — each saying they have no access to PCI data. How is a merchant supposed to figure it out?
And, by the way, in my experience, the bank/processor and assessors look for the easy way to grant compliance. Which may help in the short term but not in the long-term if there is an eventual breach.
April 4th, 2013 at 3:12 am
I doubt they will be so strict. Let’s see come October. I can’t see a way all websites with a link to a compliant payments page could possibly be made in scope.
April 9th, 2013 at 4:55 pm
Level 4 merchants are the fastest growing target group suffering data breaches. There is a massive explosion of compromises where Level 4 merchant web applications are being compromised with the specific goal of hijacking payment mechanism redirects. This is a huge problem that is growing exponentially. Most Level 4’s falsely believe they are too small of a target for a breach, but the criminal groups know that, and they know that “Bob’s Comic Shop” can’t afford an Imperva WAF, and can’t use an open source WAF in their GoDaddy/Dreamhost/whatever $10/year hosting account, and they don’t even know how to begin reviewing their logs. They are using automated mining techniques to find common vulnerabilities, exploit them, hijack the payment mechanism, and move on quickly. Multiply that by hundreds of servers a month and the money starts to add up quickly. What is most likely to happen is that any web application that initiates a redirect to an in-scope payment mechanism/web application will be included in scope for PCI. This will end up being a positive thing for merchants as it will finally bring forth the reality that the entire process needs to be secured and protected.