Page (1) of 1 - 06/21/06
email article 
print
page
Baking Security In
A Microsoft security expert explains how the company has improved its development process
By Esther Schindler
"All software has security defects," insists Michael Howard, senior security program manager at Microsoft. "You either do something about it, or you don't."In the past few years, Microsoft has learned to write more secure code. In a session given at last week's TechEd conference, Howard explained some of the lessons that the company has learned in developing its Security Development Lifecycle (SDL), and shared advice for developers who want to improve the quality of their own code.
Microsoft? Serious about security? Perhaps you scoff at the very idea. Yet, Howard insists, Microsoft has changed everything about the way it creates software. "The industry as a whole thinks that security means features," he explained, such as Kerberos or encryption tools. But "baked-in" security involves thinking about threats in every part of an application, even the method by which you generate random numbers.
Security, insists Howard, is a holistic process. "What worries me is how little attention [software] vendors are paying to this," he said. "I know of nobody else who has changed their process."
With more than a dozen "stages" necessary in the security development lifecycle, he's often asked which is the most important, or which one should take precedence. "If it didn't have demonstrable improvement, it wouldn't be in the SDL," Howard said. Microsoft reviews the SDL process twice a year, and for a stage or item to be included, the Microsoft employee has to show five bugs that the proposed change would have prevented. "Everything in the SDL is there for a reason," he said.
Howard, who co-authored the just-released book, The Security Development Lifecycle (Microsoft Press) among several others, itemized the various stages in the SDL, from education and awareness, to risk assessment, past the final security review. While the company has no hard numbers on the cost of adding this process to their product development, he said, "We estimate it on the order of [a] 12%" increase in development cost. Yet, even those numbers are difficult to provide, because Microsoft is seeing improvements even in it non-security development; after a product has been through the SDL three times, he said, the general testing phase gets shorter and shorter.
Tools do not make a code secure, stressed Howard. They help scale the process and they help enforce policy. But, while a good tool can help developers find source code implementation problems, they don't help you discover design flaws. "I love tools," said Howard, "But they're not a crutch to rely on."
As just one example of the SDL process, the first step is education, which is a requirement for all engineers. Microsoft developers must take a class once a year, starting with a four-hour video whose purpose is to show you how much you don't know. (Every developer, he says, is sure that he's already an expert.) In-depth classes go into the details of fuzz testing (creating malformed data and having the application under test consume it to see how the software reacts), using crypto effectively, or SDL for managers.
Towards the other end of the SDL is the final security review, a mandatory step before any product can be shipped; it usually takes about ten weeks. For a "big" product, the final security review includes external (non-Microsoft) review, a code review, a threat model review, and a bug review. (That might not be all!) For Microsoft Vista, Howard, said, they've already spent nine months on the Final Software Review -- and they're not done. This process is brutal, he said; the penetration testing lab in Redmond is full of people "who will shatter your ego in moments."
That isn't the end of the SDL, though. A post-bulletin process occurs for every security bug that the company missed. One engineer is dedicated to finding out, "Why did it happen? Why did we miss it? How does this bug affect other platforms?"
The SDL does need to be tempered with reality, and Howard warned against security myopia: making software that's secure but unusable. "You can write very secure code that nobody uses," he cautioned.
recommend this article
Page: 1
Esther Schindler has been writing about technology professionally since 1992, and her byline has appeared in dozens of IT publications. She's optimized compilers, owned a computer store, taught corporate training classes, moderated online communities, run computer user groups, and, in her spare time, written a few books. You can reach her at esthers@digitalmediaonlineinc.com.Related Sites: IBN - IT Business Net , IBN - Internet , IBN - Security , IBN - SoftwareDev
Related Newsletters: IBN - IT Weekly Newsletter
Source:Digital Media Online.
All Rights Reserved
