Threat Modeling Interview Questions

Process for Attack Simulation and Threat Analysis

In an attack tree, the topmost node (the root) represents the attacker's ultimate objective or goal, while the branches below it represent progressively more detailed sub-goals and methods that could be used to achieve it.

In an attack tree, a node labeled with an OR gate means that ANY one of its child sub-goals is sufficient to achieve the parent goal, whereas a node labeled with an AND gate means that ALL child sub-goals must be satisfied for the parent to succeed.

Attack trees were popularized by security researcher Bruce Schneier, who described the technique as a structured way to model an adversary's goals and the various methods used to achieve them.

STRIDE's six letters stand for Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege — each one naming a security property an attacker could violate: authentication, integrity, non-repudiation, confidentiality, availability, and authorization respectively. Modelers walk a data flow diagram element by element asking which categories apply, turning threat identification into a repeatable checklist rather than an unstructured brainstorm.

False. A threat model represents one specific architecture at one specific point in time, so it should be revisited whenever the architecture changes in a way that could introduce a new attack surface — a new external integration, a new trust boundary, a new sensitive data flow, or a significant new feature — not only at a full rewrite. Treating it as permanent lets it silently drift out of sync with the real system, which gives a false sense that the attack surface has been accounted for.

PASTA stands for Process for Attack Simulation and Threat Analysis — a seven-stage, risk-centric methodology that explicitly starts from business objectives and ends by quantifying business impact, walking through technical scope, application decomposition, threat and vulnerability analysis, and attack simulation along the way. Where STRIDE is a threat-enumeration checklist applied per diagram element, PASTA is a full end-to-end process meant to connect a technical finding all the way back to a business-risk conversation that stakeholders outside security can act on.

The correct priority order is W, Y, Z, X. Their risk scores (Likelihood × Impact) are W = 25, Y = 16, Z = 12, and X = 6, so the team should remediate Finding W first, then Y, then Z, and finally X.

The seven PASTA stages in order are: (1) Define Objectives, (2) Define Technical Scope, (3) Application Decomposition, (4) Threat Analysis, (5) Vulnerability Analysis, (6) Attack Modeling, and (7) Risk & Impact Analysis. Each stage feeds the next, moving from business goals down to quantified residual risk.

An attack tree decomposes a single attacker goal, the tree's root node, into the AND/OR combinations of concrete steps that could achieve it, showing the depth of one specific attack path rather than the breadth of every possible threat across a system. It's a depth-first complement to STRIDE's breadth-first sweep across diagram elements — STRIDE surfaces the candidate goals worth worrying about, and an attack tree explores the highest-priority ones in enough detail to see where a single mitigation would break the most paths.

Good DFD practice for threat modeling is to explicitly draw trust boundaries wherever privilege changes — even inside a single service, between an unauthenticated route and logic that assumes an authenticated caller — to label each data flow with what actually moves along it rather than leaving arrows unlabeled, and to keep the diagram abstract enough that a non-implementer can still follow and contribute to it. Modeling every function call defeats that abstraction, and error/failure paths should stay in scope rather than being excluded — a retry loop or a stack-trace-leaking error message is often exactly where the most interesting threats live.

False. DREAD was developed at Microsoft alongside STRIDE, but Microsoft moved away from recommending it internally because its numeric scores proved highly subjective — two reviewers scoring the same threat routinely landed on materially different totals. Many teams now prioritize threats using CVSS or a simpler qualitative risk matrix instead.

A team should threat model during initial design, before code is written, so findings are cheapest to act on, and then again whenever the architecture changes in a way that could plausibly introduce new attack surface: a new trust boundary, a new external integration or third-party API call, a new data flow carrying sensitive data, a significant new feature, or a move to a new deployment environment. 'Once at launch' is insufficient because a threat model represents a specific architecture at a specific point in time; as the system evolves without the model being revisited, the model silently drifts out of sync with the real attack surface, which is arguably worse than having no model — it gives stakeholders false confidence that the risk picture has been accounted for when it hasn't.

A STRIDE-based threat modeling session runs in a fixed order: first build a data flow diagram of the system, then mark trust boundaries wherever trust or privilege changes, then walk each diagram element and enumerate which STRIDE categories apply, then score and prioritize the resulting threats by likelihood and impact, and finally assign and track a mitigation for each threat that clears the prioritization bar. Prioritization has to happen before mitigation, or effort gets spent on low-impact threats while the high-impact ones wait.

1. Define the Objectives (scope, business/compliance drivers). 2) Define the Technical Scope (assets, tech stack, trust boundaries). 3) Decompose the Application (data flows, entry/exit points, controls). 4) Threat Analysis (likely attacker profiles and attack vectors). 5) Vulnerability & Weakness Analysis (bugs, misconfig, design flaws). 6) Attack Modeling / Simulation (attack trees, abuse cases, exploitability). 7) Risk Analysis & Impact Assessment (residual risk, severity, mitigation priorities).

PASTA is risk-centric and attacker-simulation-driven: it quantifies and prioritizes threats by business impact and exploitability (attack trees, likelihood), whereas STRIDE is a checklist-style taxonomy that categorizes threats into six classes (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) without an inherent risk-scoring or attack-simulation workflow.

PASTA distinguishes itself from STRIDE by explicitly tying technical threat analysis back to business impact: its seven stages walk from defining business objectives and technical scope, through application decomposition and attack simulation, to a quantified business-risk impact statement, whereas STRIDE is a threat-enumeration checklist applied per diagram element with no built-in business-risk stage. Many teams use STRIDE for the technical enumeration and layer a process like PASTA around it when the organization needs that business-risk narrative.

In the standard STRIDE-per-element mapping, data stores are commonly susceptible to Tampering and Information Disclosure, processes are the only element type where all six STRIDE categories can meaningfully apply, and a Repudiation threat against a data store is typically only modeled when that store also functions as an audit or event log. External entities are the classic target of Spoofing — an attacker impersonating a legitimate user is the textbook case — and Elevation of Privilege is conventionally scoped to processes only, since only a process has privilege in the sense the category means.

Line 7 — the flow from api_gateway to internal_admin_service carries no authentication at all, justified only by 'it's on the internal network.' That's exactly the implicit-trust assumption threat modeling exists to surface: if the gateway is ever compromised, tricked into forwarding an attacker-controlled request (e.g. via SSRF), or simply has a bug, nothing on this flow stops it from reaching PII with zero additional checks

Line 2 — modeling 'obtain valid DB credentials' as an OR node that alone reaches the goal overstates that path's sufficiency: since the database only accepts connections from inside the private subnet, credentials alone don't get an attacker there. This should be combined with 'gain network access' via an AND, not offered as a standalone OR path

DREAD asks an assessor to score five dimensions — Damage, Reproducibility, Exploitability, Affected Users, Discoverability — on a numeric scale and combine them into an overall risk score. The core criticism is subjectivity: with no shared, calibrated rubric, two reviewers scoring the identical threat routinely land on meaningfully different numbers, since a judgment like 'Discoverability: 4 or 7' has no objective grounding — that inconsistency undermines using the score to make comparable, defensible prioritization calls across a threat model, especially across different reviewers or teams reviewing at different times. Many teams now prioritize using CVSS instead, which has more rigorously published and structured scoring criteria, or fall back to a simpler qualitative risk matrix (e.g. High/Medium/Low based on likelihood × impact).

True. DREAD's five dimensions — Damage Potential, Reproducibility, Exploitability, Affected Users, and Discoverability — measure inherent threat characteristics without factoring in existing compensating or mitigating controls. Two vulnerabilities with identical DREAD scores can therefore have very different residual risk if one is already partially mitigated, which is a primary reason many teams supplement or replace DREAD with frameworks like CVSS that include temporal and environmental modifiers.

Root: "Malicious code runs in production"

Level 1 (OR — any single branch suffices):

• A: Compromise a build-time dependency
• B: Compromise CI/CD pipeline execution
• C: Compromise a developer's push/merge capability

Level 2:

A (OR):

• A1: Compromise an npm package via typosquatting or maintainer account takeover
• A2: Overwrite a package in the private registry (AND: A2a = obtain registry deploy token, A2b = registry permits overwriting existing package versions)

B (OR):

• B1: Compromise a self-hosted GitHub Actions runner (AND: B1a = exploit container escape on runner, B1b = runner holds production deploy key in secrets)
• B2: Inject code via pull_request_target workflow (AND: B2a = open a PR, B2b = workflow exposes secrets in the pull-request context)

C (AND — both required):

• C1: Obtain developer GitHub credentials (OR: C1a = phishing, C1b = leaked PAT in a public repo)
• C2: Branch protection allows the compromised identity to merge (AND: C2a = identity has admin or maintain role, C2b = no required review enforcement or admin override exists)

AND/OR justification:

• The root and branches A, B, and C are OR: any single path is sufficient to get malicious code into production.
• A2 is AND: both token theft AND a lack of immutability are required for a registry overwrite — either alone is harmless.
• B1 is AND: a container escape alone is useless unless the runner also holds production secrets.
• B2 is AND: opening a PR alone does nothing unless the workflow exposes secrets in the PR context.
• C is AND: stolen credentials are insufficient if branch protection blocks the merge; both credential compromise and a protection gap are necessary.
• C1 is OR: phishing or a leaked PAT each independently yields usable developer credentials — the attacker only needs one successful vector.
• C2 is AND: the compromised identity must both have the required role AND the protection must be bypassable — either alone blocks the path.

Prioritized mitigations (justified by tree structure):

