Threat Modeling Harnesses

Module S07 · Course 2A

60 min · Architecture Ingestion · STRIDE Engine · Mitigation + Issue Tracking

Prerequisite: S00–S06

Why threat modeling fails

Manual. A diagram in a quarterly meeting, a spreadsheet of threats. The diagram goes stale the day someone merges a Terraform change. Nobody re-runs the model.

Cure: generate the model from architecture as-written (IaC, OpenAPI). Regenerate on every change.

S07.1 — Architecture Ingestion

Source	Authoritative?
Terraform / CloudFormation	Yes — machine-verifiable declaration of what is deployed
OpenAPI / Swagger	Yes — API endpoints, schemas
draw.io / Mermaid	Supplementary — documentation drifts

Every input normalizes to a canonical DFD: elements, flows, trust boundaries.

Trust boundary detection

Where the level of trust changes — public internet ↔ VPC, low-trust tenant ↔ admin, third-party ↔ internal. Where the dangerous threats live.

Detected from: internet-facing resources, IAM cross-account roles, tenant isolation constructs. Each flow marked crosses_boundary → highest-priority analysis target.

S07.2 — STRIDE Analysis Engine

Spoofing · Tampering · Repudiation · Information disclosure · Denial of service · Elevation of privilege

Element type	Categories
External actor	Spoofing, Repudiation
Process / service	All six
Data store	Tampering, Repudiation, Info Disclosure, DoS
Data flow	Tampering, Info Disclosure, DoS

Scoping prevents irrelevant threats (don't spoof a database).

Grounded threat generation

Without grounding: "An attacker might spoof authentication." Useless — applies to any service.

With grounding (technologies + flows): "Attacker with stolen Cognito creds calls Lambda directly, bypassing API Gateway rate limit + WAF. CVSS AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:L."

Grounding is the load-bearing instruction.

Dedup + traceability

20 elements × ~3 categories × ~3 threats = ~180 candidates

Semantic similarity dedup → merge near-duplicates

Rank by draft CVSS score → top threats first

Every threat carries element_id + category → traceable + auto-retirirable on architecture change

S07.3 — Mitigation + Issue Tracking

A threat list without mitigations is a complaint. "Use strong authentication" is a platitude — prompts no action.

Three-layer mitigation mapping

Layer	Example
OWASP ASVS	V2.1.7 (MFA requirement)
CWE remediation	CWE-308 (single-factor auth)
Cloud best practice	AWS IAM condition keys require MFA for sts:AssumeRole

Implementation is concrete: a Lambda execution policy + condition key update in IaC. Engineer can implement it in a PR.

Issue tracker integration

Threats live where engineers work — GitHub, Linear, Jira. Not in a security silo.

Auto-create issues with: attack narrative, CVSS draft, mitigation, OWASP/CWE/cloud references, traceability back to the threat model. Bidirectional status sync (issue closes → threat mitigated).

Model versioning + diff

Architectures change. Diff two model versions — re-run STRIDE only on the delta.

Delta	Action
New elements	Run STRIDE
Removed elements	Retire threats (traceability)
New boundary-crossing flows	Highest priority

Cost scales with change, not architecture size. Continuous threat modeling becomes tractable.

What you take into S08

The threat modeling harness is operational: architecture → DFD → STRIDE → mitigations → tracked issues.

S08 moves to SDLC gate harnesses — the control plane shift from review-time checks to creation-time guardrails, multi-scanner orchestration, and vulnerability triage at scale.