Threat modeling is a simple, cost-effective way to ensure cybersecurity does not become an afterthought in the SDLC or a set of strictly reactive countermeasures. This practice makes apps and systems secure by design, which leads to fewer vulnerabilities in production, less risk for the business, and lower IT remediation costs.
This article is an intro to threat modeling and the positive effects early flaw detection and removal have on security posture. Read on to learn how threat modeling works and see what your business stands to gain from adopting this proactive practice.
What is Threat Modelling?
Threat modeling is the practice of systematically identifying and addressing flaws within an IT asset before someone gets a chance to exploit the vulnerability. The procedure relies on various techniques (risk criticality, brainstorming sessions, hypothetical scenarios, flow charts, diagrams, etc.) and requires input from both business and technical stakeholders.
A "threat" is a broad term that stands for someone or something that tries to perform one (or more) of the following:
- Compromise or alter critical business functions.
- Steal data or compromise its integrity.
- Destroy business systems.
- Use a system as an attack platform (e.g., turning a device into a DDoS bot).
Every threat modeling process has the following objectives:
- Get a clear picture of the asset in question (database, network, business process, infrastructure, etc.).
- Determine security, business, and technical requirements.
- Pinpoint all probable risks and threats.
- Analyze the nature of each threat, its likelihood, and the danger it poses to the asset.
- Specify threat actors, their motives, and TTP (tools, techniques, and procedures).
- Determine threat criticality (which helps prioritize remediation).
- Assess the company's current readiness to respond to each threat.
- Suggest optimal fixes and improvements.
Analysts store these findings in a threat model, a "living" document that requires regular reviews and updates. Creating threat models and keeping them up to date requires a cross-team effort that involves inputs from:
- Business stakeholders.
- Project managers.
- Security architects.
- The operations/infrastructure team.
- Software developers.
Ideally, threat modeling occurs during the design stage of a new app or feature. A team can build a model from three different perspectives:
- Asset-centric (take stock of valuable assets and analyze their vulnerabilities).
- Attacker-centric (take on the role of an attacker and see how a would-be hacker might try to compromise an asset).
- Software-centric (focus on system design and look for flaws on an architectural level).
Large companies and enterprises are not the only ones that should invest in threat models. Criminals prefer going after targets they presume have fewer cybersecurity measures, which makes SMBs prime candidates for threat modeling adoption.
Threat Modelling Benefits for DevOps Security
Introducing threat modeling into a DevOps culture provides the following benefits:
- The team "injects" security by design principles into the system architecture.
- You cut down on the number of bugs and exploits that end up in production.
- The team adopts a proactive approach to security that does not wait for something to go wrong before intervention.
- Threat models raise security awareness on a company-wide level due to the multi-team approach to security planning.
- You improve security posture at every stage of the DevOps pipeline.
- The company gets an in-depth overview of every mission-critical and valuable IT asset, plus a deep understanding of network security and app architecture.
- The team no longer makes security-related decisions based on a hunch or without supporting evidence.
- Security experts become ready both for external and insider threats.
- You improve the chance of discovering risks that fly under the radar of standard code reviews.
- The company reduces remediation costs since every threat model includes in-depth incident response plans.
- The testing costs go down as code leaves development with more quality.
- The team lowers the number of typical omissions (failing to validate input, weak authentication, inadequate error handling, failing to encrypt data, etc.).
- In-depth threat prioritization helps better allocate people and budget resources.
- The business ensures more reliable compliance with industry-specific regulations.
- The DevOps security team and its defenses stay up to date with the latest cybersecurity best practices and types of cyber attacks.
Threat Modelling Process: How to Make a Threat Model
Here's a step-by-step look at how to create a threat model:
- Set the scope: Decide what asset requires threat modeling (an app, service, intellectual property, etc.) and narrow the focus to a specific system.
- Initial evaluation: Create an inventory of the asset's components. Map the architecture and create high-level data flow diagrams to analyze the asset's role in the company.
- In-depth asset analysis: The team requires a deep understanding of every event or action that takes place in the system. How does the business use the asset? What makes it a worthwhile target for an attack? How does the system interact with users and other systems? What are its entry and exit points? Are there any external dependencies? Who has access to the asset?
- Determine likely threats: This step requires the team to list as many potential threats to the asset as possible.
- Analyze each danger: Analysts create step-by-step scenarios that outline exactly how each threat would unfold (e.g., ransomware attack, data exfiltration, SQL injection, etc.).
- Create a threat ranking: The team determines the level of risk each threat poses. The most common method is to multiply the damage potential of a threat by the probability of the incident occurring.
- Suggest mitigations: The team now decides the best course of action to deal with each threat. A mitigation plan either removes the threat entirely or reduces the risk to an acceptable level. Common fixes include firewall updates, the addition of multi-factor authentication, code changes, operating system updates, etc.
- Document results: Document all findings and share them with a decision-maker. The threat modeling team should periodically inspect the model and see whether there's a need for an update. Good times for review are when an asset goes through a massive change or when a new strategy emerges on the cybercrime landscape.
One of the key metrics of every threat model is the work factor. Work factor evaluates how much work an attacker would need to compromise a system. The higher the work factor, the more likely the criminal will move on to an easier target.
Threat Modeling Methodologies
Let's look at the ten threat modeling frameworks companies use to boost cybersecurity. Every framework focuses on one aspect of threat modeling, so remember that a well-rounded analysis requires a combined use of multiple methodologies we discuss below.
STRIDE
Developed by Microsoft in the late 1990s, STRIDE helps analyze all potential threats within a system. The team must first decompose an app to identify system entities, events, and boundaries before evaluating each component's proneness to the following threats:
| Threat type | What it violates | Threat description | |
|---|---|---|---|
| S | Spoofing | Authentication | When someone assumes a false identity |
| T | Tempering with data | Integrity | Unauthorized modification of data |
| R | Repudiation | Non-repudiation | An intruder's ability to deny malicious activity due to a lack of evidence |
| I | Information disclosure | Confidentiality | Providing access to data to someone who has no authorization |
| D | Denial of service | Availability | Exhausting resources needed to provide service to users |
| E | Elevation of privilege | Authorization | The execution of commands or functions beyond the jurisdiction of account privileges |
STRIDE is among the most mature threat-modeling methods on the market. The framework evolved to include several new threat-specific tables (most notably STRIDE-per-Element and STRIDE-per-Interaction).
PASTA
PASTA (Process for Attack Simulation and Threat Analysis) is a risk-centric framework that aims to align security requirements with business objectives. This framework involves a seven-step analysis:
- Define objectives.
- Set the technical scope.
- Perform app decomposition.
- Analyze possible threats.
- Identify vulnerabilities and flaws.
- Create attack models.
- Perform risk and impact analysis.
The PASTA framework also includes documentation for dynamic threat identification, enumeration, and a scoring process.
Attack Trees
Attack trees are among the oldest and most widely applied techniques for threat modeling. This framework works in the following manner:
- Each root node represents an attacker's goal (e.g., cause data leakage or hijack an email address).
- Each leaf node denotes the possible means of reaching the attacker's goal (these often include "AND" and "OR" conditions).
- Analysts associate each node with a vulnerability score and potential impact.
Attack trees are a simple method ideal for high-level threat modeling and teams comfortable with brainstorming sessions.
CVSS
The Common Vulnerability Scoring System (CVSS) is a risk estimation framework that provides a standardized scoring system for vulnerabilities. An analyst assigns a severity score (ranging from 0 to 10) to each threat based on the three broad metric groups:
- Base (includes exploitability metrics (vectors, attack complexity, required privileges, user interactions, etc.) and impact metrics (the effect on availability, data integrity, etc.)).
- Temporal (exploit code maturity, remediation level, etc.).
- Environmental (base metrics such as requirements for confidentiality or availability).
Once all flaws have a numerical score and a category, the team assigns a qualitative representation (low, medium, high, and critical) and begins prioritizing mitigation tasks.
The combined use of CVSS, STRIDE, and attack trees is known as the Quantitative Threat Modeling Method.
Security Cards
Security cards are the go-to option for teams trying to identify new attack vectors. This brainstorming technique requires the use of a specialized deck of 42 cards that represent threat-related activities, including:
- Attacker motivations (13 cards).
- Human impact (9 cards).
- Hacker resources (11 cards).
- Adversary's methods (9 cards).
Each card contains a topic, questions to jump-start thinking, and a few examples. Team members take out two or more cards and discuss whether the random combos might pose a realistic attack scenario.
Security cards are excellent for identifying out-of-the-box strategies that generally fly under the radar with regular threat modeling.
OCTAVE
OCTAVE (Operationally Critical Threat, Asset, and Vulnerability Evaluation) is a risk-based assessment with three broad phases:
- Create asset-based threat profiles.
- Identify and evaluate infrastructure vulnerabilities.
- Develop an appropriate security plan for each discovered risk.
This framework focuses solely on assessing organizational risks, so the framework does not consider or address technological risks.
Persona non Grata
Persona non Grata (PnG) is the ultimate attacker-centric threat modeling. PnG enables a team to develop a detailed picture of a hypothetical attacker, including their:
- Psychology.
- Motivations.
- Goals.
- Capabilities.
- Go-to tools and techniques.
- Thinking processes during an attack.
PnG helps get into the mindset of a potential intruder, which is vital to the early stages of threat modeling. Also, when you combine PnG with Security Cards and SQUARE (Security Quality Requirements Engineering Method), you get the Hybrid Threat Modeling Method (hTMM).
TRIKE
TRIKE is a security audit that looks at threat modeling from a risk-management perspective. This framework relies on a defensive viewpoint rather than trying to understand the mindset of a potential attacker.
TRIKE starts with a matrix chart that summarizes the relationships between actors, actions, and assets. The columns represent assets, and the rows denote actors present in the system. The analyst divides each cell into four parts, one for each action of the CRUD (creating, reading, updating, and deleting). Analysts assign one of three values in each action cell:
- Allowed action.
- Disallowed action.
- Allowed with rules.
The team uses the matrix to build a data flow diagram (DFD) to map each element to actors and assets. The goal is to assign each actor a score based on risk level (from 0 to 5) for each action or asset interaction.
VAST
VAST (Visual, Agile, and Simple Threat) is a type of threat modeling that focuses on development and infrastructure safety. The framework requires a team to analyze two model types:
- App threat models (process-flow charts that analyze threats that come from interacting with users and other systems).
- Operational threat models (data-flow diagrams that analyze an app from an infrastructure point of view).
VAST is a popular choice for DevOps and agile teams due to the framework's highly scalable nature.
DREAD
DREAD is a quantitative risk analysis that rates, compares, and prioritizes threats based on severity. Initially developed as an add-on for the STRIDE model, DREAD stands for six questions the analyst asks about each potential threat:
- Damage potential: How great is the damage if an attacker exploits a vulnerability?
- Reproducibility: How easy is it to reproduce the attack?
- Exploitability: How hard is it to start an attack?
- Affected users: How many users would feel the effects of an attack?
- Discoverability: How easy is it to discover the threat?
The threat modeling team answers these questions and assigns a rating between one and three. The sum total represents the severity level of a threat.
Unsure whether threat modeling resulted in a safer system? Consider running a few pen tests—penetration testing is a form of ethical hacking in which you perform simulations of real-life attacks to check the system's readiness for breach attempts.
Threat Modeling Tools
While a team can perform basic threat modeling on a sheet of paper, larger companies with a high count of vulnerabilities should use software to simplify the process.
Tools reduce the complexity of threat modeling and let a team visualize, design, plan for, and predict different types of potential dangers. Some top tools also offer suggestions for remediation. Here are a few worthwhile options:
- Microsoft Threat Modeling Tool (MTTM): This free-to-use software focuses on detecting threats and flaws during the design phase of software projects. The tool aligns with various Microsoft services and follows the STRIDE methodology.
- Cairis: This open-source, web-based tool enables users to elicit, describe, and evaluate system risk. Cairis offers one of the most comprehensive features of all threat modeling tools (attacker personas, in-depth attack breakdowns, pattern analysis, mitigation recommendations, etc.)
- OWASP: This open-source tool (which runs as a web or a desktop app) produces threat model diagrams that align with the development lifecycle. OWASP offers similar features to MTTM but with less focus on Microsoft-centered services.
- ThreatModeler: This automation-driven tool enables users to make proactive security decisions and reduce risk across a broad attack surface. ThreatModeler supports several regulatory standards, including GDPR and PCI.
- IriusRisk: This diagram-centric system asks analysts questions about the system and uses the info to create a list of potential threats and suggested mitigation strategies.
As with methodologies, you can use more than one threat modeling tool. You get the most robust and insightful analysis by relying on several platforms for gathering, visualizing, and organizing threat-related info.
Take a Proactive Stance Against Cybercrime
Being stuck in a reactive security cycle is a recipe for operational and financial disaster. Threat modeling presents an alternative based on a simple calculation: the price of being prepared far outweighs the cost of remediation (especially when caught off guard). Some basic threat modeling requires no upfront investments at all, so stop focusing on putting out fires and instead start planning how to lower risks.
