PCI DSS v4.0: What You Need to Know and What the End of v3.2.1 Means for the Future of Digital Payments

On March 31st, 2024, The Payments Card Industry Standards Security Council (PCI SSC) officially retired version 3.2.1 of the PCI Data Security Standard (PCI DSS) with the publication of its new sets of protocols and security standards forv4.0.

With the continued rise in cyber threats against financial services and institutions, PCI DSS v4.0 supersedes version 3.2.1 totackle evolving threats and technologies, facilitating enhanced approaches to counteract emerging types of cyber attacks.

> “The industry has had unprecedented visibility into, and impact on the development of PCI DSS v4.0. Our stakeholders provided substantial, insightful, and diverse input that helped the Council effectively advance the development of this version of the PCI Data Security Standard.”
>
> Lance Johnson
Executive Director, PCI SSC.

Revisions to the standard were influenced by feedback from the worldwide payments industry. Over a three year period, over 200 organizations contributed more than 6,000 pieces of feedback to ensure the standard remains aligned with the intricate and evolving landscape of payment security.

What Changes Are Coming with PCI DSS v4.0?

Version 4.0 increases the total number of PCI DSS requirements that organizations must comply with from 370 to more than 500! In 2023, API requests constituted over 71% of internet traffic, highlighting their significant role in luring potential attackers.

Findings reveal that nearly half (46%) of all Account Takeover (ATO) attacks target API endpoints. Moreover, the financial services sector faces the highest concentration of API-driven DDoS attacks, accounting for 28% of such incidents, making it the primary target for such assaults.

The list of new requirements and expected upgrades from PCI DSS v3.2.1 to v4.0 covers 12 sections. Below, we’ve highlighted the sections from the official** **PCI DSS v.4.0.1 document that talks explicitly about protecting systems from malicious attacks and API-based security threats:

Section 6:

Develop and Maintain Secure Systems & Software(s)

**Sub-**section	**Requirements &**Testing Procedures	Purpose
6.3 Security vulnerabilities are identified and addressed. 6.3.1	Defined Approach Requirements	Customized Approach Objective
Security vulnerabilities are identified and managed as follows:

• New security vulnerabilities are identified using industry-recognized sources for security vulnerability information, including alerts from international and national computer emergency response teams (CERTs).

• Vulnerabilities are assigned a risk ranking based on industry best practices and consideration of potential impact.

• Risk rankings identify, at a minimum, all vulnerabilities considered to be high-risk or critical to the environment.

• Vulnerabilities for bespoke and custom, and third-party software (for example operating systems and databases) are covered.| New system and software vulnerabilities that may impact the security of cardholder data and/or sensitive authentication data are monitored, cataloged, and risk assessed.

| 6.3.1.a
Examine policies and procedures for identifying and managing security vulnerabilities to verify that processes are defined in accordance with all elements specified in this requirement.

6.3.1.b
Interview responsible personnel, examine documentation, and observe processes to verify that security vulnerabilities are identified and managed in accordance with all elements specified in this requirement.| Classifying the risks (for example, as critical, high, medium, or low) allows organizations to identify, prioritize, and address the highest risk items more quickly and reduce the likelihood that vulnerabilities posing the greatest risk will be exploited.

Applicability Notes (for 6.3.1)
This requirement is not achieved by, and is in addition to, performing vulnerability scans according to Requirements 11.3.1 and 11.3.2. This requirement is for a process to actively monitor industry sources for vulnerability information and for the entity to determine the risk ranking to be associated with each vulnerability.

6.3.2| An inventory of bespoke and custom software, and third-party software components incorporated into bespoke and custom software is maintained to facilitate vulnerability and patch management.| Known vulnerabilities in third-party software components cannot be exploited in bespoke and custom software.| 6.3.2.a
Examine documentation and interview personnel to verify that an inventory of bespoke and custom software and third-party software components incorporated into bespoke and custom software is maintained, and that the inventory is used to identify and address vulnerabilities.

6.3.2.b
Examine software documentation, including for bespoke and custom software that integrates third-party software components, and compare it to the inventory to verify that the inventory includes the bespoke and custom software and third-party software components.| Identifying and listing all the entity’s bespoke and custom software, and any third-party software that is incorporated into the entity’s bespoke and custom software enables the entity to manage vulnerabilities and patches.

Vulnerabilities in third-party components (including libraries, APIs, etc.) embedded in an entity’s software also renders those applications vulnerable to attacks.

Knowing which third-party components are used in the entity’s software and monitoring the availability of security patches to address known vulnerabilities is critical to ensuring the security of the software.

Applicability Notes (for 6.3.2)
This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.

6.3.3| All system components are protected from known vulnerabilities by installing applicable security patches/updates as follows:

• Patches/updates for critical vulnerabilities (identified according to the risk ranking process at Requirement 6.3.1) are installed within one month of release.

• All other applicable security patches/updates are installed within an appropriate time frame as determined by the entity’s assessment of the criticality of the risk to the environment as identified according to the risk ranking process at Requirement 6.3.1.| System components cannot be compromised via the exploitation of a known vulnerability.| 6.3.3.a
Examine policies and procedures to verify processes are defined for addressing vulnerabilities by installing applicable security patches/updates in accordance with all elements specified in this requirement.

6.3.3.b
Examine system components and related software and compare the list of installed security patches/updates to the most recent security patch/update information to verify vulnerabilities are addressed in accordance with all elements specified in this requirement.| New exploits are constantly being discovered, and these can permit attacks against systems that have previously been considered secure.

