12  Threat Modelling and Mitigation

12.1 Overview

Threat modelling provides a structured approach to identifying, analyzing, and mitigating security vulnerabilities in IoT systems. This comprehensive guide is split into five focused chapters covering theory, frameworks, practical scenarios, assessments, and hands-on labs.

Sensor Squad: Thinking Like a Hacker to Stay Safe!

“To beat the bad guys, we need to think like the bad guys!” Max the Microcontroller declared. “Threat modeling is a structured way to ask: What could go wrong? How would an attacker break in? And what should we do about it?”

Sammy the Sensor explained the approach. “Imagine you are designing a smart home. You ask four big questions: What are we building? What can go wrong? What do we do about it? Did we do a good job? It is like being a detective who investigates crimes BEFORE they happen!”

“There are frameworks to help you not miss anything,” Lila the LED added. “STRIDE helps you think of six types of threats. DREAD helps you score how dangerous each threat is. And decision trees help you choose the right level of security based on what you are protecting. A smart lightbulb needs different security than a medical device!”

“Threat modeling is not just for experts,” Bella the Battery assured everyone. “Even beginners can ask ‘what happens if someone steals this device?’ or ‘what if the network is not encrypted?’ Each question leads to a mitigation – a fix that reduces the risk. The series of chapters ahead walks you through everything step by step, from basics to hands-on labs!”

12.2 Learning Path

12.2.1 1. Introduction and Fundamentals

⏱️ 20-30 minutes | 🎯 4,608 words

Start here to understand threat modeling basics, security decision trees, and regulatory requirements.

What You’ll Learn:

• The four key questions of threat modeling
• How to assess assets, threats, and attack vectors
• Security level selection (Basic to Critical)
• Real-world examples: smart home, industrial sensors, medical devices
• Trade-offs: HSM vs software crypto, edge vs cloud authentication

Key Topics:

• Security Requirements Decision Tree
• Regulatory compliance (GDPR, HIPAA, PCI-DSS, IEC 62443)
• Defense in depth strategies
• Cost-benefit analysis of security controls

12.2.2 2. STRIDE Framework and Threat Taxonomies

⏱️ 15-20 minutes | 🎯 2,961 words

Learn systematic threat identification using Microsoft’s STRIDE methodology and comprehensive IoT threat taxonomies.

What You’ll Learn:

• Applying the STRIDE model (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege)
• Five-step threat modeling process
• Mapping threats to security properties
• Identifying entry points and trust boundaries

Key Topics:

• STRIDE threat categories
• Threat modeling maturity stages
• IoT attack surfaces (device, network, application, cloud, physical)
• Attack scenario development

12.2.3 3. IoT Attack Scenarios and Risk Assessment

⏱️ 20-25 minutes | 🎯 3,650 words

Explore real-world IoT attack patterns and learn to assess risk using the DREAD framework.

What You’ll Learn:

• Critical IoT attack scenarios (default credentials, firmware bugs, MITM)
• DREAD risk scoring (Damage, Reproducibility, Exploitability, Affected users, Discoverability)
• Worked examples with smart lock vulnerability analysis
• Interactive threat assessment tool

Key Topics:

• Attack scenario analysis
• Risk prioritization methodologies
• Vulnerability impact assessment
• Remediation planning

12.2.4 4. Assessments and Resources

⏱️ 30-40 minutes | 🎯 5,319 words

Test your knowledge with comprehensive quizzes covering all aspects of threat modeling.

What You’ll Learn:

• Knowledge checks for each chapter section
• Scenario-based assessment questions
• Video resources for deeper learning
• Cross-references to related chapters

Key Topics:

• Quiz 1: Critical attack scenario analysis
• Quiz 2 & 3: Comprehensive review (40+ questions each)
• Chapter summary and key takeaways
• Visual reference gallery

12.2.5 5. Threat Detection and Risk Assessment Lab

⏱️ 45-60 minutes | 🎯 5,570 words

Practice threat detection with an interactive simulator featuring real-time attack analysis and DREAD scoring.

What You’ll Learn:

• Real-time threat detection and response
• DREAD risk calculation for detected attacks
• Attack pattern correlation
• Lockout policy configuration and recovery

Key Topics:

