18 Attack Scenarios & Risk

18.1 Learning Objectives

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

Analyze Real Attack Scenarios: Understand how IoT systems are compromised in practice
Assess Risk Using DREAD: Apply the DREAD framework to score threat severity
Prioritize Vulnerabilities: Rank risks by likelihood, impact, and exploitability
Use Threat Assessment Tools: Apply interactive tools to evaluate your IoT system’s risk profile
Document Threat Models: Create comprehensive security assessments for IoT deployments

In 60 Seconds

IoT attack scenarios ground abstract threat categories in realistic, step-by-step attack narratives that illustrate exactly how an attacker would exploit specific vulnerabilities to achieve specific goals — making the abstract threat of ‘default credentials’ concrete as ‘attacker scans for MQTT brokers on port 1883, connects with admin/admin, subscribes to all topics, and reads sensitive sensor data in real-time’. Scenario analysis is the most effective way to validate whether security controls actually address the threats they are intended to mitigate.

Related Chapters

Threat Modeling Series:

Introduction & Fundamentals - Threat modeling basics
STRIDE Framework - Systematic threat identification
Assessments - Quizzes and knowledge checks
Hands-On Lab - Interactive simulator

Security Context:

Security Overview - Security landscape
Device Security - Device hardening
Threats & Vulnerabilities - Attack catalog

For Beginners: Risk Assessment with DREAD

What is DREAD? DREAD is a risk scoring framework that helps prioritize which threats to fix first by rating five factors on a 0-10 scale: Damage potential (how bad if exploited), Reproducibility (how easy to replicate attack), Exploitability (how much skill/effort needed), Affected users (how many people impacted), and Discoverability (how easy to find the vulnerability).

Why does it matter? You can’t fix everything at once. DREAD scores help you focus on high-risk vulnerabilities (high score = critical threat) and accept low-risk ones (low score = monitor but don’t panic). A vulnerability with damage=10 but exploitability=2 might be lower priority than damage=7 with exploitability=9.

Sensor Squad: Real Attacks, Real Lessons!

“Let me walk you through how a real attack works,” Max the Microcontroller said, drawing on an imaginary whiteboard. “Step one: the attacker scans the network and finds an IoT camera with default credentials. Step two: they log in and install malware. Step three: they use the camera as a jumping-off point to reach other devices. Step four: they steal data or cause damage. Each step is a chance to stop them!”

Sammy the Sensor jumped in. “That is where DREAD scoring comes in! We rate each threat on five things, each scored 0 to 10. Damage: how bad is it? Reproducibility: can the attacker do it again easily? Exploitability: how hard is it to pull off? Affected users: how many people get hurt? Discoverability: how easy is it to find the vulnerability? Add them up, and you know what to fix first!”

“Think of it like triaging patients in a hospital,” Lila the LED suggested. “The most critical cases get attention first. A vulnerability that is easy to exploit, affects thousands of devices, and causes major damage gets a high DREAD score and goes to the top of the fix-it list.”

“Risk assessment helps you be smart about where to spend your security budget,” Bella the Battery concluded. “You cannot make everything perfectly secure – that would be infinitely expensive. But by scoring risks, you can fix the biggest dangers first and accept the tiny ones. It is about being strategic, not panicked!”

MVU: DREAD Risk Scoring

Core Concept: DREAD scores threats on five dimensions (Damage, Reproducibility, Exploitability, Affected users, Discoverability) to create a quantitative risk priority ranking. Why It Matters: Not all threats are equal; fixing low-risk threats wastes resources while critical vulnerabilities remain exploitable. Key Takeaway: Calculate DREAD score = (D+R+E+A+D)/5; prioritize threats with scores >7.0 for immediate remediation.

18.2 IoT Attack Scenarios

⏱️ ~18 min | ⭐⭐⭐ Advanced | 📋 P11.C05.U04

Key Concepts

Attack scenario: A step-by-step narrative describing how a realistic attacker would exploit specific vulnerabilities in an IoT system to achieve a specific malicious goal — used to validate threat models and test defences.
Initial access: The first step in an attack where the attacker gains an initial foothold in the IoT system, commonly through default credentials, an exposed management interface, or a phishing attack on an operator.
Lateral movement: The attacker’s progression from the initially compromised device to other devices and systems within the same network, expanding access and privilege.
Persistence mechanism: A method by which an attacker maintains access to a compromised device even after reboots, firmware updates, or credential changes — for example, by modifying the bootloader or adding a backdoor user account.
Impact phase: The final stage of an attack where the attacker achieves their objective: data exfiltration, device disruption, ransomware deployment, or using the device as a botnet node.
Attack path validation: The process of testing whether identified attack paths in a threat model can actually be executed, confirming that threats are exploitable and controls are effective.

Interactive: Security Attack Visualization Suite

Comprehensive overview of 10 critical IoT attack scenarios including network eavesdropping, sensor manipulation, actuator sabotage, administration system compromise, protocol exploitation, command injection, stepping stone attacks, DDoS botnet creation, power manipulation, and ransomware attacks with attack vectors and impact analysis — Figure 18.1: IoT attack scenarios overview

18.2.1 10 Critical IoT Attack Vectors

