14  Threat Landscape and STRIDE Model

Learning Objectives

After completing this chapter, you will be able to:

  • Classify IoT threat actors by skill level, motivation, and typical attack targets
  • Apply the STRIDE threat model (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) to IoT systems
  • Map attack vectors across physical, network, and application layers of IoT architectures
  • Evaluate the cyber-physical consequences of IoT security breaches versus traditional IT incidents
In 60 Seconds

The STRIDE model provides the structured vocabulary and categorisation system that makes IoT threat modelling systematic rather than arbitrary — each of the six categories (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) maps to a specific violated security property and a corresponding class of mitigations, enabling engineers to move efficiently from identified threats to selected controls.

IoT security is about protecting connected devices from hackers and other threats. Think of each smart device in your home as a door or window – each one could potentially let an intruder in if not properly secured. Understanding the threat landscape is the first step toward building systems that keep data safe and devices operating correctly.

“Did you know that in 2014, hackers used smart REFRIGERATORS to send spam emails?” Sammy the Sensor gasped. “Over 100,000 IoT devices were part of a botnet that no one even knew about! The owners had no idea their fridge was moonlighting as a spam machine.”

Max the Microcontroller pulled out a chart. “There are five types of attackers we need to watch for. Script kiddies use tools they find online – not very skilled, but they attack lots of devices. Cybercriminals are in it for money – they steal data and demand ransoms. Hacktivists want to make a political point. Insiders already have access to the system. And nation-states have unlimited budgets and the most advanced tools.”

“Each attacker type goes after different layers,” Lila the LED explained. “Physical attacks mean touching the device – opening it up, plugging into debug ports. Network attacks happen remotely – eavesdropping, man-in-the-middle interception. Application attacks target software – injecting malicious commands or exploiting bugs. You need defenses at every layer!”

“What makes IoT different from regular computer security is the cyber-physical connection,” Bella the Battery added. “If someone hacks a laptop, you might lose some files. But if someone hacks an IoT insulin pump or a smart car, people could be physically harmed. That is why IoT security is not just an IT problem – it is a safety issue that affects real lives!”

14.1 Threat Landscape Overview

Time: ~25 min | Level: Intermediate

Key Concepts

  • STRIDE-to-property mapping: Each STRIDE category violates a specific security property: Spoofing violates Authentication, Tampering violates Integrity, Repudiation violates Non-repudiation, Information Disclosure violates Confidentiality, DoS violates Availability, and EoP violates Authorisation.
  • Threat category to mitigation mapping: Each STRIDE category has a corresponding class of mitigations: Authentication controls for Spoofing, integrity verification for Tampering, audit logging for Repudiation, encryption for Information Disclosure, rate limiting for DoS, and least privilege for Elevation of Privilege.
  • Per-element analysis: The STRIDE methodology applied systematically to each entity, data flow, data store, and process in a Data Flow Diagram, ensuring no component is overlooked in the threat identification process.
  • Threat prioritisation: The process of ranking identified STRIDE threats by their risk (likelihood × impact) to focus mitigation effort on the most critical threats first.
  • Validation gate: A review step checking that each identified STRIDE threat has a corresponding documented mitigation, an assigned owner, and a defined validation test, before the design is approved.

Academic diagram showing IoT threat taxonomy organized by attack surface: physical layer attacks (tampering, side-channel), network layer attacks (eavesdropping, MITM, replay), and application layer attacks (injection, privilege escalation). Source: University of Edinburgh IoT Security Course.

IoT Threat Taxonomy showing attack categories across physical, network, and application layers

Source: University of Edinburgh - IoT Security Course Materials

Smart Refrigerators Hacked to Send Out Spam

In 2014, security researchers discovered that a botnet of over 100,000 compromised IoT devices—including smart refrigerators—was being used to send out spam emails. The FTC launched their “Careful Connections” campaign warning consumers that “Smart devices can be dumb about security.”

Why this matters:

  • Cyber-physical consequences: Unlike traditional computers, IoT attacks affect the physical world (unlock doors, disable cameras, control industrial machinery)
  • Unpatchable devices: Many IoT devices can’t be updated, leaving vulnerabilities unfixed for their entire 10-20 year lifetime
  • Fog computing for privacy: Processing data at the edge (fog layer) instead of sending everything to the cloud can protect user privacy while maintaining functionality

