WAFs and risk appetite
opportunities lie.
First of all I would like to remind you that seldom software nor appliances will suite your use case, in this case protecting a web application, out of the box.
You will need to do some configuration tweaking on a per application level, however
exactly this configuration is the challenge of any WAF installation.
A very short on the common approaches WAF's take:
- Whitelisting
Allow only requests which have been explicitely authorized
- Blacklisting
Deny all requests which are explicitely mentioned in the ruleset
- "Anomality scanning"
Checks for unusual requests or correlation of requests and if e.g. a prefedined score is reached the request is denied.
For the fastest time to market you would most likely want to (partially) rely on a self learning mode at the deployment or change phase of a web application. The good news is that there are quite a few vendors out there who offer this feature.
Now the best protection would result from a combination from all approaches, but future key for myself is "anomality scanning", although in my opinion there is still room for improvement in this field.
No matter which of the above configuration approaches you or your technical staff wants to take, the person configuring the WAF is key and needs to be an expert in Web Application Security and the WAF you are using.
To find the right balance between false positives (hinder business by not allowing valid requests) and false negatives (allowing malicious traffic) is not to be underestimated.
A well configured WAF, at the given time, introduces a medium to high level of security. Please be aware though that this is a statement about application security. Successful attacks to go past WAF's (such as HTTP Request Smuggling and the challenges WAF's usually face with e.g. AJAX) or direct attacks to WAF appliances are not common grounds yet, meaning that your next door script-kiddie will most likely not have much success.
Do not forget that you are introducing an additional level of complexity and that you should put reliable processes in place which at the very least consider initial deployment, change management (you can imagine how happy marketing would be if their revamped web-app would not be usable on campaign start) and capacity management.
Depending on your risk appetite you might chose to "directly" allow traffic to an Intranet application, you should keep in mind to, if not done already, protect internal critical systems.
In fact this would be yet another argument to protect your internal (intranet only facing) systems, I'll mention some more in a separate article.
So what is your risk appetite?
Responses
Re: WAFs and risk appetite
Risk appetite - that is a very good point, actually!
In my experience one of the biggest WAF risks is the tight coupling of applications and their whitelist rules. With most 'learning modes' the learning process has to be repeated whenever the application changes. And that can be very often: Think of a CMS might where the whitelist rules might need to be changed whenever new content is published. That is a lot of work, even if the learning mode helps.
I prefer dynamic whitelisting where the WAF learns at runtime - a learning phase is needless then. As a result, the maintenance effort of the WAF rules is dramatically reduced. Whitelisting is an area where WAFs still differ a lot. I recommend looking for dynamic whitelisting features (e.g. URL encryption) instead of a learning mode that generates static whitelists.