PCI 11.6.1: Strengthening Payment Page Security

This blog post aims to explore the complexities of PCI 11.6.1, its implications for cybersecurity teams, and how businesses can bolster their security strategy to meet this new guidance.

The Payment Card Industry Data Security Standard (PCI DSS) is a collection of security standards. These standards are designed to ensure that all businesses accepting, processing, storing, or transmitting credit card information maintain a secure environment. The recent introduction of PCI DSS v4.0 has brought new guidelines around client-side security, specifically PCI 6.4.3 and PCI 11.6.1. This blog post aims to explore the complexities of PCI 11.6.1, its implications for cybersecurity teams, and how businesses can bolster their security strategy to meet this new guidance.

Table of Contents

PCI 11.6.1 and Its Significance

PCI DSS v4 Requirement 11.6.1 is a part of the PCI DSS that focuses on detecting and responding to unauthorised changes on payment pages. The objective of this requirement is to ensure that e-commerce skimming code or techniques cannot be added to payment pages as received by the consumer browser without a timely alert being generated. Similarly, anti-skimming measures cannot be removed from payment pages without a prompt alert being generated.

The requirement stipulates that a change- and tamper-detection mechanism should be deployed to alert personnel to unauthorised modifications to the HTTP headers and the contents of payment pages as received by the consumer browser. This mechanism should be configured to evaluate the received HTTP header and payment page at least once every seven days or periodically, based on the entity's targeted risk analysis.

The significance of PCI 11.6.1 lies in its focus on proactive detection and response to potential security threats. It mandates that businesses must be alerted when a change has been made to their script, emphasising the need for technology and resources that can provide these timely alerts.

Many web pages now rely on assembling objects, including active content (primarily JavaScript), from multiple internet locations. Additionally, the content of many web pages is defined using content management and tag management systems that may not be possible to monitor using traditional change detection mechanisms. Therefore, the only place to detect changes or indicators of malicious activity is in the consumer browser as the page is constructed and all JavaScript interpreted.

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 unauthorised changes that may indicate a skimming attack. Additionally, by looking for known indicators of compromise and script elements or behaviour typical of skimmers, suspicious alerts can be raised.

Mechanisms that detect and report on changes to the headers and content of the payment page include but are not limited to:

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 analyse 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 behaviour is detected.
Reverse proxies and Content Delivery Networks can detect changes in scripts and alert personnel.

Often, these mechanisms are subscription or cloud-based, but can also be based on custom and bespoke solutions.

The intention of this requirement is not that an entity installs software in the systems or browsers of its consumers, but rather that the entity uses techniques to prevent and detect unexpected script activities.

The Financial Implications of Ignoring Alerts

Overlooking alerts can lead to significant financial repercussions. With websites processing thousands of payment cards daily, the difference between responding to an alert immediately and waiting for a week can translate into thousands or even millions of dollars in primary and secondary costs.

For instance, Meta Platforms Inc., the parent company of Facebook, was fined $1.3 billion for failing to monitor their PII effectively.

Moreover, the cost of a data breach is not just limited to fines. It can also include the cost of remediation, potential loss of business due to reputational damage, and the cost of providing credit monitoring services for affected customers.

Therefore, it is crucial for businesses to have robust systems in place to monitor their data and respond to alerts promptly. This can help prevent data breaches, protect customer information, and avoid the significant costs associated with a data breach.

Solutions for Compliance with PCI DSS 11.6.1

Compliance with PCI DSS v4 Requirement 11.6.1 requires a proactive approach to detecting and responding to unauthorized changes on payment pages. Here are some solutions that can be implemented to ensure compliance:

Implementing a Content Security Policy (CSP) is an effective way to prevent various types of attacks, including Cross-Site Scripting (XSS) and data injection attacks. Here's a step-by-step guide on how to implement a CSP:

Understand Your Website's Resources: Before you can implement a CSP, you need to understand what resources your website uses and where they come from. This includes scripts, images, stylesheets, fonts, frames, and more.
Create Your Policy: A CSP is defined through the Content-Security-Policy HTTP header. This header is composed of one or more directives, each of which controls the source of a specific type of resource. For example, the script-src directive controls the sources from which scripts can be loaded. A basic policy might look like this:<code> Content-Security-Policy: script-src 'self'; object-src 'none'; base-uri 'self'; </code>In this policy:
- script-src 'self' allows scripts to be loaded from the same origin as the page.
- object-src 'none' disallows the loading of plugins (like Flash).
- base-uri 'self' restricts the URLs which can be used in a document's <base> element.
Test Your Policy: Before deploying your policy, you should test it to ensure it doesn't break your website. You can do this by using the Content-Security-Policy-Report-Only header, which will log policy violations in the console but won't actually enforce the policy.
Deploy Your Policy: Once you're confident your policy is correct, you can deploy it by adding the Content-Security-Policy header to your server's responses. The exact method for doing this depends on your server software. For example, in Apache, you might add this line to your configuration:Header set Content-Security-Policy "script-src 'self'; object-src 'none'; base-uri 'self';"
Monitor and Refine Your Policy: After deploying your policy, you should continue to monitor for violations and refine your policy as necessary. You can use the report-uri or report-to directive to send violation reports to a specified URI.

Remember, implementing a CSP can be complex, especially for large websites, and it may not be suitable for all sites. It's important to thoroughly test your policy to ensure it doesn't break legitimate functionality.

Use Synthetic User Monitoring Systems

Synthetic User Monitoring (SUM) is a method of monitoring your website or application by simulating user behaviour. It's a proactive approach that allows you to identify potential issues before they impact your real users. Here's how you can use Synthetic User Monitoring systems:

Choose a Synthetic User Monitoring Tool: There are many SUM tools available on the market. Some popular options include Dynatrace, Pingdom, Uptrends, and AppDynamics. These tools offer a range of features, including uptime monitoring, transaction monitoring, and page speed monitoring.
Define User Journeys: Identify the critical paths or user journeys on your website or application. These could be actions like logging in, adding an item to a cart, or completing a purchase.
Create Synthetic Tests: Using your chosen tool, create synthetic tests that mimic these user journeys. This usually involves defining the steps that the synthetic user should take, such as clicking on a button or filling out a form.
Run and Schedule Tests: Run your synthetic tests to ensure they're working correctly. Most tools will allow you to schedule tests to run at regular intervals, ensuring continuous monitoring.
Analyze the Results: After the tests have run, analyze the results. You'll be able to see metrics like response time, load time, and error rate. This can help you identify any performance issues or errors that need to be addressed.
Set Up Alerts: Most SUM tools will allow you to set up alerts based on your synthetic tests. For example, you could set up an alert to be triggered if a test fails or if the response time exceeds a certain threshold. This allows you to respond quickly to any issues.

For example, with Dynatrace, you can create a synthetic monitor that checks your website's availability from different locations around the world. You can define the frequency of these checks and set up alerts to be notified if your website becomes unavailable.

With Pingdom, you can create a transaction monitor that simulates a user completing a purchase on your website. This monitor can check that all parts of the process, from adding an item to the cart to entering payment information, are working correctly.

Remember, Synthetic User Monitoring is a proactive approach to monitoring. It allows you to identify and fix issues before they impact your real users. However, it should be used in conjunction with other monitoring methods, such as Real User Monitoring (RUM), for a comprehensive view of your website or application's performance.

Embed Tamper-Resistant, Tamper-Detection Scripts

Embedding tamper-resistant, tamper-detection scripts in your web pages is an effective way to enhance the security of your website. These scripts can detect and alert you to any unauthorized modifications to your web pages. Here's a step-by-step guide on how to implement this:

Understand Your Web Page Structure: Before you can implement a tamper-detection script, you need to understand the structure of your web pages. This includes understanding where scripts are loaded from and what they do.
Create a Tamper-Detection Script: A tamper-detection script is a piece of JavaScript code that checks the integrity of your web pages. This could be as simple as a script that calculates a hash of your page's HTML and compares it to a known good hash. If the hashes don't match, the script can alert you to the tampering.Here's a simple example of what a tamper-detection script might look like:var pageHash = 'known-good-hash'; var currentHash = calculateHash(document.documentElement.outerHTML); if (pageHash !== currentHash) { alert('Page has been tampered with!'); }In this example, calculateHash would be a function that calculates a hash of a string, and 'known-good-hash' would be the hash of the page's HTML when it's known to be good.
Embed the Script in Your Web Page: Once you've created your tamper-detection script, you need to embed it in your web page. This is usually done by adding a <script> tag to your HTML. The script should be loaded as early as possible, ideally in the <head> of your document, to detect tampering as soon as possible.
Test Your Script: After embedding your script, you should test it to ensure it works correctly. This could involve manually tampering with your page to see if the script correctly detects the changes.
Monitor Alerts: Once your script is live, you need to monitor the alerts it generates. This could be as simple as checking for alert messages, or you could set up a more sophisticated alerting system that sends you an email or text message when tampering is detected.

