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).
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:
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:
• 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.