Threat Modeling
This document is heavily inspired by GitLab’s Threat Modeling process. As described by them, “threat modeling is the process of taking established or new procedures, and then assessing it for potential risks.”
Although threat modeling is usually mentioned in the context of code changes, it can be adapted to pretty much anything. Infrastructure changes, configuration changes, code changes, and so forth.
As we like to define, threat modeling is simply brainstorming possible attack paths and threats that could affect our processes and assets. We can call it “evil brainstorming”, if you like.
There’s no one-size-fits-all approach to threat modeling—it’s a flexible process that should be tailored to the specific needs and context of each company. Some organizations might have the capacity to support more detailed models, while others may need to simplify things due to limited resources. What matters most is having a process that fits and genuinely adds value to your development workflow. If it's doing that, we are on the right track.
You can check our Rocket.Chat + FreeSWITCH Threat Model to see an example of it.
Frameworks & Methodologies
While there’s no one-size-fits-all approach, as mentioned before, there are frameworks and methodologies that were created to help security teams create threat models more efficietly.
PASTA
The Process of Attack Simulation and Threat Analysis (PASTA) is a risk-centric methodology that consists of 7 steps:
Define objectives
Define technical scope
Application decomposition
Threat analysis
Vulnerability and weaknesses analysis
Attack modeling
Risk and impact analysis
STRIDE
STRIDE is a model for identifying and categorizing security threats developed by Microsoft. It has six categories of threats:
Spoofing
Tampering
Repudiation
Information disclosure
Denial of service
Elevation of privilege
When creating a threat model, we can use STRIDE to think of possible threats in each category for the scenarios and components that we are evaluating.
Dataflow Diagrams (DFDs)
DFDs give engineers a visual way to map out the critical components in a threat model. The level of detail can vary depending on the engineer, team, or company. Some teams might go for a highly detailed diagram that captures every data input, output, and component involved. Others might lean toward a simplified DFD, focusing on ease and clarity over complexity.
As an example, the image below shows a simplified DFD created for the threat model of our VoIP solution, which integrates Rocket.Chat with FreeSWITCH.
When it comes to creating such diagrams, there are several tools available. Below is a non-exhaustive list of options:
Excalidraw
OWASP Threat Dragon
Microsoft Threat Modeling Tool
Lucidchart
Threat Modeling @ Rocket.Chat
As PASTA can be a little tricky for people new to threat modeling, and we wanted something simple to understand and reproduce, we decided to create our own simplified version. As we've already mentioned, threat modeling is a flexible and adaptable process, and there's no right way to do it. The process must be tailored to the needs of the organization.
Our process summarizes everything in the following steps:
Collect and describe information
Create dataflow diagram (optional)
Threat and risk analysis
1. Collect and Describe Information
Goal: Understand what you're protecting.
Action: Identify key assets (systems, data, components) and describe their functionality, purpose, and users.
What to Focus On:
What are the critical systems and data?
Who interacts with them?
What are the security requirements for these assets?
2. Create Dataflow Diagram (Optional)
Goal: Visualize how data moves through the system.
Action: If helpful, sketch out how different components interact and where data flows between them.
What to Focus On:
Data inputs, outputs, and storage.
How data moves between different parts of the system (network, external entities, databases).
3. Threat and Risk Analysis
Goal: Identify potential threats, assess the risks, and consider mitigations.
Action: Analyze common threats (e.g., unauthorized access, data leaks, denial of service) and how they could impact your system. For each identified threat, consider possible ways to mitigate the risk.
What to Focus On:
What could go wrong?
What’s the impact if these threats are exploited?
How likely are these threats, and how severe would the damage be?
Possible Mitigations: If a threat is high-risk, propose solutions to reduce the likelihood or impact (e.g., stronger authentication, encryption, monitoring).
Appendix I - Threat Modeling Template
The following template can be used by engineers when creating threat models.
Threat modeling is an exercise aimed at identifying potential threats to a process or asset. It does not imply that what’s being assessed is currently vulnerable to the risks discussed, but highlights areas that could become vulnerable if precautions are not taken. For more details on the methodology used in this process, visit https://rocketchat.atlassian.net/wiki/spaces/RnD/pages/127009232.
Project/Feature Name: VoIP Example
Date: September 17, 2024
Security Engineer(s): John Doe
1. Collect and Describe Information
Overview of the System/Feature
Briefly describe the system or feature you are modeling. Include its purpose, how it integrates with other systems, and any relevant background information. You may want to include:
Key components (services, applications, databases, etc.)
Sensitive data types being handled (e.g., PII, financial data, etc.)
User roles and interactions
Key security requirements
2. Create Dataflow Diagram
Diagram
Attach or link to a dataflow diagram showing how data moves between components and systems, highlighting key data stores, external entities, and trusted/untrusted boundaries.
Summary of Dataflow
If no diagram or if you want to add more context, describe how data flows through the system, noting important communication channels, inputs, outputs, and where sensitive data is transmitted or stored.
3. Threat and Risk Analysis
For each key asset, component, or data flow, document potential threats, their likelihood, impact, and possible mitigations.
Threat 1 - Title
Description: Add description
Likelihood: High/Medium/Low
Impact: High/Medium/Low
Risk: High/Medium/Low
Mitigation: Add mitigation strategies
Threat 2 - Title
Description: Add description
Likelihood: High/Medium/Low
Impact: High/Medium/Low
Risk: High/Medium/Low
Mitigation: Add mitigation strategies
(Repeat as many times as you need)