Threat Modeling With STRIDE and PASTA

Why Threat Modeling Matters

Threat modeling is one of the highest-value activities in the entire secure software development lifecycle (SDLC). The CSSLP places it squarely in Domain 3: Secure Software Architecture and Design because this is the phase where it delivers the biggest return. The cost of fixing a security flaw grows dramatically the later it is discovered: a design flaw found during threat modeling costs almost nothing to correct, while the same flaw discovered in production can cost 30 to 100 times more, plus the reputational and regulatory damage of a breach.

Threat modeling forces the team to answer four deceptively simple questions:
1. What are we building?
2. What can go wrong?
3. What are we going to do about it?
4. Did we do a good enough job?

Because it is a proactive rather than reactive control, threat modeling supports the CSSLP principles of defense in depth, least privilege, secure by design, and risk-based decision making. It also produces artifacts (data flow diagrams, threat lists, mitigation plans) that feed directly into security requirements, secure coding standards, test cases, and penetration test scopes. From an exam perspective, you must understand both when threat modeling occurs and what frameworks are used to perform it, with STRIDE and PASTA being the two the CSSLP emphasizes most.

What Threat Modeling Is

Threat modeling is a structured, repeatable process for identifying, enumerating, and prioritizing potential threats to a system so that appropriate countermeasures can be designed before code is written. It is performed primarily during the architecture and design phase, although it should be revisited whenever the architecture changes, new features are added, or new threat intelligence emerges. Think of it as a living document, not a one-time deliverable.

Core inputs to any threat model include:
- Assets: what is valuable and needs protection (data, credentials, availability, reputation).
- Entry points: where an attacker can interact with the system (APIs, UI forms, file uploads, message queues).
- Trust boundaries: the lines where the level of trust changes, such as between the internet and the web tier, or between an application and its database. Most threats cluster at trust boundaries.
- Data Flow Diagrams (DFDs): the standard visual language of threat modeling, using external entities (rectangles), processes (circles), data stores (parallel lines), data flows (arrows), and trust boundaries (dashed lines).
- Use cases and misuse/abuse cases: how the system is supposed to be used, and how an attacker might misuse it.

Threat modeling approaches are generally categorized as asset-centric (start with what is valuable), attacker-centric (start with who wants to attack and their capabilities), or software/system-centric (start with the architecture and decompose it). STRIDE is software-centric; PASTA is risk-centric and attacker-centric. Knowing these distinctions is a frequent exam point.

STRIDE: The Microsoft Threat Classification Model

STRIDE was developed at Microsoft by Loren Kohnfelder and Praerit Garg in 1999 and is the most widely taught threat categorization scheme. It is a mnemonic that helps teams systematically ask what can go wrong with each element of a DFD. Each letter maps to a threat category and, critically, to the security property it violates. Memorizing this mapping is essential.

S - Spoofing
Violates: Authentication
Definition: Pretending to be someone or something you are not, such as a user, a process, a server, or a device.
Examples: Credential theft, session hijacking, DNS spoofing, phishing, forged certificates.
Mitigations: Strong authentication, multi-factor authentication, digital certificates, mutual TLS, secure session management, Kerberos.

T - Tampering
Violates: Integrity
Definition: Unauthorized modification of data in transit, at rest, or in memory.
Examples: Modifying parameters in a URL, altering database records, man-in-the-middle changes to network packets, binary patching.
Mitigations: Hashing, digital signatures, message authentication codes (HMAC), access control lists, input validation, TLS, file integrity monitoring.

R - Repudiation
Violates: Non-repudiation (sometimes stated as accountability or auditing)
Definition: A user denies performing an action and the system cannot prove otherwise.
Examples: A customer denies placing an order, an administrator denies deleting records, logs are missing or can be altered.
Mitigations: Secure audit logging, digital signatures, timestamps, tamper-evident logs, centralized log management, strong authentication tied to logged actions.

I - Information Disclosure
Violates: Confidentiality
Definition: Exposing information to individuals who are not authorized to see it.
Examples: Verbose error messages revealing stack traces, directory traversal, unencrypted data in transit, sensitive data in logs, side-channel leakage.
Mitigations: Encryption at rest and in transit, access control, data classification, generic error handling, data masking, least privilege.

