This is going to be preaching to the choir, but I don’t get to link enough to Hoff these days (my head is not up in the cloud, unless you count my 90% virtualized environment), and he gave an easy-to-agree-with post about WAFs:
How many infrastructure security folks do you know that are experts in protecting, monitoring and managing MBeans, JMS/JMX messaging and APIs? More specifically, how many shops do you know that have WAFs deployed (in-line, actively protecting applications not passively monitoring) that did not in some way blow up every app they sit in front of as well as add potentially significant performance degradation due to SSL/TLS termination?
I’d add to this even further. What team should be involved in the WAFs? Developers. But which team does this duty get shouldered upon because of the ease to tie a WAF onto the chokepoint appliance in the network? The network team. Maybe even the web systems team. Which team has no idea how to tune a WAF? All of the above. Why? Because it spans layers that none of those teams are wholly familiar with, from data to app to protocols to network. Maybe QA should be the answer, but I don’t have the feeling that many shops value their QA that way…
Of course, Hoff’s last statement is really a business cultural issue, and unfortunately the only way anyone has a chance to learn how to get any value out of a WAF. Sure, put it in a test environment, but how many developers, infrastructure, or security guys have the time to interrupt the others as they bounce around in the WAF? I don’t know about all sysadmins out there, but even “test” environments for developers are “production” in my eyes. If I make a change and bring a test server down for an hour, I get developer managers giving me the hairy eye…
(Side note: Want to gain some real good experience? Adopt a real, honest, working WAF, get permission to implement and toy with it, and go to town. Figure out what kills apps, figure out what attacks look like to the app you’re protecting, and figure out how to block them. Sure, this might mean a whole “sub”-project in learning attacks on web apps, but all of this is great practice to gain some experience in an area I think is still sorely lacking in real experts beyond pointing WebInspect at a URL. You can do this at home, but I feel like you’re bounded by your knowledge and use-cases, and not all the things that happen in day-to-day dev/qa/network/internet traffic. But if you *do* do it at home, start with all those vulnerable-web-apps-in-a-box setups and learn the attacks. Then put a WAF in front and block said attacks…hmm maybe I should do that again!)
May I present an alternate view?
My suggestion is to skip on WAFs entirely. It’s better to replace your Apache with Nginx so that you can run Roboo than to apt-get a ModSecurity embedded module for an already insecure Apache.
WAFs are neat for protection if your problems are input validation. However, not too many appsec issues are affected by more-specific input validation (and especially not without good canonicalization and other anti-obfuscation capabilities).
One of the best features of WAFs is to add in anti-CSRF tokens or other anti-automation. However, Roboo does that much better.
There is also one interesting monitoring capability of ModSecurity that I enjoy — the ability to detect outgoing XSS attacks. See the “Application Defect Identification” section of the old Ryan Barnett paper — http://www.blackhat.com/presentations/bh-dc-09/Barnett/BlackHat-DC-09-Barnett-WAF-Patching-Challenge-Whitepaper.pdf
It’s best to tie some sort of monitoring to a SOC viewed in a SIEM. I suggest using a combination of syslog data, ModSecurity audit files via OSSEC, MySQL (or other RDBMS) udf_log capabilities via OSSEC, and AppSensor or similar internal app instrumentation. This combination will allow your SIEM (e.g. OSSIM) to have the data it needs in order to properly correlate and understand some web application layer attacks in order to prioritize and operationalize additional appsec controls or assessments.