On March 31, 2024, the world of compliance transitioned from PCI DSS 3.2.1 to PCI DSS 4.0. The silver lining is there is a 12-month grace period until the new requirements become mandatory on March 31, 2025.
If this news comes as a surprise, it is time to prepare. PCI compliance is no longer just for traditional retail payment chains. PCI DSS 4.0 is a call to all businesses processing financial transactions or providing supporting services to comply. While the PCI DSS 4.0 requirements document is quite extensive, there are three key areas related to application protection that organizations must address.
Deploying a web application firewall to safeguard websites
For starters, PCI DSS 4.0 requires the use of a web application firewall (WAF) to safeguard websites. This is a notable shift from PCI DSS 3.2.1 where WAF protection was merely a best practice. This change was largely driven by an evolving threat landscape and the increased frequency of attacks on digital payment data.
To comply with the requirement for real-time adaptive and active protection against new threats, the WAF solution should not be limited to a signature-based approach. Instead, it should incorporate and utilize a robust, behavior-based positive security model capable of adapting and accurately discerning legitimate traffic while blocking non-essential traffic.
PCI DSS 4.0 also acknowledges that vulnerabilities can have cascading effects due to system interconnectivity. Consequently, a WAF alone is insufficient. A combination of application protection tools working in unison is necessary. This includes bot management, API protection, and client-side protection. Ideally, an automated technology that cross-correlates between different tools to provide real-time alerts and insights is recommended.
Preventing business logic attacks
PCI DSS 4.0 requires companies to implement protection against business logic attacks. As organizations rely more heavily on APIs to run their business and APIs in turn rely on multiple integrations from various third parties, business logic can easily be exposed and exploited for malicious purposes. Companies should implement a solution designed to analyze business logic and detect API requests that abuse or bypass application features and functionalities.
PCI DSS 4.0 has also strengthened rules on authentication and authorization, requiring the identification and authorization of access to cardholder data.
Implementing client-side protection
As server-side security continues to improve, more hackers are setting their sights on the less protected and often overlooked client or browser side. An average application runs dozens of different third-party JavaScript services. These services are loaded when a 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.
By exploiting vulnerabilities to plant malicious code in those third-party services, hackers can launch form jacking and skimming attacks and steal personal information from hundreds of thousands of customers without the customers or the company knowing.
Standard WAFs 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 blind spot as a growing threat, PCI DSS 4.0 now requires organizations to implement client-side protection measures.
This includes upholding the integrity of all payment page scripts executed in the consumer’s browser, including those from third-party sites. Robust controls are needed to secure all elements that interact with the consumer’s browser, especially for payment transactions.
The new PCI DSS 4.0 requirements are also designed to counter the potential impact of Magecart attacks by mandating a tamper-detection mechanism. This required mechanism promptly alerts organizations about unauthorized alterations to HTTP headers and payment page content as perceived by the consumer’s browser.
To comply with these requirements, organizations should look for a client-side protection solution that can provide complete visibility to third-party scripts that are running on the browser side of an application. Continuous, automatic discovery of the application supply chain ensures that there are no third-party domains or scripts that go unaccounted for.
An effective client-side protection solution should also assess a threat-level for each service and script with detailed activity tracking and alerts. It should notify organizations of any attempts to manipulate form and payment pages as well as any attempts at DOM XSS. In addition, organizations should look for a solution that uses a positive security model—one designed to enforce protection by surgically blocking nefarious scripts without disrupting legitimate business traffic.
