With the release of PCI DSS 3.2, the PCI Security Standards Council has updated the requirements for using multi-factor authentication. The updates clarify the existing requirements and introduce new obligations to entities with regard to remote and administrative access to the cardholder data environment (CDE).
Since the release of the current version of the DSS standard, the Council has offered no shortage of additional material addressing the updates and, as such, has provided assessors and entities alike many hot topics for conversation.
Evolution of Multi-Factor Authentication
Since the original version of the PCI DSS, the payment card requirements have required two-factor authentication for remote access to the CDE. While mechanisms for achieving two-factor come and go, the factors (something you have, something you know, and something you are) have remained unchanged.
Under PCI DSS 3.2, the Council has redefined two-factor authentication as multi-factor authentication and added a requirement to utilize multi-factor authentication for all non-console access into the CDE for personnel with administrative access.
The Council has stressed that the redefinition from two-factor to multi-factor does not change the intended interpretation of the requirements. Rather, it’s likely an effort to address the common misinterpretation of using single factor twice for authentication, such as a Windows password followed by a VPN password. The Council calls this multi-step authentication and stresses that it is not equivalent to multi-factor.
Clarifying the CDE and Multi-Factor Requirements
As for the added requirement, Council Senior Director Emma Sutcliffe addressed this during a presentation at the 2016 PCI Community Meetings. Very simply, where a user is gaining administrative access to a system in the cardholder data environment, regardless of whether or not they are in the CDE themselves, they must use multi-factor authentication.
In November 2016, the Council provided an eye-opening clarification in their monthly newsletter to assessors. In the newsletter, the Council explained that, to be considered acceptable, a multi-factor solution must not provide any indication of success or failure of any individual factors before granting access.
In other words, if the solution prompts the user to provide the second factor only after receiving a valid first factor, then it is what the Council considers to be multi-step authentication on par with using two successive passwords. This is not acceptable to meet the PCI requirement for multi-factor authentication.
Using SMS for Authentication
An example of this approach is the most common implementation of SMS-based two-factor authentication (recently deprecated by the National Institute of Standards and Technology), which texts a token to the user’s cellular telephone upon receiving a valid password. Applying the Council’s clarification, in order to align this authentication process with the Council’s expectations, the token should be sent regardless of the password’s validity, and any subsequent authentication denial should not indicate which of the factors, password or token, were invalid.
Independence of Authentication Mechanisms
In early 2017, the Council published a much-anticipated information supplement on the topic as well, providing additional clarification around the concept of “independence” of factors and mechanisms used. This means that the various factors employed in an acceptable multi-factor authentication solution must not be dependent on one another such that the compromise of one factor inherently gives access to another.
A common example would be a token generator app that runs on a user’s desktop and provides the second factor for their VPN connection. If a threat actor obtains that user’s desktop password which also happens to be used for VPN authentication, then the threat actor has inherently gained access to both factors while having knowledge of only one of them.
Similarly, tokens sent via e-mail would likely not make the grade. In most cases, a compromised workstation password inherently provides access to the user’s inbox, where they receive their token, thus not meeting the requirement for independence of mediums used.
Conclusion
Now, taking both of these multi-factor concepts into consideration, it seems reasonable to conclude that proper independence of factors and mediums allays any concern over multi-step authentication. If the multiple factors used for authentication are truly independent, then, for example, discovering the validity of a user’s VPN password doesn’t bring an attacker much closer to compromise if he doesn’t also have access to the smartphone on which the user’s token generator app resides. After all, isn’t the devaluation of exposed passwords the reason for multi-factor authentication in the first place?
Under the Council’s previously published guidance (FAQ #1426), this example would be an acceptable solution as it employs two of the three possible factors and all mechanisms are independent of one another. Unfortunately, as more and more entities are adopting multi-factor authentication in response to the rise of phishing attacks (a welcome and long-overdue trend), it appears the goal posts are being moved by the Council, which could invalidate some of the solutions previously selected by entities.
As with all other PCI requirements, assessors and entities should consider multi-factor solutions individually to determine whether or not they sufficiently meet these requirements. LBMC strongly recommends that entities review and evaluate their existing multi-factor solutions well in advance of an annual PCI attestation, to avoid any unexpected compliance related-issues.
For a private briefing on this and other PCI security standards topics, or if you have any questions about PCI compliance, please contact Brian Willis at bwillis@lbmc.com.
Download our guide, PCI Compliance Guidelines Explained, for more ways to stay up to date with PCI compliance for your firm.
