Threat modelling is a cost-effective, simple way to ensure that cybersecurity doesn’t become a secondary consideration in the SDLC. This article provides an introduction to threat modeling, as well as the benefits of early detection and removal of flaws. Read on to learn how threat modeling works and see what your business stands to gain from adopting this proactive practice.

What is Threat Modelling?

Threat modeling is the practice of systematically identifying and addressing flaws within an IT asset before someone gets a chance to exploit the vulnerability. This procedure uses a variety of techniques, including brainstorming sessions, hypothetical situations, flow charts, and diagrams. and requires input from both business and technical stakeholders.

A “threat” is a broad term that stands for someone or something that tries to perform one (or more) of the following:

Compromise or alter critical business functions.

Steal data or compromise its integrity.

  • Destroy business systems.
  • Use a system as an attack platform (e.g., turning a device into a DDoS bot).
  • Every threat modeling process has the following objectives:
  • Get a clear picture of the asset in question (database, network, business process, infrastructure, etc.

Determine security, business, and technical requirements.

  • Pinpoint all probable risks and threats.
  • Analyze the nature of each threat, its likelihood, and the danger it poses to the asset.
  • Specify threat actors, their motives, and TTP (tools, techniques, and procedures).
  • Determine threat criticality (which helps prioritize remediation).
  • Assess the company’s current readiness to respond to each threat.
  • Suggest optimal fixes and improvements.

Analysts store these findings in a threat model, a “living” document that requires regular reviews and updates. Creating threat models and keeping them up to date requires a cross-team effort that involves inputs from:

  • Business stakeholders.
  • Project managers.
  • Security architects.
  • The operations/infrastructure team.
  • Software developers.
  • Ideally, threat modeling occurs during the design stage of a new app or feature. A team can build a model from three different perspectives:
  • Asset-centric (take stock of valuable assets and analyze their vulnerabilities).
  • Attacker-centric (take on the role of an attacker and see how a would-be hacker might try to compromise an asset).
  • Software-centric (focus on system design and look for flaws on an architectural level).
  • Large companies and enterprises are not the only ones that should invest in threat models. Criminals prefer going after targets they presume have fewer cybersecurity measures, which makes SMBs prime candidates for threat modeling adoption.Threat Modelling Benefits for DevOps Security

Introducing threat modeling into a DevOps culture provides the following benefits:

The team “injects” security by design principles into the system architecture.

You cut down on the number of bugs and exploits that end up in production.

  • The team adopts a proactive approach to security that does not wait for something to go wrong before intervention.
  • Threat models raise security awareness on a company-wide level due to the multi-team approach to security planning.
  • You improve security posture at every stage of the DevOps pipeline.
  • The company gets an in-depth overview of every mission-critical and valuable IT asset, plus a deep understanding of network security and app architecture.
  • The team no longer makes security-related decisions based on a hunch or without supporting evidence.
  • Security experts become ready both for external and insider threats.
  • You improve the chance of discovering risks that fly under the radar of standard code reviews.
  • The company reduces remediation costs since every threat model includes in-depth incident response plans.
  • The testing costs go down as code leaves development with more quality.
  • The team lowers the number of typical omissions (failing to validate input, weak authentication, inadequate error handling, failing to encrypt data, etc. ).
  • In-depth threat prioritization helps better allocate people and budget resources.
  • The business ensures more reliable compliance with industry-specific regulations.
  • The security team and its defenses stay up to date with the latest cybersecurity best practices and types of cyber attacks.
  • Threat modeling is a natural part of any security-first IT strategy, which makes the practice an essential aspect of both SecOps and DevSecOps teams.
  • Threat Modelling Process: How to Make a Threat Model

Here’s a step-by-step look at how to create a threat model:

Basic threat modeling workflow

Set the scope:

Decide what asset requires threat modeling (an app, service, intellectual property, etc.) and narrow the focus to a specific system.

  • Initial evaluation: Create an inventory of the asset’s components. Map the architecture and create high-level data flow diagrams to analyze the asset’s role in the company.
  • In-depth asset analysis: The team requires a deep understanding of every event or action that takes place in the system. How is the asset used by the company? What makes it an attractive target? What is the system’s interaction with other systems and users? What are the system’s entry and exit points? Who has access to the asset? Who has access to the asset?
  • Determine likely threats: This step requires the team to list as many potential threats to the asset as possible.
  • Analyze each danger: Analysts create step-by-step scenarios that outline exactly how each threat would unfold (e.g., ransomware attack, data exfiltration, SQL injection, etc. Create a threat rating:
  • This is where the team decides what level of threat each threat represents. The most common method is to multiply the damage potential of a threat by the probability of the incident occurring.Suggest mitigations:
  • The team now decides the best course of action to deal with each threat. A mitigation plan will either eliminate the threat or reduce the risk to a level that is acceptable. Document results: Document the findings and present them to a decision maker. The threat modeling team must periodically review the model to determine if it needs an update. Good times for review are when an asset goes through a massive change or when a new strategy emerges on the cybercrime landscape.
  • One of the key metrics of every threat model is the work factor. The work factor is a measure of how much effort an attacker will need to put in order to compromise a particular system. The higher the work factor, the more likely the criminal will move on to an easier target.

Threat Modeling Methodologies

Let’s look at the ten threat modeling frameworks companies use to boost cybersecurity. Every framework focuses on one aspect of threat modeling, so remember that a well-rounded analysis requires a combined use of multiple methodologies we discuss below.

STRIDE

Developed by Microsoft in the late 1990s, STRIDE helps analyze all potential threats within a system. The team must first decompose an app to identify system entities, events, and boundaries before evaluating each component’s proneness to the following threats:

Spoofing Authentication When someone assumes a false identity
T Tempering with data Integrity Unauthorized modification of data
R Repudiation Non-repudiation An intruder’s ability to deny malicious activity due to a lack of evidence
I Information disclosure Confidentiality Providing access to data to someone who has no authorization
D Denial of service Availability Exhausting resources needed to provide service to users
E Elevation of privilege Authorization The execution of commands or functions beyond the jurisdiction of account privileges
STRIDE is among the most mature threat-modeling methods on the market. The framework evolved to include several new threat-specific tables (most notably STRIDE-per-Element and STRIDE-per-Interaction). PASTA PASTA (Process for Attack Simulation and Threat Analysis) is a risk-centric framework that aims to align security requirements with business objectives. This framework involves a seven-step analysis: Define objectives.

Set the technical scope.

Perform app decomposition.

Analyze possible threats.

  • Identify vulnerabilities and flaws.
  • Create attack models.
  • Perform risk and impact analysis.
  • The PASTA framework also includes documentation for dynamic threat identification, enumeration, and a scoring process.
  • Attack Trees
  • Attack trees are among the oldest and most widely applied techniques for threat modeling. This framework works in the following manner:
  • Each root node represents an attacker’s goal (e.g., cause data leakage or hijack an email address).

Each leaf node denotes the possible means of reaching the attacker’s goal (these often include “AND” and “OR” conditions).

PASTA threat modeling

Analysts associate each node with a vulnerability score and potential impact.

Attack trees are a simple method ideal for high-level threat modeling and teams comfortable with brainstorming sessions.

  • CVSS
  • The Common Vulnerability Scoring System (CVSS) is a risk estimation framework that provides a standardized scoring system for vulnerabilities. An analyst assigns a severity score (ranging from 0 to 10) to each threat based on the three broad metric groups:

Base (includes exploitability metrics (vectors, attack complexity, required privileges, user interactions, etc.) Impact metrics (the impact on availability, data security, etc.) and exploitability metrics (

  • Temporal (exploit code maturity, remediation level, etc. ).
  • Environmental (base metrics such as requirements for confidentiality or availability).
  • Once all flaws have a numerical score and a category, the team assigns a qualitative representation (low, medium, high, and critical) and begins prioritizing mitigation tasks.The combined use of CVSS, STRIDE, and attack trees is known as the

Quantitative Threat Modeling Method

.Security CardsSecurity cards are the go-to option for teams trying to identify new attack vectors. This brainstorming technique requires the use of a specialized deck of 42 cards that represent threat-related activities, including:

Attacker motivations (13 cards).

Human impact (9 cards).

  • Hacker resources (11 cards).
  • Adversary’s methods (9 cards).
  • Each card contains a topic, questions to jump-start thinking, and a few examples. Team members take out two or more cards and discuss whether the random combos might pose a realistic attack scenario.
  • Security cards are excellent for identifying out-of-the-box strategies that generally fly under the radar with regular threat modeling.

OCTAVE

OCTAVE (Operationally Critical Threat, Asset, and Vulnerability Evaluation) is a risk-based assessment with three broad phases:

Create asset-based threat profiles.

Identify and evaluate infrastructure vulnerabilities.

  • Develop an appropriate security plan for each discovered risk.
  • This framework focuses solely on assessing organizational risks, so the framework does not consider or address technological risks.
  • Persona non Grata

Persona non Grata (PnG) is the ultimate attacker-centric threat modeling. PnG enables a team to develop a detailed picture of a hypothetical attacker, including their:

OCTAVE

Psychology.

Motivations.

  • Goals.
  • Capabilities.
  • Go-to tools and techniques.
  • Thinking processes during an attack.
  • PnG helps get into the mindset of a potential intruder, which is vital to the early stages of threat modeling. Also, when you combine PnG with Security Cards and SQUARE (Security Quality Requirements Engineering Method), you get the
  • Hybrid Threat Modeling Method (hTMM)

TRIKE

TRIKE is a security audit that looks at threat modeling from a risk-management perspective. This framework relies on a defensive viewpoint rather than trying to understand the mindset of a potential attacker.

TRIKE starts with a matrix chart that summarizes the relationships between actors, actions, and assets. The rows and columns are actors, while the columns represent assets. Each cell is divided into four sections, one for every action in CRUD: creating, reading, updating and deleting. Analysts assign one of three values in each action cell:

Allowed action.

Disallowed action.

  • Allowed with rules.
  • The team uses the matrix to build a data flow diagram (DFD) to map each element to actors and assets. The goal is to assign each actor a score based on risk level (from 0 to 5) for each action or asset interaction.
  • VAST

VAST (Visual, Agile, and Simple Threat) is a type of threat modeling that focuses on development and infrastructure safety. The framework requires a team to analyze two model types:

App threat models (process-flow charts that analyze threats that come from interacting with users and other systems).

  • Operational threat models (data-flow diagrams that analyze an app from an infrastructure point of view).
  • VAST is a popular choice for DevOps and agile teams due to the framework’s highly scalable nature.

DREAD

DREAD is a quantitative risk analysis that rates, compares, and prioritizes threats based on severity. Initially developed as an add-on for the STRIDE model, DREAD stands for six questions the analyst asks about each potential threat:

Damage potential:

How great is the damage if an attacker exploits a vulnerability?

  • Reproducibility: How easy is it to reproduce the attack?
  • Exploitability: How hard is it to start an attack?
  • Affected users: How many users would feel the effects of an attack?
  • Discoverability: How easy is it to discover the threat?
  • The threat modeling team answers these questions and assigns a rating between one and three. The sum total represents the severity level of a threat.Unsure whether threat modeling resulted in a safer system? Consider running a few pen tests–penetration testing is a form of ethical hacking in which you perform simulations of real-life attacks to check the system’s readiness for breach attempts.

Threat Modeling Tools

While a team can perform basic threat modeling on a sheet of paper, larger companies with a high count of vulnerabilities should use software to simplify the process.

Threat modeling best practices

Tools reduce the complexity of threat modeling and let a team visualize, design, plan for, and predict different types of potential dangers. Some of the best tools offer remediation suggestions. Here are a few worthwhile options:

Microsoft Threat Modeling Tool (MTTM):

This free-to-use software focuses on detecting threats and flaws during the design phase of software projects. The tool aligns with various Microsoft services and follows the STRIDE methodology.

  • Cairis: This open-source, web-based tool enables users to elicit, describe, and evaluate system risk. Cairis has some of the most comprehensive features among threat modeling tools. (Attacker personas and in-depth breakdowns of attacks, pattern analysis, recommendations for mitigation, etc.) )
  • OWASP: This open-source tool (which runs as a web or a desktop app) produces threat model diagrams that align with the development lifecycle. OWASP offers similar features to MTTM but with less focus on Microsoft-centered services.
  • ThreatModeler: This automation-driven tool enables users to make proactive security decisions and reduce risk across a broad attack surface. ThreatModeler supports several regulatory standards, including GDPR and PCI.
  • IriusRisk: This diagram-centric system asks analysts questions about the system and uses the info to create a list of potential threats and suggested mitigation strategies.
  • As with methodologies, you can use more than one threat modeling tool. You get the most robust and insightful analysis by relying on several platforms for gathering, visualizing, and organizing threat-related info.
  • Take a Proactive Stance Against Cybercrime Being stuck in a reactive security cycle is a recipe for operational and financial disaster. A simple calculation shows that threat modeling is a better alternative.

About The Author

By omurix

XIII. Unidentified Society

Leave a Reply

Your email address will not be published. Required fields are marked *

%d