Diagram showing ten critical IoT attack vectors in a hierarchical flow: Network Link Eavesdropping, Sensor Manipulation, Actuator Sabotage, Administration System Compromise, Protocol Exploitation, Command Injection, Stepping Stone Attacks, DDoS Botnet Creation, Power Manipulation, and Ransomware with interconnected attack paths and impact levels — Graph diagram

18.2.2 Attack Scenario Details

1. Network Link Eavesdropping

Target: Communication between controllers and actuators

Attack: Passive interception of network traffic to extract sensitive operational information

Impact:

Data leakage
Intelligence gathering for Advanced Persistent Threats (APTs)
Identification of weak spots for future attacks

Mitigation:

End-to-end encryption (TLS/DTLS)
Network segmentation
Intrusion detection systems
Regular traffic analysis

From Theory to Practice

The defense against network eavesdropping is transport-layer encryption. Here is what TLS certificate pinning looks like in a MicroPython IoT client – the key technique that prevents man-in-the-middle interception:

import ssl
import socket

# Pin the server's certificate fingerprint
TRUSTED_FINGERPRINT = b'\x4a\x3b\x2c...'  # SHA-256 of server cert

ctx = ssl.SSLContext(ssl.PROTOCOL_TLS_CLIENT)
ctx.verify_mode = ssl.CERT_REQUIRED
ctx.load_verify_locations(cafile='/certs/ca-bundle.crt')

sock = socket.socket()
secure_sock = ctx.wrap_socket(sock, server_hostname='iot-gateway.example.com')
secure_sock.connect(('iot-gateway.example.com', 8883))

# Verify certificate fingerprint matches pinned value
cert_der = secure_sock.getpeercert(binary_form=True)
import hashlib
actual = hashlib.sha256(cert_der).digest()
if actual != TRUSTED_FINGERPRINT:
    secure_sock.close()
    raise Exception("Certificate mismatch - possible MITM attack")

See Secure Communications and Firmware Integrity for the complete TLS/DTLS implementation walkthrough for constrained devices.

2. Sensor Manipulation

Target: Sensor threshold values and configuration

Attack: Modify calibration parameters to accept out-of-range values

Impact:

Incorrect sensor readings
Safety system failures
Physical damage to equipment (e.g., power spikes)

Mitigation:

Tamper-resistant hardware
Integrity checking of configuration
Multiple redundant sensors
Anomaly detection algorithms

3. Actuator Sabotage

Target: Actuator configuration and operational parameters

Attack: Modify settings to cause malfunction or incorrect operation

Impact:

Production disruptions
Safety hazards
Equipment damage
Environmental incidents

Mitigation:

Command authentication
Configuration validation
Physical access controls
Fail-safe mechanisms

4. Administration System Compromise

Target: IoT device management systems

Attack: Gain full control via weak/default credentials, then modify entire deployment

Impact:

Complete system compromise
Mass device manipulation
Network-wide disruption
Cascading failures

Mitigation:

Strong authentication (MFA)
Regular credential rotation
Principle of least privilege
Network segmentation

From Theory to Practice

The defense against administration system compromise starts with eliminating default credentials. Here is a minimal secure device provisioning flow that forces unique credentials at first boot:

import secrets
import hashlib

def first_boot_provisioning():
    """Generate unique credentials on first boot - never ship defaults."""
    device_id = get_hardware_uid()  # Unique hardware identifier

    # Generate a cryptographically random password
    admin_password = secrets.token_urlsafe(24)

    # Store salted hash, never the plaintext
    salt = secrets.token_bytes(16)
    pw_hash = hashlib.pbkdf2_hmac('sha256', admin_password.encode(), salt, 100000)

    store_credential(device_id, salt, pw_hash)

    # Display password ONCE on serial console during manufacturing
    print(f"PROVISION: Device {device_id} password: {admin_password}")
    print("Record this password. It will not be shown again.")

The critical principle: no two devices should ever share the same credential, and default passwords like “admin/admin” should never exist in production firmware. See Authentication Methods for the complete mTLS and JWT implementation guide.

Knowledge Check: Attack Classification

8. DDoS Using IoT Botnet

Target: External services using compromised IoT devices

Attack: Mirai-style botnet creation for distributed attacks

Impact:

Service unavailability for victims
Network bandwidth exhaustion
Reputation damage
Legal liability

Mitigation:

Secure default configurations
Automatic security updates
Network traffic monitoring
Bot detection systems

From Theory to Practice

The Mirai botnet scanned for devices with default Telnet credentials. The defense is twofold: disable unnecessary services and implement network-level anomaly detection. Here is a basic outbound traffic monitor that detects bot-like scanning behavior:

# iptables rules to block common botnet behaviors
# Place in /etc/iptables/rules.v4 on IoT gateway

# Rate-limit outbound connection attempts (bot scanning)
iptables -A OUTPUT -p tcp --syn -m connlimit \
    --connlimit-above 10 --connlimit-mask 0 -j DROP

# Block outbound Telnet (no legitimate IoT use)
iptables -A OUTPUT -p tcp --dport 23 -j DROP

# Log unusual outbound traffic volumes
iptables -A OUTPUT -p tcp -m limit --limit 1/min \
    -j LOG --log-prefix "IOT-OUTBOUND: "

