Threat modeling is the process of taking established or new procedures, and then assessing it for potential risks. For most tech companies, this usually involves code and coding changes. However this process can be adapted to any situation where there is a potential risk, and is something that many of us do every day. Choosing the longer well-lit walk to your car as opposed to the short cut through the darkened alley. Looking both ways before crossing the street. This is something we often do by instinct.
Within the context of GitLab, there are different risks we evaluate. Will my code change introduce a security vulnerability into the product? Will a radical new company policy being introduced create outside criticism and damage GitLab's reputation? When was the last time we evaluated this existing code library for vulnerabilities? What are the potential pitfalls our new sales campaign might face when moving into new markets? These are risks we deal with all of the time, just like every other company.
Here are a few resources to help get you started in threat modeling:
We've developed an issue template available here (private link) that you can use to create an issue documenting your threat model. There's also a beginner-friendly how-to guide to threat modeling which you should read if you're new to threat modeling.
Here is a real sample of an evaluation of the install of a GitLab standalone instance in a hostile environment.
More samples will be added later.
The most common use of threat modeling within a tech company like GitLab is our code base. The Security Team has developed a threat modeling "framework" for Engineering with the following in mind:
The purpose of the GitLab Threat Modeling Process is to provide a starting point for future AppSec Code Reviews. Threat models are based on the conceptual architecture of the application and only utilize code to substantiate findings when possible.
One might ask why we are doing this. Our reasoning involves these important points:
The overall goal is not to create a rigid structure that must be strictly followed, but an adaptive tool that proactively helps uncover security risks before they occur and even chart out solutions based upon the likelihood of the risk.
After evaluation of several popular frameworks, we elected to use the PASTA framework as a base, and with a few minor tweaks for GitLab's environment, we've completed the framework. An overview from the author of the original book can be found here.
We still welcome changes to the framework and deem it to be as much of a living document as the rest of the handbook.
Our base framework is PASTA. PASTA is an acronym that stands for Process for Attack Simulation and Threat Analysis. It is a 7-step risk-based threat modeling framework.
There are several other threat modeling frameworks, however others were deemed either too focused on coding or too focused on attacks. PASTA has a much broader range and can easily scale up or scale down as needed, and most other threat modeling frameworks can map into it.
Other threat modeling frameworks examined:
PASTA has a number of advantages for GitLab over other frameworks:
PASTA has the advantage in that it can be adopted from code-based scenarios to infrastructure scenarios easily. It can be adapted to cover non-traditional threats, such as bad PR due to an executive’s social media posting or the company’s selling of the GitLab product to a controversial organization. It can even be used to map in incident response scenarios, as it allows for threat reinforcement from threat intel sources including logs, intel services, and even previous incidents.
There are seven stages to PASTA, here are our definitions. Note that while many of the examples are code-centric, these can be evolved over time to cover non-coding scenarios, such as third-party SaaS application approval, sales strategies and plan into new territories, and so on.
This helps set the tone for the project or assessment. It considers the following:
This does not have to be "tech" per se, but should include project boundaries.
This allows mapping of what is important to what is in scope.
This is where we mainly look to document relevant threats and threat patterns to the data we have gathered up until now.
This is were we examine the threats, ranking them and assessing their likelihood.
We go through the threats and turn them into attacks, by examining the attack surface before and after our proposed changes.
This covers the development of the rationale for mitigation based upon residual risk.
To help with implementing and using the PASTA framework, we can use a three-tiered approach. This approach is as follows:
GitLab’s best practices applied to components of the project.
Applies Stage I & Stage II of PASTA
Proof of a threat via numerous indicators as opposed to just theory or conjecture.
Applies Stage III, IV, V of PASTA
Applies all stages of PASTA
Here are some helpful links.