What’s in your threat modeling toolbox?

Techniques & Tooling
1

1200×300 159 KB

Hey friends, this week we want to talk about tools. The SOTM Report 2024-2025 revealed something interesting: dedicated threat modeling tools are the minority - generic tools are still the norm.

@adamshostack also wrote a post recently around threat modeling tooling, in which he helps define threat modeling tools in four categories:

“General purpose tools like whiteboards or Google docs, Programmer threat modeling tools tools (eg, pytm), Individual/small team threat modeling tools (eg, MS-TMT or Threat Dragon), Enterprise threat modeling tools (eg, IriusRisk).”

We’d love to know:

What’s your tooling technique? What do you use, why, when and how?

This post is part of our new weekly ‘Peer Perspectives’ series! Each week, we’ll explore a new threat modeling topic and open it up for community discussion. For the coming weeks ahead, we’ll discuss key findings from the newly-released State of Threat Modeling Report 2024-2025.

2

For my work, I designed a method using a hierarchically-aware diagramming tool and an auto-calculating spread sheet. I created it by using what I believed were the best parts I had seen of all the aforementioned tools and some not mentioned tools. I know it works because it helps my teams know why every mitigation is necessary, if the mitigation is actually present, and if any mitigations are missing. At the end of the day, whatever solution people use must be reused, and not shelved. A threat model has the potential to change just as much as the code changes.

2 Likes
3

My threat modeling toolbox centers around an interactive whiteboard - either physical or digital like Miro or Mural - structured with the “Who-What-How” methodology that I’ve found incredibly effective for agile teams. I think my preference for this visual, collaborative approach stems from the fact that I genuinely enjoy working with people live, whether in-person around a physical board or virtually in real-time sessions - there’s an energy and creativity in group dynamics that you just can’t replicate with asynchronous tools.

I organize the board into three main columns where we identify potential attackers, their targets, and attack methods during focused 2-4 hour sessions with 3-10 participants from security, business, and technical roles. I use colored sticky notes extensively - green for user stories, red for corresponding “abuser stories,” with different colors indicating threat criticality levels.

My approach follows a “breadth-first” analysis pattern, ensuring we cover the entire attack surface before diving into specifics, which prevents getting stuck in rabbit holes during brainstorming. For existing systems, I divide the board into component sections, allowing smaller groups to analyze each part separately before consolidating findings.

I always pre-populate the board with base threat model templates for common technologies we use, like SOAP APIs, Java frameworks, REST, etc.., which saves significant time and ensures consistency. The digital version of my toolkit automatically generates Data Flow Diagrams and threat maps that export directly to our ticketing systems, making the transition from analysis to action seamless.

During sessions, I maintain strict role assignments - facilitator, moderator, and dedicated notetaker - to keep discussions productive and ensure nothing gets lost. I cap these sessions at 10% of sprint time, following Scrum guidelines, which forces us to stay focused on the most critical risks.

The session culminates in a visual risk prioritization exercise where we physically move threats into “immediate mitigation,” “for analysis,” or “acceptable risk” zones, creating instant clarity on our security roadmap that everyone can see and understand.

3 Likes
4

I don’t distinguish too much between tools and methods.

General considerations + Writing things down

  • Start and end where all the other work is done → issue tracking
  • write where the other TechDoc is written
  • draw with draw.io
  • experimented with own markup that is especially good at structured data with enforced but flexible schema, many-to-many mappings and reverse links → Threat Items Threat Modeling Template + unpublished work
  • own template with lots of guidance, training material links and TODO checkboxes
  • Threat properties: ID, short name, description (may be GIVEN WHEN THEN), affected component(s), category, risk before mitigations, considered mitigations, selected mitigations, risk after selected mitigations, status, review
  • Mitigation properties: ID, short name, description + acceptance criteria, threat reverse links, issue tracker ticket ID, status, type
  • per threat model ID spaces
  • Or lean description only :puzzle_piece: threat model part \ :cloud_with_lightning: threat \ :umbrella: mitigation hierarchies
  • A lot of :cloud_with_lightning::umbrella: emojis
  • ask AI and add what’s insightful
  • ThreatPad for education and adhoc online threat model
  • trainings, reviews and support

Methods used

Here are some of my favorites:

Working on?

Go wrong?

Do about it?

Go wrong + do about it?

  • Attack Defense Trees - especially good when there’s powerful intermediate nodes, also: a picture is worth 1000 words effect
  • GIVEN WHEN THEN - good for techtual representation of Attack Trees and threat descriptions
  • Fortunately Unfortunately (Forests) - when we want to consider more kinds of what can go wrong, like feasibility, or do a quick discussion of pros and cons

Good job?

5

Sounds like a good idea!

Appreciated your detailed post.

6

I really wanted to strip down threat modelling to the minimum I thought was necessary and that led me to create a template that I get dev teams to populate. It still requires work to populate, but I provide a lot of guidance as well and work with teams the first time they do it.

Populating the template completely and correctly is important for threat modelling to be effective, so I created my own tool called threatware to lint the populated template for errors.

Since threatware works by making the threat model machine readable I added management capabilities to it that allows me to manage the lifecycle of the threat model using gitops and store a copy of the threat model in a git repo.

1 Like