Your customers demand and deserve better security and privacy in their software. This book is the first to detail a rigorous, proven methodology that measurably minimizes security bugs—the Security Development Lifecycle (SDL). In this long-awaited book, security experts Michael Howard and Steve Lipner from the Microsoft Security Engineering Team guide you through each stage of the SDL—from education and design to testing and post-release. You get their first-hand insights, best practices, a practical history of the SDL, and lessons to help you implement the SDL in any development organization.

Discover how to:

• Use a streamlined risk-analysis process to find security design issues before code is committed
• Apply secure-coding best practices and a proven testing process
• Conduct a final security review before a product ships
• Arm customers with prescriptive guidance to configure and deploy your product more securely
• Establish a plan to respond to new security vulnerabilities
• Integrate security discipline into agile methods and processes, such as Extreme Programming and Scrum

Includes a CD featuring:

• A six-part security class video conducted by the authors and other Microsoft security experts
• Sample SDL documents and fuzz testing tool

PLUS—Get book updates on the Web.

A Note Regarding the CD or DVD

The print version of this book ships with a CD or DVD. For those customers purchasing one of the digital formats in which this book is available, we are pleased to offer the CD/DVD content as a free download via O'Reilly Media's Digital Distribution services. To download this content, please visit O'Reilly's web site, search for the title of this book to find its catalog page, and click on the link below the cover image (Examples, Companion Content, or Practice Files). Note that while we provide as much of the media content as we are able via free download, we are sometimes limited by licensing restrictions. Please direct any questions or concerns to booktech@oreilly.com.

Microsoft product development groups. The team’s operational concept was to move from component team to component team, meeting with developers and 93 program managers, making recommendations, and filing bugs. The limitation of this incarnation of the SWI team is obvious in retrospect—the team was too small to review all the Windows components. The determination by Windows division management to treat security as a ship-stopper issue constituted a visible management commitment to security.

choose languages, coding standards, and tools with security in mind—and to avoid mistakes rather than fix them—makes for efficiency in time and effort. ▪ Similarly, applying the SDL to a mass of "legacy code" (written before security was a consideration) is expensive. The teams have to find problems, make changes, and then ensure that their changes don’t cause any problems, such as backward compatibility, with the correct functioning of the product or component. 135 ▪ From the two preceding

companies don’t need this class, but for companies like Microsoft, it’s important because the build process must be protected, and the correct security tools must be run on the build. ▪ Security Response. There will be security bugs in products, and it’s important that your team understands what the security response is going 158 to be. This subject is covered in detail in Chapter 15. ▪ Cryptography by Example. This class takes a scenario of two people wishing to communicate securely and

class. 161 ▪ Other experts review the class material for technical accuracy and applicability. ▪ Training (not security) experts edit the class material, looking for consistency and typographical errors. ▪ We deliver a beta class. The main goal of this class is to fine-tune timing and get feedback on content. ▪ We update the class material with the feedback on content. ▪ We deliver the class at least once a month for six months. ▪ After six months, we record the class and put it on the

Chapter 7; appropriate secure development best practices are covered in Chapter 11, and Chapter 12; and threat models are discussed in Chapter 9. 184 Analyzing and Triaging Security-Related and Privacy-Related Bugs Invariably, security and privacy bugs will be detected in the product during development, and such bugs must be triaged accordingly. Reviewing these kinds of bugs requires a great deal of expertise to make sure the correct course of action is taken for each. Some may be fixed with