Nudging Vendors

Gilligan is right, and clever, to invoke patches as a major part of his problem. If a vendor is not convinced that securing applications is a good idea after getting proof of an ROI from securing applications early, or after gaining the favour of large customers by submitting to a certification process or to a contract with strong language, then patches might do the trick.

Patches are like ridiculously complex tourniquets. They are the terrible price everyone - vendors and CIOs alike - pays for 30 years of insecure application development. And they are expensive. Davidson at Oracle estimates that one patch the company released cost Oracle $US1 million. Charney won't estimate. But what's clear is that the economics of patching is quickly getting out of hand, and the vendors appear to be motivated to ameliorate the problem.

At Microsoft, it starts with security training, required for all Microsoft programmers as a result of Gates' memo. Michael Howard, coauthor of Writing Secure Code, and Steve Lipner, manager of Microsoft's security centre (Patch Central), are running the effort to make Microsoft software more secure.

The training establishes new processes (coding through defence in depth, that is, writing your piece of code as if everything around your code will fail). It sets new rules (security goals now go in requirements documents at Microsoft; insecure drivers are summarily removed from programs, a practice that Richardson says would have been heresy not long ago). And it creates a framework for introducing Microsoft teams to the concept of managed code (essentially, reusable code that comes with guarantees about its integrity).

A year and several hundred million dollars later, it's still not clear if the two-day security training for Microsoft's developers is giving them a fish, or teaching them to fish. Richardson seems to believe the latter. She says the training starts with "religion, apple pie and how-we-have-to-save-America speeches". And, she says, it includes at least one tough lesson: "You can't design secure code by accident. You can't just start designing and think: Â'Oh, I'll make this secure now.' You have to change the ethos of your design and development process. To me, the change has been dramatic and instant."

To Microsoft customers, it's a more muted reaction. Since Gates' proclamation, gaping security holes have been found in Internet Information Server 5.0, reminding the world that legacy code will live on. Even the company's gaming console, Xbox, was cracked - indicating the pervasiveness of the insecure development ethos and how hard it will be to change.

Microsoft also faces an extremely sceptical community of CIOs and security watchdogs. Don O'Neill, executive vice president for the Centre for National Software Studies, says: "When it comes to trustworthy software products, Microsoft has forfeited the right to look us in the face."

So let's end where conversations about application security usually begin: Microsoft.

Richardson's reaction to Gates' memo was not much different than anyone else's. "I wondered how much of this was a marketing issue compared with a real consumer issue," she says.

The memo has become a reference point in the evolution of application security - the event cited as the start of the current sea change. In truth, the tides were turning for a year or more, and if a date must be given, it would be September 18, 2001, one week after 9-11 and the day that the Nimda virus hit. Microsoft's entering the fray - as it did with the Internet in 1995, also via a memo - is more an indication that the latecomers have arrived, a sort of cultural quorum call.

It was: "We're all here so let's get started", the beginning of the era of application security as a real discipline, and not an oxymoron.