Today’s cyber attackers are becoming ever more inventive in the way they achieve big bang cyber attacks, using tactics such as hacking suppliers in order to gain access to their customers, or compromising vulnerabilities inside an application’s code in order to attack an organisation.
As a result, developers need to be more threat conscious than ever when creating their applications and products. But with so many new and emerging threats, how can they be sure they’ve thought of everything?
That’s where a framework such as STRIDE threat modelling can help. STRIDE threat modelling supports developers and organisations to identify cybersecurity threats to their application, prioritise them based on impact and likelihood, and build mitigation into their secure software development lifecycle (SSDLC).
What is STRIDE threat modelling?
STRIDE threat modelling is a developer focussed threat modelling method based on six common threats that target software. STRIDE is an acronym for each of the threat categories it deals with: Spoofing, Tampering, Repudiation, Information disclosure, Denial of Service, and Elevation of privilege.
The STRIDE threat model was created in 1999 by security researchers at Microsoft. While STRIDE threat modelling is useful for organisations on its own, is also forms part of a wider methodology that provides security teams with a practical framework for identifying threats and dealing with them by defining security requirements, creating an application diagram, identifying threats, mitigating threats, and validating that threats have been mitigated.
The six threat groups considered in the STRIDE threat modelling framework focus on different elements of security within an application, encouraging developers to think about the threats that could impact every part of an application or system, and the ways that they can protect against them right from the start of the development process.
The six elements of STRIDE threat modelling are:
Spoofing
A spoofing attack is when attackers disguise their identity to successfully impersonate a trusted source and gain access to important data or information from a user. Spoofing often uses social engineering to convince users to give information such as usernames and passwords. Once they have the information, attackers will use it to gain access to the application and from there infect the network.
Spoofing attacks include cookie replay attacks, session hijacking, and cross site request forgery (CSRF) attacks.
Since spoofing is an attack on user authentication, the best form of prevention is to implement secure user authentication methods, including both secure password requirements and multi-factor authentication (MFA).
Tampering
Tampering involves the deliberate modification of a system in order to change its behaviour. Attackers will try to compromise applications by tampering target parameters or code in order to modify application data such as user credentials and permissions, or other crucial items in the application.
Tampering attacks such as Cross Site Scripting (XSS) and SQL injection damage the integrity of the application. In order to protect against tampering, the application should be designed to validate user inputs, and encode outputs. Static code analysis should be used to identify vulnerabilities to tampering in the application both during the development stage and once the application is in production.
Repudiation
A repudiation attack is an attack on the validity and integrity of actions on the application. Repudiation attacks take advantage of a lack of controls which properly track and log user actions, using this lack to manipulate or forge the identification of new, non-authorised actions, delete logs or log the wrong data to log files, and deny actions or receipt of service (for example, committing fraud).
Developers can build non-repudiation, or the assurance that someone can’t deny the validity of an action, by incorporating digital signatures in the application which provide proof of actions, or by ensuring that there are full, tamper-proof logs in place.
Information disclosure
Information disclosure is when the application unintentionally reveals information about the application that can be used by attackers to compromise the system.
Information disclosure can come from developer comments that are left in the application, source code that provides parameter information, or error messages that contain too many details, revealing data about users, sensitive commercial or business data, and technical details about the application and its infrastructure.
This information can then be used by attackers to force access to the application gathering information about customers, which can be used in further crime, or to gain privileges which in turn will give access to more sensitive areas of the application.
Developers are at the heart of preventing information disclosure vulnerabilities on the application:
- Error messages, response headers, and background information should be as generic as possible to avoid revealing clues about the application’s behaviour.
- Proper access controls and authorisations should be in place to prevent unauthorised access to information.
- The application itself should be checked over from a user perspective to validate that developer comments and other information is not revealed in the production environment.
Denial of service
Denial of service (DoS) attacks flood the target with traffic, triggering a crash, and shutting it down to legitimate traffic. DoS attacks typically cost time and money, but do not cause other damage to their victims. The most common form of DoS attack is a buffer overflow attack which simply sends too much traffic to the application. Other attacks exploit vulnerabilities to cause systems to crash.
DoS attacks can target both the network layer or the application layer. Applications can be protected against DoS attacks by configuring firewalls to block traffic from certain sources such as reserved, loopback, or private IP addresses, or unassigned DCHPDHCP clients, or introducing rate limiting to manage traffic.
Escalation of privilege
Privilege escalation attacks exploit vulnerabilities and misconfigurations in the application to gain illicit access to elevated or privileged rights. Privilege escalation attacks may exploit credential and authentication processes, compromise vulnerabilities in code and design, take advantage of misconfigurations, or use malware or social engineering to gain access.
Protection against escalation of privilege should be built into the application at the development stage. This includes managing the identity lifecycle, enforcing the principle of least privilege for all users, hardening systems and applications through configuration changes, removing unnecessary rights and access, closing ports, and more.
The benefits of STRIDE threat modelling
Get ahead of vulnerabilities at an early stage
Many of the accepted ways of identifying vulnerabilities (static code analysis, penetration testing, bug bounties, and so on) come into play once all or most of the application has been developed. However, it’s cheaper and easier to fix flaws during the development cycle than it is once the vulnerabilities are in the live product.
STRIDE threat modelling is a development-centric method of assessing the threats that may impact on an application. STRIDE can be used to form a checklist for a secure software development lifecycle, supporting developers to identify potential weaknesses early on when they are cheaper and easier to mitigate or remediate.
Take a security first approach
STRIDE threat modelling is built around threats encouraging developers to think about how each of the threats under consideration could attack different parts of the application. Furthermore, it challenges assumptions, making developers and information security teams question their assumptions, and test them for validity and security.
The outcomes of a STRIDE threat modelling exercise can be combined with the DREAD risk assessment model (Damage potential, Reproducibility, Exploitability, Affected users, Discoverability) to assess the impact of each risk, and prioritise vulnerabilities for remediation.
STRIDE threat modelling can be carried out over and over again
STRIDE threat modelling is never over.
STRIDE threat modelling is a framework that allows for threat modelling exercises at regular intervals to enable security teams to keep on top of the rapidly evolving threat landscape, and ensure that the protections in place are able to withstand both older and newer threats.
STRIDE threat modelling is part of a wider cybersecurity programme
Creating secure applications and systems and protecting them requires a multi-faceted cybersecurity risk management programme that incorporates infrastructure protections and other activities such as testing the security of applications and systems regularly with penetration tests.
STRIDE threat modelling provides one of these facets, supporting developers to incorporate secure development practices when developing applications and systems. STRIDE threat modelling alone will not secure your application, but it will provide a strong foundation from the very start of the process.
Stay safe
