In the ever-evolving landscape of cybersecurity, staying ahead of threats and ensuring the safety of sensitive customer data is paramount. For organizations that handle payment card information, complying with industry standards like PCI DSS (Payment Card Industry Data Security Standard) is not only a best practice, but a compliance requirement that can result in hefty fines upwards of $100,000 a month.
Starting in April 2024, auditors can begin using the new PCI DSS 4.0 guidelines with full enforcement of requirements coming in March 2025. Some new and updated requirements of PCI 4.0 aim to tackle client-side risks head-on, such as Magecart, formjacking, and online skimming attacks. In this blog, we’ll unpack the latest iteration of PCI 4.0, what it means for client-side security, and what you can do to ensure compliance.
Understanding PCI DSS 4.0
PCI DSS, or Payment Card Industry Data Security Standard, is a set of security guidelines designed to protect cardholder data. Created by major credit card companies such as Visa, MasterCard, and American Express, PCI DSS provides a comprehensive framework for securing payment card information throughout its lifecycle, from data entry to storage and transmission.
New & Updated Requirements
Requirement 6
Requirement 6 carries significant weight when it comes to client-side security, encompassing several updates and introducing entirely new criteria as well. These changes pertain to the process by which businesses identify, document, and oversee JavaScript within web browsers responsible for gathering payment data.
- Requirement 6.3.2: Identify and list all bespoke and custom software.
- A new key requirement – 6.3.2 – states that in order for organizations to enable vulnerability and patch management, they are now required to identify and list all of their custom and bespoke software, including any third-party software that has been incorporated into the organization’s bespoke and custom software. Vulnerabilities in third-party components such as libraries and APIs, integrated into an organization’s software can leave those applications susceptible to attacks. Therefore, it is crucial to maintain awareness of the third-party components used in the software and actively monitor the availability of security patches to rectify known vulnerabilities, ultimately safeguarding the software’s security.
- Requirement 6.3.3: Protect system components from known vulnerabilities.
- Requirement 6.3.3 mandates safeguarding all system components from known vulnerabilities by applying relevant security patches and updates. If you’re utilizing client-side scripts sourced from third-party libraries, it’s crucial that you implement necessary fixes to avoid the exploitation of a known vulnerability.
- Requirement 6.4.1: Public-facing web applications are protected against attacks.
- Requirement 6.4.1 calls for all public-facing applications to address new threats and vulnerabilities on an ongoing basis and protect these applications from known attacks.
- Requirement 6.4.2: Correctly configure automated public-facing web applications.
- Requirement 6.4.2 clarifies that there must be proper configuration of automated public-facing web applications to identify and thwart web-based attacks. This requirement also mandates that these configurations should remain active, regularly updated, and set to either block attacks or trigger alerts when potential issues arise. Any generated alerts must be promptly investigated.
- Requirement 6.4.3: Authorize customer browser scripts.
- Requirement 6.4.3 states that any scripts that are loaded and executed in a customer’s browser be authorized. Additionally, an inventory of scripts must be maintained with written justification as to why each script is necessary and a method must be implemented to assure the integrity of each script.
Requirement 11
Requirement 11 contains a brand new requirement that directly applies to client-side protection.
- Requirement 11.3 specifies that external and internal vulnerabilities are to be regularly identified, prioritized, and addressed
- Requirement 11.5 states that businesses are obligated to identify and react to network intrusions and unexpected file changes.
- Requirement 11.6 mandates that businesses must detect and respond to unauthorized changes on payment pages.
Achieving PCI DSS 4.0 Compliance
1. Get started now.
With the update of current requirements and brand new ones too, the shift from PCI 3.2.1 to 4.0 requires plenty of time to prep and implement. Giving your team enough time to plan and execute these best practices will help ensure compliance by early 2025.
2. Content Security Policy (CSP).
Content Security Policy (CSP) serves as an additional security layer akin to an “allowlist” when a user engages with your website and web applications. For example, when a user accesses your website, their request is transmitted to the web server, which then replies with a list of all the assets to load on that page. Throughout this operation, the system executes scripts on the client side, encompassing both first- and third-party scripts, as well as images and other assets that load in the browser. By repelling these scripts, a content security policy can intercept and prevent an attack from happening.
When dealing with front-end systems housing extensive inline scripts sourced from numerous third- and fourth-party repositories, managing policies for such complexity can become an extremely challenging and risky task. This complexity increases the vulnerability to potential attacks. Especially if third-party code, plugins or enhancements are added to the web page, this may cause policies to fail. Hence, if the organization is conducting an audit for PCI DSS compliance, there is also the concern that analysts may encounter challenges in pinpointing the reasons behind policy failures.
Automated Content Security Policy (CSP) tools can help organizations in overseeing their client-side attack exposure by implementing and overseeing CSPs within their web applications. The Feroot platform offers an advanced automated CSP solution that is proficient at recognizing all first- and third-party scripts, digital assets, and their data access privileges. Subsequently, it generates suitable CSPs by analyzing the scanned data and predicting their efficacy. Businesses have the flexibility to refine their CSPs at the domain level for streamlined management, version tracking, and reporting.
3. Implement Solutions to Support PCI Compliance.
Frankly speaking, it is going to take plenty of time and resources to document and maintain inventories of bespoke and custom software in order to securely manage all the payment page scripts that are loaded and executed in a customer’s browser. Especially if you’re a mid- to large-sized company with thousands of scripts operating on the client side, you don’t want to be doing manual code reviews.
Feroot can help automate many of the new requirements found in PCI 4.0; including granular controls required to protect payment card data on the client-side.Ready to take the first step towards PCI 4.0 compliance? Schedule a demo with a client-side security expert!
