Why The SAQs Will Change This Year

Written by Walter Conway
April 1st, 2013

A 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.


4 Comments | Read Why The SAQs Will Change This Year

  1. Greg McGraw Says:

    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.

  2. Janet L Says:

    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.

  3. Joel D Says:

    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.

  4. Trusted User Says:

    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.


StorefrontBacktalk delivers the latest retail technology news & analysis. Join more than 60,000 retail IT leaders who subscribe to our free weekly email. Sign up today!

Most Recent Comments

Why Did Gonzales Hackers Like European Cards So Much Better?

I am still unclear about the core point here-- why higher value of European cards. Supply and demand, yes, makes sense. But the fact that the cards were chip and pin (EMV) should make them less valuable because that demonstrably reduces the ability to use them fraudulently. Did the author mean that the chip and pin cards could be used in a country where EMV is not implemented--the US--and this mis-match make it easier to us them since the issuing banks may not have as robust anti-fraud controls as non-EMV banks because they assumed EMV would do the fraud prevention for them Read more...
Two possible reasons that I can think of and have seen in the past - 1) 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. 2) Also, in offline chip countries the card determines whether or not a transaction is approved, not the issuer. In my experience, European issuers haven't developed the same checks on authorization requests as US issuers. So, these cards might be more valuable because they are more likely to get approved. Read more...
A smart card slot in terminals doesn't mean there is a reader or that the reader is activated. Then, activated reader or not, the U.S. processors don't have apps certified or ready to load into those terminals to accept and process smart card transactions just yet. Don't get your card(t) before the terminal (horse). Read more...
The marketplace does speak. More fraud capacity translates to higher value for the stolen data. Because nearly 100% of all US transactions are authorized online in real time, we have less fraud regardless of whether the card is Magstripe only or chip and PIn. Hence, $10 prices for US cards vs $25 for the European counterparts. Read more...
@David True. The European cards have both an EMV chip AND a mag stripe. Europeans may generally use the chip for their transactions, but the insecure stripe remains vulnerable to skimming, whether it be from a false front on an ATM or a dishonest waiter with a handheld skimmer. If their stripe is skimmed, the track data can still be cloned and used fraudulently in the United States. If European banks only detect fraud from 9-5 GMT, that might explain why American criminals prefer them over American bank issued cards, who have fraud detection in place 24x7. Read more...

Our apologies. Due to legal and security copyright issues, we can't facilitate the printing of Premium Content. If you absolutely need a hard copy, please contact customer service.