MSDN Magazine - November 2008 - (Page 53)

Feature Lists Quality Guidelines Architecture Docs Schedules Requirements Functional Speci cations Design Development of New Code Implementation Code Signing and Signoff Bug Fixes Veri cation Release Release Design Speci cations Testing and Veri cation Product Support Service PacksQFEs Security Updates Support and Service Figure 1 The Classic Security Development Lifecycle A New Process: Combining the SDL and Agile To address this issue, the SDL team has adapted the SDL to better suit the needs of teams with Rapid Application Development (RAD) or Agile development processes. We haven’t yet determined an official name for this new SDL variant, but for the purposes of this article we’ll refer to it as SDL/Agile, or SDL/A for short. Our intention is that any product team with an iterative, phaseless development methodology will be eligible to opt into the SDL/A process instead of the “classic” version of SDL. This does not limit SDL/A to only Web applications, since many box products also follow Agile development methodologies. The first and biggest difference between classic SDL and SDL/A is that in SDL/A, every requirement does not need to be completed for every release (or every “sprint”). This may seem controversial. After all, we’ve always said that every requirement in the SDL is important and can’t be skipped. It is true that every SDL requirement is included because it has been proven to prevent a serious security or privacy vulnerability. The requirement to avoid certain banned APIs is included because it has been proven to prevent buffer overflows. The requirement to encode user input before displaying it on a Web page has been proven to prevent cross-site scripting attacks. However, as I discussed, there simply isn’t enough time in a short release cycle to complete every SDL requirement and still do feature development. So, SDL/A defines three levels of requirement frequency (that is, how often the requirement must be completed), and each SDL requirement is placed into one of those three categories. The Every-Sprint Requirements The first frequency level for SDL/A is the “every-sprint” level. These requirements are considered non-negotiable and must be completed every sprint regardless of how short the sprint length is. These requirements place the highest burden on the development teams since they’re being completed so frequently, so these requirements are chosen very carefully according to two factors. The first factor is the importance of the requirement—in other words, how many vulnerabilities does this requirement prevent, and how critical are those vulnerabilities? Every requirement is important, but just as different vulnerabilities have different weights on the bug bar, the requirements that defend against those vulnerabilities have different weights as well. For example, a temporary Denial of Service (DoS) attack is considered a much less severe attack than a remotely executed elevation of privilege. An SDL requirement that would prevent the elevation of privilege attack is much more likely to be included in the everysprint frequency category. We also look at historic vulnerability data: msdnmagazine.com if a requirement would have prevented one of the critical security vulnerabilities, such as those that were exploited by the Slammer or Blaster worms (if the requirement had existed in time to prevent introduction of the vulnerability), then that requirement is almost certain to be included in the every-sprint category. One example of a requirement that falls into the every-sprint category is the requirement to use the ASP.NET-provided ValidateRequest cross-site scripting (XSS) defense. The ValidateRequest requirement meets both criteria for inclusion in every sprint: it helps products to defend against highly critical XSS attacks, and it’s essentially free since ValidateRequest is enabled by default. The second factor that contributes to a requirement being placed in the every-sprint category is the ease with which that requirement can be automated. Even if a requirement is unlikely to prevent another Code Red attack, if it can be automated into the development build process or code check-in policy, then it’s likely to be required every sprint. Another example of an every-sprint requirement is the requirement to threat model the application. Unlike enabling ValidateRequest, threat modeling can take a significant amount of time and effort. However, threat modeling is the cornerstone of the SDL and can never be omitted. Threat modeling is essential to uncovering design-level vulnerabilities that might require significant re-architecture in order to be mitigated if they’re found later in the development lifecycle. Like heart surgery, threat modeling is expensive, but it’s well worth the price! In many cases, the cost of threat modeling is not even that high. One of the tenets of the Agile development process is to plan for no more work than is going to be completed during the current sprint. This goes for threat modeling too. There’s no need to create a detailed threat model of the complete system during the very first sprint. Only the functionality being developed in the current sprint needs to be threat modeled for that sprint. In this way, the threat modeling requirement is self-regulating with regard to time spent. The Onboarding Requirements The second group of requirements are referred to as “onboarding” requirements. These are requirements that product teams have to complete once at the beginning of the project and then never need to address again. In the classic SDL, every requirement works this way. But products using classic SDL typically have well-defined development phases, including a well-defined end (release of the product). In contrast, Web applications often do not have welldefined endings. The team may release a new update every Friday afternoon and then start developing new features Monday morning, and this process can continue indefinitely. November 2008 53 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.