PKF AvantEdge

Tag: aoc

PCI-DSS: The AoC Problem

November 28, 2020 / / 0 Comments
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: Internal Audit Signoffs

April 17, 2019 / / 0 Comments

After going through previously the nightmare of PCI-DSS Certificates, as described with considerable detail in our writeup previously, we are now faced with a new phenomenon called the Internal Audit Signoff, which is further confusing our clients.

OK, first of all, let’s do a brief recap.

How are 3 ways that PCI-DSS can be validated?

Answer :

  1. Full Report of Compliance (RoC) from QSA – Level 1 Service Providers, Level 1 Merchants
  2. Self Assessment Questionnaire (SAQ) signed off by QSA/ISA – Level 2 Merchants, (Maybe) Level 2 Service Providers
  3. Self Assessment Questionnaire (SAQ) signed off only by Merchant/Service provider – Level 3,4 Merchant, (Maybe) Level 2 Service providers

Those are the 3 endgames for PCI. And of course, the end scenario called Failure, or non-Compliance. But that isn’t cool, unless you are the type who is happy with Thanos snapping his fingers being the definite end to all things.

Now we all know item 1) requires the participation of a third party QSA/ISA to signoff on the Report of Compliance and the Attestation of Compliance. ISA here is internal security auditor. We won’t touch it this round, because this requires a whole new library of articles to discuss.

Item 2) likewise requires a third party QSA/ISA to signoff on the Self Assessment Questionnaire and the Attestation of Compliance.

Item 3) is basically, self signed – not a lot of acquirers take this seriously as basically, its anyone signing off anything they feel like. There is no validation, and sometimes, it’s akin to the CxO sticking a finger to the tongue and putting it up in the air and going, “Yeah, that feels ’bout right. Let’s sign off and say we have these controls!”

Let’s talk about item 1 and item 2.

In item 1, it’s a gimme that the QSA needs to go onsite to the locations to do an audit. I have never heard of any QSA signing off on a full RoC without actually going onsite. Maybe when our tech reaches a point where the QSA can be holographically present in a location and see what’s there without being physically there like a Jedi Force Ghost, that the PCI-SSC would accept the signoff. But by then, we could probably just tell PCI-SSC that these aren’t the companies they are looking for, and then there’s no need to do PCI.

Until then – the question is for item 2, for the QSA to signoff the SAQ, must they be onsite or they can provide a remote signoff?

Now if you ask a QSA what is the difference between 1) and 2), they would say, not much – except they don’t have to waste their time writing the tome called the Report of Compliance (ROC) for level 2. Level 2 is basically a judgement made by the QSA based on existing evidences that what is stated in the SAQ is true, or at least as much as they can have reasonable assurance on. The SAQ is not a document written by the QSA, although they can help, but in this case they are validating it. For Level 1, it’s a different story. They have to write the RoC and the work put into that reporting phase is surprisingly a lot. In comparison, it’s probably like reviewing a first term essay paper written by your senior students (SAQ Validation) versus writing the Silmarillion including the index (RoC).

However, for QSAs to conduct their audit and provide a fair opinion on the controls, they will still want to be onsite for option 2), much to the chagrin of many of my customers. Their argument here is: “Hey I am level 2, why must you come onsite??” And again, the crescendo grows that a Level 2 should have less things to worry about than Level 1 – another myth as old as us telling our children not to sleep with wet hair or else they will wake up with a storming headache.