The most effective single action against IoT botnets is disabling Telnet and SSH password authentication on all devices, replacing them with certificate-based authentication or disabling remote shell access entirely. See Network Segmentation for the complete network isolation strategy.

10. Ransomware

Target: IoT devices and data

Attack: Malware blocks access to data/functionality until ransom paid

Impact:

Critical service disruption
Safety risks (medical devices, thermostats, power grids)
Financial losses
Public safety threats

Mitigation:

Regular backups
Offline recovery systems
Security patching
User awareness training

18.3 Critical Attack Scenario Analysis

18.3.1 Scenario 1: IoT Administration System Compromise

Overview diagram of IoT administration system compromise attack scenario showing attacker's progression from network reconnaissance through gateway compromise to full device control — Figure 18.3: Attack scenario 1: Administration system compromise

Detailed threat diagram showing reconnaissance and intelligence gathering phase where attacker scans network to identify IoT devices, firmware versions, and exploitable vulnerabilities — Figure 18.4: Attack scenario 1: Threat 1

Detailed threat diagram showing exploitation and persistence phase where attacker leverages weak credentials to gain gateway access, installs backdoor, and pushes malicious firmware updates — Figure 18.5: Attack scenario 1: Threat 2

Objective: Gain persistent control over IoT devices through gateway compromise.

Flow diagram showing seven-stage administration system compromise attack chain: Reconnaissance (network scanning) → Intelligence Gathering (device identification) → Exploitation (credential attacks) → Network Compromise (gateway access) → Persistence (backdoor installation) → Firmware Update (malicious payload) → Full Control (remote manipulation) — Graph diagram

Attack Steps:

Reconnaissance: Network scanning to identify IoT devices and services
Intelligence Gathering: Determine device models, firmware versions, vulnerabilities
Exploitation: Leverage weak credentials, unpatched vulnerabilities
Network Compromise: Gain access to gateway or management system
Persistence: Install backdoor, create accounts, disable logging
Firmware Update: Push malicious firmware to maintain control
Full Control: Remote access, data theft, device manipulation

Countermeasures:

Network segmentation (separate IoT from corporate network)
Strong authentication and authorization
Regular security audits and penetration testing
Intrusion detection and prevention systems
Firmware signature verification
Incident response planning

18.3.2 Scenario 2: Value Manipulation in IoT Devices

Overview diagram of sensor value manipulation attack scenario showing how attackers intercept and modify calibration data to cause industrial robot malfunction and safety incidents — Figure 18.7: Attack scenario 2: Value manipulation overview

Detailed threat diagram showing calibration interception phase where attacker captures sensor calibration data during device boot or reconfiguration process — Figure 18.8: Attack scenario 2: Threat 1

Detailed threat diagram showing threshold modification and data injection phase where attacker alters acceptable sensor ranges causing robot to make incorrect decisions based on manipulated readings — Figure 18.9: Attack scenario 2: Threat 2

Objective: Manipulate sensor calibration to cause industrial robot malfunction.

Flow diagram showing sensor value manipulation attack progression: Intercept Calibration (capture boot data) → Modify Thresholds (alter acceptable ranges) → Inject Modified Data (send manipulated calibration) → Wrong Decisions (robot acts on bad data) → Safety Incident (equipment damage, personnel injury) — Graph diagram

Attack Steps:

Intercept Calibration: Capture calibration data during boot or reconfiguration
Modify Thresholds: Change acceptable ranges for sensor readings
Inject Modified Data: Send manipulated calibration to controller
Wrong Decisions: Robot makes incorrect decisions based on bad sensor data
Safety Incident: Erratic movements, equipment damage, personnel injury

Countermeasures:

Encrypted calibration data transmission
Digital signatures on configuration files
Integrity checks (hash verification)
Redundant sensors with cross-validation
Anomaly detection (detect out-of-pattern behavior)
Physical tamper detection

18.3.3 Scenario 3: Botnet Creation via Command Injection

Overview diagram of Mirai-style botnet creation attack scenario showing progression from device scanning with default credentials through malware installation to coordinated DDoS attack launch — Figure 18.11: Attack scenario 3: Botnet creation overview

Detailed threat diagram showing scanning and brute force phase where attacker identifies Internet-exposed IoT devices and tries default credential combinations to gain initial access — Figure 18.12: Attack scenario 3: Threat 1

Detailed threat diagram showing command injection and malware propagation phase where attacker downloads payload from command-and-control server, executes in memory, and replicates to additional vulnerable devices — Figure 18.13: Attack scenario 3: Threat 2

Objective: Build IoT botnet (Mirai-style) for DDoS attacks.

Flow diagram showing eight-stage Mirai botnet attack chain: Scanning (identify exposed devices) → Brute Force (try default credentials) → Command Injection (gain admin access) → Malware Download (fetch payload from C&C) → In-Memory Execution (run in RAM) → Propagation (infect more devices) → Botnet Formation (thousands of compromised devices) → DDoS Launch (coordinated attack) — Graph diagram

Attack Steps:

