I soon realised that "ShitFuck!", thus, was a valid password -- and off I went. Meanwhile, a teammate who had previously been a technical writer contracting with the NSA told of the "waterfall method" -- not of software developments, but of passwords. It was common in his world, apparently, and you could always hear he was typing his password by the staccato of QazWsxEdc123, etc.
https://pages.nist.gov/800-63-3/sp800-63b.html#memorizedsecr...
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.
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.
I didn't realise AWS, Cloudflare etc were so incompetent that their product can be bypassed in 5 minutes. I assume you have an example of this.
Maybe you should read it.
https://docs.aws.amazon.com/waf/latest/developerguide/waf-ov...
For oversize requests WAF can be configured to reject it.
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.
And having an insecure default is a huge difference from 100% of requests are allowed.
This guide, linked from the article, shows some simple evergreen bypass techniques (section "WAF bypass cheat sheet"):
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.
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.
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?"
https://accelerationeconomy.com/cloud/amazon-shocker-ceo-jas...
And the article you posted is about total spend not just infrastructure.
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.
We have a lot of…old…java…
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.
It could become less secure too, as WAF software itself can have vulnerabilities or misconfiguration.
Honestly AWS WAF is perfect for this. It's not a great WAF but it is ideal if you need "pretend to have a WAF" as a service so you can tick the box.
Compliance auditors are mostly there to underwrite posture, not actual risk.
Just as financial auditors are only confirming that your financial statements match what your accounting department tells them.
If you lie to your auditors, there's a good chance they won't catch it because that's not what they are looking for.
Security auditors are (quite literally) accountants.
Amateurs.
I guess there's just a decent market for the product everyone trying to check that box, though.
What matters, of course, is money.
Only if the WAFs themselves become a significant attack vector, to the extent where blame for breaches affects the bottom lines of the WAF vendors, the situation will start to change.