Jonathan Marcil’s Threat Modeling Toolkit talk

  • 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!

--

--

Generally blogging at adam.shostack.org/blog, but shared posts here before Medium asked me to jump through more and more hoops..

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Adam Shostack

Adam Shostack

Generally blogging at adam.shostack.org/blog, but shared posts here before Medium asked me to jump through more and more hoops..