PCI DSS version 4.0 recently took effect on March 31, 2024, and includes no less than 63 new requirements. This is the first update of the information security standard designed to defend against payment and credit card fraud since the release of PCI DSS v3.2 eight years ago. Like many facets of security industry regulations and standards, the update was driven by the need to ensure that “the [PCI] standard is up to date with emerging threats and technologies and change in the payment industry.” Examples of the changes include new or modified requirements and/or testing procedures or the removal of a requirement. While some requirements are effective immediately, the majority do not come into effect until March 31, 2025, giving businesses a year-long transition period to implement the more challenging aspects.
One notable shift in the updated standards lies in the heightened emphasis on penetration testing, underscoring the necessity for robust security measures. Merchants and processors will be under increased scrutiny to validate that their cardholder environments are entrusted with the appropriate protections to achieve the coveted Report on Compliance (ROC). The new standards place a premium on comprehensive penetration testing methodologies, requiring security vendors to go beyond routine assessments. By aligning with the evolving threat landscape, v4.0 ensures that consumers can trust that cybersecurity measures remain proactive, adaptive and resilient when they see the PCI DSS seal of approval.
Penetration testing forms a critical aspect of the PCI DSS changes. In terms of updates to requirements around when and how pen testing is performed, in relation to the tools used and the areas covered, the major changes affecting pen testing are:
This new requirement is to manage all other applicable vulnerabilities (those not ranked as high-risk or critical) found during internal vulnerability scans. This requirement is a best practice until March 31, 2025.
This new requirement is to perform internal vulnerability scans via authenticated scanning, which is a best practice until March 31, 2025.
This new requirement is for multi-tenant service providers to support their customers for external penetration testing. This requirement is a best practice until March 31, 2025.
This new requirement is for service providers to use intrusion detection or intrusion prevention techniques to detect, alert on/prevent, and address covert malware communication channels. This requirement is best practice until March 31, 2025.
This new requirement is to deploy a change-and-tamper detection mechanism to alert for unauthorized modifications to the HTTP headers and contents of payment pages as received by the consumer browser. This requirement is a best practice until March 31, 2025.
This new requirement is for technical controls to prevent copying and/or relocation of PAN when using remote access technologies. Expanded from former Requirement 12.3.10. This requirement is a best practice until March 31, 2025.
This new requirement is to detect and protect personnel against phishing attacks. This requirement is a best practice until March 31, 2025. See also 12.6.2 on Security Awareness training at least every 12 months.
This new requirement is to deploy an automated technical solution for public-facing web applications that continually detects and prevents web-based attacks. This new requirement removes the option in Requirement 6.4.1 to review web applications via manual or automated application vulnerability assessment tools or methods. This requirement is a best practice until March 31, 2025.
This new requirement is to increase password length from a minimum length of seven characters to a minimum length of 12 characters (or if the system does not support 12 characters, a minimum length of eight characters). This requirement is a best practice until March 31, 2025. Until then, passwords must be a minimum length of at least seven characters in accordance with v3.2.1 Requirement 8.2.3. This requirement applies only if passwords/passphrases are used as an authentication factor to meet Requirement 8.3.1. This requirement is not intended to apply to user accounts on point-of-sale terminals that have access to only one card number at a time to facilitate a single transaction.
This new requirement is for service providers only. If passwords/passphrases are the only authentication factor for customer user access, then passwords/passphrases are either changed at least once every 90 days, or access to resources is automatically determined by dynamically analyzing the security posture of the accounts. This requirement is a best practice until March 31, 2025, and does not apply to accounts of consumer users accessing their payment card information. It will supersede Requirement 8.3.10 once it becomes effective, and until that date, service providers may meet either Requirement 8.3.10 or 8.3.10.1.
This new requirement is to implement multi-factor authentication (MFA) for all access into the cardholder data environment (CDE). This requirement is a best practice until March 31, 2025. MFA is required for both types of access specified in Requirements 8.4.2 and 8.4.3. Applying MFA to one type of access does not replace applying another instance of MFA to the other type of access.
This new requirement is to document and confirm PCI DSS scope at least every 12 months and upon significant change to the in-scope environment. It is effective immediately for all v4.0 assessments.
This new requirement is to confirm, via penetration testing, the effectiveness of logical separation controls used to separate customer environments. This is a best practice until March 31, 2025.
Strictly speaking, annual penetration testing will fall under Requirement 11.3. It is important to remember that a security vendor fulfilling requirement 11.3 is not the auditor. The penetration test is one of many artifacts provided to the auditor in the ROC evaluation. This means that an effective penetration testing vendor should uncover any security vulnerabilities that could potentially impact your ROC and give you detailed steps to remediate them so that your Compliance team has a clean sheet to present to their auditor. With PCI v4.0, this includes non-critical/high findings. Merchants/processors must either remediate those medium and low findings or include an analysis that they are being resolved at a frequency according to their risk level.
The list of changes above also features authenticated scans for the internal network. This requirement can add further preparation time to which the application and infrastructure teams, or testing team, may not be accustomed. Another point to note about authentication is the new requirement to implement MFA for all access to the CDE. This, coupled with the new password length requirements, will surely be a key area of focus for penetration testers.
One final thought is the hot-button topic of what constitutes “significant change.” Who determines that a “significant change” has occurred? This is an important issue because in-scope PCI DSS systems are often only tested annually. Depending on an organization’s development lifecycle, there could be changes to these systems on a regular basis throughout the year. Consequently, leaving 12 months between assessments could pose risks to an organization that has not completed defined “significant change.” It is in this vein, perhaps, that the architects of v4.0 have introduced Requirement 6.4.2. This can be interpreted to refer to “continuous pen testing.” In other words, although a penetration test is required annually, some processes should be in place to ensure that even non-significant changes are assessed. After all, many penetration tests see minor, low-severity risks chained into a high-severity vulnerability.
While organizations have time to implement changes in response to the release of PCI DSS 4.0 and the requirements relating to penetration testing, it is important to take steps now to prepare. This involves an overview of the new requirements and your organization’s current approach to pen testing. As mentioned above, the changes could require a shift in the cadence of testing. While adapting to v4.0 changes may initially appear to present an additional security burden for in-house teams, firms can benefit by viewing it as an opportunity to review their current penetration testing practices and ensure they are maximizing their security investment. By working with a trusted external provider with a proven track record, companies can ensure that their defenses are fully tested, with a comprehensive plan to mitigate any identified issues.
Kroll’s Cyber Risk team has the knowledge and experience to handle the most complex, large-scale pen testing engagements. Our penetration testing services can be scaled and adapted to align with the requirements of the evolving compliance landscape, including those of the PCI DSS.
Incident response, digital forensics, breach notification, managed detection services, penetration testing, cyber assessments and advisory.
Kroll’s cyber risk assessments deliver actionable recommendations to improve security, using industry best practices & the best technology available.
Proactively identify your highest-risk exposures and address key gaps in your security posture. As the No. 1 Incident Response provider, Kroll leverages frontline intelligence from 3000+ IR cases a year with adversary intel from deep and dark web sources to discover unknown exposures and validate defenses.
Manage cyber risk and information security governance issues with Kroll’s defensible cyber security strategy framework.
Validate your cyber defenses against real-world threats. Kroll’s world-class penetration testing services bring together front-line threat intelligence, thousands of hours of cyber security assessments completed each year and a team of certified cyber experts — the foundation for our sophisticated and scalable approach.