PKF AvantEdge

Category: IT Security (Page 6 of 15)

Is PCI-DSS the most confusing standard?

June 24, 2020 / / 0 Comments

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!

PCI-DSS and Vendors

June 20, 2020 / / 0 Comments

One of the things that advisors and consultants do, as part of our journey to get our clients to comply to PCI-DSS is the inevitable (and unenviable) task of dealing with vendors. A vendor can be classified as anyone or any company that is selling a service or a product to our client, that directly or indirectly relates or affect their PCI-DSS compliance. Examples include firewall vendors, encryption technology vendors, HSM vendors, server vendors, Virtual solution vendors, SIEM vendors, SOC providers, call center solution vendors, telemarketing services, hosting providers, cloud providers and the list goes on. Having dealt with hundreds of vendors over the course of the decade we have come across all kinds: some are understanding, some are hostile, some are dismissive, some are helpful and the list goes on.

But there is always a common denominator in vendors: They all start by justifying why their product or service is:

a) Not relevant to PCI-DSS compliance (because they don’t store card data, usually)

b) Why their product is PCI acceptable (but it’s really not, or when we have questions on certain aspects of it)

It always begins with these two start points and it can then branch off into a myriad of different plots, twists, turns and endings, very much like a prolonged Korean drama.

With this in mind, we recently had an interesting call with one of such vendor, who basically runs a fairly important PCI subsystem for one of our clients. The problem was that their logs and console had two things that we sometimes find: the combination of truncated and hashed values of a credit card information, grouped together.

Now, just a very quick recap:

a) Truncated card data – This is where you see parts of the card replaced by XXXX characters (or any character) where the full card number is not STORED. Now it must be noted that TRUNCATED and MASKED are treated differently, although oftentimes confused and used interchangeably. When we say something is MASKED, it generally means the PAN (Primary account number) is stored in full but not displayed in full on the console/application etc. This applies sometimes to call centers or outsourced services where full PAN is not required for back office operations but for reconciliation or references. TRUNCATED here means even in storage, the full PAN is not present.

b) Hashed Card Data – Hashing means its a one-way transformation of card data into a hash value with no way to reverse it (Unlike encryption). If we use a SHA-256 hash algorithm on a PAN, you get a fixed result. Fraud management systems may store this hash PAN in order to identify transactions by that particular card (after hashing), and not worry about the actual card data being stored. It’s like hashing of passwords where the actual password isn’t known.

It’s to be noted, when done properly, these two instances of data may even be considered entirely out of scope of PCI-DSS. The problem here is when you have both of these stored together and correlated together, it renders the data protection weaker than just having one control available. This is probably where the concept usually gets lost on clients implementing these controls, as we have seen many times before – for example, tokenized information being stored together with truncated values.

Even PCI-DSS itself states clearly in the standard item 3.4 in the Note, that “Where hashed and truncated versions of the same PAN are present in an entity’s environment, additional controls must be in place to ensure that the hashed and truncated versions cannot be correlated to reconstruct the original PAN.”

To clarify, it doesn’t mean that it CANNOT be done, but additional controls must be in place. A further look at this is found in the Tokenization Product Security Guidelines Supplementary document:

IT 1A-3.b: Verify that the coexistence of a truncated PAN and a token does not provide a statistical advantage greater than the probably of correctly guessing the PAN based on the truncated value alone.

Further on:

…then the vendor provides documentation to validate the security strength (see Annex C – Minimum Key Sizes and Equivalent Key Strengths for Cryptographic Primitives) for each respective mechanism. The vendor should provide a truncated PAN and irreversible token sample for each.

And furthermore in Tokenization_Guidelines_Info_Supplement.pdf:

Note: If a token is generated as a result of using a hash function, then it is relatively trivial effort for a malicious individual to reconstruct original PAN data if they have access to both the truncated and hashed version of the PAN. Where hashed and truncated versions of the same PAN are present in the environment, additional controls should be in place to ensure that the hashed and truncated versions cannot be correlated to reconstruct the original PAN.

So in short, at anytime we see there are hashed values and truncated value together, we need to validated further on the controls. A good writeup is found here at another blog which summarises the issues surrounding this.

However, as our call with this particular vendor continued on, he demonstrated just how vendors should or should NOT approach PCI-DSS compliance, which sort of inspired this post:

A) DON’T place yourself as the topical expert in PCI-DSS: Don’t. Not because you are not, but because you are representing a product or a service, so you always view certain things through a lense you have been trained on. I know, because I was with vendors for many years and most of our consultants are from vendor backgrounds. He immediately started by stating, he is extremely well verse with section 3.4 of PCI-DSS (which basically talks about the 4 options of protecting card holder data stored), and that he has gone through this conversation many times with consultants. This immediately sends the QSA red flags, once the vendor starts moving away from what they know (their product) to what they may think they know but generally may not (PCI-DSS), and in general we don’t want to put the auditor on defence once vendors sound defensive. It should be collaborative. DO state clearly that we are subject matter experts in our own field and we are open to discussions.

B) DON’T recover by going ‘technical’: In his eagerness to demonstrate his opinion on PCI, he insisted that we all should know what 3.4 is about. Concerning the four controls stated in PCI-DSS (token, truncation, hashing, encryption), he claimed that their product is superior to what we are used to because his product has implemented 3 out of 4 of these controls (hashing, truncation and encryption) and he claims this makes it even more compliant to PCI-DSS. At this point, someone is going to call you out, which is what we did reluctantly as we were all staring at each other quizzically. We had to emphasize we really can’t bring this to the auditor or justify this to our client who was also on the call, as this is an absolute misinterpretation of PCI-DSS, no matter what angle you spin. PCI never told us to implement as many of these options as possible. In fact, clearly stating if more than one of these are introduced, extra care must be taken in terms of controls that these cannot be correlated back to the PAN. We told him this was a clear misinterpretation to which his response was going into a long discourse of where we consultants were always ‘harping’ on impractical suggestions of security and where we always think it’s easy to crack hashes just because we know a little bit about ‘rainbow tables’. We call this “going technical”. As Herman Melville, the dude that wrote Moby Dick puts it:

“A man of true Science uses but few hard words and those only when none others will serve his purpose; whereas the smatterer in Science… thinks that by mouthing hard words he understands hard things”. – Dude that wrote Moby Dick.

Our job is really to uncomplicate things and not to make it sound MORE complicated, because there may always be someone in the room (or video conference) who knows a little more than what they let on.

DO avoid jargonizing the entire conversation as it is very awkward for everyone, especially for those who really know the subject. DO allow input from others and see from the point of view of the standard, whether you agree or disagree or not and keep in mind the goal is common: to make our client compliant.


C) DO find a solution together. As a vendor, we must remember, the team is with the client. The consultant is (usually) with the client. So its the same team. A good consultant will always want vendors to work together. We always try to work out an understanding if vendors cannot implement certain things, then let’s see what we can work on, and we can then talk to the the QSA and reason things out. Compensating controls etc. So the solution needs to be together, and finally, after all those awkward moments of mansplaining everything to us, we just went: “OK, let’s move on, these are the limitations, let’s see where the solution is.” And after around 5 minutes or so, we had a workaround sorted out. Done. No need to fuss. So next step is to get this workaround passed by the auditor for this round and if not, then we are back again to discuss, if yes, then done, everyone is moving out to other issues. Time is of essence, and the last thing we need is each of us trying to show the size of our brains to each other.

D) Don’t namedrop and look for shorter ways to resolve issues. One of the weirdest thing that was said in the conversation after all our solution discussion was when the vendor said that he knew who the QSA was and he dropped a few names and said, just tell the QSA it’s so and so, and we’ve worked together and he will understand. Firstly, it doesn’t work like that. Namedropping doesn’t allow you to pass PCI. Secondly, no matter how long you have worked with someone, remember, another guy in the room may know that someone longer than you. We’ve been working with the QSA since the day they were not even in the country and for a decade, so we know everyone there. If namedropping was going to pass PCI, we would be passing PCI to every Tom, Dick, Harry and Sally around the world. No, it doesn’t work that way, we need to resolve the issues.

So there you have it. This may sound like a rant, but the end of the conversation was actually somewhat amicable. Firstly, I was genuinely appreciative of the time he gave us. Some vendors don’t even get to the table to talk and the fact that he did, I really think its a good step forward and made our jobs easier. Secondly, we did find the workaround together and that he was willing to even agree to a workaround, that’s a hard battle won. Countless vendors have stood their ground and stubbornly refused to budge even when PCI non-compliance was screaming at their faces. Thirdly, I think, after all the “wayang“, I believe he actually truly believed in helping our client and really thought that his product was actually compliant in all aspects. Of course, his delivery was awkward, but the intention was never to make life difficult for everyone, but to be of assistance.

At the end, the experience was a positive one, given how many discussions with vendors go south. We knew more of their solution, we worked out a solution together and more importantly, we think this will pass PCI for our client. So everyone wins. In this case, the Korean Drama ended well!

For more information on PCI-DSS, drop us a line at pcidss@pkfmalaysia.com and we will get back to you immediately! Stay safe!

