Security Threats - Learning Module

Loading content...

0/227

Threat Modeling

Thinking Like an Attacker

Threat modeling is the structured process of identifying threats to a system, understanding their likelihood and impact, and determining how to address them. It answers the fundamental question: 'What can go wrong with this system, and what should we do about it?'

Without threat modeling, security efforts become reactive—fixing vulnerabilities after they're exploited rather than designing them out. With threat modeling, organizations can make informed decisions about where to invest security resources, what risks to accept, and how to architect systems that resist attack from the start.

What You Will Learn

By the end of this page, you will understand the threat modeling process, major methodologies (STRIDE, PASTA, Attack Trees, DREAD), how to create and maintain threat models, and how to integrate threat modeling into development and operations processes.

Why Threat Model

Threat modeling exists because we cannot secure everything equally. Resources are finite, and not all threats are equally likely or impactful. Without structured analysis, security efforts become either scattered (trying to address everything) or misallocated (focusing on theoretical risks while ignoring practical ones).

The core value propositions:

Benefits of Threat Modeling

•Proactive Security — Identify threats during design, when they're cheapest to address. Fixing a design flaw costs 100x less than patching a deployed vulnerability.
•Focused Investment — Prioritize security spend on the threats that matter most. Limited resources address maximum risk.
•Shared Understanding — Create documented threat knowledge that survives team changes. New developers understand security rationale behind design decisions.
•Compliance Evidence — Many frameworks require documented threat analysis. Threat models provide audit-ready security documentation.
•Risk Communication — Translate technical threats into business terms for stakeholders. 'We're vulnerable to data exfiltration via SQL injection that could expose customer PII and trigger GDPR fines.'
•Defense Validation — Verify that security controls actually address identified threats. No controls implemented 'just in case' without concrete threat motivation.

When to threat model:

New systems — Before architecture is finalized, when design changes are still possible
Major changes — New features, integrations, or architectural modifications
Security incidents — After breaches to understand what the model missed
Periodic review — Annually or when threat landscape significantly changes
Compliance requirements — When frameworks require documented threat analysis

The cost of not modeling:

Organizations that skip threat modeling typically experience:

Vulnerabilities discovered late (production rather than design)
Security controls that don't match actual threats
Inconsistent security across similar components
Difficulty explaining security architecture to auditors
Repeated discovery of the same issue patterns

The Shift-Left Imperative

Security economics strongly favor early intervention. Studies consistently show that fixing security flaws in design costs 10-100x less than fixing them in production. Threat modeling is the primary mechanism for 'shifting left'—moving security consideration to the earliest possible development phase where corrections are cheapest.

The Threat Modeling Process

While specific methodologies vary, all threat modeling follows a common high-level process. Adam Shostack (Microsoft, author of Threat Modeling: Designing for Security) distills it to four questions:

What are we working on? — Understanding the system
What can go wrong? — Identifying threats
What are we going to do about it? — Addressing threats
Did we do a good job? — Validating the analysis

Let's explore each phase in detail:

Threat Modeling Process Phases
Phase	Key Question	Activities	Outputs
1. Decomposition	What are we working on?	Create data flow diagrams, identify trust boundaries, list assets, document entry points	System model, DFD, asset inventory
2. Threat Identification	What can go wrong?	Apply methodology (STRIDE, etc.), enumerate threats per element, consider attacker motivation	Threat list with descriptions
3. Risk Assessment	How bad is this?	Rate likelihood and impact, calculate risk scores, prioritize threats	Prioritized threat ranking
4. Mitigation Planning	What do we do about it?	Design countermeasures, accept/mitigate/transfer decisions, document residual risk	Mitigation plan, accepted risks
5. Validation	Did we do a good job?	Review completeness, test mitigations, update model	Validated threat model, testing results

Phase 1: System Decomposition

Before identifying threats, you must understand the system. Common techniques:

Data Flow Diagrams (DFDs):

Show how data moves through the system
Identify external entities (users, systems)
Document processes that transform data
Show data stores (databases, files)
Mark trust boundaries where privilege levels change

Trust Boundary Identification: Trust boundaries mark where security assumptions change:

Between user browser and web server
Between web application and database
Between internal network and DMZ
Between different privilege levels (user vs. admin)

Most threats occur at trust boundaries where data crosses from one trust zone to another.

Asset Inventory: What is worth protecting?

