Threat model

Threat modeling addresses two distinct, but related, topics in computer security:

• The first is a description of the security issues and resources the designer cares about. This is often represented as a Data Flow Diagram (DFD) that shows the potential attack points from outside the system.
• The second includes in, Threat modeling the development of attack trees, which are descriptions of a set of computer 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.^[1]

It is often useful to define many separate threat models for one computer system. Each model defines a narrow set of possible attacks to focus on. A threat model can help to assess the probability, the potential harm, the priority etc., of attacks, and thus help to minimize or eradicate the threats. More recently, threat modeling has become an integral part of Microsoft's SDL (Security Development Lifecycle) process.^[2] A 2015 report, the "DoD Comprehensive Military Unmanned Aerial Vehicle Smart Device Control Station Threat Model"^[3] emphasizes a holistic approach to Threat Modelling and the need for a full analysis of the threats modelled. Most organizations will need to take the more cost-effective approach of targeting those issues and resources of most importance to them. In any case the threat model by itself will not change the security of the organization until an analysis of the threats leads to mitigations of those most likely to harm the organization or the resources that it wants to protect.

Threat modeling is based on the notion that any system or organization has assets of value worth protecting, these assets have certain vulnerabilities, internal or external threats exploit these vulnerabilities in order to cause damage to the assets, and appropriate security countermeasures exist that mitigate the threats.

Approaches to threat modeling

There are at least three 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 copy this DVD and share it with his friends." This approach usually starts from either entry points or assets.

Software-centric

Software-centric threat modeling (also called 'system-centric,' 'design-centric,' or 'architecture-centric') 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.

Asset-centric

Asset-centric threat modeling involves starting from assets entrusted to a system, such as a collection of sensitive personal information.

Example threat modeling approach

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.

According to Dan Griffin of JW Secure, 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 significantly more expensive than functionality bugs.

Current threat modeling takes on a defender's perspective. This means that threats are examined and countermeasures, or security services, are identified at the design stage 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. However, the disadvantage is that all threats can not be identified unless the code is trivially simple and often threat modeling on a defender's perspective will cause the development team to falsely believe that the code is secure.

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.

See also

• Category:Computer security exploits — Types of computer security vulnerabilities and attacks
• Application security
• Attack tree
• Computer insecurity
• Computer security
• Data security
• Economics of security
• Information assurance
• Information security
• IT risk
• Network security
• Risk assessment
• Risk management
• Security engineering
• Software architecture
• Software Security Assurance
• STRIDE (security)
• Threat (computer)
• Vulnerability (computing)

References

1. Threat modeling, abuse cases, data classification BSIMM, the Building Security In Maturity Model
2. http://msdn.microsoft.com/msdnmag/issues/05/11/SDL/
3. DoD Comprehensive Military Unmanned Aerial Vehicle Smart Device Control Station Threat Model,

• Software Development Lifecycle: Usability and Threat Modeling. Retrieved from: http://www.jwsecure.com/publications/jw-secure-informer-23
• Dan Griffin's Blog. "MS08-067 and the ripple effect of Windows security bugs". Retrieved from: http://www.jwsecure.com/2008/10/24/ms08-067-and-the-ripple-effect-of-windows-security-bugs/
• ThreatModeler. Retrieved from http://www.myappsecurity.com/

External links

• Threat Modeling: Past, Present and Future
• Threat Modeling from OWASP
• Top 5 Reasons to Implement Threat Modeling (2013)
• Threat Modeling as a Basis for Security Requirements - NCASSR Publications
• ThreatModeler: MyAppSecurity's Software-Centric Threat Modeling Product
• Microsoft's Application Consulting & Engineering Team's Threat Modeling Blog
• The Microsoft SDL Threat Modeling Tool
• Uncover Security Design Flaws Using The STRIDE Approach
• Guerrilla Threat Modelling (or 'Threat Modeling' if you're American)
• Summary and Comparison of Threat Modeling Methodologies (2012)
• Securing Code through Threat Modeling (2014)
• Overview of Threat Modeling