As we help our customers with transitioning to PCI DSS 4, some immediate and future dated requirements are standing out for special attention, specifically:
- 6 – Code repositories used for custom code and configuration information
- 4.3 – Authorization of payment page scripts
- 6.1 – Change and tamper detection for payment pages, including scripts
Code Repositories and PCI DSS 4
One immediate change is that code repositories for custom code and for configuration information is now in scope for PCI DSS assessments. The overview for Requirement 6 (Develop and Maintain Secure Systems and Software) states the following, which makes it clear:
“Code repositories that store application code, system configurations, or other configuration data that can impact the security of account data or the CDE are in scope for PCI DSS assessments.”
Application code includes custom code developed and used in applications in the cardholder data environment. Configuration information may include infrastructure as code (IaC) using tools such as Terraform, Ansible or Puppet; this IaC is usually stored in repositories. Application or configuration code may be stored in GitHub, GitLab, Bitbucket some other cloud or self-hosted source code repository system.
As these are now in scope for PCI DSS assessments, you may need to request an Attestation of Compliance (AoC) from your cloud service provider (CSP) if the repositories are hosted by a CSP. You will need to check that the AoC covers the code repository services, and that the CSP has a responsibility matrix. You will still need to be compliant for requirements that you are responsible for. If your organisation self-hosts the code repository, you may want to look at how to limit scope when you bring the code repository and its supporting infrastructure into scope for assessment.
PCI DSS 4 Future Dated Requirements
Here are some of the future dated requirements that need some special attention. The deadline for these requirements is 31st March 2025, so Dionach recommend that organisations implement these as soon as possible.
6.4.3 - Payment Page Scripts are Authorized
Any scripts such as JavaScript files referenced and used in a payment page now need to be explicitly listed and authorized. A payment page is a web page with a form where account data is entered, or may be the web page hosting the iframe where account data is entered; this also applies to self-assessment questionnaire A (SAQ A) for ecommerce payments.
The guidance for 6.4.3 helps clarify the requirements. Each script referenced in the payment page or page hosting the iframe with the payment page must be inventoried, justified and authorized. To ensure the integrity of each script, the HTTP Content Security Policy (CSP) for
the page should restrict allowed sources of scripts; see the following link for more information on using a Content Security Policy:
https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP
Additionally, the integrity of scripts can be checked by including an integrity hash in the script HTML tag, using Subresource Integrity (SRI); see the following for more information on using Subresource Integrity:
https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity
There are tools and resources for some popular ecommerce platforms on adding CSP and SRI, such as WordPress and Magento.
11.6.1 - Unauthorized Changes on Payment Pages Are Detected and Responded To
This requirement to check or monitor payment pages for changes to payment pages is related to 6.4.3 for payment page script authorization. As with 6.4.3, a payment page is a web page with a form where account data is entered, or may be the web page hosting the iframe where account data is entered; this also applies to self-assessment questionnaire A (SAQ A) for ecommerce payments.
Changes to payment pages and any active content such as JavaScript must be monitored using a change and tamper detection mechanism. The mechanism must check the content, scripts and important HTTP headers that would be received by the client browser, and must check once a week or as determined by a targeted risk analysis (TRA).
The change and tamper detection mechanism must act like a browser and check the content as presented to the browser, looking for any changes to prior versions, including known signs of attacks (indicators of compromise), changes to JavaScript sources, HTTP CSP headers, and basic content. Any changes must alert personnel, and be included in the incident response plan as per requirement 12.10.5.
Examples of some services that provide web page and script monitoring can be found at https://cside.dev/compare. Note that Dionach do not endorse these and use of any of these does not guarantee PCI DSS compliance.
Summary
These are just a few of the new requirements in PCI DSS 4, so please ensure that you also implement the other requirements.
If you need any help with PCI DSS for SAQs, please contact Dionach. Some of the PCI DSS services we provide:
- PCI DSS scope review service, to help you reduce scope and work towards the best SAQ
- SAQ assistance, with PCI DSS assessment, prioritized approach, and SAQ completion
- Assessment for a Report on Compliance