01.D.07 · Threat Modeling

Choosing a Methodology

Six methods, one decision matrix. Pick by scope, regulatory pressure, stakeholder mix, and how much time you have.

The methodologies covered in this subsection are not interchangeable. Each solves a different problem. The wrong choice usually doesn't produce a wrong threat model — it produces a slow, ceremonious one that the team abandons by the second sprint.

The matrix below maps system shape and constraints to the model that fits. Below that, four quick-pick shortcuts for the cases that come up most often.

The matrix

Fit by scenario · ✓ = strong fit, ○ = workable, ✗ = wrong tool
ScenarioSTRIDEDREADPASTALINDDUNAttack TreesOCTAVEVAST
One web app, architecture review
App handling EU personal data (GDPR)
Bank transaction processing platform
Specific high-value attack chain analysis
Triage 30 findings from a pen test
Enterprise-wide risk program
200 microservices in a CI/CD pipeline
Healthcare app (HIPAA + clinical safety)
Sprint feature in two-week dev cycle

Four shortcuts

If you have 30 minutes
Use STRIDE against a back-of-napkin DFD

Two boxes, three arrows, six letters. You'll catch the obvious threats and have a reason to draw the diagram. Better than nothing by a wide margin.

If privacy law is in scope
Use LINDDUN alongside STRIDE

STRIDE catches security threats; LINDDUN catches privacy threats. They share the DFD and run independently. Both passes finish in a single workshop.

If a regulator is the audience
Use PASTA end to end

Seven stages tie business risk to technical threats to mitigations. The output reads like the document a regulator wants to receive. Worth the time.

If the scope is "the whole company"
Use OCTAVE Allegro (or VAST for many services)

OCTAVE for asset-centric organizational risk; VAST for engineering-platform threat modeling at scale. Don't try to do enterprise-scope with STRIDE — it doesn't fit.

Combine, don't compete

The cleanest real-world setups combine methodologies. A common pairing:

No methodology is the answer to every system. Match the model to the question, run two passes when needed, and don't add ceremony for its own sake.

The point

The methodology is a tool. The discipline is the conversation. Picking the model matters less than actually doing the threat modeling — a sloppy STRIDE pass that ships will catch more real threats than a perfect PASTA engagement that gets stuck in stage 1.

The four shortcuts cover 80% of real cases. The matrix covers most of the rest. When in doubt, start with STRIDE on a DFD and let the conversation tell you what additional model (LINDDUN, attack trees, PASTA) you need to bring in.

References

Formatted in APA 7. Alphabetized by first author's last name.

  1. Shevchenko, N., Chick, T. A., O'Riordan, P., Scanlon, T. P., & Woody, C. (2018). Threat modeling: A summary of available methods. Software Engineering Institute, Carnegie Mellon University. https://insights.sei.cmu.edu/library/threat-modeling-a-summary-of-available-methods/
  2. Shostack, A. (2014). Threat modeling: Designing for security. Wiley.
  3. Tarandach, I., & Coles, M. J. (2020). Threat modeling: A practical guide for development teams. O'Reilly Media.