13  STRIDE Framework & Taxonomies

13.1 Learning Objectives

By the end of this chapter, you will be able to:

  • Apply the STRIDE Model: Use Microsoft’s STRIDE framework to systematically identify threats
  • Understand Threat Taxonomies: Navigate comprehensive IoT threat classification systems
  • Map Threats to Security Properties: Connect STRIDE categories to CIA triad violations
  • Model Attack Scenarios: Build attack trees showing step-by-step compromise paths
  • Identify Entry Points: Map all attack surfaces across IoT system architecture
In 60 Seconds

STRIDE is a systematic threat classification framework that ensures comprehensive coverage of security threats by categorising every potential attack as Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, or Elevation of Privilege — applied to each component, data flow, and trust boundary in an IoT system diagram. Its power is that it turns threat identification from a creative brainstorming exercise into a structured checklist that reliably surfaces threats that would otherwise be overlooked.

Threat Modeling Series:

Security Context:

What is STRIDE? STRIDE is Microsoft’s threat modeling framework that helps you systematically identify six types of security threats: Spoofing (fake identity), Tampering (data modification), Repudiation (denying actions), Information disclosure (data leaks), Denial of service (making systems unavailable), and Elevation of privilege (gaining unauthorized access).

Why does it matter? STRIDE provides a checklist to ensure you don’t miss common vulnerability classes. Instead of guessing what might go wrong, you systematically ask: “Can an attacker spoof identity here? Can they tamper with data? Can they deny they did something?” This structured approach catches threats that ad-hoc brainstorming misses.

“STRIDE is my favorite security tool!” Max the Microcontroller said. “It gives us six questions to ask about every part of our system. Think of it as a six-point inspection, like when a mechanic checks your car.”

Sammy the Sensor listed them out. “S is for Spoofing – can someone pretend to be me and send fake sensor data? T is for Tampering – can someone change my readings while they travel across the network? R is for Repudiation – can someone do something bad and then deny they did it because there are no logs?”

Lila the LED continued. “I is for Information disclosure – can someone eavesdrop on private data? D is for Denial of service – can someone flood me with so many requests that I crash and real users cannot get through? E is for Elevation of privilege – can a regular user somehow get administrator access?”

“The magic of STRIDE is that it maps perfectly to security defenses,” Bella the Battery concluded. “Spoofing? Fix it with authentication. Tampering? Fix it with integrity checks. Repudiation? Fix it with logging. Information disclosure? Fix it with encryption. Denial of service? Fix it with rate limiting. Elevation of privilege? Fix it with authorization. Six problems, six solutions – it is beautifully organized!”

Key terms: | Term | Maps To | IoT Example | |——|———|————-| | Spoofing | Authentication | Attacker sends fake sensor data pretending to be legitimate device | | Tampering | Integrity | Attacker modifies firmware to inject malware | | Repudiation | Non-repudiation | Malicious user deletes audit logs to hide their actions | | Information Disclosure | Confidentiality | Attacker intercepts unencrypted Wi-Fi to steal passwords | | Denial of Service | Availability | Botnet floods IoT gateway with traffic, making it unresponsive | | Elevation of Privilege | Authorization | Attacker exploits firmware bug to gain root access |

MVU: STRIDE Threat Modeling

Core Concept: STRIDE systematically identifies six threat categories (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) by asking what can go wrong at each component and trust boundary. Why It Matters: Ad-hoc threat analysis misses vulnerability classes; STRIDE’s structured checklist catches 95% of common IoT security flaws. Key Takeaway: Apply STRIDE at every trust boundary (device→gateway, gateway→cloud, user→app) to systematically uncover attack vectors.

13.2 Introduction

Effective security requires systematic threat identification. While ad-hoc brainstorming might catch obvious vulnerabilities, it consistently misses entire classes of threats. Microsoft’s STRIDE framework provides a structured methodology to ensure comprehensive coverage across all threat categories.