To get to the bottom of this, we got directly from the horse’s mouth (in this case from Mastercard SDP program response: “In this scenario (describing item 2) the QSA has to be onsite. The QSA cannot simply review a RoC or SAQ without being at the location to validate that controls are actually in place.”

To be fair, the above discussion was applied to L2 Merchants (Level 2 Merchants) – those making more than 1 million volume card transactions per annum. Whether the QSA is willing to take the risk and perform an offsite review for a Level 3 or level 4, I wouldn’t know – that’s up to the QSA and the card brands I suppose. But to be absolutely safe, we would advice that all levels should be treated as such – if you need a QSA to signoff, that QSA needs to be onsite to get it done. Or use the Jedi Force Ghost. Both are acceptable to PCI-SSC I am pretty sure.

So, as an illustration, we had a request from a company, requesting us, for their location, to get the QSA to signoff remotely. Because “The Other QSA did it for us and certified us”. The other QSA meaning someone they engaged earlier.

OK – this certification term again. I am sure that did not happen – but many use the word certification for anything: actual RoC, doing the SAQ with QSA, signoff on SAQ by themselves, getting ASV scan etc…those are typical scenarios we see this certification word being thrown.

Digging further, we received a worksheet which was a typical ‘Scope’ document (you know, where they ask what sort of merchant you are, what business, how many locations, devices, whether you store card etc), and the instruction was to fill this up, send it over to the QSA and the QSA will ‘sign off’ their PCI-DSS compliance, all within 2 weeks.

QSA certified within 2 weeks, remotely, and with just the scope document, without validating any controls? No penetration testing or ASV? No Risk assessment? No review of information security policy? How?

We asked for the copy of the official signoff page (Section 3c of the AoC) but instead we got a signoff on a report from QSA stating what was scoped in and what was scoped out of PCI-DSS. A typical scope document. It’s a useful document, but it’s not a document required by the PCI SSC. In fact it doesn’t serve any purpose other than to simply state what is in scope for PCI-DSS based on the scope questionnaire (not the SAQ) provided by the QSA.

I am 100% sure the QSA meant well by this, but the problem was, there are interpretation issues. We cannot expect clients to right off the bat understand PCI-DSS and all it’s seemingly malarkey documents – the AoC, the RoC, the 9 different SAQs, the ASV scans, the partridge in the pear tree etc. So when we asked for a SAQ signed off by QSA, of course, clients will fall back to any document being signed off by QSAs. That’s why we are not big fans of the practice where clients are provided by ASV certificates just because they passed their ASV scans. They all think they are PCI certified because they have a QSA signed off document which is the ASV ‘certificate’! And the same here goes, this is simply a scope review document – almost like an internal audit report, that does not make a company PCI compliant. In fact, it is just confirming that the company MUST be PCI compliant according to the scope set.

So the moral of this story is: Not all QSA-signed off documents are valid documents for PCI-DSS. ASV scans, while valid, doesn’t make you PCI compliant. It’s only a small percentage of what you must do. Internal Audits or scope reviews like the one we saw, even signed off by the QSA, are not valid PCI-DSS documents. They do not make you PCI compliant. As PCI has explicitly stated before, the only valid PCI-SSC documentation are the AoC, SAQ, RoC and ASV scan reports (not certificates, with flowery borders and impressive cursive fonts in gold). Anything else are supplementary materials used to support the compliance, not to validate it.

For more clarity on PCI, drop us an email at pcidss@pkfmalaysia.com. We will try to sort any issues you have, and yes, we are the company you are looking for.

PCI and Multi Processing Environments

March 31, 2017 / / 0 Comments

PCI

Since our last post, we have received some queries from other companies asking us about their PCI compliance. Just to be clear, we do not charge a fee for replying to your email and assisting you make sense of this compliance. We know how frustrating it is, and no, anyone that tells you that PCI is easy as 1-2-3 isn’t really letting you know the full picture. This is because some emails had been – “I have this question, but wait, if you are going to respond and charge me a fee, then don’t bother.” What are we, mercenaries? Yes we are a company requiring profits and not an NGO, but over the 7 years we have been involved in PCI, we have actually done a fair bit of advisory without charge, just to get PCI awareness out there into the market.

So, to save the trouble, I’ll put up a public post here to sort some of the questions out. This question, we have been getting a fair bit: What if the company has a multiple processing environment? What does this mean?

Let’s say, a retailer. It has a POS environment whereby they run standalone terminals connecting to the bank for purchases in their store. Credit card is used here – card present transactions. Then they launch their e-commerce site, which redirects all card non-present transactions to a PCI certified payment gateway, where the card collection page is hosted by the gateway.

You see here – there are two different channels for credit card interaction. The traditional POS, and the e-commerce site. Both are completely outsourced – one is direct dial up to the bank, the other to the payment gateway. So how do you deal with this?

You have two options – one is to do separate SAQs for both environments. Yes, you can. In the example above, doing an SAQ B for your POS environment and an SAQ A for your ecommerce environment (assuming you are level 3 or 4 merchant) should be able to suffice. The second option is to combine these channels into one SAQ. Once you do that however, you won’t be able to go through the ‘specialised’ SAQs. Specialised SAQs are like A, A-EP, B, B-IP, C, C-VT – meaning they have conditions in which you need to adhere to in order to use them. For instance for A, it says that this will only apply to merchants with card non-present business. And likewise for B, it has condition that you do not store card information electronically and is not applicable to e-commerce merchants. So when you don’t fall into any of these SAQ buckets, you end up with SAQ D-MER, which basically covers everything in PCI. But don’t worry, you a lot of the SAQ would be non-applicable in this case, and only those related to outsourced e-commerce and POS facilities would apply.

Now another related question, and one that I ended up having a 2 hour discussion with a client on = can an entity be both merchant and service provider?

The short answer is yes, you can.

An example would be a telco. Telcos generally have massive merchant business. They accept payments for their pre-paid, post-paid etc from end customers through e-commerce, POS channels etc. But the Telco could also support a manage services and hosting environment whereby other merchants are hosting their payment sites on. Then, now you have a service provider environment.

Or, it could even be within the same organisation, you have your merchant business of a payment portal, Mobile POS, or mobile app, connecting to an outsourced payment gateway. Suddenly you decide you want to set up your own payment gateway and channel all the transactions of your merchant business to your own payment gateway.

In the first instance, if you have separate environments and businesses isolated from each other – you can again opt for separate compliance. You could be a Level 3 Merchant filling up an SAQ B form, and also a Level 1 Service Provider doing an ROC with a QSA.

In the second example where your merchant business connects to your own payment gateway, it’s a little more complicated because in all likelihood, the systems utilised by both business would be common. In this case, isolation and demarcation of type of business is more difficult to attain. Assuming you are eligible for Level 2 service provider, you can technically fill that up and ensure that it includes your payment channels within that SAQ. If you are doing a Level 1, then similarly, the QSA would likely include your payment channels (previously what you would call your merchant business) into your service provider certification efforts. Otherwise, you can still opt for a separate PCI compliance program, whereby you fulfill your merchant compliance, and for your service provider compliance program you do it separately.

For the latter option, the advantage is that if you launch your payment gateway and you provide options for other companies (not just your own) to connect to you, your compliance isn’t dependent on your payment channels (your merchant business). You would treat your own payment channels as just another merchant out of many, that are connecting to you. The downside of this is that you would likely need a clear demarcation and separation of systems between your merchant and service provider business.

Again, there are many ways to skin PCI. The best way (on paper at least) is to get your acquirer on the table or your payment service provider to ask them what is applicable to your business. Unfortunately, around 99% of the time in this region, the acquirers aren’t too knowledgeable themselves and either give wrong information or just tell our clients to do a Level 1 Certification with a QSA.

As part of our job scope – we will assess our client’s environment and provide the options on the table, and in some cases even be present on the table in the discussion with their acquirer – to obtain a clear indication on how to move forward and what PCI options are acceptable.

As always, drop us a note at pcidss@pkfmalaysia.com and we will do our best to accommodate your inquiries!

© 2024 PKF AvantEdge

— Up ↑