• Interactive threat detection simulator
• 4 guided exercises
• Challenge exercises for advanced students
• Real-world application scenarios

Knowledge Check: Threat Modeling Timing

12.3 Quick Navigation

Chapter	Focus	Time	Difficulty
1. Introduction	Fundamentals & Decision Trees	20-30 min	⭐⭐ Intermediate
2. STRIDE Framework	Systematic Threat ID	15-20 min	⭐⭐ Intermediate
3. Attack Scenarios	Real-World Attacks & Risk	20-25 min	⭐⭐⭐ Advanced
4. Assessments	Knowledge Checks	30-40 min	⭐⭐⭐ Advanced
5. Hands-On Lab	Interactive Simulator	45-60 min	⭐⭐⭐ Advanced

Total Time: ~2.5-3 hours for complete series

12.4 Prerequisites

Before starting this series, you should be familiar with:

• Security and Privacy Overview: Understanding of the CIA triad and basic security principles
• Networking Basics: Knowledge of network protocols and communication layers
• Introduction to Privacy: Understanding privacy threats and regulatory requirements

12.5 Related Topics

Security Implementation:

• Encryption Principles - Cryptographic protection methods
• IoT Device Security - Device hardening techniques
• Secure Data and Software - Data protection strategies
• Threats, Attacks & Vulnerabilities - Comprehensive attack catalog

Privacy Context:

• Privacy by Design - Built-in privacy mechanisms
• Mobile Privacy - Mobile-specific privacy concerns

Learning Hubs:

• Quiz Navigator - Find all security quizzes
• Hands-On Labs Hub - All interactive labs

12.6 Learning Objectives (Complete Series)

By completing all five chapters, you will be able to:

• Apply Threat Modeling Frameworks: Use STRIDE, DREAD, and attack trees to systematically identify IoT vulnerabilities
• Map Attack Surfaces: Enumerate device, network, and cloud attack vectors in IoT architectures
• Prioritize Security Risks: Quantify threat severity using DREAD scoring based on likelihood, impact, and exploitability
• Design Targeted Mitigations: Develop countermeasures for identified threats including authentication, encryption, and monitoring
• Create Comprehensive Threat Models: Document threat models with versioning for IoT system designs
• Implement Defense in Depth: Layer independent security controls across the IoT stack
• Detect and Respond to Threats in Real-Time: Configure threat detection systems and tune security controls
• Calculate and Interpret Risk Scores: Apply DREAD methodology to prioritize remediation efforts quantitatively

Key Concepts

• STRIDE: A threat classification framework covering Spoofing (identity), Tampering (data integrity), Repudiation (action deniability), Information Disclosure (confidentiality), Denial of Service (availability), and Elevation of Privilege (authorisation) — applied to each element and data flow in a system diagram.
• Data Flow Diagram (DFD): A diagram showing how data moves between external entities, processes, data stores, and trust boundaries in a system — the primary input document for STRIDE-based threat modelling.
• DREAD scoring: A risk scoring method rating threats on Damage, Reproducibility, Exploitability, Affected users, and Discoverability, producing a numerical priority score for each identified threat.
• Threat tree: A hierarchical diagram mapping an attacker’s high-level goal (root) to the specific conditions needed to achieve it (leaves), showing alternative attack paths and identifying which controls break the most paths.
• Mitigation: A security control designed to reduce the likelihood or impact of a specific identified threat — selected based on the threat category (authentication addresses Spoofing, integrity checks address Tampering, etc.).
• Residual risk acceptance: The explicit decision by a system owner to accept the remaining risk after mitigations are applied, documented with the owner’s name and rationale for accountability.

In 60 Seconds

Threat modelling is a structured process for identifying what could go wrong with an IoT system — who might attack it, how they might attack, what they could achieve, and which defences would be most effective — converting security decisions from gut feeling into evidence-based engineering. STRIDE provides the most widely applicable framework for IoT threat modelling, covering Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege.

12.7 Study Recommendations

For Beginners:

1. Start with Introduction & Fundamentals
2. Work through STRIDE Framework
3. Review Attack Scenarios
4. Take Assessments to test understanding
5. Complete Hands-On Lab for practical experience

For Experienced Practitioners:

• Jump to Attack Scenarios for real-world case studies
• Use Assessments to identify knowledge gaps
• Focus on Hands-On Lab for practical skills

