The Basics of Threat Modeling (Part I)
This is the first post of a series on Threat Modeling. This post presents a higher level overview on what Threat Modeling is and why you need it.
The series consists of following posts:
- The basics of Threat Modeling
2. An approach to Threat Modeling
3. Threat Modeling with STRIDE Method
Note that this post outlines an overview about what Threat Modeling is and Why you need it.This is a beginner friendly series so no prior knowledge is required.
Introduction
Threat modeling is a structured approach to identifying and prioritising potential threats to a system, software, application, IOT(Internet Of Things) device and/or a network.
The goal of this activity is to identify threats and define countermeasures to prevent before it gets exploited by threat actor(s).
Threat actor is a person (or a group of people) who exploits or takes advantages of the vulnerabilities to perform malicious act(s).
You do not necessarily need to be a security expert to implement a Threat Model for your system, software, application, IOT(Internet Of Things) device and/or a network.
Threat Modeling is is a continuous activity. It starts with a clear objective to identify threats, requires continuous analysis and action to perform counter measure to prevent threat exploitation and continuously repeat this process for each new feature which get released. It is not a scanner which will automatically identify all the threats and fix them! Threat Modeling is a logical process which will be most effective if you involve all the software developers and architects who are working on the product for which you are doing Threat Modeling. The only way to maximise benefits of Threat Modeling is to start early with initial stage of development and make everyone participate in a positive manner. Your overall security posture will grow once everyone starts participating with required effort to make it work.
Why you need Threat Modeling?
Threat Modeling consists of taking a holistic view of a product’s functionality. To identify the potential threats and associated risks, architects and developers can take collective decision, prioritise the threat and address them during the development process instead of after. It will lead to cleaner architecture with well-defined trust boundaries.
Threat Modeling not only allows the team to understand the product better, but it also helps the team better understand various components that are being utilised by the application. The knowledge of why and how the components are interconnected with the product helps understand the positive and negative impacts. It helps you to understand what could possibly go wrong in your product and what you can do about it, which will increase your trust in what you’re delivering.
Thank you for reading this post! Stay tuned for the following posts of this series. If you have any feedback, feel free to contact me on Twitter: sschhatra
