Tag: PCIDSS (Page 1 of 3)

Is PCI-DSS the most confusing standard?

After being involved in PCI-DSS for almost a decade as well as other standards and guidelines like ISO27K, 27017, 9001, PDPA, GDPR, CMMI and a partridge in a pear tree, we can almost unanimously say: PCI-DSS is probably the most confusing standard out there. Not so much of the content itself – it’s fairly easy to understand in terms of the technical controls. The confusion begins at the start: Applicability and Scope.

Now scoping for PCI-DSS has been hammered by us in many articles over the years, so for this article, we will look at Applicability.

So what is applicability?

It simply means, who does this standard apply to? This is different from ‘scope’. A scope is basically what is being assessed? Applicability is basically: Do I need to do this thing?? For instance for simplicity:-

a) GDPR = Applies to entities processing EU personally identifiable information. Entities that may have a more global presence or require to deal with customers with a larger market distribution may end up being applicable to the GDPR.

b) PDPA = applies to entities in Malaysia processing personal information, which basically means almost everyone.

c) ISO27001 = guideline that can be used by any entity to cover their core processes. This may also be required by some governments on certain industries, e.g the government requiring CNII (Critical National Information Infrastructure), so simply, if you are CNII, then you should be doing the ISO27K.

d) CSA Star Alliance = standard for our data centers to apply, but it’s not mandatory (as far as we know).

e) TVRA = based on MAS (Monetary Authority of Singapore) requirement for financial institutions, so generally if you are regulated by them, then you need to get this done. It’s actually a subset of their Technology Risk Management Guidelines. It’s pretty much a mirror of Malaysia’s RMiT (Risk Management in Technology) subset of data center resilience section. As an aside it seems slightly comical that these two countries, tied so closely together in terms of history and economy would sit down and decide to name their federal bank’s IT standard so closely to each other. I mean, it’s like:

i) Singapore – Let’s call our technology standard Technology Risk Management!

ii) Malaysia – Hmm, we can’t sound the same otherwise we might look like we aren’t original. Let’s flip it around and call it Risk Management in Technology!

Back to the subject, most standards out there has a reasonably clear idea of who it applies to. Even Bank Negara’s e-money guidelines or their baseline IT security requirements – apply to those regulated by them. HIPAA (not in Malaysia) applies to medical and healthcare entities.

Which leaves us with PCI-DSS.

From the onset, PCI-DSS applicability is actually very clear:

PCI DSS also applies to all other entities that store, process or transmit cardholder data (CHD) and/or sensitive authentication data (SAD).

PCI-DSS Standard

So in general, whenever you are storing, processing or even transmitting any part of the card holder data (PAN) or the sensitive authentication data, e.g track data, CVV etc, then PCI applies to you.

The confusion begins when these exact terms are used by those who are NOT doing any of these 3 (Store, Transmit, Process or STP) –lets call them NON STP– but still gets pulled into scope kicking and screaming like a child on his first day of kindergarten or adults on their first day of work after a holiday in the Bahamas. Examples are data centers, hosting providers, physical security storage companies (storing secure boxes for companies) – in their business model, they don’t deal with credit cards at all. But their customers may. Or may not. They don’t know. So for instance, if an insurance company decides to store their policy files with credit card information physically into a box and ship it to the physical storage company, how does the storage company gets yanked into ‘applicability’ of PCI?

The problem of section 12.8.2:

12.8.2 Maintain a written agreement that includes an acknowledgement that the service providers are responsible for the security of cardholder data the service providers possess or otherwise store, process or transmit on behalf of the customer, or to the extent that they could impact the security of the customer’s cardholder data environment

pci dss standard

The last part is where QSAs hook on – ‘impact the security of the customer’s CDE’. Now, just to be clear, 12.8.2 by itself has no indication that PCI is a requirement for these “NON STP” providers. It comes later in 12.8.4 and 12.8.5 where it states

12.8.4 Maintain a program to monitor service providers’ PCI DSS compliance status at least annually.

PCI dss standard

Argument on whether this relates to PCI-DSS compliance as a program or just service providers adhering to the PCI-DSS controls internally is an argument beyond time and space itself and requires a thesis to be written on it. Hence for now, simplicity wise, going by the standards and how many QSAs interpret it, multi factor authenticating providers gets pulled in. Hosting and cloud providers get pulled in. Storage vendors get pulled in. Cloud HSM and security providers gets pulled in. Fraud management gets pulled in. The whole thing about who could impact the security of customer’s environment gives QSAs a field day in including everyone in the party.

So applicability isn’t so straightforward after all. After determining anyone that stores, transmit and process credit/debit card with the PCI council members badges — now we have anyone that influences the security of the first group’s card data environment. This basically pulls almost everyone into applicability.

It doesn’t end there, however.

Because of the way PCI is structured, the PCI council actually washes their hands to determine who should be PCI compliant, and how they should be compliant. They pass that over to the individual card brands (I guess that’s themselves), who passes it to their banks connecting to their network, who in turn passes it on to their payment providers and who in turn passes either to their service providers or to their merchants. This is looked into in FAQ #1473, #1126, #1212 and a whole lot of other references. They always have this statement:

The PCI SSC recommends that entities contact their acquirer and/or the payment brands directly, as applicable, to understand their validation reporting requirements. Please contact the payment brands directly.

Everywhere to ensure everyone knows

When we were kids we used to play a party game whereby two teams have everyone sitting in two long straight lines. At the front of the line, the gamekeeper passes them a message, for instance “There is a blue wolf sitting in the Artic, looking at you with yellow, hungry eyes tonight” or something like that. Each kid will then need to whisper that message to the person behind him until it reaches the last person and that last person will have to go to the front and declare the message aloud, which invariably ends up something like “There comes wind that blew into the attic and sitting at me with fellow grey ice to the right.”  And everyone laughs.

This is how it is in PCI. The message gets passed down and somehow along the way, the message gets so jumbled that we can only shrug and go, “OK…” Some messages we have heard (from customers who claim their banks said):

a) “You need to show us their SAQ and ROC together! The AoC is not enough” – Not really. If you are doing SAQ, there’s no ROC (Report of Compliance). Likewise, if there is a ROC, it’s not SAQ. Both have AoC though.

b) “Physical storage companies that store physical card data like forms needs to do SAQ C-VT” – We’ve seen this, where storage company gave a SAQ C-VT (virtual terminals) to their banks and was accepted. No, you can’t. A physical storage company, being a service provider should look at the SAQ D and then mark of the irrelevant controls (such as firewall etc) as Not Applicable.

c) “You can do SAQ A – as a payment gateway!” – A permutation of b) – whereby a payment provider gave us an SAQ A as proof of their PCI compliance. I think they just scanned through which is the shortest SAQ A and go, OK, let’s go for the easiest. No, SAQ A isn”t applicable to service providers. SAQ D needs to be done and controls that are relevant to be identified.

d) “You can store hashes with truncated data, its more secure!” – This is more of our previous post, where a company we spoke to started arguing on the merits of implementing truncation, encryption, hashing and storing everything together. No, it doesn’t work like that. If Truncated information and simple hashing is stored together, without a random salt, it may be easier to determine the card information through common sense brute force (please don’t talk about rainbow tables).

e) “They need me to be a level 4 certified gateway provider since I do less than 6 million transaction.” – In general service provider levels are only level 1 and level 2, according to visa and mastercard and amex. Secondly, the transaction levels for level 1 Visa and Mastercard are 300,000 volume, significantly lower than 6 million (which is for merchants). Amex has a higher threshold (2.5 million) but in general, we look at Visa/Mastercard since they are the most widely distributed.

f) “They insist on seeing a certificate of compliance – other documents are not allowed” – This has become so common that it’s painful. There is no such thing as certificate of compliance. These are all conjured up in the imagination of QSAs and PCI-DSS never issues certificates. It is technically as useless as showing your birth certificate to your bank. Yet, your bank insist upon it. FAQ #1220 of PCI addresses it below. So while it’s not wrong to issue certificates, but these are not considered “official documents”:

Because certificates and other non-authorized documentation are not officially recognized, entities that receive these documents to indicate their own compliance (for example, from a QSA or ASV) or another entity’s compliance (for example, from a service provider) should request that official PCI SSC documentation be provided. Any organization issuing, providing, or using certificates as an indication of compliance must also be able to provide the official documents. 

FAQ #1220

g) “Since you only transmit and process card data and not store, no need for PCI-DSS” – We get this a lot from banks. Technically if you transmit or process card data , you should be PCI applicable. However, since banks have a big say in your compliance (for instance they may force you to be level 1 compliant even if you have zero transactions), on the flip side, if they say they don’t need it, then well, you don’t need it. You could probably argue with them and say you actually do need it from a technical point of view, but most customers just take the bank for their word and move on. The bank has made their risk assessment, and if they insist we don’t need to be PCI compliant and gives a black and white stating they don’t need – essentially they (the bank) is absorbing all the risk of non-compliance, aren’t they? Remember – PCI-DSS is generally a contractual obligation between parties. If the bank says contractually you are not required for PCI-DSS, then what’s the argument? In this case, we usually advice our clients to still undergo a self assessment to ensure they are aware of the security practices and we then get a nod of wise agreement before they shoo us out of the room, never to be heard from again. If they had a trapdoor button that drops us into the Rancor’s pit, I guess they would have used that.