Scanning: Identify Internet-exposed IoT devices with open ports (23, 22, 80)
Brute Force: Try default credentials (admin/admin, root/12345, etc.)
Command Injection: Inject shell commands to gain admin privileges
Malware Download: Connect to Command & Control (C&C) to download malicious payload
In-Memory Execution: Run malware in RAM (no disk traces), delete after loading
Propagation: Scan for more vulnerable devices, replicate attack
Botnet Formation: Thousands of compromised devices controlled by C&C
DDoS Launch: Coordinated attack against victim infrastructure

Real-World Example: Mirai Botnet

Compromised 600,000+ IoT devices
Used 62 default credential combinations
Launched massive DDoS (620 Gbps against Krebs on Security)
Targeted DNS provider Dyn, disrupting major websites

Countermeasures:

Pre-Deployment:
- Eliminate default credentials
- Disable unnecessary services (Telnet)
- Implement firewall rules
- Enable automatic updates
Runtime:
- Network traffic monitoring
- Anomaly detection (unusual scanning activity)
- Rate limiting outbound connections
- Quarantine compromised devices
Post-Compromise:
- Incident response procedures
- Device reflashing/factory reset
- Network forensics
- Patch vulnerable firmware

AI-Generated Visual: Risk Assessment Framework

Figure 18.15: Risk Assessment Framework - Geometric visualization of IoT security risk calculation

This risk assessment framework provides a systematic approach to evaluating and prioritizing IoT security threats based on quantifiable metrics.

AI-Generated Visual: Threat Modeling Diagram

Figure 18.16: Threat Modeling Process - Artistic guide to systematic threat identification

AI-Generated Visual: STRIDE-Based Threat Modeling

Figure 18.17: STRIDE Threat Modeling Applied - Systematic analysis across IoT layers

AI-Generated Visual: Threat Model STRIDE Matrix

Figure 18.18: STRIDE Threat Matrix - Geometric component-by-threat mapping

18.4 Worked Example: Vulnerability Risk Assessment

⏱️ ~15 min | ⭐⭐⭐ Advanced | 📋 P11.C05.U05

Worked Example: Smart Lock Vulnerability Risk Assessment

Context: A security researcher discovers a buffer overflow vulnerability in a popular smart lock’s firmware that could allow remote code execution. The manufacturer must assess the risk and decide on remediation strategy.

Given:

Vulnerability: Buffer overflow in BLE command handler allowing remote code execution
Affected devices: 50,000 deployed smart locks in residential and commercial buildings
Exploitation requirements: Network access (BLE range ~30m) + crafted packet sequence
Potential impact: Unauthorized entry, credential theft, malware injection, physical security breach

18.4.1 Step 1: CVSS 3.1 Base Score Calculation

The Common Vulnerability Scoring System (CVSS) provides a standardized method for rating vulnerability severity.

Hierarchical diagram showing CVSS 3.1 base score calculation components: Exploitability Metrics (Attack Vector, Attack Complexity, Privileges Required, User Interaction), Impact Metrics (Confidentiality, Integrity, Availability), and Scope determination flowing into final base score calculation — Graph diagram

CVSS Metric	Value	Score	Justification
Attack Vector (AV)	Network (N)	0.85	Exploitable over BLE network, no physical contact needed
Attack Complexity (AC)	Low (L)	0.77	No special conditions required, straightforward exploit
Privileges Required (PR)	None (N)	0.85	Attacker needs no prior authentication
User Interaction (UI)	None (N)	0.85	Victim doesn’t need to perform any action
Scope (S)	Changed (C)	-	Compromised lock affects physical security beyond the device
Confidentiality (C)	High (H)	0.56	Complete disclosure of lock codes, user schedules, access logs
Integrity (I)	High (H)	0.56	Attacker can modify lock state, add unauthorized codes
Availability (A)	Low (L)	0.22	Lock can be temporarily disabled but core function recoverable

CVSS Calculation:

\[\text{Impact} = 1 - [(1 - C) \times (1 - I) \times (1 - A)]\] \[\text{Impact} = 1 - [(1 - 0.56) \times (1 - 0.56) \times (1 - 0.22)]\] \[\text{Impact} = 1 - [0.44 \times 0.44 \times 0.78] = 1 - 0.151 = 0.849\]

For Changed Scope (CVSS 3.1): \[\text{Adjusted Impact} = 7.52 \times (\text{Impact} - 0.029) - 3.25 \times (\text{Impact} - 0.02)^{13}\] \[\text{Adjusted Impact} = 7.52 \times 0.820 - 3.25 \times 0.829^{13} = 6.17 - 0.24 = 5.93\]

\[\text{Exploitability} = 8.22 \times AV \times AC \times PR \times UI\] \[\text{Exploitability} = 8.22 \times 0.85 \times 0.77 \times 0.85 \times 0.85 = 3.89\]

\[\text{Base Score} = \min[1.08 \times (\text{Impact} + \text{Exploitability}), 10]\] \[\text{Base Score} = \min[1.08 \times (5.93 + 3.89), 10] = \min[10.61, 10] = \boxed{10.0}\]

Result: CVSS 10.0 (Critical) - Immediate action required

18.4.2 Step 2: Risk Quantification (Annual Loss Expectancy)

Converting the technical vulnerability score to business risk using quantitative analysis:

Risk Factor	Value	Source/Justification
Probability of exploit within 1 year	10%	Based on vulnerability disclosure timelines, attacker motivation for physical access targets
Average loss per breach event	$5,000	Includes: property theft ($2,500 avg), liability ($1,500), reputation/customer churn ($1,000)
Expected loss per device	$500	0.10 × $5,000 = $500
Total fleet at risk	50,000 devices	Current deployment footprint

Fleet Risk Calculation:

\[\text{Annual Loss Expectancy (ALE)} = \text{Probability} \times \text{Impact} \times \text{Fleet Size}\] \[\text{ALE} = 0.10 \times \$5,000 \times 50,000 = \boxed{\$25,000,000}\]

Additional Risk Factors:

Regulatory fines: Up to $50,000 per incident under various consumer protection laws
Class action liability: Estimated $5-15M if breach affects >1,000 users
Brand damage: 12-18% customer churn post-breach (industry average)
Insurance premiums: 40% increase after disclosed vulnerability

18.4.3 Step 3: Remediation Cost-Benefit Analysis

Cost-benefit analysis diagram comparing smart lock vulnerability remediation investment ($2.5M total: development, testing, OTA infrastructure, customer support, per-device deployment) against risk reduction (95% of $25M annual loss expectancy avoided, $23.75M) showing 850% ROI and residual risk of $1.25M — Graph diagram

Remediation Cost Breakdown:

Cost Category	Amount	Details
Development	$500,000	Security fix development, code review, vulnerability hardening
Testing & QA	$200,000	Regression testing, security validation, penetration testing
OTA Infrastructure	$300,000	Secure update distribution, rollback capability, monitoring
Customer Support	$250,000	Update notifications, troubleshooting, documentation
Per-device deployment	$25/device	OTA bandwidth, device testing, success verification
Total (50K devices)	$2,500,000	Fixed costs + (50,000 × $25)

Risk Reduction Analysis:

\[\text{Risk Reduction} = 95\%\] (industry standard for critical patch) \[\text{Residual Risk} = \$25M \times 0.05 = \$1.25M\] (accounts for patch failures, unupdated devices) \[\text{Avoided Loss} = \$25M \times 0.95 = \$23.75M\]

Return on Investment (ROI):

\[\text{ROI} = \frac{\text{Avoided Loss} - \text{Remediation Cost}}{\text{Remediation Cost}} \times 100\] \[\text{ROI} = \frac{\$23.75M - \$2.5M}{\$2.5M} \times 100 = \frac{\$21.25M}{\$2.5M} \times 100 = \boxed{850\%}\]

18.4.4 Final Answer: Executive Decision Summary

Factor	Value	Interpretation
CVSS Base Score	10.0 (Critical)	Maximum severity - requires immediate response
Annual Risk Exposure	$25 million	Unacceptable business risk
Remediation Cost	$2.5 million	~10% of risk exposure
Risk Reduction	95%	$23.75M avoided losses
ROI of Patching	850% (10:1 return)	Exceptionally favorable investment
Residual Risk	$1.25 million	Acceptable with insurance/monitoring
Decision	IMMEDIATE PATCH REQUIRED	Within 30-day responsible disclosure window

Timeline Recommendation:

Phase	Duration	Action
Day 1-7	Week 1	Emergency security patch development
Day 8-14	Week 2	Internal QA and penetration testing
Day 15-21	Week 3	Beta rollout to 1,000 devices, monitoring
Day 22-30	Week 4	Full fleet OTA deployment
Day 31+	Ongoing	Monitor patch success rate, support non-updated devices

Key Insight: This quantified risk analysis transforms a technical vulnerability into a clear business decision. The 10:1 ROI makes immediate patching not just a security imperative but a financially sound investment. Without quantification, security investments often lose priority to revenue-generating projects.

18.5 Interactive Threat Assessment Tool

Evaluate the security posture of your IoT deployment:

Show code

viewof device_type = Inputs.select(
  ["Consumer (smart home)", "Industrial (factory)", "Medical (healthcare)", "Critical Infrastructure", "Automotive"],
  {label: "Device Category:", value: "Consumer (smart home)"}
)

viewof connectivity = Inputs.select(
  ["Wi-Fi only", "Cellular (LTE/5G)", "LPWAN (LoRa/Sigfox)", "Bluetooth + Gateway", "Direct Internet"],
  {label: "Connectivity Type:", value: "Wi-Fi only"}
)

viewof data_sensitivity = Inputs.select(
  ["Public/Non-sensitive", "Personal data (PII)", "Financial data", "Health data (PHI)", "Critical/Safety"],
  {label: "Data Sensitivity:", value: "Personal data (PII)"}
)

viewof physical_access = Inputs.select(
  ["Physically secured", "Limited access", "Public space", "Outdoors/Unattended"],
  {label: "Physical Security:", value: "Limited access"}
)

viewof update_mechanism = Inputs.select(
  ["Automatic OTA", "Manual OTA", "Physical access only", "No updates"],
  {label: "Update Capability:", value: "Automatic OTA"}
)

Show code