Credit Card transaction flow

March 10, 2020 / / 0 Comments

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

December 11, 2019 / / 0 Comments

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!

The Art of Compensating Controls

October 20, 2019 / / 0 Comments

In our many advisories over the years with companies going through PCI, some of the challenges we face include this little thing called compensating controls.

It’s a PCI term in many sense. Same as ‘segmentation penetration testing’. It’s when you can’t address the actual control in PCI-DSS for a reason and you need to put other controls to address the ‘spirit’ of the control. The spirit means: why did PCI-DSS put that control in, in the first place?

Immediately, this becomes an outlet of some of the greatest creativity ever existed in our technology field. If everyone involved can channel such creativity of controls into developing innovative tech, we would be far ahead achieving the technology vision 2020 that our country is lagging behind in. As they say: Necessity becomes the mother of invention. So everyone starts inventing controls.

Unfortunately such invention of controls in thin air will likely face a bounced rejection from the QSA which would further cause stress due to the impending deadline and the admission that the compliance will be delayed. So it’s in everyone’s interest that compensating controls are done correctly from the beginning.

Now this article’s purpose is not to go through the whole list of what compensating controls are. There are already thousands of articles that do that. Suffice to say, a compensating control is when you cannot meet the PCI requirements and you still want to be compliant.

So to make it simple:

a. Write which control you can’t address. It may be logging and monitoring, complex password etc.

b. Why can’t you do it? Some good reasons are that the legacy system that runs on the factory store churning out a thousand printed statements a minute, that cannot be patched due to patches no longer being produced. A bad reason is, Bob is new to the company and has no clue what does patching means.

c. Risk Analysis. This isn’t something natural many companies do for IT, but it has to be done. If the system cannot be patched what are the risks? Infection of malware? Internal exploit? Availability problem? Loss of power?

d. Document the control. This has to be done. You can’t just go and say, “OK, QSA, trust us, it’s in.” It needs to be detailed procedures on how the organisation will carry out these compensating controls.

e. Ensure it’s implemented and validate it with the QSA. In fact, we would suggest to bring in the QSA early in the process. Since they are the ones validating your controls, it makes sense to onboard them with the fact that you are doing compensating controls. What you may find acceptable to your risk may not be acceptable to the QSA. It’s not a matter of, “Hey, let me bear the risk this year!”. It’s a matter of “If this thing goes south, who else is going to be affected?” – QSA, banks, companies – because credit card information isn’t just the domain of the company handling it – it has upstream and downstream repercussions – from the payment brands, banks, acquirers TPA, service providers to the customers.

To be honest, compensating is a major pain in the butt. There is no way to describe it better. It’s actually worse that the actual controls. Plus its not a given each year – QSA may decide due to next year’s evolving risks your controls are no longer acceptable!

An example here: say you can’t patch your pre-historic system for a good reason. The vendor has since announced they no longer support that system and a new release is imminent in a year’s time and the notice is for all customers to bear down and wait for the release. At this moment it’s completely out of the customer’s hands.

The compensating controls could be

a) Having a documented notice from the vendor that security patching cannot be done

b) Hosting the system in an isolated VLAN that does not have any other CDE/non-cde systems

c) MFA needs for ALL access, not just administrative

d) Firewall rules must be specific to port/source/destination

e) Copy/paste, USB etc are disallowed in said system, and any attempts to do that is logged through DLP.

f) Antimalware must be installed and logs monitored specifically

g) Logging and monitoring needs to be reviewed daily specifically for this system and a report daily separately for incidents to this system

Taking a look at the above examples, these are controls that are considered above and beyond what is necessary for PCI requirements. In short, its a lot harder or more expensive to get compensating controls done than for the actual controls, no matter what you may think.

We once had a conversation with a company who were thinking of switching to us from previous consultants. When asked, we realised that many of their systems were not PCI compliant and they had put in compensating controls. Their compensating controls were: “Mitigation plan is in place to replace these systems in a year’s time.”

That’s not a compensating control. That’s something you plan to do in 365 days time. In the meantime, what are you proposing to lower the risk? That’s your compensating controls.

Don’t use the compensating controls as a get out of jail free card. Any consultant/QSA worth their salt would know how difficult it is to get these controls done and more importantly passed for PCI-DSS. In other words, instead of looking at it as a convenient shortcut or workaround, it should be viewed as the last resort.

Drop us a note at pcidss@pkfmalaysia.com for any queries you may have on PCI-DSS and we will respond to that immediately!

« Older posts Newer posts »

© 2024 PKF AvantEdge

— Up ↑