Tuesday, 7 March, 2023 UTC
Summary
PCI DSS 4.0 contains two new requirements designed to protect against (requirement 6.4.3) and detect (requirement 11.6.1) e-commerce skimming attacks. These two new requirements are a best practice until 01 April 2025, after which they become mandatory requirements.
It may seem a long time until April 2025, but organizations should start their planning today. To meet the requirements, organizations will need to select technical controls and adopt new management processes for how JavaScript is deployed. Depending on the size and complexity of the organization, these may not be simple tasks.
1. Understand the JavaScript that’s currently on payment pages
The PCI DSS requirements only apply to JavaScript on payment pages. The first task is to make an inventory of what JavaScript is currently on your payment page, and why it is there. You could do this by looking at the page source in your browser’s developer tools, or you can also request a free inventory report of all the scripts present on your website from Jscrambler.
The type of information you should collect for each JavaScript you find is:
- Name of the script and URL
- First or third party
- The purpose of the script - what’s the script for?
- Which team, department or person is the owner of each script (i.e. who decided that script should be on the page)
- Whether the script is necessary for the operation of the payment page
2. Understand how your organization manages JavaScript
The new requirement 6.4.3 requires all JavaScript on the payment page to be recorded in an inventory, be explicitly approved, and a record kept of why the script is necessary.
Before working out how you’ll meet this new requirement, it’s important to understand how JavaScript is added to your website now, because you may already have some business processes in place. The type of information you’re looking for is:
- Which teams, people or processes can add JavaScript to the site?
- Is there a change management or approval process for this?
- Does anyone validate the integrity of the script before it is added?
- If the script’s being loaded from a third party, is there any security assessment of the third party before the script is deployed?
- Is the deployment of a new script manual or automated?
- How does the process apply to scripts that change?
- Is the same JavaScript added to every page on the site or is it possible to separate out the scripts that are included in the payment page from those that are deployed everywhere else on the site?
3. Determine your new business process
One of the key decisions you’ll need to make is whether your change control process, business operations and risk tolerance will allow you to either:
- Approve all changes to JavaScript before they happen
or - Approve changes in a sensible window after they happen
This will determine the workflow and the technology that you deploy.
3.1 Pre-change approval
You’ll need a change control workflow that caters to:
- Adding (and removing) a new JavaScript to the payment page
- Changes to first-party JavaScript
- Changes to third-party JavaScript
That workflow will need to:
- Define who is allowed to add scripts to the payment page, and who is allowed to approve such an addition
- Record why it is necessary for the script to be on the payment page (and ideally this should be in relation to the behaviors of the script)
- Record the approval of the script (e.g. who, when)
- Record any integrity information about the script such as its behaviors and how that will continue to be verified
- Update the inventory
- Approve the new or modified script to be released to the production environment
- Interface with the manual or automatic release process
This could be implemented within an existing change-control process or with something like a spreadsheet to maintain the inventory and the information specified in the requirement.
An advantage with a strict pre-deployment approval process is that you will be able to use protective measures such as Content Security Policy (CSP) and Subresource Integrity (SRI). They are based on knowing the hash values of approved scripts, because the hash value will be able to be computed as part of the pre-deployment process.
But there are two operational problems with a pre-approval process. First, the larger and more complex an organization's e-commerce platform is, the more arduous the process. There’s a real danger that it won’t be followed because it becomes a roadblock in the development and deployment process. Second, if any script changes (say by a third party provider), then the script won’t be allowed to load and so the functionality of the page will be affected - in the worst case, breaking the entire site.
3.2 Post-change approval
In this model, it is still important to control who in your organization can add new JavaScript to the page and who can approve the script. This is particularly important because you’re effectively defining a time-window in which a script is allowed to be active on the payment page before it is approved.
The workflow needs to be triggered by an automated process that detects when:
- New JavaScript appears on the page
- An already approved JavaScript changes
The automated detection must generate an alert (which has the benefit of meeting new requirement 11.6.1) and initiate the post-change approval workflow which should:
- Record why it is necessary for the script to be on the payment page (and ideally this should be in relation to the behaviors in the script)
- Record the approval of the script (e.g. who, when)
- Record any integrity information about the script such as its behaviors and how that will continue to be verified
- Update the inventory
To meet the PCI DSS requirements, if a script doesn’t get approved within a specified time period then it should be blocked or removed from the payment page.
A post-approval process is appropriate for more complex environments and ones where an organization has multiple websites or instances of a site. This is especially important where the right to add JavaScript to a site is distributed throughout an organization.
It comes with some risk because unapproved changes will be live on the site for a limited time window which, if we extrapolate requirement 11.6.1, should be no longer than seven days. However it allows for scripts to change without the risk of the website breaking which will be especially important for third party scripts.
It is not possible to use CSP and SRI in a post-change approval model because these techniques rely on a hash of a script being generated before it is deployed. A tool such as Jscrambler’s Webpage Integrity would be the preferred choice because it is able to enforce the required workflow as soon as it detects (in real time) a new script being added to a page or a change in an already approved script.
Using Webpage Integrity also minimizes the risk associated with an unapproved script being live on the site while the approval process is being followed because Webpage Integrity can automatically block any malicious behavior such as a script accessing the payment card fields on the payment page.
Check more of Jscrambler's PCI DSS resources here.