h) And finally, most recently – “they say the since we only store PAN and without expiry and CVV, they said PCI-DSS isn’t applicable to us” – this is a bit mind boggling since this bank was an international bank and we think they should know better. But that doesn’t mean local banks know less, we’ll take it back. It’s just that international banks, being exposed in so many countries, would probably have the mindshare larger than local banks to know more about these things. But this one was – “You don’t store CVV and expiry date? OK – no problem, just go ahead and store PAN for all we care! Yeay!” Granted, the use of card information without information like CVV, expiry etc may not be as useful, but there are still other ways for PAN to be used – identity theft for one. Or, it can be used in combination with other information they already have. Or they just want to sell it on the dark web. PCI-DSS puts a big premium on PAN storage, so much so saying, if PAN is stored, all other information must be protected. And oh – CVV is considered Sensitive Authentication Data (SAD), and no, it cannot be stored post authorisation for whatever reason.

There are a whole lot more of strange things we have heard over the years from banks and service providers but those are the main examples. Again, I do not think it’s due to them purposely misinterpreting the standard, but like that party game, once the message gets passed down the line so many times, eventually it’s just going to end up like garbage. It’s like how I had to deal with my wife’s instructions to buy stuff from the grocery. It’s sanskrit to me…I mean how many different pasta brands are there and why must we buy such a specific one? Pasta’s pasta, no?

If you need us to help un-garble PCI-DSS for you, drop us a note at pcidss@pkfmalaysia.com and let us get to it!

Credit Card transaction flow

It has been a VERY long while since we last updated. Q1 has been a very challenging period for not just us, but for our clients, and I am sure, many businesses around the world as well. It’s just a lot of things (not necessarily good) happening, and we can only wish all our customers and readers to be safe and to take care of oneself during these challenging times.

Instead of going into too technical a subject, it may be a good idea to just start off this decade with a quick recap on some basics of credit card flows. This allows us to understand certain things dealing with PCI-DSS and gives us some background on more technical subjects later. This article takes us back to the basic.

How does a credit card transaction flow look like?

a) A cardholder (you and me) uses a credit card to purchase something – either online (card not present) or physically (card present).

b) The merchant either uses a POS, or virtual terminal or e-commerce, but at the end the authorisation request is transmitted to the ‘acquirer’.

c) The acquirer in this case the the merchant’s bank (or payment gateway, if not a bank). Not yours (issuer). So when you receive a credit card receipt, take a look at the receipt and it should state the acquirer. The acquirer acquires (signs up) merchants to accept card payments and ensure the merchant gets reimbursed for the credit card payments they accept.

d) The acquirer sends on the request to the processor. A processor does the authorisation and settlement service for all credit card transactions for each of the cards accepted by the merchant. These generally requires a front and back end processor.

e) The processor passes the transaction to the issuer, who approves/declines the transaction for whatever reason. Your issuer is the one issuing your card and generally has badge over the card (e.g your bank).

f) Whatever the response from issuer, the processor then sends it back to the acquirer, and the acquirer then sends it back to the merchant, through the terminal or however the request came in.

g) The merchant now has the approval (or decline) code, and the transaction is completed by providing the cardholder with the receipt.

h) Now the merchant and the acquirer goes through the clearing and settlement phase and the acquirer credits the merchant’s account.

i) The acquirer submits the transaction for settlement via the processor, and the processor requests the issuer to reimburse the acquirer for the transaction.

j) Finally, the issuer post the transaction to the cardholder account and the cardholder needs to settle the account (or not) on their statement.

That, in a nutshell is how a basic credit card flow works. Of course, there are inner workings in there, such as usage of settlement banks, consolidation of different acquirers, daily clearing data file reconciliation etc. But the above overall should give you a good working knowledge of what happens when you dip or wave your card in the next transaction you make.

For more information on PCI-DSS or ISO compliance, please drop us an email at pcidss@pkfmalaysia.com! We will get back to your immediately. Stay safe!

PCI-DSS Cheatsheet