Customer PII (personal identifiable information)
Authentication credentials
Financial data
Intellectual property
System availability
Audit/compliance logs

DFD Elements

Standard DFD notation: External entities (rectangles, represent users/external systems), Processes (circles, represent code/logic), Data stores (parallel lines, represent databases/files), Data flows (arrows, show data movement), Trust boundaries (dotted lines, show security domain changes).

STRIDE Methodology

STRIDE is Microsoft's mnemonic for systematically identifying threats. Each letter represents a threat category, and the methodology involves examining each system component for vulnerability to each STRIDE category.

The STRIDE framework in depth:

STRIDE Threat Categories Detailed
Category	Violated Property	Threat Question	Typical Countermeasures
Spoofing	Authentication	Can an attacker pretend to be something/someone else?	Authentication (passwords, MFA, certificates), mutual TLS, token validation
Tampering	Integrity	Can data/code be modified without detection?	Hashing, digital signatures, input validation, access controls, integrity monitoring
Repudiation	Non-repudiation	Can actions be denied/hidden?	Audit logging, tamper-evident logs, digital signatures, witness records
Information Disclosure	Confidentiality	Can sensitive information be exposed?	Encryption (transit/rest), access controls, output filtering, error handling
Denial of Service	Availability	Can legitimate access be prevented?	Rate limiting, resource quotas, redundancy, input validation, caching
Elevation of Privilege	Authorization	Can attackers gain unauthorized capabilities?	Least privilege, authorization checks, security boundaries, sandboxing

Applying STRIDE Per Element:

For each DFD element, systematically ask STRIDE questions:

External Entities:

S: Can external entities be spoofed? (fake users, impersonated services)
R: Can external entity actions go unrecorded?

Processes:

S: Can the process be spoofed? (rogue process impersonating legitimate one)
T: Can process logic/code be tampered with?
R: Can process actions be denied?
I: Can the process leak information?
D: Can the process be crashed or overwhelmed?
E: Can the process gain unintended capabilities?

Data Stores:

T: Can stored data be modified?
I: Can stored data be read without authorization?
D: Can the data store be made unavailable?

Data Flows:

T: Can data be modified in transit?
I: Can data be intercepted in transit?
D: Can the data flow be interrupted?

Trust Boundaries:

Examine how all STRIDE threats apply at each boundary crossing
Most vulnerabilities occur at trust boundaries

STRIDE-per-Element Table

Not all STRIDE categories apply equally to all DFD elements. Processes are vulnerable to all six categories. Data stores primarily face Tampering, Information Disclosure, and DoS. Data flows primarily face Tampering, Information Disclosure, and DoS. External entities primarily face Spoofing and Repudiation. This mapping helps focus analysis efficiently.

PASTA: Process for Attack Simulation and Threat Analysis

PASTA (Process for Attack Simulation and Threat Analysis) is a risk-centric threat modeling methodology that emphasizes business impact and attacker perspective. Unlike STRIDE's focus on threat categories, PASTA builds from business objectives down to technical vulnerabilities.

The seven stages of PASTA:

PASTA Seven-Stage Process
Stage	Focus	Key Activities	Outputs
1. Define Objectives	Business context	Identify business objectives, security requirements, compliance needs	Business risk profile, security requirements document
2. Define Technical Scope	System understanding	Document architecture, data flows, technologies, dependencies	Technical architecture model, dependency maps
3. Application Decomposition	Deep technical analysis	Identify components, trust levels, entry points, data assets	DFDs, asset inventory, trust boundary map
4. Threat Analysis	Threat landscape	Research relevant threats, attacker profiles, threat intelligence	Threat library, attacker profiles, attack scenarios
5. Vulnerability Analysis	Weakness identification	Identify existing vulnerabilities, weaknesses, attack surface gaps	Vulnerability map, weakness report
6. Attack Modeling	Attacker simulation	Create attack trees, map threat-vulnerability intersections, model attack paths	Attack trees, probability analysis, exploitability assessment
7. Risk/Impact Analysis	Business impact	Calculate risk scores, business impact, prioritize mitigations	Prioritized risk catalog, mitigation recommendations

PASTA vs. STRIDE:

Dimension	STRIDE	PASTA
Focus	Threat categorization	Risk-based, business-aligned
Approach	Per-element analysis	Holistic, seven-stage process
Effort	Lighter-weight	More comprehensive
Output	Threat list	Prioritized risk catalog
Best For	Quick design review	Detailed security analysis, compliance

