Threat modelling

Threat modelling is best integrated into the design phase of an SDLC before any code is written. Threat modelling is a structured process of identifying potential security threats and prioritising techniques to mitigate attacks so that data or assets that have been classified as valuable or of higher risk during risk assessment, such as confidential data, are protected. When performed early, it brings a great advantage; potential issues can be found early and solved, saving fixing costs down the line.

There are several tools and methodologies to do threat modelling.

Methods

There are several methods to perform threat modelling. Not all the methods have the same purpose; focus varies from risk, to privacy concerns, to customer. The methods can be combined to understand potential threats better. STRIDE, DREAD, and PASTA fit together really well. Don’t let the process or tools limit learning and innovation.

STRIDE

STRIDE stands for Spoofing, Tampering, Repudiation, Information Disclosure, Denial Of Service, and Elevation/Escalation of Privilege. STRIDE is a widely used threat model developed by Microsoft which evaluates the system’s design in a more detailed view. STRIDE can be used to identify threats, including the property violated by the threat and definition. The system’s data flow diagram is to be developed in this model, and each node is applied with the STRIDE model. Identifying security threats is a manual process that tools are not supported and should be carried out during the risk assessment. Using data flow diagrams and integrating STRIDE, the system entities, attack surfaces, like known boundaries and attacker events become more identifiable. STRIDE is built upon the CIA triad principle (Confidentiality, Integrity & Availability). Security professionals using STRIDE are looking to answer “What could go wrong with this system?”

STRIDE threat
Spoofing Spoofing is an act of impersonation of a user by a malicious actor
which violates the authentication principle from the perspective of
theCIA triad. Common ways include ARP, IP, and DNS spoofing.
Tampering The modification of information by an unauthorised user. It violates
the integrity principle of the CIA triad.
Repudiation Not taking responsibility for events where the actions are not
attributed to the attacker, violating the principle of non-repudiability.
For example, the attacker clears up all the logs that could lead to
leaving traces.
Information Disclosure Information Disclosure is an act of violation of confidentiality of the
CIA triad. A typical example is data breaches.
Denial of Service Denial of Service occurs when an authorised user cannot access
the service, assets, or system due to the exhaustion of network
resources. DoS is a violation of the availability principle of the CIA
triad.
Elevation/Escalation of Privilege Escalating privileges to gain unauthorised access is a classic
example of a violation of the authorisation principle of the CIA triad.

DREAD

The abbreviation DREAD stands for five questions about each potential: Damage Potential, Reproducibility, Exploitability, Affected Users and Discoverability. DREAD is also a methodology created by Microsoft which can be an add-on to the STRIDE model. It’s a model that ranks threats by assigning identified threats according to their severity and priority. In other words, it creates a rating system that is scored based on risk probability. Without STRIDE, the DREAD model also can be used in assessing, analysing and finding the risk probability by threat rating.

DREAD potential
Damage Damage refers to the possible damage a threat could cause to the existing
infrastructure or assets. It is based on a scale of 0–10. A score of 0 means
no harm, 5 means Information Disclosure, 8 means user data is compromised,
9 means internal or administrative data is compromised, and 10 means
unavailability of a service.
Reproducibility Measures the complexity of the attack. So how easily a hacker can replicate
a threat. A score of 0 means it is nearly impossible to copy, 5 stands for
being complex but possible, 7.5 for an authenticated user and a score of 10
means the attacker can reproduce very quickly without any authentication.
Exploitability Refers to the attack's sophistication or how easy it would be to launch the
attack. A score of 2.5 implies it would require an advanced skill set of
networking and programming skills; 5 means can be exploited with available
tools, a score of 9 means we would need a simple web application proxy tool
and a score of 10 means it can exploit through a web browser.
Affected Users Describes the number of users affected by the successful exploitation of a
vulnerability. A score of 0 would mean that there would be no affected users,
2.5 shall mean for an individual user, 6 would mean a small group of users,
9 would mean significant users like administrative users, and 10 would imply
all users are affected.
Discoverability The process of discovering the vulnerable points in the system. For example,
the threat would be easily found in case of compromise. A score of 0 would
mean it would be challenging to discover it, a score of 5 means that the threat
can be discovered by analysis of HTTP requests, and 8 means it can be
easily found as it's public-facing. A score of 10 would mean it's visible in the
browser address bar.

