DSS 4.0 Clarifies, Strengthens MFA Requirements

MFA under v4.0: No more admin bypass. And no more accessing the CDE without it. Start now and make sure you’ve got the time to set up MFA correctly, and securely. Your users will thank you, your QSA will be happy, and your admins will still be able to fix things when they break!

Responding to confusion surrounding multi-factor authentication (MFA) requirements, the Security Standards Council has rewritten the requirements to be more explicit and to ensure MFA implementations are done securely. 

The DSS 4.0 requires hardened MFA processes (8.4.1) be used to secure all admin (8.5.1) and user (8.5.2) access to the CDE and for remote network access that can access or impact the CDE (8.5.3).

Ask any QSA and they can recount, with likely only slight variations, common conversations with merchants and service providers who are unsure about when, where, and how many times MFA is needed to comply with the Data Security Standard (DSS).  This is a wonderful thing since it means our customers want to get things right!  They want to protect cardholder data, apply good practices in securing their environments, and be PCI compliant.  However, when you dive into the requirements and try to figure out how to do that, it is easy to see why setting up MFA correctly can be confusing. 

In the previous DSS version, 3.2.1, there were two basic events needing MFA: non-console admin access and remote network access.  Simple enough, right?  Well, like so many things, the difficulties are in the details.  The biggest questions were, usually like,  

• "What does "non-console" mean?  And what even is a "console" these days?!" 
• "How many times do I need to MFA?"  
• "MFA is just for admins, right?" 

and the perennial favorite for all IAM engineers 

• "So, [INSERT FAVORITE TWO-STEP AUTHENTICATION PROCESS] is the same as MFA, right?" 

For the most part, these questions are still relevant, but the council has modified the MFA requirement to answer them.  Let us walk backwards through the new requirements and see.

While a detailed discussion what is and is not an authenticator is outside the scope of this blog (see the DSS Req. 8.3.1 or, if you're really bored/sleepy/interested go read NIST SP 800-63), let's talk a bit about the "is a password protected private key multi-factor" question.

 

The short answer is no. 

 

Decrypting the private key, like to use it with ssh, enables your use of it, but it does not provide any proof that the key is yours and only yours to use.  In fact, if you decrypt the key and add it to an ssh agent or keyring, anyone with access to your session can use "your" key!  This is like using a PIN with a smart card.  The PIN and card are not separate factors, but together they demonstrate that you, and not someone else, has the card, i.e., possession of that single authenticator. 

8.5.3 - MFA for remote access

As you can see here, MFA is required for remote access which could access the CDE.  It does not matter who is connecting, or even why, if their remote connection could provide a path into the CDE.  So, while we would recommend all remote access use MFA (for M A N Y reasons) if you want to allow some folks to connect without it, make sure you segment their connections away from the CDE.  This segmentation will of course be assessed (Req. 1) and tested (Req. 11). 

8.5.1 and 8.5.2 - MFA to access the CDE 

We grouped these two requirements together to answer two questions.  First, MFA is now required for anyone accessing the CDE including admins, general users, vendors, and anyone with access to or that handles more than one credit card at a time.  This is a future dated requirement, but do not wait to get rolling on this.  Get started now!  Complying with this control will mean technology changes and user training.  For example, workstation or app logins may now need MFA.

The good news, however, is that thanks to use of systems like Microsoft Office 365, Okta, Google Apps, Amazon, etc. users are getting used to at least some basic forms of MFA. 

Question: If I badge into a sensitive area, like a call center, before logging into my workstation with my name and password, am I MFA’ing?! 

QSA Answer: It depends (of course).  Theoretically, If the entire sensitive area is a CDE, and you swiped a badge AND used a PIN to enter the area, that would be a form of MFA (you HAVE the badge and KNOW the PIN).  However, if multiple folks have access to the room, this may not help identify WHO accessed a workstation in the room.  Similarly, swiping the badge for entry and knowing a user's login password does not provide the same assurance of identity that the person entering the room is that same user.  After all, there are two reasons for using MFA: to ensure that assets are protected from unauthorized access even when one authenticator (like a password) is compromised AND to provide greater confidence that an individual's actions are attributable to them and no one else.

And now, we come to the second question answered here.  Yes, remotely accessing the environment (e.g., the corporate network) and then accessing the CDE, may require MFA both times.  Nuisance?  Possibly.  But as described above, the point is to ensure the individual accessing the CDE is the individual authorized to do so and likely not anyone else. 

8.4.1 - Secure the MFA process 

The DSS already includes requirements to configure system security parameters to prevent misuse (Req. 2).  However, v4.0 adds some specific, future-dated, requirements for securing MFA processes.  Like the need for all CDE-accessing users to MFA, these requirements will be enforced later giving folks time to prepare.  This is mostly to support updating processes where bypassing MFA is unavoidable, rather than a break-the-glass event. 

Most of the bullet points for requirement 8.4.1 are typical, best-practices for implementing MFA systems.  The two biggest areas of difficulty will be in not providing details on success or failure, and not allowing administrators to bypass MFA without documented authorization including the limited time period it will be used.  For admins, changes in policy and process like emergent change control events, could satisfy this need.  Changing implemented multi-step MFA systems not to provide evidence on success or failure may be more complicated. 

For example, consider an MFA system that asks for a username, then a password, then a time-based one-time password (TOTP codes, like Google Authenticator and other "virtual" tokens use) as separate steps, and on separate screens/pages.  Aside from annoying users by taking longer, this process allows a potential attacker to verify the username, then the password, then (presumably) a stolen TOTP key.  Such a system may need to be reconfigured or replaced to comply with 8.4.1 to keep it from leaking partial or whole credentials to bad actors. 

Conclusion 

Like most of the changes in v4.0, these to MFA are expected, desirable, and beneficial to protecting cardholder data systems.  There is even baked in time to implement the more difficult ones.  We recommend getting started now.  Meeting these requirements will satisfy DSS v3.2.1 (Req. 8.3.1 and 8.3.2) and, if in place now, will be one less thing you need to worry about to comply with v4.0 (Req. 8.4.1 and 8.5.1-3). 

Online is ready to assist you in developing your PCI program, helping unpack what the v4.0 changes will mean for your organization, and then designing a compliance roadmap to get you there. For additional insight and guidance from Online’s QSA team, explore our digital PCI DSS v4.0 Resource Center, where we have identified and dissected many of the significant changes and new requirements in the latest release of the PCI Standard.