For Quick Reference:

• Introduction - Security decision tree for rapid level selection
• STRIDE Framework - Threat identification checklist
• Attack Scenarios - DREAD scoring guide

12.8 Knowledge Check

Quiz: Threat Modelling and Mitigation

Worked Example: Complete Threat Model for a Smart Door Lock System

System Overview: Consumer smart door lock with mobile app control, cloud backend, and local Bluetooth fallback.

Architecture Components:

1. Smart Lock Device (Bluetooth LE + Wi-Fi, battery-powered, installed on door)
2. Mobile App (iOS/Android, communicates via Bluetooth + cloud API)
3. Cloud Backend (AWS, stores user accounts, access logs, push notifications)
4. Wi-Fi Router (home network, provides internet connectivity for lock)

Step 1: Identify Entry Points

Entry Point	Protocol	Authentication	Encryption	Exposure
Bluetooth LE	BLE 4.2	Pairing code (6 digits)	BLE encryption	10m proximity
Cloud API	HTTPS/REST	Username/password + JWT	TLS 1.2	Internet-facing
Mobile App	N/A (local)	Biometric + PIN	App sandbox	Device-local
Wi-Fi Network	802.11 b/g/n	WPA2-PSK	AES	Home network

Step 2: Apply STRIDE to Each Component

Component: Smart Lock Device

STRIDE	Threat	Attack Scenario	DREAD	Mitigation
S	BLE spoofing	Attacker impersonates mobile app, sends unlock command	7.2	Use BLE Secure Connections with ECDH key exchange
T	Firmware tampering	Attacker opens lock, extracts firmware via UART, modifies code	6.8	Enable secure boot with signed firmware, disable UART in production
R	Repudiation	User denies unlocking door during burglary	5.0	Encrypted audit log with server-side timestamp verification
I	Key extraction	Attacker sniffs BLE pairing, recovers pairing key	8.0	Use out-of-band (OOB) pairing with NFC tap instead of numeric code
D	Battery drain DoS	Attacker floods lock with BLE connection requests, drains battery	6.5	Rate-limit BLE connection attempts, enter low-power mode after 3 failures
E	Debug port access	Attacker uses JTAG to gain root shell, reprograms lock behavior	7.5	Blow JTAG fuses in production firmware, enable read-out protection

Component: Cloud Backend

STRIDE	Threat	Attack Scenario	DREAD	Mitigation
S	Account takeover	Attacker phishes user credentials, logs into cloud account	8.5	Enforce MFA (SMS or authenticator app) for all accounts
T	Access log tampering	Attacker deletes their unauthorized unlock events from cloud logs	6.0	Write logs to immutable storage (S3 with Object Lock), SIEM integration
R	Admin denies action	Cloud admin denies deleting user account that caused lockout	4.0	CloudTrail logging with cryptographic integrity verification
I	API key leak	Developer accidentally commits AWS keys to public GitHub repo	9.0	Use AWS Secrets Manager, enable secret scanning on GitHub, rotate keys immediately
D	API rate exhaustion	Attacker floods API with requests, prevents legitimate unlock commands	7.5	Implement per-user rate limits (10 unlocks/minute), AWS WAF for DDoS protection
E	SQL injection	Attacker injects SQL in username field, gains database access	8.0	Use parameterized queries (prepared statements), input validation, least-privilege DB user

Component: Mobile App

STRIDE	Threat	Attack Scenario	DREAD	Mitigation
S	App impersonation	Malicious app pretends to be real smart lock app, steals credentials	7.0	Certificate pinning to prevent MITM, app signature verification
T	Local data tampering	Attacker roots phone, modifies app to bypass biometric check	6.5	Store sensitive data in iOS Keychain / Android Keystore, detect jailbreak/root
R	User denies unlock	User claims they didn’t unlock door remotely	5.5	Server-side audit log with device fingerprint (not just client-reported)
I	Hardcoded API key	Reverse engineer app binary, extract hardcoded cloud API credentials	8.5	Never hardcode secrets, fetch API keys from secure backend after user auth
D	Crash exploit	Malformed Bluetooth data crashes app, prevents unlock	6.0	Input validation on all BLE data, exception handling, crash reporting
E	Privilege escalation	Exploit app vulnerability to access other apps’ data on phone	5.0	Use OS sandboxing, minimize requested permissions, security code review

