We tend to associate security with specific technologies–encryption, VPNs, authentication protocols, but no single technology guarantees security; attacks come from many different directions and target the least suspected of vulnerabilities. We need to make our best effort to ensure comprehensive protection. To achieve that end, threat modeling is an essential first step. While threat modeling might sound rather academic, it is in fact entirely practical and something you can and certainly should apply in your organization and to all of your applications. And as we’ll see in this post, there is almost certainly an available threat modeling methodology that will work for you.
To gain a broad view of threat modeling apart from specific technologies, it’s worth taking a step back and realizing threat modeling has its origins in the military dating back long before the computer age. When Sun Tzu wrote in the fifth century BC that “if you know the enemy and know yourself, you need not fear the result of a hundred battles,” he was extolling the value of threat modeling. In explaining that “first comes scoping, then measurement, then calculation, then balancing and finally victory,” Sun Tzu illustrated the importance of process and of comprehensiveness, the keys to successful threat modeling.
In the field of computer security, threat modeling achieves comprehensiveness through abstractions, beginning with broad categories of threats and system architectures rather than implementation details or concrete attacks. Such abstraction encourages us to think through a broad array of threats and prevents us from getting caught up in a small number of specific threats. It prevents us from building multiple layers of mitigation against one threat while ignoring others. Threat modeling promotes comprehensive security coverage over random, haphazard, whack-a-mole defenses.
In addition to ensuring comprehensiveness, threat modeling includes the prioritization of threats and mitigations based on probabilities, business impacts, and costs of countermeasures. In other words, threat modeling requires both technical and financial calculations.
Since the late 1990s, several methodologies for threat modeling have evolved. Let’s review a few of the more popular techniques so that you can pick out which best suits your needs. Then you can follow the links to learn more and get yourself started improving security.
In a 1999 Dr. Dobb’s article, Bruce Schneier popularized the idea of attack trees, which have developed into a mainstay of threat modeling.
In an attack tree, the root node represents an attacker’s objective, such opening a safe. Second level nodes represent how an attacker might achieve the objective, such as stealing the safe’s combination or blasting the door open. Leaf nodes indicate steps required to carry out the approach, such as purchasing dynamite.
In the tree, nodes may be joined by AND or OR logic, meaning that the attacker is either required to take each step or may choose between steps. In addition, the modeler may add attributes to nodes indicating difficulty level, attack cost, risk to the attacker, special equipment, and likelihood that any particular category of attacker might take this path. Based on the logic and attributes, the model determines the most likely attacks.
Because any given application might present an attacker with several attack goals, such as stealing PII or transferring balances between accounts, a complete threat model will require multiple trees. That is, a threat model is a forest of attack trees.
Many trees that a modeller creates will apply to multiple applications. An organization, therefore, should develop a library of attack trees to use with each new analysis.
Building attack trees promotes comprehensiveness. Given its simplicity and power, the technique has been incorporated into most popular threat modeling methodologies.
The Carnegie Mellon Software Engineering Institute first published the Operationally Critical Threat, Asset, and Vulnerability Evaluation Framework (OCTAVE) in 1999. Unlike other methodologies that focus on specific applications, OCTAVE covers threat modeling of the information assets for an entire organization. OCTAVE is a comprehensive process description complete with stages, processes, inputs, and outputs.
Phase 1: Build Enterprise-Wide Security Requirements
Work with staff from multiple levels of the organization, identify information assets and their values in order to document security requirements.
Process 1: Identify Enterprise Knowledge (gather viewpoints of senior managers)
Process 2: Identify Operational Area Knowledge (gather viewpoints of operational managers)
Process 3: Identify Staff Knowledge (gather viewpoints of staff)
Process 4: Establish Security Requirements (integrate perspectives)
Phase 2: Identify Infrastructure Vulnerabilities
Associate assets to infrastructure and infrastructure to vulnerabilities.
Process 5: Map High-Priority Information Assets to Information Infrastructure (use staff knowledge to link assets to infrastructure, asset locations, and data flows)
Process 6: Perform Infrastructure Vulnerability Evaluation (associate infrastructure components with standard catalogs of intrusion scenarios)
Phase 3: Determine Security Risk Management Strategy
Create the final output document with risk analysis and mitigation plans.
Process 7: Conduct Multi-Dimensional Risk Analysis (estimate probabilities and impacts based on asset and vulnerability assessments)
Process 8: Develop Protection Strategy (select mitigation strategies based on costs and resources)
The OCTAVE process results in a comprehensive security risk management plan that covers a security strategy and continual risk management. It is appropriate to large enterprises seeking a threat model that applies across all applications and information assets.
Microsoft Security Development Lifecycle
Microsoft has defined a Security Development Lifecycle that includes threat modeling as well as other processes such as testing and incident planning. Microsoft’s threat modeling guidelines propose the following steps:
- Identify assets. What should the system protect?
- Create an architecture overview. Focus on trust boundaries, that is data flows from components owned by one entity to components owned by another entity.
- Decompose the application into subcomponents to as low a level as practical.
- Identify the threats. Use either STRIDE or a threat tree to aid in enumeration.
- STRIDE is an acronym for spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege. These broad vulnerability descriptions are not meant to be mutually exclusive, comprehensive categories, rather heuristics for enumeration. Examine each component, focusing on trust boundaries, and consider whether it exposes each of these vulnerabilities.
- Attack trees, as described by Schneier, can substitute for STRIDE.
- Document the threats.
- Rate the threats. Microsoft recommends the DREAD model, an acronym for damage potential, reproducibility, exploitability, affected users, discoverability. Threats that rank high in each of these categories should receive a higher priority rating.
The comprehensive, prioritized list of threats serves as an input into a mitigation design process. The mitigation design culminates in a set of bug reports to implement mitigations. The Microsoft Security Development Lifecycle may apply to software producers as well as organizations creating their own custom applications. It could be used by startups as well as large enterprises.
After gaining experience with the Microsoft STRIDE method, the creators of Trike found it dull and repetitive. And as you might expect of software developers, they decided to formalize and automate: “The formalisms in the Trike methodology are designed to support automation to the greatest degree possible. These same formalisms also allow us to give strong guarantees which other, more ad-hoc methodologies cannot; specifically, that when we enumerate all threats against an application, we have in fact enumerated all possible threats.” To achieve this end, the methodology involves attack trees as well as state diagrams of all actions possible within a system.
While interesting in concept, perhaps the objectives were too ambitious. All signs of work on the project ended in 2012. This failure to automate suggests that threat modeling requires human judgment as well as a certain tolerance for tedium.
Process for Attack Simulation and Threat Analysis (PASTA)
While the Microsoft SDLC fits the needs of a software organization that releases products requiring security, PASTA very much applies to the information needs of large enterprises. Created by Tony UcedaVélez, a founder of an information security consultancy, and Marco Morana, an Information Security Strategist at Citi, PASTA focuses on risk management as a way to link information security to the financial concerns of executives.
The PASTA methodology builds upon the Microsoft SDLC, beginning likewise with a list of stages:
- Define business objectives: What are the business objectives of the application and the business risk of breaches? Who are the proposed users and what are the use cases? What are the relevant governance and compliance standards?
- Technical scope: What technology stacks do you have? What are the components? What comprises the infrastructure and third-party services?
- Application decomposition: How do the components work together? What are the sequence diagrams and DFDs (Data Flow Diagrams)?
- Threat analysis: Examine the threat landscape of your industry. Study available threat intelligence. Understand which threats are relevant to this application and their probabilities.
- Vulnerability assessment: What is weak in the application? Study standards for vulnerability enumeration.
- Attack enumeration: List the attacks that might take advantage of application vulnerabilities. Map exploits to DFDs.
- Countermeasure development/residual risk analysis: Manage risks by mitigating the most probable and impactful threats and understand remaining risks. Develop cost-benefit analyses of mitigations.
Each stage consists of a set of activities with defined inputs and outputs and a RACI chart mapping roles within the methodology to roles within the enterprise, all culminating in a business-centric risk management proposal designed to win executive support. The methodology is appropriate to software development within large enterprises as it orchestrates the roles of the many stakeholders involved.
While the final result might be a list of bug tickets or a comprehensive risk management plan, threat modeling methodologies all share common themes: a systematic approach involving multiple stakeholders and techniques that aims at a comprehensive listing of threats, prioritizations, and mitigations.
As your organization or application might face unique threats or have special requirements, I would recommend pulling from each methodology whatever makes sense. Borrow, mix, and adapt. Most importantly, get started. There can be no comprehensive security without threat modeling, and you will improve with practice.