Tag: certificate

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!

PCI-DSS:Say No to Certificates

For those who have been reading this blog long enough, you would know that we are absolutely, completely, mind-numbingly devoted to the anti-certificate movement within the PCI-DSS. Really. And every single month, almost, it never fails that we get enquiry that our customer or their acquirer are demanding to see the precious certificate of compliance. And rejecting the AoC. Rejecting the RoC.

It has truly become so farcical in PCI-DSS when acquirers – banks! – demand this of our customers. To an extent that even our customers give a wry shrug at us, the way my wife and I would shrug at each other when my kid tells us that he just witnessed an elephant doing hoola-hoops in a tutu in his kindergarten that morning.

We have written it before and will keep writing it till the horn sounds for the second coming: Compliance ‘certificates’ are NOT recognised by the PCI-SSC! PCI-DSS seals with those wondrous badges (like the police etc) are not recognised by the PCI-SSC. In the words of the council:


The only documentation recognized for PCI DSS validation are the official documents from the PCI SSC website. Any other form of certificate or documentation issued for the purposes of illustrating compliance to PCI DSS or any other PCI standard are not authorized or validated, and their use is not acceptable for evidencing compliance. 

PCI COUNCIL REMONSTRATING TO ALL PRO-CERTIFICATES TO STOP DOING THIS NONSENSE

So banks – please, please, for the sake of all that is good and worthy in our God given Earth – DO NOT demand your providers/customers/merchants to show the certificate of compliance. It’s ridiculous and it demonstrates that you, an entity that should know PCI first and foremost, are absolutely not doing your job well. You are making demands for things that are considered unauthorized and unacceptable!

We are not saying certificates are illegal or those peddling these certificates are cheating anyone. By far and large, all QSAs generally provide these so called certificates as an easy way to illustrate compliance, or just to have the customer frame it up and put it onto their wall. This is perfectly, absolutely fine. Even our QSAs do it. It’s not the problem with the QSAs putting these certificates out. The problem are with the acquirers or those demanding to see PCI compliance from their merchants/providers etc. Banks, financial institutions etc who refuses to see anything else but the ‘certificate’ as evidence of PCI-DSS compliance. It’s frustrating. Yes, most clients will be able to provide these ‘certificates’, but where it boils us up is when the acquirer refuses to accept the RoC and AoC as evidence of compliance! WHY NOT? Because likely the person in the bank requesting PCI-DSS have zero clue what PCI-DSS is , or what it’s supposed to be, in the first place.

Banks, here is a simple illustration:

Would you accept the below as proof of compliance:

Or would you accept the one below:

If you answer the first one, then the question is why do you reject the second one?

“Well because it looks fake and it looks like its scrawled by a two year old, or a random hamster running around on a paper with ink on its paws,” you reply.

Well, guess what?

Both should either be rejected, or accepted because both are of the same value. SAME VALUE. Just because one certificate isn’t designed as aesthetically nicer than the other doesn’t make it less of a certificate. Why? Because the baseline worth of the certificate is zero. There is ZERO value to the certificate on paper. The only value attached to it is from the viewpoint of the person looking at this worthless piece of paper and going, “Hum, that looks nice.” or “Hmm, that color looks off.”

I know this may sound like an over-reaction, because at the end, since Certificate of Compliance is now the norm (due to these demands) – everyone who has an AoC would probably have a certificate as well, right? Well, what about those doing their own SAQ? Do they design their own Certificate then and say this is a self attested cert? So, Mr Bank, how do you wriggle yourself out of this scaffafle? Why do you place so much value into something that (according to PCI SSC) is absolutely worthless, and do not focus on the actual documents that are worth something? And worse of all – to actually reject the documents that are formally from PCI-SSC and accept only these glorified certificates that are worth as much as the paper its printed on!

I think, the only resolution to this is to completely do away with PCI certificates. The next person touting these certificates as the only means of PCI validation, we are going to show them that certificate that’s drawn by the hamster and see what they say.

Jokes aside – let us know if you have any questions on PCI-DSS or any security compliance in your company – we are always willing to help out – drop us a note at avantedge@pkfmalaysia.com.

© 2021 PKF AvantEdge

Up ↑