This chapter introduces STRIDE and complementary threat taxonomies from ENISA, OWASP, and the Open Threat Taxonomy. You’ll learn how to apply STRIDE at IoT system trust boundaries, map threats to security properties, and quantify risk using the DREAD scoring system. The chapter culminates in a complete worked example analyzing a smart water meter deployment across four trust boundaries.

By mastering these frameworks, you’ll transform from reactive security patching to proactive threat modeling that identifies vulnerabilities before attackers exploit them.

13.3 Threat Modelling Process

⏱️ ~15 min | ⭐⭐ Intermediate | 📋 P11.C05.U02

Key Concepts

  • Spoofing: Impersonating another device, user, or service to gain illegitimate access — mitigated by strong authentication (certificates, challenge-response) and anti-replay mechanisms.
  • Tampering: Unauthorised modification of data in transit or at rest — mitigated by cryptographic integrity protection (HMAC, digital signatures, TLS) and access control.
  • Repudiation: The ability to deny performing an action, making accountability impossible — mitigated by comprehensive, tamper-resistant audit logging and digital signatures on actions.
  • Information Disclosure: Unauthorised exposure of sensitive data (credentials, sensor readings, personal information) — mitigated by encryption at rest and in transit, access control, and data minimisation.
  • Denial of Service: Attacks preventing legitimate use of the IoT system by exhausting resources or disrupting communications — mitigated by rate limiting, resource quotas, and resilient network design.
  • Elevation of Privilege: An attacker gaining higher-level access than authorised — mitigated by least-privilege design, privilege separation, and input validation to prevent code execution vulnerabilities.

Threat Modelling: Structured analysis of system vulnerabilities from an attacker’s perspective to identify risks, quantify likelihood and severity, and prioritize mitigation mechanisms.

How It Works: Applying STRIDE to IoT Trust Boundaries

STRIDE threat modeling systematically analyzes security at trust boundaries where different security contexts meet:

Step 1: Identify Trust Boundaries A trust boundary exists wherever: - Data crosses network segments (device → gateway, gateway → cloud) - Privilege levels change (user → admin, guest → authenticated) - Security contexts differ (encrypted → plaintext, internal → external)

Step 2: Apply STRIDE at Each Boundary For IoT device → Cloud gateway boundary, ask:

STRIDE Category Boundary Question IoT Example
Spoofing Can identity be faked across this boundary? Rogue device impersonates legitimate sensor
Tampering Can data be modified crossing this boundary? MITM modifies sensor reading in transit
Repudiation Can actions be denied at this boundary? Device claims it never sent specific data
Information Disclosure Can data leak at this boundary? Unencrypted Wi-Fi exposes sensor readings
Denial of Service Can this boundary be overwhelmed? Flood gateway with device requests
Elevation of Privilege Can access be escalated at this boundary? Device exploits gateway vulnerability to gain admin

Step 3: Document Threats Each STRIDE category maps to security controls: - Spoofing → Authentication (device certificates) - Tampering → Integrity (HMAC signatures) - Repudiation → Logging (immutable audit trail) - Information Disclosure → Confidentiality (TLS encryption) - Denial of Service → Availability (rate limiting) - Elevation of Privilege → Authorization (RBAC)

Step 4: Prioritize by DREAD Score each threat (0-10): - Damage potential - Reproducibility - Exploitability - Affected users - Discoverability

13.3.1 Interactive: DREAD Risk Calculator

Calculate the DREAD risk score for a threat by rating each of the five factors from 0-10:

13.3.2 Five-Step Process

Five-step threat modeling process flowchart progressing from system architecture decomposition through trust boundary identification, threat enumeration using STRIDE categories, risk assessment with DREAD scoring, to attack scenario development and mitigation planning

Five-step threat modeling process
Figure 13.1: Five-Step Threat Modeling Process: From Architecture to Attack Scenarios

This view shows how organizations progress through threat modeling maturity, from reactive to proactive security:

Security concept diagram for threats stride framework

