Month: November 2020

PCI-DSS: The AoC Problem

pci-compliance
pci-compliance

Recently we were reminded once again why we constantly state that PCI-DSS must chuck away the Certification of Compliance for good. Not only it’s an unacceptable documentation to the PCI Council, but it presents a lot of problems for auditors and assessors, as well as organisations seeking PCI-DSS compliance evidence from their service providers.

Let’s go back to how PCI-DSS flows in the first place.

PCI-DSS applies to all organisations that store, process and transmit credit/debit card under the umbrella of Visa, Mastercard, Amex, JCB and Discover/Diner.

Requirement 12.8 further extends the need to manage service providers where card data is being shared, and where “they could impact the security of the customer’s cardholder data environment”. That word is key because many service providers we have spoken to retorts they are out of scope of PCI-DSS of their clients because:

a) They only provide infrastructure and has no access to card data

b) They only store physical copies of forms that are sealed in boxes and they don’t access it

c) They only provide hosting

d) They only provide customer service support

e) They only provide toilet cleaning services

Of the 5 most popular services above, only the last one, we can probably surmise, does not require PCI-DSS. The rest – not to say they are 100% applicable – would require at the very least a bit of scoping to determine if they are applicable or not for PCI. Such is the problem here.

Having established that even, say a cloud service provider that only provides IaaS, requires PCI-DSS, what is then the next problem?

We call it the problem of the AoC. Or rather, the lack-of-AoC. Or more accurately, the-refusal-of-service-providers-to-provide-AoC-since-they-already-have-the-Certificate-of-Compliance problem. Its a very long problem name, so we will just call it the Problem of the AoC.

The AoC is the Attestation of Compliance, which is basically a shortened version of the Report on compliance (ROC) or the Self Assessment Questionnaire (SAQ). So in ALL PCI-DSS Compliance, whether assessed by 3rd party or self assessed, there is an AoC. 100%.

This AoC will describe in summary what are the processes in scope of PCI-DSS AND services that are NOT in scope of PCI-DSS. This is absolute key. In Part 2 of the SAQ, it states the type of service and the name of Service included in the PCI-DSS compliance (below):

Right after that, we need to ensure there may be services being offered that for some reason is NOT assessed for PCI. An example here could be a company offering BPO services, but at the same time offering a payment gateway service. They could be PCI compliant for payment gateway but not compliant for their BPO – even though both would deal with credit cards. So we need due care in determining whether the service we are procuring from them is indeed, PCI Compliant.

This is very important. And the fact that most “Certificate of Compliance” actually does not state the scope of services under PCI-DSS, presents a problem for assessors.

We once had a very animated discussion with a large service provider providing a customer support application to our client that collected credit card information. The service provider insisted they are PCI-DSS compliant and they showed their ‘Certificate of Compliance’. The said their AoC is private and confidential and all of their customers have accepted their Certificate as proof of their compliance, which meant, we are obligated to accept it as well (according to their very animated representatives).

Now, we all know the Certificate of Compliance is as valuable as toilet paper (actually, maybe less, since toilet paper can sometimes be VERY valuable during the pandemic and panic buys) – so we insisted on them showing us their AoC. For the simple reason:

They offered the on-prem application to our client, i.e installed onsite to our client’s environment. Our client says since this application is ‘PCI-DSS’ compliant, we should not need to assess their application under Requirement 6 of PCI-DSS. Hmm.

This doesn’t sound right. The vendor kept insisting that PCI-DSS only requires them to show their Certificate, and that the information in their AoC are private and confidential and we have no right to request from them.

PCI-DSS is applicable to an environment, process and location. You can see these ALL clearly in the AoC. Not in the nonsensical and utterly useless Certificate of Compliance. Why we didn’t believe this was that, because the application was installed in our client’s environment, there shouldn’t be an instance where this application is “PCI-DSS” compliant. At most, they could claim an application to be PA-DSS compliant (or the new SSF compliant) – but that is also impossible as their application wasn’t a payment application related to settlement or authorisation – so it’s not eligible for PA-DSS! So how can this be ‘PCI-DSS Compliant’?

We were at an impasse. Because they refused to give their AoC, we refused to accept their Certificate of Compliance. They lodged a complaint, we stood firm. We were not going to pass our customer on the basis of some hocus-pocus documentation which was clearly NOT acceptable to the PCI council!

Finally, they relented, and gave us a redacted, valid AoC and telling us how wrong we were in insisting on this and we did not know what we were doing. But all we needed to see was the page above – where the scope of compliance was summarised. And in it, stated “XXXX Customer Service Cloud Solution”.

Cloud solution.

We asked the customer, did they subscribe to the cloud solution?

No, they didn’t. It was an on-prem. Installed, lock stock and barrel application into the VM managed by our client. In an environment and location secured by our client.

Wait, said the vendor. The on-prem solution is the same as the cloud solution backend they were using and have been assessed for PCI. So what was our problem? The only difference was that their ‘cloud solution’ was now installed on customer side, so this should still be acceptable.

So, well, that isn’t a cloud solution then, is it? I mean, if you have a secured safe and you put it into your high-security house, would that also mean you can put the same safe in the middle of Timbuktu somewhere and still have the same level of security? (No offense to Timbuktu, we are just using that as a reference…we should stop using it actually but oh well.) Wouldn’t the cloud solution also be assessed for its environment, processes and policies? Would this be the same on the customer end?