Step 3: Prioritize Using DREAD (Top 10 Critical Threats)

Rank	Threat	Component	DREAD	Priority Justification
1	API key leak	Cloud	9.0	Immediate full system compromise, affects all users
2	Hardcoded API secret	Mobile App	8.5	One app reverse-engineering compromises all accounts
3	Account takeover via phishing	Cloud	8.5	Direct access to unlock door remotely, no physical presence required
4	SQL injection	Cloud	8.0	Database breach exposes all user data + allows backdoor creation
5	BLE key extraction	Smart Lock	8.0	Attacker can clone key, unlock door at will
6	API rate exhaustion	Cloud	7.5	Prevents emergency unlock for all users (safety issue)
7	JTAG debug access	Smart Lock	7.5	Physical access enables complete device reprogramming
8	BLE spoofing attack	Smart Lock	7.2	Attacker can unlock door from 10m proximity
9	App impersonation	Mobile App	7.0	User installs fake app, provides credentials to attacker
10	Firmware tampering	Smart Lock	6.8	Requires physical access + expertise, but enables persistent backdoor

Step 4: Design Mitigations (Top 5 Threats)

Threat #1: API Key Leak (DREAD 9.0)

• Mitigation: Use AWS Secrets Manager with automatic rotation every 30 days
• Implementation: pip install boto3; secrets_manager.get_secret_value(SecretId='smart-lock-api-key')
• Cost: $0.40/secret/month
• Risk Reduction: 9.0 → 2.0 (78% reduction)
• Residual Risk: Insider threat with AWS console access

Threat #2: Hardcoded App Secret (DREAD 8.5)

• Mitigation: Fetch API credentials from backend after user authentication
• Implementation: POST /auth/get_api_token (requires valid JWT)
• Cost: Negligible (add 1 API endpoint)
• Risk Reduction: 8.5 → 3.5 (59% reduction)
• Residual Risk: Sophisticated attacker can still extract token from memory during runtime

Threat #3: Account Takeover (DREAD 8.5)

• Mitigation: Enforce MFA via SMS or TOTP (Google Authenticator)
• Implementation: AWS Cognito with MFA enabled
• Cost: $0.0055 per SMS (TOTP is free)
• Risk Reduction: 8.5 → 3.0 (65% reduction)
• Residual Risk: SIM swapping attacks bypass SMS-based MFA

Threat #4: SQL Injection (DREAD 8.0)

• Mitigation: Use ORM with parameterized queries (e.g., SQLAlchemy), input validation
• Implementation: session.query(User).filter(User.username == :username) (never string concatenation)
• Cost: No additional cost (development best practice)
• Risk Reduction: 8.0 → 1.5 (81% reduction)
• Residual Risk: Second-order SQL injection in rare edge cases

Threat #5: BLE Key Extraction (DREAD 8.0)

• Mitigation: Use BLE Secure Connections with ECDH, implement out-of-band (NFC) pairing
• Implementation: Replace 6-digit pairing code with NFC tap-to-pair
• Cost: $2 per lock (NFC chip)
• Risk Reduction: 8.0 → 3.0 (63% reduction)
• Residual Risk: Physical proximity still required but much harder to sniff ECDH exchange

Step 5: Calculate Overall Risk Reduction

Before Mitigations:

• Top 5 threats combined DREAD: 42.8/50 (85.6%)
• Overall system risk: CRITICAL

After Mitigations:

• Top 5 threats combined DREAD: 13.0/50 (26.0%)
• Overall system risk: MEDIUM

Investment Required:

• Development: 120 hours ($12,000 at $100/hour)
• AWS services: $50/month ongoing
• NFC hardware: $2/lock × 10,000 units = $20,000

Total: $32,050 initial + $600/year ongoing

Benefit: Reduced probability of successful attack from 85.6% to 26.0% (approximately 70% risk reduction)

Key Insight: Systematic threat modeling identifies 30+ potential threats. Prioritizing the top 5 with DREAD achieves 70% risk reduction for $32K investment. Addressing all 30 threats would cost $200K+ with diminishing returns on the remaining 30% risk.

Decision Framework: When to Use Which Threat Modeling Methodology

