Key Changes in PCI DSS 4.0 for Organizations to Address
On March 31, 2024, the Payment Card Industry Security Standards Council (PCI SSC) will enact version 4.0 of its Data Security Standard (PCI DSS), requiring organizations to be fully compliant by early 2025. The updated version presents important changes to the world of payments, placing heavier emphasis on risk management, stronger authentication capabilities and security awareness training.
PCI DSS v4.0 also introduces two significant shifts from the previous version. First, v4.0 allows organizations to take a new “Customized Approach” to meeting DSS controls rather than having to implement temporary compensating controls. Second, v4.0 makes compliance a continuous improvement effort instead of a point-in-time annual exercise.
The previous update to the PCI DSS took place in 2018 with v3.1.2. We are nearing the end of a two year transition period between v3.1.2 and v4.0. The transition period began on March 31, 2022 when PCI DSS 4.0 was released and ends on March 31, 2024 when PCI DSS 3.1.2 is retired. Until then, v3.2.1 will remain active.
The v4.0 update consists of 64 controls. 13 of those controls are effective for any PCI DSS 4.0 assessments that are completed during the transition period. The other 51 are “future-dated” and will become requirements on April 1, 2025. Until then, they are considered best practices.
What is PCI DSS?
The Payment Card Industry Security Standards Council (PCI SSC) consists of the five major credit card companies: Mastercard, Visa, American Express, Discover and JBC. PCI DSS is a set of standards and procedures designed by the SSC to secure transactions and protect cardholders from the misuse of their personal and payment information. PCI DSS was developed to prevent breaches of sensitive data for organizations handling payment card information while also facilitating widespread adoption of consistent data security measures.
Purpose of the 4.0 update
According to PCI SSC, PCI DSS 4.0 has four main goals:
- Continue to meet the security needs of the payment industry: PCI DSS 3.1.2 was released in a pre-Covid world, and security practices must evolve as threats do.
- Promote security as a continuous process: Bad actors are constantly at work to breach sensitive information, and ongoing security is crucial to protecting payment data.
- Add flexibility for different methodologies: Greater flexibility allows for more options to achieve a requirement’s objective while supporting payment technology innovation.
- Enhance validation methods and procedures: Having clear validation and reporting options supports both transparency and granularity.
Key changes to requirements
PCI DSS consists of 12 high level requirements, with each requirement mapping to an overarching principle. These can be found in Table 1 below:
Stronger Authentication Mechanisms
PCI DSS 4.0 recognizes the importance of tighter authentication measures within identity and access management practices designed to protect cardholder data. The payments industry has moved to the cloud, necessitating more robust authentication methods. In previous versions, multi-factor authentication (MFA) has been a best practice but will now be mandatory.
- New requirement to implement MFA for all access to cardholder data environments (8.4.2).
- Added the option to determine access to resources automatically by dynamically analyzing the security posture of accounts rather than changing passwords/passphrases at least once every 90 days (8.3.9).
- New requirement that if passwords/passphrases are used as authentication factors, they 1) Have a minimum length of 12 characters, and if the system does not support 12 characters, a minimum length of eight characters, and 2) Contain both numeric and alphabetic characters (8.3.6).
- New requirement to securely implement MFA systems, with the following criteria (8.5.1):
– The MFA system is not susceptible to replay attacks.
– MFA systems cannot be bypassed by any users, including administrative users unless specifically documented, and authorized by management on an exception basis, for a limited time period.
– At least two different types of authentication factors are used.
– Success of all authentication factors is required before access is granted. - New requirement to review all user accounts and related access privileges (including third-party/vendor accounts) at least once every six months. User accounts and access must remain appropriate based on job function, inappropriate access must be addressed and Management must acknowledge that access remains appropriate (7.2.4).
Increased Data Encryption Scope
Notably, the new version of PCI DSS expands the scope of the cardholder data environment (CDE). The encryption of cardholder data on trusted networks combats threats posed by malicious code within the network, insiders and network misconfigurations. Requirement 4 covers the encryption of at rest, in transit and in use cardholder data. All entities that store, process, or transmit cardholder data, including merchants, processors, acquirers and other third party service providers must follow PCI DSS. Organizations should identify the scope of their CDE before beginning to assess compliance with PCI DSS.
Additional data encryption updates include the following:
- New requirement to confirm that any certificates used for primary account number (PAN) transmissions over open, public networks are valid, not expired and not revoked (4.2.1).
- New requirement to maintain an inventory of trusted keys and certificates used to protect PAN during transmission (4.2.1.1).
Tightening Security for Systems and Software
The changes to PCI DSS include several new requirements centered on mitigating the risks of malicious software and Shadow IT. Once injected into a network, malicious code can allow bad actors to access cardholder data at weak points along its transmission path. Shadow IT, or the use of systems, devices and software not explicitly approved by IT, can significantly expand an organization’s attack surface.
Updates intended to defend against malicious code and Shadow IT include the following:
- New requirement to define a frequency for periodic malware scans in the organization’s targeted risk analysis (5.3.2.1).
- New requirement for a malware solution for removable electronic media that either (1) performs automatic scans when media is inserted or connected OR (2) performs continuous behavioral analysis of systems or processes when media is inserted or connected (5.3.3).
- New requirement to have processes and automated mechanisms in place to detect and protect personnel from phishing attacks (5.4.1).
- New requirement to develop and maintain an inventory of bespoke and custom software, including any third-party software components, to facilitate vulnerability and patch management (6.3.2).
- New requirement to deploy an automated technical solution for public-facing web applications that continually detects and prevents web-based attacks. Removed the option to review web applications via manual or automated application vulnerability assessment tools or methods (6.4.2).
- New requirement to manage all vulnerabilities, not just just those ranked as high-risk or critical, found during vulnerability scans (11.3.1.1).
Promoting a Security-Minded Culture
Many of the requirement changes are intended to support a culture of security via organizational policies and information security awareness programs. These updates all fall under Requirement 12.
Relevant updates include the following:
- New requirement to review and update organizational security awareness programs at least once every 12 months. Updates should address any new threats or vulnerabilities with potential impacts (12.6.2).
- New requirement for security awareness training to include awareness of threats and vulnerabilities that could impact the security of the CDE (12.6.3.1).
- New requirement for security awareness training to include awareness about the acceptable use of end-user technologies (12.6.3.2).
- New requirement to perform a targeted risk analysis to define the frequency of periodic training for incident response personnel (12.10.4.1).
- New requirement to perform a targeted risk analysis for any requirement that provides flexibility for how frequently it is performed (12.3.1).
- New requirement to document and review cryptographic cipher suites and protocols in use at least once every 12 months (12.3.3).
Compliance flexibility and continuous improvement
The new concept of the “Customized Approach” represents a significant structural change to PCI DSS. One of the main goals of v4.0 was to provide additional flexibility for organizations using different methods to meet security objectives. Previously, organizations could only use a traditional “Defined Approach.” Under the Defined Approach, organizations that have a legitimate, documented business constraint that prevents them from meeting a requirement can implement Compensating Controls. Organizations typically use Compensating Controls when there is a legacy system in place that cannot be updated to satisfy a requirement.
For example, PCI DSS requires the use of strong encryption to protect sensitive cardholder information. An organization operating with a legacy system that cannot fully support the latest recommended encryption standards would need to implement one or more Compensating Controls to address the system’s limitations. Implementing enhanced access controls, isolating the legacy system within a segmented network, and conducting robust continuous monitoring of the system could all serve as Compensating Controls.
Alternatively, the Customized Approach allows organizations to design their own tailored security controls to meet security requirements. For most requirements in PCI DSS 4.0, there is a Customized Approach Objective that organizations can use to understand expectations when the Customized Approach is used. With the Customized Approach, instead of compensating for a missing control, an organization may document a different control that still aligns with the “Customized Approach Objective” of the control that is being customized. This customized control is assessed instead of the original control. A major benefit of this change is that it allows for longer-term, customized solutions rather than shorter-term, compensating controls.
The Customized Approach is intended for use by mature organizations, providing space for companies already using innovative methods to achieve their security objectives. During the development of PCI DSS 4.0, a common theme in stakeholder feedback was the demand for greater flexibility around the use of innovative security technologies to meet objectives. Note that taking the Customized Approach does involve additional review, including a targeted risk assessment to ensure the organization has sufficiently addressed all related risks.
Another new element of PCI DSS 4.0 is the guidance to promote security as a continuous process. This idea is supported by a common update to 11 separate requirements (1–11: X.1.2) stating that roles and responsibilities for performing activities are documented, assigned, and understood. The spirit of this update can be found in the requirements’ objectives, which state that “personnel are accountable for successful, continuous operation” of requirements. PCI DSS 4.0 recommends documenting roles and responsibilities via a responsibility assignment matrix that includes who is responsible, accountable, consulted and informed (commonly known as a RACI matrix).
Implications for organizations
The effective date for v4.0 is right around the corner. Organizations that have not already done so should begin to assess PCI DSS compliance internally to determine where they stand. Documenting processes, network diagrams, data lineage and various systems supports compliance efforts. Organizations that clearly understand of the scope of their cardholder data environments will be in a better position to implement effective security controls. Lastly, organizations should evaluate the full control set and estimate the level of effort for each requirement. The forthcoming requirements for 2024 may in fact be more complex than the requirements scheduled for implementation in 2025. Ultimately, taking a proactive and measured approach to compliance will make the transition to v4.0 smoother.
References:
(1) Payment Card Industry Security Standards Council. “Payment Card Industry Data Security Standard, Version 4.0”
https://docs-prv.pcisecuritystandards.org/PCI%20DSS/Standard/PCI-DSS-v4_0.pdf
(2) Payment Card Industry Security Standards Council. “Summary of Changes from PCI DSS Version 3.2.1 to 4.0”
(3) Anna Fitzgerald. “What’s New in PCI DSS 4.0? The Major Changes You Need to Know”
https://secureframe.com/blog/pci-dss-4.0
(4) Anastasios Arampatzis. “What You Need to Know About PCI DSS 4.0’s New Requirements”
https://www.darkreading.com/cyber-risk/what-s-new-in-pci-dss-4-0-for-authentication-requirements-
For any questions or comments on the content in this article — please contact:
Brian Gastwirth | Senior Consultant
brian.gastwirth@dayblinkconsulting.com
Jacob Armijo, CISM | Manager
jacob.armijo@dayblinkconsulting.com
Michael Morgenstern | Partner
michael.morgenstern@dayblinkconsulting.com
