The State of Web Application and Data Security [Securosis]

June 2, 2009

Great post by Rich as Securosis of where he sees the state of web application and data security at the moment (based on customer contacts).

The first thing I really like about this post is the introduction where Rich outlines the inherent biases he faces as an analyst, and we all face in one way or the other in our industry.  We have our own “thoughts” on what is going on our there, and what should be going on, but it’s really difficult to get over our own biases and see what is really happening and the thoughts of the people that matter (our clients).  Even talking directly to customers you get skewed in a particular direction, so it’s important to take a wide view, aggregate a lot of data, and try an find the big picture no matter how ugly it might look (and be against your own thoughts/biases).

The main content of the post is going though the how/when/why of clients using web application and data security.  I don’t disagree with much of what Rich has written – why should I as it’s come from clients/customers/people in the field – but I certainly have my own insights that I would like to share.

When it comes to web application and data security, if there isn’t a compliance requirement, there isn’t budget

Foundstone certainly has clients that are like that, but looking out our project sheet, I think it’s probably less than 50% of our work that’s obviously tied to compliance.  That’s not to say that perhaps the client has their own motivation/reason for getting us to review a webapp, do a pen test, etc, but there’s a lot of projects on our books that aren’t simply PCI/HIPPA related.

I would suggest the reason for this is that we’re (Foundstone) aren’t known for simply PCI but more of the “higher-end” work.  There’s a lot of “compliance” in our work in that company X tells company Y that they have to have Foundstone look at their stuff before there’s a deal, but for PCI (and the limited scope it has) there’s cheaper options out there.

PCI is the single biggest compliance driver for web application and data security

In the wider world, I have to agree.  I certainly don’t like it, as most companies exposure to security via PCI simply means network vulnerability scanning and unauthenticated SQL/XSS testing – we all know that’s not even scratching the surface.  I guess the sliver lining, if you really squint, is that at least there’s something making companies look at network/app security, and any long journey starts with the first step.  I believe though that companies are “self-leveling” in that they will always do what in their best interests in keeping going as a company and protecting their business – if security was a big deal (their customers demanded it) and there’s a compelling business reason behind it (not just mandated compliance), every company would be doing it, or at least what works for them.  Darwinian survival really – let the customers and companies choose what’s important for them, but that presupposes that they know what they want/need (MAC vs PC adverts for example).

The Web Application Firewall (WAF) market and Security Source Code Tools markets are nearly equal in size, with more clients on WAFs, and more money spent on source code tools per client

and…

WAFs are a quicker hit for PCI compliance

and…

Most WAF deployments are out of band, and false positives are a major problem for default deployments

All add up to a really depressing view for me.  First, the pros and cons of WAFs have been trashed out loads of times, so I’m not going to go into that again.  However, we know that they are not going to find/stop everything (or even a reasonable %age it sounds like from the current state-of-the-art), and the fact that they on an equal footing with security code tools (which being closer to the logic have a much better chance of finding/fixing many more issues than a black-box system) is just wrong IMO.

No surprise that they are being used in PCI compliance though – they are specifically called out as a mitigating control, so an easy choice to make, and are cheep enough to get in lieu of a “real” review, either by a pen-test, code review, or automated scan for that matter.  Also they are a box and something “physical” that people see they are buying for their money.  I’m no accountant, but CAPEX purchases are probably from a different budget and easier to justify (we’ve got something for our money rather than just someone’s time and a pretty report).

The last part though is the most depressing.  Even though WAFs are being used for compliance – more WAFs out there, and a preference to WAFs over security in the code – they are being used out-of-band and suffering from high false-positive rates.  Being out-of-band pretty much means that if they did spot something (forgetting the false-positives at the moment), they can’t do anything about it (directly at least).  If this isn’t shutting the stable door after the horse has already bolted, I’m not sure what is.

Finally, Andre has an interesting point in the comments (although I can’t track it back on one of the main points, so I’m not certain what he was addressing)

The theory that the fault is on the vendors’ ability to set expectations is interesting. However, I think the problem is not that the tools aren’t available and easy to configure, it’s that there are no (ZERO!) people available to run the tools, or that know how to install (let alone run) the tools

My belief is that we’re suffering at the moment that most of the security tools out there are “engineers tools” and not for “general use”.  If you look at most code review or automated scanner tools, to get the most out of them they need quite in-depth configuration and when you get the results often a domain-level expert to interpret them and weed out the false positives and “non issues”.  This makes the experts more efficient, but doesn’t bring the expert-knowledge to the masses (which is what these tools are supposed to do).

The web came to the masses because tools made it easier to create pages (how many people now write HTML directly – I know some of you, myself included, will say “I do!”, but it’s a small population and you really should be spending time on more productive things) and easy to create webapps (PHP and ASP.NET especially really make it simple, not to mention the number of free apps/code there is available ready to download and just use without question).  Until security tools catch up and become that simple, allowing the people writing/developing/deploying these apps to assess the security without having to be an expert with two hats, there’s always going to be a deficiency.

And I guess that’s our problem – we’re running with scissors too fast for our own good.  We’ve not fallen over yet (as an industry – we know companies/people who have but it’s not going to happen to us), and perhaps never will (and if we do, the scissors may miss us or only cause a small cut), but there’s certainly that danger and we should be doing something about it rather than just standing by with the band-aids.

Mom, I’ve just hurt myself!

Posted in Industry, Security