In part one of our series on PCI DSS 4.0, we covered the updates in the latest version 4.0.1 and how to operationalize those changes. In this blog we are going to dig deeper into Requirement 11.6, how to interpret the nuance and automate the current guidance. Guidance that will become a mandate in March, 2025.
Let’s start with what Requirement 11.6 is and why it’s so important.
The intention of requirement 11.6.1 is to prevent and detect unexpected script activities withs techniques such as those described, but not limited to, examples of mechanisms that detect and report on changes to the headers and content of the payment page.
This requirement specifically stipulates the need for organizations handling sensitive customer payment information to implement techniques such as a Content Security Policy (CSP) and the mitigating controls to protect against unauthorized changes to these pages. Many organizations have created or are in the process of creating a CSP. However, without the mitigating controls it isn’t enough, as it won’t effectively meet the standard. 11.6 is a critical component of the PCI DSS because it addresses the complexities of the current, modern attack surface. More often than not, pages are “assembled” from various objects and other content not found in a single place at the time the page is rendered. Monitoring those pages for unauthorized changes at runtime is central to this Requirement, but that’s not where the Requirement ends. The devil, as they say, is in the details.
And 11.6 Good Guidance gets into the specific details about how to operationalize a CSP.
(Implement) mechanisms that detect and report on changes to the headers and content of the payment page could include, but are not limited to, a combination of the following techniques:
• Violations of the Content Security Policy (CSP) can be reported to the entity using the report-to or report-uri CSP directives.
• Changes to the CSP itself can indicate tampering.
• External monitoring by systems that request and analyze the received web pages (also known as synthetic user monitoring) can detect changes to JavaScript in payment pages and alert personnel.
• Embedding tamper-resistant, tamper-detection script in the payment page can alert and block when malicious script behavior is detected.
• Reverse proxies and Content Delivery Networks can detect changes in scripts and alert personnel.
The above list of mechanisms is not exhaustive, and the use of any one mechanism is not necessarily a full detection and reporting mechanism. Often, these mechanisms are subscription or cloud based, but can also be based on custom and bespoke solutions.
Beyond monitoring and reporting, organizations are being asked to detect and prevent tampering and block malicious script behavior as it is happening at runtime on the payment page. That’s a subtle nuance worth noting. For most organizations, attempting to create in-house tools for monitoring script and page activity might be possible depending on the number of scripts and pages they are expected to monitor, but creating tamper detection and unauthorized activity blocking adds a degree of complexity that’s impractical at best.
This is where Feroot can help. Leveraging our platform allows you to easily monitor, detect, prevent and report in accordance with Requirement 11.6 and make sure unauthorized changes on payment pages are detected and responded to. Feroot’s Domain Guard assists with violation of CSP; Inspector provides external monitoring of systems that request and analyze web pages and Page Guard provides tamper detection and blocking on native and embedded pages.
Don’t wait until it’s too late. Per the PCI DSS guidance, these suggested requirements and associated techniques are “a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.”
Find out how you can quickly automate compliance with PCI DSS 11.6. Get Free Assessment
