Category: PKF AvantEdge (Page 4 of 6)

PCI-DSS: Estimating the Cost

Ah money.

This is how most conversations start when we receive calls from PCI. How much will it cost?

I think this is one of the toughest subject for PCI, because it really depends on what is being done by the service provider/consultant for you, and how much you can actually do the implementation of PCI-DSS on your own. And obviously it also depends on your scope, and on top of that, depends on compensating controls if any, or any current controls you have in place. And then it also depends on the validation type – SAQ vs RoC and so on.

So, in the classic riposte to this classic question, it would be “It depends”.

Where we really need to clear the air though is the myth that once you have done PCI-DSS the first time, everything gets easier on the renewals and everything gets cheaper year on year going forward. That is for another article. There is a lot of things going on in PCI-DSS, and if you approach it from a product perspective (like most procurement do), you end up either sabotaging your entire compliance, or getting an auditor willing to sign off on God knows what, and later on realise that you’ve been out of compliance scope all the while.

To start with the pricing, you should understand a bit on the cost of PCI-DSS. And we should start with the QSA, because after all they are the focal point of the PCI program. They are the Qualified Security Assessor. Of course, you can opt to do your PCI (if allowed) without a QSA involvement (Merchant level 3 or 4) and just fill up an SAQ with or without assistance from consultants; but for the most part, a QSA would be involved in the signoff for larger projects, and this is where the cost questions take life.

Lets look firstly at the base cost of becoming a QSA. It’s very helpfully listed for us here: https://www.pcisecuritystandards.org/program_training_and_qualification/fees

So here are the maths. Imagine you are a QSA with projects in Malaysia: to start off, you will need to set aside over RM100K just to get you qualified to to audits in the Asian Region. We’re not talking about Europe or Latin America or USA here. Just APAC. That’s qualifying the company. A company, to service any region properly will probably need a bunch of QSAs trained and ready, let’s say around 3 to start off with. Each QSA will need to go for a training costing around RM12 – 13K, so let’s say you have 3 (which is very few), you are setting aside around MYR 50K for that. On top of that, there are obligations such as Insurance Coverage that is specified in the QSA Qualifications Requirement document. So it depends on which insurance you are taking, but it could be in the region of around MYR6K or above premium (spitballing). There is a requalification each year as well.

QSAs then can make their own calculations on how fast/long they need to recover their cost, but let’s say they set aside 200K just to get things set up with 3 or 4 QSAs, then they need to recover that cost. A man day of a QSA/Consultant may range from quite widely in this region but let’s say you decide to price it at “meagre” MYR2K, depending on how senior you have, so overall, you would need to have almost around 1.5 months of engagement of their QSAs just to recover the cost of setting up shop. That’s why its not unreasonable to see higher rates, because of the cost it takes.

You have salaries to consider as well. You also have to consider if something happens to one of your clients, where you happily audited them remotely and believed everything they said, and found out that they have done jack-shoot in their actual environment and you have to handle the fallout of liabilities.

Some procurement compares QSA engagements to firewall engineers. No knock on other technical engineers, but the cost of getting a Checkpoint firewall engineer and the cost to maintain one QSA is a different proposition. I am not saying one is better than another technically (I’ve seen a lot of firewall engineers who could put any auditor into their place, due to their extremely proficient technical skills), I am stating the underlying cost behind the position, which is why PCI-DSS is priced at a rate that’s comparable to say, CMMI, as opposed to say, the ISO9001.

On top of just auditing cost, QSAs take into account the actual support they are giving year on year. Some of them unburden this cost to partners and consultants who have been trained (such as PKF – and there are also other matters such as independence of audit vs implementation advisory which we will discuss later), or some of them take it upon themselves. But you must know the QSAs job is not easy. Aside from auditing and supporting, there is evidence validation and report writing. Then there is the matter of undergoing the Quality Assurance process, which brings more resources/cost to the QSA company. All this while travelling to and from audit sites, reviewing etc – the life of a QSA (ask any QSA) is itinerant and often travel heavy. Burnout may also be a concern, so if the QSAs are involved in the day to day or week to week assistance to their client’s PCI program, this isn’t sustainable.

Understanding all these underlying cost will allow the procurement or whoever is evaluating to understand how to look at projects. If a QSA is pricing extremely low, the question you will need to ask is: What’s being offered? Because all QSAs have more or less the same baseline cost and if a QSA priced themselves at RM800 per man day, and they are a small shop with less than 5 QSAs, what would then be their recovery rate? 200 man days of engagement to recover their initial cost? Most procurement wouldn’t think of things like this and they would just go to their “BAFO” Best and Final Offering – but when you break it down on what is expected, then you would understand that not all PCI offerings are the same. I could simply quote a client 3 man days of QSA work for the final audit and be done. That would be the best and final offering that would win. But what about the healthchecks, the management of the evidences and how they are submitted, the quality checking, the scope optimisation process, the controls checking etc etc?

