Threat model

From Wikipedia, the free encyclopedia

 This article or section needs to be wikified to meet Wikipedia's quality standards.
Please help improve this article with relevant internal links. (August 2007)

In computer security, the term threat modeling has two distinct, but related meanings. The first is a description of the security issues the designer cares about. This is the sense of the question, "What is the threat model for DNSSec?" In the second sense, a threat model is a description of a set of security aspects; that is, when looking at a piece of software (or any computer system), one can define a threat model by defining a set of possible attacks to consider. It is often useful to define many separate threat models for one computer system, this way you have groups of more narrow set of possible attacks to focus on. Having a threat model you can assess the probability, the potential harm, the priority etc. of attacks, and from this point on try to minimize or eradicate the threats. More recently, threat modeling has become an integral part of Microsoft's SDL (Security Development Lifecycle) process.[1] The two senses derive from common military uses in the United States and the United Kingdom.

The fundamental assertion behind threat modeling is that threats are realized through attacks which can materialize through certain vulnerabilities if they have not been mitigated with appropriate countermeasures.

Contents

[edit] The threat modeling Process

There are two general approaches to threat modeling:

Attacker-Centric

Attacker-centric threat modeling starts with an attacker, and evaluates their goals, and how they might achieve them. Attacker's motivations are often considered, for example, "The NSA wants to read this email," or "Jon wants to watch this DVD on his Linux system." This approach usually starts from either entry points or assets.

System-Centric

System-centric threat modeling starts from the design of the system, and attempts to step through a model of the system, looking for types of attacks against each element of the model. This approach is used in threat modeling in Microsoft's Security Development Lifecycle.

[edit] Updated threat modeling approach

 The tone or style of this article or section may not be appropriate for Wikipedia.
Specific concerns may be found on the talk page. See Wikipedia's guide to writing better articles for suggestions.(December 2007)

Threat modeling has changed in recent times (around 2004) to take on a more defensive perspective rather than an adversarial perspective. The problem with an adversarial perspective is that it is reactive.

When you adopt an adversarial perspective, you examine software applications, or any system, by trying to find holes in it and ways they might be exploited. Techniques that are often used in an adversarial approach are penetration testing (white box and black box), and code review. While these are valuable techniques to discover potential problems, the flaw is that you can only use them once the software has been written.

This means that if you discover any security related problems, you have to rework and re-write your code. This is very expensive in terms of both time and money.

Security bugs have a much larger impact than functionality bugs. Since code around security usually touches every portion of the application, the 'ripple effect' makes the cost exponentially more expensive than functionality bugs.

Current threat modeling takes on a defender's perspective. This means that threats are examined and countermeasures, or mitigations, are identified at the design state of the application before any code is written. This way the defensive mechanisms are built into the code as it is written rather than patched in later. This is much more cost effective and has the added benefit of increasing security awareness in the development team.

A general high level overview of common steps in the defensive perspective threat modeling are:

  • Define the application requirements:
    • Identify business objectives
    • Identify user roles that will interact with the application
    • Identify the data the application will manipulate
    • Identify the use cases for operating on that data that the application will facilitate
  • Model the application architecture
    • Model the components of the application
    • Model the service roles that the components will act under
    • Model any external dependencies
    • Model the calls from roles, to components and eventually to the data store for each use case as identified above
  • Identify any threats to the confidentiality, availability and integrity of the data and the application based on the data access control matrix that your application should be enforcing
  • Assign risk values and determine the risk responses
  • Determine the countermeasures to implement based on your chosen risk responses
  • Continually update the threat model based on the emerging security landscape.

[edit] See also

[edit] External links