News About John X. Wang

What Every Engineer Should Know About Threat Model and STRIDE

  • Nov 28, 2019 |

    We live in a world that makes heavy use of information. We use it to determine whether we need a jacket or umbrella for the day. Businesses use it to determine whether they made a profit for the week. Governments use it to determine things like incoming tax revenue. In fact, you could say that most of us rely on it. Of course, there are those that will try to exploit that information for personal gain, perhaps through ransom or through sale to the highest bidder. It's a sad fact, but true none the less. So, it will come as no surprise that there are also those out there who are working to determine the significance of these threats since the repercussions of software failure is costly and, at times, can be catastrophic. This can be seen today in a wide variety of incidents,

    • from data leak incidents caused by misconfigured AWS S3 buckets

    • to Facebook data breach incidents due to lax API limitations

    • to the Equifax incident due to the use of an old Apache Struts version with a known critical vulnerability.

    Application Security advocates encourage developers and engineers to adopt security practices as early in the Software Development Life Cycle (SDLC) as possible 1. One such security practice is Threat Modeling.

    What is a Threat Model?

    Threat modeling is a process by which potential threats, such as structural vulnerabilities, can be identified, enumerated, and prioritized – all from a hypothetical attacker’s point of view. The purpose of threat modeling is to provide defenders with a systematic analysis of the probable attacker’s profile, the most likely attack vectors, and the assets most desired by an attacker.

    A threat model, or threat risk model, is a process that reviews the security of any web-based system, identifies problem areas, and determines the risk associated with each area. There are five steps in the process:

    • Identify Security Objectives - This step determines the overall goals the organization has in regard to its security.

    • Survey the System - This step determines the components of the system, the routes through which data travels, and trust boundaries (connections made to outside networks).

    • Decompose the System - This step determines the components of the system that have an effect on security, like the login module.

    • Identify Threats - This step enumerates any potential outside threats that the system has. This generally focuses on those that are known. (How do you identify those that aren't?)

    • Identify Vulnerabilities - This step looks at the identified threats and determines if the system is weak in these areas

    What is STRIDE?

    There are various ways and methodologies of doing threat models. This CRC Press News provides a high-level introduction to one methodology, called STRIDE. STRIDE is an acronym that stands for 6 categories of security risks: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privileges. Each category of risk aims to address one aspect of security.

    STRIDE is a model of threats for identifying computer security threats. It provides a mnemonic for security threats in six categories. The threats are:

    • Spoofing

    • Tampering

    • Repudiation

    • Information disclosure (privacy breach or data leak)

    • Denial of service

    • Elevation of privilege

    The STRIDE was initially created as part of the process of threat modeling. STRIDE is a model of threats, used to help reason and find threats to a system. It is used in conjunction with a model of the target system that can be constructed in parallel. This includes a full breakdown of processes, data stores, data flows and trust boundaries.

    Today it is often used by security experts to help answer the question

    • "what can go wrong in this system we're working on?"

    Each threat is a violation of a desirable property for a system:

    Desired Property






    Impersonating something or someone else.

    Pretending to be any of billg, microsoft.com or ntdll.dll



    Modifying data or code

    Modifying a DLL on disk or DVD, or a packet as it traverses the LAN.



    Claiming to have not performed an action.

    I didn’t send that email,” “I didn’t modify that file,” “I certainly didn’t visit that web site, dear!”


    Information Disclosure

    Exposing information to someone not authorized to see it

    Allowing someone to read the Windows source code; publishing a list of customers to a web site.


    Denial of Service

    Deny or degrade service to users

    Crashing Windows or a web site, sending a packet and absorbing seconds of CPU time, or routing packets into a black hole.


    Elevation of Privilege

    Gain capabilities without proper authorization

    Allowing a remote internet user to run commands is the classic example, but going from a limited user to admin is also EoP.

    Let's dive into each of these categories.


    Spoofing refers to the act of posing as someone else (i.e. spoofing a user) or claiming a false identity (i.e. spoofing a process). This category is concerned with authenticity. Most security systems rely on the identification and authentication of users. Spoofing attacks consist in using another user credentials without their knowledge. Typical spoofing threats target weak authentication mechanisms, for instance those using simple passwords, like a simple 4 digits number, or those using personal information that can be easily found, like date or place of birth.


    • One user spoofs the identify of another user by brute-forcing username/password credentials.

    • A malicious, phishing host is set up in an attempt to trick users into divulging their credentials.

    You would typically mitigate these risks with proper authentication.


    Tampering refers to malicious modification of data or processes. Tampering may occur on data in transit, on data at rest, or on processes. This category is concerned with integrity. Only authorised users should be able to modify a system or the data it uses. If an attacker is able to tamper with it, it can have some consequences on the usage of the system itself, for instance if the attacker can add or remove some functional elements, or on the purpose of the system, for instance if important data is destroyed or modified.


    • A user performs bit-flipping attacks on data in transit.

    • A user modifies data at rest/on disk.

    • A user performs injection attacks on the application.

    You would typically mitigate these risks with:

    • Proper validation of users' inputs and proper encoding of outputs.

    • Use prepared SQL statements or stored procedures to mitigate SQL injections.

    • Integrate with security static code analysis tools to identify security bugs.

    • Integrate with composition analysis tools (e.g. snyk, npm audit, BlackDuck ...etc) to identify 3rd party libraries/dependencies with known security vulnerabilities.


    Repudiation refers to the ability of denying that an action or an event has occurred. Repudiation is unusual because it's a threat when viewed from a security perspective, and a desirable property of some privacy systems. This is a useful demonstration of the tension that security design analysis must sometimes grapple with. This category is concerned with non-repudiation. Attackers often want to hide their malicious activity, to avoid being detected and blocked. They might therefore try to repudiate actions they have performed, for instance by erasing them from the logs, or by spoofing the credentials of another user.


    • A user denies performing a destructive action (e.g. deleting all records from a database).

    • Attackers commonly erase or truncate log files as a technique for hiding their tracks.

    • Administrators unable to determine if a container has started to behave suspiciously/erratically.

    You would typically mitigate these risks with proper audit logging.

    Information Disclosure

    Information Disclosure refers to data leaks or data breaches. This could occur on data in transit, data at rest, or even to a process. This category is concerned with confidentiality. Many systems contain confidential information, and attackers often aim at getting hold of it. There are numerous examples of data breaches in the recent years.


    • A user is able to eavesdrop, sniff, or read traffic in clear-text.

    • A user is able to read data on disk in clear-text.

    • A user attacks an application protected by TLS but is able to steal x.509 (SSL/TLS certificate) decryption keys and other sensitive information. Yes, this happened.

    • A user is able to read sensitive data in a database.

    You would typically mitigate these risks by:

    • Implementing proper encryption.

    • Avoiding self-signed certificates. Use a valid, trusted Certificate Authority (CA).

    Denial of Service

    Denial of Service refers to causing a service or a network resource to be unavailable to its intended users. This category is concerned with availability. A system is usually deployed for a particular purpose, whether it is a banking application or an integrated media management on a car. In some cases, attackers will have some interest in preventing regular users to access the system, for instance as a way to blackmail and extort money from the owner of the system (e.g., with ransomware).


    • A user performs SYN flood attack.

    • The storage (i.e. disk, drive) becomes too full.

    • A Kubernetes dashboard is left exposed on the Internet, allowing anyone to deploy containers on your company's infrastructure to mine cryptocurrency and starve your legitimate applications of CPU. Yes, that happened too.

    Mitigating this class of security risks is tricky because solutions are highly dependent on a lot of factors.

    • For the Kubernetes example, you would mitigate resource consumption with resource quotas.

    • For a storage example, you would mitigate this with proper log rotation and monitoring/alerting when disk is nearing capacity.

    Elevation of Privileges

    Elevation of Privileges refers to gaining access that one should not have. This category is concerned with authorization. Once a user is identified on a system, they usually have some sort of privileges, i.e., they are authorised to perform some actions, but not necessarily all of them. An attacker might therefore try to acquire additional privileges, for instance by spoofing a user with higher privileges, or by tampering the system to change their own privileges.


    • A user takes advantage of a Buffer Overflow to gain root-level privileges on a system.

    • A user with limited to no permissions to Kubernetes can elevate their privileges by sending a specially crafted request to a container with the Kubernetes API server's TLS credentials. Yes, this was possible.

    Mitigating these risks would require a few things:

    • Proper authorization mechanism (e.g. role-based access control).

    • Security static code analysis to ensure your code has little to no security bugs.

    • Compositional analysis (aka dependency checking/scanning), like snyk or npm audit, to ensure that you're not relying on known-vulnerable 3rd party dependencies.

    • Generally practicing least privilege principle, like running your web server as a non-root user.


    In order to assess the security of a system, we must therefore look at all the possible threats. The STRIDE model is a useful tool to help us classify threats. STRIDE is a threat model methodology that should help you systematically examine and address gaps in the security posture of your applications. STRIDE is an acronym that stands for:

    • Spoofing Identity - This is a threat where one user takes on the identity of another. For example, an attacker takes on the identity of an administrator.

    • Tampering with Data - This is a threat where information in the system is changed by an attacker. For example, an attacker changes an account balance.

    • Repudiation - This is a threat where an attacker deletes or changes a transaction or login information in an attempt to refute that they ever took place. For example, deleting a purchase transaction so the item isn't charged to you.

    • Information Disclosure - This is a threat where sensitive information is stolen and sold for profit. For example, information on the latest widget is stolen and offered to a competitor for profit.

    • Denial of Service - This is a threat where the resources of a system are overwhelmed and processing stops for everyone. For example, a disgruntled attacker could have automated servers continually log into a system, tying up all connections so legitimate users can't get in.

    • Elevation of Privilege - This is a threat similar to spoofing, but instead of taking on the ID of another, they elevate their own security level to an administrator.

    See More
    Computer Game Development, Computer Science & Engineering, Engineering - Electrical, Engineering - General, Engineering - Industrial & Manufacturing, Homeland Security, Information Technology, Web, Web2