Skip to content

STRIDE Threat Modelling: Six Steps to a Secure Application

Cyber attackers today are ever more creative in their methods of executing large-scale cyber attacks using techniques such as hacking into suppliers get access to customers or by compromising weaknesses within the code of an application to target an organization.

Therefore developers have to be more alert to threats in the creation of their apps and products. However, with all the different and innovative threats how can they ensure that they’ve thought of every aspect?

This is where a framework like STRIDE threat modelling can assist. STRIDE threat modeling helps organizations and developers to recognize security threats to their applications and prioritize them according to their impact and probability and integrate mitigations in their software development cycle (SSDLC).

What is STRIDE threat modeling?

The STRIDE threat modeling is a threat modelling technique that is built on six typical threats that attack software. The acronym STRIDE refers to every threat category it addresses Spoofing, Tampering Repudiation, Information disclosure DDoS, as well as the elevation of privilege.

The STRIDE threat model was devised around 1999 by researchers from security from Microsoft. While STRIDE threat modeling is beneficial for organizations as a whole, it an integral part of a larger methodology that offers security professionals with an effective method of identifying threats and tackling them through formulating security requirements, constructing an application diagram that identifies threats, managing risks, and verifying the fact that risks have been reduced.

The six threat categories considered within the STRIDE threat modelling framework are focused on various elements of security in the application. They encourage developers to consider dangers that could affect the entire software or system and also the methods they can defend against them in the initial stages to the design process.

The six components of STRIDE threat modeling are:

Spoofing

Spoofing attacks occur when attackers disguise their identity in order to successfully impersonate a trusted entity and gain access information or data from the user. Spoofing usually employs social engineering techniques to get users to divulge data such as usernames or passwords. Once they have this information the attackers can utilize this information to access the app, and from they will spread malware to the network.

Spoofing attacks can include cookies replay , hijacking sessions and cross-site request forgery (CSRF) attacks.

Since spoofing can be a threat on authentication for users the most effective method of defense is to adopt safe methods for user authentication which include both secure password requirements as well as the multi-factor authentication (MFA).

Tampering

Tampering is the deliberate alteration of a system to alter its behavior. Attackers try to hack applications by altering the parameters or coding in order to alter the data of an application, such as user credentials , permissions, and other vital elements of the application.

Tampering attacks, such as Cross Site Scripting (XSS) and SQL injection can compromise the security and security of an application. To guard against tampering attacks, the application must be designed to verify user inputs, as well as encode outputs. Static code analysis must be utilized to detect potential vulnerabilities to tampering with the application, both in the development phase, and later when the application is operational.

Repudiation

Repudiation attacks are an attack on the legitimacy and integrity of the actions performed on the application. Repudiation attacks exploit the absence of security controls that accurately track and record user actions. They then use this inability to manipulate or alter the identity of any new, unauthorised actions, erase logs or add incorrect data to log files, or block actions or the receipt of services (for example, in the case of fraud).

Developers can create non-repudiation, or the guarantee that no one will be able to contest the legitimacy of an action by using digital signatures within the application, which offer proof of the actions taken or by ensuring there are complete, tamper-proof logs available.

Information disclosure

Information disclosure occurs when an application intentionally divulges details about the application which can be used by hackers to attack the system.

Information disclosure may result from developer comments which are included within the application, or from source code that gives details about parameters, or from error messages that have excessive details, which reveal information about users, sensitive business or commercial data as well as technical information about the application’s infrastructure and.

The information could be used by attackers to get an application to be accessed by to gather details about customers. This information could later be used for more crimes, or gain access to privileges that could allow access to the most sensitive areas of the application.

Developers are at the forefront of preventing vulnerability to disclosure of information within the application

The error messages and response headers and background information must be as general as is possible so as to not reveal any details about the behavior of the application.
Authorisations and access controls that are properly controlled should be put in the place to block unauthorised access to data.
The application should be scrutinized from a perspective of the user to ensure that comments from developers and other data are not disclosed inside the development environment.

Service denial

The Denial of Service (DoS) attacks overwhelm the targets with traffic, triggering an accident, then the target is shut down to normal traffic. DoS attacks usually take time and cost money, however, they don’t cause damages to their victims. The most commonly used form that is a DoS attack is buffer overflow attacks that simply transmits too much data through the system. Others exploit weaknesses that cause systems to crash.

DoS attacks can affect the network layer and the layer of application. Application layers can be protected from DoS attacks by setting firewalls to prevent traffic from specific sources like loopback, reserved as well as private IP addresses or DCHPDHCP clients that are not assigned or by introducing rate-limiting to control the flow of traffic.

Escalation of privilege

The attacks use weaknesses and configurations that are not correct in applications to obtain access to privileges that are elevated or restricted. These attacks could attack authentication and credential processes, compromising vulnerabilities in the design and code and exploit misconfigurations or malware Social engineering in order to access information.

The protection against escalation of privileges should be integrated into the application from the beginning of the stage of development. This means managing the lifecycle of identity and ensuring the principle of most users having the lowest privilege as well as hardening applications and systems by making configuration changes, eliminating unneeded rights and accession, closing port and many more.

The advantages of STRIDE threat modeling

Be aware of weaknesses in the beginning

A lot of the methods to identify vulnerabilities (static code analysis bugs bounties, penetration tests and other methods) are used once all or a large portion of the application is developed. It’s also cheaper and more efficient to correct vulnerabilities during the development phase rather than once flaws are present in the actual product.

Threat modelling with STRIDE is a development-based method of analysing the risks that could affect an application. STRIDE can make a checklist for an effective software development lifecycle aiding developers in identifying possible weaknesses earlier, so that they’re less expensive and easier to reduce or fix.

Make sure you are taking a security-first approach

Threat modelling in STRIDE is based on threats, which encourages developers to consider the ways in which each threat to be considered might affect different components within the software. Additionally it challenges assumptions making security and development groups question the assumptions they have made and verify their authenticity and security.

The results of the STRIDE threat modeling exercise can be used in conjunction with an DREAD Risk Assessment Model (Damage possibility, Reproducibility Exploitability, Affected Users and Discoverability) to evaluate the effects of each risk and identify vulnerabilities that require remediation.

The threat modeling STRIDE can be done repeatedly

Threat modelling with STRIDE is never ever.

The threat modeling STRIDE provides is an application that permits periodic threat modelling exercises. intervals, allowing security teams to stay abreast of the ever-changing threat landscape and ensure that the security measures put that are in place can be able to withstand both modern and old threats.

The threat modeling of STRIDE is a part of a larger cybersecurity program.

Making secure systems and applications and safeguarding them requires a broad cybersecurity risk management program that includes infrastructure protections as well as other tasks like checking the safety of the applications and systems regularly using penetration tests.

The threat modeling STRIDE provides one of these features helping developers implement secure development practices into the development of software and other systems. The threat modelling capabilities of STRIDE alone is not enough to ensure your application’s security however it can provide an excellent foundation at the beginning to the entire process.