This case highlights three critical IoT security challenges we’ll explore: devices are vulnerable targets, attacks have physical consequences, and architectural choices (like fog computing) can mitigate both security and privacy risks.

Related: For privacy implications of IoT data collection, see Introduction to Privacy.

IoT systems face threats from various actors with different capabilities and motivations:

Matrix diagram showing five threat actor types (Script Kiddies, Cybercriminals, Hacktivists, Insiders, Nation-States) plotted against capability level (vertical axis from low to high) and motivation (horizontal axis from opportunistic to targeted). Shows progression from low-skill random attacks to sophisticated targeted campaigns.
Figure 14.1: Threat actor classification by capability and motivation.

14.1.1 Threat Actor Classification

Actor Type Skill Level Motivation Typical Targets Examples
Script Kiddies Low Fame, curiosity Random devices Mirai copycats
Cybercriminals Medium-High Financial gain High-value targets Ransomware, botnets
Hacktivists Medium Political/social Organizations, governments Anonymous, DDoS
Insiders Varies Revenge, profit Own organization Disgruntled employees
Nation States Very High Espionage, sabotage Critical infrastructure Stuxnet, APT groups
Competitors Medium-High Industrial espionage Business rivals IP theft

Insider Threats: The Overlooked Danger

Insiders are the most dangerous threat actors because they bypass perimeter security with legitimate credentials. In IoT systems, insiders can: - Extract device encryption keys during manufacturing - Plant backdoors in firmware before deployment - Disable security features with admin access - Exfiltrate sensitive sensor data over time

Mitigation: Implement zero-trust architecture (verify every action, even from insiders), separation of duties (no single person controls all security), audit logging (track all privileged actions), and background checks for personnel handling sensitive IoT infrastructure.

14.1.2 Cyber Security 4-Quadrant Framework

Comprehensive IoT security requires protecting four interconnected domains:

Quadrant Security Concerns IoT Examples Mitigation Strategies
People Insiders, attackers, social engineering Disgruntled factory worker disables security cameras; phishing attack compromises admin credentials Background checks, security training, zero-trust architecture, least privilege access
Processes Purchasing, hiring, training, operations Buying devices with known vulnerabilities; inadequate vetting of firmware developers Vendor security requirements, secure SDLC, incident response plans, regular audits
Physical Environment Data centers, communications, deployment Accessible JTAG ports on deployed sensors; unencrypted Wi-Fi networks; unlocked server rooms Tamper-evident seals, encrypted communications, locked cabinets, environmental monitoring
Technology Hardware, applications, firmware, OS Outdated OpenSSL library; buffer overflow in firmware; hardcoded credentials in device Secure boot, code signing, vulnerability scanning, penetration testing, security patches
Defense in Depth Strategy

Effective IoT security requires layering protections across all four quadrants:

  • People: Train employees to recognize phishing + enforce multi-factor authentication
  • Processes: Require security reviews in procurement + implement secure development lifecycle
  • Physical: Lock network cabinets + use tamper-evident seals on devices
  • Technology: Enable secure boot + encrypt data at rest and in transit

A weakness in one quadrant can compromise the entire system—attackers target the weakest link.

14.2 STRIDE Threat Model for IoT

STRIDE is a threat modeling framework developed by Microsoft for systematically identifying security threats:

How It Works: STRIDE Threat Identification Process

STRIDE provides a systematic checklist to uncover threats across six categories:

For each system component, ask six questions:

1. Spoofing (Authentication)

  • Question: Can an attacker pretend to be someone/something else?
  • IoT Example: Fake sensor sends false temperature readings to HVAC system
  • Detection: Missing authentication tokens, forged device IDs
  • Mitigation: Device certificates, mutual TLS, challenge-response

2. Tampering (Integrity)

  • Question: Can data or code be modified without authorization?
  • IoT Example: MITM attack changes dosage command to insulin pump
  • Detection: Hash mismatches, signature verification failures
  • Mitigation: Digital signatures (HMAC), secure boot, encrypted channels

