Catching up…

August 16, 2008

What with the IR gig I’ve been on, work just being out of control at the moment, as well as the usual flurry of posts after BlackHat/DefCon, I haven’t been able to keep with my reading, let alone posting.  There’s been a lot of interesting things going on which have received plenty of coverage that I would just add to the noise to as I’ve nothing more to say than everyone else has.  However, there are two things that I have seen that I want to comment on.

Security is much more than finding/fixing defects

The first post I saw on this was from Ivan Ristic, where he says…

Underneath all our security issues lies our inability to write defect-free code. Solve that and we’ve solved the security issues. Focus on the security alone and we won’t solve anything.

This sort of follows from a really old post on the Microsoft SDL blog from James Whittaker - Reliability Vs. Security.  Defects are defects, functional or security, and we’ve been working on the former for some time.  Our techniques are better, and we’ve learnt a lot, but we still can’t write error free code, and there’s a lot of prior art/knowledge in the functional side that the security side has to catch up with.  One of my favorite (old) quotes is from Chris Mason, ex-development manger for MS-Word, who said “Since human beings themselves are not fully debugged yet, there will be bugs in your code no matter what you do”.  This leads me to the most recent post on the topic that I saw (also on the SDL blog) from Michael Howard.

Security is bigger than finding and fixing bugs

This isn’t any deep insight or rocket science, but it seems that some people have to be told it anyway.  Yes, currently there’s a lot of security issues being found after products are released, and they often track back to implementation issues (leaving aside for the moment if there were any security requirements), so people think if you patch the issues and/or look at the code then that’s 80% of the work.  This might be true for now, but so much of these things could get caught at the design or even implementation stage.  Also, I would bet that over time implementation flaws are going to start to go away as we code up defenses in frameworks, languages, API’s, etc, much like buffer overflows are much less of a worry in managed code.  Even if we get to that point there will still be vulnerable system out there because of poor design decisions, failed logic, and other problems that are simply not associated with the code at all.  Focusing on the code (and therefore testing/fixing just the code) is IMO the wrong approach.

MBTA vs MIT Students

Talking about flawed design, here’s a good example that I’ve seen lots of posts about.  The best intro is from Chris at Veracode here and here.  Basically, the Massachusetts Bay Transportation Authority (MBTA) is (was?) suing some students to stop them from presenting about a flaw that they discovered in their payment card system (turns out many other transit authorities the world over also use the same system, and thus vulnerable the same way).

I first can’t believe how basic the vulnerabilities are (which surely would have been caught in requirements/design than the much-more-expensive delivered system - once again, testing/code is not the answer), and second that anyone would defend what the MBTA is doing in suing the students (even though I understand it’s “risk prevention” on their part - this is not the right place to do that).

This leads me to something that has been going on for some time in the functional world, and perhaps needs to from a security aspect as well - software warrantees.  When someone purchases a physical item there’s an expectation of “fitness for purpose” - if it doesn’t work you can take it back for a refund, and if it blows up in your face (during “normal” use) you can sue the manufacture.

It’s extremely rare to find any warranty for software products, and the EULA is often the “get out of jail” card for the implied warranty.  I’m not sure that we’ll ever see true software warrantees because of push-back from software producers and the additional cost it would (could?) add.  However, having enforceable software warrantees would both force vendors to ensure that their software is “fit for purpose” (which in the MBTA case it clearly isn’t) and allow the purchasers of said software some rectification - I’ve had my fair share of clients that I’ve worked with that have had real problems in getting fixes to vulnerabilities I’ve found in fixing them in a timely manner because they don’t really have to.  For some purchasers (government(s) being a good example as Schneier points out) forcing these (because of their purchasing power) would force an improvement in quality, both functional and security, that would benefit everyone even if it’s only in one version/variant that you could buy if you wanted that level of expectation.

In any case, I’d like to know anyone’s thoughts on this.

(As a further resource, badsoftare.com is a site an old colleague of mine put together a while back that might have some interesting information for people.)

Posted in Industry, Musings