MSDN Magazine - November 2008 - (Page 55)

The every-sprint requirements Threat model Use ValidateRequest And so on Security veri cation bucket Fuzz le inputs Run AppVerif And so on Design review bucket Review crypto design Privacy review And so on Response planning bucket Disaster recovery plan Update response contacts And so on Figure 2 SDL/A Lifecycle An example of a one-time-only onboarding requirement is the requirement to configure the product’s bug tracking system to track security-specific data. At Microsoft, all security defects found during development that are rated as Critical, Important, or Moderate in the product’s bug bar must be fixed before release. But if you can’t track which defects are security issues and which are functional issues, you can’t reliably fix the security issues before release. Additionally, the security-specific defect fields, such as Security Defect Cause (buffer overflow, directory traversal, SQL injection, and so on) and Security Defect Effect (any of the STRIDE values), can be valuable to help developers fix the defect and to ensure that it doesn’t happen again later. The team only needs to set up the tracking system this way once, no matter how long the project runs. Another, slightly more involved onboarding requirement is the requirement to create a baseline threat model for the application. If the application is a new project, if no code has ever been written for it before, then this requirement is superfluous: the team only needs to threat model new features as they’re designed on a sprint-by-sprint basis. However, a product team may be applying the SDL/A process for the first time to a previously existing project. In this case, a baseline threat model must be built to cover the preexisting functionality of the application. Several other onboarding requirements, such as developing a security incident response plan, can be nontrivial as well. In order to prevent teams from spending a disproportionate amount of time on security, especially in their first stages with a new, unfamiliar SDL process, SDL/A provides for a three-month grace period for teams to complete the onboarding requirements. However, even though product teams aren’t required to complete every bucket requirement in every sprint, that doesn’t mean they can omit them indefinitely. In fact, teams have to complete each of the bucket requirements at least once a year. Additionally, teams are prohibited from completing the same bucket requirement two sprints in a row. For example, if Project X’s team chooses to complete an attack surface analysis to satisfy its Security Verification bucket requirement for their March sprint, they can’t then complete another attack surface analysis in April. More specifically, they could complete another attack surface analysis in April if they really wanted to; nevertheless, it just would not satisfy their SDL commitment. Other than those two constraints, teams are free to choose whichever bucket requirements they want to complete in any given sprint. SDL/A does not mandate any sort of ordering or round-robin requirement selection. This gives product teams maximum flexibility in choosing security activities that they find most useful. So if a team has historically found a significant number of defects by running Application Verifier but they’ve never found any by running a SOAP fuzzer, they can choose to run AppVerif as often as every other sprint but need only run the SOAP fuzzer once a year. Constraints The Bucket Requirements While it’s not officially prohibited, teams that follow a waterfallstyle development process with well-defined and distinct design, implementation, verification and release phases are not a good fit for SDL/A because it is designed to work with iterative, phaseless development methodologies. If a product has well-defined phases, then classic SDL is a much better fit. The concept of Agile security does not have to be a contradiction in terms. With SDL/A, the Microsoft SDL team has defined a set of process improvements that provide for an increased security focus while still respecting the need to release new code (including new functionality, not just new security improvements) on an ultra-short timeline. If you have experience, whether positive or negative, completing the classic SDL requirements in a short sprint, I’d be more than happy to hear your thoughts on SDL/Agile; you can reach me at blogs.msdn.com/sdl. Also, please see the official SDL site at www.microsoft.com/sdl.  Bryan Sullivan is a Security Program Manager for the Microsoft Security All other SDL requirements that do not fall into either the everysprint or onboarding requirement categories are placed into one of three requirement buckets: Security Verification, Design Review, and Response Plans. So, for example, the SDL requirement to fuzz input handling routines would be placed in the Security Verification bucket. Likewise, the requirement to define a disaster recovery plan would be placed in the Response Plans bucket. Unlike in classic SDL, where all of these requirements must be completed before the product can release, in SDL/A only one requirement from each bucket must be completed during each sprint. This is the concession that SDL/A makes to the shorter release schedules of Agile development projects. As they say, you can’t fit ten pounds of flour in a five-pound sack, and the bucket requirements are the five extra pounds we’ve taken out. Figure 2 shows the new flow with SDL/A. Note that the checked items will be performed during the corresponding stage. msdnmagazine.com Wrap-Up Development Lifecycle team, where he specializes in Web application security issues. His first book, Ajax Security, was published by Addison-Wesley in December 2007. November 2008 55 http://blogs.msdn.com/sdl http://www.microsoft.com/sdl http://www.msdnmagazine.com

Table of Contents Feed for the Digital Edition of MSDN Magazine - November 2008

Contents MSDN Magazine - November 2008 Toolbox CLR Inside Out Data Points Cutting Edge Security Briefs Test Your Security IQ Agile SDL Access Control Utility Spotlight RIA Test Run Wicked Code Foundations Team System End Bracket

MSDN Magazine - November 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.