Different threat modeling approaches suit different contexts. Choose based on your system maturity, team expertise, and risk profile:

Methodology	Best For	Time Required	Expertise Level	Artifact	Strengths	Limitations
STRIDE (Microsoft)	Mature systems, component-level analysis	4-8 hours per system	Medium	Threat matrix with 6 categories	Comprehensive, widely adopted, maps to mitigations	Can be overwhelming (generates 50+ threats)
DREAD (Risk scoring)	Prioritizing discovered threats	15 min per threat	Low	Risk scores (0-10 scale)	Quantifies risk, forces prioritization	Subjective, scores vary by assessor
Attack Trees (Schneier)	Complex attack chains, visual analysis	2-4 hours per scenario	High	Tree diagram with AND/OR gates	Shows attack paths, calculates probability	Time-consuming, requires security expertise
PASTA (Process for Attack Simulation and Threat Analysis)	Enterprise systems, regulatory compliance	2-4 weeks	High	7-stage report	Risk-centric, business-context aware	Heavy process, requires dedicated resources
LINDDUN (Privacy-focused)	Systems with sensitive data, GDPR compliance	4-8 hours	Medium	Privacy threat matrix	Systematic privacy analysis	Misses non-privacy security threats
VAST (Visual, Agile, Simple)	Agile teams, continuous integration	2 hours per sprint	Low	Threat cards	Lightweight, integrates with Agile	Less comprehensive than STRIDE

Decision Tree for Methodology Selection:

START: What is your primary concern?

├─ Comprehensive security coverage for new system design?
│  └─ Use: STRIDE
│     └─ When: Architecture design phase, before code written
│     └─ Output: 30-50 threats across all STRIDE categories
│
├─ Prioritizing which vulnerabilities to fix first?
│  └─ Use: DREAD
│     └─ When: After pen test, security scan, or STRIDE analysis
│     └─ Output: Ranked list of threats with quantified risk scores
│
├─ Understanding how sophisticated attackers bypass multiple defenses?
│  └─ Use: Attack Trees
│     └─ When: High-value targets, nation-state threat model
│     └─ Output: Visual attack paths with probability calculations
│
├─ Regulatory compliance requirement (SOC 2, ISO 27001)?
│  └─ Use: PASTA
│     └─ When: Enterprise systems, audit preparation
│     └─ Output: Formal threat analysis document for auditors
│
├─ GDPR/privacy-specific analysis?
│  └─ Use: LINDDUN
│     └─ When: Systems processing personal data in EU
│     └─ Output: Privacy threat matrix + GDPR compliance gaps
│
└─ Agile team with 2-week sprints, limited time?
   └─ Use: VAST
      └─ When: Fast-moving startups, continuous delivery
      └─ Output: Lightweight threat cards integrated into backlog

Hybrid Approach for IoT Systems (Recommended):

Phase 1: Design (Before Implementation)

• Use STRIDE for comprehensive threat identification
• Time: 1 full-day workshop with architects + security team
• Output: 40-60 threats documented

Phase 2: Prioritization (After Phase 1)

• Use DREAD to score all STRIDE threats
• Time: 2-3 hours (15 min per threat × 40 threats)
• Output: Ranked threat list, top 10 prioritized

Phase 3: Defense Planning (For Top 10 Threats)

• Use Attack Trees for the top 3 highest-DREAD threats
• Time: 1 hour per attack tree
• Output: Visual attack paths showing how defense layers interact

Phase 4: Continuous (During Development)

• Use VAST for new features added in sprints
• Time: 30 minutes per sprint planning
• Output: Threat cards in Jira/backlog

Total Time Investment: 16 hours initially + 30 min per sprint ongoing

Example Schedule:

• Week 1: STRIDE workshop (8 hours)
• Week 2: DREAD scoring (3 hours) + Attack trees for top 3 (3 hours)
• Week 3-12: VAST threat cards (30 min × 10 sprints = 5 hours)

Key Principle: Use comprehensive methods (STRIDE) at design time when changes are cheap. Use lightweight methods (VAST) during implementation when detailed analysis would slow development. Use scoring methods (DREAD) to bridge the gap and prioritize limited resources.

Common Mistake: Stopping Threat Modeling After Initial Analysis

