다음을 통해 공유

SDL-Agile Requirements

  • 아티클

A workhorse of Agile development is the sprint, which is a short period of time (usually 15 to 60 days) within which a set of features or stories are designed, developed, tested, and then potentially delivered to customers. The list of features to add to a product is called the product backlog, and prior to a sprint commencing, a list of features is selected from the product backlog and added to the sprint backlog. The SDL fits this metaphor perfectly-SDL requirements are represented as tasks and added to the product and sprint backlogs. These tasks are then selected by team members to complete. You can think of the bite-sized SDL tasks added to the backlog as non-functional stories.

Every-Sprint Requirements

In order to fit the weighty SDL requirements into the svelte Agile framework, SDL-Agile places each SDL requirement and recommendation into one of three categories defined by frequency of completion. The first category consists of the SDL requirements that are so essential to security that no software should ever be released without these requirements being met. This category is called the every-sprint category. Whether a team's sprint is two weeks or two months long, every SDL requirement in the every-sprint category must be completed in each and every sprint, or the sprint is deemed incomplete, and the software cannot be released. This includes any release of the software to an external audience, whether this is a box product release to manufacturing (RTM), online service release to web (RTW), or alpha/beta preview release.

Some examples of every-sprint requirements include:

  • Run analysis tools daily or per build (see Tooling and Automation later in the Applying SDL Tasks to Sprintssection).
  • Threat model all new features (see Threat Modeling: The Cornerstone of the SDL later in the Applying SDL Tasks to Sprintssection).
  • Ensure that each project member has completed at least one security training course in the past year (see Security Education later in the Applying SDL Tasks to Sprintssection).
  • Use filtering and escaping libraries around all web output.
  • Use only strong crypto in new code (AES, RSA, and SHA-256 or better).

For a complete list of the every-sprint requirements as followed by Microsoft SDL-Agile teams, see Appendix P: SDL-Agile Every-Sprints Requirements.

Bucket Requirements

The second category of SDL requirement consists of tasks that must be performed on a regular basis over the lifetime of the project but that are not so critical as to be mandated for each sprint. This category is called the bucket category and is subdivided into three separate buckets of related tasks. Currently there are three buckets in the bucket category-verification tasks (mostly fuzzers and other analysis tools), design review tasks, and planning tasks. Instead of completing all bucket requirements each sprint, product teams must complete only one SDL requirement from each bucket of related tasks during each sprint. The table below contains only a sampling of the tasks for each bucket. To see a complete list of all tasks for all three buckets, consult Appendix Q: SDL-Agile Bucket Requirements.

Verification Tasks Design Review Planning
ActiveX fuzzing Conduct a privacy review Create privacy support documents
Attack surface analysis Review crypto design Update security response contacts
Binary analysis (BinScope) Assembly naming and APTCA Update network down plan
File fuzz testing User Account Control Define/update security bug bar

Table 1. Example of bucket categories. For a complete list of bucket items, see Appendix Q: SDL-Agile Bucket Requirements.

In this example, a team would be required to complete one verification requirement, one design review requirement, and one planning requirement in every sprint (in addition to the every-sprint requirements discussed earlier). For sprint one, the team might choose to complete ActiveX fuzzing, Review crypto design, and Update security bug bar from the table. For sprint two, they might choose Binary analysis, Conduct a privacy review, and Update network down plan.

It is left to the product teams to determine which tasks from each bucket that they would like to address in any given sprint. The SDL-Agile does not mandate any type of round-robin or other task prioritization for these requirements. If your team determines that they are best served by completing file fuzzing requirements every other sprint but that SOAP fuzzing only needs to be performed every 10 sprints, that's acceptable.

However, no requirement can be completely ignored. Every requirement in the SDL has been shown to identify or prevent some form of security or privacy issue, or both. Therefore, no SDL bucket requirement can go more than six months without being completed.

One-Time Requirements

There are some SDL requirements that need to be met when you first start a new project with SDL-Agile or when you first start using SDL-Agile with an existing project. These are generally once-per-project tasks that won't need to be repeated after they're complete. This is the final category of SDL-Agile requirements, called the one-time requirements.

The one-time requirements should generally be easy and quick to complete, with the exception of creating a baseline threat model (see Threat Modeling: The Cornerstone of the SDL later in the Applying SDL Tasks to Sprintssection), which is discussed later in this section. Even though these tasks are short, there are enough of them that it would not be feasible for a team just starting with SDL-Agile to complete all of them in one sprint, given that the team also needs to complete the every-sprint requirements and one requirement from each of the buckets.

To address this issue, the SDL-Agile allows a grace period to complete each one-time requirement. The period generally ranges from one month to one year after the start of the project, depending on the size and complexity of the requirement. For example, choosing a security advisor is considered an easy, straightforward task and has a one-month completion deadline, whereas updating your project to use the latest version of the compiler is considered a potentially long, difficult task and has a one-year completion deadline. The current list of one-time requirements and the corresponding grace periods can be found in Appendix R: SDL-Agile One-Time Requirements of this document. Figure 2 provides an illustration of this process in action.

SDL-Agile_process

                                 Figure 2. SDL-Agile process

Constraints

The main difficulty that SDL-Agile attempts to address is that of fitting the entire SDL into a short release cycle. It is entirely reasonable to mandate that every SDL requirement be completed over the course of a two- or three-year-long release cycle. It is not reasonable to mandate the same for a two- or three-week-long release cycle. The categorization of SDL requirements into every-sprint, one-time, and the three bucket groups is the SDL-Agile solution for dealing with this conundrum. However, an effect of this categorization is that teams can temporarily skip some SDL requirements for some releases. The Microsoft SDL team believes this is a necessary situation required to provide the best mix of security, feature development, and speed of release for teams with short release cycles.

Although SDL-Agile was designed for teams with short release cycles, teams with longer release cycles are still eligible to use the SDL-Agile process. However, they may find that they are actually performing more security work than if they had used the classic, waterfall-based SDL. Requirements that a team only needs to complete once in classic SDL may need to be met five or six (or more) times in SDL-Agile over the course of a long project. However, this is not necessarily a bad thing and may help the team to create a more secure product.

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