COMP 6660 · Enterprise Cybersecurity Threat Modeling Methodologies

00 Introduction

Lesson 3.1 established risk as the organising principle of enterprise security. Threat modeling is the discipline that produces the threats that risk assessment evaluates.

Without threat modeling, enterprise security tends to operate reactively: scanners find vulnerabilities, incidents reveal weaknesses, and auditors point out gaps. The enterprise responds to what has already been discovered, and the adversary chooses when and where to strike. Threat modeling inverts this relationship. It is the structured discipline through which the enterprise reasons about what could go wrong — deliberately, before the adversary demonstrates it.

Threat modeling has been practised in software development for two decades and is increasingly applied at the system, architecture, and enterprise levels. It brings together the assets identified in Lesson 1.2, the objectives from Lesson 1.3, the threat actors from Lesson 1.4, and the risk framework from Lesson 3.1. Its outputs — documented threats, attack paths, and trust boundaries — are the inputs to the risk assessment and control selection work that follows.

This lesson examines threat modeling in detail. It defines what threat modeling is and why it matters. It introduces the core concepts and artifacts — assets, adversaries, attack paths, trust boundaries, data flow diagrams. It surveys the principal methodologies: STRIDE, PASTA, LINDDUN, attack trees, kill chains, and MITRE ATT&CK. It shows how to conduct a threat-modeling exercise, and how to apply the outputs to enterprise decisions. And it addresses the pitfalls that recur across enterprise threat-modeling programmes.

01 Learning objectives

By the end of this lesson you should be able to:

These objectives contribute to Unit 3 outcomes U3.1 (threat analysis) and U3.2 (risk and vulnerability assessment), and to Module 2 outcomes M2.1 and M2.2. See the Unit 3 learning outcomes page for the full mapping.

02 What threat modeling is

Threat modeling is not vulnerability scanning. Scanning identifies known weaknesses in implemented systems; threat modeling reasons about what could go wrong in design — before the system is built, or before the adversary demonstrates the weakness. It is not incident response; it happens before the incident, not after. And it is not a one-time activity; it is a recurring discipline that accompanies change.

The four questions of threat modeling

Most threat-modeling methodologies reduce to four questions, expressed in different ways but always present:

Threat modeling in the enterprise lifecycle

Threat modeling can be applied at multiple levels and at multiple points in the lifecycle:

• Design phase. Modelling the system before it is built, so that threats are identified while changes are still cheap. This is the traditional software-development application of threat modeling.
• Change phase. Re-modelling when the system changes significantly — new components, new interfaces, new data flows, new integrations.
• Architecture review. Modelling at the architecture level — how systems interact, where trust boundaries sit, what the attack paths are.
• Enterprise level. Modelling at the enterprise level — which threat actors plausibly target the enterprise, which attack classes are most consequential, and which defensive investments address them.
• Acquisition and third-party assessment. Modelling third-party systems and services as though they were the enterprise's own, so that risks introduced through the supply chain are understood.

03 Why threat modeling matters

Threat modeling is sometimes treated as a theoretical exercise — interesting but not essential. This section argues that it is essential, for five reasons.

Reason 1 — It finds threats that reactive tools do not

Vulnerability scanners find known vulnerabilities in implemented systems. They cannot find logic flaws, design weaknesses, or vulnerabilities that arise from how components are combined. Many of the most consequential enterprise breaches have exploited design flaws that no scanner would have found — because the flaw was in the design, not in a known-vulnerable component.

Threat modeling reasons about the system as designed, and can identify threats that arise from the combination of components, from trust relationships, from data flows, and from the interaction between systems.

Reason 2 — It shifts security left

The cost of addressing a security issue rises dramatically the later it is discovered. A design flaw identified during architecture review may be corrected with a conversation. The same flaw discovered after deployment may require redesign, rework, and regression. The same flaw discovered after an incident may require incident response, remediation, disclosure, and regulatory engagement.

Threat modeling shifts security work to the earliest point where it can be done — during design, when change is still cheap.

Reason 3 — It surfaces assumptions

Security architecture rests on assumptions: this system is trusted, that interface is protected, these data flows are encrypted, this third party is reliable. Assumptions are dangerous when they are unstated, because they become invisible and unexamined. Threat modeling forces assumptions to the surface — and once surfaced, they can be tested.

Reason 4 — It prioritises investment