If the most recent security patches/updates are not implemented on critical systems as soon as possible, a malicious actor can use these exploits to attack or disable a system or gain access to sensitive data.

Applicability Notes (for 6.3.3)
<NA>

6.4 **Public-facing web applications are protected against attacks. ** 6.4.1| For public-facing web applications, new threats and vulnerabilities are addressed on an ongoing basis and these applications are protected against known attacks as follows:

• Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods as follows:
At least once every 12 months and after significant changes.By an entity that specializes in application security.Including, at a minimum, all common software attacks in Requirement 6.2.4.All vulnerabilities are ranked in accordance with requirement 6.3.1.All vulnerabilities are corrected.The application is re-evaluated after the corrections.

OR

• Installing an automated technical solution(s) that continually detects and prevents web-based attacks as follows:
Installed in front of public-facing web applications to detect and prevent web- based attacks.Actively running and up to date as applicable.Generating audit logs.Configured to either block web-based attacks or generate an alert that is immediately investigated.| Public-facing web applications are protected against malicious attacks.| For public-facing web applications, ensure that either one of the required methods is in place as follows:
• If manual or automated vulnerability security assessment tools or methods are in use, examine documented processes, interview personnel, and examine records of application security assessments to verify that public- facing web applications are reviewed in accordance with all elements of this requirement specific to the tool/method.

OR

• If an automated technical solution(s) is installed that continually detects and prevents web- based attacks, examine the system configuration settings and audit logs, and interview responsible personnel to verify that the automated technical solution(s) is installed in accordance with all elements of this requirement specific to the solution(s).| Public-facing web applications are those that are available to the public (not only for internal use).

These applications are primary targets for attackers, and poorly coded web applications provide an easy path for attackers to gain access to sensitive data and systems.

Applicability Notes (For 6.4.1)
This assessment is not the same as the vulnerability scans performed for Requirement 11.3.1 and 11.3.2.This requirement will be superseded by Requirement 6.4.2 after 31 March 2025 when Requirement 6.4.2 becomes effective.

6.4.2| For public-facing web applications, an automated technical solution is deployed that continually detects and prevents web-based attacks, with at least the following:

• Is installed in front of public-facing web applications and is configured to detect and prevent web-based attacks.

• Actively running and up to date as applicable.
• Generating audit logs.

• Configured to either block web-based attacks or generate an alert that is immediately investigated.| Public-facing web applications are protected in real time against malicious attacks.| For public-facing web applications, examine the system configuration settings and audit logs, and interview responsible personnel to verify that an automated technical solution that detects and prevents web-based attacks is in place in accordance with all elements specified in this requirement.| Public-facing web applications are primary targets for attackers, and poorly coded web applications provide an easy path for attackers to gain access to sensitive data and systems.

Applicability Notes (for 6.4.2)
This new requirement will replace Requirement 6.4.1 once its effective date is reached.This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.

*Note: All the information given above is a direct representation of the information/content/data provided in the most updated PCI SSC document PCI DSS v4.0.1

To better understand the complete timeline and list of mandates to follow while implementing PCI DSS v4.0, you can access the entire list of documents and supporting materials like the summary of differences between PCI DSS v3.2.1 & v4.0, Report on Compliance (ROC) Template, ROC Attestations of Compliance (AOC), and ROC Frequently Asked Questions (FAQs) at the official PCI SSC website.

Implementation Timeline - Is Your Organisation ready for PCI DSS v4.0

During the transition period when both v3.2.1 and v4.0 are in effect, organizations have until March 31, 2025, to adopt the new requirements introduced as best practices in v4.0.

Before this deadline, organizations are not obligated to validate these new requirements. However, those who have already implemented the necessary controls and are prepared for assessment before the effective date are encouraged to proceed with validation. **After March 31, 2025, these new requirements will be mandatory and must be integrated across all PCI DSS assessments. **

What Led to the Implementation of PCI DSS v4.0

The card payments industry involves multiple stakeholders, including banks, payment processors, merchants, and consumers. This complexity creates numerous points of vulnerability that can be exploited. Weaknesses in any part of the payment chain can compromise the entire system, making coordinated security efforts challenging.

The PCI Security Standards Council implemented version 3.2.1 in 2018, but the threat landscape has continued to evolve extensively Even before the global pandemic, which drove people to shop online to minimize COVID-19 exposure, the growing use of payment cards revealed various vulnerabilities that the next version addresses.

Cybercriminals are constantly evolving their tactics, exploiting vulnerabilities in payment systems to steal sensitive cardholder data and commit fraud.

Technological advancements have made payment processes more convenient, but they have also created new avenues for cyber attacks. Methods such as phishing, malware, web vulnerability exploitations (such as SQLi & XSS), and sophisticated social engineering techniques are frequently employed to gain unauthorized access to financial information.

PCI DSS v4.0 Amid Rising API Security Threats

The introduction of PCI DSS v4.0 marks a pivotal step forward in establishing robust security standards, particularly concerning API security. This updated version underscores the necessity for rigorous measures to protect sensitive cardholder information from unauthorized breaches.

As the digital landscape continues its evolution, regular updates such as v4.0 of PCI DSS play a critical role in setting benchmarks to ensure APIs remain secure, dependable, and resilient against emerging security threats.

The post PCI DSS v4.0: What You Need to Know and What the End of v3.2.1 Means for the Future of Digital Payments appeared first on Wallarm.