As you can see in my barely updated linkedin page, I’ve been a CiSO for many years.
Since 2013, I’ve seen many different merchant profiles.
Sadly I also saw many data breaches, and more specifically Cardholder Data breaches.
Most of our customers back then got hacked through a variety of means, the most popular being unpatched CMSes.
They all shared a glaring, unforgiving trait : PCI-DSS requirements were not being followed.
What impact are you looking at ?
In some cases merchants believed in good faith they were not supposed to carry out this or that task.
In other cases they were quite happy to brandish the “I didn’t know” argument (which afforded no practical defense whatsoever, let it be known).
In yet other cases it was plain reckless disregard for the rules.
Either way I saw merchants get burned, I saw payment schemes fine them between $5 and $10 per stolen card and upgrade their PCI-DSS requirement to Level 1, requiring a yearly on-site audit, regardless of processed volumes.
- You’re looking at plummeting investor trust and stock valuation.
- You’re looking at a tarnished reputation and brand name.
- You’re looking at heavy fines.
- And you’re looking at a $50k yearly audit, and that’s not even accounting for the extra personnel you’ll need to assign to do the job.
I’m not asking you trust me blindly, see for yourself back in 2014 :
Image credit CNN. Source.
The point is, you’re looking at major trouble.
You want none of that when you’re the actual CTO, COO, or CEO.
Serverless Computing London 2019
While attending the Serverless Computing conference in London, 2019, I had the opportunity of hearing a presentation from a UK company.
They claimed they’re running on GCP so they’re entirely compliant automatically.
When I subtly pointed out that might not be sufficient to achieve compliance and that, perhaps, they should run HR screening, review code, hold training sessions, enforce change management processes… they replied that they don’t need all that because they’re compliant thanks to GCP.
Trust me, the moment they have a severe PCI-DSS breach, they’re going to hurt a lot.
Let’s not do the whole list, it’s going to get old real quick.
The key takeaways here are :
You’re NOT exempt from PCI-DSS requirements just because your PSP is certified.
You’re NOT exempt from PCI-DSS requirements just because your hosting provider is certified.
The different SAQs
There are many different Self-Assessment Questionnaires one may fill to declare PCI-DSS compliance.
The 3 most common are represented below :
Image credit Google Cloud Platform. Source.
SAQ-A, we love you ’cause you’re easy
To get it out of the way, let’s take a look at the simplest, smallest, easiest SAQ.
The PCI-SSC’s wording for SAQ-A eligibility is exceedingly clear and unambiguous :
SAQ A has been developed to address requirements applicable to merchants whose cardholder data functions are completely outsourced to validated third parties, where the merchant retains only paper reports or receipts with cardholder data.[…]
Additionally, for e-commerce channels: All elements of the payment page(s) delivered to the consumer’s browser originate only and directly from a PCI DSS validated third-party service provider(s).
And again there is no need to trust me blindly when you can get it straight from the source, page 3 of the PDF.
There can be no mistake here, and the “additionally” section clarifies : the instant your company personally has anything to do with the payment page, even if you’re merely hosting it, you’re not eligible to SAQ-A anymore.
If you read the SAQ-A, you’ll notice you still have some directives to comply with, namely in requirements 2, 6, 8, 9 and 12.
SAQ-A-EP, we love you
a little bit somewhat less
Okay so you’ve not outsourced your entire payment transmission, storage, development and hosting to a certified third party.
Maybe you still qualify for SAQ-A-EP:
SAQ A-EP has been developed to address requirements applicable to e-commerce merchants with a website(s) that does not itself receive cardholder data but which does affect the security of the payment transaction and/or the integrity of the page that accepts the consumer’s cardholder data.
This critical bit is the part people usually ignore, to pretend they can do with a simple SAQ-A.
SAQ-A-EP is undeniably harder to comply with, being no less than 47 pages long, up from SAQ-A’s 14.
With directives from chapters 1 through 12 of the PCI-DSS, SAQ-A-EP takes you through a veritable voyage, a preview of the full PCI-DSS compliance requirements.
And this is where things get ugly.
People don’t want, just because they’re merely hosting their “pay” button, to have to go through this whole SAQ.
Is it not much easier, much simpler, and much less costly to just pretend you did not see the fine print, that you genuinely thought SAQ-A applied to you ?
(I’m not saying everyone does this in bad faith, I’m saying it happens, and that’s a terrible Risk Management decision)
I’ve seen it happen, I’ve seen this exact scenario where the “pay” button was modified so it would direct to code under the hackers’ control, which in turn led to Cardholder data theft.
I’ve heard CEOs’ voices break and quaver over the phone as the implications for their business and stature dawned on them.
I’ve heard CTOs claim it was our fault, that we were the ones that had been hacked.
And every single time, after a PCI-approved Forensics job, the breach was on their end.
I do not wish this on people I dislike, I wish it less so on people I am neutral about.
This is serious stuff.
Check what SAQ you’re really eligible for, challenge your technical teams, challenge your CiSO, your CTO, your Risk Officer, your Compliance Officer.
Challenge everyone, and keep asking “why ?” until you’re satisfied.
Right, you’re not eligible for SAQ-A, nor SAQ-A-EP, and you do not fall under the conditions for the other weird SAQs.
That leaves SAQ-D, and stay seated because this one’s another beast entirely.
SAQ-D tops out at 77 pages.
Out of the 3 SAQs we’re talking about today, only the actual PCI-DSS is longer at 139 pages total.
SAQ-D for Merchants states :
SAQ D for Merchants applies to SAQ-eligible merchants not meeting the criteria for any other SAQ type. Examples of merchant environments that would use SAQ D may include but are not limited to:
- E-commerce merchants who accept cardholder data on their website
- Merchants with electronic storage of cardholder data
- Merchants that don’t store cardholder data electronically but that do not meet the criteria of another SAQ type
- Merchants with environments that might meet the criteria of another SAQ type, but that have additional PCI DSS requirements applicable to their environment
If that’s you, my sympathies, you’re in for a ride.
SAQ-D for Merchants features sub-requirements from main requirements 1 through 12.
You’ll be assessing your systems and networks, your vendor-default credentials, your transmission channel encryption, or maybe even your card storage mechanics, retention, transfer and secure removal procedures.
You’ll need to take a good look at your patch management, vulnerability watch, or periodic penetration testing.
At this point, to be entirely fair, SAQ-D becomes an actual Risk Assessment item at Tier 1 of NIST SP 800-30 (page 17 of the PDF).
Make no mistake, PCI-DSS is a Strategic change, even if you’ve already gone through the ISO27k series or similar.
This is the moment you call your Risk Officer, your Compliance Officer, your CTO, and you have them explain to you in clear and certain terms their ability to carry your company through this change.
This is the moment you grit your teeth and allocate the extra 30k budget for consulting or assistance, because ignoring PCI-DSS requirements will get right back at you.
On a parting note, if your company is well-structured and/or solid financially, you could do much worse than enrolling a few of your best staff in the ISA program.