News

Microsoft Talks up SDL

Redmond’s Secure Development Lifecycle requirements aim to counter security defects in the face of recent SQL attacks.

• By John K. Waters
• 07/01/2008

The recent wave of SQL injection attacks has thrown an unwelcome spotlight on Microsoft's application stack. Over the past several months, thousands of Web servers were compromised by an automated SQL injection attack aimed at Microsoft's SQL Server. Since then, the black hats have employed the SQL injection technique to exploit security vulnerabilities in numerous ASP and ASP.NET Web sites.

While much of the havoc wreaked by SQL injection attacks seems to have died down, officials at Microsoft remain on guard and continue to evangelize ways developers can avoid the pitfalls of such exploits. The latest Microsoft official to speak out on this issue is Steve Lipner, senior director of security engineering strategy in Microsoft's Trustworthy Computing Group.

"If we could build Web serving and database engines that were foolproof against SQL injection, we most definitely would," Lipner says in an interview. "I'm not even sure that's feasible. We're getting the word out to developers that there's this problem that's part of Web development."

SDL Evolves
Microsoft is delivering its advice on this issue on the blog for its Secure Development Lifecycle (SDL). Part of Microsoft's Trustworthy Computing Initiative, the SDL is a set of dev requirements aimed at reducing security defects in software. The process outlines a series of security-focused activities for each phase of the software development process, including the development of threat models during the design phase, the use of static analysis code-scanning tools during the implementation phase, and the conduct of code reviews and security testing during a focused "security push" phase. Before software subject to the SDL can be released, it must undergo a final security review by a team independent from its dev group.

In wake of the massive SQL injection attacks, Microsoft has outlined a set of SDL -- required SQL injection defense techniques in the SDL blog (http://tinyurl.com/4gtz2v). On the site, Microsoft software security expert Michael Howard recommends using SQL parameterized queries, stored procedures and SQL execute-only permissions.

SQL injection attacks aren't about specific SQL Server vulnerabilities, but represent a class of errors that can be made whether developers are programming for Internet Information Services, PHP-based systems, MySQL or SQL Server, according to Lipner.

"What we want to do for the industry, and especially for developers on our platform, is to say, 'OK, these are the things we really encourage you to do to avoid having these classes of vulnerabilities in your Web sites,'" he says.

As security guru Gary McGraw, who's CTO of Cigital Inc. and author of several books on software security, including "Software Security: Building Security In" (Addison-Wesley Professional, 2006), has been preaching for years, development managers need to make it a priority to build security into their apps. "Developers don't typically get rewarded for writing secure software," McGraw says. "They get rewarded for features and speed, so it's no wonder they haven't been focusing on this. But I do believe that, given the chance and the know-how, developers want to do the right thing."

“If we could build Web serving and database engines that were foolproof against SQL injection, we most definitely would.” Steve Lipner, Senior Director of Security Engineering Strategy, Trustworthy Computing Group, Microsoft

Coming of Age
One sign that McGraw's message is getting through in Redmond might be seen in the coming of age of Microsoft's SDL model, which has been brewing since 2001.

"Security is now seen as an attribute of good-quality code," Lipner says. "But it's not easy to build secure software, and developers need help. We haven't found the perfect security-development solution yet -- and personally I don't think we ever will -- but we can still make the process of building secure code easier for anyone developing on our platforms."

While observers credit Microsoft for using the SDL in its approach to building its own software, it's less clear how much traction it's gaining among the .NET community.

"The jury is out on whether developers outside the company building software for the Microsoft platform will want to adopt the SDL specifications," says Bola Rotibi, principle analyst at U.K.-based IT advisory firm Macehiter Ward-Dutton Ltd. "They've tried to make the SDL 3.2 [the current iteration] sort of a generic version of what they've done internally with the Microsoft-specific pieces stripped out. That will help, but it remains to be seen how developers will respond."

While there are skeptics who claim that the SDL may not be enough, Lipner believes it can help Microsoft's developer community avoid a repeat of attacks such as the SQL injections. "We're working to get more information, more tools and more training to outside developers," he says. "For the development community, we're still feeling our way to a strategy that will work. But we've done a lot."

"A lot" might be overstating it. There's the blog, the SDL 3.2 specs are now online -- there's an internal version 4.0 -- and there are tutorials for MSDN members. Still, McGraw believes the SDL is a step in the right direction. "Application security is a very serious business today, and we need to teach coders about building secure software while we're teaching them to code," McGraw says. "I'd like to see this stuff become part of a real computer science curriculum."

Lipner has two recommendations for developers who want to accept the responsibility of writing secure code: "First, look at the SDL material and think about what it takes to make your code secure for the environment it's operating in. That's a fundamental. The bad guys aren't going away, and they aren't getting dumber. So implement the SDL or something like it as you build code," he says.

"Second, as you're building applications, use platform services wherever you can. In other words, try to use the underlying system mechanisms, because it seems to me that, as end-to-end trust [Microsoft's proposed system for securing Web apps and services] materializes in software over time, we're likely to integrate it with system facilities, and other vendors will too. So if you've written to the platform APIs, you're more likely to wind up with code that's compatible with the way things are going."