:: extra ::

Software security can be hard to talk about, sometimes because people who make software are an incredibly diverse bunch. I’m not talking about globalization, I’m referring to the fact that the term “software” covers a lot of ground. Building operating systems, web sites, cell phones, and airplanes all require major software chops, and they all require an understanding of security, but they are very different undertakings.

If you’re talking to someone about the new software security initiative you just got off the ground, the result can be wild confusion before you figure out that the other person’s take on what a “software security initiative” means is completely different than your own. I like McGraw’s latest DarkReading column because it gives a nice overview of the different ways people get started.

“What do you do when expertise is not enough?”
Atul Gawande

Hundreds of little decisions per day. Screw up any one of them, and disaster could ensue. Smart and highly trained professionals who know what to do, but who aren’t always focused on the details. A transition from a cowboy mentality to an emphasis on a boring but safe and repeatable process.

Sound like the hymn of software security? It does indeed, but it’s also the way Atul Gawande describes modern intensive care units in his article The Checklist. Intensive care units appear to suffer from many of the same problems the software community faces. Too much complexity creates too many opportunities for error. Little mistakes lead to complications, and those complications can, quite literally, kill.

As with software, there is no easy or complete answer to the problems doctors face in the ICU, but the surprising finding this article points out is that a simple tool, the checklist, is enormously effective. Arm nurses with a five step checklist for avoiding an infection when inserting a line, and secondary infection rates plummet.

Do programmers in your organization have the equivalent for common security-sensitive operations? Maybe those cross-site scripting errors keep popping up because there’s no template to guide programmers as they create new code. If you’re still casting around for one or two more new year’s resolutions, resolve to give programmers good examples they can follow. In the book, we try to give a positive, correct, and secure code listing for every broken, bad, or vulnerable piece of code we discuss.

For as long as there have been breathalyzer machines, DUI suspects have been looking for creative ways to beat them (see newspaper clipping below.) The latest trend is to go after the source code. Here are three recent cases:

• August 2007: Minnesota Supreme Court rules that source code must be revealed.
• December 2007: Source code analysis in New Jersey class-action breathalyzer case.
• January 2008: Kentucky appeals court rules that source code must be revealed.

My favorite anecdote so far comes from the New Jersey analysis. One of the teams used Fortify to analyze the code, and lo-and-behold, they found a buffer overflow vulnerability! This raises the possibility that if you mix just the right cocktail at just the right time, you could craft an exploit. (Dream on.)

The real lesson here is that our legal system is waking up to the importance of code. If the code isn’t trustworthy, the outcome isn’t trustworthy either. (Electronic voting machine vendors, you might want to read that last line again.) If the code provides evidence that the programmers weren't being careful, that's going to be bad news for the vendor.

It appears that a buffer overflow vulnerability in The Legend of Zelda for the Wii, and that’s all hackers need in order to run their own code on the machine. Here’s the scoop.

Pretty soon this will mean game pirating for the Wii without the need to get out your soldering iron. That’s important if you want to get people to steal games in the same casual manner they steal music. Piracy is a big deal for all modern gaming platforms because most of the money comes from software (games) not from hardware.

Apple has run into similar trouble recently. It seems that more than a million iPhones have been unlocked, and I think it’s safe to assume that it’s mostly happening using the simplest mechanism out there, a web site that exploits a buffer overflow in the iPhone. That means Apple is missing out on their cut of the phone subscription going to AT&T, and that has to hurt.
The moral to this story is this: if your business relies on the security of your software, you’ve got two choices:

• Design a system that will be secure even when people discover a few bugs.
• Make sure you don’t have even a single bug.