Assessment Questions:

  • Level 1: Do you only address security after breaches? (Start here)
  • Level 2: Do you have security checklists but apply them inconsistently?
  • Level 3: Is threat modeling integrated into your design process?
  • Level 4: Do you measure and track security metrics continuously?
  • Level 5: Can you predict and prevent threats before they materialize?

1. Architecture Knowledge:

  • Identify all components (sensors, gateways, cloud services)
  • Map communication protocols
  • Document data storage locations
  • Understand key entities and their roles

2. Entry Points:

  • Physical interfaces (UART, JTAG, USB)
  • Network interfaces (Wi-Fi, Bluetooth, cellular)
  • Application interfaces (APIs, web portals)
  • Update mechanisms (OTA firmware)

3. Data Flow Paths:

  • Source → Processing → Storage → Transmission
  • Identify where data is encrypted/decrypted
  • Map authentication and authorization points

4. Trust Boundaries:

  • IoT device (often least trusted)
  • Gateway (may be trusted if secured)
  • Cloud services (typically most trusted)
  • User/admin interfaces

5. Attack Scenarios:

  • Based on experience and threat intelligence
  • Consider Advanced Persistent Threats (APTs)
  • Model both opportunistic and targeted attacks

13.4 Threat Taxonomies

⏱️ ~12 min | ⭐⭐ Intermediate | 📋 P11.C05.U03

Comprehensive threat taxonomy diagram showing hierarchical classification of IoT security threats organized into categories including spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege with subcategories and real-world IoT attack examples
Figure 13.2: Threat categories part 1
Continuation of threat taxonomy showing technical threats including credential discovery, privilege escalation, cryptanalysis, denial of service attacks, data manipulation in transit, and application exploitation vulnerabilities specific to IoT systems
Figure 13.3: Threat categories part 2
Geometric visualization of the IoT threat landscape showing the full spectrum of security threats organized by attack surface. The diagram presents device-level threats, network-level attacks, application vulnerabilities, and cloud service risks in an interconnected geometric pattern. Each threat type is color-coded by severity and connected to show attack chain relationships and lateral movement possibilities.
Figure 13.4: IoT Threat Landscape - Comprehensive geometric view of security threats

The threat landscape visualization helps security teams understand the breadth of potential attack vectors and prioritize defensive investments based on organizational risk profiles.

Geometric diagram analyzing IoT attack surfaces across the technology stack. The visualization maps entry points from physical device interfaces through network protocols to cloud APIs, showing how each surface area can be exploited. Attack surface metrics indicate relative exposure levels and recommended security controls for each entry point category.
Figure 13.5: Threat Surface - Geometric analysis of attack entry points
Geometric representation of a comprehensive IoT threat taxonomy organized into hierarchical categories. The structure shows relationships between threat actors, attack vectors, vulnerabilities, and impacts. Each node represents a specific threat type with connections showing how threats can combine or escalate into more severe attack scenarios.
Figure 13.6: Threat Taxonomy - Hierarchical geometric classification of IoT threats

This structured taxonomy provides a systematic framework for threat identification during security assessments and penetration testing engagements.

IoT threats impact assessment diagram showing weighted threat severity ratings organized in a circular visualization. The diagram displays various threat categories including unauthorized access, data breaches, denial of service, and physical tampering, with impact scores ranging from low to critical based on factors such as likelihood of occurrence, potential damage, and affected user base. Central IoT device icon surrounded by threat vectors demonstrates the multi-dimensional attack surface that IoT systems face.
Figure 13.7: Source: University of Edinburgh IoT Security Course - Figure 9: IoT threats impact
Comprehensive IoT threat taxonomy (Figure 8) showing complete classification of threats organized into major categories: Outages (device destruction, system failures), Disasters (floods, fires, power anomalies), Damage/Loss of IT Assets (data-sensitive leakage), Failures/Malfunctions (configuration errors, software vulnerabilities, third-party failures), and Eavesdropping/Interception/Hijacking (man-in-the-middle attacks, session hijacking, traffic analysis). Additional categories include Nefarious Activity covering social engineering, identity theft, denial of service, advanced persistent threats, botnets, exploitation of software bugs, manipulation of information, and unauthorized activities. Each category maps to specific IoT attack vectors and mitigation strategies.
Figure 13.8: Source: University of Edinburgh IoT Security Course - Figure 8: IoT Threat taxonomy