As we approach the end of the decade, we are approaching 16 years since PCI-DSS was first introduced back in 2004. 16 years. That’s probably a full dog lifetime. I would imagine the guys back in 2004 would have thought: “Let’s just get version 1 out this year. I’m sure our next generation of brilliant minds will figure everything out by 2020.”

So now we are a few ticking days away from 2020 and yet, at the end of the line, I am still answering calls that are increasing as the days go by: What is PCI-DSS and how do we get it?

Most of these callers are generally calling because our names are listed pretty high on the internet when someone types in PCI-DSS Malaysia. Apart from that, a majority of these callers are calling because we were reference by one of our clients. We have faced different variations of callers coming in: Some requests us to provide them with a PCI-DSS ‘license’ in order to operate for their clients. Some requires a ‘certificate’, some are literally clueless as to what it is but their banks have mercilessly dumped this whole requirement to them.

Step 1: Who’s Asking?

First of all, take a deep breath, here is a simple cheatsheet. Whoever is asking you to be PCI-DSS, take note of it. Here are the Usual Suspects:

Bank – Very likely you are connecting to them doing some sort of payment processing like a payment facilitator, a TPA etc. Or you could be a service provider and your client just happens to be a bank, which brings us to

Customer – your customer for some reason is dealing with credit/debit cards, either directly or indirectly, and they require you to do PCI-DSS because you are servicing them or they have outsourced to you, like BPO, Data Center, hosting, call center, or even network transit

Internal – One of your internal managers have read up about PCI-DSS and decided that your company will sound very cool if you are PCI-DSS certified. Now, in this case, you could or could not be PCI. Because PCI is a contractual obligation dealing with credit/debit cards badged with Visa, Amex, Mastercard, JCB, Diners/Discover – if you don’t deal with this or have any clients dealing with it but your company just wants to get any standard out there – my suggestion wold be to go for something like ISMS (ISO27001) as that’s a better guideline rather than a contractual standard like PCI-DSS. If you still insist – well, you could still go through the SAQ but a lot of it will be not applicable to you since you are Non-CDE for everything.

Those 3 are mainly the motivations behind PCI-DSS. Why is it important to determine who is asking, is because of the next step:

Step 2: Determine your Level

Now there are guidelines out there for which level you should be at. If a service provider, then anything over 300,000 volume of card processing will bump you into level 1. For merchant, anything over 6 million for level 1 and anything over 1 million for level 2. I can’t count the times people get mixed up with Service provider levels and merchant levels. Even banks. I have banks telling our payment gateway that they are Level 4 . There is no such thing. It’s either one or 2. For merchants there are level 1,2,3 and 4 but the volumes are different.

Now while the guidance is cool and all, at the end it’s your bank or customer determining your level. If your bank decides to only deal with you if you do a full certification and RoC with a QSA, then even if you are processing ZERO transactions, they have deemed you as level 1. You can then decide to either say OK, fine, or tell them you are taking your business elsewhere. In that case, they may decide not to play hardball. I don’t know. Same as your customer. Your customer may decide you need to be assessed by a QSA, so it’s best you determine this with whoever is asking you.

The secret sauce is this: Most of the time, your bank/customer won’t have a clue what they want. They will just say, Oh, be PCI compliant. In this case, approach them with some tact. Your mission, should you choose to accept it, should be to avoid level 1 certification as much as you can, if your volume is low. It’s not justifiable. Look, if you want to be assessed by a QSA, by all means, but at least, know that you have a choice if your volume is low, and your bank/customer isn’t fussy about it. Just tell them: “OK, I’ll be PCI-DSS compliant, and I will fill up the Self Assessment Questionnaire (SAQ) and our management will sign it off and send it over to you. Is this OK?” If yes, then great, do your own self assessment. You can save up some money.

Step 3: Determine your Controls

This is probably the trickiest part of PCI-DSS. You see, being level 1 or level 2, self assessed or third party assessed, SAQ or RoC does NOT make any difference on what controls you need to have in place. An example: Level 1 compliance may require you to do ASV scans for 3 external IPs and 20 Internal IP Penetration testing. Guess what? Even if you are doing an internal self signed SAQ, you are supposed to do the SAME THING. No difference. No “Oh, since I am level 2, I will do ASV scans for 1 IP and maybe take 5 Internal IP for Pentest instead of 20.” In theory, all controls are the same, the only difference is WHO assesses and attests these controls.

