Threat Modeling.
Design-time security, done properly.
A documented, framework-aligned, six-step methodology — STRIDE plus LINDDUN with an attack-tree and MITRE ATT&CK overlay — that produces a living threat-model artefact your engineers, your auditors, and your risk committee can all consume from the same source.
Three triggers — and one of them is probably on your roadmap this quarter.
Threat modeling is not a continuous activity. It is an event-driven one — and the events are predictable. We run engagements at three trigger points where the cost of doing the work is dwarfed by the cost of skipping it.
Greenfield design
When
Before the first commit on a new service, product line, or platform component.
Why now
Threats found at the whiteboard cost a meeting room. Threats found in production cost an incident bridge. The cheapest fix is the one written into the design before code exists — and the only way to land that fix is to enumerate the threats before the design is frozen.
Major architectural change
When
Splitting a monolith, introducing a new trust boundary, switching auth provider, adopting a new data store, or wiring a new third-party integration.
Why now
Architecture changes silently move trust boundaries, expose new data flows, and invalidate prior security assumptions. A targeted re-model on the changed surface is faster than a full reassessment and catches the regressions automated scanners cannot see.
Compliance preparation
When
Pre-audit for SOC 2 (CC3.2), ISO 27001 (A.5.7, A.8.25, A.8.27), PCI DSS v4.0 (Req. 6.2.3), HIPAA Security Risk Analysis, or DPDP Act DPIA.
Why now
Most modern control frameworks now explicitly require a documented threat-modeling exercise on in-scope systems. Auditors look for a repeatable methodology, a current artefact, and evidence of remediation tracking — not a slide deck. We ship all three.
STRIDE, PASTA, LINDDUN, attack trees, ATT&CK — picked per engagement.
There is no universal best threat-modeling framework — there is the framework that fits the system, the audience, and the evidence requirement. We hold expertise across five, pick the right combination at scoping, and document the choice in the engagement plan so the client can repeat it internally.
Most production engagements run STRIDE plus LINDDUN with a MITRE ATT&CK overlay. PASTA ships when board-level business-risk alignment is required. Attack trees come out for focused, high-value-target questions.
STRIDE
Microsoft
Six-category threat taxonomy — Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege. Anchored to STRIDE-per-element on a DFD. Our default for application and infrastructure threat models.
Best for
Application threats, mapped per DFD element. Fast to teach engineers; pairs cleanly with Microsoft TMT and Threat Dragon.
PASTA
VerSprite
Process for Attack Simulation and Threat Analysis — a seven-stage, risk-centric methodology that ties business objectives to attack scenarios to technical countermeasures. Heavier lift than STRIDE, but the business-impact alignment is unmatched.
Best for
Regulated industries (finance, healthcare) where threat models must defensibly tie to business risk for board / audit consumption.
LINDDUN
KU Leuven
Privacy-focused counterpart to STRIDE — Linkability, Identifiability, Non-repudiation, Detectability, Disclosure of information, Unawareness, Non-compliance. The reference framework for GDPR / DPDP Data Protection Impact Assessments.
Best for
Systems processing personal data, especially when DPIA evidence is required. We pair LINDDUN with STRIDE on consumer products.
Attack Trees
Bruce Schneier
Hierarchical decomposition of an attacker goal into the AND / OR conditions needed to achieve it. Excellent for reasoning about high-value targets (e.g. exfiltrate customer PII) where the threats are known and the question is feasibility of each path.
Best for
Adversary-driven analysis where the goal is fixed (e.g. ransomware deployment, key compromise) and the question is which path is cheapest to defend.
MITRE ATT&CK overlay
MITRE
Not a threat-modeling framework on its own — but the canonical adversary tactic / technique catalogue we overlay on every model. Each enumerated threat is tagged with the relevant ATT&CK technique ID so detection engineering can build coverage against the same model.
Best for
Bridging the threat model into the detection-engineering and purple-team backlog. Aligns the design-time view with what the SOC will see at runtime.
Asset scope → DFD → enumerate → rank → mitigate → retest.
Each step has a defined input, a defined output, and a defined exit criterion. The output of step N is the input of step N+1 — and the entire chain ships as a single living artefact, not a PDF.
Asset & scope definition
We start with what matters and what is out of bounds. Without a hard scope and a ranked asset list, threat enumeration is infinite — and infinite enumerations get filed and forgotten.
What we do
- →Identify the crown-jewel assets — data classes, secrets, money flows, intellectual property — and rank them by business impact if compromised.
- →Enumerate actors — end users, admins, support staff, partners, third-party services, internal services — and the trust level we extend to each.
- →Document attacker profiles — opportunistic, organised criminal, insider, nation-state — and decide which classes are in-scope for this model.
- →Write the explicit out-of-scope list. Threat modeling is not a vulnerability scan; we will not enumerate every CVE in every dependency here.
Exit deliverable
Scope memo — assets, actors, attacker profiles, in-scope and out-of-scope boundaries, business-impact ranking.
Data flow diagram
One picture, one source of truth. We draw a DFD that names every external entity, process, data store, and the trust boundaries between them — at the right level of abstraction for the audience.
What we do
- →Identify external entities (users, partners, third-party APIs) and the trust boundary they sit across.
- →Map processes (services, functions, jobs) inside each trust zone and the data they touch.
- →Enumerate data stores (databases, queues, caches, blob storage) and the classification of data they hold.
- →Draw the data flows between the above — and crucially, mark the trust boundary each flow crosses. Trust boundaries are where threats live.
Exit deliverable
DFD (level-0 context diagram + level-1 decomposition) in OWASP Threat Dragon or Microsoft TMT format. Versioned in the repo, not a Visio file on a shared drive.
Threat enumeration per element
STRIDE-per-element. For every process, data store, data flow, and external entity on the DFD, we walk the six STRIDE categories and ask what could go wrong. LINDDUN runs in parallel on flows that touch personal data.
What we do
- →Apply STRIDE-per-element using the Microsoft category-to-element matrix (e.g. data stores get Tampering, Repudiation, Information disclosure, Denial of service).
- →Run LINDDUN on flows that carry PII / health / financial data — the privacy categories that STRIDE does not cover.
- →For high-value targets, build a focused attack tree to enumerate AND / OR paths that automated category-walking would miss.
- →Tag every enumerated threat with the corresponding MITRE ATT&CK technique ID where one applies.
- →Capture assumptions explicitly — every threat we accept-and-defer needs the assumption that justifies the deferral written down.
Exit deliverable
Raw threat list — one row per enumerated threat, columns for DFD element, STRIDE / LINDDUN category, ATT&CK technique, attacker profile, plain-language description.
Ranking — DREAD or risk matrix
Raw enumerations are noise. We score every threat so engineering knows what to fix first. Default is a 5×5 likelihood-impact risk matrix; DREAD ships for clients who prefer numeric scores.
What we do
- →Default scoring — 5×5 likelihood × impact matrix yielding Critical / High / Medium / Low / Info bands, aligned with the client's existing risk register.
- →DREAD on request — Damage, Reproducibility, Exploitability, Affected users, Discoverability — each 0–10, averaged. Useful when threats must be ranked numerically.
- →Recalibrate against the asset ranking from step 01 — a Medium-likelihood threat against a crown-jewel asset outranks a High-likelihood threat against a low-value one.
- →Sanity-check against external CVSS-style scores for known-CVE-driven threats so the model does not contradict the public scoring of the underlying CVE.
Exit deliverable
Ranked threat catalogue — same row schema as step 03 with added Likelihood, Impact, Risk, Justification columns.
Mitigation mapping — NIST 800-53 or CIS
For every ranked threat we map one or more mitigations — and tag each mitigation to a control catalogue the client already tracks. Threat models that recommend free-form fixes get ignored. Threat models that recommend NIST AC-3 or CIS Control 6 get implemented.
What we do
- →Default catalogue — NIST SP 800-53 Rev. 5 control IDs (AC, AU, SC, SI families) for enterprise clients with an existing 800-53 mapping.
- →Alternative catalogue — CIS Controls v8 for clients running CIS-aligned hardening programmes.
- →OWASP ASVS / Proactive Controls for application-only threat models where 800-53 is overkill.
- →For each mitigation: write the control ID, the implementation summary, the owning team, and the proposed remediation deadline.
- →Mark every threat as Mitigated, Transferred, Accepted, or Avoided. Accepted threats require named owner sign-off and a residual-risk note.
Exit deliverable
Mitigation map — threat ID linked to control IDs, implementation owner, remediation deadline, and disposition.
Retest & living-document plan
A threat model is a living artefact, not a one-off audit deliverable. We agree the cadence, the trigger events, and the retest scope before the model is signed off.
What we do
- →Schedule a calendar-driven retest — annual minimum for compliance-driven models, quarterly for high-rate-of-change products.
- →Define trigger events for an ad-hoc retest — new trust boundary, new data store, new third-party integration, new attacker profile in-scope.
- →Track remediation closure against the deadlines set in step 05; residual-risk register is updated as fixes ship.
- →Schedule a retest verification engagement — the threats marked Mitigated are validated against the implemented control, not just self-reported as done.
Exit deliverable
Living threat-model document with retest cadence, trigger events, remediation tracker, and verification plan written into the repo's CODEOWNERS / SECURITY.md.
A small SaaS — DFD, five threats, mitigations mapped.
The walkthrough below is a sanitised version of a real engagement — a multi-tenant SaaS order-management product with a browser client, a REST API, a Postgres data store, a background worker, and a third-party payment processor. The illustrative DFD and the five threats are representative of what ships out of step 03 and step 05 on a small-to-mid-sized engagement.
Sample DFD — context view
┌────────────┐ ┌─────────────────┐
│ Browser │ ── HTTPS / JWT ────────▶ │ API Gateway │
│ (End user) │ │ (Auth + Route) │
└────────────┘ └────────┬────────┘
│ │
│ ════════════════ trust boundary ════════════│════════
│ ▼
│ ┌──────────────────────────┐
│ │ Order Service │
│ │ (business logic) │
│ └────┬─────────────────┬───┘
│ │ │
│ enqueues │ │ reads / writes
│ ▼ ▼
│ ┌────────────────┐ ┌─────────────────┐
│ │ Job Queue │ │ Postgres │
│ │ (SQS / Redis) │ │ (customers, │
│ └──────┬─────────┘ │ orders) │
│ │ └─────────────────┘
│ ▼
│ ┌─────────────────┐
│ │ Worker Service │
│ │ (async jobs) │
│ └────────┬────────┘
│ │
│ ═══════════════ trust boundary ══════════════════════
│ ▼
│ ┌─────────────────────┐
└──── webhook ──── │ Payment Processor │
callback │ (Third party) │
└─────────────────────┘Sample threat enumeration — five representative rows
Category
STRIDE — Spoofing
ATT&CK
T1078 (Valid Accounts)
Likelihood × Impact
High × High
Description
An attacker reuses a credential leaked from an unrelated breach and authenticates as a legitimate tenant user. The API gateway accepts the bearer token because the credential is valid.
Mitigation
NIST IA-2(1) — MFA enforced on all tenant authentication; AC-7 — account lockout after N failed attempts; AU-12 — anomalous-login telemetry forwarded to SIEM.
Category
STRIDE — Tampering / Elevation of Privilege
ATT&CK
T1190 (Exploit Public-Facing Application)
Likelihood × Impact
Medium × High
Description
Order Service exposes a /admin/refund endpoint that checks the JWT signature but not the role claim. A standard tenant user crafts a request and refunds an arbitrary order.
Mitigation
NIST AC-3 — enforce role-based access at the endpoint; AC-6 — least-privilege review of all admin endpoints; SI-10 — server-side input validation; OWASP ASVS V4.1.1 — verify access-control checks on every protected route.
Category
LINDDUN — Disclosure of information / Identifiability
ATT&CK
T1213 (Data from Information Repositories)
Likelihood × Impact
Medium × Critical
Description
Customer PII (name, email, hashed password, billing address) is stored unencrypted at the column level. A compromised read-replica credential exposes the entire dataset.
Mitigation
NIST SC-28 — encryption at rest for PII columns (pgcrypto column-level); SC-12 — KMS-managed keys with rotation; AC-6 — read-replica credentials scoped to non-PII schemas where possible; DPDP Section 8 — purpose-limited processing documented.
Category
STRIDE — Repudiation
ATT&CK
T1565 (Data Manipulation)
Likelihood × Impact
Medium × High
Description
Payment webhook callbacks are accepted without HMAC signature verification. An attacker forges a successful-payment webhook and marks an unpaid order as paid.
Mitigation
NIST SC-23 — session-authenticity controls on webhook ingress; SI-7 — HMAC signature verification against vendor-shared secret; AU-10 — non-repudiation logging of every webhook receipt for forensic replay.
Category
STRIDE — Denial of Service
ATT&CK
T1499 (Endpoint Denial of Service)
Likelihood × Impact
Medium × Medium
Description
Background worker pulls jobs from an unbounded queue. A malicious tenant submits 10M low-cost jobs, starving paying tenants of worker capacity.
Mitigation
NIST SC-5 — per-tenant rate limiting at the API; CM-7 — least-functionality on job-submission endpoints; SI-4 — queue-depth alerting; application-level fair scheduling (round-robin across tenants instead of FIFO).
Four artefacts. One source of truth. All living documents.
The threat-model pack is built to be used after the engagement closes — by engineers prioritising a sprint, by auditors reviewing evidence, and by risk committees signing off residual exposure. Each artefact has one audience and one purpose.
Threat catalogue spreadsheet
One row per enumerated threat. Columns: ID, DFD element, STRIDE / LINDDUN category, ATT&CK technique, description, likelihood, impact, risk, mitigation control IDs, owner, deadline, disposition. Ships as XLSX and CSV.
Prioritised remediation backlog
Critical and High threats lifted out of the catalogue into a Jira / Linear-ready backlog with story templates, control mappings, and acceptance criteria. Drops straight into your sprint planning — no translation step.
Residual-risk write-up
Plain-language memo for the risk committee — what was modelled, what was found, what is being fixed, what is being accepted and why. Signed by the named threat-model owner on your side; suitable for SOC 2 / ISO 27001 / DPDP audit evidence.
DFD source files
Threat Dragon (.json) or Microsoft TMT (.tm7) source committed to your repo alongside SECURITY.md. The model is a living artefact under version control — not a PDF that goes stale the day it ships.
Four tools we run with — chosen per engagement.
The DFD source has to live somewhere the engineering team can edit it after we leave. We pick the tool at scoping based on the client's existing stack — Microsoft TMT when they are Windows-centric, Threat Dragon as the open-source default, IriusRisk for enterprise programmes with dozens of concurrent models, Threagile when the team prefers a code-first workflow.
Microsoft Threat Modeling Tool
↗Windows-only. STRIDE-per-element automation, template catalogue, .tm7 source format. Default tool when the client already has a Microsoft-centric stack.
OWASP Threat Dragon
↗Cross-platform, open source, JSON-based source format. Our default for greenfield engagements — runs in a browser, diff-friendly under git, no licence overhead.
IriusRisk
↗Commercial, enterprise-grade. Strong on automated threat generation from architecture questionnaires and on integrating with Jira / Azure DevOps for remediation tracking. Used on programmes with dozens of concurrent models.
Threagile
↗YAML-driven threat modeling — define the model as code, run threagile as a CLI, get auto-generated risk reports. Our default when the engineering team prefers a code-first workflow over a GUI tool.
Where threat modeling plugs into the rest of the programme.
VAPT
The threat model tells the pentester where to focus. Pair design-time threat modeling with implementation-time VAPT for the strongest assurance evidence.
Red Team
Attack-tree enumeration of crown-jewel goals feeds red-team objectives. The MITRE ATT&CK overlay on the threat model is the same map the red team operates against.
Compliance Audits
Threat-model evidence anchors SOC 2 CC3.2, ISO 27001 A.5.7 / A.8.25 / A.8.27, PCI DSS v4.0 Req. 6.2.3, and DPDP DPIA control responses.
OWASP Top 10 (2026) Checklist
Our STRIDE walks reference the current OWASP Top 10 categories so every web-tier threat ties back to the canonical risk taxonomy your engineers already know.
Glossary — MITRE ATT&CK
Every threat we enumerate is tagged with the relevant MITRE ATT&CK technique ID. Read the glossary entry for the framework that bridges threat modeling and detection engineering.
Threat-modeling questions, answered.
How long does a threat-modeling engagement take?+
A single-product, single-trust-boundary model takes 2–3 working days end-to-end including the scope memo, DFD, enumeration, ranking, mitigation mapping, and retest plan. A multi-service platform with several trust boundaries runs 1–2 weeks. We size each engagement off the DFD complexity, not a fixed page count.
Which framework do you recommend — STRIDE, PASTA, or LINDDUN?+
STRIDE for general application and infrastructure work — it is the fastest to teach engineers and the most tool-supported. LINDDUN as a parallel pass on any flow that carries personal data. PASTA when the client needs a defensible business-risk narrative for board or audit consumption. We rarely pick one in isolation — most real engagements run STRIDE plus LINDDUN with an ATT&CK overlay on every threat.
Is threat modeling a substitute for a penetration test?+
No, and the reverse is also true. Threat modeling enumerates what could go wrong at the design level; a penetration test enumerates what is actually broken at the implementation level. Mature programmes run both — threat modeling at design time and at major architecture changes, and pentesting on the implemented system before release and at least annually thereafter. The two artefacts feed each other: the threat model tells the pentester where to focus; the pentest tells the threat model whether the assumed mitigations actually hold.
Do auditors accept your threat-model deliverable as evidence?+
Yes. The deliverable maps every threat to NIST SP 800-53 Rev. 5 or CIS Controls v8 IDs, and the residual-risk memo is signed by the named owner on the client side. SOC 2 (CC3.2 risk-identification), ISO 27001:2022 (A.5.7 threat intelligence, A.8.25 secure development lifecycle, A.8.27 secure system architecture), PCI DSS v4.0 (Req. 6.2.3 secure-development training and process), and DPDP Act DPIA evidence are all anchored to the same artefact. We have shipped this pack into auditor evidence requests without rework.
Can the threat model be kept up to date without a full re-engagement?+
Yes — and that is the point of shipping the DFD source as a git-versioned artefact. Engineering owns the model going forward; we hand over a SECURITY.md addendum that defines the trigger events (new trust boundary, new data store, new third-party integration) at which an internal re-model is required. We typically retain a quarterly or annual touch-point to verify the model has not drifted and to update the ranked catalogue.
Ready to model the system before an attacker does?
Book a 30-minute scoping call. We'll come back with a written engagement plan, a framework recommendation, and a fixed price within one business day.