13.4.1 STRIDE (Microsoft)

Microsoft STRIDE threat modeling framework showing six threat categories mapped to security properties: Spoofing attacks authentication, Tampering attacks integrity, Repudiation attacks non-repudiation, Information Disclosure attacks confidentiality, Denial of Service attacks availability, and Elevation of Privilege attacks authorization
Figure 13.9: STRIDE threat model
Educational diagram presenting STRIDE threat model with teaching-focused annotations and step-by-step guidance. Each threat category includes learning prompts, real-world IoT examples, and suggested mitigation strategies. The pedagogical design uses color coding to distinguish between threat types and their corresponding security controls.
Figure 13.10: STRIDE Framework - Pedagogical version designed for classroom instruction

This teaching-oriented visualization helps students systematically work through each STRIDE category when analyzing IoT system security.

Detailed STRIDE model diagram showing comprehensive breakdown of each threat category with specific attack techniques and countermeasures. The visualization includes attack trees for each category, mapping common IoT vulnerabilities to STRIDE classifications and recommended security controls.
Figure 13.11: STRIDE Model - Detailed breakdown with attack techniques and countermeasures

STRIDE: Comprehensive threat classification model applicable across IoT system components.

STRIDE threat classification model showing six categories: Spoofing targeting authentication, Tampering targeting integrity, Repudiation targeting non-repudiation, Information Disclosure targeting confidentiality, Denial of Service targeting availability, and Elevation of Privilege targeting authorization, each with IoT-specific attack examples

STRIDE threat model with IoT attack examples
Figure 13.12: STRIDE Threat Model: Six Categories with IoT Attack Examples

This view maps each STRIDE threat category to specific defensive controls, showing the complete mitigation strategy:

Security diagram showing threats vectors and mitigations

IoT-Specific Defense Implementation:

STRIDE Primary Defense IoT Implementation Cost Impact
Spoofing Device certificates X.509 in secure element +$2-5/device
Tampering Secure boot + TPM Hardware root of trust +$3-8/device
Repudiation Blockchain audit Distributed ledger logging +$1-2/device
Information Disclosure E2E encryption TLS 1.3 + encrypted storage +$1-3/device
Denial of Service Rate limiting Edge firewall + CDN +$0.50-2/device
Elevation of Privilege RBAC + sandboxing Container isolation +$1-3/device

STRIDE Mapping to Security Properties:

STRIDE Category Security Property Attack Example
Spoofing Authentication Attacker impersonates legitimate IoT device
Tampering Integrity Modify sensor readings or firmware
Repudiation Non-Repudiation Deny sending malicious commands
Information Disclosure Confidentiality Intercept unencrypted sensor data
Denial of Service Availability Flood network with requests
Elevation of Privilege Authorization Gain admin access from user account

13.4.2 Open Threat Taxonomy

Four Threat Categories:

Open threat taxonomy classifying IoT threats into four categories: physical threats including environmental hazards and hardware tampering, resource threats covering infrastructure and supply chain, personnel threats from insider risks and social engineering, and technical threats including credential attacks, privilege escalation, and denial of service

Open threat taxonomy categories
Figure 13.13: Open Threat Taxonomy: Physical, Resource, Personnel, and Technical Threats

Technical Threats (Most Common in IoT):

  • Credential discovery (sniffing, brute forcing, cracking)
  • Escalation/abuse of system privileges
  • Cryptanalysis
  • Denial of Service (DoS)
  • Data capture/manipulation in transit
  • Application exploitation (code injection, reverse engineering, API abuse)

