WhiteHatSec Innovation

March 18, 2008

Congrats to Jeremiah and WhiteHat for integrating their scanner into a WAF.  It’s something I have been talking about (quietly though) for a while in that would really be a killer partnership.  I don’t believe that a WAF is the answer to webappsec, but I also don’t think it provides “nothing” either.  It’s a difficult line to balance, as is being shown in the comments to JG’s post (which are worth reading in-and-of-themselves).

There’s certainly issues with app scanners - their current detection (and false positive/negative) rate is IMHO, appalling, but if you have a vulnerability, and it’s sitting out there on the Internet, then you had better patch it PDQ.  (this completely leaves aside the point that *you shouldn’t be testing for security in production* - at this point, it’s far too late in the dev/release cycle to do anything meaningful IMNSHO).  In any case, if once you/your tool has found a vulnerability, and you can “close” it quickly and safely without much effort, then all the better until you can produce a “real” fix.  Which is another thing for me - just because you’ve pushed a ruleset to a WAF/Firewall, doesn’t mean you’ve mitigated the problem - you’ve just pushed it off to somewhere else that often doesn’t understand the code as well and can have issues of it’s own.  The circle has to be closed eventually, and to my money that has to mean going and fixing the code, although if there’s technology to help buy you some time, then it’s certainly better than nothing.

On a separate note, there’s a very interesting discussion in the comments about product vs SaaS vs consultants.  As readers are aware, I’m firmly in the consulting camp, so please take that in mind when reading the following.

To start with, doing head-to-head against any of these is unfair.  Product can only do what it’s programmed to do at that snapshot in time.  Generally in any review a product only gets a small chance to impress, and if it fails it’s cast aside (which is often what happens in the real world, so I don’t see any problem there).  SaaS on the other hand has some flexibility - there are trained people that can “massage” the service, getting it “unstuck” or doing “tricky” things that a product might struggle with.  Updating the model the SaaS works on might be a little hard, but perhaps not as hard as releasing a new product version with all the testing, regression, QOS, etc, etc, that it has to go through.  Having a human consultant on the other hand allows for that person to really tailor their approach for what they are seeing - if something isn’t working (and they know it should) they can throw everything out the window and do something different - there’s nothing (codebase, workflow, data, etc) stopping them from doing that.

On the other hand, consulting is variable (although it shouldn’t be, and is something I’m working very hard internally at Foundstone to make sure doesn’t come up) - it really does depend on the quality of people that you get.  I, for example, would not be good to put on a wireless security assessment at this time because I’m not skilled in that particular service line.  Foundstone knows this, and ensures that the right people get put on the right engagements (and management are very good at letting us cross-train, so if the urge takes me, I could be doing WiFi sometime in the future).  Even within a service line, the unspoken fact is that some people are better than others.  With SaaS though, you get a little more consistently (depending on how the model works), and with product you get the same results each and every time.

Finally, there’s the cost involved.  Product costs can be kept low(er) because there’s more “users” of the effort to produce the product (return on effort).  SaaS can be a little bit more expensive, and there has to be users and infrastructure behind the scenes to support it.  Consulting finally is a “one shot” thing and obviously is the most expensive of the options if you are going to keep reviewing the same thing - the same amount of effort is expended each time (or can/should be - sometimes it’s possible to “scale back” on areas of work with help from the client on which bits have changed, but sometimes that’s a dangerous practice). 

As the saying goes - you pays your money, you takes your choice.

There’s pros and cons for each of these approaches, and some holistic approach is often the best.  Just because a solution isn’t “perfect”, doesn’t mean it’s worthless, and I think what Whitehat are trying to do is at least a step in the right direction.

Posted in Industry, Security