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 *
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:
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.
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!
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.
@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.
These are some alternative approaches that may be interesting to look at: