PKF AvantEdge

Page 13 of 40

PCI-DSS and the problem of Email

February 4, 2019 / / 0 Comments

When we first started with PCI-DSS many years ago, most of our clients were service providers – payment gateways, financial institutions, and two banks. They had their challenges – in some cases, their scope were containable (payment gateways) due to the limitation of locations – and in the bank’s cases, at least they understood the massive headaches they faced in getting their entire environment compliant (with ATMs etc all in scope).

We saw a shift over to service providers OF service providers – hosting companies, Data Centers, BPO, outsourced call centers etc. Their challenges were somewhat different – call centers especially, because of their central hub of connectivity – their telephony system, and another big problem: Email. Email issues in PCI are longstanding and absolutely difficult to resolve – and it reaches to most businesses – travel agencies, hospitality, healthcare, insurance and so on .

When email first came out in the late 60s and early 70s, I can almost imagine how excited the users were. I wasn’t born then. But I recall back in the Uni days, early days when IRC/ICQ first came out, the level of excitement we had in communicating with an actual human being a thousand miles away INSTANTANEOUSLY was so mind numbingly out of this world. Back then, we spend countless hours in the school lab, playing these text based dungeons and dragons online called Multi-User Dungeons or MUDs for short, and completely almost failing all our subjects in the process. But the excitement was there: communication.

In that sense, email is almost half a century old and is still going strong. Primary communications are still through email, for business and personal communications. Email was never built to be secure. In fact, like the wonderfully robust (but now phasing out) SMS, when it was first used, no one imagined it would become the backbone of world communication as it is today. Nobody decided back then: hey, let’s prioritise security! Hey, let’s ensure that nobody can tap into this email of ours and see our messages! Email was like the conversation in the bar. Anyone could be standing around you, or sitting next to you and listening in to your conversation — and it was ok.

Until now, it isn’t.

Well, at least from PCI-DSS perspective.

“Never send unprotected PANs by end-user messaging technologies (for example, e-mail, instant messaging, SMS, chat, etc.” – Requirement 4.2 (PCI v3.2)

Unfortunately, a lot of business utilises email as the primary channel for PCI information. Hotels we deal with, travel agencies we have worked with – call centers etc – email is sent with card data because of the convenience and the efficiency of the whole process. When we enter these environments and suggest them to look for alternatives to e-mail, we invariably face a force so strong, it’s like hitting the stone wall of Helm’s Deep: Business.

Try as we might, we often end up talking about how we can use email AND pass PCI-DSS.

Now, it’s not impossible. But by the time we are done, we are basically looking at something so extraordinarily difficult or so expensive we invariably end up taking the path of least resistance (and least cost).

But how would you have EMAIL AND PCI-DSS?

First of all, we need to understand that like water, email exist in many forms. Or rather many locations.

First of all, it’s on the endpoints. This is where the email containing card data is sent and received. So, you have data at rest. All endpoints, whether agents or cashiers, or call center workstations are in scope as CDE (card data environment). All endpoints need to have their data encrypted. You could opt for a full disk encryption, folder encryption or simply data encryption: either way, your key needs to be managed appropriately as well. If you allow devices like iPads or phones to access, you are in a world of hurt, because basically it becomes impossible to secure these devices.

The second form is in transmission. Because email isn’t point to point, it hops through multiple relays, and multiple routing points to get to where it needs to be. At any point of the journey, your email could be sniffed, or leaked. Thankfully, many email services like Office 365 is able to encrypt TLS1.2 on transmission. Obviously this helps a lot – but that’s still only on transmission.

The third form is on the interim server(s) – mail servers, relays or anything else in between before the message ends up in the recipient’s mail boxes. Whether you are running your own mailserver or using a separate provider’s, the challenge is the same. How do you ensure that the messages at rest, be it temporary or permanent, are protected?

Pretty Good Privacy (PGP) has been often offered as a solution by kindly QSAs to assist in this matter. The problem with PGP is numerous. One, it’s very old. And more importantly, it’s very difficult to use. To make it easier, some email clients had tried to simplify it, but in doing so may render it vulnerable to attacks (see the recent EFAIL attacks here: https://efail.de/). And what if we don’t send over our public key? Or forget to encrypt the communication? At best, it’s similar to the problem that QSAs have with the manual muting int telephony systems. In theory, it might work (if vulnerabilities are removed, and if users use text-based only encrypted messages), but practically is a different story. Even before the recent researches to PGP’s vulnerabilities, everyone basically knows that PGP doesn’t encrypt meta-data (the information needed to route email) – so subject lines etc are all visible. It may not look like much, but a resourceful hacker will find these information gold.

If PGP is not used – how about some of the recommended secure messaging systems like Signal or Telegram? The problem is that these are not email technologies and these have issues of their own. How do you filter out Signal? If you do receive Signal/Telegram messages on your phone, it brings your devices all in scope. How do you run a PANScan on your phone? How do you secure every phone device there as per PCI requirement?

So how do we use Email for PCI?

The only solution it seems now, is to have a PCI-DSS service provider for Email and to use them. As we don’t represent any service provider, we won’t list them down here, but a simple google search will give you some alternatives. Be aware though, to go through their AoC and ensure that their email service is fully certified. It may be likely as well for the QSA to request more information on the encryption and key management as well, as to whether keys are managed by clients on (likely, such as in the case of cloud services), managed by the provider, or they can provide a client-managed key cloud solution.

That’s only half the solution (if that manages to pass). The second problem you have is to limit the endpoints accessing the PCI compliant service as these are considered CDE. Now remember, everything connecting to the CDE becomes PCI scope. So for the rest of the organisation using email for other purposes or needing email on their phone etc (let’s call this corporate email, vs the secure email for PCI) – the corporate email needs to be segregated from the secure email. This means separate solution. This means separate emails for corporate and secure – in most cases, meaning separate email addresses. While theoretically you can split email through subdomains, the main domain still needs to accept the initial email before forwarding – so for instance if you want to have pcidss@mycompany.com come to your specific secure email provider, unfortunately, it will still hit the MX record (Mail Exchange) of mycompany.com, which means your corporate email gets into scope. It’s an endgame there. Once corporate email is in scope, it’s over. Everything else becomes impossible to be compliant.

So you need to have mycompany2.com for secure email. It doesn’t seem too difficult and it might be possible – but let’s say you have 10,000 agents or clients or service providers in the field – how do you re-educate an entire workforce to get them to resend? Remember, you can’t incrementally ‘migrate’ – i.e continually use the old email and then forward it over to the secure email – you need to completely move over to the new email service and shut down processing card on the old email. This means a lot of lost business, a lot of customer experience issues, a lot of complaints – all adding up to business issues.

After that, isolating receiving end points becomes an issue as well. All endpoints come in scope so depending on your business, this could be a secure room with only a few systems, or a distributed nightmare if you have 200 branches or outlets receiving these emails. This isolated segment is CDE, so anything it touches becomes NON-CDE in scope. Yes. It’s a nightmare. Any shared services will be pulled into non-CDE but in scope. If you want them to also use their corporate email, corporate email comes in scope. All endpoints subjected to full PCI controls. On top of that, most QSAs will likely require additional controls like data loss prevention to be present in the gateway or endpoints if let’s say the CDE systems are hooking on to another potential channel to send email (like the corporate email). Key management also comes in play for the full-disk, folder encryption at rest in the endpoints.

Overall, the massiveness of using email for PCI is difficult. I think the whole point that business wants to use email for PCI data is either the ease of use, or not changing the current way of doing business. Both are not on the cards – even if email is continually being used, the ease of use is no longer there for PCI. Also, the customer experience and frustration could be ten times worse that searching for another solution like secure repository or customer portal, or tokenisation or something. The amount of complaints foreseen in implementing new procedures, new techniques, new solutions etc – these are not just operational security nightmare, it’s a business nightmare. Plus your entire business becomes hinged on the service provider being PCI certified. What if they decided not be? Or they fail their next audit? Or they get acquired by a competitor?

If a business is willing to embark on the complexity of getting email in scope for PCI, a humble suggestion we have would be to look for alternate solutions and have them on the table as well. Because once everything is scrutinised and risk is assessed, then they would have the full picture of what they are dealing with.

For more information on PCI-DSS or any compliance or IT advisory, please drop us an email at avantedge@pkfmalaysia.com.

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!

Book Review: Artemis

January 7, 2019 / / 0 Comments

One of the things under New Year Resolution would be to read at least one book per month.

When I was back in college days, there were years where I targeted 30 books read per year. That’s an average of 2.5 books per month! And back then I wasn’t keen to pursue technology or anything, I was trying to pursue a career in literature. So the books read weren’t your typical books. The books tackled were War and Peace, Crime and Punishment, David Copperfield (not the magician, but the book by Dickens), all of Thomas Hardy’s (not the actor, but the English novelist and poet) works and so on. I recall reading several translations of Les Miserables in the university’s library and wasting away in one corner when I was supposed to be studying something else.

Obviously life doesn’t work out the way you plan, so after that period, reading has been limited to just online stuff and magazines. This year, as every year, starts with amazing resolutions and one of it is to get back on track to read BOOKS , specifically those related to our work and industry. And specifically those that has actual papers and does not consist of me staring into a screen.

So, to make life easy, I start off the year with Artemis which is completely unrelated to our work and industry but works as a warm up to reading more related books.

Artemis is written by Andy Weir, the guy that wrote The Martian, which was turned into a film starring Matt Damon as the guy stuck in Mars for God knows how many days. The Martian was a good film. I didn’t read the book, so I thought, OK, let’s pick this one up.

Artemis is the sort of book that you could probably read through within a few days, which was exactly what I did. It’s about a girl, on a moon colony, sabotaging something, getting into a murder plot, escaping, and doing a lot of stuff and then lives happily every after. On the moon.

I think the story isn’t great. The writing isn’t great. But the tech in there is pretty cool. Half the book is about expositions on how we can possibly live on the moon. It’s like Andy wanted to write a thesis on living on the moon but thought, “Heck it, it’s just too damn boring and I already made trillions from the Martian, so I’m just going to write some sort of story on top of my thesis.” It’s exactly what it is. This isn’t new. When I was younger, I wanted to write a book about programming and hacking (I thought I was a good hacker back then, but I thought wrong) and I drafted an idea of putting in a story and having little boxes within the novel to explain the technical terms that the protagonists are talking about. It’s like writing a book on PCI-DSS and then on top of it, make a story of how a merchant is swindling billions from a bank and then going through the 12 requirements to escape life and death situations. Um. Yes.

So Andy writes about the girl, but actually, it just doesn’t sound like a girl. It sounds like a middle aged male nerd like me describing what I think a 24 year old millennial girl will be thinking. It’s a very weird sensation in the novel. I read it and sometimes I get lost in the exposition like how many kPA it is on the outer hull of the moon base (what?) or how we can light fire in vacuum to weld something, or how we get oxygen from aluminium or whatever – and then suddenly the voice in the novel goes, “Hey I am a sexy girl.”

Wha-?

There was a scene where the protagonist reminded me she giggles like a girl, and that she looked like a tramp. Or that she took a lot of ‘shots’ on her face. Don’t get me wrong, I suppose, I would write a girl like that, but I am not a girl. I don’t think girls think like this, unless your name is Chastity Chandelier starring in XXX Twin Peaks. So no, the voicing is very weird. The pacing is also very strange. It’s like Andy couldn’t decide if he wanted this to be comedy or drama. In the middle of a life and death situation, the girl can make jokes.

The final third of the book is not great. The climax is very jumbled, the way how everything resolves itself is unbelievable and it’s like Andy decides that he had to submit the story on a deadline and he just went like, WTF, here it is. I mean “spoiler ahead” – the final third is about how she saves the entire city of Artemis from being chloroformed and everyone in the city has fainted. Huh? And when they woke up, nothing happened. Nothing. Even with a toddler, or baby being knocked out by chloroformed and minutes away from dying wakes up and continues to watch Thomas and Friends without being brain-damaged.

And speaking of which, writing science fiction is always tricky because at best you are writing something that is in the future. Like maybe 30 – 50 years from now. Why do the people still reference the same thing as the people in 2018? Like Buster Keaton or present day things. Wouldn’t they have something that had occurred 10 – 15 years from now, a new cultural phenomenon that would have happened and the writer should reference it? It doesn’t have to make sense to us. It just had to make sense to the narrator. And often times, the narrator breaks the fourth wall by suddenly out of nowhere, accuses us (the reader) of pretending to know what a niqab is or laughing when she said she sucked a water nipple from her space suit. Honestly, I wasn’t even thinking about it. Get on with the story, Andy!

Conversations between the characters are also very weird. It’s like some sort of high school reunion at the end, when the characters poke fun at each other while sabotaging a nuclear reactor or something, and the father of the heroine grunts disapprovingly. I think The Martian was a success because the conversations were basically in the head of the hero. He was alone. Here, the heroine has 2,000 people in the city to converse with and none of these conversations were realistic.

At one point, I just decided that I better hurry up and finish it before it becomes one of those ‘unfinished’ novels for me. It was during the climax scene where we are not supposed to know what happened, whether she made it or not etc. She suddenly, in the middle of very tense scene, made the statement like: “Meanwhile elsewhere, the other guy at another location was doing this and this, because he TOLD ME ABOUT IT later when all this was over.”

Hah? Got such thing meh? Stories in first person narrative is very tricky because there is no other POV (point of view) of other characters you can take. So Andy cheats here. He explains what happened elsewhere and how the heroine knows about it was that this story was conveyed to her AFTER everything was over, which means, she is narrating everything based on past events. It basically either states the writer can’t give a damn anymore, lazy writing, or is just going like: Hey, this is going to be a Hollywood Blockbuster even if I write that a purple octopus came out of the moon and ate the rover….this is what the term “Jump the Shark” means. This scene jumped the shark for me.

However, if you really want interesting ways that the moon could eventually be colonised, it’s an interesting read. If you want a good story, probably not. If you want a story that might turn into a hollywood blockbuster, then yes, maybe. But this is a tough read, not in terms of actual reading (it flows very simply), but in terms of the storyline.

Andy does get a lot of interesting stuff out in terms of his Thesis on Colonising the Moon. But it’s a miss in terms of actual story and protagonists.

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!

The Service Provider Challenge for PCI

August 12, 2018 / / 0 Comments

While it’s very tempting as consultants to just sometimes approach a customer requiring PCI-DSS and after identifying all their service providers, declare: “I need all your service providers to also be PCI-DSS compliant and certified!”, the truth of the matter here is, that you don’t need to. As in you (undergoing PCI) do not need to have all your service providers compliant and it will not affect your own compliance.

PCI SSC made it very clear with the publication found in their Third Party Assurance supplementary document. 

If you have time, it’s a very good read.

Service provider compliance comes in requirement 12.8. As per document:

 

When engaging with a service provider, the PCI DSS compliance must be verified with one of the following methods:

  • For providers that have undergone their own PCI DSS assessment: request and review the Attestation of compliance, scope, date
  • For providers that have not undergone their own PCI DSS assessment: include the provider’s environment as part of the entity PCI DSS assessment (increase your own assessment scope). You may need to request your own QSA to perform the provider’s review.

For the second part, it’s of course, a bit tough, seeing that you are actually paying a QSA to perform an audit for someone else, when you would think they should be paying for it.

Basically, we do need to ensure that PCI DSS clauses are present in all contracts, especially for ensuring compliance maintenance, liability, right to audit, and right to terminate in case of non-compliance to PCI-DSS. This might be a good time to call your contracts personnel and start drawing up another one. (Address 12.8.2)

It’s 12.8.4 that stuffs us up: Maintain a program to monitor service providers’ PCI DSS compliance status at least annually. This generally means, it has to be either a level 1 or SAQ verification of the service provider.

The document above actually provides a guidance for different scenarios in section 6.2: Other Considerations. It’s certainly worth the read. We have a scenario where the service provider is compliant but refuses to provide information. In 6.2.2 we also have a scenario very relevant to many: Third-party Service Provider has not Validated PCI DSS Compliance.

This is quite troublesome, but unfortunately, this is much more common than you think. A lot of providers don’t even have a clue what PCI-DSS is all about.

So if you do end up with a provider without any PCI but its too difficult to change, there is still a way out:

  • “If the TPSP (Third Party Service Provider) has not yet completed PCI DSS compliance, ask for a detailed plan with deadlines for finalizing the PCI DSS compliance process; make sure the TPSP provides status checks on a regular frequency until it achieves PCI DSS compliance.”

It really doesn’t sound that great to be honest. It’s like babysitting a misbehaving child and you just want to get it over with and have other things to do later that night but this kid is just not wanting to sleep and you feel like getting some cough syrup to mix into his milk…that sort of feeling, not that we have any first hand experience on that kind of inhumane stuff. Pftt. Of course not. We all have perfect children.

But for these service providers, you do find yourself wondering if you ended up with the short end of the stick.Extract below:

  • “If an agreement exists between the entity and the TPSP, the entity may consider an examination of the contract or agreement with the TPSP to determine which party is responsible for mitigating the non-compliant data or process.
    • Consider whether the non-compliant service or process is essential and the impact of stopping it as soon as possible until a solution can be developed.”
    • For business-critical issues, the entity and TPSP should work together to determine who will be accountable for the cost and responsibility for correcting the issue, if necessary. Discuss with legal counsel to ensure the entity or the TPSP and any nested TPSP use appropriate agreement/contract change provisions or clauses to negotiate a fair and reasonable timeframe to remediate the non-compliance issue.
    • Discuss with the TPSP and agree on introducing compensating controls as soon as possible that mitigate the risk of continuing with the non-compliant process or data exchange—while work continues on its remediation.
    • Prepare a remediation plan that can be provided to the entity or the TPSP in a form that can be used as evidence (e.g., Compensating Controls Worksheet) to provide a QSA if a PCI DSS compliance review is due within the remediation timeframe.
    • Ensure any nested TPSPs meet the agreed obligations with regard to remediating the non-compliant issue and keeps the TPSPs informed of progress.”

That’s a lot of stuff. “Nested” TPSPs in the last point doesn’t mean they have the same nest, it simply means that if there are dependence on remediation of this TPSP (i.e the TPSP of the TPSP), these guys also need to understand they are pulled into scope. It’s very headache.

In conclusion, it’s probably better to start looking out for TPSPs who are already compliant or who understands their PCI compliance obligations, and for those who refuse to put in their effort on this compliance, well, be prepared to get left behind. Because once one or two of the same industry TPSP gets compliant, it will no longer be the norm to be NON-COMPLIANT and this TPSP will stand to lose out customers in the future.

For information on how to handle your PCI-DSS requirements, please drop us an email at pcidss@pkfmalaysia.com and we will get right back to you ASAP!

« Older posts Newer posts »

© 2024 PKF AvantEdge

— Up ↑