Microsoft Developers' School of Hard Knocks

1:55 PM -- Microsoft has been there. And now it's revealing some of the lessons it learned in its ambitious Security Development Lifecycle (SDL) process.

Michael Howard, principal security program manager at Microsoft, has outlined a laundry list of things to look out for when working on building more secure software, based on Microsoft's own experience with its now five-year-old SDL. The tips are in an article in this month's Microsoft's MSDN Magazine. (See Microsoft's Happy Bugfinder).

Some security vulnerabilities are issues with design, not coding, Howard says. A case in point is Microsoft's DNS RPC buffer overrun vulnerability: The code wasn't restricted to systems admins, enabling the bad guys to access it to take over a machine.

Microsoft recommends fixing old code first, because it's most likely to have vulnerabilities, anyway. Phase out old features that don't stand up to today's security threats, or may no longer be useful. That's what Microsoft did with the Alerter service in Windows, Howard says, which eventually got abused by spammers. Microsoft disabled it by default in Windows XP SP2, and then removed it from Vista.

Howard says to use code analysis tools properly -- at "check-in time" to find vulnerabilities in the early phase of development and then regularly to catch new bugs that crop up along the way. Automate as much of the development process as possible and upload scanning results to a site where multiple security folks can analyze it, he recommends.

Even with the best practices, there will always be vulnerabilities, of course: "Zero security vulnerabilities just isn't achievable," Howard writes. Code that appears clean today may contain vulnerabilities that have yet to be discovered. One example: Microsoft's October 2003 security bulletin for a cross-site scripting bug in Outlook Web Access in Microsoft Exchange 5.5 got patched, but six months later, Microsoft had to issue another security update for a newly discovered vulnerability.

Oh -- and don't just dismiss that denial-of-service (DOS) vulnerability: "With a little work, malicious users can turn some DOS into real code execution vulnerabilities," Howard writes. That's a lesson Microsoft learned the hard way as well, he says.

— Kelly Jackson Higgins, Senior Editor, Dark Reading