Severity Rating: Each threat rated 1-5 based on likelihood and impact.

13.4.3 ENISA IoT Threat Taxonomy

European Union Agency for Cybersecurity (ENISA) IoT threat taxonomy part 1 showing asset categories including devices, sensors, actuators, communication networks, protocols, data storage, processing, cloud services and applications with associated threat vectors
Figure 13.14: ENISA IoT threat taxonomy part 1
ENISA IoT threat taxonomy part 2 detailing threat categories: nefarious activity/abuse, eavesdropping/interception, physical attacks, outages and service disruption, and legal/regulatory compliance violations with specific IoT examples
Figure 13.15: ENISA IoT threat taxonomy part 2
ENISA IoT threat taxonomy part 3 presenting vulnerability categories including hardware vulnerabilities (side-channel attacks, fault injection), software vulnerabilities (code flaws, backdoors), network protocol weaknesses, and human vulnerabilities through social engineering
Figure 13.16: ENISA IoT threat taxonomy part 3

European Union Agency for Cybersecurity (ENISA) provides IoT-specific threat taxonomy.

ENISA IoT framework classifying assets including devices, sensors, communication networks, cloud services, and applications alongside associated threat vectors and vulnerability categories for comprehensive security assessment

ENISA IoT threat framework classification
Figure 13.17: ENISA IoT Framework: Assets, Threats, and Vulnerabilities Classification

13.4.4 IoT Threat Taxonomy: A Structured View

Understanding threats requires systematic categorization across the entire IoT stack. The following mindmap provides a comprehensive view of threats organized by layer:

Comprehensive IoT threat taxonomy mind map organized by layer: physical layer threats including tampering and side-channel attacks, network layer threats including eavesdropping and jamming, application layer threats including injection and API abuse, and supply chain threats including counterfeit components and firmware backdoors

IoT threat taxonomy mind map
Figure 13.18: IoT Threat Taxonomy Mindmap: Physical, Network, Application, and Supply Chain Layers

13.4.4.1 Attack Surface by IoT Component

Each component in an IoT system presents unique vulnerabilities that attackers can exploit:

Component Primary Threats Impact Mitigation Priority
Sensors Spoofing, tampering Data integrity Medium
MCU/SoC Side-channel, fault injection Complete compromise High
Radio Eavesdropping, jamming Availability, privacy High
Gateway MITM, privilege escalation Network pivot Critical
Cloud API Injection, auth bypass Mass compromise Critical
Mobile App Reverse engineering, credential theft Account takeover High
Critical Insight: The Weakest Link

IoT security is only as strong as the weakest component. A secure cloud API is worthless if device firmware accepts unsigned updates. Defense in depth requires securing every layer.

13.5 Worked Example: STRIDE Analysis of a Smart Water Meter System

Scenario: A water utility deploys 50,000 smart meters communicating via LoRaWAN to 200 gateways, which forward usage data to a cloud billing platform via HTTPS. Each meter reports hourly consumption (4-byte reading + 8-byte timestamp + 2-byte meter ID). Apply STRIDE to identify threats at each trust boundary.

Trust Boundaries Identified:

  1. Meter-to-Gateway (LoRaWAN, 868 MHz)
  2. Gateway-to-Cloud (HTTPS over 4G)
  3. Cloud API-to-Billing System (internal REST)
  4. Billing System-to-Customer Portal (HTTPS)

STRIDE Analysis at Trust Boundary 1: Meter-to-Gateway

