2.1 Threat Modeling Introduction

RT-OPRP - Operations, Evidence & Reporting 2.1 Threat Modeling Introduction

Threat Modeling Introduction

How structured threat analysis shapes every decision in a red team engagement.

What Threat Modeling Means in a Red Team Context

A threat model is a structured, pre-engagement analysis that answers three core questions: who is realistically likely to attack this organization, how would they approach it, and where are the most probable points of entry or exploitation. In a red team context, this analysis is not theoretical. It directly determines which scenarios the team will simulate, which tools they will deploy, and what success looks like when the engagement concludes.

Red team operators build threat models not to catalog every possible attack but to focus effort on the attacks that matter most to this specific client. A financial institution facing state-sponsored espionage threats requires a fundamentally different engagement than a regional hospital concerned primarily with ransomware gangs. Without a threat model grounding those distinctions, a red team risks spending weeks testing for threats the client has already addressed while missing the ones that could cause catastrophic damage.

The threat model is built collaboratively with the client, using their internal knowledge of operations, sensitive assets, and organizational structure combined with the red team’s external knowledge of threat actor behavior and attack techniques. That combination produces something neither party could create alone.

THREAT MODELING – FIVE-STAGE PROCESS 01 SCOPE Define boundaries ▸ Client objectives ▸ Authorized scope ▸ Engagement type ▸ Time/resource limits ▸ Rules of engagement ▸ Legal constraints Input: Client brief

02 ASSETS Identify what to protect ▸ Crown jewel assets ▸ Secondary assets ▸ Data classifications ▸ Asset locations ▸ Asset owners ▸ Dependencies Output: Asset register

03 THREAT ACTORS Profile adversaries ▸ Nation-state ▸ Organised crime ▸ Insider threat ▸ Opportunistic attacker ▸ Capability profile ▸ Motivation / intent Output: Actor profiles

04 ATTACK PATHS Map plausible chains ▸ ATT&CK techniques ▸ Attack chain stages ▸ Detection gaps ▸ Entry points ▸ Pivot opportunities ▸ Impact scenarios Output: Attack chains

05 RISK SCORES Prioritise scenarios ▸ Likelihood score ▸ Impact score ▸ Risk = L × I ▸ Matrix placement ▸ Scenario ranking ▸ Client sign-off Output: Threat model doc

BUILT COLLABORATIVELY WITH THE CLIENT Client supplies: internal asset knowledge, org structure, sensitive data locations, known threat history Red team supplies: external threat actor behaviour, attack technique library, detection gap analysis

Threat Model vs. Risk Assessment

A risk assessment and a threat model address adjacent but distinct questions. A risk assessment asks: what could go wrong and how bad would it be? It is typically broad, covering operational, financial, regulatory, and reputational categories, and it is usually conducted without detailed knowledge of specific adversary behavior. Risk assessments produce probability-impact matrices and compliance checkboxes.

A threat model is narrower and more adversarially focused. It asks: given this organization’s specific asset profile and real-world threat landscape, which adversaries are motivated and capable enough to attack, what would their approach look like, and which defenses are most likely to fail under that specific pressure? A threat model informs attack simulation. A risk assessment informs governance decisions.

Red teams engage with both. The client’s existing risk assessments provide useful background context about what leadership is already worried about. But the threat model the red team builds is a separate, operationally oriented document that gets specific about adversary TTPs, likely access vectors, and the realistic outcomes of successful intrusion.

Building the Model Before Planning the Engagement

Threat modeling must precede engagement planning, not follow it. When operators start planning tactics before the threat model is complete, they default to their own preferences and familiar techniques rather than what the adversary profile actually calls for. This produces engagements that are technically impressive but strategically misaligned with the client’s real risk exposure.

The threat model gates scope definition, tool selection, scenario development, and success criteria. Once it is complete, every subsequent planning decision has a reference point. If a proposed technique does not serve the threat actor profile, it should not be in the engagement. If a target asset is outside the threat actor’s realistic interest, it should be deprioritized. The model keeps the engagement honest.

Common Frameworks and When Each Applies

STRIDE is a developer-facing framework originally designed for software threat modeling. It categorizes threats by type: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege. STRIDE is most useful when the engagement has a significant software or application security component and the red team needs a systematic way to enumerate threat types against a specific system or interface.

PASTA (Process for Attack Simulation and Threat Analysis) takes a risk-centric approach structured around seven stages, from defining business objectives through attack simulation and risk analysis. It is more comprehensive than STRIDE and better suited to full-organization engagements where the threat model needs to align with business context. PASTA is particularly useful when the red team needs to tie technical findings back to business impact for executive reporting.

Attack trees provide a visual, hierarchical representation of how an attacker could achieve a specific goal. The root node is the attacker’s objective, and the branches represent the possible paths to get there, each decomposed into sub-conditions. Attack trees are especially useful for modeling a single high-priority scenario in detail, identifying all the decision points where detection or prevention could block the attack.

In practice, most red team threat models combine elements of all three. STRIDE informs the enumeration of digital attack surfaces. PASTA provides the business-risk framing. Attack trees map the specific chains the red team will test. The framework is a tool, not the output. The output is a model that makes the engagement more focused, more realistic, and more useful to the client.

The Threat Model as Engagement Foundation

When the threat model is complete, it becomes the root document for everything that follows. Scenario selection references it directly: each scenario should be traceable to a specific threat actor profile and a specific attack chain identified in the model. Tool choices should reflect what that threat actor realistically uses, not what the red team finds technically interesting. Success criteria should describe what a successful attack by that actor would look like, so the team knows when they have genuinely proven a critical risk rather than just demonstrated a technical capability.

The threat model also protects the engagement legally and operationally. It documents that the team examined the client’s risk landscape before acting, that decisions were made deliberately based on client context, and that the engagement is grounded in real-world adversary behavior rather than arbitrary technique demonstration.

Key Takeaways

A threat model is adversarially specific: it identifies who would attack, how they would proceed, and where they would focus, not just what could theoretically go wrong.
Threat models precede planning: building the model after planning begins causes operators to rationalize preferred techniques rather than simulate realistic threats.
STRIDE, PASTA, and attack trees serve different purposes: STRIDE enumerates threat types, PASTA ties threats to business risk, and attack trees model specific attack paths in detail.
The model gates every downstream decision: scenario selection, tool choices, and success criteria all trace back to the threat model for justification.
Client knowledge is essential input: the threat model combines the red team’s adversary expertise with the client’s understanding of their own assets and operations.

Sources: NIST SP 800-86 – Guide to Integrating Forensic Techniques · NIST SP 800-101 – Guidelines on Mobile Device Forensics · PTES – Post Exploitation · Physical Red Team Framework (PRTF)

Complete the course to unlock the certificate