Poor password management – including the continued reliance on default, stolen, weak and non-unique passwords – is a key factor in more than 80% of hack-driven breaches, according to Verizon’s 2017 Data Breach Investigation Report.
The New PCI DSS 3.2 Standards – New Authentication Requirements for Cardholder Data
In response to growing waives of fraud and data leakage, the PCI Security Standards Council, the global payment card authority, is updating industry-wide standards to improve authentication, third party accountability and software design. Payment Card Industry Data Security Standard (PCI DSS 3.2) went into effect February 1, 2018 – writes Dirk Denayer, Business Solutions Manager at VASCO Data Security.
One of the standard’s key changes is to authentication. PCI DSS 3.2’s Requirement 8.3 makes multi-factor authentication (MFA) mandatory for all involved in payment card processing: merchants, processors, acquirers, issuers, service providers, and any entities storing, processing or transmitting cardholder data and/or sensitive authentication data.
The revised standard is a response to breaches of major retailers – including Target and Home Depot in the US, which compromised the payment card information of 130+ million consumers. This fall’s Equifax “mega-breach” further underscored the urgent need for more and better protections, both for consumers and for all in the transaction chain.
Updated Multi-Factor Authentication and Cardholder Data Environment Policies
The newer “multi-factor authentication” term replaces the previously-used “two-factor authentication” requirement. This may seem a minor change, but it increases and clarifies the standard’s minimum requirements for authentication.
Another important change is the scope of access points covered by the standard’s authentication requirements, which now expands to include all who have “non-console administrative access,” to the Cardholder Data Environment (CDE). This means that multi-factor authentication is now required for everyone accessing data over a network rather than via a direct physical connection, including internal and external networks. It applies to general users, administrators and third parties such as vendors (for support and maintenance) with remote access to the network – wherever that access might ultimately result in access to the CDE. Think of this as the Target HVAC clause.
PCI’s Implementation Guidance for Multi-Factor Authentication
To explain where and how MFA must be implemented, the Council’s “Information Supplement – Multi-Factor Authentication version 1.0” provides MFA implementation principles, reviews laws and regulations, and common authentication scenarios.
Implementing MFA requires the use of at least two of the three authentication factors: something you know (such as a password, PIN or answers to secret questions), something you have (such as a token device or smartcard), and something you are (such as biometrics).
The information supplement also clarifies the use of other authentication factors, stating for example: “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.”
This makes clear that although supplemental factors such as geolocation and time data may be used to further reduce risk, MFA requirements still firmly apply.
The PCI DSS 3.2 standard and information supplement make it clear that authentication mechanisms must be independent of one other: any potential compromise of one factor must not affect the integrity or confidentiality of any other factor, and access to one factor must not grant access to any other factor. Examples of situations to be avoided:
- Re-Use of Credentials: When a username/password combination is used to enter the company network, and the same credentials also grant 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 to the second factor.
- Common Access to Certificates: A software certificate stored on a laptop (i.e. something you have) that is protected by the same set of credentials used to log in to the laptop (i.e. something you know) may not provide independence.
- Single (Mobile) Device Vulnerability: The Counsel notes that “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.”
“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,” the Council advises.
This means that all authentication factors must be verified together, before system access is granted. This prevents a bad actor from corrupting security using a stolen phone.
Before PCI DSS Requirement 8.3 takes effect, all involved in the handling of cardholder data need to review, implement and upgrade their MFA strategies and implementation to assure compliance.
The post The new PCI DSS 3.2 standards – New authentication requirements for cardholder data appeared first on Payments Cards & Mobile.
