Microsoft's New Security Focus: Less and More Than Meets the Eye
January 18, 2002
I have not seen the actual memo, but based on reports, there is both less and more to it than is initially apparent.
Gates referred to the new approach as a "fundamental change," but that is PR spin. Microsoft will continue to stuff its products full of features in order to drive the industry toward software and hardware upgrades.
Some have suggested that Microsoft now will disable more features by default. In the case of Universal Plug and Play (UPNP), which was on by default in Windows XP and contained a buffer overflow exploit, that wouldn't make sense.
UPNP is designed to make using a network easier, so a user can plug in a computer, plug in a printer and have them recognize each other. Requiring every user to navigate through a series of menus to enable UPNP defeats its purpose.
You can think of a company's attitude toward an issue like security as a procession through four stages. First is ignoring it; second is talking about it and hoping employees do the right thing; third is putting procedures in place to deal with it; and fourth is really bearing down to solve the problem.
Microsoft is already between stages three and four with respect to security. Windows XP requires no fundamental architectural changes to be secure, and the code was heavily scrubbed for security bugs back in early 2000. New designs were reviewed at a high level for security flaws.
Windows XP is indeed Microsoft's most secure OS ever, despite the UPNP flaw. As I wrote in an earlier article, Microsoft has the tools available to detect buffer overflows; what it needs is developers who pay more attention.
Months before the Gates memo, the UPNP flap should have been enough to finally drive home the importance of security. I hope that every developer at Microsoft writing code that receives packets off the network now realizes the dangers of a buffer overflow exploit. If they don't, sending them to "security training" probably won't help; sending them to the unemployment line might be more appropriate.
While securing Windows XP merely requires fixing some bugs, the story on privacy (the second area covered by the Gates memo) is much less evolved. Microsoft is just now moving from stage one to stage two with respect to privacy.
Windows XP was not designed with privacy in mind. Of course, having a secure system is the first step required to protect users' data, but the privacy issues might not be worked out until several operating system releases later.
The most important aspect of the memo, however, has not been widely covered by the press. Reportedly, compensation for developers now will be affected by their ability to write secure code.
This is a fundamental change. It shows that Microsoft has, finally, completely internalized the notion that software is not something you ship to customers and then forget about.
Various groups at Microsoft already know that software doesn't just head out the door without the company following it. The product support people learned it first, since that is their job. Next, the sales force began to realize that alternatives to Microsoft existed, and that future sales depended on how satisfied customers were with their existing software. Now, the small parts of product development teams responsible for producing service packs see that software cannot just be tossed over the wall and ignored.
But the core product development teams have remained insulated from the effects of shipping bad software because of the nature of Microsoft's review process.
Microsoft reviews are done every six months. New goals are set, and old goals are evaluated. Bonuses are handed out during every review, raises and stock options once a year. But review periods were intentionally designed to be self-contained.
A review goal like "Ensure my code has no buffer overflows revealed within the first year of shipping" was not just unusual, it violated a policy that stated all goals had to be measurable at the end of the review period. Whatever lousy code you wrote during a particular six-month period, once your review was done, it didn't matter what happened to customers.
Hopefully, this new focus on security during reviews won't just consist of managers asking, "Hey, didja check yer code for them buffer overflows?" To get people's attention, you sometimes have to hit them in the wallet, and it now appears possible that a Microsoft developer actually may get a bad review because of shoddy work done years ago.
And that is very significant.
Adam Barr worked at Microsoft for over ten years before leaving in April 2000. His book about his time there, "Proudly Serving My Corporate Masters," was published in December 2000. He lives in Redmond, Washington and can be reached for response to this column by e-mailing him at: email@example.com.