Skip to main content

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.

Let's look at some basic examples of what threat modeling is and what it isn't:

Definitions of what is and isn't involved in threat modeling

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.

The recommended approach is to use a whiteboard to sketch out each threat model, thereby facilitating team discussion around the diagram. The SDL is specific in recommending that threat models use the data flow diagram (DFD) as the foundational diagramming technique. Having a project member who is already familiar with data flow diagramming can be a big help, and that individual would be best suited to facilitate the first threat modeling session. So, the first step in threat modeling is to draw a DFD on the whiteboard that represents your envisioned application. Next, let’s look at the various threat modeling diagram types.

The highest-level diagram you can create is the context diagram. The context diagram is typically a simple diagram that captures the most basic interactions of your application with external actors. Figure 1 is an example of a context diagram. Following the context diagram, there are a variety of more detailed diagrams that can show more specific interactions of your application’s internal components and actors. The Diagram Levels table below lists the various levels of diagrams, along with descriptions of what each level typically contains.

Threat model diagram
Figure 1. Context diagram

Diagram levels

Once you have created a few of these high-level diagrams with your team, the next step is to identify the trust boundaries that we discussed earlier. Trust boundaries are represented by drawing lines that separate the various zones of trust in your diagram. It is the action of applying the trust boundary that changes the DFD into a threat model. It’s critical that you get the trust boundaries correct because that is where your team will focus its attention when discussing threats to the application. Figure 2 shows a Level 0 threat model with trust boundaries included.

Level 0 diagram with trust boundaries
Figure 2. Level 0 diagram with trust boundaries

Once you’ve created the threat model, your team will be ready to start discussing the threats to the application as envisioned in deployment. In order to do this efficiently, the SDL has categorized potential threats along with the most common mitigations to those threats in order to simplify the process. For a more complete discussion on threat models, refer to the book Threat Modeling by Frank Swiderski and Window Snyder.

Let’s next examine the process you can follow to identify, classify, and mitigate threats to your application. We call this process STRIDE.

STRIDE

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.

STRIDE definitions

Notice how each of the definitions are described in terms of what an “attacker” can do to your application. This is an important point: When threat modeling, it’s crucial to convey to your project team that they should be more focused on what an attacker can do than what a legitimate user can do. What your users can do with your application should be captured in your user stories and not in the threat model.

Now that you’ve created the threat model and discussed the threats to the various components and interfaces, it’s time to determine how to help protect your application from those threats. We call these mitigations. the following table lists the mitigation categories with respect to each of the STRIDE elements.

STRIDE and mitigation categories

We’ve discussed the basics of threat modeling, so next we’ll turn our attention to how we can incorporate threat modeling with agile methods. While a full discussion of STRIDE and threat modeling is beyond the scope of this article, you can read much more on the topic by referring to the resources at the end of this article. Additionally, it’s important to note that once you have created your threat models on the whiteboard, you need to capture them as a drawing. Microsoft provides an excellent tool for this purpose: the Microsoft SDL Threat Modeling Tool. This tool allows you to easily create your threat model diagrams, and provides a systematic approach to identifying threats based on trust boundaries and evaluating common mitigations to those threats.

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.


SDL for Agile
Figure 3. SDL for Agile

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.

Simplified SDL process and threat modeling
Figure 4. Simplified SDL process and threat modeling

Threat modeling can be an involved process, and activities that require significant effort are often considered incompatible with agile development methodologies. I would like to dispel any idea that threat modeling cannot fit with agile. It absolutely can fit! The key to effectively incorporating threat modeling is to decide on the scope of the threat modeling that you will perform during the various stages of your agile development project.

Understanding the challenge of how much threat modeling to perform is best served using a simple example. Let’s say you are developing a web services application incrementally. Initially, you plan to offer only some basic functionality, and, over subsequent releases, you will expand on the functionality in the web services application. Threat modeling solely the functionality that you plan to release in the first iteration might not reveal enough of the system design to identify threats or allow sufficient time to address them. On the other hand, if you create complete threat models for how the entire application is envisioned, that would obviously be too expensive a single agile iteration.

So what’s the best approach? I recommend a strategy in which you create the context and Levels 0, 1, and 2 diagrams during the early inception and requirements phases of the project. Additionally, any other diagrams in which sufficient detail is known about the likely application architecture or high-level design should be included during this phase. It’s not important during this stage to identify every threat and mitigation for each diagram, though the more you can, the better. The point here is that it’s better to diagram what you do know at this stage, versus waiting for the entire design to be completed. This will allow you sufficient time to address threats that are identified during the initial stage of the project.

The following list categorizes the suggested threat modeling activities based on project stage:

  • Project Inception - Create context and Level 0 and Level 1 diagrams.
  • Requirements Planning - Identify the threats and mitigations that you expect to have greatest impact on the overall system design and architecture.
  • Sprint Planning - Identify where new threat models are required and where current threat models need to be updated or completed.
  • Sprint Execution - Develop, update, and complete threat models according to tasks assigned during sprint planning.
  • Final Release Planning - Ensure that all threat models are complete and included in the project archive.
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.

At this point you might be asking what complete means when it comes to threat modeling. Simply put, complete means that for a given threat model:

  • All of the identified threats have been discussed by the project team.
  • Appropriate mitigations have been discussed.
  • Bugs have been opened to address each threat for which a mitigation must be developed.

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.

As you can see, threat modeling will become one of the recurring activities during your agile development lifecycle, much like any of the recurring tasks from sprint to sprint as you work off the project backlog. By the time the project is completed, the threat model should be completed with each threat identified and mitigation implemented according to your team’s processes and bug bars. I hope that this article has shown you how you can implement threat modeling into your agile development activities in order to reduce vulnerabilities and ultimately help your application be more secure when it’s deployed.

About the Author

Chas Jeffries photoChas 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.

Microsoft Security Newsletter

Sign up for a free monthly roundup of security news, bulletins, and guidance for IT pros and developers.