PCI DSS 4: what changes in the new version and how to comply with it

In this interview, Hervé Hulin, Regional Sales Manager (France) of Jscrambler explains how to comply with the new PCIDSS version 4.


The evolution of skimming attacks: What are the risks for victims?

The skimming or Magecart attack has become a tool of choice for cybercriminals looking to steal their victims’ sensitive data related to payment cards. All e-commerce/online sales companies are now exposed to this new risk.

While the attack is carried out through websites that appear safe and legitimate, users may not know that their data has been stolen. Sometimes it takes a long time to realize that the flaw is in a malicious script hosted on a legitimate online payment page. British Airways and Emma Literie are examples of credit card data mining with 400,000 and 94,000 customers affected respectively.

In 2021, 90% of data breaches involved web applications and 44% involved personal information (Sources: Verizon 2021 and IBM Data breach reports).

95% of websites and 55% of mobile apps are based on JavaScript.

The Javascript language is everywhere, it offers a wide field of attacks, especially by third parties, applications or existing services reused in the development of new services or websites. So fast that the activity of the sites can become “busy”.

On average, we found that out of 35 parts, 70% of an e-commerce website’s scripts come from third parties and even “fourth parties”. The injection, more or less buried, of the malicious script can appear by “surprise”. The goal of the attackers is to see their malicious JavaScript executed at the user/customer browser level and to extract sensitive data (eg bank card). Attacks can come either through a commercially owned website, the injection is made directly on the company’s servers (British Airways case), or through the payment service provider. It can also go through another third-party service (ticket Master case through the “Chatbot” service), or through the “Tag Manager” (Adverline case) that manages third-party services such as advertising, profiling, tracking/localization.

Companies naturally focus their protection efforts on the “internal” side of the company’s SERVER. However, the CLIENT side, that is, the browser, remains secure to ensure the direct protection of users of Web services and the proper operation of the activities of the “owner” of the Web site.

What are the new requirements of this standard?

The standard PCI DSS (Payment Card Industry Data Security Standard) is a global standard that governs the protection of banking data against illicit attacks.

Faced with the real vulnerability of web forms, the new version of the data security standard, published by the PCI Security Standards Council, strengthens the protection of payment data with new controls and therefore fights against sophisticated attacks. -cyber attack.

The PCI DSS 4 standard is enriched with 64 new requirements, two of which aim to prevent and detect skimming attacks launched on e-commerce sites:

● Requirement 6.4.3 is intended to reduce the attack surface. This guarantees that all JavaScript elements contained in a payment page are required, that they are included in an inventory, and that they are explicitly approved. It also requires ensuring the integrity of all JavaScript.

● Requirement 11.6.1 relates to the detection of any tampering with JavaScript code included in payment pages. This indicates that changes made to the “http Headers” scripts and page headers can be detected and the corresponding alerts generated. A dynamic analysis must be performed periodically and/or at a maximum frequency of 7 days.

What changes does this new version bring? What steps must be taken to comply?

E-merchants who own their sites and payment service providers need to ensure full visibility and management of all scripts loaded on the payment page. In addition, they will need to detect changes to existing scripts — proprietary or third-party, knowing that almost 70% of scripts on a site come from third-parties.

Creating alerts that notify them in real time of changes made to existing scripts will help them in day-to-day management. By detecting and analyzing changes, they can verify that no one is trying to steal data belonging to the cardholder.

Returning to compliance will require implementing solutions or tools to:

• Build Inventory.

• Allow scripts to be present

• Prove their need.

• The integrity of the scripts is guaranteed (they are not modified).

• Alert as needed.

• Check periodically and/or with a frequency of 7 days.

• Check if there are any changes in the content of the active page that may affect the payment method.

• Detect changes in http headers (Headers).

In the first approach, we can consider a combination of the standard methods of CSP (Content Security Policy) and SRI (Sub-Resource Integrity) security functions developed for the Web. Thus, site owners will be able to declare the approved sources of content loaded by browsers and verify that the services delivered are free of unexpected manipulation.

If however they can cover the requirements of the standard, however they have shortcomings or weaknesses:

Regarding requirements 6.4.3 – CSP and SRI

• Build inventory: external manual method (spreadsheet)

• Allow scripts to be present: external manual method

• Prove the need: external manual procedure

• Guarantee the integrity of scripts: Manual checking of functionalities. Hash generation for SRI.

Regarding 11.6.1-CSP and SRI Requirements

• Alert as needed: CSP alerts, external “scan” checks can be alerted.

• Control seasonally and/or with a frequency of 7 days: CSP can alert in real time. Otherwise, an external review is required.

• Check if there are any changes in the content of the active page that could affect the payment procedure: SRI detected changes in the scripts.

• Detect changes in http headers (Headers): External checking is required.

In addition, it is important to consider the following information:

• Whenever the PSP (Payment Service Provider) changes its JavaScript, you will need to get a new hash from it and update your parent page.

• Any addition of JavaScript from new locations requires a change to the CSP, and it may not match business workflows.

• CSP and SRI have the disadvantages of manual interventions. Moreover, they are based on valid but relatively “static” information.

Tools that allow dynamic, real-time analysis of the activities of scripts on different website pages will facilitate its compliance and monitoring. For example, Jscrambler’s Web Page Integrity solution, based on a secure agent injected into the web pages to be analyzed, will make it possible to report script activities in real time on a configurable dashboard to automate control and security actions. The solution allows to:

• Build Inventory. An Inventory is generated in real time as soon as a script appears or changes.

• Allow scripts to be present. There are fields to record consent. Optionally, unauthorized scripts can be blocked.

• Prove their need. The rationale of the scripts present is listed in the context of the inventory.

• The integrity of the scripts is guaranteed (they are not modified). Functionality will be developed and the behavior of each script will be tested.

• Alert as needed. Alert messages will be sent via email, Slack and also appear on the dashboard via your SIEM.

• Check periodically and/or with a frequency of 7 days. A control can be performed in real time.

• Check if there are any changes in the content of the active page that may affect the payment method. Changes are detected in real time, reported from sessions, behavior is analyzed and risk is assessed.

• Detect changes in http headers (Headers). Changes are detected in real time, and reported from sessions.

In addition to the full treatment of the requirements in 6.4.3 and 11.6.1, tools such as Jscrambler with WebPage Integrity due to the granularity of its programming can perform targeted blocking actions.

What is the compliance schedule?

These new requirements will become mandatory starting March 31, 2025.

The old version of the standard (V3.2.1) will remain valid for two years to allow organizations to not only familiarize themselves with the new version, but also have time for planning and implementation.

However, it is important that e-merchants have upstream visibility, risk management capabilities and the ability to control the JavaScript code. In fact, the frequency and level of sophistication of this type of attack is expected to increase before the new rules are widely implemented in the payments ecosystem.

Leave a Reply

Your email address will not be published. Required fields are marked *