Understanding the PCI SSC Multi-Factor Authentication Supplement
An in-depth look at the PCI Security Standard Council’s recent MFA guidance supplement and what it means for your organization.
 |
| George Mateaki Security Analyst QSA, CISSP |
Moving toward true security
In the wake of recent massive data breaches, foundational data security principles—like network segmentation, strong passwords, and multi-factor authentication (MFA)—are getting more attention from organizations, consumers and security experts.
The Deloitte data breach of September 2017 was recently tied to a lack of multi-factor authentication on an admin account. Aetna and Airbnb have announced they are shifting away from single-password authentication and towards strong, multi-factor authentication access for users of their apps.MFA is also an important principle for any business’s internal operations, especially when it comes to remote access into a company’s cardholder data environment (CDE). There has been some confusion within the QSA community, the payments industry, and the data security/PCI compliance realm. In order to clear up confusion and offer help, the PCI Security Standard Council released a supplement in February of 2017 with additional guidance and clarification about MFA.
Even with the additional supplement, it can be confusing to keep all of the principles, terms, and definitions related to MFA straight. This post is intended to help our readers understand Multi-Factor Authentication, and the associated PCI SSC guidance, at both practical and conceptual levels.
Purpose of the MFA Supplement
The bottom line? The PCI SSC wants to help secure remote user access. Remote access is still the biggest vector for an attack into sensitive data systems. But, strong MFA can keep criminals and hackers away from your systems.This new supplement does not create any new requirements. Its intent is to provide further guidance and help people understand the underlying principles of security, so they can go the extra mile to truly protect their network. The overall security goal is clean, multi-factor authentication into a critical network/CDE, from anywhere outside of that network.
The supplement also does a great job of getting down to the details of MFA; it defines terms and compares authentication principles. It clears up some previous points of confusion, like what is really meant by “independence of factors,” “multi-step,” and “multi-factor.”
It’s important to note that MFA is not currently a requirement for PCI compliance. But, according to the supplement, “While PCI DSS 8.3 does not currently require organizations to validate their MFA implementation to all the principles described in this guidance document, these principles may be incorporated into a future version or future revision of the standard.” Work with your QSA now to look closely at your current MFA system, even though it may not be a requirement yet.
SEE ALSO: New Multi-Factor Authentication Clarification & Supplement: Principles You Should Know
MFA Basics
PCI DSS 3.2 requirement 8.3 says, “Multi-factor authentication requires an individual to present a minimum of two separate forms of authentication before access is granted.” In this case “two” is the minimum—not the maximum—number of factors required. For true MFA, you need at least two factors from at least two of these three categories:• Something only you know (password)
• Something only you have (smart card, token)
• Something only you are (fingerprint, ocular scan, face scan)
While you can add other types of factors to your MFA solution—like geolocation, time, IP address, or MAC address—they don’t count towards the two-factor minimum.
“Factor Independence”
To maintain factor independence:- Access to one of the factors can’t automatically enable access to an additional factor. For instance, if you want to use a laptop login as one factor, and an open SSH key certificate file stored on the same laptop (used to gain access to a remote server), that won’t work. You would need more server-side validated factors—like a google authentication.
- It’s best to physically separate your factors. Good example: a password is in your head, and a token is sent to a device. Bad example: you log in to your laptop, click on a link for remote access, and a password is added automatically from a password vault or single sign-in system. In that case, you wouldn’t maintain factor independence.
The PCI Security Standard Council reiterates that factor independence is not a PCI DSS requirement at this time, but that we should be focused on increasing security, not just compliance. The guidance supplement can help us all move up to a higher level of security.
Out-of-Band Authentication
Factors communicated through separate, protected channels and are known as “out-of-band authentication,” e.g., through a cell phone, FOB, etc. Examples:- A remote user enters username and password, plus a one-time password sent to them on their smart phone.
- A remote user enters username and password, and then must use a unique dynamic number found on an RSA SecurID™ token
Be mindful when using a smart phone or another device to make a remote connection on VPN or SSH. If you use the same device to login and receive a one-time password or google authorization, this negates your factor independence.
Also, be aware of who has possession of such a device. If your text message notifications pop up and display automatically on your phone screen, you could inadvertently show someone your second-factor token. It might just be a quick SMS text message with the token, but if not secured behind a lock or pin, it would invalidate the true principles of MFA.
Cryptographic Tokens
If you’re authenticating from a single device or channel, you can enforce independence of factors by using cryptographic tokens. Here are a few examples:- Store a token on a secure cryptographic environment like a SIM card, chip or USB, that could then be embedded directly into a device (like a laptop or cell phone, or tablet).
- Sometimes a hidden SMS text message called over-the-air programming can be sent directly to a SIM card (if the SIM card has a secure element on it). This is not something the user would be interacting with, but it would be used to run an application that would ask for a pin or fingerprint, then send you a more complex token as a second factor. In that case, you would preserve the factor independence.
There aren’t a lot of these solutions available currently, but we keep a look out for “secure environment” methodologies. And, there will be more coming in the future.
Protect Your Factors
Whatever your factor is, you have to protect it. If it’s “something you know,” you have to use strong password principles. If it’s biometric data or “something you are,” you have to make sure it can’t be replicated. And if it’s “something you have,” make sure you’re not sharing that data with someone else, for instance with coworkers.Understanding Multi-Step vs. Multi-Factor
The principle that has caused the most discussion and confusion for QSAs is “multi-step vs. multi-factor” authentication. We want to make sure our readers understand this principle.The PCI DSS itself has always stated that all factors have to be verified before full access to the network or an asset is granted. It is well-understood that if any of the factors fail, no access is granted. But, the MFA supplement goes on to say that your MFA solution cannot provide any clues as to which, if any, of the factors was a failure. This additional guidance is based on strong security principles, but it is not well-understood by the community. The misunderstanding has resulted in many MFA solutions that use the following pattern:
- Ask for a user name and password
- If those work, enter a second factor (like a code sent through SMS text, google authorization number, or a fingerprint.)
If you type in a wrong password and then you’re not asked for the second factor (usually with an accompanying “sorry, that didn’t work” message), then the PCI Security Standards Council—as well as the National Institute of Standards and Technology (NIST) would consider that to be a multi-step, not multi-factor authentication. This is because all factors weren’t presented at the same time and before access was or wasn’t granted, so the user can surmise which of the two tokens failed.
For true multi-factor authentication, the pattern would need to ask you to submit the username/password and the second token at the same time. Then it could subsequently grant (or not grant) access. That way the user can’t know which of the two factors failed—the password or the token.
Many of you may be using a method similar to the first example. Our advice? Move away from that. Whether you’re a merchant, vendor, QSA—find a way to achieve true multi-factor authentication. It may be difficult to hear, but the truth is that large data compromises happen through insecure remote access every day.
SEE ALSO: 2 Things You Should Know about PCI 3.2 Multi-Factor Authentication Updates
Examples of MFA
The PCI SSC guidance document gives examples of some commonly used MFA solutions. Some are better than others. But, there are many more methods and configurations. You can work with your QSA to find the best solution for your organization.Example 1:
- An individual logs in to workstation/device, and accesses a software token stored on that device, with one set of credentials (password A).
- The individual then connects to the CDE/corporate network by using a different set of credentials (password B) and a “one-time password” generated by the software token as authentication.
- If both factors are valid—something you know (password B) and something you have (software token)—the authentication system will grant access.
If you use this method: make sure the software token is embedded carefully. It can’t be moved to another physical device. Protect that physical device and maintain proof of possession by the user.
Example 2:
- An individual uses a set of credentials (password A) to log in to a workstation, and those credentials also provide access to a software token stored on the device.
- Then the individual launches a browser window that automatically prepopulates password B (either from a cache or a password vault). Password B is then used in conjunction with the one-time password to connect to the CDE/corporate network.
This is an example of a poor MFA solution, because it does not provide independence between the two authentication factors. Password B came from a password vault stored on the device, not from memory. So, password A provides access to two factors.
Example 3:
- An individual uses one set of credentials (password A) to log in to a workstation
- The individual then uses that same password (A) and a one-time password generated by a software token on their mobile device to connect to the CDE/corporate network.
Even though the individual used the same password (A) to authenticate the workstation and the CDE/corporate network, the one-time password from the phone provided a second, physically separate factor. Note that if you use a mobile device to get a second factor; you shouldn’t use that same device to log in to the remote system. That would negate factor independence. In this case, the phone is the device used to receive the second factor, not the device used for login authentication.
Example 4:
- An individual uses multi-factor authentication (e.g., password and biometric) to log in to a smart phone or laptop.
- The individual then provides a single authentication factor (e.g., another password, digital certificate, signed challenge response) to connect to the CDE/corporate network.
This is a good example, although likely uncommon. The individual enters two factors right when getting into the system, and then uses a signature or client certificate stored on the device to request access to the CDE/corporate network.
If you use this method: be sure there are always two factors required to log in to the device, and that there is no way to circumvent authentication of those two factors for login. This solution could be difficult in a “bring your own device” environment; if used in such an environment, the individual user-devices should maintain a robust isolated execution environment that can’t be adversely impacted or bypassed by the user.
SEE ALSO: PCI Requirement 8: Combatting Weak Passwords & Usernames
We’re all in this together
The main thing to remember about the PCI SSC’s MFA guidance document: it’s not changing the PCI DSS. However, we in the data security realm need to learn the attributes of our current solutions and think about security, not just compliance. Are you practicing the bare minimum to achieve PCI compliance? Or have you achieved true MFA? Evaluate your solution using the principles we’ve discussed here.Remember that we’re all in this together. We need to be ready for future changes both to the standard and to the security environment as a whole. The PCI standard helps and guides us in our quest for security. As always, it represents the “floor” of data security, not the ceiling.
More questions about multi-factor authentication? Contact us.
