Finding security defects early in the SDLC with STRIDE threat modeling [updated 2021]

Originally written by Karthik, updated for 2021 by Patrick Mallory

Given how much time, money and energy go into designing, building and delivering your software solutions, it makes sense to find a proven method to identify defects and threats early on in the process. 

Although there are various models, threat modeling provides a structured method to evaluate the vulnerabilities that can potentially exist in a given piece of software under observation. Although vulnerabilities may not always be found, prioritizing threat modeling and proactively hunting for potential attack vectors can go a long way toward reducing the attack surface. At the same time, threat modeling is an iterative process that should be done when there are changes to your applications or even your business processes. 

The result is not only a comprehensive assessment and security profile of that particular application under observation, but the peace of mind that comes with knowing your organization is taking the steps needed to improve the security of your technology ecosystem.

Learn Threat Modeling

Get hands-on experience with six threat modeling courses covering defense-in-depth, frameworks like STRIDE and Rapid Threat Model Prototyping (RTMP), agile architecture and more.

Start Learning

Threat modeling categories

As mentioned before, there are various forms of threat models, but they generally fall into one of three major categories according to how it is implemented: 

• End-point-centric
• Design-centric
• Asset-centric

End-point-centric threat models

An end-point-centric threat model focuses on the attacker’s perspective of an application, which includes the information and profile that they would have if they were to plan to carry out an attack. 

In this case, the internal development team sits together and speculates how an attacker might penetrate their product. Based on this assessment, they come up with defenses to those attack vectors.

Design-centric threat models

Design-centric threat modeling focuses on the design process of the application itself. However, it is important to remember that vulnerabilities do not only exist in code, but also in the structure and design of the application, which can allow attackers to find loopholes in the application and use it to their advantage. The design is processed based on inputs from various members and then a final draft is made.

Asset-centric threat models

Asset-centric threat modeling focuses on the information that is passed to and from the application. Because this information and data is often sensitive and trusted by other applications and users, attackers can use this vector as a way to inject malicious traffic or use the information to perform social engineering-based attacks, thereby gaining access to the target. 

The STRIDE threat model

Although there are many trusted threat models, in this article we will apply the STRIDE model as an example of how an organization can approach the process, organize the inputs and utilize the outputs. 

The acronym STRIDE stands for:

• Spoofing
• Tampering
• Repudiation
• Information disclosure
• Denial of service attacks
• Elevation of privilege

Overview of the STRIDE components

Spoofing

In simplest terms, spoofing refers to an action by a person or device who claims to be one which they are not to initiate and perform exploitation. 

Examples can include:

• DNS spoofing
• IP spoofing
• MAC address spoofing
• Email spoofing
• SMS spoofing
• Biometric spoofing

In all these cases, the attacker utilizes information or characteristics of the victim device to impersonate it and gain the trust of the target network in the process. 

For example, in a DNS spoofing attack, also known as a man-in-the-middle attack, the attacker impersonates legitimate client-server packet traffic. In specific, every DNS “conversation” between a client and a server involves packets that are sent with a sequence number for tracking purposes and are incremented by one. To perform the attack, the attacker “spoofs” (or fakes) a packet to reach the victim before the legitimate response reaches him, thus “poisoning” the DNS cache. 

As another example, IP spoofing is a classic example of masking one’s identity when performing an attack. Proxy servers or “zombie” systems, which are composed of compromised devices to facilitate traffic redirection, are generally used by attackers when they carry out full-fledged attacks.

Finally, another common example is phishing. When performing a phishing attack, email spoofing or SMS spoofing can be used to gain the trust of the victim and trick them into trusting a malicious link. 

Tampering

Tampering also involves manipulating information sent from one machine to another. In this situation, a message sent from one host may not reach the destination in the same form as it was at its source. 

The use of the Tamper Data plugin in Firefox is an example of this attack vector, where the plugin is used to successfully tamper with a checkout request coming from e-commerce sites and manipulates it according to the needs of the attacker. The traffic capture tool Burp can also perform the same data manipulation, allowing a user to capture and change website requests from the original sender before it reaches the intended destination.

Repudiation

If an application cannot log and handle validations and internal transactions, then an attacker can take advantage of this design flaw. In particular, an attacker can initiate transactions and leave inaccurate, or even zero logs behind within the application.

For example, suppose the attacker is successful in finding a window through which he can perform actions anonymously (due to the flaw in the design or implementation of an application. If found, then all the transactions or actions initiated by the attacker are not handled appropriately by the code, which results in “dirty” entries in the database that can render all of the other data points invalid, too.

Information disclosure

This threat involves the unintended capture and exploitation of user or system information for malicious purposes by a cybercriminal. 

For example, a web browser vulnerability can allow for a user’s mouse movements to be tracked. Once captured, an attacker can exploit this vulnerability by tracking mouse events and using it to their advantage to manipulate links, actions and scripts, to gain access to the user’s system. 

Denial of service

Denial of service (DoS) attacks lead to the unavailability of a machine or a device. 

The most basic forms of DoS attacks are to consume the bandwidth or computing power of the target device, causing it to fail. A DoS attack can also occur when an attacker injects or introduces configuration errors to the network device such that the service is disrupted or blocked.

Because of the ability of security products to block or filter traffic from a malicious source, DoS attacks have evolved with distributed DoS attacks (DDoS). DDoS attacks pose a serious threat because they are implemented by multiple devices attacking a single target. This reduces the time needed to perform the attack, increases its effectiveness, and reduces the ability of security products to completely block malicious traffic. Also, in such a scenario, it’s very difficult to trace the attack back to the source when millions of devices attack a single target.

Escalation of privilege

When an attacker gains access to a system, they often work to obtain the highest privileges, or rights, within it. In Windows systems, this includes NT/system access while in Linux-based systems, this is referred to as root access. 

If achieved, the attacker has the highest access rights on the victim device such that they can perform actions and tasks with the least amount of access control limits.

Using STRIDE in threat modeling

When an organization begins threat modeling, it should involve representatives from across their business units working together to identify all of the various kinds of attacks that can be achieved in the target system. 

Following the STRIDE model described above, the team would use the model as prompts, or a structured approach, toward comprehensively evaluating the system. In other words, the team would start from S and end at E. 

Once each aspect of the STRIDE model is discussed and the potential vulnerabilities captured, each should either be remediated or determined to be acceptable risks.

A brief scenario of the threat model 

As an example, the STRIDE model can be used as a threat modeling approach for a web-based login page for an application.

Working through each component of STRIDE could result in:

• S
• Spoofing identity through SQL injection
• Spoofing cookies through cross-site scripting in the search tab
• T
• Tampering of login credentials on the wire
• Observing the GET/POST requests and manipulating them
• R
• Repudiation of application login data by stealing the authentication session
• I
• Decryption or manipulation of the cryptography of login credentials so that they are passed “in the clear” in plaintext
• D
• Attempting to “overflow” or overload, also known as “fuzzing” field input in an attempt to crash or manipulate the behavior of the application
• Trying to send numerous login requests such that bandwidth is consumed
• E
• Performing a SQL injection to gain user credentials

Learn Threat Modeling

Get hands-on experience with six threat modeling courses covering defense-in-depth, frameworks like STRIDE and Rapid Threat Model Prototyping (RTMP), agile architecture and more.

Start Learning

Using the STRIDE approach for threat modeling

The STRIDE approach to threat modeling is just one way that an organization could introduce a structured, interactive method toward evaluating the potential vulnerabilities of an application. However, it is important to remember that vulnerability analysis and threat modeling is not a “one and done” exercise; it should be continually performed as business operations evolve and new potential threats are introduced.