A few weeks ago I attended a medical device threat modeling bootcamp put on by MDIC / MITRE / FDA / Shostack & Associates. Shostack & Associates is lead by Adam Shostack, who literally wrote the book on threat modeling. I learned a lot from his various papers, blog posts, videos, and the small part of the book I managed to read while I was setting up a Product Security Risk Process for my employer, so I was pretty excited to get to do some of his training.
Originally this was supposed to be a 2-day in person training session, but due to the pandemic it was shifted to a week long course. Each day consisted of a 2 hour Zoom call, where most of the time was spent in a small group discussing the exercises, and about 2-3 hours of videos to watch and exercises to do. Adam repeatedly emphasized the need to do the homework, and indeed it helped a lot with retention to write about STRIDE and Kill Chain, and to apply them both to the problem we started with and a problem of my own. Here one of the drawbacks of remote learning became clear. Although I blocked off time in my calendar for the homework, I still chose to help with production issues that came up, and it seems that lots of others had work and life intruding on that time as well. It’s harder to block all that out when you are at home than when you are trapped in a conference centre.
Although this bootcamp was about threat modelling for medical devices, the example that we threat modelled first was a toy problem that Adam probably uses a lot: Bikes as a Service. The idea behind this system is that the is an app users can download and use to locate a bike. They can find and unlock a bike, ride it to where they need to go, and then release the bike and get billed for the time or distance. There is lots of interesting stuff to threat model in this system, including cloud and app software, external systems like a payment processor, and hardware to keep the bikes secure. Like some medical devices, the combination of hardware and software makes for a lot of different areas to look at while threat modelling, including the interaction with safety risk, for example if the bike has a brake or something that could be remotely activated while being ridden.
From the sounds of it some folks didn’t like this example system because they felt it was too far away from medical devices they were used to, but the goal was to introduce a new system for everyone to work on so that everyone was sort of starting from scratch, so that they could focus on learning the threat modelling process, not on the system being threat modelled. It turns out that the last exercise we would do in the bootcamp was student’s choice, so people did get a chance to threat model their own devices as well.
I learned a lot from the bootcamp. I had come across maybe half of the material before when I was setting up our product security process, but it was really nice to see that we are on the right track. I’ll take away some improvements we can make to our process, but also new ideas for how I teach threat modelling internally.
The group I was in included people with all sorts of different perspectives: regulators, manufacturers, healthcare delivery organizations. It was great to get different perspectives on security and we had some interesting discussions.
When I set up our product security process, it was based on AAMI TIR57, NIST 800-30r1. These don’t really cover how to find threats. They ask for lists of assets, vulnerabilities, threat actors, and threat events and give some examples, but don’t cover how to determine those for your own systems. The threat modelling process is the gap and the playbook will really help improve this. Those lists, particularly of threat actors, events, vulnerabilities, and impacts, are outputs of the threat modelling process, but those standards almost make the sound like they are a priori inputs. In reality I find that we threat model, we tell stories about what might happen, and we can then tease apart those stories to find the pieces. I hope that the threat modelling playbook that is related to this bootcamp will help fill this gap and make it clearer how the whole process should fit together.
Since then I’ve started doing some internal mini-bootcamps on threat modelling. I definitely recommend trying it out! It’s a great way to help build more secure systems.