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 