Introduction
I'm a software developer, and I've worked at small companies that don't have a ton of security infrastructure. These are a few things I have learned about Threat Modeling, which is often described as one of the first things you should start doing as a company to improve your security posture.
At first, I assumed Threat Modeling was something like a honey-do list for developers: a list of things that should be fixed on a system to make it secure. I also thought Threat Modeling was a complex document or diagram format that needed a certification or training to write and read properly. Neither of these assumptions were correct! A threat model can be simple, easy to read, and something that empowers devs instead of handing them a list of work to do.
What is Threat Modeling?
What could go wrong?
Threat modeling started to make sense when I stumbled across this phrase. What could go wrong? One of the main goals of threat modeling is answering this question.
“Identify the likely threats to a system to inform the design of security countermeasures.”
– Alyssa Miller
Alyssa Miller's definition is excellent, and shows us a few things. First, that a threat model is unique to your team and the system you are maintaining. Second, the threats you are identifying are the ones that are likely to happen. And third, you do this work to help you make good decisions and design good mitigations.
I like to think of threat modeling like code review: something that you do on a regular basis, that you do as a team, and where the more you practice the better you get.
Okay, how do I write a Threat Model?
A great resource for learning Threat Modeling is the Threat Modeling Manifesto. The manifesto has a skeleton framework to get started with threat modeling, which essentially asks your team to answer the following questions about your system:
- What are we building?
- What could go wrong?
- What are we going to do about it?
- How well did we do?
If your team collaboratively answers these questions, you have essentially written your first threat model! You will have some information about your system, the threats to your system, the mitigations your team is capable of implementing, and a measurement of your progress to help you continuously improve.
I don't have any support – what can I do?
If you're wanting to implement threat modeling into your team's workflow, but you don't have any support from your company, here's a few things you can do yourself.
First, you can ask for the time or budget to perform a static analysis of your production code. Static analysis will produce a report detailing the vulnerabilities that exist in a code base, and you can use this report to help your company understand the importance of doing threat modeling early in the Software Development Lifecycle (SDLC).
Second, you can do a little exercise whenever you find out about new threats, whether in your own learning journey, on Twitter, or other infosec news. The exercise could look like this – when you learn about the threat, analyze whether this threat affects your system, and then if it does, think of what mitigations you could implement. Hooray! You've just made a tiny threat model that has one threat in it. This practice, done over time, will help you think about threat modeling in a practical and actionable way.
Third, you can do a lunch-and-learn with your team. Make sure you have a whiteboard or document visible for the whole team, and at the top write "What could go wrong?". Your team will have a lively discussion about your system, how different parts interact, and things that could go sideways. In the end, you will have a great document – the start of your first threat model!
Thanks for reading, and if you have any questions, I am happy to help find the answers. You can email me at: isaac@ike.io
Download my slides:
Resources
Threat Modeling Manifesto
Alyssa Miller: User Story Threat Modeling
OWASP Top Ten
Source Code Analysis Tools: