Multi-factor Authentication to Comply with PCI DSS 3.2

On February 1, 2018, Requirement 8.3 of the Payment Card Industry Data Security Standard (PCI DSS 3.2) goes into effect, making multi-factor authentication mandatory for non-console access to computers and systems handling cardholder data, and remote access to the cardholder data environment (CDE). Earlier this year, the PCI Security Standards Council also issued guidance for multi-factor authentication implementations.

PCI DSS 3.2

The PCI DSS applies to all entities involved in payment card processing, including merchants, processors, acquirers, issuers and service providers. It also applies to all other entities that store, process or transmit cardholder data or sensitive authentication data.

Since the release of the PCI DSS, two major releases have been made, version 2.0 in November 2010 and 3.0 in October 2013. The most recent sub-release, version 3.2, was published in April 2016 and introduces a few new requirements that are considered best practices until January 31, 2018, after which they become mandatory requirements. These changes ensure that the standards are up to date with emerging threats and changes in the market. The most significant change is the revised Requirement 8.3 regarding multi-factor authentication.

Some of these changes come in response to major hacking incidents in the U.S., including the Target and Home Depot data breaches where hackers obtained names, credit card numbers and other information about millions of people. The 2013 Target breach alone compromised 40 million customers’ payment card information and partially exposed another 70 million. After a long investigation, Target will pay $18.5 million in a security breach settlement. The retailer has spent $202 million on legal fees and other costs since the breach.

Requirement 8.3 and Multi-Factor Authentication

The first change to Requirement 8.3 is the introduction of the term “multi-factor authentication” rather than the previous term “two-factor authentication”, as two or more factors may be used. By changing this terminology, two factors of authentication becomes the minimum requirement.

The second and major change is to expand Requirement 8.3 into two sub-requirements, to require multi-factor authentication for all personnel with non-console administrative access, and all personnel with remote access to the CDE.

New Requirement 8.3.1 addresses multi-factor authentication for all personnel with non-console administrative access to the CDE, where “non-console access” refers to logical access that occurs over a network rather than via a direct physical connection, including access from within internal networks as well as access from external or remote networks.

New Requirement 8.3.2 incorporates the former Requirement 8.3, and addresses multi-factor authentication for all personnel with remote access to the CDE. This requirement is intended to apply to all personnel – including general users, administrators and vendors (for support and maintenance) with remote access to the network – where that remote access could lead to access to the CDE.

Guidance for Multi-Factor Authentication

Since the change to Requirement 8.3, the PCI Security Standards Council has received a number of questions about how the different factors should be implemented, both from organizations planning to implement MFA and security assessors evaluating MFA implementations.

To answer these questions, the Council published Information Supplement - Multi-Factor Authentication version 1.0 to describe the industry-accepted principles and best practices for a MFA implementation, including the:

• Definition, independence and protection of authentication factors
• Misuse of multi-factors, including multi-step authentication

In the last section, the Council explores common authentication scenarios and considerations for multi-factor authentication.

Authentication factors

Multi-factor authentication requires the use of at least two of the three authentication factors as described in PCI DSS Requirement 8.2:

• Something you know, such as a password, PIN or the answer to secret questions
• Something you have, such as a token device or smartcard
• Something you are, such as a biometric

The sector is already fully aware of this definition, but they still struggle with how to implement these different authentication factors.

The PCI SSC also mentions other factors: “Other types of information, such as geolocation and time, may be additionally included in the authentication process; however, at least two of the three factors identified above must always be used. For example, geolocation and time data may be used to restrict remote access to an entity’s network in accordance with an individual’s work schedule. While the use of these additional criteria may further reduce the risk of account hijacking or malicious activity, the remote access method must still require authentication via at least two of the following factors: something you know, something you have, and something you are.”

Independence of authentication factors

The MFA should be implemented with authentication mechanisms that are independent of each other, to avoid that access to one factor does grant access to any other factor, and the compromise of one factor does not affect the integrity or confidentiality of any other factor.

Some of the pitfalls described by the PCI SSC:

• First, when a username/password combination is used to enter the company network, and the same credentials also give access to an email account to which a one-time password is sent as second factor, these factors are not independent. The first factor (username/password) gives access to the email account and thus the second factor.
• Second, “a software certificate stored on a laptop (something you have) that is protected by the same set of credentials used to log in to the laptop (something you know) may not provide independence.”
• Third, “Transmission of a one-time password (OTP) to a smartphone has traditionally been considered an effective out-of-band method. However, if the same phone is then used to submit the OTP—for example, via a web browser—the effectiveness of the OTP as a secondary factor is effectively nullified.” When entering credentials via the same device that receives (or stores/generates) a second factor, a hacker who has control of the device might capture both authentication factors.

Protection of authentication factors

To avoid any misuse of the authentication factors, they need to be protected from unauthorized access and use, as defined in PCI DSS Requirement 8. In addition, “where any authentication elements rely on a multi-purpose consumer device – e.g. mobile phones and tablets – controls should also be in place to mitigate the risk of the device being compromised.”

Multi-step vs. multi-factor

PCI DSS requires that all factors in multi-factor authentication are verified together, prior to obtaining access to the system. If a user can obtain the knowledge of the success or failure before all factors have been submitted, the overall authentication process becomes a multi-step, single-factor authentication, even if a different factor is used for each step. This is not compliant with the multi-factor authentication requirement.

Common authentication scenarios

In the last section of this Information Supplement, the PCI SSC describes four multi-factor authentication scenarios that clarify the different conditions for the authentication factors and how best to implement them.

Conclusion

With less than three months before the PCI DSS Requirement 8.3 takes effect, it is time for action. I am convinced the Information Supplement - Multi-Factor Authentication version 1.0 is a good starting point as you prepare to review, implement or upgrade your multi-factor authentication solutions.