This week another outbreak of Magecart was detected in at least 19 eCommerce sites. It is using a new way to obfuscate and gather cardholder data (CHD). As I read through the latest description, it brought to mind SAQ A.
But before I launch into that diatribe, first a little bit of history so that everyone understands why SAQ A even exists.
In the early wild, wild west days of payment card security on the internet, enterprising solution providers were pandering “outsourced” solutions that would “avoid” compliance with the then Visa Cardholder Information Security Program (CISP) and MasterCard Site Data Protection (SDP) compliance efforts. What they were selling was a solution that used a variety of Web site techniques to keep the CHD away from the merchant’s Web site. These solutions sold themselves because they took the merchant out of scope from the very onerous Visa and MasterCard security programs.
Then along came the PCI DSS and the self-assessment questionnaires (SAQ). As part of that process, the Council and the Brands realized that these so-called out of scope solutions were not really “out of scope”. The result was SAQ A which covers these outsourced solutions. For years they had kept their solutions out of the card brands’ compliance programs and now they were included. SAQ A was good news, bad news moment for the solution providers. The bad news was that there was no escaping the fact that their customers were now in scope for PCI compliance. However, the good news was that to placate these solution providers who were lobbying loudly for no scope, the Council and Brands minimized the number of requirements in SAQ A to a very, very bare minimum so that these outsourced solutions would not scare their customer bases off due to PCI compliance.
Just for the record. SAQ A is the absolute bare minimum number of requirements any merchant can comply with and be considered PCI compliant. There is nothing less.
And Now The Jokes – Bad As They Are
The first joke is that SAQ A is the absolute prime example of compliance does not equal security, bar none.
Anyone that thinks compliance with SAQ A keeps their customer payments secure is seriously lying to themselves. Magecart in all of its forms is exhibit number 1 as to why SAQ A is a joke and should be retired.
I have told my clients since SAQ A was published that if they thought compliance with SAQ A would keep them out of trouble to think again. Yes, SAQ A keeps the processors, banks and brands happy, but it does nothing to manage the risk presented by any web site. That is because if the code/executable/script on their server that invokes the redirect or iFrame is ever tampered with (as with Magecart), it will not be the processor or bank held legally responsible, it will be the merchant that operates that web site that is legally on the hook.
That is the second joke of SAQ A. Merchants think they have pushed the payment card processing risk of their eCommerce operation off to a service provider and they have not. Unknowingly, they still have a lot of skin in the game. More than they realize or want to realize.
Yet time and again, I encounter merchants following SAQ A that blindly go about life without regularly patching, maintaining or monitoring their web site because “SAQ A says I do not need to do that”. All of this under the mistaken belief that SAQ A’s requirements create security for that web site which they do not. Sadly, I have also encountered a number of merchants over the years that have been caught in the SAQ A trap and found out the hard way the monetary and business costs of their beliefs in SAQ A protecting them from bad actors.
SAQ A Is Compliance Not Security
In the last update of the SAQs in 2018, the Council did address a minor shortcoming in SAQ A. That addition was to require organizations to ensure that their Web server was patched current for critical vulnerabilities. However, from a risk perspective for an internet-facing system, that did very little to ensure the security of merchant Web sites used for directing payment processing.
Notably, SAQ A does not require at least any of the following:
- Only one major service running, i.e., Web server with eCommerce application.
- External and internal vulnerability scanning.
- External and internal penetration testing.
- Critical file monitoring to identify if the redirect or iFrame invocation method has been tampered with.
- Logging and monitoring of the Web server and Web applications.
Most information security professionals would still likely consider even these aforementioned requirements inadequate. These are all items I have told my clients I recommend, but even these absolute bare minimum steps for securing a Web server are not required for SAQ A compliance.
As a result, is it any surprise that most information security professionals and most QSAs consider SAQ A worthless for anything other than PCI compliance? Organizations that truly understand information security also realize that SAQ A is not security and follow SAQ A-EP for ensuring the security of their out of scope Web servers.
The bottom line is that we in the payment security industry need to lobby the PCI SSC, banks and card brands to get rid of SAQ A before even more organizations get hurt.
PCI Guru 
With all respect, in the scenario you suggest SAQ-A is not applicable, in that case you may choose SAQ A-EP wich have a range of requirements for E-commerce scope.
There are a number of service providers that would argue otherwise. 😉
Guru,
Thank you for posts like these. It always helps immeasurably.
I would like to pose a different view point to SAQ A (and SAQ A-EP). I believe that SAQ A does serve a purpose, but one that is significantly more limited that what people want to use it for.
I submit that SAQ A is for merchants that utilize 3rd party services to list and sell their products. For example, I would expect Amazon, E-Bay and ETSY would fall into this category for the merchants that utilize these services to sell their products. Obviously Amazon, E-BAY and ETSY would have to comply as a service providers. But say I sell widgets on Amazon. I do not have access to the payment pieces beyond providing my account number to put the profits into. (Please understand that this is under the belief that these services don’t have a model that would allow me to have my own website in the mix here.)
As soon as a merchant puts their own web server (hosted or on-prem) in the mix, they would have to use SAQ A-EP. In SAQ A-EP, it specifies “requirements that refer to the “cardholder data environment” are applicable to the merchant website(s)”. I have discussed this with some of my business partners (in my company), and have decided that even if they put a phone number for payment or address to send payment information to, that web service would need to be protected the same as if they were using a I-frame or redirect to a processing page.
Just my thoughts on it.
Thank you for all of the information and dialog you provide. I find it very beneficial.
Craig
The only hitch in your comment is that some of these services do provide the merchant the ability to access and manage those hosted sites and possibly access payment processes. So it might not be as clear cut as you describe.
I follow this line of logic. However, I have two issues with these cloud based third party providers (Amazon, E-Bay and ETSY, etc).
PCI DSS will apply to the merchant account owner. Who owns the merchant account? If it is the service provider, the customer has no compliance reporting responsibilities. As an example, if I sell on Amazon, completely outsource everything to them, should I complete SAQ A and submit it to Amazon?
Enter the EULA.
The other issue I find frustrating is I have seen vague statements about security and compliance buried in EULAs (often it either claims the customer has no compliance obligations – “we do it all for you!” – or it links to a dynamic agreement no one ever reads that gets updated at the whim of the provider’s laeyers).
Until one of these service providers suffers a breach, I’m not sure anything will change with this business model.
I agree the greater risk is being responsible for hosting the site that links to a compliant service provider while claiming SAQ A sufficiently addresses the risk to cardholder data.
If the merchant does not have the account used for payments, then you are correct. This is how Square operates. Square is the merchant of record, not the person selling you the painting or jewelry at the art fair. Which is why those Square merchants know nothing of PCI compliance as it is Square’s problem.
However, what I am talking about here are merchants that have a redirect or iFrame to a processor that processes payments under the merchant’s account.
Well said.
Two additional complaints from my experience the last few years:
1) I have encountered a number of service providers whose only role is hosting and maintaining a website that redirects to a compliant third party service provider (take, for example, a WordPress site hosted with AWS).
When I inquire about their AOC, I am provided the AWS AOC. When I ask about the company’s AOC, they claim they are out of scope as the site doesn’t store, process, or transmit CHD. I then attempt to convey the phrase “or impact the security of cardholder data”, and the company often repeats it doesn’t touch cardholder data. I have been able to get a few of these service providers to engage a QSA to get a more thorough assessment, but some of these requests not do not get approval.
To your point, this complaint is about compliance. What about security?
2) Mobile applications (often using an iframe). I see this too frequently. The vendor claims their mobile app is out of scope as the app doesn’t store, process, or transmit CHD. I then pull FAQ 1283, and again highlight “has the potential to impact the security of CHD”. For all I know, someone’s nephew or niece developed this mobile app using youtube tutorials. I have encountered some vendors who have provided a self-signed SAQ A for their mobile app, claiming it to be evidence they are compliant.
In either case during normal times, a QSA engagement for compliance would presumably not be too taxing on the service provider for either scenario. Unless, of course, the service provider has poor security practice, which presumably a QSA would identify and help ensure remediation is addressed. But, that would still just address compliance. . .
Enjoy your site!