STRIDE
STRIDE is a method of threat analysis to aid in secure design of systems. We have already looked at risk analysis and threat analysis in general. We know that threat analysis and mitigation are important to develop robust security requirements for projects.
STRIDE was introduced by Microsoft and focuses on what the attacker is trying to achieve. This process is endorsed by many industry players, including OWASP, and Microsoft.
The process of STRIDE is taught in security certification programs, and has wide use in industry, whilst being approachable to the end user.
STRIDE is used at the design phase and helps to find and fix issues before they occur, instead of removing them once deeply embedded in the application.
Data Flow Diagrams
The first step in STRIDE is to introduce data flow diagrams, which are graphical representations of the system under review. DFDs model the entry, exit and traversal of data across software components, showing all data sources and destinations.
The DFD shows all relevant processes the data goes through, and also handles data at rest as well as in motion. A DFD is a critical requirement to threat modelling.
A good DFD doesn't necessarily mean modelling every detail in the system, but getting the relevant details at the right level in the context that is being worked in.
Elements
Elements of a data flow include:
- External entity--in a rectangle
- Process--in a circle
- Data flow--arrows
- Data store--two horizontal lines
- Trust boundary--dashed line surrounding processes in the system
Trust Boundaries
These intersect data flows and are points at which an attacker can interject. These can occur at the machine-level, privilege-level, or integrity levels.
Processes across a network always have a trust boundary, as encryption only addresses confidentiality and we need to think about tampering or spoofing of the data.
Decomposition
DFDs are drawn at varying levels of abstraction. Initially, these are very high level, looking at the software and external entities that interact with it.
From here, we move to a level 1 diagram, which is more in depth than the context diagram, but are still high level, showing the major business processes.
These processes can then be decomposed into level 2 diagrams, and we continue decomposing until no further decomposition can occur.
Identification of Threats
Once we have DFDs at the appropriate level of abstraction, we can then begin to identify threats. Domain experts can brainstorm possible threats, but without being an expert, we might not be able to think of everything. STRIDE provides a mnemonic to identify threats without being an expert. The mnemonic is as follows:
| Threat | Property Desired |
|---|---|
| Spoofing | Authentication |
| Tampering | Integrity |
| Repudiation | Nonrepudiation |
| Information Disclosure | Confidentiality |
| Denial of Service | Availability |
| Elevation of Privilege | Authorization |
From these properties, we then can begin doing element mappings. We take the threat type, and assign one or more DFD elements to the threat.
Refining with Threat Trees
Threat types are refined into concrete threats with threat trees or composition of threats. STRIDE provides threat trees for each element of STRIDE. We can then go through each of the trees for the relevant threats to see what threats actually apply to which DFD elements.
Drawing DFDs
The main tool recommended by the module is the Microsoft Threat Modelling Tool, but this is only available on Windows. For Linux, OWASP maintain the Threat Modelling Dragon, which is a multiplatform tool that it primarily web-UI based but also includes a graphical frontend as part of the application.
Mitigating Threats
So far, we have looked at the threats that are possible and how we model the system to find these possible threats. Once the threats have been found, we now need to assign them a risk level so that we can begin to mitigate them.
Risks can be assessed as a combination of the likelihood and impact, as discussed in the initial risk analysis lecture. STRIDE defines 4 of these risk levels, 1 being very high and fixed during development, 2 high and also fixed in development, 3 a medium risk, fixed before product becomes release candidate and 4 when the risk is low and we have time to address it.
Assessing Risks
Microsoft has the concept of a bug bar, which classifies the threats based on their impact. The bug is assigned a STRIDE category, then the risk level is assigned based on a variety of different factors:
- Server application versus client application
- Local versus remote accessibility
- Accessibility to anonymous versus authenticated users
- Accessibility to authenticated users versus administrators
- The degree of user interaction required
- In the case of an information disclosure threat, whether the data is personally identifiable information (PII) or is sensitive data
- In the case of a DoS attack, whether the application continues service or is non-functional once an attack starts
Once assessed, we can begin moving to mitigations.
Planning
Threats can be mitigated in four ways. The first is to do nothing, the second is to remove the feature, the third is to accept the vulnerability in the design, and the fourth is to counter the threats with technology.
The STRIDE documents give a list of threats, the property desired to counter this, and a bunch of ways that we can go about doing this. For example, take spoofing: this is a property of authentication. Authentication can then be split into people or code and data. For people, we could choose to implement basic authentication, and for code or data, we could use digital signatures.
There is a long list for each threat and property, giving a list of all the different mitigations. We can then go back to our DFD list with the threat type, the threat itself, and the mitigation. We then assess the risk of the threat (1-4), then for each threat with risk level 1 or 2, propose a mitigation.
Validation
Model
The final step in STRIDE is to validate the threat model. We want to check the following properties hold:
- Diagram matches final code
- Threats fully enumerated
- Minimum of STRIDE per element that touches a trust boundary
- Test/QA approval of the model
- Mitigation of each threat
- Mitigations implemented correctly?
- Checked before final security review?
Threat and Mitigation
For threats, we need to check if they describe the attack, describe the context, and describe the impact of the threat. For the mitigations, we need to check if they can be associated with a threat, and that the mitigation has been described in sufficient detail.
Information Captured
The final validation step is to check the dependencies of our project, and see what security functions are implemented in their code. We also need to check that our assumptions hold, and if not, modify the model.
Summary
Threat modelling can help to find and mitigate security design flaws before the system is built. STRIDE is a systematic process to identify and mitigate security design flaws, and can be used by non-experts.