Attackers continue to compromise valid credentials to access company networks and steal data. To help organizations combat this growing threat, the PCI Security Standards Council (PCI SSC) has issued guidance on the proper use of multi-factor authentication (MFA) for preventing unauthorized access to computers and systems that process payment transactions. In this blog post we talk with Senior Data Security Standards Director Emma Sutcliffe on how organizations can benefit from this new resource.
Why is the PCI SSC issuing guidance on multi-factor authentication?
From its earliest versions, the PCI Data Security Standard (PCI DSS) has required multi-factor authentication (MFA) to be implemented for remote access to the cardholder data environment (CDE). In PCI DSS v3.2, a new sub-requirement was added to Requirement 8.3, for MFA to also be applied to all non-console access into the CDE for personnel with administrative access.
Since updating the standard with this change, we’ve received a number of questions, both from organizations planning to implement MFA and security assessors evaluating MFA implementations, about how the different factors should be implemented. The MFA Information Supplement provides guidance on a number of industry-recognized best practices that should be included as part of a secure MFA implementation. Use of this guidance is not required to meet current PCI DSS requirements, but is intended to help organizations understand the security principles for implementing and adapting MFA solutions effectively in order to better address security risks.
What is MFA?
The intent of MFA is to provide a higher degree of assurance of the identity of the individual attempting to access a resource — such as a physical location, computing device, network, or database — by creating a multi-layered mechanism that an unauthorized user would have to defeat in order to gain access.
In addition to unique user identification per PCI DSS Requirement 8.1.1, MFA requires at least two of the three authentication methods described in PCI DSS Requirement 8.2:
- Something you know, such as a password or passphrase;
- Something you have, such as a token device or smart card;
- Something you are, such as a biometric.
You’ve said that MFA is only as good as its implementation. What’s one of the most common mistakes you see when it comes to proper implementation?
Some implementations of MFA may not meet the principles spelled out in this guidance document and are therefore not providing the security benefit intended by multi-factor authentication, which is to prevent someone pretending to be a valid user from using a valid username and password to gain access to sensitive network resources and/or cardholder data. One of those principles is that MFA should be implemented so that authentication mechanisms are independent of each other. This means that access to one factor does not grant access to any other factor, and the compromise of one factor does not affect the integrity or confidentiality of any other factor.
For example, if an individual uses one set of credentials (username/password) to authenticate to the company network, and then uses the same credentials for access to an email account to which a second factor (such as a one-time password) is sent, these factors are not independent per a number of industry standards (for example, NIST SP 800-63B). This is because access to just one factor — the username/password in this case — gives access to the email account and thus the second factor, allowing an entity to gain access to the cardholder data environment just by knowing the username/password. Similarly, use of a software certificate that is stored on a laptop and protected by the same set of credentials used to log in to the laptop may not meet independence requirements.
What makes a good MFA implementation?
Principles of a good MFA implementation include independence of authentication mechanisms, protection of authentication factors, and ensuring that no knowledge of the success or failure of a factor is provided to the individual until all factors have been submitted.
How should organizations use this guidance?
Organizations are strongly encouraged to evaluate all new and current MFA implementations for conformance to these principles in order to implement solutions effectively and better address security risks. While PCI DSS does not currently require MFA implementations to meet all the principles described in this guidance document, it may in the future, and these industry-recognized best practices provide a roadmap for future security considerations. Additionally, many organizations may be subject to regional laws or regulations that define requirements for MFA that are more stringent than PCI DSS, and that may require some of the principles in this guidance to be implemented.
