There are many reasons to use a web application firewall. Most people tend to focus on prevention and blocking when the term is brought up, but that is just one of the possible uses. Three years ago, almost to the day, I wrote this post to argue how one needs a WAF to serve as a part of the overall defence strategy. My opinion remains unchanged today, but I have since expanded the list of use cases for web application firewalls. Here they are:
- Web intrusion detection and prevention. Applying the principles of external traffic monitoring (IDS) and prevention (IPS) to HTTP and the related technologies, which are used to build web applications. Through your WAF you will look for signs of generic web application attacks (negative security model), or deploy a learning engine to construct a model of your site and reject all invalid traffic, not just attacks (also known as positive security model).
- Continuous security assessment. The idea with this case is to emphasize the fact web application firewalls actually understand web applications pretty well. Armed with this knowledge, they can do more than detect attacks; they can observe from signs of weaknesses, information leaks, configuration errors, and similar problems before an attempt to exploit them is made.
- Virtual (or just-in-time) patching. When you need to deal with a specific problem in your web site, which exists either in your code or in the code of the product you are relying on. The focus in this use case is on writing custom rules to deal with custom issues.
- HTTP traffic logging and monitoring. Do you know what is actually going on in your web applications? Who are your users and how are they using your systems? Are you being attacked and how?
- Learning. My original list did not include learning as a WAF feature but, in retrospective, I realised I was failing to convey a very important functionality and differentiator over intrusion detection and prevention systems. The point is that WAFs understand web applications, so in some cases they are able to move away from intrusion detection (as in traffic monitoring) to a default deny security model.
- Web application hardening. If you deploy your WAF as a reverse proxy then you can get it to modify the traffic stream to fix some of the design faults of your application or the HTTP protocol.
I will expand on each use case in my future posts.
Update (10 July 2008): I've decided to remove the "Network building blocks" use case from the list. While I still believe this is an important use case, I now think the usefulness should be attributed to reverse proxies. And, if a WAF happens to be implemented as a reverse proxy, that it will include the advantages and the disadvantages of that model.
Note: This post is part of the Web Application Firewall Concepts series.