Hacker News Reader

Comment by beardedwizard | Hacker News Reader

WAFs were a band aid over web services that security teams couldn't control or understand. They fell out of favor because of performance and the real struggle tuning these appliances to block malicious traffic effectively.

WAF based approach is an admission of ignorance and a position of weakness, only in this case shifting right into the model is unproven, can't quite be done yet, contrary to ideas like reactive self protection for apps.

View on HN

A third of the web runs on Wordpress last I checked and that install base is largely maintained by small businesses who outsource that process to the least expensive option possible. If they do it at all.

A WAF is a good thing for most of that install base who have other things to do with their day to make sure they survive in this world than cybersecurity for their website.

That would only be true if WAFs weren't so easily bypassed: https://habr.com/en/companies/dsec/articles/454592/

WAFs are a key part of a defense in depth model.

Also, I don't understand this sentence: "WAF based approach is an admission of ignorance and a position of weakness, only in this case shifting right into the model is unproven, can't quite be done yet, contrary to ideas like reactive self protection for apps."

The vast majority of WAF deployments seem to be plain defense rather than defense in depth. I.e. WAFs aren't very often deployed because someone wanted an additional layer of protection on top of an already well secured system. Typically they're deployed because nobody can/will add or maintain a sensible level of security to the actual application and reverse proxy itself so the WAF gets thrown in to band-aid that.

Additionally, a significant number of enterprise WAFs are deployed just minimally enough to check an auditing/compliance checkbox rather than to solve noted actionable security concerns. As a result, they live up to the quality of implementation they were given.

I don't think I agree with you, but it's hard to know one way or the other because you've not justified any of your positions, just offered opinions.

Can you back up your statements? I'd be really interested in that.

To be fair, it the most honest product description available. A traditional WAF is - at best - a layer of security that is not guaranteed to stop a determined attacker. This service is the same - a best effort approach to stopping common attacks. There is no way to deterministically eliminate the classes of attacks this product defends against. Why not try and undersell for the opportunity to overdeliver?

Eh, I wouldn't say they fell out of favor in "the enterprise". There are an awful lot of Fortune 500-type shops with WAFs via Akamai or Cloudflare.

They definitely haven't. But that's mostly not due to how effective they are. It's more due to the fact that some regulatory or industry standard the enterprise promises to follow requires a WAF to be in place. If not by directly requiring then by heavily implying it in such a way that it's just easier to put one in place so the auditor won't ask questions.

WAFs are a manifestation of Conway's Law: The people responsible for securing the company's web presence are not in general the same as the people implementing the web request. When some API has some security issue, the securing team needs some mechanism to handle the issue faster than the API can be fixed. With that specification, you pretty much end up with a WAF, once you've been around the design space a few dozen times to refine the final product.

If you are not a large corporation it may seem silly, but as the corporations scale up they become simply a necessity. If you like, call it "non-technical reasons", but it doesn't change their necessity.

WAFs do things like securing an API written years ago by people no longer at the company, that for legal reasons can not be "just" modified or taken down, but which also can't be left with an arbitrary code execution vulnerability in it.

By all means when possible fix the real underlying vulnerabilities, but at scale that gets to be easier said than done. In real life you may be arguing for weeks about whose "fault" it is, whose responsibility it is, whether it is even a bug or a real issue, and in the meantime, the company wants some ability to deal with this.

I totally agree - for companies with opportunities to embed security more deeply, waf is rarely the right choice

It’s not that simple. You’re right that many places have compliance policies but that’s not all, or even most, of the benefit. WAFs are useful any time you don’t have a team of experienced 24x7 engineers who have complete control and knowledge of each and every application on your network, which isn’t the case for any large organization.

When things like log4j come out, it’s really nice to be able to have a vendor like Cloudflare or AWS deploy a single rule off-hours which will cover all of your public facing services, especially when some of them are not your own code or hard to deploy. It’s one thing if a patch is a single line change pushed out in your CD pipeline than if it’s “beg the vendor for an update, get an emergency CAB approved, and follow the 97 step Word document”.

> which isn’t the case for any large organization.

…and it isn’t the case for most small organizations either.

I agree but it’s more possible this far into the cloud era that, say, a small business might have outsourced everything but their own application.

> It's more due to the fact that some regulatory or industry standard the enterprise promises to follow requires a WAF to be in place.

This is the comment I was looking for. This is exactly right, most companies do it to check a box for compliance.

Sure, but I think you can make the same comment about the motivation behind and effectiveness of almost any security measure in the enterprise space. WAFs aren’t particularly bad or particularly ineffective… They just aren’t good.

Sure, but I think you can make the same comment about the motivation behind and effectiveness of almost any security measure in the enterprise space.

Hence the notion of layering and "defense in depth". But as old as this idea is, it seems like some people are still looking for / expecting silver bullets that magically "fix security". Also consider threat modeling... what security measure one needs to take are driven at least in part by factors like "how valuable is what you're protecting?" and "what are the expected capabilities of the enemy who would be attacking you?" and so on.

WAF shouldn't be the only line of defence. It's just another layer in the security onion.

> WAF based approach is an admission of ignorance and a position of weakness

Sure, but what about the benefits?

Let's say you've got an ecommerce website, and you find XSS.

Without a WAF that would be a critical problem, fixing the problem would be an urgent issue, and it'd probably be a sign you need to train your people better and perform thorough security code reviews. You'll have to have an 'incident wash-up' and you might even have to notify customers.

If you've got a WAF, though? It's not exploitable. Give yourself a pat on the back for having 'multiple layers of protection'. The problem is now 'technical debt' and you can chuck a ticket at the bottom of the backlog and delete it 6 months later while 'cleaning up the backlog'.

it is totally fair to say that a position of weakness is still defensible - I agree. But it should be a choice, for some it doesn't make sense to invest in strength (ie more bespoke or integrated solutions)

Reply on news.ycombinator.com