Threat Modeling and Agile Development Practices
Published: February 21, 2012
Author: Chas Jeffries, Security Architect, Microsoft Services
Strong demand for rapid application delivery continues to drive today's fast-paced application development cycles. There are more and more web services, new cloud applications, and mobile applications. Just because your application needs to be developed rapidly, doesn't mean that you can't develop that application with privacy and security in mind. In a previous article, I wrote about how you can use the Microsoft Simplified Security Development Lifecycle (SDL) for web application development. In that article, I briefly discussed how threat modeling can be used to understand threats to your application and how to mitigate them. In this article, we are going to closely examine how to effectively perform threat modeling for projects that demand rapid development processes. Before we dive into the details on threat modeling, let's briefly review how threat modeling fits into the SDL.
Threat Modeling and the SDL
My colleague, Michael Howard, who is co-author of the book, The Security Development Lifecycle, likes to say that, "If you’re only going to do one activity from the SDL, it should be threat modeling!" I couldn't agree more; hopefully, this article will demonstrate how easily threat modeling can fit into your agile development practices. Let's quickly review the basics of threat modeling before getting into how threat modeling integrates into agile development methodologies.
Threat modeling overview
Threat modeling is a fundamental activity of the SDL and the main software engineering artifact that results from following the SDL. A threat model is a diagram that encapsulates the various interactions of your envisioned application or service to include both internal and external factors. A fundamental concept in threat modeling is that of “trust” boundaries. These are the points of demarcation between parts of your application where threats are most likely to occur. The most obvious example of a trust boundary for web applications is the demarcation between the user’s browser/computer and your application interface, which resides on a server somewhere on the Internet. Your application faces a myriad of potential and unanticipated threats beyond those you might expect from your trusted user or customer. Using trust boundaries in threat modeling simplifies the identification and classification of threats.
What threat modeling is and what it isn't
To understand what threat modeling is, it's helpful to also look at what it isn't. Those who are new to threat modeling often misunderstand its purpose or intent and often will argue that creating yet another system diagram is duplication of effort for the overall project. This is a heightened concern when teams are focused on realizing the speed and efficiencies of agile development methodologies. The goal of this article is to demonstrate why threat models are valuable and stand on their own as software engineering artifacts for your agile project.
How to perform threat modeling
As described above, threat modeling is largely a team activity. Does that mean an individual can’t threat model alone on a small project? Of course not, but you will get the greatest benefit from the activity by including as many project members as possible. This is because each member will bring unique perspectives to the exercise, and that input is essential when trying to identify the various ways that an attacker might attempt to break your application or service.
STRIDE is a framework for classifying threats during threat modeling. STRIDE stands for Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation Privilege. The table below provides basic descriptions of the elements of STRIDE.
The SDL and Agile Methodologies
There are a number of agile methodologies in practice today. They include Scrum and Extreme Programming (XP), and, in some cases, teams like to use practices from a number of methodologies. Regardless of the methodology you follow, you don’t have to sacrifice security just because you are developing using one of the agile methodologies. SDL for Agile is now included in the Microsoft SDL process guidance, and you can find the latest details in the
SDL 5.1. Figure 3 shows how the SDL integrates into agile development methodologies. The key takeaway here is that, to include threat modeling, SDL activities can be organized into “bite-size chunks” across various iterations or sprints or in buckets as part of agile software development methodologies.
Threat Modeling and Agile
Now that we’ve examined how SDL fits into agile methodologies, let’s examine more closely how you can successfully implement threat modeling in your agile projects. One of the most common questions about implementing threat modeling in agile methodologies is when to begin the activity. Typically, threat modeling is considered to be an activity that takes place in the design phase of the SDL methodology as shown in Figure 4. However, when following agile methodologies, it can be beneficial to begin threat modeling earlier in the process.
Iteration or sprint planning
Depending on the agile methodology you are following—whether Scrum, XP, or another methodology— typically a day or a portion of a day will be set aside to plan the iteration, or sprint in Scrum parlance. This is the time to discuss whether threat models will need to be added or updated during the iteration. As the project team reviews the user stories that will be implemented during the iteration, the team should ask if these stories are already covered by one of the completed threat models, and, if so, whether the model requires modifications to accommodate any of the stories. If the team is uncertain, then you simply need to add a task to the sprint to review the threat models, thereby determining if an update is required.
Who should threat model?
In theory, any member of the project team can be responsible for threat modeling the entire project or any given iteration. In fact, to provide fresh perspectives to the activity, it can be beneficial to share the responsibility for threat modeling. That said, a minimum requirement should ensure that whoever is responsible for the project threat models has completed the required security training as described in the SDL guidance. Additionally, it’s ideal that team members have an interest in security as this will ensure that the threat models are completed enthusiastically.
How do you know when a threat model is complete when using agile methods?
When following a more deliberate software development methodology such as the waterfall or spiral methodologies, this is a much easier question to answer: Threat models should be 100 percent complete before moving to the next phase of the project lifecycle. In agile development, threat models are “living” project artifacts that should be updated and enhanced during every iteration or sprint. However, just because threat models will be considered in subsequent sprints, it does not mean that it’s okay to skip updates to the threat models. If during the iteration planning a task has been added for threat modeling, then the team should complete as much of the threat model as necessary to cover the story being implemented. To reiterate: The earlier you can identify threats, the more time you have to develop mitigations for them.
Let’s look at a scenario to better understand when a threat model is complete. Consider a Level 1 diagram that includes a number of services and interactions that enable multiple user stories. Now let’s say that those stories will be implemented over a number of iterations or sprints. Do you need to complete the entire threat model at the end of the iteration? Certainly not. However, that answer requires a bit more explanation. I would suggest that it’s a requirement to complete the diagram, along with trust boundaries, to the fullest extent possible, and that it’s necessary to identify threats on all of the major interfaces and entities. The reason for this is that the earlier that you identify major threat vectors, the more time you’ll have to work on major mitigations to threats that might affect your overall architecture and design. You might not need to mitigate threats for areas of the threat model that won’t be implemented until a later iteration or sprint, and this means that the threat model will not be fully complete from one iteration to the next, but that’s okay.
About the Author
Chas Jeffries is a Security Architect in Microsoft Services who focuses on Cyber Security and the Security Development Lifecycle. Prior to joining Microsoft Services was a Lead Program Manager for 10 years providing program management for the development of various applications for Microsoft.com and security components for the Microsoft Windows operating system. Chas is a CISSP and holds a MS in Computer Science from the University of Nebraska.