Remember, while tamper-detection scripts can enhance your website's security, they are not a silver bullet. They should be used as part of a broader security strategy that includes server-side security measures and regular security audits.

Utilise Reverse Proxies and Content Delivery Networks (CDNs)

Reverse proxies and Content Delivery Networks (CDNs) are powerful tools for enhancing the performance and security of your website. Here's how you can utilise them:

Reverse Proxies

A reverse proxy is a server that sits between client devices and your web server, forwarding client requests to the web server and returning the server's responses back to the clients. Here's how to use a reverse proxy:

Choose a Reverse Proxy Software: There are many reverse proxy software options available, including Nginx, Apache HTTP Server with mod_proxy, and Microsoft's Internet Information Services (IIS).
Configure the Reverse Proxy: The configuration process varies depending on the software you choose. Generally, you'll need to specify the IP address and port of your web server, and configure the reverse proxy to listen on the appropriate IP address and port.
Test the Reverse Proxy: After configuring the reverse proxy, test it to ensure it's correctly forwarding requests to your web server and returning responses to clients.
Monitor the Reverse Proxy: Once your reverse proxy is live, monitor it to ensure it's operating correctly and to keep an eye on its performance.

Content Delivery Networks (CDNs)

A CDN is a network of servers distributed across various locations around the world. When a user requests a resource (like an image or a script), the CDN delivers the resource from the server closest to the user, improving the speed of the delivery. Here's how to use a CDN:

Choose a CDN Provider: There are many CDN providers available, including Akamai, Cloudflare, and Amazon CloudFront.
Upload Your Resources to the CDN: The process for this varies depending on the provider, but generally, you'll need to upload your static resources (like images, stylesheets, and scripts) to the CDN.
Update Your Web Pages: Replace the URLs of your resources in your web pages with the URLs provided by the CDN. This will direct requests for these resources to the CDN instead of your web server.
Test the CDN: After updating your web pages, test them to ensure the CDN is correctly delivering your resources.
Monitor the CDN: Once your CDN is live, monitor it to ensure it's operating correctly and to keep an eye on its performance.

Remember, while reverse proxies and CDNs can greatly enhance your website's performance and security, they should be used as part of a broader strategy that includes other security measures.

Regularly Conduct Risk Analysis

PCI 11.6.1 requires the mechanism to function at least once every seven days or periodically, based on the entity's targeted risk analysis. Regular risk analysis can help identify potential vulnerabilities and threats, allowing you to take proactive measures to enhance your security.

Invest in Client-Side Security Tools

Invest in client-side security tools that offer prevention-first, client-side web application security.

Client-side security tools are designed to protect the client-side of web applications, which includes the web browser and associated software. Here are a few examples of such tools and how to use them:

Source Defense: Source Defense provides real-time threat protection and visibility for client-side web application security. To use it, you would need to sign up for their service, install their agent on your server, and configure the settings according to your needs. The platform will then monitor your website for any client-side threats and alert you in real-time if any are detected.
Snyk: Snyk is a developer-first security tool that helps to find and fix vulnerabilities in open source libraries and containers. To use Snyk, you would need to install their CLI tool, integrate it with your code repository, and then run scans to identify any vulnerabilities. Snyk will then provide recommendations on how to fix these vulnerabilities.
Jscrambler: provides JavaScript application security, protecting web applications against reverse engineering and tampering. To use Jscrambler, you would need to sign up for their service, integrate their tool into your build process, and then configure the protection settings. Jscrambler will then obfuscate and protect your JavaScript code, making it difficult for attackers to reverse engineer or tamper with it.
Akamai Page Integrity Manager: is a client-side security solution that detects and mitigates JavaScript threats in real-time, including Magecart and other digital skimming attacks. To use it, you would need to sign up for Akamai's service, install their JavaScript agent on your web pages, and then configure the settings according to your needs. The agent will then monitor your web pages for any JavaScript threats and alert you in real-time if any are detected.
Human Security Code Defender is a client-side application security solution that protects against digital skimming and formjacking attacks. To use Code Defender, you would need to sign up for their service, install their JavaScript sensor on your web pages, and then configure the settings according to your needs. The sensor will then monitor your web pages for any digital skimming or formjacking attacks and alert you in real-time if any are detected.

Remember, the choice of a client-side security tool will depend on your specific needs, the nature of your web applications, and the threats you are most concerned about. It's important to thoroughly evaluate any tool before implementing it to ensure it aligns with your security strategy.