PKF AvantEdge

Tag: saq (Page 1 of 3)

Do or Do Not – ASV for SAQ A

July 24, 2021 / / 0 Comments
pci-compliance

I would have thought this debate died out with the extinction of dinosaurs, but apparently, we are still at this subject in 2021. Still. Going. On.

So in the past weeks, there were some debate between us and some consultants as to whether the SAQ A requires an ASV scan or not. Our position was No. Their position was yes. So let’s look at it.

Now, keep in mind, we aren’t talking about best practice. We are talking about PCI-DSS v3.2.1 and what it says about ASV scans being mandatory for SAQ A. That’s it. That’s the statement. Now, debate.

There is actually no debate. This isn’t some sort of grey area, hard to explain, obscure rule in Sanskrit and written on the Sankara stones. This is just: Look at SAQ A, search for ASV, don’t find it. Thank you.

The ASV requirement is present in item 11.2.2 of PCI-DSS.

SAQ A does not have it.

So why do consultants still insist people do ASV scans for SAQ A?

There could be a lot of reasons, ranging from ‘guideline’, ‘best practice’ and so on. No doubt, having a scan (which isn’t expensive in any case) would be the least effort of security done by the merchant if they are hosting an e-commerce website that is redirecting customers to their payment processor once the “Click here to pay” is clicked. I mean, even if it has nothing to do with PCI, it may seem like common sense to have at least a scan done on your site to ensure it passes the very minimal requirement of security. So do we advocate an ASV scan to be done on any e-commerce site that deals with payment options (not necessarily payment data)? Yes, we do. There are many ways a site may get compromise. A coding error may allow data to be siphoned off, or passwords may be compromised. A re-direct may be vulnerable to man in the middle attacks; or even a total redirect to another page altogether where payment data is inadvertently entered. While the e-commerce site may be outsourcing the payment part to a processor, it still has the job of redirecting traffic to it.

Think of it as an usher (not the singer, but the job); where you enter into a dark auditorium, let’s say Royal Albert Hall to watch Ed Sheeran – and the usher takes you through this row of lights to what is supposedly your seat which you paid RM10,000 for.

When the lights come on, you find yourself in nice cosy room and in front of you someone who seemed to resemble Ed Sheeran but slightly off. His hair isn’t ginger and he isn’t as chubby as you see that guy on TV and he speaks with a slight Indian accent. And isn’t the Royal Albert Hall a HALL? Why are you in this room that resembles a glorified grandmother’s living room? You find out later that the usher had led you through the wrong Hall into a neighboring pub attached to the side of the hall and you are listening to the wonky music of Eddy Shiran.

The point is, the usher is pretty important in leading people to their seats. So as a redirect, even though you aren’t the main draw, you could end up leading your customers to Eddy Shiran instead.

But back to the main debate, whether it is required for SAQ A customers to go through ASV? No, it’s not.

However, there is always a but in everything. There are exceptions.

Some acquirers make it a point to state that they still require an ASV report even if merchants are going through SAQ A. That’s completely fine because the guidelines from Visa/Mastercard are just guidelines. At the end, the acquirer or payment brands may make individual decisions based on merchants, so it’s not written in stone. However, if there are no such requirement, we’re left to interpret the SAQ as it is, and it doesn’t state anything there.

Some may point out within the SAQ A under part 3a, there is a statement

ASV scans are being completed by the PCI SSC Approved Scanning Vendor (ASV Name)

Triumphantly being pointed out as proof of ASv requirement

Take note however, that above, under Part 3a, the instructions do state:

Signatory(s) confirms:
(Check all that apply)

the realisation that asv is still not needed for Saq A (or B)

Even under the title “PCI DSS Self-Assessment Completion Steps” of the SAQ:

Submit the SAQ and Attestation of Compliance (AOC), along with any other requested documentation—such as ASV scan reports—to your acquirer, payment brand, or other requester.

It does seem to be grappling at straws if this sentence was used to justify the requirement for PCI-DSS. “Such as” generally denotes an example, which may or may not exist or is required.

