Advanced Security #STRIDE #threat-modelling #PASTA #DREAD

Threat Modeling

5 exercises — master threat modelling vocabulary: STRIDE threat classification, DREAD vs CVSS risk rating, PASTA methodology, threat actor profile definition, and building a mature threat modelling programme.

0 / 5 completed

Threat modelling quick reference

STRIDE — Spoofing / Tampering / Repudiation / Information disclosure / DoS / Elevation of privilege. Applied to each element of a DFD.
DREAD — Damage / Reproducibility / Exploitability / Affected users / Discoverability. Simple 1-10 relative scoring for internal prioritisation.
CVSS — Common Vulnerability Scoring System; standardised 0-10 score. Use for published CVEs and external reports.
PASTA — 7-stage, business-risk-centric methodology: Objectives → Scope → Decompose → Threats → Vulnerabilities → Attack simulation → Risk analysis.
Threat actor profile — defines attacker identity, motivation, starting access, skill level. Must be set before scoping decisions are made.
Shift-left — threat modelling at design time, not after implementation. Security champions own it in the dev team.
Living threat model — updated with each significant change; linked to tickets; reviewed regularly.

1 / 5

A security lead introduces threat modelling to the team: "We're going to use STRIDE to analyse the new API gateway. Can someone walk through what each letter stands for and how we apply it?"

STRIDE — the universal threat classification framework for threat modelling sessions across any system type.

STRIDE categories with examples:

Letter	Threat	Violated property	API gateway example
S	Spoofing	Authentication	Forged JWT token passes API gateway auth
T	Tampering	Integrity	Man-in-the-middle modifies request payload
R	Repudiation	Non-repudiation	No audit log — user denies making API call
I	Information disclosure	Confidentiality	Stack trace in 500 error reveals internal paths
D	Denial of Service	Availability	Expensive query floods backend, exhausts DB pool
E	Elevation of privilege	Authorisation	IDOR bug: user accesses another user's resources

STRIDE application process (on a DFD):
1. Draw a Data Flow Diagram (DFD) showing processes, data stores, external entities, data flows, and trust boundaries
2. For each element, systematically apply each STRIDE category: "Can an attacker spoof this? Tamper with this?..."
3. Log each threat found: what is it, how can it be exploited, what's the impact
4. Rate severity (DREAD, CVSS, or simple H/M/L)
5. Assign mitigations: what control prevents or detects this threat?

STRIDE-per-element (systematic approach):
• External entities (humans, other systems) → focus on S (spoofing identity)
• Processes → focus on T (tampering with logic), E (privilege escalation)
• Data stores → focus on T (modification), I (disclosure), D (deletion/unavailability)
• Data flows → focus on T (tampering in transit), I (interception), D (dropped messages)
• Trust boundary crossings → all STRIDE categories apply

Key vocabulary:
• STRIDE — Spoofing / Tampering / Repudiation / Information disclosure / Denial of Service / Elevation of privilege; a threat classification taxonomy for systematic threat elicitation
• Threat modelling — structured analysis of a system to identify, enumerate, and prioritise potential threats before implementation
• DFD (Data Flow Diagram) — diagram showing how data moves through a system, used as the canvas for STRIDE analysis
• Trust boundary — a line on a DFD where data crosses from one trust level to another; highest-risk points in a system

2 / 5

During a threat modelling session, the team needs to rate the severity of identified threats to prioritise remediation. The facilitator introduces DREAD scoring. How does DREAD work, and what are its trade-offs vs CVSS?

DREAD — a simple relative scoring model for internal threat prioritisation; CVSS — the standardised score for published vulnerabilities and cross-organisational communication.

DREAD scoring dimensions:

Letter	Dimension	1 (low)	10 (high)
D	Damage potential	Cosmetic only	Full data compromise / root takeover
R	Reproducibility	Very hard to reproduce	Always reproducible
E	Exploitability	Expert attacker required	Novice / automated exploit available
A	Affected users	Individual user	All users / all customers
D	Discoverability	Hard to find / code review only	Publicly documented / trivially found

