Jonathan Marcil’s Threat Modeling Toolkit talk
[no description provided]There's a lot of threat modeling content here at AppSec Cali, and sadly, I'm only here today. Jonathan Marcil has been a guest here on Adam & friends, and today is talking about his toolkit: data flow diagrams and attack trees.
His world is very time constrained, and it's standing room only.
- Threat modeling is an appsec activity, understand attackers and systems
- For security practitioners and software engineers. A tool to help clarify what the system is for reviewers. Highlight ameliorations or requirements.
- Help catch important things despite chaos.
- Must be collaborative: communication is a key
- Being wrong is great: people get engaged to correct you!
- Data flow diagrams vs connection flow diagrams: visual overload. This is not an architectural doc, but an aid to security discussion. He suggests extending the system modeling approach to fit your needs, which is great, and is why I put my definition of a DFD3 on github; let's treat our tools as artifacts like developers do.
- An extended example of modeling Electrum.
- The system model helps organize your own thoughts. Build a visual model of the things that matter to you, leave out the bits that don't matter.
- Found a real JSONRPC vuln in the wallet because of investigations driven by system model.
- His models also have a "controls checklist;" "these are the controls I think we have." Controls tied by numbers to parts of diagram. Green checklists are a great motivator.
- Discussion of one line vs two; would another threat modeling expert be able to read this diagram? What would be a better approach for a SAML-based system? Do you need trust boundaries between the browser and the IDP? What's going through your head as you build this?
- Use attack trees to organize threat intelligence: roots are goals, leafs are routes to goals. If the goal is to steal cryptocurrency, one route is to gain wallet access, via stealing the physical wallet or software access. (Sorry, I'm bad at taking photos as I blog.) He shows the attack tree growing in a nice succession of slides.
- Attack trees are useful because they're re-usable.
- Uses PlantUML to draw trees with code, has a bunch of advantages of version control, automatically balancing trees.
- Questions: How to collaborate with and around threat models? How to roll out to a group of developers? How to sell them on doing something beyond a napkin.
- Diagrams for architects versus diagrams for developers.
- If we had an uber-tree, it wouldn't be useful because you need to scope it and cut it. (Adam adds: perhaps scoping and cutting are easier than creating, if the tree isn't overwhelming?)
- Link attack tree to flow diagram; add the same numbered controls to the attack tree.
- If you can be in a meeting and say nothing in the TM meeting, you've won!
Lastly, Jonathan did a great job of live-tweeting his own talk.