FIGURE 1: "V4.0"
On March 31, 2024, we transition from PCI DSS 3.2.1 to PCI DSS 4.0. If this news surprises you and makes you jump out of your seat, it is time to prepare. The silver lining is a 12-month grace period until the new requirements become mandatory on March 31, 2025. During this period, a best-effort approach is expected.
If you are already familiar with PCI DSS, you are likely involved in online retail. However, if you have overlooked this, it is time to pay attention. PCI DSS 4.0 extends its compliance scope to all entities processing financial transactions, not just traditional retail payment chains. This includes businesses indirectly facilitating transactions or providing supporting services. So, it is crucial for all to understand and adhere to the new PCI DSS 4.0 compliance.
As the PCI DSS 4.0 requirements document is quite extensive, in this blog post, I will try to simplify three key areas related to our world of application protection solutions.
First, Web Application Firewall (WAF):
Solution Implementation - PCI DSS 4.0 requires the use of a Web Application Firewall (WAF) to safeguard websites, marking a notable transition from PCI DSS 3.2.1 where it was merely best practice. This change mirrors the evolving threat landscape and the increasing frequency of attacks on digital payment data.
Elevated Role of Positive Security Model - The new standard raises the importance of positive security models. To comply with the requirement for real-time adaptive and active protection against new threats and blocking of non-essential traffic, your application protection solution mustn't be solely signature-based (negative security model, also known as block lists). Instead, it should incorporate and utilize a robust, behavior-based positive security model capable of adapting and accurately discerning legitimate traffic (allow lists) and blocking all else.
Lastly, a Comprehensive Approach - PCI DSS 4.0 acknowledges that vulnerabilities can have cascading effects due to system interconnectivity. This highlights the increasing sophistication of cyber threats. Consequently, a WAF alone is insufficient. A combination of application protection tools, including WAF, Bot management, API protection, and Client-side protection, working in unison is necessary. Ideally, an automated technology that cross-correlates between different protections, providing real-time alerts, insights, and enhanced protection, is recommended.
What About API Protection? What’s Required?
Preventing Data Leakage and Protecting Against Business Logic Attacks (BLAs): PCI DSS 4.0 mandates companies to implement measures for data leakage prevention and Business Logic Attack (BLA) protection. With multiple API integrations from various third parties, business logic can easily be exposed and exploited for malicious purposes. Companies must protect their APIs against these business logic attacks and implement a solution that in addition to discovering all API endpoints and their parameters, can also analyze business logic and detect anomalies in the content and order of API requests that deviate from normal behavior. PCI DSS 4.0 has also strengthened requirements on authentication and authorization, necessitating the ability to identify and authorize access to cardholder data.
Last, But Not Least, Client-Side Protection
The Major Addition to the New PCI DSS – As server-side security continues to improve, hackers are increasingly targeting the less protected and often overlooked client side. An average application runs dozens of different third-party JavaScript services. These services are loaded when the user first visits a page and are automatically trusted by the main application, but they are rarely monitored.
While enterprises are doing their best to protect customers’ personal data on their application server-side environments, the information that end-users enter on their browser side can be exposed to third-party services embedded in the applications. Hackers are relentlessly trying to compromise the security of these third-party services.
By exploiting vulnerabilities to plant malicious code in those third-party services, they can launch form jacking and skimming attacks and steal hundreds of thousands of customers’ personal information without the customers or the company knowing about it.
Standard web application firewalls do not have visibility into the data path between end users and third-party applications, and therefore cannot detect nor stop these types of attacks. Recognizing this as a high-growing risk, the Payment Card Industry Digital Security Standard version 4 (PCI DSS 4.0) requires organizations to implement client-side protection measures:
Integrity of Payment Page Scripts: Section 6.4.3 necessitates that organizations uphold the integrity of all payment page scripts executed in the consumer’s browser. This requirement extends to scripts sourced from third-party sites, emphasizing the need for robust controls that ensure the security of all elements interacting with the consumer’s browser, especially within payment transactions.
Tamper-Detection Mechanism: Section 11.6.1 seeks to counter the potential impact of Magecart attacks by mandating a tamper-detection mechanism. This mechanism would promptly alert organizations about unauthorized alterations to HTTP headers and payment page content as perceived by the consumer’s browser.
To comply with these requirements, look for a client-side protection solution that can provide complete visibility of all third-party scripts that are running on the browser side of your application. This continuous automatic discovery of your application supply chain promises that there is not a single third-party domain or script that remains unaccounted for.
It must also provide a threat-level assessment of each service and script with detailed activity tracking and alerts. Notifying you of any attempts to manipulate form and payment pages as well as any attempts at DOM XSS. Look for a solution that uses a positive security model and enforces protection in a surgical manner that does not stand in the way of business and surgically blocks only nefarious scripts with illegitimate parameters.
Contact us to learn how Radware can help your organization comply with the new PCI DSS 4.0.