Now, of course, realistically, this is not happening. Like I always illustrate, some companies consider a firewall as a wall on fire and they sign themselves off as PCI-DSS. Hence the whole passing the buck, passing the risk thing about PCI that I won’t go into discussion here. But in theory at least, same controls apply. But how do you determine what applies to your business? Well, based on your business flows of course.

Determine above all whether you are storing credit card information. If you are not, roughly 35% of PCI-DSS is not applicable (I am plucking that % out of no where, so don’t quote me). But a big chunk isn’t applicable. Second, determine whether you even interact with credit card or not. Look into all your channels. It could be complex like a call center, or simple like a network transit. In most case if you can determine that you have no access to credit card PAN or don’t store, and don’t process, the controls that are applicable to you are minimal. You should STILL be PCI compliant, but minimal controls apply.

Step 4: Determine your vendors and outsourcers

We had a client who cancelled an ongoing PCI-DSS with us because they have deemed themselves PCI-DSS compliant because they are using a PCI-DSS software. I cannot count the number of times I have to correct them – NO. Just by using a software which is PA-DSS compliant or even PCI compliance (like Cloud) DOES NOT make you PCI-DSS compliant. Will it help? Sure it will, but can you piggy back on someone else’s compliance? No. You can’t. So either you go through PCI yourself, or stay non-compliant, but don’t say you are compliant when you are only using a software that is compliant. That’s like saying you are certified to fly a plane when you are a passenger of a plane flown by a certified pilot. Or something similar.

Get your vendors on board for PCI if possible. If they refuse you can still use them, but you now have to include their processes under YOUR PCI-DSS program. Why would you want to spend extra days getting your vendor compliant when there are OTHER vendors who already are compliant?

So there you have it:- When someone requests PCI compliant – first, review your options. There is no ONE way for PCI. Go with the least resistance – self signed SAQ if your volume allows it. That saves you a lot of time and money as opposed to getting a QSA to come in.

If you have any queries on PCI-DSS, drop us a note at pcidss@pkfmalaysia.com and we will attend to it right away! Merry Christmas!

IATA PCI-DSS: What Exactly is Required?

pci-compliance

Continuing our series on Merchant program for PCI-DSS. Why this is (or will be) so important is that in around 12 – 15 months, if you are a merchant, very likely you will be getting a call from your acquirer.

About 2 months back, Mastercard announced that all acquirers must have in place a risk assessment program for Level 4 merchants by March 31, 2019. This basically means that there is a great concern that 99% of Level 4 merchants out there are blissfully unaware of this PCI-DSS nonsense they need to comply. It is the acquirer’s duty, but the pain starts all the way at the merchants.

One industry feeling the pinch here is the travel industry. But don’t worry, travel agents, soon, the other industries like your cousins at the hotels and hospitality will be going through the same process as you are going through now. It’s just who is going through first. And the faster you get through the better.

Travel agents across the world has been mandated by IATA to be PCI compliant. Please read our previous post here.

We have gone through the requirements in that post, but we’ve been hearing a lot of things coming to us from the travel agencies recently, namely:

a) All Travel Agents need to engage a QSA to formally sign off their SAQ.

IATA should be able to give a formal statement on this. QSAs or consultants or PCI experts cannot dictate or mandate the validation requirements. Mostly this is by the processor (IATA) or the acquiring bank. If they can’t make a statement, then it would fall back into the card brand validation requirements. Which it has so far, unless IATA comes forward to clear this up. We can’t seem to find anywhere that IATA has had special requirements other than listed in the card brands requirements.

There might be further explanation needed based on their PDF at http://www.iata.org/services/finance/Documents/pci-dss-compliance-procedure.pdf

The procedure first states

Travel Agents are encouraged to contact their merchant bank (acquirer) or the applicable payment brand(s) to identify the appropriate procedures based on their eligibility.

But then at the bottom it implies that for assessment, it needs to have a QSA perform ‘on-site’ PCI assessment – which is not exactly accurate as it depends on their level. Further on right at the bottom, it states:

Depending on the number of card transactions handled those can be:
– PCI DSS Attestation of Compliance (AOC) which must be completed by a Qualified Security Assessor (QSA).
– Self-assessment questionnaire signed by an authorized officer.
– The results of quarterly vulnerability scans if applicable.

The problem here is that if the AoC is required to be signed by the QSA, so does its corresponding SAQ. These documents have the same signoff (3c for QSA) section. If you read the above you might be tempted to also argue that IATA is saying, depending on the number of card transactions (meaning your level), the requirements can be either:

