WAFs, or web application firewalls, have been around since the late 1990s, becoming popular in the early 2000s when OWASP formalized its top 10 list of application vulnerabilities. WAFs are designed to monitor and block suspicious HTTP traffic from reaching your web applications. This is typically done based on a series of rules that block any traffic that matches a signature designated as an attack pattern. As “DevSecOps” and “shifting security left” become popular buzzphrases and attacks have grown increasingly complex, many have wondered whether WAFs are still meeting our needs. In their traditional form, maybe not, but the WAF market is evolving to accommodate the fast-paced software development lifecycle.
Signature vs. Rule-Based WAFs
Most traditional WAFs allow or block traffic with signature-based policies. Each of these signatures essentially describes a pattern for a known attack, so the WAF can issue an alert or block traffic when it meets that pattern and therefore has that signature. This poses a problem for applications in fast-paced continuous integration and continuous development environments where manual updating of signatures isn’t feasible due to the constant state of flux. Similarly, as the number of attacks grows and attackers are able to better mask their efforts, this method has grown cumbersome and outdated. Only stopping traffic that meets pre-defined patterns will not stop a new attack, and slight variations may be able to get through.
Today’s WAFs are moving away from signature-based detection toward rule-based detection. Rule-based detection uses artificial intelligence to create rules based on a number of attack patterns, as opposed to recording the exact attack pattern of a specific attack. This requires a lot less manual updating of signatures and offers wider attack coverage with fewer rules, which also helps with processing speed.
Using WAFs in Conjunction with RASP
Web application firewalls are designed to block or allow traffic based on whether or not it matches a defined signature or rule. One of the downsides of WAFs, however, is that they are not able to see how that traffic is being processed by an application, which is where runtime application security protection (RASP) comes in. While WAFs are designed to provide broad protection to the entire web application infrastructure, RASP tools are designed to protect a specific application. RASP tools are able to take a detected attack string and see if it would actually be able to execute successfully, reducing the number of alerts received by your security team, to only the ones that require attention.
RASP tools are also able to help detect some of the new attack patterns that a WAF would miss based on how this traffic interacts with the application. The downside of runtime application security protection is that it must be run on the server where the application is running, which can impact performance, and they only protect that specific application, so it can be cost-prohibitive to apply to an environment with a number of apps. It may make sense to apply RASP only to the most important applications while continuing to use a WAF to ensure broad coverage across the environment.
WAAP Solutions
Rule-based WAFs and WAFs used in conjunction with RASP tools still have some drawbacks. A leading alternative to traditional WAFs, designed for the modern cloud-first environment, is the web application and API protection (WAAP) solution. These technologies recognize that traditional signature-based WAFs are not ideal for continuous integration and continuous delivery environments, as the constant state of flux makes it difficult to manually maintain the signature policies needed.
They also address the growing use of APIs with the capability to also inspect traffic headed for API endpoints. These tools typically combine next-generation WAF capabilities, including using machine learning to block attacks and RASP capabilities, with protection around APIs, microservices, and serverless functions, which makes it ideal for the cloud. WAAPs also provide additional protections against DDoS attacks and bots.
Conclusion
WAFs are not going away anytime soon. The core concepts behind WAFs are being adapted and integrated into modern solutions that address some of the traditional WAF deficiencies while adding capabilities for the cloud and machine learning.
Another important distinction in the world of WAFs is that not all applications are subject to the DevSecOps process. Legacy applications still exist, as do third-party apps that may not necessarily be implemented by the development or security teams. These applications that are not routinely undergoing code review still need protection, and WAFs can play a vital role.
While incorporating security into the development process early does help reduce the number of vulnerabilities in the live environment, the reality is that vulnerabilities still get through. The use of third-party code libraries introduces a significant opportunity for risk. What was approved as safe during the development process may end up insecure later due to changes in one of these components, so relying solely on DevOps for security is unwise. WAFs and their next-generation successors can act as another line of defense in the continual fight against threats to our web applications moving forward.
RH-ISAC members have access to a community of cybersecurity professionals who can answer questions about WAF implementation and can provide advice for strengthening your applications against common vulnerabilities. Not an RH-ISAC member? Learn more about how being a part of the RH-ISAC’s member community can benefit you.
