Background
In March 2022, the Payment Card Industry Security Standards Council released a revised version of its Data Security Standard, commonly known as PCI DSS v4.0. In this revised version are two new sections, 6.4.3 and 11.6.1 which offer guidance regarding 3rd, 4th, and nth party JavaScript running on your websites.
Both of these requirements are quoted below, followed by an explanation of how Source Defense addresses and resolves them.
PCI DSS 4.0 - Section 6.4.3
All payment page scripts that are loaded and executed in the consumer’s browser are managed as follows:
• A method is implemented to confirm that each script is authorized.
• A method is implemented to assure the integrity of each script.
• An inventory of all scripts is maintained with written justification as to why each is necessary
How Source Defense addresses section 6.4.3
Source Defense provides a rich inventory management system to automatically track 3rd party scripts and 4th+ party scripts (shadow scripts) identified on payment pages and enter their written justification. This management system identifies any new scripts added, which can be leveraged to ensure authorization.
Source Defense also tracks script behavior and highlights behaviors recommended to review via the behavior acknowledgement menu; by leveraging the capability to review events and acknowledge behavior, it is easy to see if new behaviors are found, including rich data to facilitate further investigation if required, thereby ensuring the integrity of each script.
PCI DSS 4.0 - Section 11.6.1
Defined Approach Requirements
A change- and tamper-detection mechanism is deployed as follows:
• To alert personnel to unauthorized modification (including indicators of compromise, changes, additions, and deletions) to the HTTP headers and the contents of payment pages as received by the consumer browser.
• The mechanism is configured to evaluate the received HTTP header and payment page.
• The mechanism functions are performed as follows:
– At least once every seven days
OR
– Periodically (at the frequency defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1).
Examples
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 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.
Customized Approach Objective
The customized approach objective includes:
Anti-skimming measures cannot be removed from payment pages without a prompt alert being generated.
How Source Defense addresses section 11.6.1
Source Defense runs an external scan to identify unauthorized modification (including indicators of compromise, changes, additions, and deletions) to the HTTP web headers as received by the consumer browser. The solution includes a management system to facilitate the process and remove false positives.
Additionally, Source Defense will identify unauthorized modifications on the contents of payment pages as received by the consumer browser by tracking script behavior and alerting upon newly identified script behaviors. Click here for more information on how to track script behaviors. In addition to alerts, Source Defense also provides the capability to block scripts when malicious behavior is detected.
Source Defense generates in-app alerts as well as email and webhook alerts, if defined, in case there is a risk of being removed from the payment page due to lack of data receieved at the time interval defined.
Source Defense generates in-app alerts and email alerts — and, if a webhook is configured, sends webhook notifications — when data hasn’t been received within the defined interval, indicating a potential risk of removal from the payment page.