Crystal ball 2008

January 22, 2008

Strangely, I’ve not seen the usual rash of security predictions for the coming year.  Perhaps I’m not reading the correct blogs (a quick search shows there are a good number), but I’ve seen seldom few direct posts in my RSS aggregator.  Apart from two that I’ve seen today that is - one from the SDL blog, the other from Ivan Ristic (of ModSecurity fame).

Let’s look at the SDL blog’s post first, as it’s quite an easy one to write about.

Vulnerabilities in commercial and non-commercial software will continue to be reported to CVE (as tracked in the US National Vulnerability Database) at a record pace. However, the number of newly reported vulnerabilities in Microsoft products will decrease when expressed as percentage of overall CVE vulnerabilities in 2008 - Eric Bidstrup.

This is a no-brainer.  The trend of vulnerabilities discovered in Microsoft products just on my own anecdotal evidence of following the bulletins (not to mention the stats Eric links to in the post - although different, the trend is upheld in OSVDB with 113 in 2006-2007 vs 68 in 2007-2008).  The significant effort Microsoft are putting into the security of their software obviously seems to be paying off.

My prediction for 2008: I believe that 75% or more of all privacy breaches will not involve an exploit, but will involve some other sort of operational security failure, such as lost or stolen hardware or inadvertent sharing of data. - Adam Shostack

Once again, no surprises there.  First off, it takes quite a lot of effort to grab significant quantities of data from a site or server across the Internet, and in many cases no-one actually knows how much data was actually accessed (remember the TJX case where the number keep increasing every report?).  As Michael Howard predicted ages ago, as systems become more secure, attackers will resort to social engineering and more direct methods.  We’re not at the place of unattackable systems (not yet, and not any time soon), but without encryption on laptops, CDs, backup tapes, hard-disks, etc, this might just be one of the weak links in the chain this year.

My prediction for 2008: I predict that in 2008 we will see at least a 50% increase in the number of Cross-Site Request Forgery (XSRF) vulnerabilities. Bryan Sullivan

I’ve already written about this, and agree.  CSRF flaws are just inherent in web software, and haven’t been taken advantage of nearly as much as they could have been.  Partly I feel that is because there’s so much other low hanging fruit in this area (why do something more complicated than you have to), and partly because CSRF looks so much like “normal” usual behavior, I’m not sure even when it does happen we’d notice it (unless a user complains).  XSS/CSRF worms might be more noticeable by their very nature, but if there was a good, targeted, CSRF attack planted out there somewhere to, say, a popular banking site, and it wasn’t very aggressive, I doubt that you’d get that much noise.  Think the accounting system virus in the film Office Space.

And so finally onto Ivan’s post.  In a nutshell he gives reasons why he thinks it’s the year for Web Application Firewalls (and thankfully points out that it’s been the year for WAF’s previously - but this time it’s different). 

Although many of the points in his argument I’d agree with - both why it was too soon before, and how WAFs are different to network firewalls, however, this is where my agreement stops.

I’m not sure that WAFs will ever catch on fully.  Of course, they can be used in catching certain attacks like SQL injection and XSS in their basic form, and therefore are of some use, but after these attacks are gone what is left are business logic flaws, authorization flaws, and complex design/architecture/filter bypass/general usage flaws.  Just think about CSRF for a moment - would a WAF ever catch that attack, or some subtle privilege escalation.

The issue with WAFs vs. network firewalls is that in the network world, things are very homogeneous - blocking a port on one server is very much the same as doing it on another regardless of hardware/software.  Same can be said of the “old” network attacks like Syn, Smurf, Land, etc - from a TCP/IP point of view they all look the same, so a firewall/stateful inspector/IDS can easily pick them up.  As Ivan points out though, most webapps are bespoke and seldom share many commonalities.  For a WAF to understand them all, and know how to deal with them (unlike a network firewall, simply dropping packets isn’t necessarily the correct thing to do in the web world), to my mind means writing code or significant configuration, which should be done where it is understood the most - in the application itself.  The closer to the code you are, the more context there is, and therefore easier to tell if something is “bad” or not, and what to do with it. 

Sure, there are some circumstances that I can think of where I’d want to throw something quick on a WAF, like for example where an attack vector is known and I want to give myself breathing space to develop, test, and deploy a fix.  With webapps that is possible as in most cases the code is available - I’m sure if more people had (and understood) the code to the TCP stack on their OS they might have decided to fixed the flaws in “traditional” network vulnerabilities and not rely on the firewall to save them (as it only saves you from the outside - just like M&M’s, once inside the hard outer shell of a corporate network you get to the soft chocolaty good stuff :))

I believe that WAFs play a part in a network architecture, and should probably be under the control of the application team rather than the network team (one of the questions in Ivan’s post) so they can can catch low hanging fruit or  throw up mitigations while working on a real fix, but I can’t say with any strong conviction that they will ever be as widespread as traditional firewalls.  Webapp software is just different, and it’s much better to be spending time getting the application right, even if that means pulling it apart and rewriting bits of it, than throwing expensive pizza boxes into the network rack.  Spend the effort looking after the custom software (which is, after all, one of the companies main assets anyway) and you’ll thank yourself for it in the long run.

Posted in Security