The transition from PCI DSS v3.2.1 to PCI DSS v4.0 marked a significant shift towards a more proactive approach to payment security. Then PCI DSS v4.0.1 was released on June 11, 2024 to update some requirements and add a glossary of terms. PCI DSS v3.2.1 was retired on March 31st, 2024, but certain requirements for PCI DSS v4.0.1 go into full effect on March 31st, 2025. Today, we will focus on Requirements 6 and 11 of PCI DSS v4.0.1, concerning vulnerability scanning, remediation and penetration testing. First, we will explore the difference between Vulnerability Scanning and Penetration Testing according to PCI DSS v4.0.1, since this can be a point of confusion (no doubt exacerbated by certain vendors marketing “automated penetration testing” services).
Vulnerability Scanning vs. Penetration Testing
Vulnerability scanning is an automated process to identify potential vulnerabilities in a network or web application. These scans serve as a preliminary step, providing a snapshot of potential security weaknesses that exist within an environment. Vulnerability scanners are tools, and their results need to be validated by humans afterward.
Penetration testing, on the other hand, is not a tool. Rather it’s a service performed by experienced professionals. Penetration tests go much deeper than vulnerability scans that rely purely on automation. Defined by the PCI SSC, penetration testing involves a credentialed expert actively attempting to exploit vulnerabilities to determine how an attacker could potentially enter an environment. Penetration testing simulates real-world attack scenarios, to help define an organization’s potential exposure and devise a strategy to remediate these vulnerabilities.
Vulnerability scanning is usually the first step when performing a penetration test, but a human is always required to interpret those results. A penetration test is not deemed adequate if it solely focuses on exploiting vulnerabilities identified in a scan. Penetration testers, with their deep knowledge of systems and potential attack strategies, manually probe for weaknesses. Some techniques employed by penetration testers to obtain this extra layer of depth would include fuzzing, injection, forgery tests, and business logic testing (scanners lack the real-world risk context that humans possess). They may use automated tools as part of their toolkit, but the expertise and creative problem-solving of the tester are indispensable since those qualities cannot be automated.
For example, if a vulnerability scan identifies a potential weakness in an application server, a penetration tester may use this foothold to launch subsequent attacks that an automated tool would not attempt. By chaining exploits and using the compromised server as a staging point, testers can simulate complex attack paths that an attacker might use, uncovering layers of potential weaknesses that a scan alone would not be able to reveal.
Penetration testing also includes the assessment of security monitoring and detection methods. Testers confirm the effectiveness of logging and file integrity monitoring mechanisms, aspects critical to an organization’s ability to detect and respond to an attack.
Requirement 6
Security Vulnerability Identification & Risk Ranking: Requirement 6.3.1 mandates that organizations identify new security vulnerabilities using industry-recognized sources and assign risk rankings based on industry best practices. The risk ranking must identify all high-risk and critical vulnerabilities. Regular vulnerability scanning ensures that vulnerabilities are systematically discovered and prioritized for remediation.
Protection from Known Vulnerabilities through Patching: Requirement 6.3.3 instructs organizations to install security patches for critical vulnerabilities within one month of release, and other patches must be applied based on a risk assessment following the ranking process defined in 6.3.1. Vulnerability scanning plays a critical role in detecting outdated or unpatched systems, ensuring compliance with this requirement.
Protection of Public-Facing Web Applications: Requirement 6.4.1 states that it is essential for public-facing web applications to undergo manual or automated vulnerability assessments at least once every 12 months and after significant changes. Alternatively, organizations can deploy automated solutions such as Web Application Firewalls (WAFs) to detect and prevent web-based attacks. Vulnerability scanning is crucial for meeting this requirement by identifying exploitable weaknesses in web applications.
Verification of PCI DSS Controls After Significant Changes: Following significant changes to system components, requirement 6.5.2 organizations must verify that all applicable PCI DSS requirements remain in place and update documentation accordingly. Vulnerability scanning ensures that newly introduced or modified systems are not left exposed to security threats after major updates or infrastructure changes.
Requirement 11
Quarterly Vulnerability Scanning: Under requirement 11.3.2, organizations are required to conduct vulnerability scans quarterly by a PCI SSC Approved Scanning Vendor (ASV). This adjustment emphasizes the importance of identifying vulnerabilities but also resolving them following the ASV Program Guide’s standards. While only quarterly scans are required, it’s encouraged to scan after significant changes to infrastructure or applications, such as adding new network devices or pushing deployments to production.
Annual Penetration Testing on Cardholder Data Environments (CDEs): The updated requirements, 11.4.2 and 11.4.3, mandate an annual penetration test on both internal and external CDEs. This requirement also mandates penetration tests following significant changes to infrastructure or applications.
Verification of Remediation and Risk-Based Approach: The new standard requires retesting to verify the effectiveness of corrective actions (11.4.4). In doing so, PCI DSS v4.0.1 also advocates for a risk-based approach to prioritizing remediation efforts.
Segmentation Controls and Multi-Tenant Service Providers: Requirement 11.4.5 necessitates testing segmentation controls annually or after any changes, critical for isolating the cardholder data environment (CDE). For multi-tenant service providers, the new standards (11.4.6) call for validating logical separation controls biannually with a penetration test. Another set of biannual penetration tests is required (A.1.1.4) for multi-tenant service providers to determine adequate separation between customers in their environment. Requirement 11.4.7 increases the emphasis on multi-tenant service providers to assist customers with their external penetration tests.
Edgescan Can Fulfill PCI DSS V4.0.1 Requirements
Risk rating is a key part of requirement 6. The Edgescan platform displays risk ratings for every vulnerability according to EPSS (Exploit Prediction Scoring System), CISA (Cybersecurity and Infrastructure Security Agency) KEV (Known Exploited Vulnerability), CVSS (Common Vulnerability Scoring System) and asset criticality to ensure that you are properly triaging PCI failing vulnerabilities in the context of your organization.
Edgescan is recognized as a PCI Approved Scanning Vendor (ASV) and offers an integrated platform where organizations can manage both their penetration testing findings and vulnerability scanning results. Consolidating these functions allows for a more efficient and holistic approach to maintaining PCI DSS v4.0.1 compliance.
The Edgescan platform only shows validated vulnerabilities, which means no false positives in Edgescan’s scanning results. On average, not having to validate false positives saves organizations’ security teams a few hours every week. In the context of quarterly vulnerability scans for PCI compliance, this is valuable. Organizations can be sure that all PCI failing vulnerabilities have been validated as true positives.
Edgescan offers unlimited, no-charge retesting on any penetration testing finding. This ensures that any remediation efforts are verified effectively and requirement 11.4.4 is satisfied without the financial strain associated with paying traditional penetration testing vendors for retesting.
The transition to PCI DSS v4.0.1 will significantly impact how organizations approach vulnerability scanning and penetration testing. Edgescan’s PCI compliance program utilizes a risk-based approach and unlimited, no-charge retesting on penetration testing findings to deliver simple but affordable PCI DSS v4.0.1 compliance.
References
Requirements and Testing Procedures Version 4.0.1
Summary of Changes from PCI DSS Version 3.2.1 to 4.0
