VA+WAF: that’s hot!

June 19, 2008

So, it seems that the whole VA+WAF discussion is clearly the “hot” topic in webappsec this week.  First up we have the ts/sci post that I linked to earlier, Andre responded, and we also have a post from the guys at CGISecurity.

I’ll first address one of Andre’s comments before getting into the meat of this post, so bear with me for a sec.

If developers are so hard to work with, so miserably stupid, and so unwilling to develop with security in mind — then how can a WAF vendor write secure software for their own products? This is the classic example of where a security vendor assumes that their own products are secure just because they are a security company.

Yes, just because someone is a security company, doesn’t mean that their products are secure – we’ve seen far too many vulnerability in “security products” to even make that claim.  However, there certainly is a scale out there when it comes to the quality code vs where that code comes from – there’s an 80/20 rule, even for programmers.  The 20%-ers are going to be drawn to security issues and security companies (if that’s their “thing”), whereas the rest aren’t going to be interested and just want things to “work”.  They aren’t hard to work with, stupid, or unwilling to develop with security in mind, it’s often that they work in a org where there’s a need to “get it right enough to support the business” (there’s another codinghorror post on this very topic, but by google-foo is failing me tonight).  Ok, we could talk about security being a requirement (which it very rarely it is), “fit for purpose” and all that, but that’s a topic for a whole different post.  The issue is that security is seldom the first thing on an average developer’s mind, nor should it be.

Anyway, I really wanted to know more, and Jeremiah Grossman reached out invited to demo his VA+WAF solution and ask any questions I wanted.  JG obviously has a bias, but wanted to know what I thought as I have no investment in this field (at least, I can’t think of any) other than wanting customers to be more secure.

First things first – WAF is not a panacea to all your security woes.  My thoughts on this, and agreement from JG, is that it’s just a temporary thing until the real cause of the vulnerability is fixed.  My analogy (and I love analogies) is exactly the “band-aid” one people have been throwing around – if you’ve just cut yourself, probably badly, would you at least put a band-aid on it, or cover it with something to stem the bleeding until you manage to get to the emergency room for the wound to be sewn up, or is it better just to leave it open and potentially bleed to death?

A big discussion point with VA+WAF is the false positive issue – if a rule is pushed that isn’t a “real” vulnerability, then is can negatively impact the application.  WhiteHat are approaching this in a “softly-softly” approach, using black-lists on parameters that are “known bad”.  Black-lists I hear everyone say!  Surely for security you want white-lists.  Well, yes, if you have context (ZIP, telephone number, person’s name, etc) but a WAF doesn’t have that (which is why issues really have to be fixed in the code eventually).  Instead, an approach is to not to attempt to “fix” the vulnerability itself, but to just stop exploitation though that vector.  For XSS and SQLi the individual characters that are used in exploits are pretty well understood and shouldn’t ever appear in a a legitimate request, so black-lists work “well enough” in this case.

The other part of the false positive issue is how do you actually know it’s a vulnerability – scanners produce output like it’s going out of fashion, often having hundreds of “findings” to go though.  Which of these can (or should) be blocked at the WAF?  Well, most scanners are pretty good now at identifying XSS (and some instances of SQLi), and as I’ve discussed above, having a rule that simply stops exploitation won’t affect the app as the characters that are “blocked” shouldn’t appear in legitimate requests anyway – no harm, no foul.  Scanners are going to get better, but there’s a whole raft of vulnerabilities that can’t effectively be scanned for (and never will), and can’t be fixed at a WAF.  I don’t believe that there’s ever going to be a “perfect” VA or WAF solution, but starting with XSS and SQLi is a reasonable place to at least start the journey as there’s lots of these issues out there and they don’t seem to be going away.  We are at the beginning of a journey, and just because we haven’t come up with a “unified theory” (and might not be able to) doesn’t mean we can’t start learning from smaller steps.

So, why not just go and fix the code instead – adding a WAF + rule-set just adds complexity and potentially another set of vulnerabilities in the WAF itself.  Although I agree in principal, and back when I was an academic I wouldn’t have budged on this.  Now however, I’m a bit more of a pragmatist – in some cases it’s not possible to immediately go and fix the problem because of change windows, vuln/bug-fix priority, staffing, regression testing, etc, etc.  For the life of me I can never figure out why a site goes live on the net without security QA (I’m often the first person to evaluate a site for security after it’s been in use, and clearly vulnerable, for a significant amount of time), but once again that’s another post for another time.  In any case, in a lot of instances, it’s not as simple that some people make out to simply make an immediate change (any change) in a live webapp.

There’s an article out there somewhere (as I said, my google-foo just isn’t working tonight) that argues that a company shouldn’t have any firewalls, but just to have all hosts out there on the internet.  If everything were patched, configured securely, and had updates applied to them immediately (forgetting for the moment zero-days and non-published vulns), then they wouldn’t be vulnerable right? It certainly would keep everyone on their toes, but I don’t think I know one person that would recommend that approach and I think we are in exactly that position with webapps today. 

Is there a market for VA+WAF – I’m sure there is – it addresses a need (or pain-point) that exists out there.  We know this because even though the “simple” vulns like XSS and SQLi are extremely well known, and fixing them is very simple, there’s still many many apps out there that have these problems and they continue to exist on top x lists.  Is the “right” thing to do?  Perhaps – as a temporary measure until the root cause can be identified and fixed, it at least stops the bleeding.  My main concern about this approach is it becoming a “crutch” and companies relying on it as a way of becoming “secure”.  It doesn’t close the loop, train the developers in the why/how their code is vulnerable and how not to make the same mistake again – it’s the being given fish vs being taught how to fish deal – reliance is not a good thing (perhaps this is a better link – especially the one by gareth ).  JG said that they would be able to see over time how many of the rules pushed to the WAF are later removed and are fixed in the code, which are metrics I would be very interested in seeing.

This is turning out to be a longer post that I really have time for, or anyone would really want to read – it’s just opinions, instead of hard data which I haven’t seen presented yet.  All I can say is that VA+WAF is no magic bullet, and I haven’t heard of anyone that claims it it.  However, just because it’s not a magic bullet, doesn’t mean that there’s not at least some worth behind the idea.

Posted in Musings, Security