Navigating the Latest PCI DSS Updates: Addressing Requirements 6.4.3 and 11.6.1 for Client-Side Security

5 min read

The release of PCI DSS v4.0 has introduced significant updates to address emerging threats in the payment ecosystem, particularly focusing on client-side security. Two new requirements—6.4.3 and 11.6.1—are particularly important for businesses of all sizes that handle payment card data, as they highlight the vulnerabilities posed by external scripts used on payment pages. As scripts loaded onto websites can undergo changes or be compromised without an entity’s knowledge, the PCI Security Standards Council has emphasized the need for stronger controls to mitigate this risk.

In this post, we’ll break down the importance of these new requirements and offer actionable guidance for implementing them, ensuring compliance and protecting your payment environments.

Understanding Requirement 6.4.3: Managing and Protecting Scripts

PCI DSS Requirement 6.4.3 addresses the need to manage and protect scripts loaded and executed on the payment page. As entities often rely on third-party scripts for enhanced functionality—such as analytics, fraud detection, or customer experience improvements—these scripts can become a critical attack vector. The Standard now acknowledges that scripts can change functionality without the entity’s knowledge or approval, opening the door to client-side attacks such as Magecart-style breaches.

Key Points of Requirement 6.4.3:

  • Maintain an Inventory of Scripts: Entities must identify and document all scripts that are loaded and executed on the payment page. This includes both internal and external scripts, such as those from third-party vendors.
  • Define Approved Sources: A list of approved scripts and their sources must be established, ensuring that only trusted scripts are allowed to run on the payment page.
  • Integrity Checks and Change Management: Entities must implement mechanisms to verify that scripts maintain their integrity, are unchanged from the authorized version, and are executed from approved sources.

How to Implement 6.4.3 in Practice:

  1. Create a Script Inventory: Begin by conducting a thorough audit of all scripts currently running on your payment page. This should include JavaScript libraries, tracking pixels, and any code provided by third-party vendors. For each script, document details such as its function, source, and approval status.
  2. Establish a Whitelisting Process: Work with your development and security teams to create a list of approved scripts. Ensure that this list is periodically reviewed, particularly when new functionality is added to your website.
  3. Implement Content Security Policy (CSP): A CSP can help enforce whitelisting of approved script sources, preventing unauthorized code from being executed. CSPs act as a powerful security control by blocking any scripts that are not explicitly authorized in the security policy.
  4. Apply Subresource Integrity (SRI): SRI ensures that scripts have not been tampered with by verifying the script’s integrity using cryptographic hashes. If the hash value does not match, the browser blocks the execution of the compromised script.
  5. Develop a Change Management Process: Establish a formal change management process for scripts. This should include review and approval workflows, as well as the automatic detection of any changes in script functionality or source, triggering alerts for the security team.

Demonstrating Compliance During Your PCI DSS Assessment:

  • Script Inventory: Provide your QSA with the documented inventory of scripts loaded on your payment page, including internal and external scripts.
  • Change Management Procedures: Present evidence of your change management processes, such as logs showing approvals of new or updated scripts.
  • Proof of Integrity Mechanisms: Share details of your integrity controls (e.g., CSP policies and SRI configurations) to demonstrate how you prevent unauthorized scripts from being executed.
  • Periodic Review Documentation: Document and provide proof of periodic reviews of your approved script list and sources.

Understanding Requirement 11.6.1: Continuous Monitoring of Scripts for Unexpected Changes

Requirement 11.6.1 builds on 6.4.3 by ensuring that approved scripts are continuously monitored for any unauthorized changes, adding an extra layer of security. This proactive approach helps detect potential tampering or malicious changes that could occur without the entity’s knowledge, further protecting payment pages from client-side attacks.

Key Points of Requirement 11.6.1:

  • Automated Change Detection: Entities are required to implement automated tools or solutions to detect unauthorized changes to scripts. This monitoring must be continuous and cover all scripts loaded and executed on the payment page.
  • Alerting Mechanisms: The solution must generate alerts whenever an unauthorized script or change is detected, enabling the entity to quickly respond to and remediate the threat.

