Threat Modelling: Methodologies

To follow the series — https://vkfrost.com/tag/threat-modelling/

As Adam Shostack states, “A good threat model is one that produces valid findings.” Threat modelling employs different methodologies to produce useful outcome, These outcome are shaped by factors that vary across different development stages:

• Stage 1: No Previous Security Goals
  At the outset, it’s beneficial to focus on “low-hanging fruits”—quick wins that introduce security fundamentals into regular practices and early design decisions.
• Stage 2: Appoint a Security Champion
  To provide a structured threat modeling approach, appoint an experienced security practitioner who can guide the team toward detailed, actionable results.
• Stage 3: Shared Responsibility for Product Security
  In this stage, security ownership extends to all individuals, fostering a well-documented approach. Multiple teams can identify risks, propose fixes, and communicate openly, embedding security into everyday design thinking.

When selecting a threat modeling framework, it’s essential to consider the following four guiding questions. These questions help determine the most effective approach and methodology for the organization.

To select the most effective methodology, it's also crucial to examine it from various perspectives, including different filters, angles, and lenses. The three primary approaches are:

• System-Centric Approach (Architecture/Design-Centric)
• Attacker-Centric Approach
• Asset-Centric Approach

Threat Modelling Methodologies

STRIDE

An acronym for Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege. This methodology focuses on identifying which systems, assets, or data flows could be vulnerable to specific threats. STRIDE can be applied in two ways:

• STRIDE per Element: Each element of the chosen system model, such as DFDs, is reviewed to identify any potential STRIDE threats that might affect it.
• STRIDE per Interaction: Interactions between elements are examined to determine if any STRIDE threats could emerge from these connections.

PASTA (not 🥘 )

The Process for Attack Simulation and Threat Analysis (PASTA) is a risk-focused methodology designed to identify viable threat patterns targeting applications or systems. This method quantifies risk based on application components, underlying infrastructure, and data related to business operations.

PASTA is heavily reliant on key elements such as assets, threats, weaknesses, system/application use cases, abuse cases, actors, attack vectors, countermeasures, attack surfaces, and attack trees. The process involves several structured stages:

1. Define Business Objectives
   Establish objectives based on business, security, and compliance requirements, as well as business impact analysis and risk profiles.
2. Define Technical Scope/Assets
   Focus on software components, data sources, storage, actors, system-level services, third-party infrastructure, protocols, and asset completeness.
3. Decompose the Application
   Understand application use cases, create data flow diagrams (DFDs) for identified components, and perform security analysis focused on trust boundaries.
4. Perform Threat Analysis
   Assess threat scenarios by gathering threat intelligence from both internal and external sources, updating threat libraries, mapping threat agents to assets, and assigning probabilities to identified threats.
5. Detect Vulnerabilities
   Review and correlate existing vulnerability data, identify weak design patterns, map threats to vulnerabilities, and perform context-driven risk analysis and targeted testing.
6. Enumerate Attacks
   Instead of performing attacks, assess the probability and potential impact of threats based on vulnerability data (e.g., CVEs), define the attack surface, and evaluate attack scenarios through attack trees.
7. Conduct Risk and Impact Analysis
   Analyse the likelihood of each threat being realized, evaluate countermeasures, calculate residual risk, and devise a strategy to manage that residual risk effectively.

TARA (I love tech names)

Threat Assessment and Remediation Analysis is a methodology designed to identify and prioritize attack vectors based on assessed risk, and to select countermeasures that are both cost-effective and impactful. It focuses on the resilience of systems, assessing how they can withstand threats if initial security barriers are breached.

Built under the MITRE ATT&CK framework, TARA's methodology outcomes are expected to include details such as the target TTP (Tactics, Techniques, and Procedures) name, source of reference, plausibility, and rationale.

Key features of TARA include:

• Assessment Flexibility: Enables TARA assessments on deployed systems or those in the acquisition lifecycle.
• Consistent TTP and Countermeasure Catalogs: Maintains stored catalogs of TTPs and countermeasures to ensure consistency across TARA assessments.
• Adjustable Rigor: Allows assessment rigor to be tailored to specific needs or resource levels.
• Quantitative Scoring Model: Provides a default scoring toolset for assessing TTP risk and countermeasure cost-effectiveness based on metrics of Accessibility, Scalability, Educational value, Utility, Agility, Representativeness, and Unconstraint (ASURA).