DREAD score = average(D + R + E + A + D) / 5
• 1-3: Low risk
• 4-6: Medium risk
• 7-10: High risk

CVSS v3.1 Base Score vectors:
• Attack Vector (network/adjacent/local/physical)
• Attack Complexity (low/high)
• Privileges Required (none/low/high)
• User Interaction (none/required)
• Scope (unchanged/changed)
• Confidentiality/Integrity/Availability Impact (none/low/high)
• Output: 0-10 numerical score + Critical/High/Medium/Low/None

When to use each:
• DREAD — internal design-time threat prioritisation where the team wants a quick, relative ranking to decide where to focus mitigation efforts. Subjective but fast.
• CVSS — reporting discovered vulnerabilities externally (CVE database, vendor advisories, penetration test reports, bug bounty programmes). Standardised for comparability.
• Many teams use CVSS for all internal scoring too — ensures consistent, cross-comparable prioritisation aligned with industry expectations

DREAD criticism:
Microsoft originally included DREAD in the threat modelling methodology but later dropped it from official guidance — partly because "Discoverability" creates a perverse incentive (lowering the score by keeping vulnerabilities secret rather than fixing them).

Key vocabulary:
• DREAD — Damage potential / Reproducibility / Exploitability / Affected users / Discoverability; a relative threat risk scoring model
• CVSS (Common Vulnerability Scoring System) — industry-standard vulnerability severity scoring system; Base Score, Temporal Score, Environmental Score
• Base Score — CVSS intrinsic vulnerability characteristics independent of time and environment
• Risk rating — a composite score combining likelihood and impact to prioritise security decisions

3 / 5

A principal engineer proposes using PASTA (Process for Attack Simulation and Threat Analysis) instead of STRIDE for the company's threat modelling programme. What distinguishes PASTA from STRIDE, and when is it more appropriate?

STRIDE and PASTA are complementary, not competing. STRIDE excels at systematic threat elicitation; PASTA excels at business-risk-aligned threat analysis with attack simulation.

PASTA 7 stages (mnemonic: Objectives → Scope → Decompose → Threats → Vulnerabilities → Attack → Risk):

#	Stage	Key outputs
1	Define business objectives	Business risk register, compliance requirements, SLAs
2	Define technical scope	Architecture diagrams, DFDs, infrastructure inventory
3	Application decomposition	Data flows, trust levels, dependencies, third-party integrations
4	Threat analysis	Threat intelligence feeds, MITRE ATT&CK patterns, threat actors
5	Vulnerability detection	SAST/DAST results, dependency CVEs, configuration findings
6	Attack modelling	Attack trees, attack scenarios, adversary simulation
7	Risk and impact analysis	Business risk scores, residual risk, remediation roadmap, sign-off

When to choose STRIDE vs PASTA:
• STRIDE — agile sprint threat modelling, developer-led sessions, feature-level analysis, 1-2 hour workshop. STRIDE is integrated into the development workflow.
• PASTA — security programme-level analysis, regulated systems (PCI-DSS, HIPAA, financial), M&A security due diligence, annual security architecture review. PASTA produces business-justifiable risk decisions.
• Teams often combine: STRIDE for day-to-day feature modelling, PASTA for quarterly system-level deep dives.

Threat actor profiles in threat analysis (PASTA stage 4):
• Script kiddies — opportunistic, use existing exploit kits, low sophistication
• Motivated criminals — financial gain, ransomware, stolen credentials, credit card fraud
• Hacktivists — reputational damage, data dumps, DDoS for political purposes
• Nation-state APTs — long dwell time, supply chain compromise, espionage
• Malicious insiders — privileged access, data exfiltration, sabotage

Key vocabulary:
• PASTA — Process for Attack Simulation and Threat Analysis; 7-stage, business-risk-centric threat modelling methodology
• Attack simulation — constructing realistic attack scenarios (attack trees + threat intelligence) to test whether controls are effective
• Threat intelligence — curated information about threat actors, TTPs, and active campaigns; used in PASTA stage 4 to ground threat identification in reality
• Remediation roadmap — prioritised list of controls to implement based on risk scoring; output of PASTA stage 7