3. Repudiation (Non-repudiation)

  • Question: Can someone deny performing an action?
  • IoT Example: Malicious user unlocks smart door, deletes audit logs
  • Detection: Missing or incomplete audit trails
  • Mitigation: Immutable logging, cryptographic timestamps, remote log backup

4. Information Disclosure (Confidentiality)

  • Question: Is sensitive data exposed to unauthorized parties?
  • IoT Example: Unencrypted Wi-Fi leaks patient health data from wearable
  • Detection: Cleartext traffic observed, exposed debug endpoints
  • Mitigation: TLS 1.3, encryption at rest (AES-256), data minimization

5. Denial of Service (Availability)

  • Question: Can the system be made unavailable?
  • IoT Example: Botnet floods IoT gateway with requests, blocking legitimate users
  • Detection: Unusual traffic spikes, resource exhaustion alerts
  • Mitigation: Rate limiting, DDoS protection, resource quotas, watchdog timers

6. Elevation of Privilege (Authorization)

  • Question: Can someone gain unauthorized access or permissions?
  • IoT Example: Buffer overflow in firmware gives attacker root shell
  • Detection: Unexpected privilege escalations, unauthorized admin actions
  • Mitigation: Least privilege, input validation, RBAC, disable debug modes

Why This Works: STRIDE ensures comprehensive threat coverage - each category maps to a violated security property, so addressing all six categories means defending all security principles.

STRIDE threat model diagram showing six categories in a circular arrangement: Spoofing (violates Authentication), Tampering (violates Integrity), Repudiation (violates Non-repudiation), Information Disclosure (violates Confidentiality), Denial of Service (violates Availability), and Elevation of Privilege (violates Authorization). Each category connected to its corresponding violated security principle.
Figure 14.2: STRIDE threat modeling framework showing six threat categories and violated security principles.

14.2.1 Spoofing (Identity)

Definition: Pretending to be someone or something else

IoT Examples:

  • Fake sensor data injection
  • Rogue device joining network
  • MAC address spoofing
  • GPS spoofing for trackers

Attack Scenario:

// VULNERABLE: No device authentication
void processMessage(String message) {
  // Blindly trust any message
  float temperature = message.toFloat();
  updateDatabase(temperature);  // Could be fake data!
}

// SECURE: Verify sender identity
void processMessage(String message, String deviceId, String signature) {
  if (!verifySignature(message, deviceId, signature)) {
    Serial.println("ALERT: Invalid signature - potential spoofing!");
    return;
  }

  float temperature = message.toFloat();
  updateDatabase(temperature);
}

Countermeasures:

  • Device certificates and mutual TLS
  • Message authentication codes (HMAC)
  • Challenge-response authentication

14.2.2 Tampering (Data)

Definition: Unauthorized modification of data or code

IoT Examples:

  • Firmware modification
  • Sensor data manipulation
  • Configuration file changes
  • MITM attacks modifying packets

Attack Scenario:

# Attacker intercepts MQTT message
# Original: {"temperature": 22.5, "humidity": 60}
# Modified: {"temperature": 99.9, "humidity": 10}
# Result: Triggers false alarm, wrong decisions

# DEFENSE: Use digital signatures
import hashlib
import hmac

def sign_message(message, secret_key):
    signature = hmac.new(
        secret_key.encode(),
        message.encode(),
        hashlib.sha256
    ).hexdigest()
    return f"{message}|{signature}"

def verify_message(signed_message, secret_key):
    try:
        message, signature = signed_message.split('|')
        expected = hmac.new(
            secret_key.encode(),
            message.encode(),
            hashlib.sha256
        ).hexdigest()
        return hmac.compare_digest(signature, expected)
    except:
        return False

Countermeasures:

  • Encryption (TLS/DTLS)
  • Digital signatures
  • Secure boot and verified firmware
  • Integrity checks (checksums, hashes)

14.2.3 Repudiation (Non-repudiation)

Definition: Denying that an action occurred

IoT Examples:

  • User denies sending command
  • Device denies reporting data
  • No audit trail of changes

