How to detect client-side tampering: baselines, monitoring, alerting and evidence

Start with a baseline

Change can only be seen against something. A baseline is a record of the known-good state of each payment page, taken after you have reviewed and approved what it contains. It should include:

• every script, by address and a fingerprint of its content, and every inline script by a hash;
• the page's own content that matters for payment, such as the forms, their fields and where they submit to;
• embedded frames and their sources;
• the HTTP security headers, especially the Content Security Policy (see HTTP security headers for payment pages);
• the third-party domains the page contacts.

The baseline is only as good as the review behind it. Building it from a script inventory that people have approved means the baseline already carries the decisions.

What counts as a change worth an alert

• A script that is new, removed or whose content has changed.
• A script that now comes from a different address, or loads something new.
• A form that gains a field or submits somewhere else.
• A security header that is missing, weakened or different, or a policy that now allows a new source.
• A new third-party domain contacted by the page.

Not every difference is an attack. Releases, vendor updates and marketing changes all alter pages. The way to keep alerts meaningful is to tie detection to approval: a change that matches an approved change request is expected; one that does not is investigated. That is the pairing of 6.4.3 and 11.6.1.

Where to look from: what the customer receives

Requirement 11.6.1 speaks of pages and headers as received by the consumer's browser. The ways to observe that include:

• Synthetic monitoring with a real browser. A browser outside your network walks the payment flow, including steps behind a login, and records what it receives. It is independent of your servers and sees what a customer's browser would run, but sees only what its own visit triggers.
• An embedded reporting script. It reports from real visitors' browsers, but runs in the same place an attacker's script does and can be altered or disabled by one.
• A reverse proxy or CDN feature. It sees traffic passing through, but not what scripts do inside the browser.
• Server-side file integrity monitoring. It catches changed files on your servers, but not changes made by third-party scripts or at runtime.

The approaches complement each other. Choose what suits your architecture, and be prepared to explain to your assessor how the combination covers the intent.

How often to check

PCI DSS 11.6.1 sets a floor: at least once every seven days, or at the frequency in your targeted risk analysis. A skimmer that runs for a week can take a lot of cards, so many organizations check daily or more often, particularly for pages with high volume. Match the frequency to your risk and document the reasoning. Also run a check immediately after any release, tag manager publish or vendor change.

Alerting and response

Make the alert actionable

An alert should say which page, what changed (before and after if possible), when it was first seen and from where, and whether it matches an approved change. Send it to named people through a channel they watch, and record who responded.

Decide in advance what happens next

1. Triage. Was the change approved? Compare it with change tickets and the tag manager's publish log.
2. Contain. If it was not, remove or disable the script or revert the change, and consider whether the payment page should stay up while you investigate.
3. Preserve evidence. Keep the page as received, the logs and the change history before they are overwritten.
4. Investigate the way in. Find how the change was made and close that route; see XSS and injected skimmer code.
5. Notify. Follow your incident response plan and contracts for telling your acquirer, the payment brands and others, and the law on breach notification.
6. Learn. Update the baseline, the inventory and the plan.

Evidence worth keeping

For an assessment you will want to show a process that ran through the period, not only the latest result. Keep the schedule or risk analysis, the baseline and its approvals, a history of each run, every alert and what was decided, and any incident records. Keep it at least for the assessment period, commonly twelve months, and confirm the retention your assessor expects.