Not every threat requires treatment. Threat modeling produces a structured list of threats, each with an assessment of likelihood and impact — the raw material for risk-based prioritisation. Without threat modeling, priorities tend to reflect whatever the scanner reported or whoever argued loudest.

Reason 5 — It supports communication and governance

Threat models are communicable. They can be shown to technical teams, to architects, to executives, and to auditors. They provide a common language for discussing what could go wrong and what should be done about it — and they produce documentation that demonstrates the enterprise has reasoned about threats deliberately, not merely reacted to them.

04 Core concepts and artifacts

Threat modeling uses several core concepts and produces several standard artifacts. Understanding them is prerequisite to understanding the methodologies that follow.

Core concepts

Data flow diagrams

The data flow diagram is the workhorse of threat modeling. It represents the system as four types of element:

• External entities. Parties outside the system boundary that interact with it — users, other systems, third-party services.
• Processes. Transformations of data — computations, business logic, API handlers, data pipelines.
• Data stores. Places where data is held — databases, file systems, caches, queues, object stores.
• Data flows. Movement of data between the other elements — API calls, message passing, file transfers, network connections.

Trust boundaries are drawn on the DFD as dashed lines, crossing the flows where the level of trust changes. Typical trust boundaries include:

• between the internet and the enterprise network;
• between the enterprise and a third-party service;
• between unprivileged and privileged components;
• between different security domains (for example, IT and OT);
• between a client and the server-side of a distributed application.

The DFD makes the system's trust relationships visible. Threats are then analysed at each element and each crossing of a trust boundary — where the greatest risk typically concentrates.

The four-question process

Most methodologies structure the exercise around four questions, applied iteratively:

05 STRIDE

The six threat categories

How STRIDE is applied

STRIDE is applied element by element on the data flow diagram. For each process, data store, data flow, and external entity, the analyst asks which of the six threat categories applies, and identifies specific threats.

Not every category applies to every element. Guidance suggests which categories are most relevant to each element type:

• External entities — primarily spoofing and repudiation.
• Processes — all six categories, because processes validate, transform, and act on data.
• Data stores — primarily tampering, information disclosure, denial of service, and repudiation.
• Data flows — primarily tampering, information disclosure, and denial of service.

Strengths and limitations

06 PASTA

The seven stages of PASTA

07 LINDDUN

The seven privacy threat categories

When to use LINDDUN

LINDDUN is used where privacy is a primary concern — systems that process personal data subject to strong regulation, systems where users have specific privacy expectations, and systems whose failure to protect privacy would have significant legal or reputational consequences. It complements STRIDE: STRIDE covers security threats, LINDDUN covers privacy threats, and the two are often applied together to systems where both are relevant.

LINDDUN's principal limitation is its focus. It addresses privacy threats specifically; security threats are addressed through complementary methodologies. Applying LINDDUN in isolation produces an incomplete picture of a system's exposure.

08 Attack trees and kill chains

STRIDE and its analogues enumerate threats by category. Attack trees and kill chains take a different approach: they model the adversary's progression toward an objective, revealing the sequence of steps that must succeed for the attack to achieve its aim.

Attack trees

An attack tree is a hierarchical model of the ways an adversary could achieve a specific objective. The root of the tree is the adversary's goal; the branches are alternative ways to achieve it; the leaves are the concrete actions or conditions the adversary must realise.

Nodes in an attack tree may be OR nodes — any of the children achieves the parent — or AND nodes — all children must succeed for the parent to be achieved. The tree can be annotated with estimates of cost, difficulty, or likelihood for each leaf, allowing the analyst to identify the most probable or least defended paths.

Attack trees have several strengths. They are intuitive — anyone can understand a tree of "ways to achieve X". They focus attention on the adversary's objective rather than on threat categories. They support analysis of control effectiveness: if a control blocks one branch of the tree, the adversary must use another. And they can be quantified — the cost of attack along each path can be estimated, supporting decisions about which paths to defend most heavily.

Their principal limitation is scope. An attack tree is rooted in a single objective; modelling all objectives for a system requires multiple trees. And trees can become large for complex systems, with the analysis effort growing quickly.

Kill chains

The cyber kill chain, developed by Lockheed Martin, models an intrusion as a sequence of phases through which an adversary progresses. The original model has seven phases:

09 MITRE ATT&CK

Structure

ATT&CK organises adversary behaviour into tactics — the adversary's goals at each stage of an intrusion — and techniques — the specific methods used to achieve each tactic. The enterprise, mobile, and industrial control system matrices cover different environments; the enterprise matrix is the most widely used.

Enterprise ATT&CK tactics include:

• Reconnaissance — gathering information to plan the attack.
• Resource development — establishing infrastructure and capabilities.
• Initial access — gaining a foothold in the environment.
• Execution — running malicious code.
• Persistence — maintaining access across restarts.
• Privilege escalation — gaining higher-level permissions.
• Defense evasion — avoiding detection.
• Credential access — stealing credentials.
• Discovery — exploring the environment.
• Lateral movement — moving through the environment.
• Collection — gathering data of interest.
• Command and control — communicating with compromised systems.
• Exfiltration — stealing data.
• Impact — manipulating, interrupting, or destroying systems and data.

Beneath each tactic, ATT&CK lists techniques and sub-techniques — the specific methods adversaries use. Each technique is documented with descriptions, real-world examples, and detection guidance.

Applications

ATT&CK supports several enterprise security activities:

• Threat modeling. ATT&CK provides a structured enumeration of adversary behaviour that can be used to model threats against a specific environment — particularly useful for identifying detection gaps.
• Detection engineering. ATT&CK techniques are the basis for detection rule development; the goal is to have detection coverage across the techniques relevant to the enterprise's threat profile.
• Threat intelligence. ATT&CK provides a common vocabulary for describing adversary behaviour, enabling intelligence to be communicated and compared across sources.
• Purple teaming. ATT&CK techniques are used to design adversary emulation exercises that test detection and response capability.
• Coverage assessment. Enterprises map their detection capability against the ATT&CK matrix, identifying techniques for which they have no detection.

Strengths and limitations

ATT&CK's principal strength is its empirical basis. It is derived from observed adversary behaviour, not from theoretical categories — which makes it directly applicable to detection and response. Its common vocabulary supports coordination across teams, organisations, and jurisdictions. And its coverage of the full intrusion lifecycle supports holistic assessment.

Its principal limitation is that it describes adversary behaviour, not system vulnerabilities. It does not, on its own, identify what could go wrong in a specific system — that requires a threat-modeling methodology oriented toward the system (STRIDE, attack trees, or PASTA). ATT&CK complements those methodologies rather than replacing them.

10 Comparing and combining methodologies

The methodologies are not alternatives. Each is suited to different purposes, and mature programmes combine them.

Combining methodologies in practice

A common approach in mature enterprises is to combine methodologies at different levels of analysis:

• STRIDE for application and component modeling. Applied by development teams as part of design review, using data flow diagrams and the six threat categories.
• PASTA for significant systems and change initiatives. Applied at the architecture level, connecting threats to business objectives and impact.
• LINDDUN where privacy matters. Applied to systems processing personal data, in addition to STRIDE.
• Attack trees for critical objectives. Applied to understand the ways an adversary could achieve a specific high-value objective — for example, exfiltrating a customer database or disrupting a critical service.
• Kill chain framing for control placement. Used to ensure that controls address multiple phases of the intrusion lifecycle, rather than concentrating on prevention at the perimeter.
• ATT&CK for detection and response. Used to design detection coverage and to align threat modeling with how real adversaries operate.

The combination is not prescriptive. Enterprises select the methodologies that fit their context, their capability, and the decisions the threat modeling must support. The essential discipline is to apply a structured method rather than relying on unstructured discussion — which tends to surface the threats the participants already know and miss the ones they do not.

11 Conducting a threat-modeling exercise

This section describes how to conduct a structured threat-modeling exercise. The method below is generic — it draws on the common structure of the methodologies examined above — and can be adapted to different contexts.

Preparation

• Define the scope. What system, application, or estate is being modelled? What is in scope and what is explicitly out of scope?
• Identify participants. Threat modeling is more effective with the right participants in the room — architects, developers, security specialists, and business owners. Participants should be able to answer questions about the system's design, data, and context.
• Gather inputs. Architecture diagrams, data flow documentation, asset inventories, and threat intelligence all inform the exercise.
• Select a methodology. Choose the methodology appropriate to the context — STRIDE for application modeling, PASTA for enterprise systems, LINDDUN for privacy-focused systems, and so on.

The exercise

