Danna Bethlehem | Director, Product Marketing
On March 31, 2022, the PCI Security Standards Council (PCI SSC) published version 4.0 of the PCI Data Security Standard (PCI DSS). PCI DSS v4.0 replaces version 3.2.1 to address emerging threats and technologies and enable innovative methods to combat new threats. The updated standard and Summary of Changes document are available now on the PCI SSC website.
Implementation timeline
To provide organizations time to understand the changes in version 4.0 and implement any updates needed, the current version of PCI DSS, v3.2.1, will remain active for two years until it is retired on 31 March 2024. Once assessors have completed training in PCI DSS v4.0, organizations may assess to either PCI DSS v4.0 or PCI DSS v3.2.1.
In addition to the transition period, organizations have until 31 March 2025 to phase in new requirements that are initially identified as best practices in v4.0. Prior to this date, organizations are not required to validate to these new requirements. However, organizations that have implemented controls to meet the new requirements and are ready to have the controls assessed prior to their effective date are encouraged to do so. After 31 March 2025, these new requirements are effective and must be fully considered as part of a PCI DSS assessment.
Figure 1: PCI DSS 4.0 Implementation Timeline. Source: PCI SSC
“Don’t wait until 2024 to implement the updated standard. Begin assessing the changes and getting your implementation together now,” notes Lee Neely, a senior IT and security professional at Lawrence Livermore National Laboratory (LLNL).
What has changed?
Updates to the standard focus on meeting the evolving security needs of the payments industry, promoting security as a continuous process, increasing flexibility for organizations using different methods to achieve security objectives, and enhancing validation methods and procedures. Details about the updates can be found in the PCI DSS v4.0 Summary of Changes document on the PCI SSC website.
Examples of the changes in PCI DSS v4.0 include:
- Expansion of Requirement 8 to implement multi-factor authentication (MFA) for all access into the cardholder data environment.
- Updated firewall terminology to network security controls to support a broader range of technologies used to meet the security objectives traditionally met by firewalls.
- Increased flexibility for organizations to demonstrate how they are using different methods to achieve security objectives.
- Addition of targeted risk analyses to allow entities the flexibility to define how frequently they perform certain activities, as best suited for their business needs and risk exposure.
What is the requirement for MFA?
The updated PCI DSS version 4.0 includes three requirements that mandate strong authentication for users and administrators using multi-factor authentication (MFA). According to the standard, the “Two fundamental principles of identifying and authenticating users are to 1) establish the identity of an individual or process on a computer system, and 2) prove or verify the user associated with the identity is who the user claims to be.” When each user can be uniquely identified, it ensures there is accountability for actions performed by that identity, and when such accountability is in place, actions taken can be traced to known and authorized users.
The requirements are:
- 8.3 Strong authentication for users and administrators is established and managed.
- 8.4 Multi-factor authentication (MFA) is implemented to secure access into the CDE.
- 8.5 Multi-factor authentication (MFA) systems are configured to prevent misuse.
These requirements apply to all accounts on all system components, including but not limited to:
- Point-of-sale accounts
- Accounts with administrative capabilities
- System and application accounts
- All accounts used to view or access cardholder data or to access systems with cardholder data.
This includes accounts used by employees, contractors, consultants, internal and external vendors, and other third parties (for example, for providing support or maintenance services).
A common approach for a malicious individual to compromise a system is to exploit weak or nonexistent authentication factors (for example, passwords/passphrases). Requiring more than one type of authentication factor reduces the probability that an attacker can gain access to a system by masquerading as a legitimate user, because the attacker would need to compromise multiple authentication factors. However, as the standard notes, poorly configured MFA systems can be bypassed by attackers, and therefore the selected MFA solution should not be “susceptible to replay attacks.”
What kind of MFA is sufficient?
“More MFA is always better. But at this point, your question shouldn't be if you need MFA. The question should shift to what kind of MFA is sufficient for a particular application,” says Dr. Johannes Ullrich, Dean of Research for SANS Technology Institute.
The truth is that not all MFA solutions offer the same degree of security. For example, SMS-based multi-factor authentication is considered to be less secure, with NIST and ENISA suggesting that organizations should reconsider its use. ENISA’s “Boosting your Organization’s Cyber Resilience” publication suggests that organizations should avoid using SMS as authentication methods. In addition, NIST’s SP 800-63 publication specifies that SMS-based authentication is “a restricted” one, meaning that it is less reliable in today’s threat environment. The key reason behind this suggestion are SIM swapping attacks.
The recent breach of Okta by Lapsus$ criminal group highlighted a weakness of Push OTP authentication, “MFA prompt bombing.” Many organizations have implemented push notifications on mobile devices. Lapsus$ issued multiple Push requests to the end user’s legitimate device until the user accepted the authentication, allowing the group to eventually gain access to the account.
This is why government security policies are calling for the adoption of stronger forms of authentication, including phishing resistant MFA. The Office of Management and Budget (OMB) in the US, and ENISA in the EU have both released guidelines requiring organizations to deploy “phishing resistant” MFA methods, such as FIDO2 keys for sensitive users and use cases.
Organizations wishing to be compliant with both PCI DSS 4.0 and government regulations around MFA should look for solutions like Thales’s SafeNet Trusted Access, that offer a broad range of authentication methods and form factors, allowing them to address multiple use cases and assurance levels. This access management and authentication service combines the flexibility of Single Sign-On with MFA and adaptive authentication to help ensure a safe and convenient log-on experience for all employees. SafeNet Trusted Access supports a broad range of standards-based multi-factor methods, including, FIDO2, and certificate-based authentication.
Learn how SafeNet Trusted Access can strengthen your MFA implementation.