When to use PASTA:

High-value systems requiring thorough analysis
Compliance-driven environments needing documented risk assessment
Systems with significant business impact from security failures
Organizations wanting attacker-perspective simulation
Initial threat modeling for critical new systems

PASTA's comprehensiveness makes it more time-consuming than STRIDE, but produces more actionable risk-prioritized outputs.

Methodology Selection

No single methodology is best for all situations. STRIDE is excellent for design reviews and quick analysis. PASTA provides comprehensive risk assessment. Attack trees excel at modeling specific attack scenarios. Many organizations use multiple methodologies for different contexts—lighter methods for ongoing reviews, deeper methods for critical systems.

Attack Trees

Attack trees are hierarchical diagrams that represent how attackers might achieve specific malicious goals. Developed by Bruce Schneier, attack trees model attacker objectives as root nodes, with child nodes representing different ways to achieve parent goals.

Attack tree structure:

Root node — The attacker's ultimate goal (e.g., 'Steal customer data')
Child nodes — Sub-goals or methods to achieve parent goal
Leaf nodes — Atomic attack steps that cannot be further decomposed
AND nodes — All child conditions must be met
OR nodes — Any child condition is sufficient

Example Attack Tree: Steal Customer Data

                        Steal Customer Data (ROOT)
                                  |
        +-----------------+-------+-------+-----------------+
        |                 |               |                 |
    SQL Injection    Compromise Admin  Social Engineering  Insider Threat
        |                 |               |                 |
   (Leaf: exploit    +----+----+     Phish Support      (Leaf: malicious
    input validation  |         |        Staff              employee)
    flaw)         Credential  Exploit       |
                   Stuffing    Vuln     +---+---+
                      |         |       |       |
                  (Leaf:    (Leaf:   Get      Trick
                  reuse    0-day   Creds     Victim
                  leaked   or       |         |
                  creds)   unpatched) (Leaf) (Leaf)

Annotating Attack Trees:

Attack trees become more useful when annotated with:

Cost — Resources required by attacker (money, time, effort)
Skill — Technical capability required
Detectability — How likely the attack is to be detected
Probability — Likelihood of success given appropriate attacker
Impact — Damage if attack succeeds
Countermeasures — Defenses that block this path

Attack Tree Node Annotation Example
Attack Path	Cost	Skill	Detectability	Probability
SQL Injection → Data Extraction	Low ($)	Medium	Low (logged but ignored)	High (if no input validation)
Phishing → Admin Creds → Data Access	Medium ($$)	Medium	Medium (some email filtering)	Medium (MFA may block)
Insider Exfiltration	Low ($)	Low	Medium (DLP may detect)	Variable (depends on controls)
Zero-day Exploitation	Very High ($$$$$)	Very High	Low (no signatures)	Low (expensive, rare capability)

Attack Trees for Risk Comparison

Attack trees excel at comparing attack paths. By annotating cost, skill, and probability, you can identify which paths attackers will prefer (low cost, low skill, high success) and prioritize defenses accordingly. The 'obvious' technical exploit may be less likely than a simple social engineering attack if the human path is cheaper and more reliable.

DREAD: Threat Risk Ranking

Once threats are identified, they must be prioritized. DREAD is Microsoft's risk ranking methodology that scores threats across five dimensions to produce a prioritized threat list.

The DREAD categories:

DREAD Risk Scoring Dimensions
Category	Question	High Score (3)	Medium Score (2)	Low Score (1)
Damage	How bad if exploited?	Complete system compromise, data breach	Individual data exposure	Minor data corruption
Reproducibility	How easy to repeat?	Always works, no special conditions	Works under specific conditions	Difficult to reproduce
Exploitability	How much skill/effort?	Script kiddie, automated tools	Skilled attacker, some effort	Expert attacker, significant effort
Affected Users	How many impacted?	All users, entire organization	Subset of users, one department	Individual user, edge case
Discoverability	How easy to find?	Publicly known, obvious	Requires effort to discover	Very obscure, unlikely to find

Calculating DREAD Scores:

Each dimension is rated 1-3 (or 0-10 in some variants). The final score is the sum or average of all dimensions.

Example DREAD Calculation:

Threat: SQL Injection in Login Form

Category	Rating	Justification
Damage	3	Could expose entire user database
Reproducibility	3	Works reliably once injection found
Exploitability	2	Requires some SQL knowledge, automated tools exist
Affected Users	3	All users have credentials stored
Discoverability	2	Not advertised, but standard attack surface