Attack Scenario:

User: "I never unlocked the door at 3 AM!"
System: [No logs to prove otherwise]

Malicious insider: "I didn't change the sensor calibration"
System: [No audit trail]

Countermeasures:

// Implement comprehensive logging
#include <SD.h>
#include <TimeLib.h>

void logAction(String user, String action, String details) {
  File logFile = SD.open("audit.log", FILE_APPEND);

  String logEntry = String(now()) + "," +
                    user + "," +
                    action + "," +
                    details;

  logFile.println(logEntry);
  logFile.close();

  // Also send to remote secure log server
  sendToRemoteLog(logEntry);
}

// Usage
logAction("user@email.com", "DOOR_UNLOCK", "Front Door");

Best Practices:

  • Immutable audit logs
  • Cryptographic timestamps
  • Remote log backup
  • Digital signatures on transactions

14.2.4 Information Disclosure (Privacy)

Definition: Exposing information to unauthorized parties

IoT Examples:

  • Unencrypted sensor data transmission
  • Exposed API endpoints
  • Debug information leaking
  • Cloud storage misconfiguration

Attack Scenario:

# Attacker sniffs Wi-Fi traffic (unencrypted MQTT)
$ tcpdump -i wlan0 port 1883
# Captures: {"device": "bedroom_camera", "stream_url": "rtsp://..."}
# Result: Privacy invasion

# Attacker finds exposed API
$ curl http://iot-api.example.com/api/devices
# Returns: Complete list of all devices with credentials!

Countermeasures:

// Always encrypt sensitive data
#include <WiFiClientSecure.h>
#include <PubSubClient.h>

WiFiClientSecure espClient;
PubSubClient mqtt(espClient);

void setup() {
  // Use TLS certificate pinning
  espClient.setCACert(ca_cert);
  espClient.setCertificate(client_cert);
  espClient.setPrivateKey(client_key);

  // Connect to MQTTS (port 8883)
  mqtt.setServer("broker.example.com", 8883);
}

// Sanitize debug output
void debugPrint(String message) {
  #ifdef DEBUG
  // Never log sensitive data
  message.replace(password, "***REDACTED***");
  Serial.println(message);
  #endif
}

14.2.5 Denial of Service (Availability)

Definition: Making system unavailable to legitimate users

IoT Examples:

  • DDoS attacks (Mirai botnet)
  • Battery depletion attacks
  • Network flooding
  • Resource exhaustion

TCP SYN Flood attack diagram showing attacker sending multiple SYN requests to a web server which responds with SYN-ACK and waits for ACK responses that never arrive, exhausting server connection queue with open ports waiting for ACKs, until legitimate user requests are denied because the server is unavailable

TCP SYN Flood attack mechanism
Figure 14.3: TCP SYN Flood Attack: Attacker sends massive SYN requests with spoofed addresses. Server allocates resources for half-open connections waiting for ACKs that never come.

Attack Scenarios:

// Scenario 1: Battery depletion attack
// Attacker sends continuous ping requests
// Device stays awake responding - battery drains

// DEFENSE: Rate limiting
unsigned long lastResponse = 0;
const int MIN_RESPONSE_INTERVAL = 5000;  // 5 seconds

void handlePing() {
  if (millis() - lastResponse < MIN_RESPONSE_INTERVAL) {
    // Drop request - too frequent
    return;
  }

  lastResponse = millis();
  sendPingResponse();
}

Countermeasures:

  • Rate limiting and throttling
  • Input validation
  • Resource quotas
  • DDoS mitigation services (Cloudflare)
  • Watchdog timers

14.2.6 Elevation of Privilege (Authorization)

Definition: Gaining unauthorized access or permissions

IoT Examples:

  • Buffer overflow to gain root
  • SQL injection to admin account
  • Exploiting debug interfaces
  • Firmware backdoors

Attack Scenario:

// VULNERABLE: Buffer overflow
void handle_command(char *input) {
  char buffer[64];
  strcpy(buffer, input);  // No bounds checking!
  // Attacker sends 200 bytes -> buffer overflow
  // -> Overwrites return address -> Executes malicious code
}

// SECURE: Bounds checking
void handle_command(char *input) {
  char buffer[64];
  strncpy(buffer, input, sizeof(buffer) - 1);
  buffer[sizeof(buffer) - 1] = '\0';
}

Countermeasures:

  • Least privilege principle
  • Input validation and sanitization
  • Memory-safe programming
  • Disable debug interfaces in production
  • Role-based access control (RBAC)

14.3 Worked Example: STRIDE + DREAD Analysis of a Smart Hospital Infusion Pump

Scenario: A hospital deploys 200 networked infusion pumps that deliver medication to patients. Each pump connects via Wi-Fi to a central pharmacy server that dispatches dosage prescriptions. The security team must perform a STRIDE analysis with DREAD risk scoring to prioritize mitigations within a $150,000 security budget.

System components: Infusion pump (ESP32-based, Wi-Fi, 256 KB RAM), pharmacy server (Linux, MySQL), nurse station tablet (Android), hospital Wi-Fi (WPA2-Enterprise).

14.3.1 Step 1: Apply STRIDE to Each Component

Component STRIDE Threat Attack Description Consequence
Pump Spoofing Rogue device impersonates a legitimate pump and accepts dosage commands Wrong patient receives medication intended for another
Pump Tampering Attacker modifies firmware via exposed USB debug port Pump delivers incorrect dosage – potential patient death
Pump-to-Server link Tampering Man-in-the-middle modifies dosage in transit (e.g., 5 mg changed to 50 mg) Patient overdose
Pharmacy Server Repudiation Pharmacist denies approving a dangerous dosage; no audit trail exists Liability dispute, no accountability
Pump Information Disclosure Unencrypted Wi-Fi traffic exposes patient name, medication, and dosage HIPAA violation, $50K-$1.9M fine per incident
Pharmacy Server Denial of Service DDoS attack overwhelms server; pumps cannot receive new prescriptions Medication delivery halted for all 200 pumps
Nurse Tablet Elevation of Privilege Malware on tablet escalates from nurse role to pharmacist, changes dosages Unauthorized dosage modifications across the ward

14.3.2 Step 2: Score Each Threat Using DREAD (0-10 Scale)

DREAD scores each threat on five criteria: Damage potential, Reproducibility, Exploitability, Affected users, Discoverability. The average produces a risk score from 0 (negligible) to 10 (critical).

Calculate DREAD scores for your own threats:

Try it: Adjust the sliders to calculate DREAD scores for threats in your IoT system.

Threat D R E A D Score Priority
Dosage tampering in transit (MITM) 10 7 6 8 5 7.2 Critical
Firmware tampering via USB 10 8 4 3 3 5.6 High
DDoS on pharmacy server 8 9 7 10 8 8.4 Critical
Patient data exposure (HIPAA) 7 9 8 10 9 8.6 Critical
Privilege escalation on tablet 9 5 4 6 4 5.6 High
Pump spoofing 8 6 5 3 4 5.2 Medium
Missing audit trail 4 10 10 10 2 7.2 Critical

Score interpretation: 8-10 = Critical (fix immediately), 5-7.9 = High (fix within 30 days), 3-4.9 = Medium (fix within 90 days), 0-2.9 = Low (accept or defer).

14.3.3 Step 3: Allocate the $150,000 Budget by DREAD Priority

Mitigation Addresses Cost DREAD Reduction
TLS 1.3 for all pump-server communication Data exposure (8.6), MITM tampering (7.2) $25,000 8.6 to 2.1, 7.2 to 2.3
DDoS protection + server redundancy Server DoS (8.4) $35,000 8.4 to 3.0
Immutable audit logging (append-only database + remote backup) Missing audit trail (7.2) $15,000 7.2 to 1.5
Epoxy-fill USB debug ports on all 200 pumps Firmware tampering (5.6) $5,000 5.6 to 1.2
Device certificate provisioning (X.509 per pump) Pump spoofing (5.2) $30,000 5.2 to 1.8
MDM + app sandboxing on nurse tablets Privilege escalation (5.6) $20,000 5.6 to 2.4
Network segmentation (dedicated medical IoT VLAN) All threats (lateral movement) $20,000 Reduces all scores by 1-2 points
Total $150,000