– PCI DSS Attestation of Compliance (AOC) and ROC or SAQ which must be completed by a Qualified Security Assessor (QSA) – this applies to Level 1 Merchant (they can also use ISA but lets put that aside for now), and also Level 2 if you deal with mastercard.
– Self-assessment questionnaire (SAQ) and AoC signed by an authorized officer. – This applies to level 3 and 4
– The results of quarterly vulnerability scans if applicable.

Now we don’t know if this is what IATA is saying – it’s just the many ways this section can be interpreted so we do hope IATA will have a clarification on this matter. They CAN decide on a more stringent requirement for their agencies (such as ALL levels engaging a QSA to be onsite like a level 1 merchant), but this needs to be clear, so agencies can forge ahead with the proper budget and expectation.

Most travel agents fall under the Level 4 category of merchants, which based on the current requirements of PCI-DSS only requires a merchant officer to sign off the document.

Mastercard’s SDP services recently responded back to us on this with a confirmation as below:

Level 4 merchants are required to ensure they are PCI-DSS compliant by filling in the correct SAQ based on their processing environment and have the evidences prepared , and also to do this each year. There is no requirement from Mastercard to engage a QSA/ISA to signoff their SAQ on part 3c or part 3d of their SAQ/AoC and their executive signoff on part 3b is sufficient. This must be signed by the merchant. Engaging a QSA will be above and beyond their requirement and only done if they require assistance in filling their SAQ. Therefore, using a QSA is entirely optional and based on the discretion of the merchant.

This goes a long way in saying the same thing that has always been said. The logic I would argue here is, if your industry is made up thousands of merchants, how do we build a meaningful program to get all these merchants compliant? If QSAs are supposed to validate all the evidences, how much bottleneck will there be?

This is also inline with the famous PCI-DSS myth document at https://www.pcisecuritystandards.org/pdfs/pciscc_ten_common_myths.pdf. In Myth 6:

Myth 6 – PCI requires us to hire a Qualified Security Assessor
Because most large merchants have complex IT environments, many hire a QSA to glean their specialized value for on-site security assessments required by PCI DSS. The QSA also makes it easier to develop and get approval for a compensating control. However, PCI DSS provides the option of doing an internal assessment with an officer sign-off if your acquirer and/or merchant bank agrees. Mid-sized and smaller merchants may use the Self-Assessment Questionnaire found on the PCI SSC Web site to assess themselves.

Now, I know, there are so-called ‘merchant programs’ out there run by a few QSAs. I’ve spoken to many merchants who deem themselves compliant just because an ASV ran a scan on their external IP address and gave them a ‘certificate’ of compliance (which is not even a recognised document by PCI-SSC!).  If anything, it just makes the merchant falsely complacent and gives PCI a bad name and a bad rep as an on-paper compliance but practically as useful as ice is to eskimoes.

The crux of the matter isn’t whether QSAs need to be involved or not. It would be super if they can get involved, but the matter is cost and time. QSAs programs are not cheap, and also, how much work do they actually do for the client? The counter argument is, if QSAs are not involved, what then? You get a bunch of executives just signing off they have a firewall when in their mind they are thinking, “Man, Which wall am I going to have to set on fire to comply to this stupid request?”. It’s not a knock on their intelligence, but really, a lot of merchants are really good in doing whatever they are doing and they don’t exactly have a CIO to standby to interpret all the requirements of PCI-DSS for them. And PCI, despite its oftentimes banal requirements, is a compliance requiring a lot of technical understanding.

How do we solve this? Awareness.

The SAQs reason for existence serves simply as a baseline document and puts the onus on the merchant to ensure they have the proper security in place. A lot of merchants are not aware of this obligation. The moment they sign off that document, they are saying, I am taking responsibility over this document. I verify and validate this as true. If it’s not…well. If it comes to any breaches or anything, then the merchant takes responsibility.

If they are fully aware of their responsibility, then getting help is likely required. But now, there is no need for a formal QSA to get involved. If you can, then do so as QSAs do theoretically should have more experience in PCI – but consultants, or advisors can take this role. And there are many reasons why it might turn out better this way which I will explore in my next few articles.

b) All Travel Agents need to engage ASV to do their security scans

Man. This is probably the most misunderstood requirement of all time. All time. 100s of merchants have come to us proudly saying their ASV scan proves their PCI compliance. No, it doesn’t. The ASV scan is just one of many requirements you need to go through. It’s like you dressing for work and wearing only your shoes and nothing else and go to work and say, “Hey, I am all dressed!”. Um. No.

And while ASV is important, we have seen our fair share of trigger happy ASVs being done for travel agencies. Oh, you have a website? ASV! Oh, you have an internet facing IP and router? ASV!

Come on. We recently adviced one client who was having trouble remediating an issue on their website. I asked them, wow, for a small company doing internet transactions, its a big deal. And they went like, “What in the good name of **** are you talking about?” And they explained they just had a corporate website and were asked to do a scan. I went and look, and aside from the site looking like it had been designed by a 15 year old drinking too much mountain dew, it serviced no credit card transactions at all. They don’t even have any systems doing that. They just do EDC terminals that connect directly to the bank and completely isolated. So why the scan?

Because we were told, they said.

And so I drafted an email for them and told them to send it over to their QSA (they are level 4 by the way) and the response came back, “Oh thanks man, they told us there is no need to scan anymore! Yay!”.

The problem remains. How many merchants are scanning their completely static websites and receiving a certificate of compliance and pronouncing they are PCI ‘certified’? Is it the ASV or QSA’s problem? No. PCI clearly states that it is the merchant (or scan customers) who ‘defines the scope of the scan’, so merchants are taking a fair bit of the burden if the ASV is done incorrectly. ASV scans are needed if your site does credit card acceptance (SAQ A-EP). It’s also needed on any external IPs you might have if these are transmitting card information (SAQ B-IP, SAQ C). SAQ A, B and C-VT has no scan requirements listed. A lot of clients could possibly fall under the SAQ B and possibly SAQ C-VT, so ASV scans can be further avoided.

c) All Travel Agents will be fined XYZ amount for non-compliance

Now, this might be true but IATA hasn’t really come out to say anything. Frankly I will be very surprised if there is such a requirement. Basically, IATA is just saying, if you don’t become compliant, don’t connect to us. If you don’t connect to us, then you can’t issue tickets. This is a worse threat than being fined. So they don’t have to be overbearing to impose such a condition AND impose a fine for clients who are non compliant. Because technically, if you are non compliant, you are not connected to IATA. If you are not connected to IATA, what are they fining you for?

smartmurphy

d) PCI-DSS is applicable to all Travel Agents even those without credit card acceptance and transactions

OK. I am not sure whether there will be such agencies or not, meaning there is ZERO card acceptance or processing or storage or transmission in your merchant environment. Now do note, even e-commerce when you outsource your ENTIRE payment processing, the fact that you have the credit card payment option on your website puts you in need of compliance. For merchants that do not have any facility whatsoever (either card present or card-non-present), then technically, PCI-DSS should not apply. I say technically. Because if you are connecting to IATA’s processor (BSP) then even if you make zero or a million transactions, the risk is still there. So yes again IATA as the big boss of BSP has the right to ask for compliance from agencies with zero credit card transactions. In this case, my suggestion is to write to IATA  and see what is the next step. I can’t imagine any merchant business now not catering to credit/debit card payment but, wait. OK, my neighbourhood barber actually told me they only accept cash only, or barter trade my iphone for 2 years supply of haircut. So yeah, why not. But really, if no credit/debit card payment is an option and you regularly settle through agency credit or carrying a pile of cash, you technically can ask IATA what’s the next step.

In summary, we are not saying that there is some sort of conspiracy theory going on where QSAs are trying to pull a fast one on customers and creating F.U.D in the industry. After all, we ourselves have been certifying clients for 7 plus years already. But what we need to understand is that wrong information could be worse than no information. We need to get the right information out there so that merchants can make informed decisions. If they want QSAs, then ok all the better. If they prefer in house or specialised consultants, then OK. If they decide to do the hokey pokey instead of PCI compliance, then hey, that’s an informed decision on their side.

So, let’s get this awareness out. Travel agencies have about 10 months to get compliant. It’s not crunch time yet. This is like the start of the 3rd quarter in basketball. Important, but not Michael Jordan clutch time.

If you need more information on PCI-DSS applicability in your merchant business, drop us an email at pcidss@pkfmalaysia.com. We’ll get in touch with you ASAP.

The SAQ Bs and how they apply to you

pci-compliance

We always say SAQ As and Ds get all the glory and attention.

This is because a majority of our SAQ clients are e-commerce companies and therefore they apply SAQ A or A-EP depending on where their credit card information is collected.

However, recent times, we have been working on a well-known retailer and were told that SAQ D would be the one that applies to us. Now the SAQ was passed to them by the bank and the bank insisted that they do SAQ D-Mer.