1. Model the system Draw the data flow diagram. Identify components, data stores, external entities, and data flows. Mark trust boundaries. The DFD is the foundation of the exercise and should be produced collaboratively.
2. Enumerate threats Apply the selected methodology to the DFD. Work through each element and each trust boundary crossing. For STRIDE, ask each of the six questions at each point. The goal is breadth — surface as many plausible threats as possible.
3. Assess each threat For each identified threat, assess likelihood and impact in the enterprise's context. Draw on the adversary profile from Lesson 1.4 and the risk reasoning from Lesson 3.1. Not every threat will require treatment.
4. Prioritise Rank the threats by assessed risk, informed by appetite. Identify which require treatment and which are acceptable.
5. Identify countermeasures For each threat requiring treatment, identify the controls that would reduce the risk to acceptable levels. Consider controls at multiple layers of defence-in-depth. Assess residual risk.
6. Document and communicate Produce the threat model as a document — the DFD, the threat list, the assessments, the treatment decisions, and the owners. Communicate the results to the audiences that need them: technical teams, architects, executives, and auditors.
7. Review and update Revisit the threat model when the system changes, when the threat landscape changes, and on a periodic schedule. Threat models decay; without maintenance they become misleading.

Practical guidance

• Keep the exercise focused. An exercise that tries to model everything in detail produces a model that is too large to be useful. Scope the exercise to a specific system or decision.
• Involve the right people. The most useful threat models are produced by groups that include both technical and business perspectives. Technical participants know what could go wrong; business participants know what matters.
• Do not aim for completeness. Threat modeling is not exhaustive — it is structured. A model that identifies the ten most consequential threats and addresses them is more valuable than one that lists a hundred and addresses none.
• Document assumptions. Threat models rest on assumptions — about trust, about controls, about adversary behaviour. Documenting them makes them testable and revisable.
• Connect to decisions. A threat model that does not change a decision has not produced value. The exercise should be tied to design decisions, control selection, risk acceptance, or detection engineering.
• Iterate. The first pass at a DFD is rarely right. Threat modeling benefits from iteration — refining the DFD, revisiting the threats, and re-assessing as understanding improves.

12 Enterprise application and pitfalls

Threat modeling is straightforward in concept and difficult to sustain in practice. Several pitfalls recur across enterprise programmes.

Pitfall 1 — One-time exercise

Conducting threat modeling once at the start of a project and never revisiting it. Systems change; threat models must change with them.

Mitigation: Integrate threat modeling into change management. Revisit the threat model when the system changes significantly, and on a periodic schedule.

Pitfall 2 — Documentation without decisions

Producing elaborate threat model documents that no one acts on. The model becomes an artefact of compliance rather than a tool for design.

Mitigation: Tie every threat model to specific decisions — design changes, control selections, risk acceptances, detection requirements. Measure the value of the programme by the decisions it has informed.

Pitfall 3 — Mechanical application

Applying STRIDE or another framework as a checklist, without genuine adversarial thinking. The exercise produces a list of categories but not insight into what could actually go wrong.

Mitigation: Emphasise adversarial reasoning. Encourage participants to think like an attacker. Use real-world examples and threat intelligence to ground the analysis.

Pitfall 4 — Missing participants

Conducting threat modeling with only security specialists, or only developers, or only architects. Each group brings a different perspective; the absence of any one of them produces an incomplete model.

Mitigation: Assemble a group with the right perspectives — architecture, development, security, and business. Include someone who can speak to business impact and appetite.

Pitfall 5 — Analysis without prioritisation

Identifying many threats without assessing or prioritising them. The output is a list, not a decision.

Mitigation: Assess every identified threat. Prioritise based on risk and appetite. Not every threat requires treatment; the model should make clear which do.

Pitfall 6 — Disconnection from risk management

Treating threat modeling as a separate activity from the enterprise's risk management process. Threats identified by threat modeling do not feed into risk registers, and risks identified through other channels do not inform threat modeling.

Mitigation: Integrate threat modeling with the risk management process. Threats from threat modeling become inputs to risk assessment; risks identified elsewhere prompt threat modeling where relevant.

Pitfall 7 — Insufficient skill

Conducting threat modeling without the skills required to identify threats effectively. Threat modeling is a craft; it improves with practice and benefits from experienced facilitation.

Mitigation: Invest in training. Use experienced facilitators for the first exercises. Build the capability within the organisation over time.

13 Key concepts

The terms below are used throughout Module 2. Capture them in your own words as you work through the lesson.

Threat modeling