How to Implement 11.6.1 in Practice:

  1. Implement Script Monitoring Solutions: Leverage tools designed to continuously monitor the integrity of scripts on your payment page. Solutions like Content Security Monitoring tools (e.g., Feroot or Jscrambler) can automatically detect unauthorized script changes or executions and provide real-time alerts.
  2. Set Up Alerts and Incident Response: Ensure your monitoring tool is configured to send immediate alerts when an unauthorized script or change is detected. These alerts should be integrated into your broader incident response program to ensure rapid remediation. Additionally, the alerting mechanism must be tested periodically to ensure its reliability.
  3. Conduct Regular Script Audits: Even with automated solutions in place, manual reviews of your script inventory and monitoring configuration should be conducted regularly. This ensures that new scripts or sources have been properly approved and integrated into the monitoring system.
  4. Integrate with Web Application Firewalls (WAF): Consider integrating script monitoring with your WAF to block unauthorized scripts in real-time, offering an additional line of defense.

Demonstrating Compliance During Your PCI DSS Assessment:

  • Automated Monitoring Reports: Provide evidence of the automated monitoring solution in use, such as monitoring logs or reports that detail when and how the system was triggered.
  • Alert Logs and Incident Reports: Share examples of alerts generated by your system, along with the corresponding incident response actions taken.
  • Configuration Documentation: Present documentation detailing how your automated tool is configured, including specific criteria for what constitutes an unauthorized script or change.

Why These Changes Matter: Protecting Against Client-Side Attacks

The rise of sophisticated client-side attacks such as Magecart, which exploit vulnerabilities in third-party scripts, is a key driver behind these changes. Scripts loaded from external sources can easily be modified by attackers to steal sensitive payment data directly from users’ browsers—without triggering server-side defenses. By requiring a combination of inventory management, integrity checks, and continuous monitoring, PCI DSS v4.0 aims to prevent these types of attacks and ensure that entities maintain control over their payment environments.

As businesses increasingly rely on third-party scripts, the attack surface expands, and so do the risks. By implementing Requirements 6.4.3 and 11.6.1, businesses can take proactive steps to manage client-side security and safeguard the integrity of their payment processes.

Final Thoughts: Taking Action on PCI DSS v4.0

The introduction of these new requirements underscores the critical importance of client-side security. PCI DSS v4.0 acknowledges that entities may not always have full visibility into the scripts running on their payment pages, making it crucial to put the necessary controls in place. By actively managing scripts, implementing integrity checks, and continuously monitoring for unauthorized changes, businesses can reduce the risk of client-side attacks and maintain compliance.

If you’re preparing for your next PCI DSS assessment, now is the time to review your script management practices, implement automated monitoring solutions, and ensure that your change management processes are airtight. The changes to PCI DSS v4.0 are significant, but with the right approach, businesses can stay ahead of the curve and protect their payment environments effectively.

By following this guidance, you’ll be well-positioned to demonstrate compliance during your assessment and ensure that your payment pages remain secure against evolving threats.

Popular

Navigating the Latest PCI DSS Updates: Addressing Requirements 6.4.3 and 11.6.1 for Client-Side Security

5 min read –The release of PCI DSS v4.0 has introduced significant updates to address emerging threats in the payment ecosystem, particularly...

Now is the Time for Organizations to Adopt the Future-Dated Requirements of PCI DSS v4.x

5 min read –The landscape of payment security continues to evolve, and organizations handling cardholder data must stay ahead of the curve...

Secure Customer Authentication: How Not to Do It

5 min read –In today’s digital-first world, secure customer authentication (SCA) is critical for protecting data and meeting regulatory requirements, such as PSD2. While SCA...

Related articles

Navigating the Latest PCI DSS Updates: Addressing Requirements 6.4.3 and 11.6.1 for Client-Side Security

5 min read –The release of PCI DSS v4.0 has introduced significant updates to address emerging threats in the payment ecosystem, particularly...

Now is the Time for Organizations to Adopt the Future-Dated Requirements of PCI DSS v4.x

5 min read –The landscape of payment security continues to evolve, and organizations handling cardholder data must stay ahead of the curve...

Secure Customer Authentication: How Not to Do It

5 min read –In today’s digital-first world, secure customer authentication (SCA) is critical for protecting data and meeting regulatory requirements, such as PSD2. While SCA...

Your advisor is ready to help now.

Your details