The Mistake: A development team conducts a comprehensive STRIDE analysis before launching their IoT smart camera product. They document 45 threats, implement mitigations for the top 15, and consider threat modeling “complete.” Two years later, the product is compromised via a vulnerability that didn’t exist at launch.

What Went Wrong:

Original Threat Model (2022):

• System: Smart camera with RTSP streaming over local network
• Assumption: “Device will only be used on home networks behind NAT firewall”
• Threat: “Internet exposure” scored as LOW (DREAD 3.0) because “users won’t port-forward”

Reality (2024):

• New feature added: Cloud recording service
• Required change: Camera now accepts inbound connections from cloud service
• Result: Cameras are now internet-accessible via cloud relay
• Threat model was never updated

Vulnerability: Cloud relay had authentication bypass bug (CVE-2024-XXXX). Attackers scanned for exposed cloud relay endpoints, bypassed auth, accessed camera feeds for 50,000+ devices.

Root Cause: The original threat model’s assumption (“local network only”) became invalid when cloud features were added, but no one updated the threat model.

The Correct Approach: Living Threat Models

Threat modeling is not a one-time activity. It must evolve with the system.

Triggers for Threat Model Updates:

Trigger	Update Required	Example
New Feature	Re-run STRIDE for new components	Cloud integration added → analyze cloud API threats
Architecture Change	Re-evaluate trust boundaries	Switched from local processing to cloud AI → new data flows
Dependency Update	Check for new CVEs	OpenSSL update patches Heartbleed → remove “encryption broken” threat
New Attack Discovered (in wild)	Add to threat model	Zero-day found in similar product → check if we’re vulnerable
Regulatory Change	Add compliance threats	GDPR enacted → add “unlawful data processing” to LINDDUN analysis
Deployment Context Change	Re-score DREAD	Device now used in hospitals → increase impact scores for availability threats
Yearly Review	Full STRIDE re-run	Annual security review → identify assumption drift

Threat Model Versioning Example:

v1.0 (2022-01-15): Initial product launch - 45 threats identified - 15 mitigated, 12 accepted risk, 18 deferred

v1.1 (2022-06-20): Mobile app added - 8 new mobile-specific threats (app reverse engineering, credential storage) - 6 mitigated, 2 accepted

v2.0 (2023-03-10): Cloud recording feature - 15 new cloud threats (API authentication, data residency, service availability) - Re-scored existing “internet exposure” threat: 3.0 → 8.5 (now CRITICAL) - 12 mitigated, 3 accepted

v2.1 (2023-11-05): Log4Shell vulnerability discovered (CVE-2021-44228) - Checked: Camera uses Log4j in cloud service - Added “Log4Shell exploitation” threat (DREAD 9.5) - Patched within 48 hours, removed from threat model

v3.0 (2024-01-15): Annual review - 3 previously-accepted risks re-evaluated (now higher priority due to deployment scale increase) - 2 mitigations found inadequate (firmware signature check bypassed by researcher) - 5 threats removed (deprecated features no longer in product)

Threat Model Maintenance Checklist:

• Monthly: Review CVE disclosures for dependencies (NIST NVD, vendor advisories)
• Quarterly: Review incident reports from SOC/support for unexpected attack patterns
• Semi-Annually: Re-score DREAD for all HIGH/CRITICAL threats (impact may change as deployment scales)
• Annually: Full STRIDE re-run with entire architecture team
• Ad-hoc: Update within 1 week of major feature changes or architecture decisions

Metrics to Track:

Metric	Target	Current (Example)
Threat model version	Updated per checklist	v3.2 (last updated 45 days ago)
Open threats (unmitigated)	<10 CRITICAL, <30 HIGH	2 CRITICAL, 18 HIGH
Average threat age	<90 days	62 days (healthy)
Mitigated threats	>80% of CRITICAL/HIGH	95% CRITICAL, 75% HIGH
Threat model coverage	100% of components	92% (new Zigbee module not yet analyzed)

Key Takeaway: A threat model is a living document, not a one-time deliverable. Systems evolve, attacks evolve, and threat models must evolve with them. Schedule regular reviews and trigger updates on every significant change. A 2-year-old threat model is essentially fiction.

Putting Numbers to It: STRIDE Risk Quantification

