I’m reading “Brain of the Firm” and working on a threat modeling methodology, actually. I worked on one that’s been used a bit internally at work. It allowed us to threat model before design. That provided a framework to guide design and support implementation, rather than just checking those things when they were done.

It has some similarities to Trike (at least as I understand it). That probably shouldn’t be surprising since I worked for Mike Eddington for a while in the 2010’s. It starts with something very similar to the trike requirements model, but isn’t restricted to CRUD. It also added an additional “constraint” field which was free text. It was really powerful, but could be hard to use. One folks learned it, they were able to get great results. The best thing is that TPMs and product owners, not security folks, owned the first step. By including them in the process, the whole product team started to think in a more adversarial way. But it was always missing some stuff. The hardest thing is figuring out what level of abstraction to model. It also never had a good threat library.

Since digging into the Beer’s Viable System Model, I think I’ve figured out a lot of additional things. There are still some gaps. All of this was happening before LLMs, and a lot of the manual work was mutating triplets. The whole thing was designed with formal language in mind (some folks suggested ACE). With LLMs the text manipulation is pretty easy, and formal language may not be necessary. Integrating VSM can clarify what level to model, while still providing recursion to model at a deeper level.

I’m also thinking about integrating the OODA loop. The whole idea of threat model then test has always been a problem for me. There’s a natural interplay between your observations, how they fit in to what you know (orientation), which things you then prioritize to test (decide), and how you formulate your action into a hypothesis.