Software is eating the world. As a result, 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.
In this article, I offer a high-level introduction to one methodology, called STRIDE, and in a future article, I will demonstrate this process using an existing open-source application as an example.
Here is the obligatory Wikipedia definition:
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.
With that out of the way, the simplest explanation in English is this:
Threat Models are a systematic and structured way to identify and mitigate security risks in our software.
There are various ways and methodologies of doing threat models, one of which is a process popularized by Microsoft, 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.
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.
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.
You would typically mitigate these risks with:
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.
This category is concerned with non-repudiation.
You would typically mitigate these risks with proper audit logging.
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.
You would typically mitigate these risks by:
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.
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 refers to gaining access that one should not have.
This category is concerned with authorization.
Mitigating these risks would require a few things:
npm audit, to ensure that you’re not relying on known-vulnerable 3rd party dependencies.
So, STRIDE is a threat model methodology that should help you systematically examine and address gaps in the security posture of your applications.
In a future article, we’ll take an application and go through this process so you can get a feel for how this works.
If you would like to propose an application for me to threat model next, feel free to drop suggestions in the comments below.