PCI DSS 3.2 – Complying with 2FA requirements without tryingElli Lytra
Welcome to the new age of PCI 3.2. Its not radically different and you do have time till Jan 30 of 2018 to comply with the new guidelines. Then why is this article being written? What is the rush here?
Once you scratch under the surface of PCI DSS 3.2 you’ll quickly realize that there is something not quite so simple lurking underneath. Read through the draft and you’ll find language that identifies the need to have 2 Factor Authentication (2FA), also called multi factor authentication (MFA), enabled for all sensitive data access such as payment card information. Not a big deal right?
Where is the data stored?
Where your payment information is stored matters. Here’s why: in order to protect your payment card information you need to ensure how that data is accessed. Handling data on premise or in your private cloud is easier in terms of compliance than on a 3rd party server. This is common sense and practitioners in the security and compliance space have known and implemented this over the years. Now however, with the proliferation of cloud services and servers, storage is migrating slowly but surely, to the cloud. How can you ensure that the hyper-visor where your virtual instance is running is not compromised? Of course, there are ways to do this, but its a challenge and someone has to take charge of issues like these.
Who has access to the data?
Before you can claim to protect your data you need to understand who has access to your data. Some enterprises have upwards of 500 groups in Microsoft Active Directory. It is no trivial task to allocate pack leaders for internal and external apps and servers. This is compounded by the fact that the people who access a resource might not be in the pay-grade to take ownership of the service or server cluster.
Specifically for PCI DSS 3.2, for admin level access companies should implement 2FA on all sensitive applications and servers. This ensures that only the right person at the right time, from the right location can access any sensitive data. Whether you are allowing access to data on a server, through a web interface or something else you need to layer 2 Factor Authentication in front of your admins who are accessing the data from the various portals.
Pitfalls and challenges
Why is this challenging? Hasn’t 2 Factor Authentication been around forever? Yes, there’s nothing new about 2 Factor Authentication but lets try to find one instance of a 2FA rollout in an enterprise where the employees and end users have not complained about the cumbersome nature of the various solutions. Nobody is arguing whether 2FA is useful or not, the point is to do an enterprise rollout you absolutely need to consider the user experience. With the mandate for PCI DSS 3.2 this is even more critical. You could have got away with only layering 2FA in from of IT assets used by IT personnel. Now, you’ll have to layer 2FA in front of admin accounts on SaaS services and servers being accessed by all groups who are getting to the sensitive data. Its an uphill task to convince people that usage of the 6 digit numbers received via an app on the phone or SMS is a good way to adhere to this compliance requirement.
Another issue is SaaS services. What are you going to do when more than 70% of the applications used by your employees do not support 2FA right off the bat. How are you going to implement 2FA on applications that have no native support for 2FA?
Strategies to reduce the pain
The good news is that not all is lost! The mobs holding pitchforks will not materialize if you follow some simple guidelines:
(1) Layer low friction 2FA techniques like Geofencing, Geoproximity, Fingerprint sensing instead of 6/8 digit based logins. The lower the friction of verifying your identity the better adoption you will see.
(2) Install command introspection mechanisms to prevent misuse of server level employee accounts. This ensures that even when accounts are compromised an account cannot be misused.
(3) Have in place automated audit mechanisms to see who has accessed data. Implement 2FA for authorization, not just authentication – follow a layered approach to security not an M&M one.
(4) Discover from your AD or LDAP who are the group leaders and what applications people are accessing. You can choose to also parse through any SIEM logs or analyze access patterns directly from the servers.
(5) Implement a way for layering 2FA on apps that do not support 2FA. You can look at some commercial products that can help or build in hooks to your forward web proxy or CASB solution using their APIs. Tying these APIs with Twilio type of services will make implementation easier.
In this article we have discussed PCI DSS 3.2 and some of the challenges with aligning easily with the compliance requirements. We have discussed why things can become challenging and some strategies to soften the compliance process and make it less thorny.