Almost seven years ago, I sat in a steakhouse in Manhattan listening to Jeremiah Grossman of WhiteHat Security hold forth on the serious nature of web application security and how Web Application Firewalls (WAF) could help improve vulnerability remediation rates. Inspired, I set out evangelizing the benefits of WAF for providing another layer of input and protocol validation, thus enabling terminally vulnerable web applications to be protected from their own flaws. Many IT organizations met this recommendation with either confusion (What’s a SQL injection?) or disbelief (Why would someone try to do that?). Often, the former audience was the network engineering team, which was expected to own the WAF, and the latter audience was the application development team, expected to fix the application code.
Fast forward, the WAF conversation is much easier to have today. Knowledge of web application flaws such as SQL injection is widespread, and IT organizations have gotten serious about implementing better application security practices. Secure coding practices and frameworks help to prevent vulnerable code from making it to production, and application security testing (AST) tools help find those flaws when they do make it through to production. However, these same organizations still wrestle with how to deploy and manage WAF. In fact, I’ve written in the past about where WAF fits in your application security practice. In that article, I didn’t discuss who should own and operate the WAF, as the answer varies based on the organization. Mike Rothman of Securosis wrote extensively on the challenges of managing a WAF way back in 2012, and his guidance remains relevant today.
Some teams are fortunate to have a full-time engineer dedicated to WAF operation and maintenance. Others divide the task between app dev and security or network engineering. Most frequently, the WAF administration is left to the network engineering or security teams, because they own all the other types of firewalls and security appliances. These teams have often been very successful deploying all manner of network firewalls, intrusion prevention/detection systems (IPS/IDS), and other in-line security solutions. However, unlike other firewalls, WAF demands a high level of customization for each web application, which in turn demands very specific knowledge of each protected web application. This specific nature of the WAF policy per application increases the operational workload over most other security solutions. In addition, web applications, especially business critical ones, are rarely static. As the application changes, the WAF policy must change with it, which increases the already-high bar for operating a WAF.
With the advent of DevOps, and frequent pushes of new web application code into production, the headwinds for WAF adoption grow stronger. A truly DevOps-driven environment is also much more able to find and remediate web application vulnerabilities via Continuous Delivery and Deployment of code.
Is there a place for WAF in the DevOps future?
The answer is “Yes, but the WAF must evolve to avoid extinction.”
Most WAF deployments are focused on enhancing or patching input and HTTP protocol validation, which most application servers and the web applications should be able to handle themselves, but traditionally have not. DevOps makes it possible to find and address these input validation flaws as quickly as applying a WAF policy tweak. For WAF technology to remain relevant, however, the focus must shift from fixing the flaws of the target web application to enhancing the defensive posture of the web application. Great effort has been spent building web application learning engines in WAF technologies, to ease the burden of building accurate policy tailored to the web application. While these learning engines work well in many cases, they haven’t completely obviated the need to understand the web application.
Some current WAF solutions have already evolved some of the advanced capabilities needed to survive, such as:
- Dynamic bot detection
- Client-fingerprinting
- Web scraping mitigation
- Application layer denial-of-service detection and mitigation
- URL profiling
These types of capabilities extend the security of the web application without requiring extensive customization of the policy or knowledge of the web application. Learning engines must also evolve to assess the overall risk and threat of a given session, and make blocking or alerting decisions based on that information. For example, a single request carrying a SQL-injection payload may or may not be a false positive. However, if that same session has also attempted an HTTP GET flood, a cross-site scripting attack, and the client has bot-like characteristics, the risk assessment reduces the probability of a false positive upon a blocking action.
This type of anomaly detection and risk/threat assessment can be described as behavioral analysis. WAF proxies are uniquely positioned to intercept, profile, and manipulate application traffic for the purpose of behavioral analysis. As a proxy, many WAFs are more able to detect non-human or malicious behavior and track that at the application session-level. As a central enforcement point, The WAF, like other firewall types, is also able to see the big-picture view of the threat surface that individual web application servers are likely to miss.
Application layer threats such as SQL-injection and cross-site-request-forgery (CSRF) continue to be some of the biggest dangers for data theft. High profile breaches heighten our awareness of these dangers, and continue to drive adoption of application layer security technologies like a WAF. However, we must seek out technologies that our organizations can deploy and manage, enabling the security benefit to be realized. Even as we evolve our secure coding practices and adopt more flexible deployment models such as DevOps, the need for application layer visibility and security remains prevalent. When selecting such technology, it’s critical to identify solutions with clear roadmaps, not only for usability and manageability, but also for evolving security mechanisms. The traditional notion of WAF is no longer sufficient in modern infrastructures, but there is promise for advancing the original idea for WAF to something more usable and effective than ever before.