D - Denial of Service
Violates: Availability
Definition: Making a system or resource unavailable to legitimate users.
Examples: Resource exhaustion, SYN floods, algorithmic complexity attacks, locking out accounts, filling disk space with logs.
Mitigations: Rate limiting, throttling, input size limits, resource quotas, redundancy, load balancing, graceful degradation, failing securely.

E - Elevation of Privilege
Violates: Authorization
Definition: A user or process gains capabilities beyond what they are entitled to.
Examples: Buffer overflow leading to code execution as root, insecure direct object references, exploiting a misconfigured sudo rule, horizontal or vertical privilege escalation.
Mitigations: Least privilege, role-based access control, input validation, sandboxing, privilege separation, complete mediation, secure defaults.

How STRIDE Is Applied

There are two common variants. STRIDE-per-element examines each DFD element and applies only the threat categories relevant to that element type. For example, external entities are typically subject to Spoofing and Repudiation; data stores to Tampering, Information Disclosure, Denial of Service, and sometimes Repudiation (if they hold logs); data flows to Tampering, Information Disclosure, and Denial of Service; and processes to all six. STRIDE-per-interaction examines each data flow crossing a trust boundary and asks all six questions about the interaction. Microsoft provides a free Threat Modeling Tool that automates much of this analysis from a DFD.

A key limitation of STRIDE is that it identifies and categorizes threats but does not rank them. For prioritization, STRIDE is commonly paired with DREAD (Damage, Reproducibility, Exploitability, Affected users, Discoverability), which scores each threat typically from 1 to 10 per factor, or with CVSS, or with a simple likelihood-times-impact matrix. Note that Microsoft itself retired DREAD because of its subjectivity, but it still appears on exams as a classic risk-rating companion to STRIDE.

PASTA: Process for Attack Simulation and Threat Analysis

PASTA was created by Tony UcedaVelez and Marco Morana and published in 2015. Unlike STRIDE, which is a classification taxonomy, PASTA is a complete seven-stage, risk-centric methodology that aligns business objectives with technical requirements and places threats in the context of actual business impact. It is attacker-centric in that it explicitly simulates how real adversaries would attack the application, and it is designed to produce output that executives and risk managers can act on, not just developers. The seven stages are:

Stage 1 - Define the Objectives
Identify business objectives, security and compliance requirements (PCI DSS, HIPAA, GDPR), and perform a preliminary business impact analysis. The question here is: what does the business need this application to do, and what would it cost if it failed?

Stage 2 - Define the Technical Scope
Enumerate the technical environment: application components, infrastructure, network, third-party services, dependencies, and the attack surface. Understand the boundaries of what is being analyzed.

Stage 3 - Application Decomposition
Build data flow diagrams, identify trust boundaries, entry points, actors, assets, roles, and use cases. This is where the architecture is broken down into analyzable pieces, similar to the DFD step in STRIDE.

Stage 4 - Threat Analysis
Analyze threat intelligence, attack scenarios, and threat agents relevant to this specific application and industry. Incorporate logs, incident data, and external threat feeds. Build a threat library and probabilistic analysis of likely attacks.

Stage 5 - Vulnerability and Weakness Analysis
Correlate identified threats with existing vulnerabilities and design weaknesses. Map to CWE and CVE, review scan results, and identify which weaknesses the threats from Stage 4 could actually exploit.

Stage 6 - Attack Modeling
Simulate attacks using attack trees and attack scenarios. Model how an attacker would chain weaknesses to achieve objectives. This is the attack simulation that gives PASTA its name and distinguishes it from purely theoretical analysis.

Stage 7 - Risk and Impact Analysis
Quantify residual risk, determine business impact, and develop countermeasures prioritized by risk. Produce recommendations that connect each mitigation to a business justification.

A helpful mnemonic for the seven stages is Define Objectives, Define Technical scope, Decompose, Threats, Vulnerabilities, Attacks, Risk, or simply remember that PASTA moves from business context at the top, through technical decomposition in the middle, to attack simulation and risk quantification at the end.

Comparing STRIDE and PASTA