In previous requirements of merchants from Visa, there used to be statements describing merchant levels such as 

 * Merchant levels are based on Visa USA definitions
** The PCI DSS requires that all merchants perform external network scanning to achieve compliance. Acquirers may require submission of scan reports and/or questionnaires by level 4 merchants

And perhaps there is where the myth was perpetuated from. In recent times Visa has updated its site (https://www.visa.com.my/support/small-business/security-compliance.html) to reflect a better understanding, stating:

“Conduct a quarterly network scan by an Approved Scan Vendor (“ASV”) (if applicable)”

In conclusion, SAQ A and B do not require ASV scans. If it’s required by the acquirer then so be it. If it’s supposed to be done out of best practice requirements, so be it. But you don’t want to hear an ASV/QSA telling you that you need to do something that is above and beyond your PCI requirement without them pointing to something in the standards that states so.

Finally – for SAQ B, which usually applies to POS terminals dialing up to the bank for authorisation; we’ve even seen some consultants requiring the merchant’s website to undergo ASV, which has nothing to do with their POS Terminals. Why ASV the website? Don’t know. So the merchants go about scanning their website that hasn’t been updated since 2012 and wonder, what sort of nonsensical requirement is this from PCI-DSS that needs them to pay just to scan something that is built by an 18 year old intern who had left the company 10 years ago? You don’t need to. So don’t do it.

Anyway, that’s it for now. Let us know your thoughts or questions and send to us at pcidss@pkfmalaysia.com and we will get back to you ASAP. Now, back to listening to our Spotify for Eddy Shiran!

The Biggest (Real) Myths of PCI-DSS: Part 1

April 4, 2021 / / 0 Comments
pci-compliance

Sometime back, PCI-DSS published the Top 10 Myths of PCI-DSS which we debunked in our series of Myths of the Top 10 Myths here. In this article, we are going to jump into the real actual Myths of PCI-DSS and we will explain it as we go along. We are not going to touch on the original myths published by PCI Council, but this is really very much based on our experience in PCI-DSS for more than a decade here in Malaysia, and what we often hear companies going about.

Often this misinformation is because the client facing PCI-DSS finds it hard to dissect all the information needed for the standard. Unlike standards like ISO27001, PCI-DSS is like a journey with different routes to the same destination: PCI Compliance. There are 3 separate destination for PCI – Level 1 Certified with QSA, Level 2 Self Assessment with QSA/ISA signoff, and Level 2 Self Assessment with Self Sign off (no QSA, no ISA signoff). Of course if you are a merchant, then you have level 3 and level 4, but those are the same as the third iteration where you signoff the SAQ on your own without involvement of QSA/ISA.

But while the destination itself can be clarified, the whole process to obtain PCI can be convoluted. Some clients are told by their banks, that because they do not store credit card, they are considered SAQ level 2. Or some are told because they have a website, they must do ASV scans. Or some are told that QSAs must be involved in everything. Some are even told, that local QSAs must be hired, and not any other QSAs. Some are of the opinion that PCI is a license they need to purchase, or a training they need to do. And some are of the opinion that the ASV scan will make them PCI compliant.

Hence, it’s easy with all the above misinformation and more, that customers get frustrated with the expectations of PCI. When they hear a level 1 certification may set them back 15 – 20K USD or more, or that it would take them 6 months or so, they balk at it. It’s funny because often I would start my sales pitch by saying: “At the end of our conversation, it would be goal to try to get you to avoid getting services from us if possible.” Because it’s essentially true. Our job at the beginning isn’t to peddle services or consulting or audit that our clients may not need. Our goal is to provide them with enough information of PCI-DSS so they can make informed decisions. And yes, even if those informed decisions would be that they can avoid PCI, or do their own SAQ without any consultation or ASV scans or certification, or get exemption from their banks/customers or anything else that can lower their requirements for PCI-DSS. And yes, many people who have called us actually just pay us by saying ‘thank you’ and we never hear from them again. Because as advisors, it’s better we start doing the right thing at the very beginning instead of focusing to sell services that customers do not need. This philosophy has been adopted from the start of our company – which is one of the reasons why I failed so miserably in my previous corporate role as regional head of professional service sales. Or also why I was once told off by a potential business partner that I was a poor sales person and that he preferred to work with an organisation with someone better handling sales. Ah well.

So here are some of the top REAL myths of PCI-DSS that needs to be debunked, burned, destroyed and thrown out of the window for the garbage that it is.

1) All PCI-DSS Projects Require ASV Scans