14.3.4 Step 4: Calculate Residual Risk

After applying all mitigations, the residual risk profile:

Threat Before After Residual Risk
Patient data exposure 8.6 2.1 Accepted (TLS + segmentation)
DDoS on pharmacy server 8.4 3.0 Accepted (redundancy + rate limiting)
Dosage tampering in transit 7.2 2.3 Accepted (TLS mutual auth)
Missing audit trail 7.2 1.5 Accepted (immutable logs)
Firmware tampering via USB 5.6 1.2 Accepted (ports sealed)
Privilege escalation 5.6 2.4 Accepted (MDM + sandboxing)
Pump spoofing 5.2 1.8 Accepted (X.509 certificates)

Result: Total DREAD risk reduced from 47.8 to 14.3 (70% reduction) within a $150,000 budget. All threats moved from Critical/High to Low/Accepted. The largest single-investment impact was TLS deployment ($25K) which simultaneously addressed the two highest-scoring threats.

Key insight: The DREAD scoring revealed that patient data exposure (8.6) was the highest risk – not the life-safety concern of dosage tampering (7.2). This is because data exposure is highly reproducible, easily exploitable, and affects all patients, while dosage tampering requires a more sophisticated MITM position. Without quantitative scoring, the team would likely have prioritized dosage integrity first, leaving the more probable HIPAA violation unaddressed.

14.4 Common Security Pitfalls

Pitfall: Relying on Network Perimeter Security for IoT

The Mistake: Organizations assume IoT devices are protected because they are “behind the firewall” or on a “private network.” Security controls are applied only at the network edge, leaving internal IoT traffic unencrypted and unauthenticated.

Why It Happens: Traditional IT security focused on perimeter defense (castle-and-moat model). IoT devices have limited resources, so encryption seems expensive. Internal networks are assumed trustworthy. VLANs provide network isolation, creating false confidence.

The Fix: Implement defense-in-depth with zero-trust principles: - Encrypt all traffic: Use TLS/DTLS even on internal networks. Assume attackers are already inside (lateral movement). - Authenticate every device: Use X.509 certificates or pre-shared keys for device-to-device and device-to-gateway communication. - Network segmentation: Isolate IoT devices on dedicated VLANs with strict firewall rules. Block IoT-to-IoT communication unless explicitly required. - Microsegmentation: Apply per-device or per-application firewall policies. A compromised thermostat should not reach the financial database. - Monitor east-west traffic: Deploy network detection tools (Zeek, Suricata) to detect anomalous internal communication patterns.

Pitfall: Storing Credentials in Firmware or Source Code

The Mistake: API keys, Wi-Fi passwords, MQTT broker credentials, or cloud service tokens are hardcoded directly in device firmware or checked into version control.

Why It Happens: Hardcoding works during development and prototyping. Developers forget to remove credentials before committing. Configuration management for IoT fleets is complex.

The Fix: Implement proper credential management: - Never hardcode: Use environment variables, secure element storage, or runtime provisioning. Treat any credential in source code as compromised. - Manufacturing provisioning: Inject unique credentials per device during manufacturing using secure provisioning stations. - Runtime provisioning: Use device provisioning protocols (AWS IoT Just-in-Time Provisioning, Azure DPS) to issue unique certificates on first boot. - Secret scanning: Add pre-commit hooks with tools like trufflehog, git-secrets, or detect-secrets to prevent credential commits.

Concept Relationships
Concept Relates To Nature of Relationship
Threat Actors Attack Motivation Actor type determines likely attack targets and methods
STRIDE Categories CIA Triad STRIDE maps to Confidentiality, Integrity, Availability violations
Cyber-Physical Consequences Risk Assessment IoT attacks affect physical world, not just data
Four Quadrants (People/Process/Physical/Tech) Defense in Depth Comprehensive security requires addressing all domains
Insider Threats Zero Trust Insiders bypass perimeter defenses, require continuous verification
Attack Vectors Mitigation Strategies Each vector (physical, network, firmware) requires specific defenses
See Also

