Web Application Firewall Use Cases Update
My list of web application firewall use cases continues to involve. I've decided to shuffle things somewhat:
- I am going to remove the "Network building blocks" use case because that is really a feature of reverse proxies. If a WAF happens to be implemented on top of a reverse proxy that it will also inherit all of its benefits (and downsides, I should mention). In retrospective, I thought the two (reverse proxies and WAFs) should really stay separate.
- I am going to add "Learning" as a new use case. As I was looking at the previous list of use cases it stroke me that I was failing to convey the ability of web application firewalls to understand what is going on, and this is what learning does.
Note: This post is part of the Web Application Firewall Concepts series.
I agree with the removal of the "Network building blocks". I had the feeling that was redundant. Learning is a good addition. It is an efficient way to understand an application when you have to write WAF rules to protect it.
Could you elaborate, why you think WAF and RP should stay seperate?
Posted by: Christian Folini | July 11, 2008 at 10:22 AM
I am sorry, I was just very clumsy in expressing myself. I didn't mean to imply WAFs and RPs should be separate in deployment sense. These technologies work very well combined. I think every reverse proxy should incorporate WAF functionality, but the opposite is definitely not true: in many cases WAFs are more useful when entirely passive, or embedded. In that sense, I don't think reverse proxies are an integral part of the WAF identity.
Posted by: Ivan Ristic | July 11, 2008 at 10:40 AM