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.