Now this post is going to assume that you have some working knowledge on what SAQ’s are in PCI-DSS world. Self Assessment Questionnaires are one of the most misunderstood concepts in PCI. They are like Donald Trump’s foreign policy and the plot of Interstellar all mashed into one misunderstood mess. Often because acquirers find it so hard to understand, they just tell all their merchants that they should go for SAQ D.

Now we have fought for our clients before – where we overturned the acquirer insistence for one of our e-commerce clients to do an SAQ D-Mer, and instead got them to agree that an SAQ A-EP is sufficient. SAQ A-EP = around 140 questions. SAQ D-Mer = around 320 questions. Big difference.

Why is this important? We firmly believed in the concept of overdoing PCI is not a good thing. Why? Because our clients have other things to do and limited time and money to do these. Ideally, sure, everyone should go on Level 1 Certification. But the reason why the PCI Council created a whole bunch of ‘levels’ and then types of SAQs is simply because different businesses face different risks. It doesn’t make sense for a neighbourhood grocery that accepts 10 cards a month to implement the same million dollar controls as, say, Tesco or Exxon Mobil. So. Don’t overdo things, but don’t under-do it as well.

Back to SAQ Bs. So with this client, after talking to them a few rounds we found out that:

a) Their credit card terminals are separate and not integrated with their POS machines and connected via USB.

b) The POS machines are all connected back to the branch switch (let’s call it branch switch) and from there connects back to corporate HQ for reconciliation purposes

c) However – we found out that the Credit Card terminals have their own connectivity to their own ethernet switch (lets call it Credit Card switch) that connects to an ISDN router and directly to the bank.

This means, there are two flows – once the credit card is used on the Credit Card terminal, the card information is sent out directly via ISDN to the bank. Whatever approval etc that comes back, it will go through the USB to update the POS.

The crunch here is that NO CREDIT CARD information is ever sent back to the client’s environment. Everything is out through the bank environment – as the Credit Card Switch all belongs to the bank. It’s only located on the customer premise but the customer has no access to it – physical or logical.

So begin our argument with the acquirer, to overturn their SAQ D to SAQ B or B-IP. Let’s look at SAQ B criteria as per PCI document:

a) Your company uses only an imprint machine and/or uses only standalone, dial-out terminals (connected via a phone line to your processor) to take your customers’ payment card information;

Seems like it. Technically, the question here is whether a credit card terminal connected to a POS machine with USB is considered ‘standalone’. Our argument here is yes, as long as no credit card info flows through that USB connection and only approval/decline/transaction dollar amounts etc. Remember the USB connection connects the terminal to to the POS machine (a Windows box). Credit card info flows out the other way, directly to the bank via a circuit switched technology like ISDN (i.e dial out). For the millenials, ISDN used to be the granddaddy of broadband. If you have ever gone through internet connectivity era with normal dial up 14.4kbps, ISDN is like what God would send to us out of mercy and grace.

b) The standalone, dial-out terminals are not connected to any other systems within your environment;

Again, the argument here is ‘connected’. What does this mean? Is it through IP means, or even an RS232 connectivity is considered connected? Our reasoning is that this is USB connection and no card data flows through this ‘connection’ and we will use this reasoning once we get on the table with the acquirer.

c) The standalone, dial-out terminals are not connected to the Internet;

No they aren’t. They are on ISDN direct to the acquirer.

d) Your company does not transmit cardholder data over a network (either an internal network or the Internet);

No they don’t. In fact, no credit card info is stored, processed or transmitted anywhere in the customer environment. Except for the physical protection over the bank equipments residing on customer premise.

e) Any cardholder data your company retains is on paper (for example, printed reports or receipts), and these documents are not received electronically; and

They do have some credit card info on paper which they need to protect, but these are manual forms they need to fill out for refund process. And the process is dictated by the bank.

f) Your company does not store cardholder data in electronic format.

No, of course not.

So you see, except for the tiny word ‘connected’ in question b), our client does meet all the SAQ B criteria. It’s really ridiculous to have someone go through the entire SAQ D when they do not have card holder data in the environment they control. And what if they have 80 branches, each with 10 POS terminals and servers? That would mean 800 systems in all branches come into scope for pentest, internal scans etc? No wonder I hear some retailers using PCI as a cuss word these days.

So, we don’t know how this is sorted out yet, but we will soon, and perhaps that will constitute another post. For now, if you need any help with your PCI-DSS – SAQ or Level 1 certification, drop us an email at pcidss@pkfmalaysia.com.

Cheers for now!

« Older posts

© 2020 PKF AvantEdge

Theme by Anders NorenUp ↑