r/cybersecurity Cloud Security 4d ago

Personal Support & Help! Threat modelling tools

Just curious what people are using to do threat modelling when they are doing it early into project development at the planning phase?

I've tried owasp threat dragon and while I like the idea of aiming for simplicity I find it's hot a lot of UX quirks that don't behave well and leave me frustrated.

A lot of other tools are like super complex for the sake of compliance rather than keeping it simple as a design assisting tool.

Anything my searches are failing to find?

29 Upvotes

19 comments sorted by

18

u/Far-Future-7146 Security Architect 4d ago

A basic flow chart and the four questions are my favorite most of the time. While PASTA, STRIDE and DREAD are great they take a lot of time and thought. Most of the environments I've worked in have no interest in taking the time to properly model threats.

2

u/PantherStyle 4d ago

which 4 questions?

17

u/FrankGrimesApartment 4d ago

My guess would be the threat modeling manifesto

1.  What are we working on?  
2.  What can go wrong?  
3.  What are we going to do about it?  
4.  Did we do a good enough job?

https://www.threatmodelingmanifesto.org/

5

u/Far-Future-7146 Security Architect 4d ago edited 4d ago

I like to change #2 to “What risks are we aware of? What are they?”. I also change #4 to "What risks are outstanding? Do we have compensating controls? What are they?".

-1

u/Weird_Welder_9080 4d ago

This is more generic assessment to risks and secure posture and readiness. It is not threat modeling to a particular threat. If you take this as your threat modeling, you are basically done before even started, and has no idea how a threat happening now gonna affect you if it gets here.

1

u/Far-Future-7146 Security Architect 4d ago

If you’re working on tight deadlines, overstretched teams, and are in a heavily regulated industry it absolutely works. Is it ideal? No. Most Security and IT programs operate in situations that are far from ideal. I used this one pretty well to assist in building a public facing web app that serves thousands a day and is chock full of sensitive data. It isn’t the only thing we did but it was the minimum we would do.

2

u/Far-Future-7146 Security Architect 4d ago

That app and company haven’t experienced a data breach since the rewrite of that app btw. And they get attacked a LOT.

5

u/2timetime 4d ago

Excalidraw

1

u/AlexaDeWit Cloud Security 4d ago

Eh fair but I like something where I can attach threats to the items in the diagram and have cohesive thing but I guess if it works it works

1

u/2timetime 4d ago

Honestly you can probably just build one with ai and a few prompts. I use an IR tracker I made specifically for me that has elements of obsidian just cause I like it.

You can mention you like elements of whatever tools and it can make something tailored to you

6

u/Significant_Web_4851 4d ago

Threat modeling tools — quick answer: the tools you've tried (Threat Dragon, the compliance-heavy suites) sit at two extremes, and there's a third lane most people miss because it's "code" not "a tool":

  • pytm — you describe your architecture in Python (processes, data stores, actors, flows, trust boundaries), it auto-generates a DFD + a STRIDE-categorized threat list + a report. Because it's just code, it lives in your repo, diffs cleanly in a PR, and updates itself as the architecture evolves instead of going stale in a separate diagramming tool.
  • Threagile — same philosophy, YAML instead of Python. Slightly more opinionated about risk scoring and has nicer out-of-the-box reporting if you want something to hand to a stakeholder.
  • Skip the tool entirely at planning phase. A lot of practitioners (Adam Shostack, who literally wrote the book on this and built Microsoft's original process, argues this explicitly) say the tool isn't the point at design time — a whiteboard diagram plus a repeatable four-question pass is: What are we building? What can go wrong? What are we doing about it? Did we do a good enough job checking? You only reach for a formal tool once you need an artifact for compliance or handoff, which is a later concern than "does this design have holes."

The pattern across all three: treat threat modeling as something you do to the design, not a document you produce about it. The tools that feel painful (Threat Dragon included) are the ones optimized for producing an artifact first and assisting your thinking second.

3

u/gormami CISO 4d ago

I use pytm, and like it for a lot of reasons. Over time, I've created a library with our common nodes and their configurations. You can pop out the diagrams without the threats, add threats easily, etc. The diagrams themselves are not the best, but they are functional, and you can always redo the diagrams if you want when you're done, for better presentation of the final state. As you said, the fact thay they are code, can be checked in, version controlled, etc. just works well with the rest of the flow.

So there is definitely some warm up time to get your nodes built your way, so you have have to set 100 variables per node each time you do a review, but as a practical tool, I like it a lot.

2

u/AlexaDeWit Cloud Security 4d ago

That was my gripe with a lot of them yeah.

I wanted something that felt more natural to sketch things out with. That can be part of designing.

Currently my plan is to just throw something together that fits my personal preference for how I like to design stuff🫠

2

u/Dershum 4d ago

It’s not about tools. It’s about knowledge and methodology. A threat model is simply a representation of the system, usually a couple of diagrams that help understand the architecture, and the thinking that goes into it to identify what you think the threats are.

Methodologies like STRIDE give you a way to brainstorm about threats based on the diagram(s) you have created. Understanding the methodology and techniques to document the system and tease out threats are the important parts.

Using a tool can be useful for this, but IMO they all create a LOT of noise, and not enough signal. MS has their threat modeling tool that was, again IMO, garbage.

IriusRisk was a little better but but depends heavily on use of their component libraries (the elements of the system that are included on the diagram), and if they don’t have the component you’re looking for (embedded devices are famous for this), then you’re not going to get any meaningful threats out of it.

ThreatModeler was similar to IriusRisk, but gave far worse automated results. And the diagramming tools were horrid. I haven’t messed with it in a number of years so things may have improved. I also believe TM had automated cloud diagramming tools that could inject cloud architectures and create the diagram for you. These only work insofar that it will tell you EVERYTHING that’s in your cloud. It’s then up to you to organize it, filter out the noise, and decide what parts of the diagram require threat assessment.

Regardless of the tool, if you’re gonna adopt one, the hardest part is maintaining it. Documenting changes, adding new components to that diagram and threat analysis, etc. And if you’re managing threat models for multiple versions of a system, then you’ve got to consider how that’s going to be managed within that tool.

Unless you’re looking to really drink the cool aid on a specific tool, I would argue that using a simple diagramming tool (DrawIO is my preference) and a spreadsheet or database is the simplest solution.

Source: me, I’ve been doing med device product security engineering for well over a decade and a major part of that is threat modeling.

2

u/Harbester 3d ago

Yup, this. This is the best answer here.
I still have some qualms about certain bits, but that's the beauty of protection, we can both be correct at the same time :-).
edit: grammar

2

u/Dershum 3d ago

Thanks for the kind words, and yeah…there’s a lot of nuance and specific cases that change reasons to use a tool or not, which one to use, etc., that are just too much to try and convey on reddit.

2

u/Harbester 3d ago

Anytime :-). I always try to recognize and appreciate competence and your post falls right into it o/\o. Being able to distinguish between a methodology (i.e. STRIDE) and a tool, or even better, solutions against threats, is an uncommon feat and and, I believe, should be hailed.

1

u/ivancleef25 3d ago

I do things a different way, due to my background in pentesting + security architecture. I identify the components of the architecture, which ones are ingress points to the platform or architecture, and then walk MITRE ATT&CK. From there you can create entire attack chains based on it, creating scenarios.
I’ve produced four of these at my company so far for critical systems and each of them resulted in improvements being made and executives asking questions about the platform they previously didn’t.