You may have heard of threat modeling as a structured activity for identifying and managing threats. Threat modeling can be applied to a wide range of things, including software, applications, systems, networks, IOTs and business processes.
Threat modeling’s motto should be, “The earlier the better, but not too late and never ignore.” Without threat modeling, your security is a gamble—and in today’s business environment, you’re sure to lose.
When you design an application, you will face several security issues during different phases of the software development life cycle (SDLC), and so having threat modeling in the SDLC from the beginning can help to safeguard that applications are being developed, with security built in.
Simply put, threat modeling is a procedure to identify threats and vulnerabilities in the earliest stage of the development life cycle to identify gaps and mitigate risk, which guarantees that a secure application is being built, saving both revenue and time.
Why Threat Modeling?
- It is better to find security flaws when there is time to fix them.
- It can save time, revenue and the reputation of your company.
- To build a secure application.
- To bridge the gap between developers and security.
- It provides a document of all the identified threats and rated threats.
- It offers knowledge and awareness of the latest risks and vulnerabilities.
How To Do Threat Modeling
Many people think only security engineers can do threat modeling. That’s not true. Anyone, from developer to software project manager, can threat-model. In fact, I would suggest they should also know a little bit of threat modeling as part of their work.
Let’s look at the elements of threat modeling:
Assets: What valuable data and equipment should be secured?
Threats: What the attacker can do to the system?
Vulnerabilities: What are the flaws in the system that can allow an attacker to realize a threat?
Steps to Threat Modeling
Step 1: Identify the assets (database server, file servers, data lake stores, Active Directory, REST calls, configuration screens, Azure portal, authenticated and anonymous web user, Azure AAD client apps, database users, DB administrators)
Step 2: Outline details of architecture on which the valuable asset is being processed. It may include the software framework, version and other architectural details (ASP.net web application connection to cloud data stores and third-party services using JWT tokens).
Step 3: Break down the application regarding its process, including all the sub-processes that are running the application. We create a data flow diagram (DFD).
Step 4: List identify threats in a descriptive way to review to process further.
Step 5: Classify the threats with parallel instances so that threats can be identified in the application in a structured and repeatable manner.
Step 6: Rate the severity of the threat.
Threat Modelling Methodologies
STRIDE (Uses application-centric approach)
- Spoofing of user identity
- Information disclosure (privacy breach or data leak)
- Denial of service (DoS)
- Elevation of privilege
PASTA (risk-centric approach): Process for Attack Simulation and Threat Analysis
TRIKE (risk-based approach with unique implementation and risk-modeling process)
VAST (Visual, Agile and Simple Threat modelling)
OCTAVE (focused on assessing organizational (non-technical) risks that may result from breached information assets.)
When to use Threat Modeling
In simple words, at the early stages of the SDLC, perform threat modeling:
- Every time there is a change in the system’s architecture.
- After a security incident has occurred or new vulnerabilities are introduced.
- As soon as the architecture is ready.
It is not a mandate to perform threat modeling at the early stages of the SDLC; you can still pick up threat modeling at any stages even if it is close to deployment.
Threat models are continuously changing, and the models you prepared today may not be efficient tomorrow. And it is difficult to say that you are covered from all the threats. But if you have performed threat modeling and done whatever it takes to minimize your exposure to security risks, at least the impact of something very bad happening will be manageable (again, hopefully, but not a guarantee).
Tools to Perform Threat Modeling
I have used two tools for threat modeling, both of which are free to use.
- OWASP Threat Dragon
- Microsoft Threat Modelling Tool 2016.
Let’s take a look at both the tools:
|Microsoft Threat Modelling Tool 2016
| OWASP Threat Dragon
|Full version available for free (as of now)
|Alpha version available, flaws are still there. It is an OWASP incubator project, so it is at its early stage.
|Installable desktop application available.
|The tool comes in two variants: an online web application for GitHub and second an installable desktop application.
|Documentation easily available on Microsoft website. Default threat template is available.
|You have to search, default threat template is present
|I found the UX better, unique methodology available, the user can understand threats better. Guidance and feedback in drawing a model.
|Good UX. Fun and engaging user experience.
|Presently using this tool for threat modelling.
|Maybe I will use. I think will continue to improve.
|End-user documentation is available.
|End-user documentation is also available. Automated threats.
|Threat Grid, Template editor, Mitigating existing DFDs.
|Mitigating existing DFDs. Powerful threat mitigation. Rules have not yet been coded as it is the Alpha stage.
|Comes with a base set of threat definitions using STRIDE categories.
|Even in its current stage (alpha), you can create threats from those STRIDE categories.