2) ASV scans makes you PCI compliant

3) All PCI-DSS requires (local) QSA

4) All PCI projects are the same (One Certificate to Rule them All)

5) All PCI-DSS services must be outsourced

6) All service providers MUST be certified to do implementation services

7) PCI scope and application of controls can be determined by the customer

8) PCI-DSS gets easier and cheaper every year

9) A company is considered PCI compliant even after the expiry of certification, due to 90 days grace period from the council

10) If the company is an ISMS certified company, they have already complied to 90% of PCI-DSS

So there is quite a bit of stuff – some may be half truths and other are utter nonsense – we need to uncover, likely will need to break this article up into two parts. Let’s jump into it.

Real Myth 1: All PCI-DSS projects require ASV scans

This myth is often peddled by those who are selling ASV scans as part of their service. Don’t get me wrong, we also do ASV scans through our ASV partners for sure, but you can’t go around town telling people that all PCI requires ASV scans when it doesn’t! Read SAQ A. Read SAQ B. You don’t see ASV being mentioned anywhere in the SAQ except for this portion in Part 3a:

ASV scans are being completed by the PCI SSC Approved Scanning Vendor (ASV Name)

And under “PCI DSS Self-Assessment Completion Steps”:

Submit the SAQ and Attestation of Compliance (AOC), along with any other requested documentation—such as ASV scan reports—to your acquirer, payment brand or other requester.

The thing is, if you go through each control under the SAQ, the ASV control 11.2.2 isn’t mentioned, so therefore it’s not required. It’s highly frustrating to us, especially when travel agencies for instance who are just doing EDC terminal business (SAQ B) that connects directly via cellular or phone line to acquirer coming to us and asking us to quote for an ASV scan for their website. We tell them, you don’t need to do ASV scan for your website unless its in scope. You can force us to sell to you, but it’s against our moral code to sell you stuff you don’t need. We take a look at it, find its a simple site with only information and they tell us, “Well, their PCI advisor previously told them to scan their website.” No. You don’t need to. Don’t waste your money, and don’t do it unless you have a website in scope or you are doing an SAQ requiring ASV scan or you consciously make a decision to do it out of best practices and security requirement – NOT as a mandatory PCI-DSS activity.

So, please, take a look. Even SAQ A, usually adopted by e-commerce sites that redirects to a payment gateway for card input – where there is likely a website, the myth is that ASV needs to be done. Read SAQ A. Again, no requirement for ASV scan. You can still do an external scan for security purpose, but strictly for compliance? No. Not needed, unless requested specifically by the acquirer.

And yes, we do have ASV scans as part of our service. But that shouldn’t make us charlatans peddling services to customers when it isn’t mandatory. If the client still wants to pick it up, ok, fine – but don’t say it’s compulsory when it’s not!

Real Myth 2: ASV scans makes you PCI compliant

We have flogged this one half to death in our earlier article here: ASV scans=/ PCI Compliance

I won’t repeat what we have said there but by far, this is a myth that gets peddled a lot. One, sadly, is because the propagation of this nonsense seems to be acceptable by banks. I hear: “Oh, no problem, the bank says all we need to do is to run an ASV scan on our website.” I interject: “Wait sir, you aren’t doing that e-commerce business. You are doing a call center with virtual terminal payments..” <Click> <Dial tone due to hang up>

So there you have it : companies and merchants that have no business doing ASV scans , but using ASV scans as a means to ascertain PCI compliance. We get this even weirder ones when we are trying to obtain an AoC from one of our client’s service providers and they pass us their passed ASV scan report. We ask what the heck that is and they go – that’s our PCI compliance, so please shut up and stop bothering us. And it’s so difficult to go out and explain to them that whoever told them that, is wrong, and they have to go through the actual PCI compliance, which their wonderful ASV scan may (or may not) be part of that overall PCI Compliance.