Systematic threat identification using STRIDE categories, with quantitative risk scoring per threat type.

STRIDE-to-Risk Formula: Each STRIDE threat scored on impact (I: 0-10) and likelihood (L: 0-10): \[\text{Risk} = I \times L\]

Working through an example: Given: Smart home gateway threat model with 6 STRIDE categories

STRIDE Category	Example Threat	Impact (0-10)	Likelihood (0-10)	Risk Score
Spoofing	Attacker impersonates legitimate device	8	7	\(8 \times 7 = 56\)
Tampering	Firmware modified to add backdoor	9	5	\(9 \times 5 = 45\)
Repudiation	User denies unauthorized command	3	6	\(3 \times 6 = 18\)
Information Disclosure	Network traffic eavesdropping reveals credentials	7	8	\(7 \times 8 = 56\)
Denial of Service	DDoS makes gateway unavailable	6	7	\(6 \times 7 = 42\)
Elevation of Privilege	Attacker gains admin access via vulnerability	10	6	\(10 \times 6 = 60\)

Step 1: Identify highest risk score: Elevation of Privilege = 60 (highest) Step 2: Prioritize for remediation: EoP → Spoofing & Info Disclosure (tied 56) → Tampering (45) → DoS (42) → Repudiation (18)

Result: Focus first on preventing privilege escalation vulnerabilities (authentication flaws, input validation bugs)

Aggregate System Risk: \[\text{Total Risk} = \sum_{i=1}^{n} I_i \times L_i = 56 + 45 + 18 + 56 + 42 + 60 = 277\] Normalized: \(\frac{277}{6 \times 100} = 0.462 = 46.2\%\) of maximum possible risk

After Mitigations (implement MFA, input validation, encryption): - Spoofing: \(8 \times 2 = 16\) (MFA reduces likelihood) - Tampering: \(9 \times 2 = 18\) (code signing reduces likelihood) - Info Disclosure: \(7 \times 3 = 21\) (TLS encryption reduces likelihood) - Elevation of Privilege: \(10 \times 2 = 20\) (input validation reduces likelihood)

New total: \(16 + 18 + 18 + 21 + 42 + 20 = 135\) (51% reduction)

In practice: STRIDE is qualitative (name the threats), but Risk = Impact × Likelihood makes it quantitative. This enables data-driven prioritization: “Fix Elevation of Privilege first (score 60) before addressing Repudiation (score 18).” Budget allocation: $60K security budget → allocate $60K × (60/277) = $13K to EoP mitigations.

Interactive DREAD Calculator:

Try scoring your own threats using the DREAD framework:

viewof damage = Inputs.range([0, 10], {value: 5, step: 1, label: "Damage (0-10)"})
viewof reproducibility = Inputs.range([0, 10], {value: 5, step: 1, label: "Reproducibility (0-10)"})
viewof exploitability = Inputs.range([0, 10], {value: 5, step: 1, label: "Exploitability (0-10)"})
viewof affectedUsers = Inputs.range([0, 10], {value: 5, step: 1, label: "Affected Users (0-10)"})
viewof discoverability = Inputs.range([0, 10], {value: 5, step: 1, label: "Discoverability (0-10)"})

dreadScore = (damage + reproducibility + exploitability + affectedUsers + discoverability) / 5

riskLevel = dreadScore >= 8 ? "CRITICAL" :
            dreadScore >= 6 ? "HIGH" :
            dreadScore >= 4 ? "MEDIUM" : "LOW"

riskColor = dreadScore >= 8 ? "#E74C3C" :
            dreadScore >= 6 ? "#E67E22" :
            dreadScore >= 4 ? "#3498DB" : "#16A085"

html`<div style="background: ${riskColor}; color: white; padding: 20px; border-radius: 8px; text-align: center; margin: 20px 0;">
  <h3 style="margin: 0; font-size: 24px;">DREAD Score: ${dreadScore.toFixed(1)}/10</h3>
  <p style="margin: 10px 0 0 0; font-size: 18px; font-weight: bold;">${riskLevel} Risk</p>
</div>`

Interpretation Guide:

• CRITICAL (8.0-10.0): Immediate mitigation required. Stop development until addressed.
• HIGH (6.0-7.9): Must fix before production release. Allocate dedicated resources.
• MEDIUM (4.0-5.9): Schedule for next sprint. Document compensating controls.
• LOW (0.0-3.9): Accept risk or address in future maintenance releases.