threats = {
  let analysis = {
    risk_score: 0,
    threats: [],
    mitigations: []
  };

  // Device type risks
  if (device_type.includes("Medical")) {
    analysis.risk_score += 30;
    analysis.threats.push({name: "Patient Safety", severity: "Critical", desc: "Compromised devices can harm patients"});
    analysis.threats.push({name: "HIPAA Violations", severity: "High", desc: "Health data breach penalties up to $1.5M"});
  } else if (device_type.includes("Critical")) {
    analysis.risk_score += 35;
    analysis.threats.push({name: "Infrastructure Disruption", severity: "Critical", desc: "Power grid/water supply attacks"});
    analysis.threats.push({name: "Nation-State Actors", severity: "Critical", desc: "Advanced persistent threats"});
  } else if (device_type.includes("Industrial")) {
    analysis.risk_score += 25;
    analysis.threats.push({name: "Production Sabotage", severity: "High", desc: "Manufacturing disruption costs $22K/minute"});
  } else if (device_type.includes("Consumer")) {
    analysis.risk_score += 15;
    analysis.threats.push({name: "Botnet Recruitment", severity: "Medium", desc: "Mirai-style DDoS attacks"});
    analysis.threats.push({name: "Privacy Invasion", severity: "Medium", desc: "Surveillance and data harvesting"});
  }

  // Connectivity risks
  if (connectivity.includes("Direct Internet")) {
    analysis.risk_score += 25;
    analysis.threats.push({name: "Remote Exploitation", severity: "High", desc: "Directly exposed to internet attacks"});
    analysis.mitigations.push("Implement firewall rules and VPN tunneling");
  } else if (connectivity.includes("Wi-Fi")) {
    analysis.risk_score += 15;
    analysis.threats.push({name: "Wi-Fi Attacks", severity: "Medium", desc: "Evil twin, deauth attacks"});
    analysis.mitigations.push("Use WPA3 and network segmentation");
  }

  // Data sensitivity
  if (data_sensitivity.includes("Health") || data_sensitivity.includes("Financial")) {
    analysis.risk_score += 20;
    analysis.threats.push({name: "Data Breach", severity: "High", desc: "Regulatory fines + reputation damage"});
    analysis.mitigations.push("Implement end-to-end encryption (AES-256)");
    analysis.mitigations.push("Enable audit logging and anomaly detection");
  }

  // Physical access
  if (physical_access.includes("Public") || physical_access.includes("Unattended")) {
    analysis.risk_score += 20;
    analysis.threats.push({name: "Physical Tampering", severity: "High", desc: "Device theft, firmware extraction"});
    analysis.mitigations.push("Use secure boot and hardware security modules (HSM)");
    analysis.mitigations.push("Implement tamper detection mechanisms");
  }

  // Update mechanism
  if (update_mechanism.includes("No updates")) {
    analysis.risk_score += 30;
    analysis.threats.push({name: "Unpatched Vulnerabilities", severity: "Critical", desc: "Known exploits remain forever"});
    analysis.mitigations.push("CRITICAL: Implement OTA update capability");
  } else if (update_mechanism.includes("Physical")) {
    analysis.risk_score += 15;
    analysis.threats.push({name: "Delayed Patches", severity: "Medium", desc: "Slow vulnerability response"});
  }

  // Add general mitigations
  analysis.mitigations.push("Implement device authentication (mutual TLS)");
  analysis.mitigations.push("Apply principle of least privilege");
  analysis.mitigations.push("Regular security audits and penetration testing");

  analysis.risk_level = analysis.risk_score < 40 ? "Low" : analysis.risk_score < 70 ? "Medium" : analysis.risk_score < 90 ? "High" : "Critical";
  analysis.risk_color = analysis.risk_score < 40 ? "#16A085" : analysis.risk_score < 70 ? "#E67E22" : analysis.risk_score < 90 ? "#E74C3C" : "#8E44AD";

  return analysis;
}

html`<div style="background: linear-gradient(135deg, #2C3E50 0%, #34495E 100%); color: white; padding: 25px; border-radius: 12px; margin: 20px 0;">
  <div style="display: flex; justify-content: space-between; align-items: center; margin-bottom: 20px;">
    <h4 style="margin: 0;">🛡️ Security Assessment Results</h4>
    <div style="background: ${threats.risk_color}; padding: 10px 20px; border-radius: 25px;">
      <strong>${threats.risk_level} Risk</strong> (Score: ${threats.risk_score}/100)
    </div>
  </div>

  <div style="background: rgba(255,255,255,0.1); padding: 15px; border-radius: 8px; margin-bottom: 15px;">
    <h5 style="color: #E74C3C; margin-top: 0;">⚠️ Identified Threats</h5>
    ${threats.threats.map(t => html`
      <div style="background: rgba(0,0,0,0.2); padding: 10px; margin: 8px 0; border-radius: 5px; border-left: 3px solid ${t.severity === 'Critical' ? '#8E44AD' : t.severity === 'High' ? '#E74C3C' : '#E67E22'};">
        <strong>${t.name}</strong>
        <span style="background: ${t.severity === 'Critical' ? '#8E44AD' : t.severity === 'High' ? '#E74C3C' : '#E67E22'}; padding: 2px 8px; border-radius: 10px; font-size: 0.8em; margin-left: 8px;">${t.severity}</span>
        <p style="margin: 5px 0 0 0; font-size: 0.9em; opacity: 0.9;">${t.desc}</p>
      </div>
    `)}
  </div>

  <div style="background: rgba(255,255,255,0.1); padding: 15px; border-radius: 8px;">
    <h5 style="color: #16A085; margin-top: 0;">✅ Recommended Mitigations</h5>
    <ul style="margin: 0; padding-left: 20px;">
      ${threats.mitigations.map(m => html`<li style="margin: 5px 0;">${m}</li>`)}
    </ul>
  </div>
</div>`