1. Pin dependency versions + enable npm provenance (Sigstore verification): This eliminates A1, a zero-depth OR leaf — the easiest single-step path with no prerequisites. Cutting the cheapest OR leaf first maximizes attacker-cost increase per defender effort.
2. Enforce OIDC short-lived tokens with strict subject claims and remove pull_request_target secret exposure: This breaks the AND at B2b, disabling the entire B2 branch by making one required child unsatisfiable. Breaking an AND chain by hardening one child is more efficient than hardening both.
3. Enforce required reviews with no admin override + replace PATs with short-lived OAuth tokens: This breaks C's AND structure by making C2b unsatisfiable and raising C1's cost. This is ranked last because C already has the highest attacker cost (two-step AND + sub-AND), so the marginal risk reduction per dollar is lower than cutting A1 or breaking B2.

The priority order follows directly from the tree: A1 is a single-step leaf with no AND gate (trivially achievable), B2 is a two-step AND breakable by hardening one child, and C is a multi-step AND with a sub-AND gate (highest attacker cost already). Fund the cheapest-attacker-path cut first.

Root: "Attacker forges a valid service certificate"

Level 1 (OR):

• A: Compromise the CA signing key
• B: Obtain a legitimate certificate issuance from the KMS
• C: Forge a signature without the key (cryptographic attack)

Level 2:

A (OR):

• A1: Side-channel attack on the HSM to extract the CA private key
• A2: Exploit HSM firmware vulnerability to dump key material
• A3: Compromise HSM admin credentials (AND: A3a = obtain HSM admin PIN, A3b = HSM configuration allows key export with admin auth)

B (OR):

• B1: Compromise a microservice identity to request a cert (AND: B1a = steal the service's mTLS client certificate, B1b = KMS does not bind cert issuance to hardware workload attestation)
• B2: Exploit KMS API authorization bug (AND: B2a = reach the KMS API endpoint, B2b = authorization logic has a confused-deputy flaw allowing cross-tenant cert requests)

C (OR):

• C1: Find ECDSA nonce reuse enabling private-key recovery
• C2: Exploit a weak hash algorithm in the certificate signature

What the attack tree reveals that STRIDE/DFD does not:

The DFD shows the KMS receiving cert requests from microservices and returning certificates. STRIDE would label this data flow as subject to Spoofing (microservice impersonation) and Elevation of Privilege (authorization bypass). However, STRIDE is enumerative per element — it lists threat categories independently and does not compose multi-step causal chains. The attack tree's AND node A3 reveals that key compromise requires BOTH an admin credential AND an export-enabling configuration — two conditions that STRIDE would flag as separate threats on two separate elements (credential theft = Information Disclosure on the admin; export config = Elevation of Privilege on the HSM) without showing that neither alone is sufficient. Similarly, AND node B1 reveals that stealing a microservice's mTLS cert is necessary but insufficient unless the KMS also lacks workload attestation — a combined precondition that STRIDE treats as two independent findings.

Scenarios where attack trees are the wrong artifact:

1. Modeling lateral movement after initial compromise: If an attacker has a foothold in one microservice, mapping all possible pivot paths requires a graph of network adjacency and trust relationships. Attack trees have a tree structure — no shared subtrees, no cycles — and cannot represent the combinatorial explosion of reachable targets where the same intermediate node is reachable via multiple paths and can itself be a stepping stone back to a previous node. A network reachability graph or attack graph (DAG) is the correct artifact.

2. Modeling supply-chain trust where a shared container base image is consumed by multiple microservices: If a vulnerability in the base image affects every service that derives from it, the correct model is a dependency graph (DAG) where a single shared node fans out to multiple consumers. Attack trees are trees — each node has exactly one parent — so they cannot represent a shared dependency that simultaneously enables multiple attack paths. A software supply-chain dependency graph (or SBOM-based DAG) is the correct artifact.

Inherent limitation of attack trees:

Attack trees model attacker capability paths but do not naturally represent defender detection and response. The tree says nothing about whether any internal node is observable by a SIEM, whether a detection rule can fire on a partial AND chain before the attacker completes the second step, or whether an automated response can interrupt the chain. Additionally, attack trees typically assume independent leaf probabilities, ignoring correlated failures — for example, if the same HSM firmware bug (A2) also weakens the side-channel resistance that A1 relies on, multiplying their independent probabilities understates the combined risk. To capture detection coverage you must augment with defense nodes (attack-defense trees) or overlay detection coverage as a separate mapping exercise.

Trust boundaries mark where data or control passes between entities at different trust levels — they are not defined by security controls or network topology, and they can exist even within a single process (e.g., between untrusted input parsing and privileged code). When data flows from a lower-trust to a higher-trust entity, the higher-trust side must validate it. Mutual TLS authenticates callers but does not eliminate trust boundaries, since authenticated services can still send malicious data.