STRIDE Category Specific Threat Severity Mitigation
Spoofing Attacker clones a meter’s DevEUI and AppKey to inject false readings HIGH LoRaWAN 1.1 join server with per-device root keys; hardware secure element stores AppKey
Tampering Attacker modifies meter reading in transit (e.g., reduces water usage to lower bill) HIGH LoRaWAN MIC (Message Integrity Code) using AES-128-CMAC; any modification invalidates 4-byte MIC
Repudiation Customer claims meter reading was forged by utility MEDIUM Server-side log with MIC verification proof; tamper-evident meter seal with photo documentation
Info Disclosure Attacker eavesdrops on consumption patterns to determine occupancy MEDIUM LoRaWAN AppSKey encryption (AES-128-CTR); attacker sees encrypted payload only
Denial of Service Attacker jams 868 MHz band near gateway, blocking 250 meters HIGH Redundant gateways with overlapping coverage; ADR (Adaptive Data Rate) to increase power
Elevation of Privilege Compromised meter sends administrative commands to gateway LOW LoRaWAN Class A devices are receive-only during RX windows; meters cannot initiate commands

Quantified Risk: Spoofing Attack Economics

Attack cost to clone one meter:
  SDR hardware (HackRF One): $300
  Capture join request: 1 hour monitoring
  Brute-force 128-bit AppKey: Infeasible (2^128 operations)
  Alternative: Extract AppKey from physical meter: $50 (JTAG probe)
  Total attack cost per meter: $350

Impact of successful spoofing:
  Average water bill: $60/month
  Maximum billing fraud per meter: $720/year
  Payback period for attacker: 6 months (for single meter)

Mitigation cost:
  Hardware secure element (ATECC608B): $0.65/meter
  50,000 meters: $32,500 total
  Makes AppKey extraction infeasible (hardware tamper protection)

ROI calculation:
  If 1% of meters were compromised: 500 meters × $720/year = $360,000/year
  If 10% were compromised: 5,000 meters × $720/year = $3.6M/year
  $32,500 investment prevents potential multi-million dollar fraud

Key Finding: The STRIDE analysis reveals that Denial of Service (gateway jamming) is the highest-impact threat because it affects 250 meters per gateway, while Spoofing has the highest fraud potential but requires physical access. The Elevation of Privilege risk is inherently low due to LoRaWAN’s asymmetric architecture where meters cannot send administrative commands.

Concept Relationships
Concept Relates To Nature of Relationship
STRIDE Categories Security Properties Each STRIDE threat violates specific security principle
Trust Boundaries Attack Surface Boundaries mark security context transitions
ENISA Taxonomy STRIDE Mapping Both frameworks classify threats but at different granularities
Attack Trees Threat Decomposition Trees show step-by-step paths to achieve STRIDE goals
Threat Modeling Defense in Depth Systematic threat ID informs layered protection design
IoT Attack Surfaces Component Analysis Each system layer (device, network, cloud) has distinct threats
See Also

STRIDE Application:

Taxonomies:

Practical Application:

Regulatory Context:

13.6 Knowledge Check

STRIDE provides complete coverage of CIA triad violations through six orthogonal threat categories.

\[\text{Coverage} = \bigcup_{i=1}^{6} T_i \supseteq \{\text{Confidentiality}, \text{Integrity}, \text{Availability}, \text{Authentication}, \text{Authorization}, \text{Non-repudiation}\}\]

where \(T_i\) represents each STRIDE category.

Worked Calculation: Smart Water Meter Threat Count

Given: LoRaWAN smart meter with 4 trust boundaries (meter→gateway, gateway→cloud, cloud→API, API→billing)

Step 1: Calculate theoretical maximum threats - Trust boundaries: \(B = 4\) - STRIDE categories: \(S = 6\) - Maximum unique threats: \(T_{\max} = B \times S = 24\)

Step 2: Apply STRIDE at each boundary | Boundary | Spoofing | Tampering | Repudiation | Info Disc | DoS | Elev Priv | Total | |———-|———-|———–|————-|———–|—–|———–|——-| | Meter→Gateway | 2 | 3 | 1 | 2 | 2 | 1 | 11 | | Gateway→Cloud | 1 | 2 | 1 | 2 | 1 | 1 | 8 | | Cloud→API | 2 | 1 | 1 | 1 | 2 | 2 | 9 | | API→Billing | 1 | 1 | 1 | 2 | 1 | 1 | 7 | | TOTAL | 6 | 7 | 4 | 7 | 6 | 5 | 35 |