4 / 5

During a threat model review, the team labels several items as "out of scope — attacker has physical access to the server." A security architect objects: "You need to define your threat actor profile and attack scope before deciding what's out of scope." What does she mean?

Scope decisions in threat modelling must be grounded in a clearly defined threat actor profile — the starting assumptions about attacker capability and access.

Threat actor profile components:
• Identity / motivation — who are they and what do they want? (financial gain, espionage, disruption, insider sabotage)
• Access level — where are they starting from? (unauthenticated internet, authenticated user, compromised employee account, supply chain, physical access)
• Skill level — what capabilities do they have? (script kiddie → professional penetration tester → nation-state APT)
• Resources — time, money, custom tooling, zero-day knowledge

How profile drives scope decisions:

Threat actor	In scope	Out of scope
Unauthenticated internet attacker	Public endpoints, auth bypass, injection attacks	Physical access, VM escape, hypervisor attacks
Malicious authenticated user	IDOR, privilege escalation, API abuse	Physical access, internal network lateral movement
Malicious insider (IT admin)	Database dumps, config changes, log deletion, key exfiltration	Physical infrastructure (if cloud-hosted)
Supply chain attacker	Dependency backdoors, build pipeline compromise, container image poisoning	Physical, direct network attacks

Common threat modelling scope assumptions to document explicitly:
• "We assume the cloud provider is not compromised (or: the cloud provider IS in scope for threat analysis)"
• "We assume the attacker cannot break modern TLS encryption (or: TLS downgrade attacks are in scope)"
• "We assume the CI/CD pipeline is secure (or: supply chain attacks are in scope)"
• Documenting these assumptions makes threat models auditable, comparable across reviews, and useful for compliance evidence

Key vocabulary:
• Threat actor profile — documented description of an attacker's identity, motivation, starting access level, skill, and resources; defines what attacks are plausible in the threat model
• Attack scope — the boundary of what is considered "in scope" for a threat model; should be derived from the threat actor profile(s)
• Threat modelling assumptions — explicit statements of what the model assumes to be true; makes scope decisions auditable
• APT (Advanced Persistent Threat) — a sophisticated, well-resourced attacker (typically nation-state or organised crime) who maintains long-term, stealthy access to a target network

5 / 5

A security team is shifting from ad-hoc threat modelling to a systematic threat modelling programme. They want threat models to be created per feature, reviewed at architecture review, and kept up to date. What does a mature threat modelling programme look like?

Threat modelling programmes succeed when they become a development practice, not a security team gate. The goal is "security as code" — threat analysis happening as early as feature design.

Threat modelling integration points in the development lifecycle:

Stage	Threat modelling activity	Who
Feature design	Quick 30-min threat brainstorm using STRIDE checklist	Dev team + security champion
Architecture review	Formal DFD-based STRIDE analysis; threats logged; controls approved	Security architect review
Significant change (new auth, new DB, new external integration)	Incremental threat model update; delta review only	Dev + security champion
Annual system review	Full PASTA-style review; validate all existing mitigations still effective	Security team + architects

Making threat models actionable:
• Link each threat to a JIRA/GitHub ticket with owner, due date, and remediation description
• Define "done" for each mitigation (unit test, architecture change, policy update)
• Track unmitigated threats in a risk register with accepted/mitigated/transferred status
• Use threat model findings to inform static analysis (SAST) rules and security unit tests

Security champion model:
Each development team has a designated "security champion" — a developer with additional security training who facilitates team-level threat modelling, triage security findings, and liaises with the central security team. Champions scale security expertise without requiring every decision to go through a central team.

Key vocabulary:
• Shift-left security — identifying and addressing security issues earlier in the development lifecycle (design, not production); reduces cost and risk
• Security champion — a developer with additional security training who advocates for security practices within their development team
• Living threat model — a threat model document that is continuously updated as the system evolves; treated as a maintained artefact, not a one-time deliverable
• Risk register — a tracked list of identified risks with status (accepted/mitigated/transferred) and owner; makes unaddressed threats visible to management