And in line with our effort estimation, one should also split the pricing into two: Audit and Consultation vs Implementation service and products.

Because if let’s say we find your Requirement 10 is completely empty, and you are thinking to purchase a QRadar SIEM to address it, you could be looking upwards of RM60,000 just to get the product in. Couple that with training for engineers, usage, hiring etc, and you are well over the six figure stage just for Requirement 10! How about testing and application reviews? If you don’t have the personnel on this, then you have to consider setting aside another RM50K etc depending on how many applications/mobile applications/ systems you have in place. So it’s highly essential to have the QSA/consultant assist you in scope reduction. Most may not view it that way, so it’s essential to find an auditor who is experienced and who looks after your interest.

Finally, understand that cost of audit/consulting would be different depending on how you go through PCI-DSS. Level 1 certification requires the effort of validating evidences, doing gap assessments and auditing and writing the RoC. Level 2 SAQ with QSA signoff is slightly easier, as there is no RoC to write while the last option of self signed SAQ without QSA is obviously a lot less costly as you are basically doing a self-signoff. Those are just broad guidelines and not how QSAs may price it, because as I say, due to variables.

You could opt to use the rule of 1/3 when it comes to estimating these costs, although your mileage may vary. For instance, if the QSA throws a RM100K audit fees (comparing it to CMMI fees) for a Level 1 Certification, then a RM60-65K (2/3 of the Level 1) for a SAQ Signoff could be reasonable; and furthermore if you just need them in for consultancy for the non QSA signoff SAQ, it could be 30K (1/3 of the level 1) or so. But note, the SAQ self signoff can be carried out entirely on your own, so the cost could be close to zero as well.

I know its a tough one to place this as pricing varies so often. We aren’t selling a product with specific hardware/software. We are selling a service that will take you through 6 months of work to cover scoping exercise, project meetings, changes, consultancy and advisory, pre-audits and post audits checks, evidence and artefacts sample validations, audit, report writing, training and all the variables in between.

Let us know if you need us to look at your PCI today, drop us a note at pcidss@pkfmalaysia.com and we will attend to you immediately!

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.

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 kerfuffle? 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.

SAQ A and A-EP, the eternal struggle

Another week, another lockdown struggle, another political instability and another question on the eternal confusion called the SAQ A and A-EP. And this time, it wasn’t so much of us trying to clarify with the customer on this – but us trying to explain to QSAs on it. It just shows how much confusion there is to this thing even after all these years, that even auditors, whose bread and butter is literally on PCI-DSS still struggle to understand it. I don’t blame them – it’s the way that the SAQs are worded, and the confusion that surrounds it that makes it so frustratingly difficult to interpret.

SAQ A by far gets the most mileage. Not because a lot of people are eligible for it, but because at 20+ questions, it’s by default the go-to SAQ for most organisations, whether they are eligible for it or not. I mean, comparing the SAQ D and the A is like scaling Everest vs the little sand hill that your 5 year old kid just built on the beach. Something like that. So everyone (even non-eligible Service Providers) always default to the Open Shortest Path First, which is the SAQ A when they need to choose an SAQ to be “PCI-Compliant”.

However, SAQ A is notoriously difficult to be eligible for and today we are going to look at it. Again. We have often seen everyone anything from storing card information, to hardcopy storage of insurance policies, to doing outsourced call center picketing in front of our office shouting for their SAQ A rights. I mean, let’s start here with SAQ A and A-EP and the difference.

We are not going to focus on the controls in these SAQ, but rather the ‘eligibility’ of it, meaning, on Page 4 of both SAQ under “Before You Begin”. Instead of just repeating all that is typed in there in this article, I will assume those reading this article is keen for a deeper dive into the murky waters of SAQ and not here for a shallow wade – so I am going to assume you have those SAQs right in front of you and I don’t have to delve into the history much, ok?

SAQ A’s story starts off by stating there are TWO types of business who are eligible for it.

a) E-Commerce Merchants

b) MOTO (mail order/telephone order) – card not present

c) Of course, those who do not STORE, PROCESS or TRANSMIT card holder data in ANY electronic format on their system and premise.

Let’s start with MOTO first, because this often confuses people. Straight away those doing MOTO will dance a jig in front of me and gleefully points out that they deserve the SAQ A. All your base are belong to SAQ A, if those nerds like me would understand. Because I usually move them over to SAQ C or C-VT depending on how their call center/MOTO transactions are set up (even B-IP may apply e.g MOTO function on terminal, but mostly MOTO ends up being in SAQ D because they often store card data on file).