The point here, is that based on the AoC, we can clearly say that the PCI compliance isn’t applicable to the on-prem solution. So we still have to assess the application as it is, under Requirement 6, under the client’s PCI program.

This isn’t any ‘victory’ or whatever we can claim, but it is so extremely frustrating to waste so much time on matters that would not be any issue at all, if the problem of the AoC is resolved. Just HAVE THE AoC TO ATTEST PCI-DSS! And stop this Certificate baloney! Because of this, we end up behind schedule and we have to chase up again and again.

So, read the AoC thoroughly before you decide on a vendor/service provider – because the certificate they provide to you could very well be invalid to the services they are actually offering you. Insist on the AoC.

Drop us a note at pcidss@pkfmalaysia.com to know more about your compliance. We will respond to you immediately!

ASV Scans /= PCI Compliance

There is an old story about a chicken and eagle. I hear this story being told by life coaches or motivational trainers trying to get through to our thick, jaded, technical skull that there is something more to life than coding and technology.

The abbreviated version is this: A farmer was walking and finds an eagle’s egg fallen out of the nest. He picks it up, brings it back to his farm, and puts it into the chicken coop. Soon, it hatches, and joins the other chickens in the farm and learns how to be a chicken, even though its an eagle. So this is where some of the version diverges.

a) The chicken and the eagle starts talking one day and the eagle notices another eagle flying high in the sky and he goes, “Dang, I wish I could be an eagle,” and his chicken-pal looks at him scornfully and says, “You are a chicken. How can you be like the king of all birds, soaring through the sky?” So the eagle keeps thinking he is a chicken and the next day he gets roasted for dinner. And the farmer finds his meat a bit tough and doesn’t taste like chicken at all. The moral here is: Don’t let your limitations inhibit you or you will end up a cooked and eaten. This is probably the original version before the other two came along below:

b) The farmer is visited by a naturalist who observes this ‘chicken’ and immediately knows he is an eagle. So he takes this chicken up to a high cliff, and throws him over, shouting: “Spread your wings and fly! Soar like the eagle you are meant to be!” And the eagle soars through the clouds and sky and become the king of all birds. The moral of the story: All of us are eagles, even if you think you are a chicken. All you need is a life coach or a motivational trainer to throw you off the ledge and you will soar. This is the preferred version for life coaches and motivational speakers. For obvious reason.

c) Same as story b) above, but instead of soaring, the naturalist throws the ‘chicken’ off the ledge, and it falls 100 feet and splatters its brains all over the bottom of the ledge and dies since it doesn’t know how to fly. And gets cooked and roasted for dinner. The moral of the story (and this is by far, our more preferred, realistic and risk-averse version): Don’t do something you may be destined for but not ready for. Or you will end up smashed, cooked and eaten.

All three versions have this theme in common: The eagle isn’t a chicken and the chicken isn’t an eagle. The chicken may have commonalities of an eagle, like wings and a beak, but just because it has those doesn’t make it an eagle.


Yes, I am aware that the anecdote above isn’t a very good illustration of the point I am trying to make, but I couldn’t think of a better one. And in a roundabout way, what I want to illustrate here is that ASV scans do not make you PCI Compliant.

We get this a lot.

A company would come and say they are PCI-compliant. Or we have a client who outsources certain portion of their operations to another company and that company comes back and shows us their ASV compliant scan and says this is all they need to show us. We (The auditors/consultants) are compelled to accept this because the ASV scans demonstrate their PCI Compliance, they say.

Let’s make a point here: ASV questions and subquestions in the SAQ D covers around 14 queries. Out of around 600. That means ASV covers 2.33% of PCI-DSS. There is a massive load of other controls and items covering PCI-DSS Other than those precious ASV quarterly scans. What about your patching? Hardening? Firewall security? HR policies? Logging and monitoring? Logical access? MFA? Hardening of systems? Anti-virus and host firewalls? What about service provider management? What about vendor default passwords? What about storage, encryption, key management? Software development? Application and penetration testing? Internal vulnerability scans? Training?

You can see how impossible it is to accept just the ASV report as an evidence of PCI compliance, much like how we cannot accept the chicken as an eagle, but yet, we are constantly berated upon that we don’t know what we are doing and that their Banks have accepted their ASV scans as a sign of PCI compliance, so we should to. But we can’t. We can’t accept 2.33% as a 100% of something. It’s simply mathematically not possible.

So there you go – banks. Why do banks perpetuate this myth that PCI compliance = ASV scans? Why? It’s 2.33% of PCI-DSS! You can’t accept something as an eagle just because it has wings and a beak! There’s really no argument about it.

Here is what 2.3% feels like:

a) The number of Jazz music of all US Music sales in 2013

b) Increase in slot machine spending in New Zealand in 2018 Q1

c) Auto parts industry against the US GDP in 2013

d) Android 6.0 Marshmallow installation for all Android devices in July 2016

e) Thats lesser than the % of freshwater we have on this planet (2.5% of water on the planet is freshwater)

I am sure there’s a lot of 2.33% out there on this planet, but the point we are making is this: It’s not compliance. It’s a small but important part of compliance but it’s not compliance. So no matter what your banks tell you, we can never accept the ASV scan as a sign of PCI compliance. It can be accepted as one of the evidences of PCI compliance amongst many, but not as an evidence of complete compliance.

Now, stop calling a chicken an eagle. Let us know about your questions for PCI or any compliance at pcidss@pkfmalaysia.com.

© 2021 PKF AvantEdge

Up ↑