An in-depth look at the PCI Security Standard Council’s recent MFA guidance supplement and what it means for your organization.
An in-depth look at the PCI Security Standard Council’s recent MFA guidance supplement and what it means for your organization.
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.
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
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.
To 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.
Factors communicated through separate, protected channels and are known as “out-of-band authentication,” e.g., through a cell phone, FOB, etc. Examples:
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.
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:
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.
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.
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:
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.
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.
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.
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.
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.
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
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.
.svg)
