[转载]A Look Inside the Security Development Lifecycle at Microsoft
原始连接：<A href="http://msdn.microsoft.com/msdnmag/issues/05/11/SDL/default.aspx">[url]http://msdn.microsoft.com/msdnmag/issues/05/11/SDL/default.aspx[/url]</A><BR><BR><SPAN class=clsSearchBox>This article discusses:</SPAN><TABLE cellSpacing=0 cellPadding=0 border=0>
<TBODY>
<TR>
<TD width="55%">
<DIV class=clsDiscuss>
<UL>
<LI class=clsInfoBox>Overview of the Security Development Lifecycle
<LI class=clsInfoBox>Security in the design and development processes
<LI class=clsInfoBox>Threat modeling and testing
<LI class=clsInfoBox>Security reviews and responses</LI></UL></DIV></TD>
<TD>
<DIV class=clsInfoBox><SPAN class=clsSmWhite><B>This article uses the following technologies:</B><BR>Security Development Lifecycle</SPAN><BR></DIV></TD></TR></TBODY></TABLE>
<HR>
<DIV class=articletext>
<P class=clsNoIndent><IMG height=63 hspace=5 src="http://msdn.microsoft.com/msdnmag/images/caps/T.gif" width=44 align=left>he goals of the Security Development Lifecycle (SDL), now embraced by Microsoft, are twofold: to reduce the number of security-related design and coding defects, and to reduce the severity of any defects that are left. This follows our oft-cited motto, "Secure by Design, Secure by Default, Secure in Deployment and Communication" (also known as SD<SUP class=clsSmall>3</SUP>+C). SDL focuses mainly on the first two elements of this motto. Secure by Design means getting the design and code secure from the outset, and Secure by Default is a recognition that you never will. To be realistic, you never will get the code 100 percent correct, but more on this later when I discuss attack surface reduction.</P>
<P>This article outlines how to apply the SDL to your own software development processes. I will explain how you can take some of the lessons we have learned at Microsoft when implementing SDL, so you can use these concepts in your own development process. But before I get started, I want to make clear that SDL is process-agnostic as far as how you go about developing software. Whether you use a waterfall model, a spiral model, or an agile model, it really doesn't matter; you can still use the process improvements that come from SDL. SDL involves modifying a software development organization's processes by integrating measures that lead to improved software security. The really great news is SDL does improve software quality by reducing security defects.</P>
<P>SDL adds security-specific checks and measures to any existing software development process. <A class=clsFigs onclick="OpenUrl('default.aspx?fig=true#fig1'); return false;" href="http://msdn.microsoft.com/msdnmag/issues/05/11/SDL/default.aspx?fig=true#fig1" target=_self>Figure 1</A> shows how SDL maps onto a "generic" process. If it makes you happy, wrap the SDL around a spiral or down a waterfall.</P>
<P>I'll take a look at each major phase and outline what you can do within your own organization to implement SDL.</P><BR><A style="DISPLAY: none" name=S2></A><SPAN class=clsSubhead>Leadership and Education</SPAN><BR>
<P>I'm often asked why SDL has been so successful at Microsoft. The answer is very simple: executive support, and education, and awareness. Getting Bill Gates and Steve Ballmer committed to SDL was critical, but just as critical is an educated engineering workforce.</P>
<P>For leadership, you need to nominate one or more individuals to be the point people for security. Their jobs include staying on top of security issues, pushing the security practices on the development organization and being the voice of reason when it comes to making tough security decisions. (If you're reading this, that person is probably you.) The leadership person or people should monitor the various security related newsgroups, such as Bugtraq (<A href="http://www.securityfocus.com/">www.securityfocus.com</A>).</P>
<P>If your engineers know nothing about the basic security tenets, common security defect types, basic secure design, or security testing, there really is no reasonable chance they could produce secure software. I say this because, on the average, software engineers don't pay enough attention to security. They may know quite a lot about security features, but they need to have a better understanding of what it takes to build and deliver secure features. It's unfortunate that the term security can imply both meanings, because these are two very different security realms. Security features looks at how stuff works, for example the inner operations of the Java or common language runtime (CLR) sandbox, or how encryption algorithms such as DES or RSA work. While these are all interesting and useful topics, knowing that the DES encryption algorithm is a 16-round Feistel network isn't going to help people build more secure software. Knowing the limitations of DES, and the fact that its key size is woefully small for today's threats, is very useful, and this kind of detail is the core tenet of how to build secure features.</P>
<P>The real concern is that most schools, universities, and technical colleges teach security features, and not how to build secure software. This means there are legions of software engineers being churned out by these schools year after year who believe they know how to build secure software because they know how a firewall works. In short, you cannot rely on anyone you hire necessarily understanding how to build security defenses into your software unless you specifically ask about their background and knowledge on the subject.</P>
<P>Some good sources for online and instructor-led security education include Microsoft eLearning (<A href="http://www.microsoftelearning.com/security/">www.microsoftelearning.com/security</A>). The security guidance for developers is derived from some of the security basics material we present at Microsoft.</P>
<P>You should also build a library of good security books, such as those listed in <A class=clsFigs onclick="OpenUrl('default.aspx?fig=true#fig2'); return false;" href="http://msdn.microsoft.com/msdnmag/issues/05/11/SDL/default.aspx?fig=true#fig2" target=_self>Figure 2</A>.</P>
<P>Some groups at Microsoft have set up book clubs where they each read a chapter of a given book and then discuss it with the group. To further their knowledge, they search for examples of defects or design issues from common security stomping grounds, like <A href="http://www.securityfocus.com/">Bugtraq</A>.</P>
<P>Consider having security folks within your company hold presentations on security topics, including common security code defects (buffer overflow, cross-site scripting, SQL injection, integer arithmetic, weak crypto, and so on), secure design, threat modeling, and security testing. To add more depth and relevance to the discussions, find defects in your own code and use them as examples for the rest of the developers.</P>
<P>Finally, engineering staff should be encouraged to update their skills at least once a year—whether on their own or by attending staff development events—and this should be tracked so people don't fall between the cracks. It's really important that people stay on top of the security landscape, as it changes rapidly. A common bug today may be a significant security vulnerability tomorrow.</P><BR><A style="DISPLAY: none" name=S3></A><SPAN class=clsSubhead>The Design Phase</SPAN><BR>
<P>The best opportunity to influence the security design of a product is early in the product lifecycle. This is the phase in which architects, developers, and designers traditionally do the bulk of the feature design. Design typically begins with a very short description of the intended functionality (sometimes in the form of a short functional summary), followed by a functional specification that describes the customer's view of the feature, which is, in turn, followed by a design specification that describes the technical details outlining how the feature will be implemented.</P>
<P>If you're using an agile development method, you may just opt for the shorter one-page summary, but this page should include the security aspects of the component. Functional specifications may need to describe security features that will be directly exposed to customers, such as requiring end user authentication to access specific data or advanced functionality. Design specifications will need to describe how to implement security features, as well as to ensure that all functionality is implemented as secure features. Notice the use of the word secure rather than security. Secure features are defined as ensuring that all functionality is well engineered with respect to security, such as robust use of Crypto APIs, use of managed code wherever possible, rigorously validating all data before processing it, and several other considerations. When designing features, it is crucial to carefully consider security concerns in order to avoid trying to bolt security onto the product near the end of the design process.</P>
<P>All functional and design specifications, regardless of document size, should contain a section describing how the component impacts security. To get some ideas on what to add to this section, you should review RFC 3552 "<A href="http://www.faqs.org/rfcs/rfc3552.html">Guidelines for Writing RFC Text on Security Considerations</A>".</P>
<P>An important part of the design process is to understand how you will reduce the attack surface of your application or component. Anonymously accessible and open UDP ports to the Internet represent a larger attack surface than, say, an open TCP port accessible only to a restricted set of IP addresses. I don't want to spend too much time on the subject here; instead you should refer to my article on attack surface reduction "<A href="http://msdn.microsoft.com/msdnmag/issues/04/11/AttackSurface/">Mitigate Security Risks by Minimizing the Code You Expose to Untrusted Users</A>" in <I>MSDN</I><SUP class=clsSmall>
页:
[1]