Security Engineering Explained - Chapter 4 - Threat Modeling

From Guidance Share

Jump to: navigation, search

Note - patterns & practices Security Engineering is now live at http://msdn.microsoft.com/en-us/library/ms998382.aspx.


- J.D. Meier, Alex Mackman, Blaine Wastell, Prashant Bansode, Jason Taylor, Rudolph Araujo

Contents

Summary

Threat modeling is an engineering technique that you can use to help identify threats, attacks, vulnerabilities, and countermeasures that may be relevant to your application. This module summarizes the patterns & practices approach to threat modeling by explaining what it is and why you should use it. It also describes the key concepts behind the approach.


What Is Threat Modeling?

Threat modeling is an engineering technique that you can use to help identify threats, attacks, vulnerabilities, and countermeasures that might be relevant to your application. The threat modeling activity helps you to recognize the following:

  • Your security objectives
  • Relevant threats
  • Relevant vulnerabilities and countermeasures


Why Use Threat Modeling?

Threat modeling is performed to identify when and where more resources are required (or justified) to reduce risks. There are many possible vulnerabilities, threats, and attacks, and it is unlikely that your application will encounter all of them. It is also unlikely that your company would need to address all of them. Threat modeling helps you to identify where your organization needs to apply effort.


Threat modeling helps you to:

  • Shape your application design to meet your security objectives.
  • Help make engineering decisions that weigh security goals against other design goals.
  • Address and improve the quality of your engineering efforts by eliminating common vulnerabilities.
  • Improve quality of service by implementing necessary and effective countermeasures.
  • Reduce risk of security issues arising during development and operations.


Where Does Threat Modeling Fit In?

Threat modeling begins early in the architecture and design phase of the application life cycle. It is performed with knowledge of your security objectives. Your security objectives are a key part of your business objectives and they are used to determine the extent of the threat modeling activity and where to spend the most effort.


As the life cycle progresses and your design and development evolve, you progressively add more detail to your threat model. Threat modeling is iterative, and you need to repeat the process as indicated by the following:

  • Increase the detail of your model whenever new environmental facts become known.
  • While you develop, increase the detail of your model as design and implementation decisions reveal new facts.
  • Add detail as new uses and configurations of the application appear. This is during the application lifetime including after the application is in production and is maintained by the operations team.


Add information to the model as it becomes available to you, and keep identifying what you now know and what you need to know next.


Terminology

Threat modeling uses the following terms:

  • Asset. An asset is a resource that has value. It varies by perspective. To your business, an asset might be the availability of information or the information itself, such as customer data. It might be intangible, such as your company’s reputation. To an attacker, an asset could be the ability to misuse your application for unauthorized access to data or privileged operations.
  • Threat. A threat is an undesired event or potential occurrence, often best described as an effect that could damage or compromise an asset or objective. It may or may not be malicious in nature.
  • Vulnerability. A vulnerability is a weakness in some aspect or feature of a system that makes an attack possible. Vulnerabilities can exist at the network, host, or application level and include operational practices.
  • Attack (or exploit). An attack is an action taken that uses one or more vulnerabilities to realize a threat. This could be someone following through on a threat or exploiting a vulnerability.
  • Countermeasure. A countermeasure addresses a vulnerability to reduce the probability of attack or the impact of a threat. A countermeasure does not directly address a threat. Instead, it addresses the factors that define the threat. Countermeasures

range from improving application design or improving code, to improving an operational practice.


Activity Overview

The five major threat modeling steps are shown in Figure 4.1 on the next page. You should progressively refine your threat model by repeatedly performing steps 2 through 5. You will be able to add more detail as you move through your application development life cycle and discover more about your application design.


Image:IterativeThreatModelingProcess.gif

Figure 4.1 The iterative threat modeling process

The five threat modeling steps are:

  • Step 1: Identify security objectives. Clear objectives help you to focus the threat modeling activity and determine how much effort to spend on subsequent steps.
  • Step 2: Create an application overview. Itemizing your application’s important characteristics and actors helps you to identify relevant threats during step 4.
  • Step 3: Decompose your application. A detailed understanding of the mechanics of your application makes it easier for you to uncover more relevant and more detailed threats.
  • Step 4: Identify threats. Use details from steps 2 and 3 to identify threats relevant to your application scenario and context.
  • Step 5: Identify vulnerabilities. Review the layers of your application to identify weaknesses in the context of your threats. Use vulnerability categories to help you to focus on those areas where mistakes are most often made.


You add progressively more detail to your threat model as you move through your application development life cycle and discover more details about your application design. Because key resources identified in threat modeling are also likely to be important from a performance and functionality perspective, you can expect to revisit and adjust your model as you balance your needs. This is normal and is a valuable outcome of the process.


Activity Summary Table

Table 4.1 summarizes the threat modeling activity and shows the input and output for each step.


Table 4.1: Activity Summary with Input and Output

Input

Step

Output

  • Business requirements
  • Security policies
  • Compliance requirements

Step 1: Identify security objectives

  • Key security objectives
  • Deployment diagrams
  • Use cases
  • Functional specifications

Step 2: Create an application overview

  • Whiteboard-style diagram with end-to-end deployment scenario
  • Key scenarios
  • Roles
  • Technologies
  • Application security mechanisms
  • Deployment diagrams
  • Use cases
  • Functional specifications
  • Data flow diagrams

Step 3: Decompose your application

  • Trust boundaries
  • Entry points
  • Exit points
  • Data flows
  • Common threats

Step 4: Identify threats

  • Threat list
  • Common vulnerabilities

Step 5: Identify vulnerabilities

  • Vulnerability list


Key Concepts

The patterns & practices threat modeling approach is optimized to help you identify vulnerabilities in your application. The key concepts on the next page represent best practices refined by industry security experts, Microsoft consultants, product support engineers, customers, and Microsoft partners.


Table 4.2: Key Concepts

Concept

Description

Modeling to reduce risk

Use threat modeling to identify when and where you should apply effort to eliminate or reduce a potential threat. Avoid wasted effort by threat modeling to clarify the areas of most risk.

Incremental rendering

Perform threat modeling iteratively. You should not be too concerned about missing details in any single iteration — instead focus on making each iteration productive.

Context precision

Understand application use cases and roles in order to identify threats and vulnerabilities that are specific to your application. Different application types, application usage, and roles can yield different threats and vulnerabilities.

Boundaries

Establish boundaries in order to help you define constraints and goals. Boundaries help you identify what must not be allowed to happen, what can happen, and what must happen.

Entry and exit criteria

Define entry and exit criteria to establish tests for success. You should know before you start what your threat model will look like when complete (good enough) and when you have spent the right amount of time on the activity.

Communication and collaboration tool

Use the threat model as a communication and collaboration tool. Leverage discovered threats and vulnerabilities to improve shared knowledge and understanding.

Pattern-based information model

Use a pattern-based information model to identify the patterns of repeatable problems and solutions, and organize them into categories.

Key engineering decisions

Expose your high-risk engineering decisions and design choices with your threat model. These high-risk choices are good candidates for focusing prototyping efforts.


Conclusion

Threat modeling is a structured activity for identifying and evaluating application threats and vulnerabilities. You should start the threat modeling activity early in the architecture and design phase of your application life cycle, and then continually update and refine the model as you learn more about your design and implementation. Use threat modeling to shape your application design to meet your security objectives, to help weigh the security threat against other design concerns (such as performance) when making key engineering decisions, and to reduce the risk of security issues arising during development and operations.

Additional Resources

For more information on threat modeling, see http://msdn.com/threatmodeling.

Personal tools