Threat Modeling Methodologies

What the Exam Is Really Testing

Most organizations skip threat modeling entirely. They build systems, deploy them, and then act surprised when an attacker finds a path nobody considered. The post-breach investigation reveals what structured threat modeling would have shown months earlier — for a fraction of the cost.

CISSP tests whether you understand that threat modeling is a proactive, structured process that belongs early in design — not a reactive exercise performed after something breaks.

The exam wants you to know:

• Which methodology fits which context
• What each framework actually produces
• Where threat modeling fits in the development lifecycle
• How to identify threat agents and their attack vectors

STRIDE: The Microsoft Standard

STRIDE was developed at Microsoft and remains the most widely referenced threat modeling framework on the CISSP exam. Each letter maps to a specific security property violation:

• Spoofing → violates Authentication
• Tampering → violates Integrity
• Repudiation → violates Non-repudiation
• Information Disclosure → violates Confidentiality
• Denial of Service → violates Availability
• Elevation of Privilege → violates Authorization

This mapping matters. When a scenario describes an attacker gaining unauthorized admin access, that is Elevation of Privilege — an Authorization failure. When data is exposed during transit, that is Information Disclosure — a Confidentiality failure.

STRIDE works by decomposing a system into components (using data flow diagrams), then systematically evaluating each component against all six threat categories. It is developer-oriented and integrates naturally into the SDLC.

PASTA, VAST, and DREAD

PASTA (Process for Attack Simulation and Threat Analysis)

PASTA is a seven-stage, risk-centric methodology. Unlike STRIDE, which focuses on threat categories, PASTA works backward from business impact. It asks: what are the business objectives, what are the application components, and what attack scenarios would damage those objectives?

The seven stages move from defining objectives through technical scope, decomposition, threat analysis, vulnerability analysis, attack modeling, and finally risk and impact analysis. PASTA is the answer when a question asks about aligning threat modeling with business risk.

VAST (Visual, Agile, and Simple Threat)

VAST was designed for Agile and DevOps environments. It creates two types of models: application threat models (for developers) and operational threat models (for infrastructure teams). VAST scales across large organizations because it integrates into automated CI/CD pipelines rather than requiring dedicated workshops.

When a scenario describes a fast-moving development team that needs threat modeling without slowing sprints, VAST is the likely answer.

DREAD (Damage, Reproducibility, Exploitability, Affected Users, Discoverability)

DREAD is a risk rating model, not a full methodology. It scores each threat on five dimensions to produce a priority ranking. Microsoft originally used DREAD but later moved away from it due to subjectivity in scoring. The exam may reference it as a prioritization tool, but DREAD alone does not constitute a complete threat modeling process.

Attack Trees and Threat Agents

Attack trees visualize the paths an attacker could take to reach an objective. The root node is the attacker's goal (e.g., "steal customer data"). Each branch represents a different method, and sub-branches represent the prerequisite steps.

Attack trees are useful because they force you to think like an attacker. They also make it visible when multiple weak controls compound into a viable attack path that no single control assessment would reveal.

Threat agents are the actors behind the attacks. Identifying them matters because different agents have different capabilities, motivations, and resources:

• Nation-state actors — high capability, persistent, strategic targets
• Organized crime — financially motivated, opportunistic but capable
• Insiders — already have access, difficult to detect
• Hacktivists — ideologically motivated, variable capability
• Script kiddies — low capability, use available tools

The countermeasures you select should reflect the threat agent you are defending against. Building defenses against script kiddies when your actual threat is a nation-state is a misallocation of resources.

When Threat Modeling Happens

This is the point the exam returns to repeatedly: threat modeling belongs in the design phase of the SDLC. Not after development. Not after deployment. Not after the first penetration test finds what you missed.

The logic is straightforward. Fixing a design flaw in the design phase costs a fraction of fixing it in production. Threat modeling during design lets you:

• Identify trust boundaries before they are coded
• Evaluate data flows before they are deployed
• Select countermeasures before they become retrofits
• Document accepted risks before they become surprises

Organizations that defer threat modeling to post-deployment are not modeling threats. They are performing damage assessment.

Pattern Recognition

When you see these patterns in CISSP questions:

• "Categorize threats by type" → STRIDE
• "Align threat analysis with business objectives" → PASTA
• "Scale threat modeling across Agile teams" → VAST
• "Prioritize threats by risk score" → DREAD
• "Visualize attacker paths to an objective" → Attack trees
• "When should this happen?" → Design phase of the SDLC

The exam does not expect you to execute a full threat model. It expects you to select the right approach for the given context and know where it fits in the process.

Trap Patterns

Watch for these in answer choices:

• "Perform threat modeling after deployment to validate controls" — wrong. Threat modeling is a design activity, not a validation exercise.
• "Use DREAD as your complete threat modeling methodology" — wrong. DREAD is a scoring model, not a full methodology.
• "STRIDE identifies vulnerabilities" — wrong. STRIDE identifies threat categories. Vulnerabilities are identified through separate analysis.
• "Threat modeling replaces penetration testing" — wrong. They serve different purposes at different stages. Threat modeling is proactive design analysis; penetration testing is active validation.

Scenario Practice

Question 1

A development team is designing a new web application that handles financial transactions. The security architect wants to systematically identify threats against each component of the system.

Which threat modeling methodology is MOST appropriate?

A. DREAD
B. PASTA
C. STRIDE
D. VAST

Question 2

An organization wants to ensure its threat modeling process directly connects identified threats to potential business impact and strategic objectives.

Which approach BEST supports this requirement?

A. Attack trees
B. STRIDE
C. DREAD
D. PASTA

Question 3

A security team completed a full threat model for an application after it was deployed to production. Several significant design flaws were identified that would require re-architecting core components.

What was the PRIMARY failure in this process?

A. The team used the wrong methodology
B. Threat modeling was performed too late in the SDLC
C. The team did not use attack trees
D. Penetration testing should have been used instead

Key Takeaway

Threat modeling is not a technical exercise you hand off to a penetration testing team. It is a structured design activity that asks: what can go wrong, and what are we doing about it before we build?

For the CISSP exam, remember three things:

1. STRIDE maps threats to security properties — know the six pairings.
2. Threat modeling happens during design, not after deployment.
3. Different methodologies serve different purposes — match the method to the context.