It’s been a relatively long time since the Security Standard Council released its last update: The Payment Card Industry Data Security Standard (PCI DSS) v4.0.
Why is this?
Well, it takes organizations a great deal of time, resources and money to implement change, which often leads to projects overrunning and IT teams becoming stretched. For this reason, many organizations will turn to PCI Compliance management services to stay on top of regulations.
However, the PCI recently announced the publication of version 4.0 of the PCI DSS. This is a global standard that provides a baseline of technical and operational requirements designed to protect account data. Version 4.0 replaces version 3.2.1. It responds directly to emerging threats and technologies in the card payment space.
The updated standard includes 64 new requirements, 14 of which are documentation and policy-type changes. It has been available since March 2022 and organizations can choose to comply and attest to it immediately.
Version 3.2.1 is still live, but businesses must…
To make the transition from version 3.2.1 to PCI DSS v4.0 as smooth as possible, we’ve developed two key recommendations for your consideration.
1. Firstly, conduct a full assessment of your current scope. To implement the new changes effectively, we’d recommend reducing your scope in any way possible. Either look at adopting new payment methods or outsourcing certain processes to validated third parties. This way, you will only need to implement a selection of the new controls, which will save time, money, and resources.
2. Secondly, you could wait until you ‘have to’ implement these new controls to stay compliant, but we recommend you start the process as soon as possible. Give your team as much time as possible to avoid putting a strain on available resources and, more importantly, potentially avoiding fines for missing the PCI DSS deadline.
We’ve explored more of the PCI DSS v4.0 changes on our Where Are We Now blog, or head to PCI SSC’s list of v4.0 changes.
In recent years, criminal behavior has become more sophisticated, and, as a result, many countries, especially the USA, are adopting EuroPay, Mastercard, and Visa (EMV) technology. Criminals are moving away from stealing card data from physical point of sale (POS) terminals and turning their attention to ‘skimming’ data from e-commerce sites.
reviously, attacks were predominantly made inside systems and databases, and the advice from experts was to stop storing card data. Following this was a rise in RAM scraping attacks – an intrusion of the random access memory of retail sales terminals to gather card details prior to encryption. Businesses could counter these by using 3D-Secure authentication to verify cardholder details via their bank. Both methods of attack worked for a time, but it was also becoming easier for cyber criminals to be detected.
There has now been a shift to skimming card data from a user’s web browser while payment information is being entered. All a hacker needs to do is infiltrate the payment page and insert a few lines of javascript, and they will have full access to all of the individual’s information.
When the customer inputs their data, the javascript executes and takes a copy of the payment details. When the customer presses ‘submit,’ the information is sent to the merchant, and the order is complete. The customer still receives the service and/or the products they ordered, but what they don’t know is that their card details have also been sent to a criminal to be used elsewhere. Only when their bank statement arrives will they see what has actually happened.
One of the main reasons for the new update is to combat the challenge of cyber criminals targeting users within their web browser. PCI DSS v4.0 gives a full spectrum of control to this issue including preventative, detective and corrective measures.
Lots of companies use javascript from third-party domains, for example. Unfortunately, this increases the attack surface. If third-party javascript happens to be malicious and is loaded into a user’s payment page, criminals will be able to harvest their data with ease.
New requirement 6.4.3 focuses on understanding the type of javascript your organization runs, what it does, and how to implement a method of approving new scripts.
Requirement 11.6.1 follows 6.4.3, as it addresses the monitoring of the script while it’s running.
These two new controls have been designed to help you understand what javascript is acceptable and what you should be using. They also act as a first line of defense, as you’ll be able to detect when something within your system isn’t quite right.
1. Reduce the amount of javascript on your payment page. It may not be popular with the marketing department, but it could prevent the loss of extremely sensitive data
2. Implement a Content Security Policy (CSP). This restricts the location where the payment page can be loaded and prevents unauthorized payment pages from appearing
3. Establish a Content Delivery Network (CDN). Having a CDN in place helps detect changes in any page javascript and alerts users if something has changed
4. Install SubResource Integrity (SRI). This allows a user’s browser to validate the javascript being used, and confirm that it hasn’t been tampered with
To recap the benefits of PCI DSS v4.0, understanding what script you have running on your payment page is key. From there, you can reduce non-compliance risk, monitor changes, and prevent the loss of customer data.