Disclaimer

This tool provides educational guidance only. For production deployments, conduct formal threat modeling (STRIDE, DREAD) and engage professional security auditors.

18.6 Knowledge Check

Quiz: Attack Scenarios & Risk

Match the Attack Vector

Order the DREAD Risk Assessment Steps

18.7 What’s Next

If you want to…	Read this
Apply STRIDE to systematically generate attack scenarios	STRIDE Framework
Study specific attack vulnerabilities in IoT systems	Threats Attacks and Vulnerabilities
Understand threat modelling as the foundation for scenarios	Threat Modelling and Mitigation
Apply scenarios to security assessments	Threats Assessments
Return to the security module overview	IoT Security Fundamentals

Putting Numbers to It: DREAD Risk Scoring

Quantitative threat severity assessment using five dimensions to prioritize vulnerability remediation.

DREAD Score Formula: \[\text{DREAD} = \frac{D + R + E + A + D}{5}\] where each factor is scored 0-10: - $D$ = Damage potential (how bad if exploited) - $R$ = Reproducibility (how reliable is the exploit) - $E$ = Exploitability (how much skill/effort required) - $A$ = Affected users (how many people impacted) - $D$ = Discoverability (how easy to find vulnerability)

Working through an example: Given: Smart lock firmware buffer overflow vulnerability - Damage: 9/10 (unauthorized physical entry, theft risk) - Reproducibility: 10/10 (works every time) - Exploitability: 6/10 (requires BLE knowledge, but tutorials exist) - Affected users: 8/10 (50,000 deployed locks) - Discoverability: 5/10 (requires security research)

Step 1: Sum the scores: $9 + 10 + 6 + 8 + 5 = 38$ Step 2: Divide by 5: $\frac{38}{5} = 7.6$

Result: DREAD Score = 7.6 (HIGH risk - remediate within 30 days)

Risk Classification Thresholds:

Critical: 8.0-10.0 → Emergency patch (<7 days)
High: 6.0-7.9 → Urgent patch (<30 days)
Medium: 4.0-5.9 → Scheduled patch (<90 days)
Low: 0.0-3.9 → Next release cycle

Mitigation Impact: After implementing BLE Secure Connections with ECDH: - Damage: 9 (unchanged - if breached, impact is same) - Reproducibility: 2 (ECDH prevents replay) - Exploitability: 3 (requires breaking ECDH) - Affected users: 2 (only unpatched devices) - Discoverability: 2 (attack no longer works)

New DREAD: $\frac{9 + 2 + 3 + 2 + 2}{5} = \frac{18}{5} = 3.6$ (LOW risk)

Risk Reduction: $\frac{7.6 - 3.6}{7.6} = 0.526 = 52.6\%$ reduction

In practice: DREAD transforms subjective gut feelings into objective numbers. Two vulnerabilities may both seem “bad” but DREAD shows one is 7.6 (urgent) and the other is 4.2 (can wait). Budget allocation: if you have $50K for security fixes and 10 vulnerabilities, prioritize the 3 highest DREAD scores first. Post-mitigation scoring proves the fix worked: 7.6 → 3.6 shows quantifiable risk reduction.

18.7.1 Interactive DREAD Calculator

Calculate risk scores for your vulnerability:

Show code

viewof damage = Inputs.range([0, 10], {
  label: "Damage Potential (0-10):",
  step: 1,
  value: 5
})

viewof reproducibility = Inputs.range([0, 10], {
  label: "Reproducibility (0-10):",
  step: 1,
  value: 5
})

viewof exploitability = Inputs.range([0, 10], {
  label: "Exploitability (0-10):",
  step: 1,
  value: 5
})

viewof affected_users = Inputs.range([0, 10], {
  label: "Affected Users (0-10):",
  step: 1,
  value: 5
})

viewof discoverability = Inputs.range([0, 10], {
  label: "Discoverability (0-10):",
  step: 1,
  value: 5
})

Show code

dread_score = (damage + reproducibility + exploitability + affected_users + discoverability) / 5

dread_level = dread_score >= 8.0 ? "Critical" : dread_score >= 6.0 ? "High" : dread_score >= 4.0 ? "Medium" : "Low"

dread_color = dread_score >= 8.0 ? "#8E44AD" : dread_score >= 6.0 ? "#E74C3C" : dread_score >= 4.0 ? "#E67E22" : "#16A085"

dread_timeline = dread_score >= 8.0 ? "Emergency patch (<7 days)" : dread_score >= 6.0 ? "Urgent patch (<30 days)" : dread_score >= 4.0 ? "Scheduled patch (<90 days)" : "Next release cycle"

