Deets

• Threat Modeling by Adam Shostack
  • ISBN-13: 978-1118809990
• Threat Modeling by Izar Tarandach & Matthew J. Coles
  • ISBN-13: 978-1492056553
• Adversary Emulation with MITRE ATT&CK by Drinor Selmanaj
  • ISBN-13: 978-1098143763

Review

Threat modeling, as a discipline, feels lacking. It claims to be something that anyone can learn to do, but leans heavily on domain specific knowledge that not everyone has. It claims to be open, but in practice requires a priestly caste of Security Professionals to analyze results. It relies heavily on hand annotated diagrams that leave easy opportunities for loss. Most distressingly it reinforces that security stands alone as a field rather than being integrated into software development.

I don’t believe that this is the result of any conscious decisions on the behalf of creators and practitioners of Threat Modeling. But there is a great opportunity for things to be better. I believe that there is a great deal of promise in architecture diagrams that also show data flows. I believe that straightforward rules can allow for programmatically analyzing for issues. Composability would allow for scaling these up. How to realize that is something I need to examine more, I was unable to find anything that fully realized this. However something like this would allow any engineer to diagram their work in ways useful beyond security, while also helping to ensure that the security properties threat modeling provides are upheld.

I arrived at this conclusion after reading several books on Threat Modeling:

• Threat Modeling by Adam Shostack
• Threat Modeling by Izar Tarandach & Matthew J. Coles
• Adversary Emulation with MITRE ATT&CK by Drinor Selmanaj

I attempted to have Gemini arrange the books since I only have the e-books. Amusingly enough it really struggled with this. If you compare the right two books and the actual covers you can spot some issues.

Threat Modeling (Shostack)

The “og” book on threat modeling. This book, to its credit, does a good job of describing the principles of Threat Modeling. My own research on blog posts and other free resources was not nearly as enlightening as reading this book.

That said, my biggest struggle with the book is the approach it takes to threat modeling. It’s ad-hoc, it requires careful thought to look at everything and find issues. It focuses on hand drawn charts and thinking through designs collaboratively, but these don’t make for repeatable nor reliable work.

As a survey of threat modeling and how security orgs approach it, this book is a good introduction to understanding how a security org operates. You will know STRIDE by the end, you’ll know a few other techniques. You’ll understand standard approaches to handling threats. To help get to a common baseline it is very helpful. The focus on hand drawn charts and simple whiteboarding is good for an ideation stage, but it doesn’t set up practitioners for repeatability nor detailed analysis.

Adversary Emulation (Selmanaj)

Adversary Emulation (AE) is very different from the other two books. While the prior two focus on how to model threats, Adversary Emulation focuses on trying to simulate on what an attacker would actually do. Rather than review architecture for defensive purposes, this focuses on trying to act as an attacker, generally on actual systems. This lets one perform more sophisticated tests of theoretical architecture.

This sort of behavior is often called “Red Team’ing” and the book has a fun etymology aside on the history of the term:

In everyday language, playing devil’s advocate describes a situation where someone, given a particular point of view, takes an alternative position from the accepted norm to explore the thought further using valid reasoning. Military and intelligence leaders started using a similar concept to appoint people to a group they called the red team, to realistically evaluate the strength and quality of various strategies

What I enjoyed the most about this book is that it acts as an introduction to the sort of terms and thinking a modern cybersec team might use. In addition to discussing how adversaries behave there is a lot of terminology that is discussed in formal terms that I had not seen laid out so well before.

So many of the terms used are consciously chosen for their connection to military terms, including the phrases “Advanced Persistent Threat” to refer to adversaries and even the “Kill Chain” walk-through for modeling how an attacker behaves. At times it feels like a LARP, especially when one digs into the low quality code adversaries may use or the amazing ability of base64 encodings to smuggle malicious programs by scanners. By the time I got to the author referring to hacks as attacks and “With Article 5 of the NATO treaty stating that an attack on one member is an attack on all, the potential consequences of such an attack cannot be overstated.” I giggled a bit. To be fair, recently I found myself putting together a “war room” for a discussion and sighed at myself before calling it a “discussion hall.”

In terms of discovering threats, (AE) is legitimately useful for helping to decide what is a threat. There are a lot of potential problems out there, with lots of levels of risk for each issue. As John Lambert once said the “biggest problem with network defense is that defenders think in lists. Attackers think in graphs.” Even within the lists, sorting problems by what seems likely is not easy. AE lets you pick likely attackers, and look at the graph like they would. From there, you can get a lot of hands on data about where the weak points are. This is great for both simulating likely attacks as well as understanding how a single malicious path for an attacker can bring down an org. Because AE focuses so much on actually conducting the attacks, it is still very expensive to test.

Threat Modeling (Tarandach & Coles)

A more recent take on the art of Threat Modeling and a more practical one in my opinion. This book focuses on more data driven and empirical approaches than Shostack’s, which I found made it a better read.

This book is intended to be a standalone book, so it does cover much of the same material as Shostack, but it has a more systematic approach. Concepts like Data Flow Diagrams take a firmer stance on the shapes to use and provide more useful details on how to analyze connections between components. This in turn allows for more rigor and repeatability across projects.

The more modern age of the book also allows for more modern threat modeling techniques which are interesting to learn about. LINDDUN for privacy is covered in a way there it feels possible to apply. Risk analysis via FAIR and SPARTA is covered as well for more modern approaches.

The final part that is covered, which is one of my favorites, is how to automate threat modeling. Various tools for being able to display and analyze threats are covered, which I feel is really where this needs to go. Without a standardized language it’s hard to save and review work over time and across projects. With a standard way to interpret models, analysis can be possible to automate for managing key storage, identifying gaps, and emulating attackers. The book has a bias towards their in house tool “pytm”, but various others are discussed in detail as well. My personal take after reviewing it is that pytm doesn’t go far enough to simulate full architectures, but as far as tools go it is useful.

Where to go from here?

I started by expressing my displeasure with the state of threat modeling, so how I can finish this with where I believe it should go? Threat modeling needs to be something verifiable, something savable and loadable over time. It needs to exist within the broader engineering effort, not parallel to it. It needs to be extensible so a component can be modeled, and then put inside a larger system to review. What’s I believe this comes back to is threat modeling needs to be a part of architecture diagrams. Not simple whiteboard drawings either, textual descriptions that get rendered and can be explored as graphs of key locations, data flows, health checks, and everything else possible. These are by necessity heavyweight items, annoying to fill out, but they front load the necessary work to identify gaps and can both be fit into a larger system and have their validation logic extended as well. Pytm, from the final book, gets to the starting line but doesn’t attempt to be a full architecture diagram. Honestly I’m wary of the interpretable python part as well but that’s a whole other issue. Where something like this exists, I’m not sure.