Real Myth 3: The Auditor (QSA) must be Local

This is one of the strangest myths ever.

We get calls from customers going, “Is your QSA a Malaysian?” And I go, “No, we work with our partner QSA, from India, US or Singapore”. And they go, “Well we want a Malaysian QSA.” And I ask, “Why?”, and most of them are not able to ascertain why they need the QSA to be local, except that it may be a requirement checkbox in their document or policy.

Ok, I can’t argue with your policy, if you have nationalist preferences to your auditors for whatever reason. But it’s not logical for companies to have that requirement, that only local QSAs must be used. PCI-DSS never stated that. In fact, its preferable to have a QSA with regional/global experience as opposed to a local QSA. If PCI-DSS had this requirement for local QSAs to carry out audits, how can QSAs then say they have ‘regional experience’? You see the conundrum? You want an experienced QSA company, yet you want a QSA that is only local. If every enterprise in the world thinks that way, how would QSAs have regional/global experience? By that argument, then all QSAs would be local to that country – not just Malaysia – but each country would only have QSAs auditing in that country and nowhere else. And immediately you can see the fallacy and illogical argument attached to this myth. But this myth still prevails, for whatever reason (we sort of know the reason actually).

PCI-DSS requires a lot of experience. The last thing we need is a QSA with only a handful of experience and no operational idea of how to run things or recommend solutions and just rely on a checkbox and some cute marketing gimmicks. I’ve seen plenty of good auditors overseas, a whole lot better than the local ones I come across and vice versa. “Local QSA requirement?” It could be peddled by local auditors attempting to block off better equipped, or even cheaper auditors from overseas (better or worse) and really narrowing the options for their clients, who would be hemmed in by such requirement, thinking its a PCI-DSS requirement. It’s not.

If you mean by local support- that they can respond faster since they are local, then, yes, there is some sense in that. If you mean they are cheaper compared to a guy in US, then yes, but let that be a commercial decision and not a technical one. Sometimes even overseas (good) QSAs can be cheaper. Local support I agree, 100%. Nothing is more frustrating than sending a message to someone and them taking 24 hours to reply due to them being in another timezone. Local presence, local support – yes. But they technically don’t need to be a QSA. They could be consultants and there is a very good case in that. We noted it here in this article “PCI-DSS – So Why Aren’t We QSA?”. We consciously made a decision NOT to be a local QSA a few years ago to avoid possible conflict and to support our clients a lot easier and not to be bogged down by auditor responsibilities in PCI.
QSAs are a busy and itinerant lot. Aside from handling other audits, writing reports, they also need to be careful of overstepping their independent role by advising and implementing for their clients and then auditing this same control they devised.

There is really, if you come down to it, no perceivable value in saying having a “local QSA” is better or not. Having local support throughout the PCI-DSS compliance is important – and whoever is supporting should have at least the same or more knowledge than the QSA.

In some QSA Companies, they have a set up to differentiate the auditor and the consultant. Whereby the consultant is different from the auditor to ensure there is more independence. We have the same set up – PKF is the consulting arm and we deal mainly with implementation, testing and assistance of our client to get past PCI. The QSA is well, the QSA in this case, and they can do their audit without being too involved in the implementation. We know as much (and if not more, sometimes) than the QSA due to our operational experiences, and this puts us in a better position – conflict free- to get our clients certified.

So, no, in this opinion, there is no real value or even PCI requirement in having a local QSA, because that generally does not make sense and is counter-intuitive to peg a customer to only select local, less experienced auditors. Most QSAs can (and should) be able to do regional or even inter-regional work because a QSA Company, by its very nature is a regional or global company anyway (QSA pays to be auditors based on regions, and not country specific). Again, while our opinion may be biased because of the strategic decision we made years ago, we made that decision with all these considerations in mind.

Select the best QSA option based on experience, pricing and quality, not because they are local or non-local.

Real Myth 4: All PCI projects are the same (One Certificate to Rule them All)

A customer once said that we didn’t have much value and all we did was to forward their emails to the QSA for validation (not true). He said he had his team done PCI across other countries and we were just making it more complicated than necessary since they have already been experienced, implying that we hoodwinked them.

It’s very difficult to talk to people who are in this position because you can see from the onset, they do not support outsourcing advisory and consulting and they have a personal vendetta against this profession. So we don’t need to speak reason to them. In this case, we decided to pull out of the deal for advisory and all other works of implementation except for the ASV scans.

Two years from starting their PCI project on their own, and they are still in the wilderness. We ended up supporting them in any case, and perhaps their thought process had somewhat soften now because we are now finally seeing the end of the project, with us (ironically) leading them to it.

And their ‘experience’ from other PCI compliance projects? Different experience. Some were basically e-commerce SAQ A, A-EP type, some were their retail arm SAQ B or B-IP. But what they were doing in Malaysia was the outsourcing, call center and BPO – all of which involves credit card storage, processing and transmission.

Not all PCI-DSS projects are created equal.

Another company employed the ‘One Certificate to Rule Them All’ philosophy. They were providing warehouse storage facility to one of our clients, essentially storing physical copies of forms containing credit card information. So, this is a service provider, providing storage that needs to be assessed for their physical security.

They immediately told us they are already PCI compliant and they will send us the certificate. We insisted on AoC but they obliged us with their ‘certificate’ anyway, emblazoned with their QSA logo proudly, stating – SAQ C-VT Certified.

Huh? What has SAQ C-VT (merchant SAQ) got to do with the warehouse storage you are offering to my client?

Apparently that SAQ C-VT cert is from one of their parent companies overseas or something and has as much relation to our current project as me running to become the president of the United Sates. It means, One Certificate 100% does not rule them all. It’s a completely different business function and you can’t just use another SAQ or AoC from another parent/child company that is selling ice-cream cakes and had their call agent processes certified and say this applies to your warehouse storage facility half a world away!

Ok, we are halfway there, bear with us. Writing all these myths really can drag an article and you can probably read the frustration oozing out each paragraph. I’ll admit, we get extremely frustrated, but we also must remind ourselves – most of them (customers, banks – NOT QSAs, they don’t get any free passes for giving misinformation!) do not know better and they are just doing what they think it’s right or what they have been told by so called consultants or QSAs. That’s why we need to set their paths correctly so they know what options are there before them. So, we need to stop getting frustrated and blaming them for bad decisions, and get more involved in educating and providing information so they can make good decisions.

We will continue the next time once we catch our breath and go through the other wonderful misinformation on PCI-DSS we have heard over the years. Till then, drop us a note at pcidss@pkfmalaysia.com on anything to do with this standard or other standards like ISMS/ISO27001 etc.

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 – Merchant EDC and Scoping

February 2, 2019 / / 0 Comments

Many merchants we meet often tells us this: They are not in scope because they only do EDC (electronic data capture) – or payment terminal – transactions and these belong to the bank. Therefore, the bank has to ensure these are compliant and merchants do not need PCI-DSS since they do not store credit card.

Upon this, it’s the prevailing myth that storing credit card information is what PCI-DSS is all about, and as long as we avoid this, we don’t need to be PCI.

While non-storage of credit card does reduce scope SIGNIFICANTLY, it’s not the only thing PCI is harping about. It’s pretty clear in the standard itself:

PCI DSS applies to all entities involved in payment card processing—including merchants, processors, acquirers, issuers, and service providers. PCI DSS also applies to all other entities that store, process, or transmit cardholder data and/or sensitive authentication data.

I don’t blame the merchants. They already have a hard enough time competing in a new digital landscape of virtual buyers and getting margins from their products – the last thing they need is a consultant coming in, brandishing some sort of standard called the PCi-DSS and the only thing that flashes through their minds is: How much is this sucker going to cost me, now ?

But it is what it is and we try to make our client’s (or in many cases, not even our clients, but anyone who calls us – and doesn’t even need to pay) life easier – and provide enough information for them to decide whether they need consultation, help or go it alone for PCI.

Yes – we technically consult them to potentially not consult with us.

But we believe in the long run, trust is something every consultants or advisors need to earn and it’s not something that comes with the territory. In fact, if I had a ringgit for every joke made about CON-SULTANS…we wouldn’t need to make any more new sales.

Anyway back to PCI. So the question to ask back the merchant is simply: “Great that you don’t store – but do you process card data?”

“No we don’t, the bank does it.”

“You don’t handle card data?”

“Handle? As in physically handle?”

“Yes”

“Of course (now somewhat flustered) – how do we get customer card if we don’t handle it?”

So in that sense – they answer their own question – if they are not there (handling the card), there is no transaction and no processing of card. Therefore, they are involved in the processing of card data. Does PCI apply? Yes, it does.

How does PCI apply?

Again, I am not going into the story of levels (how do be validated) vs controls (what to be validated) – already covered in previous posts on this, recently here .

But before our merchants get discouraged, most of their scope is very limited and in fact, I recommend them to try and go it alone.

Scenario 1

Their EDC connects directly to the bank through a dial up or cellular. No storage of card.O Only flow is to receive card, dip it, wave it and pass it back to the customer. That’s it.

Look at SAQ B. Last check, there are 41 questions. You don’t really have too much complexity in there, except to just ensure information security policy is there, physical security of the EDC is there etc. It’s not that difficult and really, most merchants should try to at least get these done.

Scenario 2

Their EDC connects to the bank via the merchant broadband.

This becomes trickier as this means the card data potentially passes through devices in the customer premise. This also includes when the branch locations sends credit card information back to the HQ and uses the HQ own internet set up to send to the acquirer. Another permutation here is that the acquirer would have their own equipment in the customer HQ where all branch data is consolidated to and sent.

The above scenario is more often found in very large Merchants.

In this case, the best bet we can go for is SAQ B-IP, with around 82 questions. Again, card data cannot be stored (full 16/15 PAN) or Sensitive Authentication data like CVV or track or PIN cannot be stored. In this case, PCI can still accept SAQ B-IP but most of the interim systems will be in scope for SAQ B-IP controls.

The trick here is really the SAQ B-IP requirement:

“The standalone IP-connected POI devices are not connected to any other systems within the merchant environment (this can be achieved via network segmentation to isolate POI devices from other systems);”

This is not as easy as it sounds as many environments still have their EDC all in a flat network as any other systems, and part of the requirement will need these EDCs to be properly segmented out to avoid pulling in the entire corporate into scope. This becomes complicated further if EDCs connect via wireless.

Another thing to be aware of is that you probably need a letter or confirmation from the acquirer that the entire card flow is encrypted end to end – meaning from the EDC all the way to acquirer environment, rendering the merchant environment as simply a transition point. Think of a road, being used by an armored truck that the merchant has no access to, as they do not have access to the encryption keys.

Other than that, depending on the number of segments you have – segmentation penetration testing is probably another headache you need to look at. However, this can be done via sampling, so consult with either the QSA or PCI expert for an idea of what an acceptable sampling is. Due to the risk being rather low, the challenge here is just to ensure that all setup is standardised across stores.

Your EDC shouldn’t be relying on your POS machine to send card data or process. The POS should only be passing transactional information and any information obtained from the EDC should be truncated PAN (if necessary) or only transaction information.

There you go.

With these, you can probably navigate through the initial headache of PCI for your merchant environment! Let us know at pcidss@pkfmalaysia.com if you have further questions! Since we sometimes consult you not to consult us, it would definitely be an interesting discussion!

FAQ on SAQs Once Again

January 6, 2019 / / 0 Comments

Over the past few months, we have been absolutely busy with a fair amount of work. One of the things that we  have seen an uptick are merchants coming to us requesting PCI compliance. We have had some small ones, big ones and mega huge companies coming to us, but the trajectory discussion is always the same:

a) Bank wants us to do PCI

b) Bank says we are Level 2 Merchant because they say we store card data

c) Can you audit and certify us ?

I don’t blame them actually because their core isn’t PCI. Heck, most of them aren’t even into payment systems! Unlike service providers where they have a fair bit of knowledge of how payment via credit card functions, most merchants are basically: OK, give us the EDC and let’s make some money. Or set me up on my e-commerce and let’s get it done.

The Banks are obviously not helping by giving half-baked information on PCI-DSS. And PCI-SSC isn’t helping by making PCI so….confounding to the lay person.

So, here are some basic FAQs on SAQs (Self Assessment Questionnaire)

a) What Level Merchant are we?

This depends on your volume of card data being processed. Many assume that it’s more than 6 million volume (not value) transactions a year that puts you to Level 1, but actually this is defined by individual card brands. That 6 million is more popular because that’s what Visa and Mastercard go by. Amex goes by different volumes. A nice chart here can get us started:

b) Wait. We were told to be level 2 because we store credit card.

That unfortunately is not that accurate. Type of levels are defined by your volume transactions. This determines HOW you get PCI – either by a 3rd party ROC audit (level 1), a 3rd party validation on your SAQ (Level 2), or self signed SAQ (Level 3 and 4).

Whether you store credit card or not, that has nothing to do with your credit card volume. Remember – for PCI, as long as you store, process and transmit credit card, you get hit with compliance.

c) So if we are just transmitting credit card in high volume, we could be considered level 1 or 2 without STORAGE?

Yes, of course. It’s highly possible that you do not store credit card but trillions of card data flow through you, then yes, technically you would be level 1. You don’t store, which is good, but you have high volume, which determines your level, and that determines how you get PCI (either audited by 3rd party of self signed in SAQ)

d) But what if I have LOW volume but store credit card? Don’t I get bumped up into level 2 or level 1?

In theory, no. If you have low volume, then your level could be 3 (for e-commerce) or 4. Then once your level is determined and you know how to validate PCI, you need to decide what to validate to. That’s where the different types of SAQ come in. If you store credit card, you immediately have to use SAQ D, which is tough and have 340++ questions to whet your appetite over. If you do not store, then you need to understand which SAQ (there are 9 types) to apply – it could be A (which has the least questions) or C-VT (which has more, but less than SAQ D) etc. An example for A would be an e-commerce entity fully outsourcing all payment processes and pages to a PCI compliant provider.

e) So you are saying, I could be a level 1 merchant doing SAQ A because I fully outsource my payment? What do I need to do then?

If you are level 1, SAQ is out of the window. You need to get a QSA in to do a full Report on Compliance. But you can use SAQ A as an internal guideline to prepare for the audit of course, because basically the auditor will be utilising those controls if they determine that you are truly SAQ A.

f) What do you mean by “Truly SAQ A”?

In the auditing world, we can’t take your word that you are really saying what you are. It’s not that you are dishonest, it might be that there are processes you are not aware of that might for instance cause you to store data and that makes you ineligible for SAQ A. Just sayin’.

g) So basically, I can go and tell my bank they are wrong to force me to be Level 1 or 2 just because I store credit card?

Yes and No. Because those level volumes are guidelines. At the end, its the bank that’s taking a risk at you so they get the final say of what levels you need to eventually be.

h) So what’s the POINT?! 

The point is that a lot of banks have no idea on this, so they dump you into SAQ D even when your volume doesn’t add up. Or they think that you are Level 1 or 2 just because you store credit card. Both are disadvantageous to you because you end up doing more than what PCI requires. The point here is for you to head back to the bank with this information and confirm with them if they are aware of these requirement and that they are purely requiring you to go through MORE than what is required by PCI just based on their internal risk assessment of your business.

i) At the end, we are still at the same place. The Bank is telling us what to do.

Yes, but you can now reason with them further. Because if they are the only bank asking for this, merchants might look for other banks to be their acquirer. It’s business. So, at least now you know!

j) So can we go through all the SAQ types now with you?

Not really because this article is too long and I have lunch to go to. Next time maybe! Have a great 2019!

« Older posts

© 2024 PKF AvantEdge

— Up ↑