DREAD Score: (3+3+2+3+2)/5 = 2.6/3 = HIGH PRIORITY

Criticisms of DREAD:

DREAD has been criticized and even deprecated by Microsoft due to:

Subjectivity — Ratings depend heavily on analyst perspective
Discoverability controversy — Security through obscurity is not a reliable defense
Inconsistent application — Different teams calculate scores differently

Many organizations now use simpler likelihood × impact matrices or adopt CVSS (Common Vulnerability Scoring System) for standardization.

Discoverability Caution

Many security practitioners argue that Discoverability should always be rated high (assume attackers will find it) or removed entirely. Rating something as 'hard to discover' encourages security through obscurity, which is not a reliable defense. If a vulnerability exists, assume motivated attackers will discover it.

Threat Mitigation Strategies

After identifying and prioritizing threats, you must decide how to address them. There are four fundamental strategies for responding to identified risks:

The risk response options:

Risk Response Strategies
Strategy	Description	When to Use	Example
Mitigate	Implement controls to reduce likelihood or impact	When controls are cost-effective relative to risk	Add input validation to prevent SQL injection
Accept	Acknowledge risk and take no action	When cost exceeds benefit, very low probability	Accept minor DOS risk during non-critical hours
Transfer	Shift risk to another party	When insurance/outsourcing is cost-effective	Cyber insurance for breach costs, WAF service
Avoid	Eliminate the risky element entirely	When risk is unacceptable and can be eliminated	Remove feature that creates unjustifiable risk

STRIDE-Based Mitigation Patterns:

Each STRIDE category has established mitigation patterns:

Spoofing Mitigations:

Authentication mechanisms (passwords, MFA, biometrics)
Mutual TLS for service-to-service authentication
API keys and JWT tokens with proper validation
Certificate validation and pinning

Tampering Mitigations:

Cryptographic hashing and digital signatures
Input validation and sanitization
Access controls limiting write permissions
Integrity monitoring (file, database, configuration)

Repudiation Mitigations:

Comprehensive audit logging
Tamper-evident log storage (write-once, forwarded)
Digital signatures for critical transactions
Timestamps from trusted sources

Information Disclosure Mitigations:

Encryption (data in transit and at rest)
Access controls (need-to-know basis)
Output encoding and filtering
Proper error handling (no stack traces to users)

Denial of Service Mitigations:

Rate limiting and throttling
Resource quotas and limits
Input validation (prevent algorithmic complexity attacks)
Redundancy and failover

Elevation of Privilege Mitigations:

Least privilege principle
Authorization checks at every operation
Security boundaries and sandboxing
Privilege separation (don't run as root)

Defense in Depth

Never rely on a single mitigation. For critical threats, implement multiple overlapping controls (defense in depth). If SQL injection prevention fails at input validation, prepared statements provide a second layer. If authentication is bypassed, authorization checks are backup. Layered defenses ensure single control failures don't result in compromise.

Threat Model Documentation

A threat model is only valuable if it's documented, accessible, and maintained. Poor documentation means the analysis is lost when team members leave, cannot be audited for compliance, and won't be updated as systems change.

Essential threat model documentation:

Threat Model Document Components

•System Description — What is being modeled; scope and boundaries; intended functionality and users
•Data Flow Diagrams — Visual representation of system components, data flows, and trust boundaries
•Asset Inventory — What needs protection; sensitivity classification; data types handled
•Threat Enumeration — Complete list of identified threats with descriptions of attack scenarios
•Risk Assessment — Likelihood and impact ratings; prioritization rationale; risk scores
•Mitigation Plan — Controls to address each threat; responsible parties; implementation timeline
•Accepted Risks — Risks explicitly accepted with justification; risk owner sign-off
•Assumptions and Dependencies — Security assumptions made; external dependencies relied upon
•Review History — When model was created, reviewed, and updated; version history

Threat Tracking Integration:

Threats should integrate with existing workflow systems:

Issue trackers (Jira, GitHub Issues) — Create tickets for mitigation work with threat context
Risk registers — Roll up accepted risks to organizational risk management
Security dashboards — Track mitigation progress across threat models
Documentation wikis — Store models where developers can access during development

Living Document Concept:

Threat models are living documents, not one-time exercises:

Initial creation during architecture/design phase
Updates when system changes (new features, integrations, dependencies)
Reviews triggered by security incidents or near-misses
Periodic reassessment as threat landscape evolves
Retirement when systems are decommissioned

Without maintenance, threat models become security theater—impressive documents that don't reflect reality.

Tool Support

Several tools assist threat modeling: Microsoft Threat Modeling Tool (free, STRIDE-based), OWASP Threat Dragon (open-source), IriusRisk (commercial, automated), draw.io / Lucidchart (for DFD creation). Tools help with diagram creation, threat enumeration, and report generation, but don't replace security expertise—they're aids to human analysis.

Agile Threat Modeling

Traditional threat modeling—comprehensive, document-heavy, conducted at design time—conflicts with agile development's iterative, fast-moving nature. Agile threat modeling adapts threat modeling to fit sprint-based development without sacrificing security rigor.

Challenges with traditional approaches in agile:

Design is emergent, not upfront—there's no 'design phase' to threat model
Long documentation cycles conflict with sprint timeframes
Waterfall-style threat models become outdated within sprints
Security reviews become bottlenecks blocking delivery

Agile Threat Modeling Strategies
Strategy	Description	When to Apply
Story-level threat analysis	Include threat thinking in story definition; 'as an attacker...' stories	Every story with security implications
Incremental modeling	Update threat model incrementally as features are added	Each sprint that changes attack surface
Sprint security reviews	Brief security review of sprint deliverables	End of each sprint
Continuous threat model	Maintain living threat model updated with code	Ongoing throughout product lifecycle
Architecture runway	Do deeper analysis for significant architectural decisions	When architecture changes
Threat modeling cards	Quick threat identification using card-based prompts	Story grooming, design discussions

Embedding Threat Thinking in Development:

During Backlog Grooming:

Ask 'How could this be abused?' for each story
Create 'evil user stories' ('As an attacker, I want to...')
Identify stories that cross trust boundaries

During Sprint Planning:

Identify security implications of sprint scope
Include mitigation tasks for identified threats
Ensure security work is sized and prioritized

During Development:

Developers consider threats at implementation time
Security team provides lightweight consultation
Automated security testing in CI/CD pipeline

During Review:

Demo includes security-relevant behavior
Security team spot-checks high-risk changes
Update threat model documentation

Threat Modeling Manifesto:

The threat modeling community has articulated core values:

Finding and fixing design issues over comprehensive documentation
Threat modeling for everyone rather than security specialists only
Continuous refinement over one-time analysis
Practical, actionable outcomes over theoretical completeness

Developer-Friendly Threat Modeling

The best threat modeling happens when developers do it themselves with security team guidance, rather than security teams analyzing systems they don't deeply understand. Train developers in basic threat modeling; they know their systems best. Security teams provide frameworks, review results, and handle complex analysis—but developers should drive day-to-day threat thinking.

Summary: Threat Modeling in Practice

We've explored threat modeling—the structured approach to identifying, assessing, and addressing security threats. This discipline transforms security from reactive firefighting to proactive architecture, enabling organizations to build security in rather than bolt it on.

Key Takeaways

•Threat modeling answers 'What can go wrong?' systematically—through decomposition, threat identification, risk assessment, and mitigation planning.
•STRIDE provides a mnemonic for threat categories—Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege.
•PASTA offers a comprehensive, risk-centric seven-stage process aligning threats with business objectives.
•Attack trees model specific attacker goals hierarchically, enabling comparison of attack path costs and probabilities.
•DREAD (or similar frameworks) prioritizes threats by Damage, Reproducibility, Exploitability, Affected Users, and Discoverability.
•Mitigation strategies include mitigate (implement controls), accept (acknowledge and document), transfer (insurance/outsourcing), and avoid (remove risky element).
•Documentation makes threat models auditable, maintainable, and valuable beyond the initial analysis team.
•Agile threat modeling integrates security thinking into iterative development through story-level analysis and incremental model updates.

What's Next:

With threat modeling understood, we'll conclude this module with Risk Assessment—the quantitative and qualitative methods for evaluating risk to inform business decisions about security investments. Risk assessment takes threat model outputs and translates them into business terms.

Page Complete

You now understand how to systematically identify and analyze threats to systems. Threat modeling is a skill that improves with practice—start with STRIDE for quick analysis, use PASTA for comprehensive assessment, and integrate threat thinking into your development process. The goal isn't perfect threat models; it's better security through structured thinking.