STRIDE Framework:

Threat Actor Analysis:

Practical Application:

Implementation:

14.5 Knowledge Check

Threat actor capability is modeled as a resource-constrained optimization problem:

\[C(\text{Actor}) = w_s \cdot S + w_t \cdot T + w_b \cdot B\]

where \(S\) = skill level (0-10), \(T\) = time available (months), \(B\) = budget ($), and \(w_s, w_t, w_b\) are normalized weights.

Worked Calculation: Comparing Threat Actors for Smart Hospital System

Given: Hospital with 5,000 connected medical devices requiring threat prioritization

Step 1: Score threat actors on capability dimensions | Actor | Skill (S) | Time (T, months) | Budget (B, $) | Motivation (M) | Capability (C) | |——-|———–|——————|—————|—————-|—————-| | Script Kiddie | 2 | 0.5 | $0 | 3 | 1.8 | | Cybercriminal | 6 | 2 | $5,000 | 9 | 6.2 | | Hacktivist | 5 | 1 | $1,000 | 7 | 4.8 | | Insider | 7 | 6 | $0 | 8 | 7.5 | | Nation-State | 10 | 24 | $1M | 10 | 10.0 |

Capability calculation (normalized weights: \(w_s = 0.5, w_t = 0.3, w_b = 0.2\)):

For Cybercriminal: \[C = 0.5 \times 6 + 0.3 \times (2/24 \times 10) + 0.2 \times (5000/1000000 \times 10) = 3.0 + 0.25 + 0.01 = 3.26\]

For Insider: \[C = 0.5 \times 7 + 0.3 \times (6/24 \times 10) + 0.2 \times 0 = 3.5 + 0.75 + 0 = 4.25\]

Step 2: Calculate attack success probability \[P(\text{Success}) = \frac{C(\text{Actor})}{C(\text{Actor}) + D(\text{Defense})}\]

With hospital defense capability \(D = 6.0\) (moderate investment): \[P(\text{Insider success}) = \frac{4.25}{4.25 + 6.0} = 0.41 \quad (41\%)\] \[P(\text{Cybercriminal success}) = \frac{3.26}{3.26 + 6.0} = 0.35 \quad (35\%)\]

Step 3: Calculate expected loss by threat actor \[E[\text{Loss}] = P(\text{Attack}) \times P(\text{Success | Attack}) \times I(\text{Impact})\]

Actor P(Attack) P(Success Attack) Impact ($)
Script Kiddie 0.80 0.15 $50K $6,000
Cybercriminal 0.60 0.35 $500K $105,000
Insider 0.05 0.41 $2M $41,000
Nation-State 0.01 0.90 $50M $450,000

Result: Despite low attack probability (1%), nation-state actors represent highest expected loss ($450K) due to catastrophic impact. Prioritize defenses against high-capability actors even when attack frequency is low.

In practice: Capability-based threat modeling prevents over-investing in low-skill attacker defenses (script kiddies) while ignoring APTs. Hospitals face nation-state reconnaissance - defenses must match this reality.

Calculate threat actor capability and attack success probability:

Try it: Model different threat actors by adjusting skill, time, and budget. See how your defense capability affects attack success probability.

14.6 What’s Next

If you want to… Read this
Apply the STRIDE model in practice through the framework chapter STRIDE Framework
Use the model in hands-on threat modelling Threat Modelling and Mitigation
Apply the model to realistic attack scenario analysis Threat Attack Scenarios
Practise applying the model through exercises Threats Exercises
Return to the security module overview IoT Security Fundamentals

Common Pitfalls

The STRIDE model must be re-applied whenever the system design changes. New data flows, new external entities, and new trust boundaries introduce new threats that were not present in the original model.

Mis-categorising an Information Disclosure threat as a Tampering threat leads to selecting integrity controls (HMAC) instead of confidentiality controls (encryption). Verify the category by identifying which security property is violated before selecting mitigations.

A STRIDE analysis that produces a 200-item threat list without owner assignment, prioritisation, and tracking becomes unmanageable. Limit to actionable threats with realistic exploitability and track them in a structured risk register.