- Explore more great deals on thousands of titles in our Deals in Books store.
Enter your mobile number or email address below and we'll send you a link to download the free Kindle App. Then you can start reading Kindle books on your smartphone, tablet, or computer - no Kindle device required.
To get the free app, enter your mobile phone number.
The Security Development Lifecycle: SDL: A Process for Developing Demonstrably More Secure Software (Developer Best Practices) 1st Edition
Use the Amazon App to scan ISBNs and compare prices.
Prepare for your professional certification with study guides and exam prep tools from Wiley. See more
Customers who bought this item also bought
What other items do customers buy after viewing this item?
Special offers and product promotions
From the Publisher
The software industry is clamoring to learn more about the SDL methodology. With insights direct from Microsofts security team, where these techniques have been developed and proven to help reduce code defects, this book premieres SDL to a worldwide audience and is the first to detail the methodology stage by stage.
Key Book Benefits:
Delivers practical, proven advice from the experts for minimizing security-related code defects
Details a methodology that can be applied to any development process, with outstanding results
Includes a CD-ROM with video training classes for developers conducted by coauthor Michael Howard, a security program manager at Microsoft
About the Author
Michael Howard, CISSP, is a leading security expert. He is a senior security program manager at Microsoft® and the coauthor of The Software Security Development Lifecycle. Michael has worked on Windows security since 1992 and now focuses on secure design, programming, and testing techniques. He is the consulting editor for the Secure Software Development Series of books by Microsoft Press.
Steve Lipner, CISSP, is the senior director of Security Engineering Strategy for Microsoft. He is responsible for defining and updating the Security Development Lifecycle and has pioneered numerous security techniques. Steve has over 35 years’ experience as a researcher, development manager, and general manager in IT security.
If you are a seller for this product, would you like to suggest updates through seller support?
Top Customer Reviews
"Security Development Lifecycle" (SDL) is unique because in many ways it exposes the guts of Microsoft's product development process. I cannot recall seeing another technical company share so much of its internal procedures with the public. One of the most interesting aspects of SDL is the attention paid to security after a product is shipped. No one at Microsoft breathes a sigh of relief when boxes appear on store shelves. Instead, Microsoft explains how it conducts security response planning in ch 15 and security response execution in ch 17. (Between the two is ch 16 -- only 3/4 of a page! Why bother?)
Although I liked SDL overall (enough to justify 4 stars), I thought it suffered three major problems. First, I don't think the audience was defined properly. p xviii mentions "managers" as the primary target, along with architects and designers. Specifically, "this is not a book for developers." Yet, ch 12 ("Secure Testing Policies") is definitely for programmers. A manager probably not going to know what a "null pointer dereference" is; at the very least that is not a subject that should be discussed in a book for managers.
Second, I think SDL suffers a little too much overlap with the earlier Microsoft book "Writing Secure Code, 2nd Ed." WSC2E addressed writing documentation, security testing ,and obviously secure coding in much the same language as repeated in SDL. Sometimes repetition is justified, but perhaps those subjects appeared in WSC2E for a reason and did not belong in a book for managers.
Third, and most importantly, Microsoft continues its pattern of misusing terms like "threat" that started with "Threat Modeling" and WSC2E. SDL demonstrates some movement on the part of the book's authors towards more acceptable usage, however. Material previously discussed in a "Threat Modeling" chapter in WSC2E now appears in a chapter called "Risk Analysis" (ch 9) -- but within the chapter, the terms are mostly still corrupted. Many times Microsoft misuses the term risk too. For example, p 94 says "The Security Risk Assessment is used to determine the system's level of vulnerability to attack." If you're making that decision, it's a vulnerability assessment; when you incorporate threat and asset value calculations with vulnerabilities, that's true risk assessment.
The authors try to deflect what I expect was criticism of their term misuse in previous books. On p 102 they say "The meaning of the word threat is much debated. In this book, a threat is defined as an attacker's objective." The problem with this definition is that it exposes the problems with their terminology. The authors make me cringe when I read phrases like "threats to the system ranked by risk" (p 103) or "spoofing threats risk ranking." On p 104, they are really talking about vulnerabilities when they write "All threats are uncovered through the analysis process." The one time they do use threat properly, it shows their definition is nonsensical: "consider the insider-threat scenario -- should your product protect against attackers who work for your company?" If you recognize that a threat is a party with the capabilities and intentions to exploit a vulnerability in an asset, then Microsoft is describing insiders appropriately -- but not as "an attacker's objective."
Don't get me wrong -- there's a lot to like about SDL. I gave the book four stars, and I think it would be good to read it. I fear, though, that this is another book distributed to Microsoft developers and managers riddled with sometimes confusing or outright wrong ways to think about security. This produces lasting problems that degrade the community's ability to discuss and solve software security problems. I also question the implication that SDL is great and everything else doesn't produce verified security improvements. I can understand denigrating Linux, but is Microsoft afraid to acknowledge the security record of an OS like OpenBSD?
The introductory material is weak, part 1 which explores the reasoning and history behind the SLD seemed to be stretched needlessly, repeating the same information multiple times. Chapter 4 which provides the management impact of the SDL lacks focus, and does not justify the need (ROI) for the SDL.
Part 2 goes though each step of the SDL in detail. Overall, this section is more polished and for the most part does a good job of covering each domain in detail. While this book is focused on managerial and operational activities, there are times where it awkwardly delves into specific technical details. Chapter 10 (Documents, Tools, Practices for customers) and chapter 15 (Response planning) are strong chapters which most everyone can lean from.
Part 3 is a series of reference materials. Chapter 20 (Crypto) and 21 (Compiler Options) are good guidelines to compare your organizations own practices against.
+ Talks about a real methodology being used at MS everyday
+ Excellent references, cites many foundation papers
+ Gives the reasoning behind many decisions in development in SDL
+ Good discussion of threat trees
+ Managerial focused chapters are well thought out and complete
- Technical information is MS focused
- Might be acronym heavy for non-technical/security managers
- Does not reference other secure development processes, such as IATF section 3
- Does not reference NIST 800 series for risk analysis
What I would like to see:
*Expanded Chapter 5 (Education and Awareness), giving more information on the curriculum of security classes offered.
*Better balance between the technical and managerial aspects of the SDL. This book would be stellar either with more technical information (platform independent) or by focusing the book more on managerial aspects of the SDL.
*The actual SDL documents being used at MS
Overall, this is a good book, I would recommend it. However I do think a second edition would help this book immensely.
Microsoft is, of course, a huge software development organization. To move the organization into writing more secure code it was necessary to develop plans, procedures, classes for managers and programmer and the like to implement writing more secure code. The resulting effort is called the Security Development Lifecycle (SDL).
The results of implementing SDL are summarized in the Introduction to the book. Here are two newspaper headlines quoted there:
Gartner Recommends Against Microsoft IIS (eWeek, 2001)
We actually consider Microsoft to be leading the software industry now in improvements in their security development life cycle (CRN 2006)
This book is aimed at the people managing and defining software projects. It does not contain very many specific code examples that would appeal to the developer. This is not to say that developers shouldn't read it, but that it is not a detailed techie document.
The CD that comes with the book includes several documents that extend the concepts talked about in the book and a six part security class video conducted by the authors.
One note of caution. This book is on the Microsoft approach to security. It's what they are doing. It works for them. But there are also other approaches such as that being implemented by organizations such as the US Government.
Most Recent Customer Reviews
This is the place to start if you're interested in developing secure software or reviewing systems for security and re3liability.