Hold on there though. Eligibility of MOTO is tied to the eligibility of c) – i.e you do not store (OK), process (erm, yeah ok, sometimes) or TRANSMIT card holder. Often the transmit and process part is done when you have people on your premise doing MOTO. The moment a phone call comes in – BAM! you are hit. You are done for.

So the ONLY time MOTO is eligible for SAQ A is later described in the SAQ:

Mail order/telephone order (MOTO) or e-commerce merchants that have completely outsourced all operations (where there is no redirection mechanism from the merchant to the third party) and therefore do not have any systems in scope for this SAQ, would consider these requirements to be “not applicable.”

SAQ A

The above is talking about how we can mark Requirement 2,6 and 8 as Non applicable. But notice where it states: COMPLETELY OUTSOURCED ALL OPERATIONS. This means, your company’s MOTO transaction is never done by your own company or on your own premise or by your people or using your technology. You have Completely, irrevocably, irreversibly outsourced the entire function to someone else who is PCI-DSS compliant. Then OK, you cool.

So now we know how to deal with that MOTO part. Oh wait, wait. There is a scenario from one client, where customers actually come over to the counter and try to make payment. However, because they have upgraded everything, instead of dipping or waving that card into a terminal for a POS payment, the counter person whips up a high tech iPad, connects to the companies website, looks at the credit card (while the customer is in front of them) and type out the transaction onto the e-commerce site itself for the transaction. How do we deal with this?

Well. This certainly doesn’t qualify for SAQ A in a strict sense, since this is considered a ‘face-to-face’ channel. However, logically, that transaction is made as an e-commerce, card non present transaction, because the CVV is entered as well and on the merchant end, it qualifies as a e-commerce transaction based on the flow and the fee they are paying. This is an interesting scenario as I would likely look at it as an e-commerce flow, since technically, the customer can do it themselves, but its just that for some reason, maybe they don’t know how, or they can’t figure it out, they go over to the counter to do it. The acquirer certainly doesn’t know about it. But because the information is going through the company’s asset, the company’s line, the company’s network, there would be additional risk they need to consider. In the end, it would be the call of the QSA on how they view this, however, I don’t think this could qualify for an SAQ A channel. It could be technically treated as a SAQ B-IP as we can assume its a terminal, but most auditors, to err on the side of caution may just opt for the full SAQ D on this.

OK, MOTO done.

Now for the e-commerce. I am not going to repeat what I’ve written some years back: https://www.pkfavantedge.com/it-audit/pci-dss-saq-a-and-saq-a-ep-differences-in-a-nutshell/

But I am just going to dive right in where the confusion begins. SAQ A-EP is written in a way that confuses people, and requires some sort of Indiana Jones exploration to figure out what in tarnation they are trying to get at.

So, under Before you begin, the second eligibility point (we call this ITEM 2):

Item 2: “All processing of cardholder data, with the exception of the payment page, is entirely outsourced to a PCI DSS validated third-party payment processor;”

This is confusing. They say – “All processing of cardholder data EXCEPT the payment page”. This means, the payment page actually SITS with the merchant, while everything else is outsourced to PCI third party. This means, this SAQ is eligible for merchants with PAYMENT PAGE (where credit card is entered) residing in their premise. So therefore, if the PAYMENT PAGE is also outsourced, immediately, this SAQ is no longer eligible. In a simple logic:

if (paymentpage) then { read next line;} elseif (!paymentpage) { exit();}

That means, SAQ A-EP doesn’t apply anymore to us if we have outsourced the payment page because this condition is not met, and therefore the if statement should exit, or if you are in a loop, it should end. SAQ ENDS.

The problem is auditors are generally non-programmers and even when the condition is no longer eligible, they keep going!!

And it’s really, the next line that is the confusion of all confusion:

Item 3: “Your e-commerce website does not receive cardholder data but controls how consumers, or their cardholder data, are redirected to a PCI DSS validated third-party payment processor;”

I mean, if we had exited the SAQ loop on the second condition, we won’t need to deal with this nonsense. So let’s break it down. YES, my e-commerce website does not receive card holder data, since I outsourced ALL MY PAYMENT page already to third party. But wait, you are saying “CONTROLS’ how consumers or data are ‘redirected’ to a third party? What? Obviously there is an element of control here, so how do we define ‘control’? Isn’t redirecting to an outsource payment page CONTROL?

The next confusion is the next line:

Item 4: “If merchant website is hosted by a third-party provider, the provider is validated to all applicable PCI DSS requirements (e.g., including PCI DSS Appendix A if the provider is a shared hosting provider);”

