In the ever-evolving landscape of cybersecurity, staying updated with the latest standards and protocols is crucial. One such standard that has undergone significant changes is the Payment Card Industry Data Security Standard (PCI DSS) Requirement 11. This requirement, focused on the regular testing of security systems and networks, has seen notable updates in its transition from version 3.2.1 to version 4.0. check out our comprehensive guide on the “12 requirements of PCI DSS.”
In this blog post, we will delve into the intricacies of these changes, providing a comprehensive understanding of each sub-requirement, from identifying and monitoring wireless access points to detecting and responding to unauthorized changes on payment pages. We will also discuss the continual discovery of vulnerabilities by malicious individuals and researchers, and the need for frequent testing of system components, processes, and custom software.
Join us as we navigate through these changes, helping you stay ahead in maintaining robust security controls in a dynamic environment.
| Requirement | v3.2.1 (11.1) | v4.0 (11.2.1) | Changes |
|---|---|---|---|
| Core Requirement | Processes for detecting and identifying both authorized and unauthorized wireless access points. | Identical requirement. | No Changes. |
| Methodology | Suggests verifying methods can detect various unauthorized access scenarios (rogue devices, cards inserted into systems, etc.) | Retains the focus on covering potential rogue devices. | No Changes. |
| Frequency | Requires testing quarterly. | Shortens the interval to "at least once every three months". | Increased frequency requirement. |
| Automated Monitoring | Mentions automated monitoring (IDS/IPS, etc.) generates alerts. | Retains this requirement. | No Changes. |
| Testing Procedures | Focuses on examining policies, reviewing scan results, etc. | Includes policy and process review, like v3.2.1, but emphasizes that the conducted assessments align with the requirements. | Focus on verifying that what's on paper matches' practice. |
PCI DSS v4.0 enhances wireless access point checks by increasing scan frequency to at least every three months and emphasizing alignment between real-world practices and procedures.
| Requirement | v3.2.1 (11.2.3) | v4.0 (11.3.1.3 & 11.3.2.1) | Changes |
|---|---|---|---|
| Triggering Event | Significant network or system changes | Identical trigger | No changes. |
| Scan Scope | Both internal and external scans required post-change | Separate rules now for internal (11.3.1.3) and external (11.3.2.1) scans | Increased clarity. |
| Internal Remediation Goal | Rescan until "high-risk" vulnerabilities are resolved (defined in 6.1). | Must resolve "high-risk and critical" vulnerabilities based on the entity's own risk rankings (defined in 6.3.1). | A more nuanced, risk-based approach. |
| External Remediation Goal | Rescan until no vulnerabilities rated 4.0 or higher by CVSS remain. | Identical requirement. | No changes. |
| Tester Qualifications | Qualified personnel. Organizational independence for scans mentioned. | Explicitly requires organizational independence of the tester. | Increased rigor. |
| Testing Procedures | Focuses on review of scan reports and correlation with change control records. | Retains similar focus on scan reports and change controls, with an added emphasis on interviewing personnel. | Stronger emphasis on verifying real-world practice. |
PCI DSS v4.0 refines vulnerability scanning by introducing a risk-based approach, distinguishing between internal and external scans, aligning remediations with the organization’s vulnerability rankings, and mandating tester independence.
| Requirement | v3.2.1 (11.3) | v4.0 (11.4.1) | Changes |
|---|---|---|---|
| Methodology Basis | Must be based on industry-accepted approaches (e.g., NIST SP800-115). | Identical requirement. | No changes. |
| Scope | Must cover the entire CDE perimeter and critical systems. | No changes. | Identical requirement. |
| Internal & External | Requires testing from both inside and outside the network. | No changes. | Identical requirement. |
| Segmentation Testing | Must include tests to validate segmentation controls. | No changes. | Identical requirement. |
| App-Layer Testing | Tests must address vulnerabilities listed in Requirement 6.5 | Shifts focus to those listed in Requirement 6.2.4 | Updated reference to align with current vulnerabilities. |
| Network-Layer Testing | Includes network components and operating systems. | Identical requirement. | No changes. |
| Threat Review | Methodology should consider threats from the past year. | No changes. | Identical requirement. |
| Risk Assessment of Findings | N/A in v3.2.1 | v4.0 mandates a documented approach for assessing and addressing risks from identified vulnerabilities. | Significant addition. |
| Record Keeping | Requires retention of results. | Expands recordkeeping to include remediation activities and extends the retention period to at least 12 months. | Increased retention timeframe. |
PCI DSS v4.0 updates penetration testing methodology by introducing a risk-focused approach, aligning application-layer testing with current vulnerabilities, and enhancing recordkeeping requirements.
| Requirement | v3.2.1 (11.3.3) | v4.0 (11.4.4) | Changes |
|---|---|---|---|
| Core Principle | Exploitable vulnerabilities found during penetration testing must be corrected and retested for verification. | Identical core principle. | No changes. |
| Risk-Based Remediation | No explicit mention of risk assessment in the remediation process. | Requires remediation to align with the entity's risk assessment (defined in Requirement 6.3.1). | Introduces risk-based approach to remediation. |
| Terminology | Focuses on "exploitable vulnerabilities". | Expands to include "security weaknesses" alongside exploitable vulnerabilities. | Broader scope of issues to address. |
| Testing Procedures | Focus on verifying correction through examining results and retesting. | Similar focus on documentation and retesting. | No major changes. |
PCI DSS v4.0 revises penetration testing findings’ handling by adopting a risk-based approach for remediation priority and expanding the scope to address all identified security weaknesses.
| Requirement | V3.2.1 (11.1.2 & 11.5.1) | v4.0 (12.10.5) | Changes |
|---|---|---|---|
| Scope | 11.1.2: Unauthorized wireless access points 11.5.1: Change-detection alerts | Broadens scope to alerts from various security systems, including those previously specified. | Consolidation and broader focus. |
| Incident Response Plan | Both require the incident response plan to address these alerts. | Maintains the requirement of having a plan. | No changes. |
| Testing Procedures | v3.2.1 focuses on past incident review (wireless) and interviewing personnel for change-detection alert response. | Shifts to observing processes and verifying if the plan covers responding to various alerts. | Focuses on plan and practice alignment. |
PCI DSS v4.0 enhances alert response by consolidating wireless and change-detection alerts into the incident response plan, broadening the scope to include alerts from all security monitoring systems, and emphasizing alignment between the written plan and actual response practices.
New Requirements:
Requirement 11.1.2:
PCI DSS v4.0 Requirement 11.1.2 mandates that roles and responsibilities related to Requirement 11 must be clearly defined, assigned, and comprehended. (This requirement is effective immediately for all v4.0 assessments.)
This involves:
- 11.1.2.a: Checking that these roles and responsibilities are properly documented and allocated.
- 11.1.2.b: Confirming through interviews that the assigned personnel understand their roles and responsibilities as documented.
Requirement 11.3.1.1:
PCI DSS v4.0 Requirement 11.3.1.1 stipulates that vulnerabilities not classified as high-risk or critical (as per Requirement 6.3.1) must be managed as follows: (This requirement is a best practice until 31 March 2025.)
- They should be addressed based on the risk defined in the entity’s targeted risk analysis, which should comply with all elements specified in Requirement 12.3.1.
- Rescans should be conducted as necessary.
Sub-requirements are:
- 11.3.1.1.a: Verify that the risk analysis for addressing all other applicable vulnerabilities was performed in accordance with Requirement 12.3.1.
- 11.3.1.1.b: Confirm through interviews and examination of internal scan report results that all other applicable vulnerabilities are addressed based on the risk defined in the entity’s targeted risk analysis, and that rescans are conducted as needed to confirm the vulnerabilities have been addressed.
Requirement 11.3.1.2:
PCI DSS v4.0 Requirement 11.3.1.2 requires internal vulnerability scans to be performed using authenticated scanning. (This requirement is a best practice until 31 March 2025.) The key points are:
- Systems that can’t accept credentials for authenticated scanning must be documented.
- For systems that accept credentials, sufficient privileges must be used for scanning.
- If accounts used for authenticated scanning can also be used for interactive login, they must be managed as per Requirement 8.2.2.
Sub-requirements include:
- 11.3.1.2.a: Verify that authenticated scanning is used for internal scans, with sufficient privileges, for systems that accept credentials.
- 11.3.1.2.b: Verify that authenticated scans are performed by examining scan report results and interviewing personnel.
- 11.3.1.2.c: If accounts used for authenticated scanning can be used for interactive login, verify that these accounts are managed as per Requirement 8.2.2.
- 11.3.1.2.d: Verify that systems unable to accept credentials for authenticated scanning are documented.
Requirement 11.4.7:
PCI DSS v4.0 Requirement 11.4.7, applicable only to multi-tenant service providers, mandates that they must support their customers for external penetration testing as per Requirement 11.4.3 and 11.4.4. The testing procedure involves examining evidence to verify this support. (This requirement is a best practice until 31 March 2025.)
Requirement 11.5.1.1:
PCI DSS v4.0 Requirement 11.5.1.1, applicable only to service providers, mandates the use of intrusion-detection and/or intrusion-prevention techniques to detect, alert on, and address covert malware communication channels. (This requirement is a best practice until 31 March 2025.) The sub-requirements are:
- 11.5.1.1.a: Verify that methods to detect and alert on/prevent covert malware communication channels are in place and operating.
- 11.5.1.1.b. Verify that the entity’s incident-response plan requires and defines a response if covert malware communication channels are detected.
- 11.5.1.1.c: Verify that personnel maintain knowledge of covert malware communication and control techniques and know how to respond when malware is suspected.
Requirement 11.6.1:
PCI DSS v4.0 Requirement 11.6.1 requires a change- and tamper-detection mechanism to be deployed that: (This requirement is a best practice until 31 March 2025.)
- Alerts personnel to unauthorized modifications to HTTP headers and payment page contents.
- Is configured to evaluate the received HTTP header and payment page.
- Functions at least once every seven days or at a frequency defined in the entity’s targeted risk analysis (Requirement 12.3.1).
Sub-requirements include:
- 11.6.1.a: Verify the use of a change- and tamper-detection mechanism by examining system settings, monitored payment pages, and monitoring results.
- 11.6.1.b: Verify the mechanism is configured as per this requirement.
- 11.6.1.c: If the mechanism functions at an entity-defined frequency, verify the risk analysis was performed as per Requirement 12.3.1.
- 11.6.1.d: Verify the mechanism functions either at least once every seven days or at the frequency defined in the entity’s targeted risk analysis.
Conclusion:
The revisions within PCI DSS v4.0 demonstrate the continuous adaptation of the standard to an ever-evolving threat landscape. The new emphasis on clarity of roles, increased testing frequency, risk-based remediation, broader security monitoring, and proactive malware detection underscores a determination to stay ahead of malicious actors.
These enhancements aren’t just a matter of checkbox compliance; they’re crucial for the protection of cardholder data and the reputation of businesses handling that sensitive information. By diligently adhering to PCI DSS v4.0, organizations take a decisive step towards building a robust cybersecurity posture.
Also Read : PCI DSS Requirement 10
Let us help you
Need help navigating PCI DSS v4.0? We have been active in the PCI DSS space since 2008 and even certify payment brand. Our PCI DSS services provide assurance on card security controls, with offerings for both product platform and backend services attestation.
We have a dedicated team of auditors and a separate team for consulting/advisory assignments to even help our esteemed clients to define processes and achieve compliance.
We have completed multiple PCI DSS 4.0 certifications too right from scoping to Readiness Assessment, Advisory and Final Certification.
We are vendor neutral and have a strict no-outsourcing policy. We can also assist you with the technical assessments needed for PCI DSS Compliance – Vulnerability Assessment, Penetration Testing, Network Segmentation Testing, Network Architecture Review, Firewall Assessment, Secure Configuration Assessment, Web and Mobile Application Security Assessment, and Secure Code Review.
