Analysis of PCI DSS v4.0 - Part 6: Requirements 10 & 11

Here's the latest addition to our ongoing PCI DSS v4.0 analysis series, which looks at requirements 10 and 11. These requirements are part of group 5. Regularly Monitor and Test Networks, which continues with the same name as version 3.2.1 of the standard.

Click here to read the Analysis of DSS DSS v4.0

Part 5: Requirements 7, 8 & 9

The purpose of these two requirements is to ensure traceability in the compliance environment in order to detect malicious patterns. They also serve as a basis in the event of a forensic investigation and validate that the security levels of the environment continue to be acceptable over time.

Requirement 10: Log and Monitor All Access to System Components and Cardholder Data

Requirement 10 defines the security controls required to record the activities that affect the system components of the environment and cardholder data in order to identify any suspicious event proactively and to be able to conduct a post-incident investigation. The critical elements that are part of this requirement are the event/audit records (or logs) and their time synchronization, to ensure the correct correlation of activities of all assets involved in a particular event.

It is imperative to clarify that PCI DSS version 4.0 explicitly excludes activities performed by cardholders from this requirement. Instead, it includes actions performed by employees, contractors, consultants, internal and external vendors, and any other entity that has access to or may affect the security of the environment.

In general terms, this requirement had no relevant changes beyond a reorganization of controls and the addition of some clarifications:

Event log management:

• It is clarified that audit logs must be enabled and active for all system components and cardholder data. It is also emphasized that these logs must only contain the information required for their operation, avoiding the storage of sensitive data (req. 10.2.1)
• As of March 31, 2025, the review of audit logs must be performed using automated tools. This requirement responds to the need to minimize human interaction and its consequent error rate during the manual log review process
• The review periods for event records that should not be reviewed daily (req. 10.4.1) should be adjusted based on risk analysis, in accordance with requirement 12.3.1
  

All other log-related controls (types of actions to be logged, details of each event, log centralization and protection, retention times, etc.) remain unchanged in this new version.

Time synchronization:

• All controls related to time synchronization are unchanged in this new version.

Response to failures in critical security systems:

• Unlike PCI DSS v3.2.1 where only service providers were required to perform detective and corrective actions for any critical failure in critical security systems, in PCI DSS v4.0 this requirement has been extended to all entities affected by PCI DSS compliance as of 31 March 2025 (req. 10.7.2). This includes not only the identification and alerting of the affected critical security control but also the definition of activities aimed at restoring the affected service (req. 10.7.3).
  

These controls subtly introduce the concept of availability into the PCI DSS controls, traditionally oriented towards confidentiality and integrity protection.

Figure 1. Information Security Triad (CIA)

Requirement 11: Test Security of Systems and Networks Regularly

In general terms, throughout the PCI DSS, the actions associated with the lifecycle of security controls for payment card data protection are listed: asset categorization, selection, and implementation (requirements 1, 2, 3, 4, 5, 6, 7, 8 and 9), monitoring (requirement 10) and assessment (requirement 11). The objective of the controls assessment phase is to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the requirements of the standard. All of these actions are covered in PCI DSS Requirement 11.

As a result of the evolution in attack techniques and software vulnerabilities, as well as the massification in the use of cloud platforms, requirement 11 has included a series of updates that allow optimizing the activities oriented towards the evaluation of security controls required by the standard, among which are:

Wireless networks:

• Wireless network identification processes must detect and identify not only authorized access points but also unauthorized ones (req. 11.2.1). The applicability of this control is extensive to both organizations that allow the use of this type of technology in their facilities and those that prohibit it by the policy
• The control associated with incident response procedures for the identification of rogue wireless access points (11.1.2 in PCI DSS v3.2.1) was moved to requirement 12.10.5 in PCI DSS v4.0.

Internal vulnerability scans:

• For internal vulnerability scans, it is clarified that the tool used must be updated with the latest vulnerability information (req. 11.3.1)
• Unlike PCI DSS v3.2.1, vulnerabilities not categorized as critical or high risk must be managed according to risk analysis, and re-scans must be run if necessary (req. 11.3.1.1). This control is applicable as of 31 March 2025
• Probably one of the most relevant changes in PCI DSS is the inclusion of the concept of "authenticated scanning". This approach allows internal scans to go beyond the detection of vulnerabilities from the network point of view and evolves towards the identification of vulnerabilities from the point of view of the asset (host), giving greater visibility to the results and incorporating not only the vulnerabilities of the services exposed to networks but also of the local software and its configuration. To do so, the entity must establish authentication credentials with sufficient privileges to be used by the scanning tool. If the device does not support authentication, it is necessary to document this exception (req. 11.3.1.2). This control is applicable as of 31 March 2025
  
  

Figure 2. Differences between traditional vulnerability scanning and authenticated scanning

External vulnerability scans:

• All controls related to external vulnerability scans remain unchanged in this new version

Internal and external penetration tests:

• It is clarified that:

  •  Testing from inside the network (or "internal penetration testing") means testing from inside the CDE and to the CDE from trusted and untrusted internal networks

  • Tests from outside the network (or "external penetration tests") are those performed at the exposed external perimeter of trusted networks and to critical systems connected or accessible to public networks

  • Penetration test reports must be stored for at least 12 months

• Exploitable vulnerabilities identified in this exercise must be corrected according to the risk levels defined by the organization (req. 11.4.4)

• In the case of multi-tenant providers, these providers shall provide evidence to their customers that their infrastructure penetration tests have been successfully executed and facilitate their customers to execute their own tests (req. 11.4.7). This control is applicable as of 31 March 2025

Intrusion detection/prevention systems (IDS/IPS):

• For service providers, intrusion detection and/or prevention systems must be capable of detecting, alerting, preventing, and managing covert malware communication channels (req. 11.5.1.1). This control is applicable as of 31 March 2025

Protection against unauthorized changes to payment pages:

• Probably one of the most anticipated controls in this version of PCI DSS was the control for protection against unauthorized changes to payment pages. With the escalation of attacks against e-commerce websites using digital skimmers (malicious code developed to remain hidden while capturing and exfiltrating sensitive data on websites, being the digital equivalent of physical skimmers installed on POI devices and ATMs), it was only a matter of time before the PCI SSC took action since this type of attack could neither be identified nor managed with the controls of PCI DSS version 3.2.1
• In April 2017 the PCI SSC published the Information Supplement: Best Practices for Securing E-commerce. This document in its section 7.7 "Best Practices for Securing e-Commerce" described a series of best practices among which was the regular review of any web links (such as URLs, iFrames, APIs, etc.) from the merchant's website to the payment gateway to confirm that these links had not been altered to redirect traffic to unauthorized locations. Still, these actions fell short of mitigating digital skimming attacks
• In PCI DSS v4.0 control 11.6.1 has been included, which requires the deployment of a control to detect unauthorized changes and manipulations in payment pages. These solutions must alert internal staff in the event of unauthorized modifications and must be executed at least every 7 days or at a frequency based on a risk analysis of the entity.

This control (11.6.1) complements control 6.4.3 of PCI DSS v4.0 which requires verification of scripts loaded by payment forms.

New to the Analysis of PCI DSS v4.0 series by Advantio? Follow the links below to catch up on all the articles:

• Part 1: PCI DSS v4.0 Introduction
• Part 2: PCI DSS v4.0 Requirements 1 & 2
• Part 3: PCI DSS v4.0 Requirements 3 & 4
• Part 4: PCI DSS v4.0 Requirements 5 & 6
• Part 5: PCI DSS v4.0 Requirements 7, 8 & 9

References:

• Information Supplement: Effective Daily Log Monitoring
• NIST Risk Management Framework (RMF) Overview
• Information Supplement: Best Practices for Securing E-commerce