Understanding how these two approaches differ is a prime exam target.

- Nature: STRIDE is a threat classification taxonomy or mnemonic. PASTA is a full end-to-end methodology.
- Focus: STRIDE is software-centric and developer-focused. PASTA is risk-centric and attacker-centric, bridging business and technical stakeholders.
- Prioritization: STRIDE does not prioritize on its own and needs DREAD, CVSS, or another scheme. PASTA builds risk and impact analysis into Stage 7.
- Business alignment: STRIDE is largely silent on business objectives. PASTA begins with them in Stage 1.
- Complexity and effort: STRIDE is lightweight and fast to learn; it fits agile sprints well. PASTA is heavier, more thorough, and better suited to high-risk or regulated applications.
- Attack simulation: STRIDE categorizes threats theoretically. PASTA explicitly simulates attacks with attack trees in Stage 6.
- Compatibility: They are not mutually exclusive. STRIDE is often used inside PASTA Stage 4 to enumerate threat categories during decomposition.

Other Frameworks You Should Recognize

The exam may present distractors, so be able to distinguish these:
- DREAD: a risk rating scheme, not a threat identification method.
- Trike: an open-source, requirements-based, risk-management-focused methodology using a defensive perspective and acceptable-risk definitions by stakeholders.
- VAST (Visual, Agile, Simple Threat modeling): designed to scale across large enterprises and integrate with agile and DevOps, using application and operational threat models.
- OCTAVE: an organizational, asset-driven risk assessment methodology from Carnegie Mellon, more about enterprise risk than application design.
- LINDDUN: a privacy-focused threat model (Linkability, Identifiability, Non-repudiation, Detectability, Disclosure of information, Unawareness, Non-compliance).
- Attack trees: hierarchical diagrams with the attacker goal as the root and sub-goals and methods as branches; used in PASTA Stage 6 and as a standalone technique.
- MITRE ATT&CK: a knowledge base of adversary tactics and techniques, frequently used as threat intelligence input to PASTA Stage 4.

How Threat Modeling Fits the SDLC

In the CSSLP view, threat modeling outputs feed forward and backward:
- Backward into requirements: each identified threat should map to a security requirement or an accepted risk.
- Forward into implementation: mitigations become secure coding tasks and architectural patterns.
- Forward into testing: each threat becomes a security test case or abuse case; threat models define penetration test scope.
- Forward into deployment and operations: residual risks inform monitoring, logging, and incident response planning.

Threat models should be revisited when there is a significant architectural change, a new integration, a new deployment environment, a major vulnerability disclosure affecting a component, or at regular intervals as part of the security review cadence.

Exam Tips: Answering Questions on Threat Modeling With STRIDE and PASTA

Tip 1 - Lock in the STRIDE-to-property mapping. The single most common question type gives you a scenario and asks which STRIDE category it represents, or asks which security property is violated. Spoofing = Authentication, Tampering = Integrity, Repudiation = Non-repudiation, Information Disclosure = Confidentiality, Denial of Service = Availability, Elevation of Privilege = Authorization. If a question says an attacker modified something, it is Tampering. If a user denies doing something, it is Repudiation. If an attacker gained admin rights, it is Elevation of Privilege. Do not confuse Spoofing (pretending to be someone) with Elevation of Privilege (gaining more rights than you have).

Tip 2 - Know the phase. If asked when threat modeling should be performed, the best answer is during architecture and design, as early as possible. If the options include design and testing, choose design. If the question asks when it should be updated, the answer is whenever the architecture or threat landscape changes, meaning it is iterative and continuous, not one-time.

Tip 3 - Distinguish taxonomy from methodology. If a question describes a mnemonic for categorizing threats, that is STRIDE. If it describes a seven-stage, risk-centric process that aligns business objectives with technical requirements and simulates attacks, that is PASTA. If it describes rating or scoring threats, that is DREAD or CVSS, not STRIDE.

Tip 4 - Watch for the keyword business. Any question emphasizing business impact, business objectives, executive stakeholders, compliance drivers, or risk quantification is pointing toward PASTA. STRIDE does not address business context.

Tip 5 - Remember what STRIDE lacks. If a question asks about a limitation of STRIDE, the answer is that it does not prioritize or rank threats and must be combined with a risk-rating method. If asked what to pair with STRIDE for prioritization, DREAD is the classic answer.

Tip 6 - Memorize the PASTA stage order. Questions may ask which stage comes first, which stage involves attack trees, or which stage produces DFDs. Stage 1 is objectives, Stage 3 is decomposition (DFDs), Stage 6 is attack modeling (attack trees), Stage 7 is risk and impact. If asked where threat intelligence is consumed, that is Stage 4.

Tip 7 - Trust boundaries are where threats live. If a question asks where to focus threat modeling effort in a DFD, the answer involves data flows that cross trust boundaries. Entry points and trust boundaries are the highest-yield areas.

Tip 8 - Identify the centricity. Asset-centric starts with what is valuable, attacker-centric starts with adversary goals and capabilities, software-centric starts with the system design. STRIDE is software-centric. PASTA is attacker-centric and risk-centric. OCTAVE is asset-centric.

Tip 9 - Choose the best mitigation by property. When asked how to mitigate a STRIDE threat, align the control to the violated property: authentication controls for Spoofing, integrity controls like hashes and signatures for Tampering, logging and signatures for Repudiation, encryption and access control for Information Disclosure, rate limiting and redundancy for Denial of Service, least privilege and RBAC for Elevation of Privilege. Eliminate any answer that addresses a different property.

Tip 10 - Apply the CSSLP mindset. The CSSLP favors answers that are proactive, risk-based, integrated into the SDLC, and that involve the right stakeholders. If two answers seem correct, prefer the one that happens earlier in the lifecycle, that is repeatable and documented, and that ties security decisions to risk rather than to gut feeling. Avoid answers that treat threat modeling as a one-time checkbox or that push it to the testing phase.

Tip 11 - Read for exact wording. Questions often hinge on words like best, first, most, or primary. If asked for the first step of threat modeling in general, it is understanding and decomposing the application (identify assets, build the DFD). If asked for the first stage of PASTA specifically, it is defining business objectives. Do not mix the generic process with the PASTA-specific order.

Tip 12 - Eliminate distractors by domain. If an option names OCTAVE or NIST RMF in a question about application design-level threat identification, it is likely a distractor because those are organizational risk frameworks. If an option names LINDDUN in a question about security rather than privacy threats, it is likely a distractor. Narrow to the frameworks that operate at the software design level.

Practice Scenario Walkthroughs

Scenario A: A developer notes that the application returns detailed SQL error messages to users when a query fails. Which STRIDE category does this represent? Think: detailed errors expose internal information, which violates confidentiality. Answer: Information Disclosure.

Scenario B: An organization wants a threat modeling approach that starts with regulatory compliance drivers and ends with quantified residual risk that can be presented to the board. Which framework fits best? Think: business objectives, compliance, quantified risk. Answer: PASTA.

Scenario C: A team has used STRIDE to list 40 threats and now needs to decide which to fix in the current sprint. What should they use? Think: STRIDE identifies but does not rank. Answer: a risk rating method such as DREAD.

Scenario D: An audit log can be edited by the same service account that writes to it. Which STRIDE threat is most directly enabled? Think: if logs can be altered, users can deny actions and the system cannot prove otherwise. Answer: Repudiation (with Tampering as the enabling mechanism; pick the one the question emphasizes).

Scenario E: In which PASTA stage would a team construct attack trees to simulate how an adversary might chain vulnerabilities? Answer: Stage 6, Attack Modeling.

Final Summary

Threat modeling is the design-phase discipline that turns security from an afterthought into an architectural input. STRIDE gives you a fast, memorable way to enumerate what can go wrong by mapping six threat categories to six security properties. PASTA gives you a rigorous, business-aligned, seven-stage methodology that simulates real attacks and quantifies risk. For the CSSLP, master the STRIDE property mapping, the PASTA stage sequence, the differences in scope and centricity between the two, the role of DFDs and trust boundaries, and the companion rating schemes like DREAD. Approach every exam question by first identifying what is being asked (identify, classify, prioritize, or mitigate), then matching it to the framework or control that addresses that exact need.