The road to hell is paved with tl;dr. I am not a fan of the term or its implication. If we ever really manage to irrevocably screw up this planet the epitaph will be tl;dr.
But taking the world on its own terms, here is my tl;dr book review of Adam Shostack's new Threat Modeling book - its full of gems, better yet, it shows you how to create your own treasure map - get it, read it, and use it.
Its actually much more than a guide on how to Threat Model, though its a top notch resource on what works, and what doesn't in threat model. Its much more than that, when you step back from it, its how to think about security at a deeper level. That's critical, because security is liking playing chess. You are playing white and your opponent is playing black. Most people just play their side of the board, but to improve you have to anticipate your opponent's moves. Security is the same way, you can't just say "we are inside the firewall so its ok right?", you need to think about the other side of the board, whrere/how/what the attack will come at you - beyond the threat model tactics, Shostack's work brings this essential element into clear focus and rich depth for security people.
One of my favorite parts of the book is the guidance on what not to do. This is a truly useful gift to anyone just getting started. Security programs have enough trouble gaining credibility in their companies. It an uphlll slog to curry favor with developers, managers, et al and just get stuff done. The best way to ensure that you will get nothing done is to roll out guidance at the wrong level and advocate tools and techniques that don't work well in your organization. Threat models are often introduced as "think like an attacker", it sounds good, right? In practice it doesn't work all that well for ~90% of developers. Shostack hits this several times and shows better ways, one of my favorites is the pre-mortem.
I have slightly a different perspective on Shostack's view on assets. The book goes into different views that launch the threat model, the approach advocated for in the book is very software-centric. I have no quibble on that, especially if you work for a software company. But for a financial institution, a supply chain, a healthcare company, I think it works less well to assume a software first view of the world. Its simpler in those companies to get traction by looking at the assets in play - accounts, confidential data, supplier access, and so on. for one thing, you can engage a wider portion of the organization. For another you have an easier time linking the resultant threats to a business impact.
Business impact and risk is not given much coverage here, and that is no big deal, its a topic unto itself but the conversation eventually is going to get there and threat model team needs to be prepared to deliver that linkage.
Shostack covers a lot of real world challenges, one of my favorites is threat modeling APIs. The challenge is clear, not only do what not know what the attacker (black) is going to do, we don't really know what API consumer is going to do!
So now we are sitting in the park playing chess, and play three white moves up front, try to threat model what black is doing, then get up and walk away from the chess board and let someone on the park bench next to us plays white for us for three or four moves. Good luck on that threat model when you have to account for an unknown white player and unknown black player! Hope you play the perfect Hedgehog opening before you give up the pieces. Shostack enumerates the keys to developing your own version of the Hedgehog, and find specific threats to aid defensive coding for APIs:
- Perform all security checks inside the trust boundary
- When reading, ensure that all data is copied in before validation for purpose
- Know what purpose the data will be put to, and validate that it matches what the rest of yoru system expects from it
- Ensure your messages enable troubleshooting without giving away secrets
- Document what security checks you perform, and the checks you expect callers to perform for themselves
- Ensure that any cryptographic functions run in constant time
- Handle the unique security demands of your API
This is a good list of defensive considerations, the third bullet "know what purpose" is often hard in practice for many API developers, though.
The book also considers the inverse case, where you acquire software, and how to threat model that. Basically you need to reverse engineer the software model, anyone who ahs dealt with large software package integration will appreciate the difficulties (vendors who invent their own "Security" protocols!) and importance (hey my whole business is in SAP!) here.
The book is full of gems from time in the trenches "whatever bug tracking software you use should be used to track threats." How to make friends with the devil compliance. Realistic goals for rolling out threat modeling in your organization, convincing management and key contributors. There is substantial time in cockpit here and its to the reader's benefit to learn from other's scars. The list of dangerous approaches is particularly helpful:
- Cargo culting
- the kitchen sink
- Think like an attacker
- You're never done threat modeling
- This is the way to threat model
- The way I threat model is....
- Security has to be about protecting assets
I'll reiterate my quibble with the asset piece but otherwise a great list of things people frequently do that seem like a good idea at first and only later realize the issue.
The book is not just gems and gotchas. There's treasure too. The treasure is the Broad Street taxonomy, see an example here. This is the find of the whole book, it brings together Shostack's philosophy into a repeatable, analytical framework to categorize attacks consistently and quickly. If you ever wanted something similar to the checkin list of vitals at the Emergency Rom, that tells you how to route the patient and where to go next - this is it.
For the non tl;dr people out there that read this far, its a worthy effort and deserves wide reading and thorough application of the key techniques in this book. You aren't playing chess until you play both sides of the board, and you're not doing AppSec until you are threat modeling.
Comments