Over the last couple of years, security has become a major topic for every DevOps team. Cloud-first initiatives of various companies help to push the DevSecOps movement forward. The transition to a microservices architecture puts your system even more at risk since the attack surface increases exponentially. Valuable data which is of strategic interest becomes much more attractive to attackers. Security is not an afterthought anymore but should be included early in the Software Development Life Cycle. But how? Threat Modeling enhances system security, but how do DevOps teams get started? In this article, I will highlight what threat modeling is and how to start to practice it.
What is threat modeling?
Data and systems need to be protected in every phase of their existence. DevOps teams and their stakeholders need a common understanding of potential threats and how to mitigate them. Threat modeling helps to identify, understand, communicate, and mitigate security risks.
Valuable assets within the context of a software development company include infrastructure components & resources, software applications, databases, IoT devices, business processes, source code, and more.
In order to protect these assets, a threat model helps you to articulate actions:
- Identify what you are worried about: describe or design it to make it practical.
- List the assumptions of (potential) threats about the thing you want to protect.
- Define actions for each threat to mitigate it.
- Validate the model and threats to capture verification of the actions
As with “shift security left”, it’s best to start with threat modeling early in the software development release cycle. It requires an upfront investment but given the risk of an exploit, most of the time it’s worth it.
Why it is important
Common justifications to spend time and effort on threat modeling is to gain a shared understanding by different teams on what to protect (and what not) and how to make this a reality.
From a cloud-native perspective, it’s most important to build a secure system that can safely operate in a zero-trust environment. Business features and the corresponding data should be protected against incidents, malicious actors such as hackers, and other failures. This is especially true in the world of “Internet of Things” in which humans interact with tech systems and the other way around. Business features should be protected to identify security weaknesses and compliance violations.
Key arguments
In order to do that, threat modeling helps to prioritize security-related aspects, development activities, planning of human resources, and other related tasks. It narrows the gap between Dev and Ops in which security plays an intermediate role. Together with the security specialists, those teams also determine when building control is unneeded if the risk is acceptable. In the end, the owner of the business feature accepts the risk since the business department is ultimately responsible for it.
Besides this threat modeling helps to define security test cases & scenarios to validate security requirements and controls. And last but not least: document threats and share mitigation techniques across other teams.
When you embed threat modeling in the SDLC, security becomes an integral part of the daily activities of the developer teams.
Know the actors
Before we dive into the different methods which are available, it’s good to understand the actors which you need to know where to start your threat modeling activities and with which motivation. By identifying common actors you can (hopefully) pinpoint your time and effort towards the threats that make the most sense.
Try to answer the following questions to gain a better understanding:
- Who is the person, group, or entity which might attack you?
- Capture probably reasons why do they might want to attack you.
- What do they want to achieve, both in the short term and long term?
- Identify how skilled these people are and which tools they use to attack you.
- Where are these people located and which role does this location play in their intentions?
Take a look at the last example. If you know for sure that most attacks might come from a specific country, you can take extra measures to make sure traffic which originates (if not spoofed) from that country. You can filter this traffic and log more details so you already have a lot more evidence in case a real attack happens from that country.
Targets
It’s good to understand which assets of your organization are particularly attractive to attackers to focus your threat modeling activities on:
- Data: by far the most important one. If you use your valuable data for strategic purposes, a competitor might want to steal or destroy it.
- Resources: for example, this can be compute or storage resources which an attacker might want to use for their activities.
- Services: perhaps your service is exceptionally good and a hacker wants to damage your reputation so you will lose highly paying customers.
- Ecosystem: once a hacker gains access to your ecosystem he/she can use it to attack other linked services or connected organizations which are his intended target.
It really helps to think like an attacker and use the previous topics to start your threat modeling activities.
Threat modeling methods
As of today, a number of threat modeling methods help you to carry out the above-mentioned activities. It’s impossible to describe all methods so let’s focus on the main ones. Organizations should pick the tool which best fits their needs.
STRIDE & DREAD
Stride is one of the oldest threat modeling methods. It’s already two decades old. Microsoft adopted it in 2002. The acronym which depicts common threats stands for Spoofing identity (violating authentication mechanisms), Tampering with data (violating integrity), Repudiation (and the counterpart called non-repudiation), Information disclosure (confidentiality), Denial of service (make a service unavailable) and Elevation of privileges (violate authorization levels).
Thread modeling tool
To make Stride practical Microsoft offers an online tool. This tool focuses on five sequential aspects which are repeated for every potential threat:
- Define security requirements
- Create an application diagram
- Identify the threats
- Describe how to mitigate or them
- Validate the mitigated ones
One of the benefits of this tool is to use a standardized notation to visualize system components, data flows, and security boundaries. This is especially useful in the public cloud where there is no clear security perimeter and where this is different for every application. A microservices-oriented architecture makes this even more difficult since there are so many services and connections involved.
Standard notations help to streamline the communication between members of different teams. In addition to that, there are several plugins to integrate the threat modeling tool into various issue tracking systems like Jira. With this in mind, it’s easy to add a threat modeling task to every user story of the current sprint.
Last but not least: Microsoft now also offers DREAD which stands for Damage potential, Reproducibility, Exploitability, Affected users, Discoverability. It’s a bit similar to STRIDE but the categories in DREAD do not share correlations. This makes DREAD a bit more flexible compared to STRIDE. No fuzzing over “in which category should this threat fit”. DREAD is very useful to view potential threats in isolation and assign a risk score to it. Those risk scores help security teams to put their focus on the right topics.
CVSS
NIST designed the Common Vulnerability Scoring System (CVSS) methodology. It focuses on the specific characteristics of a (known) vulnerability. Three metric groups are important:
- Base (e.g. impact metrics, attack vector, integrity impact, etc)
- Temporal (e.g. exploit code maturity, remediation level)
- Environmental (e.g. confidentiality & integrity & availability requirement)
The CVSS gives the person who performs the threat modeler a standardized risk score system and users can calculate the CVSS risk score using an online calculator. At present CVSS is maintained by the Forum of Incident and Security Teams (FIRST) and the CVSS Special Interest Group helps to support and contribute to it. Security tools like Sysdig include CVSS in their GUI and vulnerability reports.
PASTA
In one of my previous articles, I highlighted the need for a proper risk management strategy in the world of DevOps. PASTA takes a risk-centered approach. It stands for Process of Attack Simulation and Threat Analysis.
Every stage (from 1 to 7) within the framework contains a list of activities which sometimes overlap. It starts with the business objectives and works its way through the (potential) business impact. Using this system you can bridge the business and IT gap. This is a very strong point since often teams only focus on the technical aspects rather than what it really means for the business. Negative business value in case of an exploit is also very useful information!
Stages
The 7 stages are:
- Define main objectives that focus on the business objectives and security requirements which include the business impact analysis.
- Define the technical scope which captures the boundaries of the environment and which also identifies the application dependencies and infrastructure related aspects.
- Application decomposition into user stories, assets, roles, data sources, trust boundaries, etc.
- Threat analysis collects potential attack scenarios and the analysis of security events.
- Vulnerability & weakness analysis track existing vulnerability reports & design flaw analysis by utilizing Use Cases and Abuse Cases. Last but not least: it uses CVSS to standardize the risk scores.
- Attack modeling which zooms in into the attack surface of systems and applications. Attack trees are used to refine and detail the components.
- Risk & impact analysis determines the impact on the business from a quantitative and qualitative aspect. It also includes risk mitigation strategies and governs any residual risks in case you cannot or decide not to mitigate them.
Other methods
There are some more methods which might be interesting for your organization:
- Trike – originally created as a security and auditing framework.
- Person Non-Grata – which has a dedicated focus on the human factor of attacks. This also links to phishing.
- Hybrid Threat Modeling Method (HTMM) – which combines security cards, Person Non-Grata, and the Secure Quality Requirements Engineering Method.
- Security cards – to identify complex and unusual attacks. Potentially a high number of duplicate risk findings.
- Another risk-based strategy is offered by OCTAVE which stands for Operationally Critical Threat, Asset, and Vulnerability Evaluation. It focuses on three phases: threat profiles, infrastructure vulnerabilities, and the security strategy.
- VAST modeling – large organizations benefit from it since it mainly consists of an automated threat modeling platform.
Considerations
Although threat modeling is very useful, there are several considerations to take into account. Below are the most common ones across different methods:
- Be aware of false positives – this is one of the main reasons for “alert fatigue” so really critical issues which are no false positives can be missed.
- Inconsistent results – this mostly has to do with inexperienced teams so threats are mixed up across different categories or stages.
- Lack of proper documentation – this is important to apply the method in the way the creators intended it. It helps to avoid confusion and it aims to provide consistent results.
- Keep an eye on the defined scope of threat modeling. If unwanted scope creep occurs, too much time is needed to capture all threats also the less important ones. By then the benefits don’t outweigh the efforts.
- Start with threat modeling before you choose a complicated platform or tool which is difficult to learn. It helps to overcome barriers to implement these into the organization.
These considerations might help you when you have to evaluate and work with the various threat modeling tools. Put them on the list of the requirements to select the proper method.
Conclusion
Threat modeling is a highly useful technique to capture risks early in the Software Development Life Cycle. It’s important to evaluate different methods to find the one which suits your organization. Team members should train themselves to effectively use the chosen method. Security teams can help. Be sure to map the technical risks to the potential business impact so you can determine the risk mitigation strategy.
In the end, by working on these tasks in an effective way, you can greatly improve the security of your applications in an on-premise and cloud environment.
