This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "Category:Threat Modeling"

From OWASP
Jump to: navigation, search
Line 1: Line 1:
This category should be used to tag articles that are related to threat modeling. This might include articles about
+
This category should be used to tag articles that are related to threat modeling.
* structuring a threat modeling effort
 
* tools and techniques for threat modeling
 
* examples of threat models
 
  
You should visit the [[:Category:OWASP CLASP Project|OWASP CLASP Project]] for more information.
+
==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).
 +
 
 +
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.
 +
 
 +
==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.
 +
 
 +
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.
 +
 
 +
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.
 +
 
 +
==Threat Modeling - Generic Steps==
 +
 
 +
For a threat to an application to exist, there must be:
 +
 
 +
* a threat agent
 +
* a viable attack
 +
* a vulnerability not blocked by a countermeasure
 +
* a negative impact to the business
 +
 
 +
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.
 +
 
 +
The basic threat modeling process consists of the following generic steps. Each step may have a special name at a particular phase of the lifecycle.
 +
 
 +
; 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.
 +
 
 +
; 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 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 exploitable vulnerabilities
 +
:
 +
 
 +
; Evalute severity of identified threats
 +
:
 +
 
 +
; Identify countermeasures to reduce threat
 +
:
 +
 
 +
==Threat Modeling - Concept Phase==
 +
 
 +
Threat modeling can and should be used very early in the concept and planning phase of an application to help get a handle on security very early in the process.  The threat model at the concept phase defines the broad outlines of security, such as the primary classes of attackers, the broad classes of assets and functions managed by the application, and the basic security mechanisms in place.
 +
 
 +
==Threat Modeling - Requirements Phase==
 +
 
 +
TBD
 +
 
 +
==Threat Modeling - Architecture Phase==
 +
 
 +
TBD
 +
 
 +
==Threat Modeling - Implementation Phase==
 +
 
 +
TBD
 +
 
 +
==References==
 +
 
 +
* [http://blogs.msdn.com/threatmodeling Microsoft's Application Consulting & Engineering Team's Threat Modeling Blog]
 +
* [http://www.rockyh.net/Posts/Post.aspx?postId=c85d6411-3eb8-4f26-9213-cbd735d01979 RockyH.net Threat Modeling v2]
 +
* [http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsecure/html/sdl.asp Microsoft's Security Development Process]
  
 
[[Category:Activity]]
 
[[Category:Activity]]

Revision as of 02:52, 26 September 2006

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

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.

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.

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.

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.

Threat Modeling - Generic Steps

For a threat to an application to exist, there must be:

  • a threat agent
  • a viable attack
  • a vulnerability not blocked by a countermeasure
  • a negative impact to the business

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.

The basic threat modeling process consists of the following generic steps. Each step may have a special name at a particular phase of the lifecycle.

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.
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 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 exploitable vulnerabilities
Evalute severity of identified threats
Identify countermeasures to reduce threat

Threat Modeling - Concept Phase

Threat modeling can and should be used very early in the concept and planning phase of an application to help get a handle on security very early in the process. The threat model at the concept phase defines the broad outlines of security, such as the primary classes of attackers, the broad classes of assets and functions managed by the application, and the basic security mechanisms in place.

Threat Modeling - Requirements Phase

TBD

Threat Modeling - Architecture Phase

TBD

Threat Modeling - Implementation Phase

TBD

References