PKF AvantEdge

Month: March 2019

The Service Provider Conundrum

March 28, 2019 / / 0 Comments

This is probably the umpteenth time I am writing this, but again we need to clarify once more on how Service Providers that do not store, process or transmit credit cards come in scope for PCI-DSS.

I just finished a very testy call with a multi-factor authentication cloud provider (actually he is a reseller/distributor), who called us back on our enquiry whether his cloud service is PCI compliant or not. He said he doesn’t need to be but their solution will help our clients in becoming compliant. If I get a dollar everytime this argument is punched out, I will be retired in the Bahamas by now.

Now, to be fair, almost everyone thinks like this. “If we do not store, process or have any credit card processes, we don’t need to be PCI compliant.” It may be like this in the past, but unfortunately, QSAs are tightening up their definitions of service providers and cover what we now deem as having ‘security influence’ over CDE .

So yes, you technically have nothing to do with credit card of your clients, but let’s say your client authenticates to your CLOUD solution to get multi factor authentication to access their CDE. Let’s say you are having a bad day and you get compromised, and the attacker hijacks your cloud and provide a counterfeit token attack similar to what was suspected to have occured on the RSA SecurID breach in 2011. Would a scenario like this equate to a CDE compromise? Would this mean your service is actually having security influence over CDE?

I could have explained this to the earnest reseller on the other end of the call. But I was fighting a fever, cough and flu all thrown in one large ball of crappiness that made my mood not so great. And the fact that he sounded a little patronizing when he said, “Oh, you are very confused. We don’t need PCI-DSS, so maybe you need to understand the standard a bit more.”

Hey, Captain, I’ve been living in this PCI crap for the past 8 years. I wish I didn’t understand it as much as I do right now to be honest because then I can always plead ignorance when questions like these pop up. As it is with all who are cursed with knowledge, I now have to trudge this lonely path of patronizing, condescending and almost pitiful responses to my queries as I had to on this very sick morning.

So, QSAs are lumping MFAs cloud solutions as critical security functions. To be fair to these QSAs, PCI did identify the following to be in scope:

“At least annually and prior to the annual assessment, the assessed entity should confirm the accuracy of its PCI DSS scope by identifying all locations and flows of cardholder data, and identify all systems that are connected to or, if compromised, could impact the CDE (for example, authentication servers) to ensure they are included in PCI DSS scope.”

We always assumed we were talking about authentication as in AD, or LDAP and never thought of lumping multi factor ‘authentication’ into authentication servers. But think about it. If you have an onpremise MFA solution in your data center, would that be under scope for PCI-DSS, if its used for access to get into CDE? How different would it be from AD or LDAP, which manages one factor of authentication (something you know). Wouldn’t the other factor also need to be looked into? (Something you have or something you are).

In the same argument, thus QSAs conclude that if there is an authentication in the cloud, regardless of which factor, that authentication service is in scope of PCI-DSS. Same goes for logging and monitoring service providers.

So what’s there left for customers using MFAs cloud providers to do?

Well, there are two options.

  • 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 (tough… preferred solution is to work with providers able to demonstrate their PCI DSS compliance with their own assessment)

I am afraid it is what it is.

After getting sermonized by the (I believe, well intentioned, though somewhat with such poor communication skills) cloud MFA reseller, I thought writing all this down will save me the agony of going through over the phone to explain this particular situation. In that conversation, I just asked him, “Is your solution PCI Compliant or not?” and never really got him to answer properly because he kept arguing the fact that I am completely missing what PCI-DSS is all about.

Knowing it was impossible to argue on this point, I finally said, “Thank you so much for your time, I will let you know when I need more clarifications.” And away his solution went, lumped within the 20 others in my bin called “Non Compliant MFAs”. The search goes on, and looking forward to more patronizing put-downs from well-intentioned resellers. Hopefully this article goes some was in clarifying without anyone getting jumpy on us.

If you need more information on PCI-DSS or any other compliance standards for that matter, let us know and drop us an email at avantedge@pkfmalaysia.com

PCI-DSS Service Provider SAQ

March 7, 2019 / / 0 Comments

Recently, we have had quite a number of requests from service providers requesting us for clarifications on PCI-DSS. Some comes from way of reference by other clients; while some just cold calls me and starts firing questions away. I don’t mind actually. I’ve done many ad-hoc advisory in my car as I am always driving from one place to another.

Recently I had a discussion with a potential client and I went on to do my normal explanation of SAQ options available for him. He was more animated than normal and from our conversation, I could tell that he has done some reading.

The first thing he insisted was that he was doing less than 6 million of transactions, so therefore he doesn’t quality for level 1 PCI-DSS, to avoid the controls for Level 1.

Firstly, just to be clear, the controls for Level 1, 2, 3 and 4 (for merchants) are EXACTLY the same. It doesn’t mean that you are going through Level 1 you end up doing more than other levels. The levels are guidelines on HOW you get PCI (either you do a self-sign or get a QSA/ISA to signoff for you).

