PCI DSS 11.6.1: A Guide to Compliance and Vulnerability Management

PCI DSS 11.6.1 requires regular vulnerability scans to be performed on all system components, including network devices, servers, and applications.

These scans should be conducted at least quarterly, or more frequently if there are changes to the environment.

The scans should be performed by a qualified security professional using a tool that is compliant with the PCI DSS requirements.

The results of the scans should be reviewed and remediated within a specified timeframe, which is typically 30 days.

Regular vulnerability scans help identify and address potential security threats before they can be exploited by attackers.

The PCI DSS approach for examining compliance with section 11.6.1 is straightforward, involving the thorough examination of system settings, payment pages, and monitoring logs to ensure a change and tamper detection mechanism is deployed.

This mechanism must be set up compliantly and evaluate the received HTTP header and payment page, with businesses required to check it weekly or complete a risk assessment to determine a safe frequency of checks.

Entities are only responsible for scripts loaded into the page that hosts the iframe, not for any scripts that are loaded in the iframe, and the Payment Processor / PSP is responsible for all scripts loaded in the iFrame.

The customized approach to meeting requirements introduced in PCI DSS v4.0 allows for the use of innovative technologies and methods to meet a control objective, even if they deviate from the predefined requirement approach.

A change- and tamper-detection mechanism should be deployed to alert personnel to unauthorized modifications to the HTTP headers and the contents of payment pages as received by the consumer browser.

Entities must be alerted when a change has been made to their script, and technology and resources that can provide these timely alerts are emphasized.

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

PCI significance lies in its focus on proactive detection and response to potential security threats. This is a game-changer for businesses, as it emphasizes the need for timely alerts when a change has been made to their script.

The requirement stipulates that a change- and tamper-detection mechanism should be deployed to alert personnel to unauthorized 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 is not just about detecting changes, but also about preventing and detecting unexpected script activities. This is crucial in today's e-commerce landscape, where many web pages rely on assembling objects from multiple internet locations.

Here are some examples of mechanisms that detect and report on changes to the headers and content of the payment page:

Compliance Requirements are in place to ensure the security of payment pages and prevent unauthorized changes. PCI DSS v4 Requirement 11.6.1 requires a change- and tamper-detection mechanism to be deployed to alert personnel to unauthorized 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 goal is to detect and respond to potential security threats proactively.

To comply with PCI DSS 11.6.1, system settings, all payment pages, and monitoring logs must be thoroughly examined to ensure there is a change and tamper detection mechanism deployed. 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.

Businesses must either perform the checks weekly or 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.

The following are some mechanisms that detect and report on changes to the headers and content of the payment page:

Note that the entity is not required to install software in the systems or browsers of its consumers, but rather to use techniques to prevent and detect unexpected script activities.

The updated guidance for compliance requirements is a welcome change. It now explains why checking the HTTP headers is useful in detecting a skimming attack, which is a crucial aspect of PCI-DSS 11.6.1 compliance.

The guidance also mirrors the good practice in 6.4.3, which requires the Payment Processor to provide evidence that they are meeting this requirement for a payment page in an iframe. This ensures that all parties involved are on the same page.

A notable change is that the list of examples given is not the only way of potentially meeting the requirement. This means that businesses have more flexibility in how they choose to implement the necessary controls.

Businesses can now use a combination of approaches or tools to meet the requirement, which is a more practical and effective way of ensuring compliance. Jscrambler's Webpage Integrity, for example, is sufficient to meet 6.4.3 and 11.6.1 on its own.

Here are some of the key points to keep in mind:

Vulnerability management is a critical aspect of maintaining a secure environment, and PCI DSS 4.0 emphasizes the importance of regular scans to identify potential vulnerabilities.

External vulnerability scans must be performed by an Authorized Scanning Vendor (ASV), and internal scans must be authenticated to ensure accuracy.

Scan frequencies should be based on targeted risk analysis, not a one-size-fits-all approach, to allocate resources efficiently.

The PCI DSS has clarified what constitutes a security-affecting change, which is a crucial aspect of vulnerability management.

Only changes that can affect the security of cardholder data need to be monitored, which is a more nuanced approach than previously thought.

The original requirement was to detect unauthorized changes to the HTTP headers and the contents of payment pages as received by the consumer browser.

This has been changed to "the security-impacting HTTP headers and the script contents of payment pages as received by the consumer browser."

This change reflects how most entities were interpreting the requirements, and it's a welcome clarification in the world of vulnerability management.

Here's a breakdown of the key changes:

By focusing on security-affecting changes, organizations can prioritize their vulnerability management efforts and allocate resources more effectively.

Vulnerability management is crucial for any organization, and PCI DSS 4.0 has introduced new requirements to ensure it's done correctly. External vulnerability scans must be performed by an Authorized Scanning Vendor (ASV).

Internal scans must be authenticated, which means they need to verify the identity of the systems being scanned. This adds an extra layer of security to prevent unauthorized access.

Scan frequencies must be based on targeted risk analysis, so you don't waste resources scanning systems that are low-risk. This approach helps you focus on the areas that need the most attention.

By following these requirements, you can ensure that your vulnerability management process is robust and effective.

Compliance checks for PCI DSS 11.6.1 are a straightforward process.

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

This mechanism must be set up compliantly and evaluate the received HTTP header and payment page.

Businesses are required to either perform these checks weekly or complete a risk assessment to determine 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.

In fact, PCI DSS v4.0 introduces a 'Customized Approach' to meeting requirements, which allows businesses to use innovative technologies and methods to meet a control objective, even if they deviate from the predefined requirement approach.

For section 11.6.1, the customized approach focuses on preventing e-commerce skimming code or techniques from being added to payment pages without generating a timely alert.

Compliance checks for PCI-DSS 11.6.1 are straightforward, involving the examination of system settings, payment pages, and monitoring logs to ensure a change and tamper detection mechanism is deployed.

This mechanism must be set up compliantly to evaluate the received HTTP header and payment page, and configuration settings will be checked to ensure this is the case.

Businesses are required to perform checks at a frequency that is either weekly or based on a risk assessment, which will be analyzed and verified as part of an audit.

A 'Customized Approach' is also introduced in PCI DSS v4.0, allowing for the use of innovative technologies and methods to meet control objectives, even if they deviate from the predefined requirement approach.

To ensure compliance with PCI DSS 11.6.1, a proactive approach to detecting and responding to unauthorized changes on payment pages is required.

Implementing a Content Security Policy (CSP) is a solution that can be used to ensure compliance, but it can be complex, especially for large websites, and may not be suitable for all sites.

Merchants now often don't create their own payment forms, but instead load a Payment Processor/PSP's form into an iFrame.

This means they don't store, process or transmit cardholder data, but they can still affect the security of the payment card data by controlling the loading of the iframe.

The first clarification in the Applicability Notes aims to reduce the risk of attacks against the iframe such as overlay or hijacking attacks.

The requirement now applies to scripts in the entity's webpage(s) that includes a TPSP's/payment processor's embedded payment page/form.

This extension of the requirement was previously included in SAQ A, but it's now part of the standard, making it clear and closing a loophole.

The clarification also makes it clear that merchants are responsible for scripts loaded into the page that hosts the iframe, also known as the Parent Page.

Here's a summary of the responsibility for scripts in an iframe:

It's worth noting that this clarification only applies when the PSP's payment page is loaded in a cross-origin origin iframe.

In cases where the PSP's iframe is created in the same origin as the merchant's parent page, the merchant should have responsibility for scripts loaded in both the parent page and the payment page in the iframe.