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