Extremely valid comment made by Pavel Skovajsa in response to my “Rest in peace, my WAF friend” post beautifully illustrates the compartmentalized state some IT organizations face; before going there, let’s start with the basic questions.

Do we need WAF ... as a function, not as a box or a specific product? It’s the same question as “do we need virus scanners” or “do we need firewalls” in a different disguise. In an ideal world where all the developers would be security-conscious and there would be no bugs, the answer is “NO”. As we all know, we’re in a different dimension and getting further away from the heavens every time someone utters “just good enough” phrase or any other such bingo-winning slogan.

It’s popular to bash IT vendors’ lack of security awareness (Microsoft comes to mind immediately), but they’re still far ahead of a typical web application developer. At least they get huge exposure, which forces them to implement security frameworks.

The exposure a typical web application gets is low (unless you’re working for Google, Facebook, Twitter, Amazon or a few others) and the vulnerabilities are thus hidden until someone takes advantage of them. Not surprisingly, hacking accounts for more than 90% of stolen data records in 2009 and within that category, SQL injection is responsible for almost 90% of the stolen goods (source: Verizon’s 2010 Data Breach Investigation Report). All this has been known years ago, but still most web sites don’t use a WAF. The situation is similar to the behavior of early Internet adopters around the time the Firewalls and Internet Security book was published, but with infinitely more money at stake.

Web server module or standalone solution? When you mention standalone WAF to the web community, the typical response is “we don’t need it; there’s mod_security for Apache”. They might be partially correct: if you write your application in an open-source language running within an open-source web server on an open-source operating system it makes sense to use yet another open-source firewall product ... just make sure you understand the support model. The good-enough open-source solutions also explain (at least partially) Cisco’s failure in this market segment. However, the choice of the product (and its licensing methodology) should have no impact on the embedded or standalone question.

There are tons of good reasons favoring standalone solution and only a single one favoring the embedded module (it’s cheaper). In the world of virtual servers and virtual appliances deploying another virtual machine carries little incremental cost, so even the cost argument is gone.

And now let’s get to the behavior problems described in Pavel’s comment.

Application folks usually get to choose stuff protecting their application. True, but completely wrong. It’s the same idea as server people choosing the firewall to protect them. BTW, don’t even try to launch the “if they knew something about security, we wouldn’t need a WAF” argument; it will not make you popular.

WAF security should be a Data Center-wide function like firewalls and load balancers and whoever is made responsible for it should choose the best solution for the job, not the one the application people are most familiar with.

Last but not least, there’s always the “checks and balances” question.

Application people usually choose server-based protection. Of course they do, as they already have the web server up and running (see above). One should also consider that they’ll usually deploy tons of web servers for isolation, scalability and redundancy reasons ... and some web servers (or Web UI interfaces embedded in other software products) might not even have a WAF module.

Now step back a bit and look at the bigger picture: is it easier to manage, configure, patch and upgrade tens of modules on individual web servers (with different users having administrative rights) or a single centralized device?

Putting L7 devices managed by network guys in front of public facing servers is a bad idea due to the "it's not our fault" tendency. If this applies to your IT organization, it might be time to polish your resume and consider looking around. If your managers don’t understand where the industry is going, and what they should do to adapt, your users will eventually give up, try to bypass you and move to public cloud services. Definitely a bad idea, but it will happen eventually.

BTW, second part of The Future is Here post by Chuck Hollis has some useful ideas; I know I’ve read something even better, but (as usual) can’t find it when needed.