There are now two options to meeting the new requirement 6.4.2 for a web application firewall: WAF or RASP. Notice I didn’t say manual code review!
On March 31st, 2022 PCI DSS v4.0 was released. Today’s post is part of series of pieces we are publishing that explore the changes to the PCI standard and provide insight into what the changes will mean for your organization. All of our posts can be found here.
Anyone who has been around the Payment Card Industry and PCI DSS for a long time remembers the version upgrade of PCI from 2.0 to 3.0. Now we are at version 3.2.1 and looking at the update to 4.0. Each new release has a focus on improving the security of cardholder data.
The PCI SSC has stated there are four goals with the release of version 4.0. One of these goals is to promote security as a continuous process which can be seen throughout the v4.0 updates. This blog will focus on the change in Requirement 6, Develop and maintain secure systems and applications, and specifically 6.4.2.
Requirement 6 reviews Secure Coding Practices, focusing on activities that must be in place to secure applications in scope for PCI. Application developers have been trained to deliver their code for production after considering and testing against the OWASP Top 10 web application security risks. When applications are not developed with secure coding procedures in place, it leaves gaps that attackers could take advantage of to gain access to cardholder data. Several experts have reported that 84% or more of security breaches occur at the application layer, which is why this is so important.
| “Many organizations have significant network security in place but it’s not enough as 84 percent of all cyber-attacks are happening on the application layer” said Tim Clark, Head of Brand Journalism at SAP, in a recent Forbes blog. |
The PCI SSC has strengthened Requirement 6 and put more focus on protecting public-facing web applications. Continuous attacks on web-facing applications are impacting the availability and protection of these applications, which can facilitate access to cardholder data. Ultimately, this can have a negative impact on the organization, the customers using the application, and possibly the credit card data. There could also be legal and financial implications to consider.
One new requirement, 6.4.2, requires an automated technology solution to be deployed in front of web-based applications or within the application to continually detect and prevent web-based attacks in real-time. The solution must be actively running, generating audit logs, and configured to either block web-based attacks or generate an alert for immediate investigation. As of today, 6.4.2 is a best practice. However, as of March 31, 2025 it will be required as a replacement for 6.4.1.
How does this impact your organization? First, you must understand your application and data flow. Where does your application sit within the organization? Who has access to the applications? Does it contain cardholder data?
Suppose you have an application that is web-facing and stores, processes, and/or transmits cardholder data. In that case, this requirement change will impact your organization as it will take time, finances, and process improvements to implement the specified guidance.
Are there options to meet this new requirement? Yes, the Council has documented two options that meet the requirement goal. One is a network-level solution, and the other is an application-level solution.
A company can consider implementing a Web Application Firewall (WAF) in front of a public-facing application. This option will detect and prevent common software attacks such as those documented in the OWASP Top 10 (for example - SQL injection). Rules, or policies, are set up to block malicious HTTP traffic. A WAF can be implemented as a network, host, or cloud-based solution.
An alternative to implementing a WAF is to look at the Runtime application self-protection (RASP) technology. RASP is an automated solution that integrates within the application, runs in real-time, looks for specific requests to the application, and then denies all other requests. The RASP tool runs on the server, identifying attacks in real-time.
Either of these solutions would be acceptable to meet the new requirements. They both have pros and cons based on your organization. A review of risk, cost, and impact should be considered when making the final decision.
Logging and alerting from either of these solutions are critical. This allows any detected activity to be investigated to mitigate any potential attacks. Audit logging is also required to ensure unexpected activity is being captured for review.
Requirement 6.4.2 is a new, future-dated requirement, replacing Requirement 6.4.1 in v3.2.1. Companies with web-facing applications in scope for PCI should begin to assess their environment, understand the impact of the change, and develop an implementation plan before the requirement date to deliver adequate artifacts demonstrating it is working as expected prior to the official PCI 4.0 assessment compliance date. Don’t let this new obligation surprise you.
Online is ready to assist you in developing your PCI program, helping unpack what the v4.0 changes will mean for your organization, and then designing a compliance roadmap to get you there. For additional insight and guidance from Online’s QSA team, explore our digital PCI DSS v4.0 Resource Center, where we have identified and dissected many of the significant changes and new requirements in the latest release of the PCI Standard.