html`<div style="background: linear-gradient(135deg, #2C3E50 0%, #34495E 100%); color: white; padding: 25px; border-radius: 12px; margin: 20px 0;">
  <div style="display: flex; justify-content: space-between; align-items: center; margin-bottom: 20px;">
    <h4 style="margin: 0;">📊 DREAD Risk Score</h4>
    <div style="background: ${dread_color}; padding: 10px 20px; border-radius: 25px;">
      <strong>${dread_score.toFixed(1)}/10</strong> - ${dread_level}
    </div>
  </div>

  <div style="background: rgba(255,255,255,0.1); padding: 15px; border-radius: 8px; margin-bottom: 15px;">
    <h5 style="margin-top: 0;">Score Breakdown:</h5>
    <div style="display: grid; grid-template-columns: 1fr 1fr; gap: 10px;">
      <div style="background: rgba(0,0,0,0.2); padding: 8px; border-radius: 5px;">
        <strong>Damage:</strong> ${damage}/10
      </div>
      <div style="background: rgba(0,0,0,0.2); padding: 8px; border-radius: 5px;">
        <strong>Reproducibility:</strong> ${reproducibility}/10
      </div>
      <div style="background: rgba(0,0,0,0.2); padding: 8px; border-radius: 5px;">
        <strong>Exploitability:</strong> ${exploitability}/10
      </div>
      <div style="background: rgba(0,0,0,0.2); padding: 8px; border-radius: 5px;">
        <strong>Affected Users:</strong> ${affected_users}/10
      </div>
      <div style="background: rgba(0,0,0,0.2); padding: 8px; border-radius: 5px; grid-column: span 2;">
        <strong>Discoverability:</strong> ${discoverability}/10
      </div>
    </div>
  </div>

  <div style="background: rgba(255,255,255,0.1); padding: 15px; border-radius: 8px;">
    <h5 style="color: ${dread_color}; margin-top: 0;">Recommended Action:</h5>
    <p style="margin: 0; font-size: 1.1em;"><strong>${dread_timeline}</strong></p>
  </div>
</div>`

Common Pitfalls

1. Developing attack scenarios only from the attacker’s perspective

Scenario analysis is most valuable when paired with a defender’s perspective: for each attack step, identify which control would detect or block it. Scenarios without defender analysis are threat intelligence without security engineering value.

2. Using attack scenarios from different industries without adaptation

An attack scenario from a healthcare IoT breach report may not directly apply to an industrial IoT deployment with different network architecture, physical access controls, and attacker motivations. Adapt scenarios to the specific deployment context.

3. Treating low-probability scenarios as not worth analysing

Sophisticated supply-chain attacks and zero-day exploits are low-probability but catastrophic-impact events. Include at least one worst-case scenario in every analysis to test whether your architecture survives a sophisticated, targeted attack.

4. Not validating scenario assumptions with field personnel

Attack scenarios developed entirely by security engineers often contain false assumptions about what an attacker can realistically achieve physically (getting close enough to an industrial sensor to access its JTAG port). Validate scenarios with field operations staff.

Label the Diagram

💻 Code Challenge

18.8 Summary

This chapter explored real-world IoT attack scenarios and risk assessment methodologies:

Critical Attack Scenarios: How IoT systems are actually compromised - Default credentials enable botnet recruitment (Mirai) - Firmware vulnerabilities allow remote code execution - Man-in-the-middle attacks intercept unencrypted traffic - Physical access leads to device compromise - Supply chain attacks inject malware at manufacturing

DREAD Risk Scoring: Quantitative threat prioritization - Damage: Impact if exploited (0-10 scale) - Reproducibility: Consistency of exploit - Exploitability: Skill/effort required - Affected users: Scale of impact - Discoverability: Ease of finding vulnerability

Risk = (D + R + E + A + D) / 5

Worked Examples: Applying DREAD to real vulnerabilities - Smart lock firmware bug: DREAD = 7.6 (high priority) - CVSS 10.0 vulnerability with Changed Scope demonstrates maximum severity scoring - Interactive calculators enable hands-on risk assessment practice

Interactive Threat Assessment: Hands-on risk evaluation tool helps you score your own IoT system’s vulnerabilities and generate actionable remediation plans.

Key Insight: Threat modeling isn’t just theoretical - it directly maps to how attackers actually compromise IoT systems. Understanding these patterns helps you design effective defenses.

Continue to the Assessments chapter to test your understanding or jump to the Hands-On Lab for practical experience.

Concept Relationships

Understanding how attack scenarios and risk assessment concepts interconnect:

Core Concept	Prerequisite Skills	Validates Understanding Of	Enables Decision Making
Attack Scenario Analysis	System architecture, threat actors	Threat modeling (STRIDE), attack vectors	Defensive architecture design, penetration test scoping
DREAD Scoring	Threat identification (STRIDE), risk factors	Quantitative risk assessment, impact analysis	Budget allocation, remediation prioritization
CVSS vs DREAD	Vulnerability scoring systems	Exploitability, impact, scope	Patch management prioritization, SLA setting
Worked Examples (Smart Lock)	Real vulnerability analysis, ROI calculation	Cost-benefit security decisions	Executive security investment justification
Interactive Threat Assessment	Device categorization, risk factors	Context-specific risk (medical vs consumer)	Tailored mitigation recommendations

Key Insight: DREAD scoring transforms subjective “this seems bad” into objective “this scores 8.2/10, fix within 30 days.” Two vulnerabilities with the same CVSS score may have very different DREAD scores based on your deployment context (internet-exposed vs air-gapped, medical vs consumer).