Concept Relationships

Understanding how threat modeling concepts interconnect across the 5-chapter series:

Core Concept	Prerequisite Knowledge	Builds Toward	Common Pitfall
Four Key Questions (Ch 1)	System architecture, asset inventory	STRIDE application, attack scenarios	Treating threat modeling as one-time deliverable (it’s iterative)
STRIDE Framework (Ch 2)	CIA triad, security properties	Systematic threat identification, OWASP mapping	Missing threats by skipping STRIDE categories (check ALL six)
DREAD Scoring (Ch 3)	Threat taxonomy (from STRIDE), risk assessment	Remediation prioritization, resource allocation	Unweighted averaging (Damage should outweigh Discoverability)
Attack Trees (Ch 1-3)	Probability theory (AND/OR gates), threat chains	Defense-in-depth ROI, weakest link identification	Confusing sequential (multiply) vs parallel (OR) probabilities
Trust Boundaries (Ch 1-2)	Data flow diagrams, authentication points	Entry point identification, segmentation design	Assuming same-network = same trust level
Threat Model Versioning (Ch 1, 5)	Architecture change tracking, CVE monitoring	Living documentation, continuous compliance	One-time threat model becomes stale fiction after 6 months

Key Insight: Threat modeling is not about predicting every possible attack—it’s about systematically thinking through “What could go wrong?” for each component. STRIDE ensures you don’t miss entire attack categories. DREAD ensures you fix the worst problems first.

See Also

This Threat Modeling Series (Navigate Within):

• Chapter 1: Introduction & Fundamentals - Four questions, decision trees, regulatory requirements
• Chapter 2: STRIDE Framework - Six threat categories, systematic identification
• Chapter 3: Attack Scenarios & Risk - Real-world IoT attack patterns, DREAD scoring
• Chapter 4: Assessments - Quizzes to validate threat modeling knowledge
• Chapter 5: Hands-On Lab - Interactive threat detection simulator

Foundational Security Concepts:

• Security Overview - CIA triad, security vs privacy
• Threats & Vulnerabilities - Comprehensive attack taxonomy
• Security Frameworks - OWASP IoT Top 10 maps to STRIDE categories

Implementation and Mitigation:

• Encryption Principles - Mitigating Information Disclosure (I) threats
• Device Security - Mitigating Tampering (T) and Elevation of Privilege (E)
• Secure Data - Mitigating Repudiation (R) threats with audit logs
• Compliance Frameworks - IEC 62443 threat modeling requirements, FDA SBOM

Learning Resources:

• Knowledge Map - Visual STRIDE/DREAD relationships
• Quiz Navigator - Threat modeling scenario quizzes
• Hands-On Labs Hub - All interactive security labs

Match the Threat Modeling Methodology

Order the Four Key Threat Modeling Questions

Label the Diagram

12.9 What’s Next

If you want to…	Read this
Apply STRIDE systematically to IoT threats	STRIDE Framework
Study the OWASP IoT Top 10 as a complementary framework	OWASP IoT Top 10
Explore realistic attack scenarios for validation	Threat Attack Scenarios
Apply threat models to security assessments	Threats Assessments
Return to the security module overview	IoT Security Fundamentals

Common Pitfalls

1. Threat modelling only once, at initial design

Threat models must be updated whenever the system architecture changes — when new device types are added, new integrations are built, or the deployment context changes. A stale threat model is worse than no threat model because it creates false confidence.

2. Creating threat models without involving operations teams

Security engineers designing threat models without input from the people who operate the system miss operational threats (misconfiguration, credential sharing, bypass procedures created for convenience) that are often more realistic than technical attack vectors.

3. Modelling threats without prioritising by exploitability and impact

A threat model listing 50 threats without prioritisation is not actionable. Apply DREAD scoring or a simple impact/likelihood matrix to identify the top 5–10 threats requiring immediate mitigation.

4. Confusing threat identification with mitigation selection

Threat modelling and control selection are distinct activities. First, identify threats without solution bias. Then, separately evaluate mitigation options for each threat based on effectiveness, cost, and operational impact.

💻 Code Challenge