Creating a Threat Modeling Program

[tmekelburg1]

I'm currently in the process of learning about and implementing a threat modeling program for overall architecture and systems changes within our Org. At this point, I'm leaning towards using STRIDE with the four key questions:

* I'm going to tailor them a bit to fit our Org better but the concepts are the same *

1. What are you building?
2. What can go wrong?
3. What should you do about those things that can go wrong?
4. Did you do a decent job of analysis?

I'm currently reading Threat Modeling by Adam Shostack to learn more about threat modeling in general. It's a tome of a book but I'm enjoying it. I like the STRIDE method because of how simple it is to communicate and how broad the threat categories are. 

My questions are:

• Are you using a formalized threat modeling program or method? If so, which one?
• Any gotchas or things you would do differently if you could do it all over again?
• Most of the video training courses on threat modeling are centered on building applications and not necessarily around network or overall architecture changes. Is that intentional?
• Any other comments on threat modeling are welcome as well

[AppDefects]

Sure Adam's book was a "best seller" back in 2014 and now we even have a Threat Modeling Manifesto (good values and principles), but calling anything a manifesto leads to many different interpretations and debates that I choose to avoid. What has changed over time? Unfortunately, not much. It is still a "systems centric" approach that you see in all of those "training" videos and "textbooks". No one presents an "application centric" approach, lest even talk about modern software architecture or how-to model Cloud services. The techniques have not kept up with modern software architecture. They are stuck in the past with an infrastructure centric approach, which is okay if that is what you need to model.

If you are modeling modern web applications then would suggest going back and looking at the concepts, methods, and techniques that were presented at the 2020 (ISC)2 Security Congress. There was a talk on Cloud Threat Modeling that was "paradigm shifting for the discipline". Listen to it and it will change how you think about that "one size that fits all framework" approach. Again, nobody takes the application centric approach but that guy. Think about the tools and attack frameworks to test theoretical flaws and design assumptions.

Finally, stay sharp my friend and far away from any sales pitch that claims that they can create a threat model with one click of a mouse because it will cost you dearly.

[AppDefects]

Essential to creating a threat modeling program is having:

1) Policy that requires it.

2) Procedures for how-to create models and reports.

3) Clearly defined deliverables e.g., models, reports, bug IDs, product roadmaps.

4) Program metrics.

That is my threat modeling program recipe for success!

[tmekelburg1]

I get it, the book is a little old and easy to make fun of. It's perfect for what I'm trying to achieve in creating a new program with lots of detail on the procedures of how to approach identifying threats. I'm definitely going to pull from other sources as well but this is a good starting point. Thanks for the manifesto and effort in pointing me in the right direction. I can easily see this fitting into our overall enterprise risk management policy with a pointer to a more detailed policy on the Threat Program itself.

At first, I thought I would have to include a CPE question, that could easily be found in the manual, to get anyone to respond to the thread lol. 

[AppDefects]

@tmekelburg1 you are right on with thinking about including threat modeling into an overall enterprise risk management program! The output from threat modeling needs to be tracked and issues driven to closure.

Notably, I consider findings from a threat modeling exercise as "design defects" unlike CWEs. The reason I say that is I've discovered that many developers in organizations suffer from "vulnerability fatigue". Threat modeling is the exact opposite. It's a fun an interactive exercise! It breaks the monotony of just coding and fixing defects that many organizations face today.

[AppDefects]

@tmekelburg1 how about that CPE question 😉

[wimremes]

These are some alternative approaches that may be interesting to look at:

https://github.com/geoffrey-hill-tutamantic/rapid-threat-model-prototyping-docs

https://swagitda.com/blog/posts/security-decision-trees-with-graphviz/

[Fritz]

The only mistake that you will make is not just diving in. STRIDE is good as any. Just break down your environment, piece, by piece (which you need to prioritize, like Application, Web Server, OS, platform), thinking in STRIDE terms. Lather, rinse, repeat... The deeper you go the more you get into code and applying STRIDE to code. Don't get hung up on perfect. Don't stop for not knowing. Ask questions of SMEs. "Five whys..."

[RRoach]

if IT based, consider looking at OWASP and NIST as they have some good information to help.

[CJM]

Great question! I too am reading Adam's book and about to do the same thing!