Advanced Tactics in Cyber Threat Modeling

A threat model answers four questions, articulated by Adam Shostack:

1. What are we building? (architecture, data flows, trust boundaries)
2. What can go wrong? (threats)
3. What are we going to do about it? (mitigations)
4. Did we do a good job? (validation)

Common frameworks:

• STRIDE — Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege. Per-component or per-data-flow categorization.
• PASTA — Process for Attack Simulation and Threat Analysis. Seven-stage risk-centric methodology starting from business objectives.
• LINDDUN — privacy-focused, adds Linkability, Identifiability, Non-repudiation, Detectability, Disclosure of information, Unawareness, Non-compliance.
• OCTAVE / OCTAVE Allegro — organization-centric, asset-based.
• Attack trees — Schneier-style hierarchical decomposition of attacker goals into sub-goals and methods.
• VAST — Visual, Agile, Simple Threat modeling; integrates with sprint workflows.
• TRIKE — risk-based with auto-generated threat lists.

Most pragmatic teams adopt STRIDE-per-element or STRIDE-per-interaction for the bulk of modeling, supplemented by attack trees for high-value flows.

The single most important artifact is a clear DFD with trust boundaries. Standard symbols:

• External entity (square) — users, third-party services, anything outside your control.
• Process (circle) — code you run.
• Data store (parallel lines) — databases, caches, queues, blob storage.
• Data flow (arrow) — protocols and the data they carry.
• Trust boundary (dashed line) — interfaces between zones of differing trust.

Every arrow crossing a trust boundary is a threat surface. Every data store is a target. Every process is a privilege escalator if it handles input from a less-trusted zone.

Tools to draw and analyze DFDs: Microsoft Threat Modeling Tool, OWASP Threat Dragon, IriusRisk, ThreatModeler, pytm (Python-based, code-as-threat-model), drawio + STRIDE templates.

A productive workshop:

1. Pre-work — engineer presents architecture; lead distributes DFD and component list.
2. Trust-boundary review — confirm where they are; this alone often surfaces design errors.
3. STRIDE per element — for each component, walk through S, T, R, I, D, E. Many will be N/A; the ones that aren't become candidate threats.
4. Mitigation mapping — for each threat, identify existing controls or new ones needed. Map to OWASP ASVS, NIST SP 800-53, internal standards.
5. Risk ranking — DREAD (controversial but useful), CVSS-style, or qualitative high/medium/low based on likelihood × impact.
6. Action items — concrete, owned, dated, tracked in the same ticket system as other engineering work.

Two failure modes to avoid: documenting threats nobody fixes, and exhaustively enumerating low-impact issues while missing the design-level problem (e.g., putting an HSM on a server that should never have existed in the first place).

PASTA's seven stages: Define objectives, Define technical scope, Decompose the application, Analyze threats, Vulnerability analysis, Attack modeling, Risk and impact analysis. PASTA produces deeper output than STRIDE and ties decisions back to business risk, but takes 5–10x the time. Reserve it for crown-jewel systems: payment platforms, healthcare records, election infrastructure, smart-contract treasuries.

Attack trees decompose adversary goals. Example for "exfiltrate customer PII":

Goal: Exfiltrate customer PII
├── Compromise database directly
│   ├── SQLi in any web service (AND vulnerable parameter, AND DB privilege)
│   ├── Stolen DBA credentials (OR phishing, OR cached creds, OR keylogger)
│   └── Cloud IAM misconfiguration (OR overprivileged role, OR public snapshot)
├── Compromise application servers
│   ├── RCE → memory dump
│   └── SSRF → cloud metadata → IAM token
└── Compromise backup storage
    ├── S3 misconfiguration (public bucket)
    └── Encryption key compromise (OR KMS misuse, OR HSM bypass)

Each leaf is a concrete exploit pathway. Each AND/OR node informs probability calculations. Attack trees are wonderful for communicating risk to non-technical leadership because they read narratively.

Microservices, cloud-native, serverless, and ML systems each have characteristic threats:

• Microservices — service-to-service authentication, mTLS coverage, mesh policies, secrets distribution, supply-chain of container images. Tools: SPIFFE/SPIRE, OPA, Istio.
• Serverless — function-level IAM scope, event-source poisoning (S3 bucket triggers, SQS), cold-start vs. concurrency issues, dependency vulnerabilities (long-lived Lambda layers).
• Cloud-native data — encryption at rest with proper key isolation, encryption in transit, IAM boundary conditions, KMS key policies, cross-account assumptions.
• ML systems — model poisoning, training-data leakage, prompt injection, adversarial inputs, model theft, supply-chain attacks against pre-trained models.
• Blockchain / smart contracts — economic attackers, MEV, oracle dependencies, governance capture; threat modeling here is largely economic modeling.

To scale beyond workshops, teams encode threats:

• pytm lets architects write a Python file describing components, flows, and threats; auto-generates DFDs and threat lists.
• threagile (YAML-based) integrates into CI/CD pipelines.
• STRIDE-GPT and similar LLM-assisted tools accelerate enumeration (with human review).
• OPA/Rego policies encode threat-model assumptions and fail builds on violations (e.g., no S3 bucket may be publicly readable).

Continuous threat modeling means re-running the model whenever architecture changes: new microservice, new third-party integration, new data flow.

• Capital One (2019) — a thorough threat model of the WAF setup would have flagged the SSRF + over-privileged IAM role; the breach affected 100M+ records.
• Target (2013) — third-party HVAC vendor access to the corporate network was a textbook trust-boundary violation; a vendor-access threat model would have caught it.
• Twilio Authy (2024) — public unauthenticated endpoint allowed enumeration of phone numbers; a STRIDE Information Disclosure analysis on the API would have flagged it.
• SolarWinds (2020) — supply-chain threat to a code-signing build pipeline; very few orgs at the time threat-modeled their build systems as in-scope.
• MongoDB and Elasticsearch leaks (ongoing) — default-no-auth deployments. A T (Tampering) + I (Information Disclosure) review on any DB-deployment design surfaces this in minutes.

For embedding threat modeling in engineering:

1. Make it part of the design-review process. Every RFC/ADR for a new service includes a "Security Considerations" section informed by threat modeling.
2. Train engineers, not just security team. Shostack's Threat Modeling: Designing for Security, OWASP cheatsheets, and 1-hour internal workshops scale far better than centralizing all threat modeling.
3. Maintain reusable threat libraries. Catalog known threats per technology (Kafka, S3, OAuth provider) so teams don't re-derive them.
4. Right-size effort. Hour-long lightweight sessions for low-risk features; multi-day PASTA for crown jewels.
5. Capture assumptions explicitly. "We assume the upstream API is trusted" becomes an audit trail when the upstream is later compromised.
6. Track mitigations in the same backlog as features. Security debt is invisible if it lives in a separate spreadsheet.
7. Re-model on change. Major architecture changes, third-party additions, M&A, and post-incident reviews should all trigger re-modeling.
8. Validate with red teams and pen tests. Threat models predict where the bugs are; offensive testing confirms or refutes.
9. Use LLM-assisted enumeration carefully. Helpful for breadth; humans must check applicability and avoid hallucinated mitigations.
10. Metrics that matter — % of new services with documented threat models, time-to-mitigate identified threats, threat-model-predicted findings vs. pen-test findings.