The Security Development Lifecycle

Features

• Cover Type: Paperback with 352 pages
• Published by: Microsoft Press June 28, 2006
• Written in: English
• ISBN 10 Number: 0735622140
• ISBN 13 Number: 978-0735622142
• Book Dimensions: 9 x 7.3 x 1.1 inches
• Weighs: 1.5 pounds

Product Description
The software industry has been struggling with how to create and release software that is more security-enhanced and reliable#151; the Security Development Lifecycle (SDL) provides a methodology that works. Adapted from Microsoft's standard development process, SDL is a critical way to help reduce the number of security defects in code at every stage of the development process, from design to release. In addition to a brief history of the methodology, this book details each stage of the SDL methodology and discusses its implementation across a range of Microsoft software, including Microsoft- Windows Server#153; 2003, Microsoft SQL Server#153; 2000 Service Pack 3, and Microsoft Exchange Server 2003 Service Pack 1, to help measurably improve security features. Coauthored by Michael Howard and Steve Lipner, you get direct access to insights from Microsoft's security team and lessons that are repeatable and applicable to software development processes worldwide, whether on a small-scale or large-scale. This book includes a CD featuring videos of developer training classes.

Publisher Description
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

Reader Reviews
I read six books on software security recently, namely "Writing Secure Code, 2nd Ed" by Michael Howard and David LeBlanc; "19 Deadly Sins of Software Security" by Michael Howard, David LeBlanc, and John Viega; "Software Security" by Gary McGraw; "The Security Development Lifecycle" by Michael Howard and Steve Lipner; "High-Assurance Design" by Cliff Berg; and "Security Patterns" by Markus Schumacher, et al. Each book takes a different approach to the software security problem, although the first two focus on coding bugs and flaws; the second two examine development processes; and the last two discuss practices or patterns for improved design and implementation. My favorite of the six is Gary McGraw's, thanks to his clear thinking and logical analysis. The other five are still noteworthy books. All six will contribute to the production of more security software. "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?