SDL-Agile Example

A database-driven web product is currently in development by a team with a four-week sprint duration. It is primarily written using C# and ASP.NET. There is a Windows service that processes some data from the web application. The service was originally written three years ago and is about 11,000 lines of C++ code-it's pretty complex.

Input to the web application is mostly unauthenticated, but it does offer a remotely accessible admin-only interface. The application also uses a small ActiveX control written in C++.

The product backlog includes 45 user stories-21 of these are high-priority stories, 10 are medium-priority stories, and 14 are low-priority stories. During the sprint planning phase, 10 user stories are selected for the current sprint, 3 stories are high priority, 3 are medium priority, and the final 4 are low priority.

At this point, the team adds technology stories for each of the every-sprint SDL requirements. Even though the product uses both managed and native modules, the team is only working on the managed- code modules during this sprint, so only the every-sprint tasks that apply to managed online services are added to the sprint.

Since this is the first sprint in which the team is using the SDL-Agile process, additional high-priority stories are added to complete some of the one-time requirements (for example, registering the project in the security compliance tracking system, creating a privacy form, and identifying a privacy incident response person). One more high-priority story is added to update the build process to integrate the SDL-required, every-build requirements (use of the SDL-required compiler and linker flags and integration of the FxCop security rules).

Finally, the team also adds in high-priority stories for the bucket tasks that the team wants to complete during the current sprint. For this sprint, the team chooses to add tasks to run an attack surface analyzer, review the crypto design of the system, and create a content publishing and user interface security plan.

The sprint begins, and two people on the team take on the task of building the threat model for the features to be developed during this sprint. The big problem is that no one knows how to build a threat model, so the two people read the threat modeling chapter in The Security Development Lifecycle and read Adam Shostack's series of threat modeling blog posts. This gives them enough information to perform the threat modeling task.

After the threat model is built (and the corresponding story completed), the team uncovers a critical vulnerability-the database contains sensitive data (users' names, computer information, browser information, and IP addresses), and the data is not protected from disclosure threats. Because the data is sensitive, and it appears that unauthenticated attackers could access the data through a potential SQL injection vulnerability, two more high-priority stories are added to the sprint backlog-one to add defenses to protect the data in the database and the other to scour the code for SQL injection vulnerabilities. The team does not know about protecting data from disclosure, so the person slated to work on this defense reads chapter 12, "Failing to Store and Protect Data Securely," in the 19 Deadly Sins.

One developer checks to ensure that the build environment is set up to use the SDL-required compiler and linker switches and that the security-focused code analysis tools are also set to run as part of the build process.

After looking at the new set of user stories so far, the team decides to remove two medium-priority stories and two low-priority stories to keep within the sprint time box-these stories are put back in the product backlog. Finally, after talking to the customer, one high-priority story is downgraded to a medium-priority story but is to be completed in this sprint.

One developer elects to address the possible SQL injection vulnerabilities identified by the threat model. He spends three days finding all database access code within the web and C++ code and modifying it to use stored procedures and parameterized queries. He also modifies the access rights of the interactive database user so that it does not have access to any database tables that are not necessary for the application. He also removes the interactive user's permissions for deleting database objects and creating new database objects, since these are also not necessary for the application to function. These practices are good defense-in-depth measures that help prevent the system from being exploited in the event that a vulnerability accidentally slips into the production code.

Nineteen days into the sprint, all of the SDL-required, high-priority stories are completed, as are many of the selected user stories. The team finishes out the sprint, completing the rest of the selected user stories. The sprint is a success, and the team is poised to release their new code to the public.

Content Disclaimer

This documentation is not an exhaustive reference on the SDL process as practiced at Microsoft. Additional assurance work may be performed by product teams (but not necessarily documented) at their discretion. As a result, this example should not be considered as the exact process that Microsoft follows to secure all products. This documentation is provided “as-is.” Information and views expressed in this document, including URL and other Internet website references, may change without notice. You bear the risk of using it. This documentation does not provide you with any legal rights to any intellectual property in any Microsoft product. You may copy and use this document for your internal, reference purposes. © 2012 Microsoft Corporation. All rights reserved. Licensed under Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported