Microsoft Helps Developers Write More Secure Code

REDMOND, Wash. — Feb. 2, 2010 — The past 15 years have seen the motive behind security threats shift from a desire for infamy to, increasingly, a desire to steal. Today’s attackers are no longer script-kiddies looking for kicks. They’re sophisticated criminals after money, not “one-upmanship” over professional software engineers.

As a result, attackers will exploit any vulnerability in order to infiltrate a network, no matter where in the software stack they find it. So application developers are increasingly finding their code being put to the test.

Security threats are moving up the software stack, says David Ladd, principal security program manager of Microsoft’s SDL Team.

Version 7 of Microsoft’s Security Intelligence Report shows that for the first six months of 2009, 81 percent of reported vulnerabilities were in nonbrowser applications, 5 percent were in Microsoft products and the remainder were in browsers.

“Security is not something app developers have prioritized in the past,” says David Ladd, principal security program manager at Microsoft. “Their focus has been getting a product that has a competitive edge in terms of features and functionality to market as quickly as possible. That’s not a criticism, it’s just a factor of commercial priority.”

The shift in the nature and target of threats is challenging application developers to produce code with fewer vulnerabilities. Doing so results partly from a professional incentive to “do the right thing,” but there is also potentially a commercial gain and an opportunity to improve productivity.

“It’s our experience that companies that demonstrate not only an awareness of software security, but also a commitment to addressing it, stand out from their competitors,” says Vincent Liu of security services firm Stach & Liu. 

Any apparent reluctance on behalf of the application developer community to embrace more secure development practices is not a question of desire. According to Ladd, “most software developers want to write more secure code. However, many just don’t know where to start, or assume security means added cost and longer development cycles.”

As a member of Microsoft’s Trustworthy Computing (TwC) Group, Ladd is better qualified than most to comment on what it takes to produce software code more securely. Throughout the late 1990s Microsoft’s Windows platform became a popular target for virus writers and other cybercriminals. In 2001, a rash of “superworms” such as Nimda and Code Red escalated what had previously been mainly a nuisance problem into an issue that disrupted organizations’ operations.

In January 2002, concerned about the potential of such attacks to erode trust in the Internet, Microsoft formed the TwC Group. One of its tasks was to drive a culture of security through the company’s development operations.

TwC took on responsibility for the Security Development Lifecycle (SDL), a security assurance process designed to reduce the number and severity of vulnerabilities in software, taking it to the point where, in 2004, SDL became mandatory for all Microsoft products.

“Writing code with zero vulnerabilities is not possible,” says Ladd. “We still have plenty of work to do, and attackers will continue to pose threats. But our experience is unique among software developers. Over the past nine years or so we’ve learned the hard way how to develop code more securely. We believe the SDL process is an industry best practice.”

Based on a belief that more secure code benefits the entire industry, Microsoft has committed to sharing with the broader developer community the expertise that has gone into producing the SDL by releasing free secure development tools and expertise in the form of white papers and other instructional guidance.

Since April 2008, the SDL Group has publicly released four tools, including the SDL threat modeling tool, the Minifuzz file fuzzer, the Binscope binary analyzer, and the SDL Process Template for Visual Studio Team System. The developer community has been quick to take advantage; in total the four tools have been downloaded over 48,000 times, and 10 sets of SDL guidance materials have been downloaded over 75,000 times.

“We could take the view that we created the SDL, it’s ours and we’re keeping it,” says Ladd. “But what’s the point in that? An entire developer community that creates code with fewer vulnerabilities is not only better for Microsoft, but for everyone. By sharing what we have learned we hope to help accelerate the learning process for other developers.”

“The SDL tools made available by Microsoft’s software development security program are the very same tools they use to harden Windows, and here they are offering them freely to the public,” says Liu.

The latest set of SDL tools and guidance will be released at the Black Hat DC event in Washington, D.C., on Feb. 2.

Ladd calls attention in particular to a guidance paper titled “Simplified Implementation of the Microsoft SDL,” which aims to help development organizations, regardless of size, adopt SDL-type secure development practices.

“Because Microsoft created the SDL, some people think they have to have Microsoft-like resources to be able to implement it,” says Ladd. “It’s true that we do invest a lot in the SDL, but that’s largely because we have so many products that go through it. This paper sets out how any development team — even teams of eight to 10 developers — can implement the SDL.”

The 18-page document describes a step-by-step approach to implement SDL practices and improve an organization’s ability to develop code more securely without significant additional cost or resources. Furthermore, because the SDL is not proprietary to Windows, the techniques described can be applied to applications developed for other platforms.

Enhancing the SDL

At Black Hat DC, Microsoft will also release a downloadable template for applying SDL methodology to the Microsoft Solutions Framework (MSF) for the Agile Software Development process. The template for Visual Studio 2008 is available now as a beta (planned for release at the end of Q2); a version for Visual Studio 2010 will be available shortly after Microsoft releases that product in April.

The MSF-Agile+SDL process template enables developers to integrate the SDL-Agile secure development methodology directly into the Visual Studio Team System (VSTS) development environment. With the MSF-Agile+SDL template, any code checked into the VSTS source repository by the developer is analyzed to ensure that it complies with SDL secure development practices. The template also automatically creates workflow tracking items for manual SDL processes such as threat modeling to ensure that these important security activities are not accidentally skipped or forgotten.

Microsoft will expand the SDL Pro Network, which was set up in November 2008. SDL Pro Network members are specialist security organizations that offer services to help organizations adopt the SDL.

Microsoft also will announce the creation of a Tools membership category to complement the Consulting and Training categories. Tools members are companies that are able to deploy a range of security tools, such as static analysis tools for the Implementation Phase and dynamic and binary analysis tools for the Verification Phase.

Finally, Microsoft will announce seven new members of the SDL Pro Network:

  • Fortify (Tool Member)

  • Veracode (Tool Member)

  • Codenomicon (Tool Member)

  • Booz-Allen Hamilton (Consulting Member)

  • Casaba Security (Consulting Member)

  • Consult2Comply (Consulting Member)

  • Safelight Security Advisors (Training Member)

More information about the Microsoft SDL Pro Network and tools is available through the SDL portal.

Related Posts