Hold up – didn’t we already agree that if the merchant entire website is hosted by a third party PCI provider, this would already not be in SAQ A-EP (see the exit rule of item 2). In fact, isn’t completely outsourcing the website the whole point of SAQ A? What sort of black magic is this?

Item 5: “Each element of the payment page(s) delivered to the consumer’s browser originates from either the merchant’s website OR a PCI DSS compliant service provider(s);”

Look at this wording. Look at it. Tell me that this is not contradicting item 2, the ‘with exception of the payment page’ condition. Let me rephrase item 2:

“You can go for SAQ A-EP if you host your payment page and have outsourced your processing to a PCI third party” –therefore implying that if you don’t host payment page and outsource everything, then another SAQ (SAQ A) applies.

Item 5 slaps Item 2 in the face and goes, “No. SAQ A-EP for you if you host the payment page, or the payment page is hosted by your PCI-DSS service provider. So no, Item 2, you wrong. You dead wrong.”

That usage of the word “OR” in that sentence confuses programmers or those with IT background, I think. This is a logical connector where if condition A OR condition B, if any of this is TRUE or both TRUE, we enter into the loop. Compared with the AND connector, where both needs to be true, otherwise we don’t process the loop. So the above statement is stating “ANY CONDITION WHATSOEVER” since it uses “OR”, will need to apply SAQ A-EP.

In fact, if they had clarified if all of these conditions are connected to each other either through the AND or OR operator, it would makes much more sense to us. It’s like the question, “Are you going to do it now OR do it later?” and we answer “Yes!” because we are indeed doing it now or later, and the question didn’t specify which condition as long as we are doing it.

Anyway, back to the story. The note in SAQ A-EP states:


For the purposes of this SAQ, PCI DSS requirements that refer to the “cardholder data environment” are applicable to the merchant website(s). This is because the merchant website directly impacts how the payment card data is transmitted, even though the website itself does not receive cardholder data.

SAQ A-EP OMINOUS NOTES

It is very ominous. It states, even if your website does not receive card holder data, you still impact or ‘control’ how the payment card is transmitted.

All is not lost though, because if you flip back to SAQ, under the SAQ A notes:

For this SAQ, PCI DSS Requirements that address the protection of computer systems (for example, Requirements 2, 6, and 8) apply to e-commerce merchants that redirect customers from their website to a third party for payment processing, and specifically to the merchant web server upon which the redirection mechanism is located

SAQ A OPTIMISTIC NOTES

I mean, I don’t know how clear it needs to be. It states in SAQ A “FOR THIS SAQ” – apply to merchants that ‘REDIRECT’ customers FROM their website (merchant website) to 3rd party for payment processing and specifically TO the merchant web server where the redirection occurs.

I am going to clarify the phrase that is underlined. the word “TO” is a preposition of the verb “apply to” in the earlier sentence, i.e this applies to merchants, specifically to their web server etc etc. Why its confusing here is because some may read it as a preposition to indicate direction , i.e redirect customers from their website to a 3rd party, specifically TO a merchant web server etc etc, which basically indicates the redirect is going into a loop (from merchant site to third party back to the merchant site) which doesn’t make sense.

I just want to point this out as I may not be the only one confused with this play of words and irresponsible usage of the preposition “TO”. Only me? Ok, fine.

Anyway – long story short, we used the notes in SAQ A to get out of jail for our client, and the QSA seemed to be resigned to that, noting there is a huge huge confusion with how A-EP is written. You do need to know, A-EP was born after A, so definitely, there would be some contradiction since they weren’t written together. SAQ A-EP is like the grumpy uncle that sits in the corner in your Christmas party and snaps at you when you ask him how he’s doing, while SAQ A is like the uncle with all the presents and all the children running around him and laughing with him as he tells a joke. Ah, SAQ A, we like you a lot.

Anyway – a final note on us, while we can state on PCI side, a full outsourcing of e-commerce payment page to third party qualifies for SAQ A, you do need to think – SAQ A-EP makes sense. The page doing the re-direct could be attacked and compromise and the redirect sent to another ‘payment page’ that looks exactly the same as the actual one. So while you are laughing with SAQ A, you need to take into account not to ignore the reasonable requirements that A-EP puts to you – vulnerability scan, firewall rules, penetration testing – i.e these are all best practice baselines that should be practiced regardless of compliance conditions etc. I would recommend a middle ground and take up a risk approach to it – implement these controls based on a good risk assessment and not just ignore the poor, grumpy SAQ A-EP uncle sitting in the corner. Because he may have a point in terms of security, after all.

Let us know about your experience or questions on PCI, SAQs or any other compliance questions at avantedge@pkfmalaysia.com!

« Older posts Newer posts »

© 2024 PKF AvantEdge

Up ↑