Difference between revisions of "Category:Threat Modeling"

From OWASP
Jump to: navigation, search
(Threat Modeling - Generic Steps)
 
(7 intermediate revisions by 2 users not shown)
Line 3: Line 3:
 
==Overview==
 
==Overview==
  
The term "threat modeling" has become quite popular recently. Microsoft has published a book about their process and includes threat modeling as a key activity in their [http://msdn.microsoft.com/security/default.aspx?pull=/library/en-us/dnsecure/html/sdl.asp Secure Development Lifecycle] (SDL).
+
The term "Threat Modeling" has become quite popular recently. Microsoft has published a book about their process and includes threat modeling as a key activity in their [http://msdn.microsoft.com/security/default.aspx?pull=/library/en-us/dnsecure/html/sdl.asp Secure Development Lifecycle] (SDL).
  
 
A threat model is essentially a structured representation of all the information that affects the security of an application. In essence, it is a view of the application and its environment through security glasses.
 
A threat model is essentially a structured representation of all the information that affects the security of an application. In essence, it is a view of the application and its environment through security glasses.
Line 9: Line 9:
 
Threat modeling is a process for capturing, organizing, and analyzing all of this information. Threat modeling enables informed decision-making about application security risk. In addition to producing a model, typical threat modeling efforts also produce a prioritized list of security improvements to the concept, requirements, design, or implementation.
 
Threat modeling is a process for capturing, organizing, and analyzing all of this information. Threat modeling enables informed decision-making about application security risk. In addition to producing a model, typical threat modeling efforts also produce a prioritized list of security improvements to the concept, requirements, design, or implementation.
  
==Threat Modeling Across the Lifecycle==
 
  
Threat modeling can be applied at any stage of a project in order to get a handle on security. The process is essentially the same at different levels of abstraction, although the information gets more and more granular throughout the lifecycle. Ideally, a high-level threat model should be defined in the concept or planning phase, and then refined throughout the lifecycle. As more details are added to the system, new attack vectors are created and exposed. The ongoing threat modeling process should examine, diagnose, and address these threats.
+
== '''Objectives of Threat Modeling''' ==
  
Note that it is a natural part of refining a system for these new threats to be exposed. For example, when you select a particular technology -- such as Java for example -- you take on the responsibility to identify the new threats that are created by that choice. Even implementation choices such as using regular expressions for validation introduce potential new threats to deal with.
+
Threat modeling is a procedure for optimizing Network/ Application/ Internet Security by identifying objectives and vulnerabilities, and then defining countermeasures to prevent, or mitigate the effects of, threats to the system.
 +
A threat is a potential or actual undesirable event that may be malicious (such as DoS attack) or incidental (failure of a Storage Device). Threat modeling is a planned activity for identifying and assessing application threats and vulnerabilities.
  
Understanding the generic threat modeling process is important, and the steps are described below.  But it may be more helpful to examine the threat modeling process at particular lifecycle stages, using specific terms and artifacts that are available at that stage.
+
==Threat Modeling Across the Lifecycle==
  
* [[Threat Modeling - Concept Phase]]
+
Threat modeling is best applied continuously throughout a software development project. The process is essentially the same at different levels of abstraction, although the information gets more and more granular throughout the lifecycle. Ideally, a high-level threat model should be defined in the concept or planning phase, and then refined throughout the lifecycle. As more details are added to the system, new attack vectors are created and exposed. The ongoing threat modeling process should examine, diagnose, and address these threats.
* [[Threat Modeling - Requirements Phase]]
+
 
* [[Threat Modeling - Design Phase]]
+
Note that it is a natural part of refining a system for new threats to be exposed. For example, when you select a particular technology -- such as Java for example -- you take on the responsibility to identify the new threats that are created by that choice. Even implementation choices such as using regular expressions for validation introduce potential new threats to deal with.
* [[Threat Modeling - Implementation Phase]]
+
  
 
==Threat Modeling - Generic Steps==
 
==Threat Modeling - Generic Steps==
  
For a threat to an application to exist, there must be:
+
For a threat to an application to exist, there must be a combination of the following where the combined likelihood and impact are important enough to do something about. Following is an outline of a generic methodology for Threat Modeling:
  
* a threat agent
+
* Assessment Scope
* a viable attack
+
* System Modeling
* a vulnerability not blocked by a countermeasure
+
* Identify Threats
* a negative impact to the business
+
* Identify Vulnerabilities
 +
* Examining the Threat History
 +
* Evaluation or Impact on the Business
 +
* Developing a Security Threat Response Plan
  
 
To understand whether an application is secure enough or not, you have to search out combinations of these ingredients that lead to realistic threats. The real trick to threat modeling is not wasting time on threats that are too unlikely or too inconsequential. Beware threat modeling processes that are inefficient about pruning the search space of possible threats to eliminate threats that are very unlikely or have minimal impact.
 
To understand whether an application is secure enough or not, you have to search out combinations of these ingredients that lead to realistic threats. The real trick to threat modeling is not wasting time on threats that are too unlikely or too inconsequential. Beware threat modeling processes that are inefficient about pruning the search space of possible threats to eliminate threats that are very unlikely or have minimal impact.
  
There is no "right" way to evaluate the search space of possible threats. But there are "wrong" ways. Attempting to evaluate all the possible combinatations of threat agent, attack, vulnerability, and impact is a waste of time and effort. Note that many of the automated tools take this approach - gathering lots of data and producing thousands of possible threats. Generally it is more productive to focus on finding high likelihood and high impact threats.
+
There is no "right" way to evaluate the search space of possible threats. But there are "wrong" ways. Attempting to evaluate all the possible combinations of threat agent, attack, vulnerability, and impact is a waste of time and effort. Note that many of the automated tools take this approach - gathering lots of data and producing thousands of possible threats. Generally it is more productive to focus on finding high likelihood and high impact threats.
  
 
The basic threat modeling process consists of the following generic steps. The process of exploring the search space is iterative and constantly refined based on what you have done so far. So, for example, starting with all possible vulnerabilities is usually pointless, as most of them are not attackable by the threat agents, protected by a safeguard, or do not lead to a conseequence. Therefore, it's generally best to start with the factors that make a lot of difference.
 
The basic threat modeling process consists of the following generic steps. The process of exploring the search space is iterative and constantly refined based on what you have done so far. So, for example, starting with all possible vulnerabilities is usually pointless, as most of them are not attackable by the threat agents, protected by a safeguard, or do not lead to a conseequence. Therefore, it's generally best to start with the factors that make a lot of difference.
  
* '''Identify assets and capabilities to be protected''' - The first step is always to understand what's on the line. Identifying tangible assets, like databases of information or sensitive files is usually easy. Understanding the capabilities provided by the application and valuing them is more difficult. Less concrete things, such as reputation and goodwill are the most difficult to measure, but are often the most critical.
+
* '''Assessment Scope''' - The first step is always to understand what's on the line. Identifying tangible assets, like databases of information or sensitive files is usually easy. Understanding the capabilities provided by the application and valuing them is more difficult. Less concrete things, such as reputation and goodwill are the most difficult to measure, but are often the most critical.
  
* '''Identify existing countermeasures''' - Threat modeling is best viewed as an ongoing process throughout the lifecycle. Each iteration should take into account the countermeasures already in place from the last round.  
+
* '''Identify [http://www.owasp.org/index.php/Category:Threat_Agent Threat Agents] and possible [[Attacks]]''' - A key part of the threat model is a characterization of the different groups of people who might be able to attack your application. These groups should include insiders and outsiders, performing both inadvertent mistakes and malicious attacks.
  
* '''Identify threat agents and possible attacks''' - A key part of the threat model is a characterization of the different groups of people who might be able to attack your application. These groups should include insiders and outsiders, performing both inadvertent mistakes and malicious attacks.
+
* '''Understand existing [[Countermeasures]]''' - The model must include the existing countermeasures
  
* '''Identify exploitable vulnerabilities''' -  
+
* '''Identify exploitable [[Vulnerabilities]]''' - Once you have an understanding of the security in the application, you can then analyze for new vulnerabilities. The search is for vulnerabilities that connect the possible attacks you've identified to the negative consequences you've identified.
  
* '''Evalute severity of identified threats''' - asdf
+
* '''Prioritized identified risks''' - Prioritization is everything in threat modeling, as there are always lots of risks that simply don't rate any attention. For each threat, you estimate a number of likelihood and impact factors to determine an overall risk or severity level.
  
* '''Identify countermeasures to reduce threat''' - asdf
+
* '''Identify [[Countermeasures]] to reduce threat''' - The last step is to identify countermeasures to reduce the risk to acceptable levels.
  
 
==Benefits==
 
==Benefits==
  
Done right, threat modeling provides a clear "line of sight" across a project that justifies security efforts. The threat model allows security decisions to be made rationally, with all the information on the table.
+
Done right, threat modeling provides a clear "line of sight" across a project that justifies security efforts. The threat model allows security decisions to be made rationally, with all the information on the table. The alternative is to make knee-jerk security decisions with no support. The threat modeling process naturally produces an assurance argument that can be used to explain and defend the security of an application. An assurance argument starts with a few high level claims, and justifies them with either subclaims or evidence.
 
+
The threat modeling process naturally produces an assurance argument that can be used to explain and defend the security of an application. An assurance argument starts with a few high level claims, and justifies them with either subclaims or evidence.
+
 
+
The alternative to threat modeling is to guess about security decisions and wonder whether you are making the right investment in security.
+
  
 
==References==
 
==References==

Latest revision as of 04:37, 22 June 2010

This category should be used to tag articles that are related to threat modeling.

Contents

Overview

The term "Threat Modeling" has become quite popular recently. Microsoft has published a book about their process and includes threat modeling as a key activity in their Secure Development Lifecycle (SDL).

A threat model is essentially a structured representation of all the information that affects the security of an application. In essence, it is a view of the application and its environment through security glasses.

Threat modeling is a process for capturing, organizing, and analyzing all of this information. Threat modeling enables informed decision-making about application security risk. In addition to producing a model, typical threat modeling efforts also produce a prioritized list of security improvements to the concept, requirements, design, or implementation.


Objectives of Threat Modeling

Threat modeling is a procedure for optimizing Network/ Application/ Internet Security by identifying objectives and vulnerabilities, and then defining countermeasures to prevent, or mitigate the effects of, threats to the system. A threat is a potential or actual undesirable event that may be malicious (such as DoS attack) or incidental (failure of a Storage Device). Threat modeling is a planned activity for identifying and assessing application threats and vulnerabilities.

Threat Modeling Across the Lifecycle

Threat modeling is best applied continuously throughout a software development project. The process is essentially the same at different levels of abstraction, although the information gets more and more granular throughout the lifecycle. Ideally, a high-level threat model should be defined in the concept or planning phase, and then refined throughout the lifecycle. As more details are added to the system, new attack vectors are created and exposed. The ongoing threat modeling process should examine, diagnose, and address these threats.

Note that it is a natural part of refining a system for new threats to be exposed. For example, when you select a particular technology -- such as Java for example -- you take on the responsibility to identify the new threats that are created by that choice. Even implementation choices such as using regular expressions for validation introduce potential new threats to deal with.

Threat Modeling - Generic Steps

For a threat to an application to exist, there must be a combination of the following where the combined likelihood and impact are important enough to do something about. Following is an outline of a generic methodology for Threat Modeling:

  • Assessment Scope
  • System Modeling
  • Identify Threats
  • Identify Vulnerabilities
  • Examining the Threat History
  • Evaluation or Impact on the Business
  • Developing a Security Threat Response Plan

To understand whether an application is secure enough or not, you have to search out combinations of these ingredients that lead to realistic threats. The real trick to threat modeling is not wasting time on threats that are too unlikely or too inconsequential. Beware threat modeling processes that are inefficient about pruning the search space of possible threats to eliminate threats that are very unlikely or have minimal impact.

There is no "right" way to evaluate the search space of possible threats. But there are "wrong" ways. Attempting to evaluate all the possible combinations of threat agent, attack, vulnerability, and impact is a waste of time and effort. Note that many of the automated tools take this approach - gathering lots of data and producing thousands of possible threats. Generally it is more productive to focus on finding high likelihood and high impact threats.

The basic threat modeling process consists of the following generic steps. The process of exploring the search space is iterative and constantly refined based on what you have done so far. So, for example, starting with all possible vulnerabilities is usually pointless, as most of them are not attackable by the threat agents, protected by a safeguard, or do not lead to a conseequence. Therefore, it's generally best to start with the factors that make a lot of difference.

  • Assessment Scope - The first step is always to understand what's on the line. Identifying tangible assets, like databases of information or sensitive files is usually easy. Understanding the capabilities provided by the application and valuing them is more difficult. Less concrete things, such as reputation and goodwill are the most difficult to measure, but are often the most critical.
  • Identify Threat Agents and possible Attacks - A key part of the threat model is a characterization of the different groups of people who might be able to attack your application. These groups should include insiders and outsiders, performing both inadvertent mistakes and malicious attacks.
  • Understand existing Countermeasures - The model must include the existing countermeasures
  • Identify exploitable Vulnerabilities - Once you have an understanding of the security in the application, you can then analyze for new vulnerabilities. The search is for vulnerabilities that connect the possible attacks you've identified to the negative consequences you've identified.
  • Prioritized identified risks - Prioritization is everything in threat modeling, as there are always lots of risks that simply don't rate any attention. For each threat, you estimate a number of likelihood and impact factors to determine an overall risk or severity level.
  • Identify Countermeasures to reduce threat - The last step is to identify countermeasures to reduce the risk to acceptable levels.

Benefits

Done right, threat modeling provides a clear "line of sight" across a project that justifies security efforts. The threat model allows security decisions to be made rationally, with all the information on the table. The alternative is to make knee-jerk security decisions with no support. The threat modeling process naturally produces an assurance argument that can be used to explain and defend the security of an application. An assurance argument starts with a few high level claims, and justifies them with either subclaims or evidence.

References