1) WAF do far more than just prevent SQL injections.
2) Many companies don't own the software they run and so they can't guarantee that it is free of SQL injections or that the version of ORM libraries are secure. WAF protect against this.
3) Auto-scaling is just as much about high availability than performance. Database indexes do not help with the former.
Look, if you want a "real" WAF capability you buy something like Imperva and manage the care and feeding of a team of say 2-4 ppl who understand web app vulnerabilities in depth, AND know the tool. Your SOC/NOC will need training and procedures too. Fully loaded an average enterprise will pay > $1M a year to maintain the capability if you look at the TCO carefully.
There are environments where this makes sense. Banks are the classic - they have the money, they care about the risk, lots of places have systems still on java 8 and take > 1 month to deploy code fixes.
The biggest practical problem in my experience is that it's almost impossible to keep good people maintaining an enterprise WAF. Anyone with a deep enough understanding of web app security and network infra to do the job properly will get bored in the role and leave. WAFs are usually barely maintained for this reason.
Another major issue is alert handling - there's nobody with enough context. The SOC staff usually understand nothing (not the vuln, not web, not the app). The devs don't understand the vuln and the security team don't understand the app so tickets go round in circles with nobody able to understand if an alert is an FP or an actual issue. Eventually alerts start getting quietly dropped on the floor.
Can confirm. I work in financial services, we employ Imperva for WAF + DDoS.
Initial onboard was 2 FTE for ~6 months.
We are now at probably .5-.75 FTE. Onboarding new sites, responding to “waf broke the site”, type things and doing exceptions (for pen tests and what not).
Not sure of the TCO, but I shudder to think what would happen if we didnt have it.
Most enterprises have moved public facing sites to the cloud. And so are making use of the cloud provided WAF solutions all of which are trivial enough for someone to manage part-time.
Also in 20+ years in enterprises have never heard of firewalls being left unmaintained. I don't know how that would pass security audits, why such a critical piece of security architecture would end up in this state or how any in-house development would work given the constant need to make changes to it.
I do agree lightweight cloud WAFs can have positive ROI. You have to be realistic about their capabilities however and what you can expect from a part-timer managing one.
You end up choosing between a heavyweight "advanced" WAF (either cloud or on-prem) that requires lots of tuning and response, which most orgs can't do properly, or a lightweight cloud WAF with vendor rules that doesn't do much but hey at least it's easy to look after.
Re: enterprise WAF maintenance, I know this is anecdotal but I was a pentester for 10 years and I could count the "non-dysfunctional enterprise WAF setups" I saw on one hand. Were you in a role where you talked to the staff who looked after them or dealt with the alerts? Often the org lacked the insight to understand there was a problem. "We bought the magic security box, we applied the patches, what's the issue?"
I did not downvote you, but as the article explains, WAFs don't protect against anything assuming the attacker bothers to spend five minutes bypassing them with one of a thousand well-known tricks.
It's not about competency but the fundamental nature of WAFs. It's like using a regular expression to sanitize input parameters you concatenate into a SQL query, except you also can't make it specific to the SQL dialect used. It doesn't matter how competent you are or how much money you spend on engineering the regular expression.
8KB is a small amount of data. Many apps will need more, so will not be able to blanket block these. Even 64k, what appears to be the absolute limit, might not be enough.
Continuing, not blocking, is the default when not using the console, making this insecure by default.
> 1) WAF do far more than just prevent SQL injections.
They largely don't prevent SQL injections.
> 2) Many companies don't own the software they run and so they can't guarantee that it is free of SQL injections or that the version of ORM libraries are secure. WAF protect against this.
Only if the WAF somehow understands the internals of that software better than that software itself. Which, sure, sometimes happens, but there's no systematic reason to believe it. Why should the WAF have a better hit rate than the makers of the actual application? Does the WAF vendor offer a guarantee that systems behind it wil never be hacked?
The code hasn't, but it would be a lie to say that the application hasn't, and as a leader of ops teams while I can't directly influence code security & quality, I can damn sure influence overall security by demanding a WAF.
Defense in depth is an important concept in security for a very good reason.
You sprinkle it on top of code riddled with SQL injections nobody could be bothered to avoid or fix, and now magically the code has a become secure!
You’ll find it on the shelf next to auto-scaling cloud wizardry, which can similarly be used to fix the total absence of indexes in the database.