The structured process of identifying and analysing the threats that could affect a system, application, or enterprise, and the controls that could mitigate them. Produces a documented understanding of what could go wrong, how, and what should be done about it.

Trust boundary

A line in the architecture across which the level of trust changes. Controls are placed at trust boundaries because that is where trust, privilege, and data classification change.

Attack surface

The set of all points through which an adversary could attempt to access, extract data from, or disrupt the system.

Attack path

The sequence of steps an adversary would take to achieve an objective — from initial access through lateral movement and privilege escalation to the target asset.

Data flow diagram (DFD)

A graphical representation of how data moves through a system — processes, data stores, external entities, and the flows between them. The primary artifact of most threat-modeling methodologies.

STRIDE

A threat enumeration framework categorising threats into six types — Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, and Elevation of privilege. Each maps to a violated security property.

PASTA

Process for Attack Simulation and Threat Analysis — a risk-centric threat-modeling methodology with seven stages, connecting threats to business objectives, vulnerability analysis, and attack modelling.

LINDDUN

A privacy-focused threat-modeling framework with seven privacy threat categories — Linking, Identifying, Non-repudiation, Detecting, Data disclosure, Unawareness, and Non-compliance.

Attack tree

A hierarchical model of the ways an adversary could achieve a specific objective. The root is the objective; branches are alternative ways to achieve it; leaves are concrete actions or conditions.

Cyber kill chain

A model of an intrusion as a sequence of seven phases — reconnaissance, weaponisation, delivery, exploitation, installation, command and control, and actions on objectives. Used to place controls across the attack lifecycle.

MITRE ATT&CK

A curated knowledge base of adversary tactics and techniques observed in real-world attacks. Provides a common vocabulary for describing adversary behaviour, used for threat modeling, detection engineering, threat intelligence, and adversary emulation.

Tactic (ATT&CK)

The adversary's goal at a stage of an intrusion — reconnaissance, initial access, persistence, privilege escalation, lateral movement, exfiltration, and others.

Technique (ATT&CK)

A specific method an adversary uses to achieve a tactic. Documented with descriptions, real-world examples, and detection guidance.

Countermeasure

A control that reduces the likelihood or impact of a threat. The output of threat modeling's "what are we going to do about it?" question.

14 Activities

The activities below help you test your understanding and prepare for the unit discussion and Assignment 2 — which includes a threat-modeling exercise. They are not graded, but completing them will substantially improve your preparation.

15 Self-check

Answer the questions below before moving to Lesson 3.3. If you cannot answer a question confidently, revisit the corresponding section.

16 Summary

This lesson has examined threat modeling — the structured discipline through which the enterprise reasons about what could go wrong before an adversary demonstrates it. The essential points are:

• Threat modeling is the structured process of identifying and analysing threats. It answers four questions: what are we building, what can go wrong, what are we going to do about it, and did we do a good job?
• It finds threats that reactive tools do not. Scanners find known vulnerabilities; threat modeling reasons about design, logic, and trust relationships. It shifts security left, surfaces assumptions, prioritises investment, and supports communication and governance.
• The core artifacts are the data flow diagram and the trust boundaries. The DFD represents the system as external entities, processes, data stores, and data flows; trust boundaries mark where the level of trust changes.
• STRIDE categorises threats into six types — Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, and Elevation of privilege — each mapping to a violated security property.
• PASTA is a risk-centric methodology that connects threats to business objectives and impact, through seven stages from defining objectives to risk and impact analysis.
• LINDDUN is a privacy-focused methodology with seven privacy threat categories, used where privacy is a primary concern.
• Attack trees model the ways an adversary could achieve a specific objective. Kill chains model the temporal progression of an intrusion, supporting control placement across the attack lifecycle.
• MITRE ATT&CK provides a curated knowledge base of adversary tactics and techniques, used for detection engineering, threat intelligence, and coverage assessment.
• The methodologies are complementary. Mature programmes combine them — STRIDE for application modeling, PASTA for enterprise systems, LINDDUN for privacy, attack trees for critical objectives, kill chains for control placement, and ATT&CK for detection.
• Common pitfalls recur. One-time exercises; documentation without decisions; mechanical application; missing participants; analysis without prioritisation; disconnection from risk management; insufficient skill.

These ideas prepare for Lesson 3.3, which examines vulnerability assessment — the identification of the specific weaknesses that threats could exploit. Together, threat modeling and vulnerability assessment produce the picture of exposure that risk assessment evaluates and that control selection addresses.