TRIKE(Not an acronym)

TRIKE is a developer-centric threat modeling framework that shifts the focus from "thinking like a hacker" to a risk management perspective. Unlike traditional approaches, it prioritizes security auditing through a defender's lens, empowering developers to assess risks based on asset protection rather than attacker tactics.

TRIKE incorporates four primary models:

1. Requirements Model: This model creates a comprehensive table of assets, actors, and potential actions—covering all Create, Read, Update, and Delete (CRUD) actions essential to the system's normal functionality.
2. Implementation Model: Focused on both core (supporting) and experimental actions, this stage involves creating Data Flow Diagrams (DFDs) that map out all system actions crossing trust boundaries, providing an exhaustive review of internal workflows.
3. Threat Model: Here, the primary emphasis is on Denial of Service (DoS) and Elevation of Privilege threats. Each identified threat is used to develop attack trees and graphs, illustrating potential attack paths. While TRIKE supports some tool-based automation, many graphs are created manually to ensure thoroughness.
4. Risk Model: Each asset is assigned a risk level, weighted by business value. Actor trust levels range from 1 (highly trusted actor) to 5 (anonymous actor), linking directly to their actions within the system.

LINDUNN (Really though)

Linkability, identifiability, nonrepudiation, detectability, disclosure of information, unawareness, and noncompliance (very long) focuses on privacy threat modelling - Privacy = data. Privacy threat modelling aims to safeguard data by addressing not only external threats but also potential organisational actions that may inadvertently compromise individual privacy. This model incorporates key properties that ensure privacy protection and uphold the rights of data subjects:

1. Unlinkability: Prevents the reliable linking of identities or data points due to limited or fragmented information.
2. Anonymity: Ensures that the identity of individuals cannot be established.
3. Pseudonymity: Allows individuals to use an alternative identifier, reducing direct traceability to their true identity.
4. Plausible Deniability: Enables individuals to deny actions, with no means for others to definitively confirm or refute these actions.
5. Undetectability and Unobservability: Shields the presence of data or actions from detection, protecting individuals from exposure.
6. Content Awareness: Ensures that users understand what information is accessible to the public or third parties.
7. Policy and Consent Compliance: Confirms that the system adheres to privacy policies and consent requirements before data access.

SPARTA (Ow! The SPARTANs)

Security and Privacy Architecture Through Risk-Driven Threat Assessment is a tool that enriches the threat modelling with DFD and enhanced metadata in the following areas;

1. Adding representation of security solutions and the purpose to promote verification of data and consequences.
2. Relationship between security mechanism and consequences is traceable.
3. Security solutions and threat libraries evolve independently from each other.
4. Continuous threat assessment when necessary

INCLUDES NO DIRT (So far information overload)

Bridge gap between security, privacy and compliance and applying the constrcut to the world. This model combines LINDUNN and STRIDE to be used in the healthcare industry. In full the mode is; Identifiability, Nonrepudiation, Clinical Error, Linkability, Unlicensed activity, Denial of service, Elevation of privilege, Spoofing, Noncompliant to policy or obligation, Overuse, Data error, Information Disclosure, Repudiation, Tampering.

Other Quick mentions;

1. DREAD — This is more of a risk assessment model as compared to threat assessment which focuses on analysing the impact of threats to an environment. This was deprecated by Microsoft in 2008
2. OCTAVE — similar to DREAD, is a risk based strategy that helps organizations identify and prioritize risks based on their operational requirements. 
3. VAST — to replace the old methodologies? is a recent model implemented in the Devsecops pipeline to ensure threat modelling is a continous process. Visual, Agile and Simple threat is lightweight and efficient which integrates into the SDLC lifecyle.

Resources;

• https://linddun.org/ — LINDUNN privacy threat modelling
• https://youtu.be/ApKk8-aqiHM — TRIKE implementation
• https://shostack.org — Anything threat modelling
• https://www.hackerone.com/knowledge-center/threat-modeling-process-frameworks-and-tools 
• https://threatmodel.buzzsprout.com/2152378/episodes — Enjoy Podcasts
• https://owasp.org/www-community/Threat_Modeling_Process
• Threat Modeling: A Practical Guide for Development Teams 1st Edition — Book