Step 3: Analyze threat distribution - Total threats identified: 35 - Theoretical maximum (4 boundaries × 6 categories): 24 - The 35 threats exceed the theoretical maximum because some threats span multiple boundaries (e.g., a DoS attack can affect both meter→gateway and gateway→cloud) - This overlap is expected in real systems where threats cascade across trust boundaries

Step 4: Calculate risk reduction per mitigation category | STRIDE Category | Threats | Avg DREAD | Mitigation Cost | Total Risk Reduction | |—————–|———|———–|—————–|———————| | Spoofing (6) | 6 | 7.2 | $8,000 (certs) | \(\Delta R = 6 \times 7.2 \times 0.85 = 36.7\) | | Tampering (7) | 7 | 8.1 | $3,000 (MIC) | \(\Delta R = 7 \times 8.1 \times 0.90 = 51.0\) | | Info Disclosure (7) | 7 | 8.6 | $2,000 (TLS) | \(\Delta R = 7 \times 8.6 \times 0.95 = 57.2\) |

Result: Information Disclosure mitigations provide highest risk reduction per dollar invested (57.2 / $2,000 = 0.029 vs Spoofing 36.7 / $8,000 = 0.0046).

In practice: STRIDE’s orthogonality ensures no threat category is missed. The 6-category framework maps to exactly 6 security properties, making it provably complete for security analysis.

13.7 What’s Next

If you want to… Read this
Apply STRIDE in depth to IoT system threat modelling Threat Modelling and Mitigation
Compare STRIDE with the OWASP IoT Top 10 approach OWASP IoT Top 10
Use STRIDE in realistic attack scenario development Threat Attack Scenarios
Apply STRIDE findings to security assessments Threats Assessments
Return to the security module overview IoT Security Fundamentals

Common Pitfalls

STRIDE threats arise at both components (devices, services) and data flows (communications between components). Applying STRIDE only to devices misses threats like man-in-the-middle (Tampering/Information Disclosure on data flows) and replay attacks (Spoofing on authentication flows).

STRIDE analysis produces a list of threats; its value is only realised when each identified threat is paired with specific mitigations and tracked through implementation. A threat list without mitigations is a vulnerability inventory, not a security plan.

Generic STRIDE templates list ‘potential spoofing on device authentication’ as a threat for every system. The value of STRIDE comes from specificity: ‘an attacker who can observe MQTT traffic can replay device credentials because the broker does not implement challenge-response authentication’.

STRIDE analysis conducted by a single security engineer misses domain knowledge held by firmware developers, network engineers, and field operators. STRIDE is most effective as a facilitated group exercise with diverse participants.

13.8 Summary

This chapter covered systematic threat identification using STRIDE and comprehensive threat taxonomies:

STRIDE Framework: Six threat categories that map to security properties - Spoofing attacks authentication - Tampering attacks integrity - Repudiation attacks non-repudiation - Information Disclosure attacks confidentiality - Denial of Service attacks availability - Elevation of Privilege attacks authorization

Threat Modeling Process: Five-step systematic analysis 1. Architecture knowledge (components, protocols, data flows) 2. Entry points (physical, network, application interfaces) 3. Data flow paths (where data is encrypted, authenticated) 4. Trust boundaries (device, gateway, cloud, user interfaces) 5. Attack scenarios (opportunistic and targeted threats)

IoT Attack Surfaces: Multiple layers of vulnerability - Device layer (firmware, debug ports, storage) - Network layer (protocols, wireless, APIs) - Application layer (mobile apps, web dashboards) - Cloud layer (APIs, databases, authentication) - Physical layer (tampering, theft, environmental)

Key Insight: IoT security is only as strong as the weakest link. A secure cloud API is worthless if device firmware accepts unsigned updates. Defense in depth requires securing every layer.

Continue to Attack Scenarios to see how these theoretical threats manifest in real-world IoT breaches.