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.
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:
One might ask why we are doing this. Our reasoning involves these important points:
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 a few resources to help get you started in threat modeling.
We've included a sample template to be cut and pasted into an issue or document, which is available here. The idea would be to open an issue and work through the template, documenting everything.
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.
Here are some helpful links.