PCI-DSS change and tamper mechanism

Ever since v4 of PCI-DSS has hit the web, we’ve been talking to customers about how they can ensure they remain compliant with the upcoming changes. One regulation in particular which is gaining a lot of attention is 11.6.1 – the requirement to deploy what’s called a “change and tamper detection mechanism” on your payment pages. In this article, we will look at what the changes are, what they mean for your business, and how you can ensure you remain compliant.

What does the new regulation say, exactly?

Unlike some of the other updates, 11.6.1 is a totally new regulation, which means it hasn’t been changed or updated from a previous version, it’s a new addition which you need to be compliant with by 2025, under 11.6, which is the regulation that any unauthorized changes on payment pages need to be detected and alerted to.

The wording of the PCI-DSS is as follows:

11.6.1 New requirement to deploy a change-and-tamper detection mechanism to alert for unauthorized modifications to the HTTP headers and contents of payment pages as received by the consumer browser.

The PCI DSS update that “By comparing the current version of the HTTP header and the active content of payment pages as received by the consumer browser with prior or known versions, it is possible to detect unauthorized changes that may indicate a skimming attack. Additionally, by looking for known indicators of compromise and script elements or behavior typical of skimmers, suspicious alerts can be raised.”

What is the point of this new regulation?

There is a very clear objective behind this updated PCI-DSS regulation – to protect against code injection and web skimming attacks. Attackers add skimming code to payment pages to steal data directly from your customers. Sometimes threat actors will even remove anti-web skimming measures, all without you ever knowing changes have occured. With this new requirement, any changes to the code of a payment page will trigger an alert. This means you immediately know about modifications, additions, deletions or Indicators of Compromise (IoC). By monitoring for script changes on the client side, often outside of the remit of today’s security tools – businesses can better stay on top of this behavior.

This is how the PCI-DSS compliance check will be undertaken:

11.6.1a: System settings, all payment pages, and monitoring logs will be thoroughly examined to ensure there is a change and tamper detection mechanism deployed.

11.6.1b: Configuration settings will be checked to ensure the mechanism has been set up compliantly and that it evaluates the received HTTP header and payment page.

11.6.1.c: Businesses are required to either perform the checks weekly, or to complete a risk assessment to ascertain a safe frequency of checks. An audit will include an analysis of this risk assessment, and verification that the requirement is performed at the necessary frequency.

What is “tamper and detection”?

Web-skimming is an attack method that targets sensitive areas of a website like the checkout page, in order to collect user data. The attack is usually created by client side attacks that tampers with existing components of a website. For example, the attack will tamper with the checkout form, changing the destination of the form to the attacker’s domain instead of the payment gateway domain.

The tampering options are extremely varied, from changing the domain to creating a completely new object on top of the previous one; the imaginations of today’s attackers are unlimited. But one thing would usually be constant, a new behavior will be added that did not exist in the site in the past. This is the very core of the new regulation requirement. Monitor the page so that you know what is supposed to be running on the page, and then allow or whitelist the common and expected behavior so that you can then detect and flag changes. These changes need to be identified either in the headers, in the form, or even in the components.

It is tricky, as there are many legitimate changes that need to be allowed on any single page, so smart detection mechanism needs to avoid false-positives and will require an in-depth analysis of the scripts that are already on the page and their actions. For example, comparing hashes won’t help at all.

How are companies mitigating this risk right now?

The PCI-DSS regulation update gives some examples of how organizations can adhere to this new requirement. In many cases, businesses will rely on Content Security Policies. Any changes to a CSP could indicate that tampering has occurred to the website payment pages.

Other options are to use a third-party system that requests the data from specific web pages, before analyzing the data. These systems use synthetic user monitoring to detect any changes to the JavaScript code on website payment pages. Some businesses will comply with this regulation by using a tamper-detection script on the payment page, which searches for malicious script behavior and sends an alert. A reverse proxy or a CDN (content delivery network) can act similarly, detecting any changes that happen to scripts and then sending a notification to security teams in real-time.

The challenges of this new PCI-DSS requirement

For today’s organizations, the real challenge will be managing the behavior of third-party digital web applications who need a certain amount of control over their activities on your website. Think about the social media widgets which need to update dynamically, analytics trackers which provide insight on performance, the payment processing tools that help you with your chosen business model, or adverts and pop ups that act as an additional revenue stream.

Blocking or alerting to changes to these scripts would be an added overhead at best, and a business nightmare at worst. However, whitelisting their behavior leaves you open to risk, and won’t cover you against these new compliance rules.

Instead, what you need is full visibility into what third-party applications are doing, and the control to set granular rules for what is allowed and what is not. With Reflectiz, that’s exactly what you get. View a full list of all third- and fourth-party applications running on your website, and choose the behaviors that are given the green light, those which should send security teams a notification, and those that should be blocked outright. Understand in full what these applications are doing with your user data, where it’s being sent, and why.

When audit time rolls around, you have a continuous change and tamper detection mechanism (much better than every seven days) which is monitoring not only payment pages, but your whole website across the whole user journey.

See how it works for yourself by scheduling a demo of the Reflectiz solution.