PCI DSS Compliance and Beyond: Why V4.0 is Not Enough
Learn about PCI DSS V4.0’s limitations in addressing JavaScript threats.
Rui Ribeiro, co-founder and CEO of Jscrambler, discusses how PCI DSS v4.0 tackles JavaScript vulnerabilities but needs complete client-side protection. Rui further explains why businesses need comprehensive solutions.
Twenty years ago, facing a continued rise in payment fraud, the business community was growing increasingly focused on the need to develop and drive the adoption of new data security standards. Answering the call were American Express, Discover Financial Services, JCB International, Mastercard, and Visa, which joined forces to create the payment card industry Security Standards Council, or PCI SSC.
The PCI SSC is a global council committed to driving the adoption of data security standards and resources that will help secure payments worldwide. Its effort began with the Payment Card Industry (PCI) Data Security Standard (DSS), which has evolved significantly over the years. The latest iteration is v4, which became available on March 31, 2022.
Introducing PCI DSS V4.0
The impetus behind v4.0 is the changing nature of technology, the way payment cards are processed, and criminals’ ever-innovative techniques. One example is version four’s focus on eliminating vulnerabilities that come from the use of JavaScript, which–while helping enable a new wave of digital transformations–has made client-side environments significantly more vulnerable to attack.
Industry-standard groups and regulatory bodies have quickly recognized the issue’s severity and established new requirements for securing web applications. This includes the payment card industry, the Federal Trade Commission (FTC), and the Office of Civil Rights (OCR) within the Health and Human Services (HHS).
Now, with PCI DSS v4.0 requirements, the standard aims to ensure that cardholder data is handled, stored, and transmitted securely during payment card transactions and includes specific requirements for how JavaScript is secured on payment pages.
All in all, v4.0 includes 64 new requirements for organizations seeking compliance. Two of these are specifically focused on securing e-commerce payment pages and combatting e-commerce skimming (Magecart) attacks. Details include:
Requirement 6.4.3: Aim to reduce vulnerabilities and oversee all JavaScript utilized on payment pages by requiring businesses to follow an approval and justification process for all scripts they integrate into these pages. The goal is to reduce the attack surface by ensuring that companies actively manage all JavaScript elements and their integrity.
Requirement 11.6.1. Focuses on detecting unauthorized modifications or tampering on payment pages, which could signal a potential skimming attack. Apart from detecting changes, 11.6.1 also stipulates that an alert must be generated whenever any such alterations are detected, although it doesn’t mandate that the changes be immediately blocked.
Any organization that wishes to process transactions using payment cards issued by PCI SSC participating card brands must sign a contract agreeing to the card brand’s rules. These rules specify that:
- The organization must comply with the requirements contained in PCI DSS.
- The organization is responsible for ensuring third-party service providers handling cardholder data security comply with PCI DSS.
Where the Requirements in PCI DSS Fall Short
PCI DSS v4.0 is a big step forward in addressing the latest wave of security threats businesses face today, but it alone is not enough. V4.0 centers only on payment page pages because PCI DSS is designed to protect payment data. What it does not do is mandate blocking. That’s because blocking isn’t always the answer and is currently technically unfeasible for most merchants, given the inherent insecurity of JavaScript. As a result, data can be sent to locations and destinations not required by that vendor or tag. This is why businesses need a client-side approach beyond the payment page security.
A great example of why active management of scripts and detecting changes alone are not enough to protect sensitive data is related to the use of Facebook/Meta profiling and tracking. In 2022, researchers analyzed the analytics tracking tool called Meta Pixel installed on the website of a group of 33 hospitals. The tool collected sensitive health information from patients and shared it with the social media giant, including details on medical conditions, prescriptions, and more. Third-party tags are vital to businesses. They enable innovations that would otherwise be impossible. However, the incident with Meta belies exactly why third-party tags need to be policed to limit their access to data not intended for their operations. This challenge spans all industries, including online retail, where it has become a growing challenge.
See More: Securing Critical Infrastructure Amid Geopolitical Conflict
Taking Back Control
According to a Ping Identity survey, 81 percent of customers said they would stop engaging with a brand online following a data breach, highlighting the importance of expanding from PCI DSS’s requirements of visibility, detection, and integrity requirements to a truly secure solution that takes full control of data access and exfiltration while enabling the business prevent malicious activity and inadvertent data access and usage that is vital to protecting data privacy on a much larger scale.
Speed is imperative, especially for online merchants. That’s because as online sales grow, retailers are experiencing a surge in malicious scripts targeting customer data. This is happening through various methods. Some of the most common include keylogging, card skimming, web supply chain attacks, and credential hijacking, which evolve regularly using never identical vectors. Ultimately, these merchants find themselves vulnerable to attack vectors like JavaScript data exfiltration and script hijacking. The challenge is exacerbated by these companies relying heavily on third-party vendors and struggling to regulate the data accessible to these third-party tags.
Online retailers require solutions that provide fine-grained behavioral control over third-party tag access. This includes the ability to access forms and data based on high-level assumptions and user-defined rules, as well as the power to authorize or block scripts individually. For example, the flexibility to say that only specific scripts can access the usernames or credit card numbers in a specific form, essentially customizing access rather than having to block it entirely.
Businesses must be able to define global- and domain-specific policies that provide a granular level of control over data access. This could include the capability to fence off individual fields and customize access to information based on specific scenarios and customer journeys. Different policies could be defined for different user journeys based on variables such as login status, allowing the business to align security protocols with the data sensitivity of particular pages or fields.
It’s also important to define access policies corresponding to sensitive information on any page or even in a particular field. For example, a business may feel it’s okay to give a third-party vendor access to email addresses on a simple login page but not on a payment page that contains sensitive information like names, mailing addresses, and payment card information.
At the end of the day, it’s important that businesses have the freedom to leverage first- and third-party JavaScript. These allow them to transform their digital presence, measure performance, drive customer traffic and loyalty,…the list goes on. But these advancements cannot open the door to new threats such as Magecart and skimming attacks. The new requirements in PCI DSS v4.0 are a great first step that all companies should adhere to, but it alone is not sufficient to prevent all client-side risks. For complete peace of mind, the best bet is to implement a complete client-side protection platform that secures the entire business.
MORE ON PCI DSS COMPLIANCE