PASTA

PASTA is short for Process for Attack Simulation and Threat Analysis; it is a risk-centric threat modelling framework. PASTA’s focus is to align technical requirements with business objectives. PASTA involves the threat modelling process from analysing threats to finding ways to mitigate them, but on a more strategic level and from an attacker’s perspective. It identifies the threat, enumerates them, and then assigns them a score. This helps organisations find suitable countermeasures to be deployed to mitigate security threats.

PASTA Stage
Define Objectives The first stage focuses on noting the structure and defining objectives.
This makes the end goal a whole lot clearer and ensures the relevant
assets are threat modelled by defining an asset scope.
Define Technical Scope This is where architectural diagrams are defined, both logical and
physical infrastructure. Helpful in mapping the attack surface and
dependencies from the environment.
Decomposition &
Analysis
Each asset will have a defined trust boundary that encompasses all
its components and data in this stage. For example, mapping threat
vectors for a payment service and evaluating which components
underlying the service can be leveraged for an attack; components
can be libraries, dependencies, modules or underlying services etc.
Threat Analysis This refers to the extracted information obtained from threat
intelligence. Useful to identify which applications are vulnerable to
specific vectors; for example, a customer/public-facing application
can be susceptible to DDOS, unauthorised data alteration etc.
Vulnerabilities &
Weaknesses Analysis
it analyses the vulnerabilities of web application security controls.
It identifies security flaws in the application and enumerates
vulnerabilities. It is highly recommended to add mitigation to the
identified threat in this stage. For example, when describing a past
incident involving an exploit of a mail server, lessons learned or
mitigation: lack of thorough testing before implementation and
hardening the server.
Attack/Exploit Enumeration &
Modelling
In this stage, we map out the possible threat landscape and the entire
attack surface of our web application. We then map all potential attack
vectors to the different nodes, identifying exploits and attack paths.
This stage simulates all the enumerated information extracted from all
of the previous steps; this helps determine the extent and probability
of successfully launching the identified vulnerabilities.
Risk Impact Analysis Based on the collective data from the previous stages, the scoped
assets that have been affected are analysed and finally, based upon the
risk analysis, recommended steps to mitigate the risks and eliminate
the residual risks are documented.

Example threat matrices

Often, the objective of threat modelling is to discuss the most relevant and high-priority security risks with mitigations. If it is a very large project, and most of the modules serve similar functions, it may be beneficial to perform the threat modelling with high-risk parts or the one which can mostly represent the business functions.

Pipeline components

Name Tools
Device Developer Workstation: Mac/Win/Linux/Cloud-based
Git Repository Service GitHub, GitLab, Bitbucket, Beanstalk, GitHub, GitLab, SourceForge
CI CI/CD Services like CircleCI, Cloud Build, Codebuild, GitHub Actions,
R2Devops
CD CI/CD Services like CircleCI, Cloud Build, Codebuild, GitHub Actions,
and CD Services like Spinnaker and ArgoCD
Secret Management Secret Management Services like AWS Secret Manager,
GCP Secret Manager, HashiCorp Vault
Production environment Cloud Services (AWS, Azure, GCP) and other resources like
Container Registry, Linux Server, Kubernetes

Recommended modules for threat modelling and code reviewing:

  • Modules with security controls such as authentication, authorisation, session management, encryption, data validation, error handling, or logging, administration, and database handlers.

  • Legacy modules with vulnerable CVE.

  • Modules that may externally interact with unknown users or third-party APIs.

  • Modules that handle sensitive information.

Example threat matrices

DevOps threat matrix (Microsoft)

DevOps threat matrix

Common threat matrix for CI/CD pipeline (Mercari)

Common Threat Matrix for CI/CD Pipeline