Security Series: Threat Modeling 1 — Introduction
Security has quite a few paths and a lot of challenges. This series aims to help you find your path, learn step by step and bring transparency to the mountain of design choices. It will teach you principles, not formulas. There will be some simple, but also complex case studies to further extend your understanding.
Let us be clear on this: We can only put action on things, that are worth it. And often, we are not entitled to verify if it is or not. A third party needs to not only understand, but also agree that the topic in discussion has life-death importance. So let’s start here:
Why is Threat Modeling of key-importance?
Simply worded: In the long term it makes work easier and better.
Detailed explanation: In today’s world of innovation, change and speed any unexpected changes in the future will have an heavy impact on the costs and therefore on the success of the solution. Threat modeling leads to cleaner architectures, well-defined trust boundaries, focused security testing and better documentation. This helps to reduce the incalculable variables to a minimum.
Now this next point might appear to show why it is unnecessary, but spoiler: It actually underlines the importance even more by clarification.
Why you don’t need Threat Modeling:
It is not going to solve security problems by itself. You don’t need it for compliance (it is not an exercise that attempts to put checks in the compliance requirement).
We discussed the importance. You should be ready for the sales-pitch to your manager. Let us focus on what it is all about right away.
What is Threat Modeling about?
What you do:
Threat modeling is the process of analyzing a system and looking for weaknesses that origin in design choices.
The goal:
We desire to find issues and weaknesses before the code is being baked into the system (implementation and deployment). We try to understand characteristics in the system so that we can identify modifications to it that helps to reduce risks to an acceptable level. Understanding what could go wrong and what we can do about it increases trust in what we are delivering.
How we do it:
We look at the system as a collection of its components and their interaction to outside of it (e.g., other systems it interacts with) and actors that perform actions.
We simulate and imagine scenarios that can lead to failures, unintended behavior. Based on this, we identify threats and change our system to resist them.
Now that we understand why, how and what is hidden behind “Threat Modeling”, it is time to further expand on the process. We will continue on the next blog-post on this series. Stay safe, and continue the learning soon.
If you enjoyed the key points, you might also consider the book Threat Modeling — A Practical Guide for Development Teams by Izar Tarandach & Matthew J. Coles, which this series is based on.
Introduction 1 — Fin.
