Threat Modeling

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:

  1. Define objectives

  2. Define technical scope

  3. Application decomposition

  4. Threat analysis

  5. Vulnerability and weaknesses analysis

  6. Attack modeling

  7. 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

  • http://Draw.io

  • 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:

  1. Collect and describe information

  2. Create dataflow diagram (optional)

  3. 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)