Secondly, these Levels are generally defined by the card brands. You won’t see level definitions in PCI-DSS officially. The reason how we ended up with these 1,2,3 and 4 is the common levels from Visa and Mastercard in their merchant program. Those numbers you often associate with PCI (6 million for level 1 etc) are associated to Visa and Mastercard programs. Go ahead to https://www.americanexpress.com/content/dam/amex/hk/en/staticassets/merchant/pdf/support-and-services/data-rsecurity/DataSecurityOperationPolicyMerchants.pdf 

Amex has different definitions! Surprise! Their merchant definition of level 1 is much lower than the 6 million we see. It’s 2.5 million transactions per year. But I guess the number of people actually using Amex is probably the same number of people who understands the rules of winter curling, we end up just falling back to Visa and Mastercard’s definition .

Thirdly though – because this person was considered a service provider, these merchant numbers are moot. They need to look at service provider numbers which is much lower – Level 1 Service Providers are 300,000 or above transactions yearly for Visa and Mastercard (Amex incidentally just keeps it at 2.5 million consistently for merchants and service providers).

So, if you are a service provider, don’t look at the merchant numbers for Level definitions!

It was hard enough to explain that on the phone. He kept insisting he was a PCI Level 3. I kept resisting the urge to correct him to say Level 3 definitions are mainly for e-Commerce merchants.

After a while and after he had somewhat calmed down, he then went on the trajectory that he wasn’t storing any card data and he was outsourcing the storage and processing over to another payment provider. This is possible. Many providers or aggregators utilise other payment gateways or third party facilitators to assist in the connectivity to the banks. But they use this argument to say PCI doesn’t apply.

Again – PCI applies regardless of whether you store or not. If you process, transmit, or even have security influence over those that handles card data – boom, PCI technically hits you. How it hits you is the question. If there is no storage for instance, you may be able to escape the dreaded Requirement 3 and the Mystery of the Key Management Nonsense. But yes, some controls will still hit you regardless.

After a lull in the conversation, he started his engine again by claiming that OK, he might be a Level 2 as discussed, but he is definitely an SAQ A because he has outsourced everything to another gateway and he only redirects to the payment gateway for card processing.

Again, while appreciating his enthusiasm, I have to say again, SAQ A is applicable to merchants. If you are a service provider, you generally only have one – SAQ D. To which I became the receiving end of some colourful expletives (not aimed at me in particular). However, depending on his scope, some of the SAQ D controls may be marked off as NON APPLICABLE, so at least I have some good news for him – if what he told me was actually in place.

Then he went on a different tangent – so how often will Bank Negara (Malaysia’s Central Bank) ask us for this? I paused for a while unsure if I heard it correctly. When reconfirmed, I mentioned that our Central Bank has no mandate on PCI-DSS (as far as I know). PCI is a contractual obligation. To which I was then queried: So who do I pass this PCI document to? (in more colourful language). And I simply say: Pass it upwards! If your bank requires it, send to them. If your customer requires it, send it to them. If God Almighty requires it, send it to Him.

And then he asked the common question: Wait, if it’s a self signed, who will believe me?

Well, here’s the thing. Probably no-one. But apparently, that’s how PCI works. If you are doing an SAQ and its allowed by your bank or customer, it is perfectly fine for you to do a sign off in Section 3b of the SAQ and AoC. It is after all a Self Signed Self Assessment Questionnaire. Based on his stunned silence, I imagined he thought I was kidding. So he repeated: “So if I hung up now, and just sign off everything, does that mean I am compliant to PCI?”

“Well, yes, it would mean you have attested that you are compliant.”

“What if I didn’t do what the PCI needed me to do?”

“Then you are non-compliant.”

“Wait but I already signed off on it!”

“Well, that’s you attesting and saying you are compliant.”

The self assessment concept is very difficult to understand to some. It’s like trying to explain time dilation formula or something. And this is also the reason why I think, in 2012, the council decided that in the SAQ there would be an option to have an ISA/QSA to validate the SAQ (Section 3c). This means, your SAQ is no longer “Self Assessment” but rather “Self Assessed with an Auditor verifying it”. It’s not mandatory for level 2 Service Providers, but usually clients or banks will want to see some other guy other than the executive signing off on the SAQ.

I had to end the call then as I had reached my destination, so I offered to go over to his office to see if he needed any help on his Self Assessment. I haven’t heard back from him since, so I guess he is still evaluating his options or something.

But the above conversation is more common than you think: Mixing up the levels, the SAQs between merchant and service providers and grasping the concept of the SAQ. If you need any clarifications, drop us a note at pcidss@pkfmalaysia.com and we will call you back. We are always looking forward to colourful conversations!

© 2024 PKF AvantEdge

— Up ↑