Led by Michael Howard (among others), Microsoft has embarked on a serious program of reform and claims it is committed to implementing these best practices. The comprehensive effort begins, Howard says, with mandatory training. Within 60 days of hiring, every developer assigned to a product team is indoctrinated with the principles of what Microsoft calls its Security Development Lifecycle.
"The level of security expertise in the marketplace -- in the industry in general -- is abysmally low," Howard says. "So we need to bridge that gap."
Independent experts, including Schneier, Metzger, and Cooper, can't accurately gauge the extent or the effect of these reforms. But they all know people who work inside Microsoft, and they all relay anecdotal reports that there has been real change in the right direction. Could Microsoft's military discipline make it a leader rather than a follower in the quest for more secure software?
Of course, even if Microsoft did everything right from now on, the sins of the past will be with us for many years to come -- and no one believes that Microsoft is doing everything right. The bottom line? We're in a world of hurt because of Microsoft's past practices. That pain can't and won't go away anytime soon. But some of the right medicines are finally being applied, the results are tangible, and there's a reason for Microsoft to stay the course.
"The problem has always been economic, not technical," Schneier says. "It was never in Microsoft's economic interest to make its stuff secure."
But now, as growing numbers of people abandon Internet Explorer for Mozilla Firefox and as organizations look to Linux and OpenOffice.org as alternatives to Microsoft's OS and productivity suite, the cost of insecure software is starting to be felt in Redmond. If that pressure keeps up, we'll all be safer. Eventually. [Full story at InfoWorld.com]
Like religion and politics, security tends to defy rational discussion. Among open source advocates, for example, it's an article of faith that Microsoft is incapable of fixing the mess it has made. There's also a presumption that open source systems and methodologies are inherently more secure simply because they are open source. While I understand the reasons for these views -- and partly agree with them -- I worry when complex issues are reduced to simple credos.
One of the most interesting things I read, while researching this piece, was John Viega's Open Source Security: Still a Myth. He writes:
All in all, in some cases open source may have more eyeballs on it. Are those eyeballs looking for security problems, though? Are they doing it in a structured way? Do they have any compelling incentive? Do they have a reason to focus dozens or hundreds of hours on the problem to approach the level of effort generally given to a commercial audit? The answer to all of these questions is usually no. A good deal of software doesn't get examined for security at all, open source or not. When it does, commercial software tends to receive much more qualified attention.This observation deserves more discussion than it has received. I'll be particularly interested to see whether SourceLabs and SpikeSource, two newly-announced companies focused on commercial support of open source "stacks," will include security auditing and certification as part of the value they add.
I think Microsoft's software is neither more nor less inherently securable than open source software. When a source code analyzer was pointed at Microsoft's code a few years ago, it found a bunch of bugs. The same thing happened more recently when another analyzer was pointed at the Linux code. It's just plain hard work to write secure software. Microsoft is handicapped by its history of wrong thinking on the subject. But open source ought not rest on its laurels. Everyone needs to work harder, and more importantly smarter. If Microsoft finally starts to be credible on the issue of security, it's good news for everyone -- including open source. The competition between these two software superpowers will keep everyone on their toes.
Former URL: http://weblog.infoworld.com/udell/2004/10/12.html#a1093