PCI DSS v4.0.1 was recently released to clarify the requirements of v4. What it means for you is that v4 is being retired on 31/12/24, the date you should have complied by, but you must comply with V4.0.1 by the 31st of March 2025. You have an extra three months to get your house in order.
PCI DSS v4.0.1 was recently released to clarify the requirements of v4. What it means for you is that v4 is being retired on 31/12/24, the date you should have complied by, but you must comply with V4.0.1 by the 31st of March 2025. In effect it has given organisations an extra three months to get their house in order.
Primarily it is a requirement to have your development team trained at least annually, and in the case of the new release to V4.0.1 to have ensured that your team is aware of the distinct security requirements of the new standard and have started work to confirm they are in place in your software and websites. You can, of course, call us to organise a 1-day training session to both comply with the training requirement, and see and practice the ways to defend against attacks!
There are many specific instructions in V4 including Requirement 6.4.3 which requires that "a method is implemented to confirm that each script is authorised" on Payment Pages. As an example, you may be including a JavaScript library from an external Content Delivery network (CDN) source. Don’t think that only having internal CDNs is safe though. In fact, any repository you access, anywhere, is inherently vulnerable.
This is because, in many cases, whilst the security of the system the files reside on has been taken care of, the integrity of the file also must be checked, and for many developers, this is not something that has ever been considered. Indeed, the perimeter security mentality, ‘no-one will ever be able to tamper with those files’, which is still prevalent in engineering teams, would seem to protect the application. However, anybody tampering with the JavaScript codebase or replacing it with infected code, if the integrity is not established or checked, would immediately have access to the application at the permission level of the executing code, typically elevated.
There are several ways to address the security of included scripts, whether JavaScript, CSS or JSON. Using a Content Security Policy (CSP) for the website is one approach. This is also an excellent approach for testing as the CSP Header has a report only option, ‘Content-Security-Policy-Report-Only’, which allows for testing on a live site. It assists the developers in seeing what libraries are currently being included and which endpoints they are coming from. When that intelligence is collated and analysed, action can be taken to restrict access to the website for those scripts only. In this way it would not be possible for an attacker to inject scripts which are not expected.
It is also important to know that the library that is being used by the website has not been tampered with. This can be done by hashing the library and storing the expected hash information in the CSP. When the library is imported from the CDN it is hashed, and that hash is compared to the stored hash. If they are the same it is likely that the library has not been changed, as the avalanche effect would significantly change the new hash if even only a single character has been changed in the imported library. Here’s an example illustrating the use of the integrity tag option.
There is even a more significant protection for imported libraries. Generating a nonce ("number used once" or "number once" aka "cryptographic nonce") for the file ensures that the library can be trusted. A nonce is a random number used only once that you can use to mark a <script> tag as trusted. The nonce has to be generated on each call to load the library and there are many ways to generate the nonce. It can be done in JavaScript for example, and Cloudflare has support for nonce generation using Cloudflare workers.
In this instance a nonce is injected into the page header and is matched up with the nonce in the page. If they are both the same, we’re good to go. Here’s an example of a nonce in the CSP as used on the https://bbc.com website:
default-src 'none'; script-src 'strict-dynamic' 'nonce-IbaKY28Spn4Gmok23WibvVVrJC73Er9WcNhpnqXm9qaCwf27P7'
To check your own websites, you can use https://securityheaders.com which will analyse the output and report how secure your sites are. Most of the requirements around injected code security are client side based, integrated into the browser. 10 years ago we would have said that there is no such thing as client side security, but these days, the browser development community is integrating useful tooling to help our teams achieve compliancy.
The above requirement is only one of the many skillsets that your software engineering teams need to acquire to be able to ensure your PCI DSS compliancy. V4.0.1 doesn’t add any new requirements to the V4 document. It simply clarifies some of the areas of PCI DSS following feedback from the user community.
It can be a challenge to make PCI DSS training interesting. Many of the training opportunities available to organisations are watch, listen, learn trainings. Here at Framework Training, we try to ensure that from the moment we get going the delegates are getting hands on with the technology solutions. Our PCI DSS training can be attended by the full range of software engineering and security team members, including non-hands-on technical roles like project managers, testers and some security team staff from the red and blue teams. This is because we use examples that can be completed and understood by everyone attending. Our environment is prebuilt and can be run either face to face or online.
Your team members should be able to evaluate your current systems, processes, and policies to identify gaps and areas for improvement. They should be able to maintain compliance, but this can only be achieved if the knowledge has been acquired. These are sections 2 and 10 in the PCI DSS standard and the focus of our knowledge transfer trainings..
Have a look at our range of courses on PCI DSS:
