Applying SDL Tasks to Sprints

Article
05/22/2012

While the previous section focused on requirements specific to the SDL-Agile, this section focuses on tasks associated with the SDL and how they are applied within the Agile framework.

Security Education

Each member of a project team must complete at least one security training course every year. If more than 20 percent of the project members are out of compliance with this non-negotiable requirement, the requirement is failed (and consequently so is the sprint, and the product is not allowed to release). Consult your sprint leader for a list of courses that satisfy SDL training requirements. You can also consult the SDL Pro Network for training courses and recommendations.

Additionally, in the interests of staying lean, engineers and testers performing security-related tasks or SDL-related tasks should acquire relevant security knowledge prior to performing the tasks on the sprint. In this case, relevant is defined as security concepts that are pertinent to the features developed or tested during the sprint. Examples include:

Web-based applications

Cross-site scripting (XSS) vulnerabilities
SQL injection vulnerabilities

Database applications

SQL injection vulnerabilities

C and C++ applications

Buffer overflows
Integer overflows

All languages

Input validation
Language-specific issues (PHP, Java, C#)

Cryptographic code

Common cryptographic errors

Acquiring security knowledge could be as simple as reading appropriate chapters in a book (19 Deadly Sins of Software Security by Howard, LeBlanc, and Viega is a book that focuses on language and domain-specific coding vulnerabilities) or watching an online training class. If someone on the team wants to adopt the role of "security champion" or security expert for their team, they should attend broader and deeper security education as part of their normal ongoing education. Having a security expert close by is advantageous to the team and, more importantly, to the customer.

Tooling and Automation

Tools that automate security-related tasks are critical to a successful security process because the more you can automate the work necessary to meet requirements, the easier security becomes. Also, tools help reduce some of the development effort required of the developers by shifting it onto the tools. When security is involved, tools are not a replacement for humans, but tools do offer scalability-a tool can scan lots of code or check binaries without getting tired. Keep in mind, however, that simply running tools does not make a software product secure.

SDL-Agile requires the following tools to be run at least once per sprint and recommends that they be run daily or as part of the build and check-in process:

.NET code:

CAT.NET (applies to ASP.NET applications only)
FxCop 1.35 or later (all security rules at a minimum)

Native code:

Fix issues identified by static code analysis tools for unmanaged code. Use the currently required (or later) version of /analyze compiler option in Microsoft Visual Studio with the C and C++ compiler for native code for the target platforms and fix all required minimum (Min SDL) warnings. (Note: Also called /analyze in Microsoft Visual Studio.)

Threat Modeling: The Cornerstone of the SDL

At some point, the major SDL artifact-the threat model-must be used as a baseline for the product. Whether this is a new product or a product already under development, a threat model must be built as part of the sprint design work. Like many good Agile practices, the threat model process should be time-boxed and limited to only the parts of the product that currently exist or are in development.

Once a threat model baseline is in place, any extra work updating the threat model will usually be small, incremental changes.

A threat model is a critical part of securing a product because a good threat model helps to:

Determine potential security design issues.
Drive attack surface analysis and most "at-risk" components.
Drive the fuzz-testing process.

During each sprint, the threat model should be updated to represent any new features or functionality added during that sprint. The threat model should also be updated to represent any significant design changes, even if the functionality stays the same.

SDL Threat Modeling Tool

While not officially required as part of the SDL (either SDL-Agile or SDL-Classic), many internal Microsoft teams use the SDL Threat Modeling Tool with great success. The SDL Threat Modeling Tool is specifically designed to be used by developers and architects who may not necessarily have security expertise. A full review of the SDL Threat Modeling Tool is beyond the scope of this paper, but you can read more about it (and download it for free) at the Microsoft SDL Threat Modeling Tool website.

Starting a Threat Model for an Existing Project

If an Agile team adopts the SDL-Agile as outlined in this document while a product is already in development, a threat model needs to be built for the current product, but it is imperative that the team remains lean. A minimal, but useful, threat model can be built by analyzing high-risk entry points and data in the system. At a minimum, the following should be identified and threat models built around the entry points and data:

Anonymous and remote network endpoints
Anonymous or authenticated local endpoints into high-privileged processes
Sensitive, confidential, or personally identifiable data held in data stores used in the application

Continuing Threat Modeling

Threat modeling is one of the every-sprint SDL requirements for SDL-Agile. Unlike most of the other every-sprint requirements, threat modeling is not easily automated and can require significant team effort. However, in keeping with the spirit of agile development, only new features or changes being implemented in the current sprint need to be threat modeled in the current sprint. This helps to minimize the amount of developer time required while still providing all the benefits of threat modeling.

Fuzz Testing

Fuzz testing is a brutally effective security testing technique, especially if the team has never used fuzz testing on the product. The threat model should determine what portions of the application to fuzz test. If no threat model exists, the initial list should include high-risk items, such as those defined in Appendix S: SDL-Agile High-Risk Code.

After this list is complete, the relative exposure of each entry point should be determined, and this drives the order in which entry points are fuzzed. For example, remotely accessible or unauthenticated endpoints are higher risk than local-only or authenticated endpoints.

The beauty of fuzz testing is that once a computer or group of computers is configured to fuzz the application, it can be left running, and only crashes need to be analyzed. If there are no crashes from the outset of fuzz testing, the fuzz test is probably inadequate, and a new task should be created to analyze why the fuzz tests are failing and make the necessary adjustments.

Using a Spike to Analyze and Measure Unsecure Code in Bug Dense and "At-Risk" Code

A critical indicator of potential security bug density is the age of the code. Based on the experiences of Microsoft developers and testers, the older the code, the higher the number of security bugs found in the code. If your project has a large amount of legacy code or risky code (see Appendix S: SDL-Agile High-Risk Code), you should locate as many vulnerabilities in this code as possible. This is achieved through a spike. A spike is a time-boxed "side project" with a well-defined goal (in this case, to find security bugs). You can think of this spike as a mini security push. The goal of the security push at Microsoft is to bring risky code up to date in a short amount of time relative to the project duration.

Note that the security push doesn't propose fixing the bugs yet but rather analyzing them to determine how bad they are. If a lot of security bugs are found in code with network connections or in code that handles sensitive data, these bugs should not only be fixed soon, but also another spike should be set up to comb the code more thoroughly for more security bugs.

Examples of analysis performed during a spike include:

All code. Search for input validation failures leading to buffer overruns and integer overruns. Also, search for insecure passwords and key handling, along with weak cryptographic algorithms.
Web code. Search for vulnerabilities caused through improper validation of user input, such as CSS.
Database code. Search for SQL injection vulnerabilities.
Safe for scripting ActiveX controls. Review for C/C++ errors, information leakage, and dangerous operations.

All appropriate analysis tools available to the team should be run during the spike, and all bugs triaged and logged. Critical security bugs, such as a buffer overrun in a networked component or a SQL injection vulnerability, should be treated as high-priority unplanned items.

Exceptions

The SDL requirement exception workflow is somewhat different in SDL-Agile than in the classic SDL. Exceptions in SDL-Classic are granted for the life of the release, but this won't work for Agile projects. A "release" of an Agile project may only last for a few days until the next sprint is complete, and it would be a waste of time for project managers to keep renewing exceptions every week.

To address this issue, project teams following SDL-Agile can choose to either apply for an exception for the duration of the sprint (which works well for longer sprints) or for a specific amount of time, not to exceed six months (which works well for shorter sprints). When reviewing the requirement exception, the security advisor can choose to increase or decrease the severity of the exception by one level (and thus increase or decrease the seniority of the manager required to approve the exception) based on the requested exception duration.

For example, say a team requests an exception for a requirement normally classified as Moderate, which requires manager approval. If they request the exception only for a very short period of time, say two weeks, the security advisor may drop the severity to Low, which requires only approval from the team's security champion. On the other hand, if the team requests the full six months, the security advisor may increase the severity to Important and require signoff from senior management due to the increased risk.

In addition to applying for exceptions for specific requirements, teams can also request an exception for an entire bucket. Normally teams must complete at least one requirement from each of the bucket categories during each sprint, but if a team cannot complete even one requirement from a bucket, the team requests an exception to cover that entire bucket. The team can request an exception for the duration of the sprint or for a specific time period, not to exceed six months, just like for single exceptions. However, due to the broad nature of the exception-basically stating that the team is going to skip an entire category of requirements-bucket exceptions are classified as Important and require the approval of at least a senior manager.

Final Security Review

A Final Security Review (FSR) similar to the FSR performed in the classic waterfall SDL is required at the end of every agile sprint. However, the SDL-Agile FSR is limited in scope-the security advisor only needs to review the following:

All every-sprint requirements have been completed, or exceptions for those requirements have been granted.
At least one requirement from each bucket requirement category has been completed (or an exception has been granted for that bucket).
No bucket requirement has gone more than six months without being completed (or an exception has been granted).
No one-time requirements have exceeded their grace period deadline (or exceptions have been granted).
No security bugs are open that fall above the designated severity threshold (that is, the security bug bar).

Some of these tasks may require manual effort from the security advisor to ensure that they have been completed satisfactorily (for example, threat models should be reviewed), but in general, the SDL-Agile FSR is considerably more lightweight than the SDL-Classic FSR.

Now that the basic methodology and foundation is in place, it's time for an example scenario.

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.

Licensed under Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported