Analysis of PCI DSS v4.0 Part VI: Requirements 10 and 11

In this sixth installment of the series ‘PCI DSS analysis v4.0’, requirements 10 and 11 of the PCI DSS standard v4.0 will be analysed. These requirements are part of the group 5. Regularly Monitor and Test Networks, It continues with the same name as version 3.2.1 of the standard.

The objective of these two requirements is to ensure traceability in the compliance environment in order to detect malicious patterns and serve as a basis in the case 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 necessary to record activities affecting the system components of the environment and cardholder data in order to proactively identify any suspicious events 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 its synchronization at the time level, to ensure the correct correlation of activities of all assets involved in a particular event.

It is important to clarify that in version 4.0 of PCI DSS the activities carried out by cardholders are explicitly excluded from this requirement (cardholders) and includes actions taken by employees, contractors, consultants, internal and external suppliers and any other entity that has access to or may affect the security of the environment.

Generally speaking, this requirement had no relevant changes beyond a reorganisation of controls and the addition of some clarifications:

Event logs management:

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

All other controls related to logs (types of actions to be registered, details of each event, centralization and protection of logs, retention times, etc.) do not change in this new version.

Time synchronization:

All controls related to time synchronization do not change 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 against 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 generation of alerts of the critical security control affected but also the definition of activities aimed at the restoration of the affected service (req. 10.7.3). These controls introduce the concept of availability in a subtle way (availability) within the controls of PCI DSS, traditionally oriented to the protection of confidentiality (confidentiality) and integrity (integrity).

Information Security Triad (ICS)

Requirement 11: Test Security of Systems and Networks Regularly

Generally speaking, actions related to the lifecycle of security controls for payment card data protection are listed throughout the PCI DSS standard: asset categorization, selection and implementation (requirements 1, 2, 3, 4, 5, 6, 7, 8 and 9), monitoring (requirement 10) and evaluation (requirement 11). The objective of the evaluation phase of controls is to determine the extent to which controls are correctly implemented, function as intended and produce the desired result with respect to compliance with 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 overcrowding in the use of cloud platforms (cloud), requirement 11 has included a series of updates that allow optimizing the activities oriented towards the evaluation of the security controls required by the standard, among which are:

Wireless networks:

• Wireless network identification processes should detect and identify not only authorised but also unauthorised access points (req. 11.2.1). The applicability of this control is extended both to organizations that allow the use of this type of technology in their facilities and those that prohibit it by regulation.
• The control associated with response procedures to the identification of unauthorized 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 should be managed according to a risk analysis and re-scans should be executed if necessary (req. 11.3.1.1). This check is applicable from 31 March 2025.
• Probably one of the most relevant changes in PCI DSS is the inclusion of concept of “authenticated scans” (authenticated scanning). This approach allows internal scans to go beyond the detection of vulnerabilities from the network point of view and evolve towards the identification of vulnerabilities from the asset point of view (host), giving greater visibility to the results and incorporating not only the vulnerabilities of the services published in data networks but also of the local software and its configuration. To do this, the entity must establish authentication credentials with sufficient privileges so that they can be used by the scanning tool. In the event that the device does not support authentication, it is necessary to document this exception (req. 11.3.1.2). This check is applicable from 31 March 2025.

Differences between traditional vulnerability scanning and authenticated scanning

External vulnerability scans:

All controls related to external vulnerability scans do not change in this new release.

Internal and external penetration tests:

• It is clarified that:
  • In-network testing (or "internal penetration testing") means testing from within the CDE and into the CDE from trusted and untrusted internal networks.
  • External network tests (or ‘external penetration tests’) are those carried out on the exposed external perimeter of trusted networks and critical systems connected or accessible to public networks.
  • Penetration test reports should be stored for at least 12 months.
• Exploitable vulnerabilities identified in this exercise should be corrected according to the risk levels defined by the organization (req. 11.4.4).
• In the case of suppliers multi-tenant, these suppliers shall provide evidence to their customers that the penetration tests of their infrastructure have been successfully executed and facilitate their customers in the execution of their own tests (req. 11.4.7). This check is applicable from 31 March 2025.

Intrusion detection/prevention systems (IDS/IPS):

• For service providers, intrusion detection or prevention systems must be able to detect, alert, prevent and manage covert communication channels of malware (req. 11.5.1.1). This check is applicable from 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 skimmersmalicious code developed to remain hidden while capturing and exfiltrating sensitive data on websites, being the digital equivalent of skimmers physical devices installed in POI devices and electronic tellers), it was a matter of time before the PCI SSC took action on the matter, since this type of attack could not be identified or managed with the controls of version 3.2.1 of PCI DSS.

In April 2017 the PCI SSC published the document Information Supplement: Best Practices for Securing E-commerce. This document in its section 7.7 “Best Practices for Securing e-Commerce” described a number of best practices including regular review of any web links (such as URLs, iFrames, APIs, etc.) from the merchant 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 the attacks of Digital Skimmers.

In PCI DSS v4.0 control 11.6.1 has been included, where the deployment of a control is required to detect unauthorized changes and manipulations on payment pages. These solutions should alert internal staff in case of unauthorised modifications and their implementation should be at least every 7 days or at regular intervals based on a risk analysis of the institution.

This control (11.6.1) complements PCI DSS v4.0 control 6.4.3 where a verification of the scripts loaded on the payment forms is required.

References

• Information Supplement: Effective Daily Log Monitoring https://docs-prv.pcisecuritystandards.org/Guidance%20Document/Logging/Effective-Daily-Log-Monitoring-Guidance.pdf
• NIST Risk Management Framework (RMF) Overview https://csrc.nist.rip/Projects/Risk-Management/Risk-Management-Framework-(RMF)-Overview
• Information Supplement: Best Practices for Securing E-commerce https://docs-prv.pcisecuritystandards.org/Guidance%20Document/e-Commerce/best_practices_securing_ecommerce.pdf