15 OWASP IoT Top 10 Vulnerabilities

Learning Objectives

After completing this chapter, you will be able to:

Identify and explain the OWASP IoT Top 10 vulnerabilities and their real-world impact
Analyze how default credentials, insecure network services, and unpatched firmware create attack surfaces
Apply lessons from major IoT security incidents (Mirai botnet, Jeep Cherokee hack) to system design
Design mitigation strategies for each OWASP IoT Top 10 vulnerability category

Key Concepts

OWASP IoT Top 10: A community-maintained list of the ten most critical IoT security risks: Weak Passwords, Insecure Network Services, Insecure Ecosystem Interfaces, Lack of Secure Update Mechanism, Use of Insecure or Outdated Components, Insufficient Privacy Protection, Insecure Data Transfer and Storage, Lack of Device Management, Insecure Default Settings, and Lack of Physical Hardening.
Insecure network services: Unnecessary network-accessible services (Telnet, HTTP without TLS, SNMP) running on IoT devices that expand the attack surface and provide attackers with additional exploitation vectors.
Insecure ecosystem interfaces: Vulnerabilities in web dashboards, mobile applications, cloud APIs, and backend services that interact with IoT devices, providing indirect paths to device compromise.
Insufficient privacy protection: Collection, transmission, or storage of personal IoT data without appropriate consent, encryption, data minimisation, or retention controls — violating user privacy and regulatory requirements.
Lack of device management: The absence of centralised visibility into device inventory, health, firmware versions, and security posture, making it impossible to respond effectively to security incidents or deploy patches.
Lack of physical hardening: Insufficient physical security controls (accessible debug ports, easily removed storage, no tamper detection) that allow attackers with physical access to compromise device security.

In 60 Seconds

The OWASP IoT Top 10 identifies the ten most critical and prevalent security risks in IoT systems — from weak passwords and insecure network services to lack of secure update mechanisms — providing a prioritised, evidence-based starting point for IoT security assessment and hardening that is more practical than attempting to address every possible threat simultaneously.

For Beginners: OWASP IoT Top 10 Vulnerabilities

IoT security threats are the various ways that connected devices and their data can be compromised. Think of your IoT system as a house – you need to understand how burglars might try to get in before you can choose the right locks, alarms, and security cameras. This chapter helps you understand the threats so you can build effective defenses.

Sensor Squad: The Top 10 Mistakes to Avoid!

“OWASP made a list of the ten worst security mistakes in IoT, and guess what number one is?” Sammy the Sensor asked the group. “Weak and default passwords! The Mirai botnet tried just 62 common passwords and took over 600,000 devices. That is like leaving your front door unlocked with a sign that says ‘Come on in!’”

Max the Microcontroller went through the list. “Number two is insecure network services – things like Telnet and open ports. Number three is insecure interfaces like web panels with no protection. Number four is no update mechanism, which means bugs can never be fixed. Each one is a real door that attackers walk through every day!”

“My least favorite on the list is ‘Insufficient Privacy Protection,’” Lila the LED said. “Some devices collect way more data than they need and store it without encryption. Smart TVs recording conversations, fitness trackers sharing your location with advertisers – that is not just a security risk, it is a privacy invasion!”

“The good news is that most of these are easy to fix IF you know about them,” Bella the Battery said cheerfully. “Change default passwords: done. Encrypt your data: done. Disable unused services: done. Add a firmware update mechanism: done. The OWASP Top 10 is like a checklist – go through it item by item, and your device will be safer than 90 percent of IoT products out there!”

15.1 OWASP IoT Top 10 Vulnerabilities

How It Works: Mirai Botnet Attack Propagation

The 2016 Mirai botnet demonstrated how IoT vulnerabilities cascade into massive attacks:

Phase 1: Scanning (Reconnaissance)

Botnet scans internet IP ranges for open Telnet (port 23) and SSH (port 22)
Uses SYN scan to minimize detection (half-open connections)
Identifies ~600,000 vulnerable devices in first 72 hours

Phase 2: Credential Attack

Automated login attempts using 62 hardcoded default credentials
Common pairs: admin/admin, root/root, admin/12345
Success rate: ~40% of discovered devices (240,000+ compromised)

Phase 3: Malware Installation

Downloads lightweight malware loader (6-8 KB)
Malware runs in memory only (no disk writes avoid detection)
Closes original exploit port after infection (prevents re-infection by competitors)

Phase 4: Command & Control Enrollment

Infected device connects to C2 server via IRC or custom protocol
Awaits commands for DDoS attacks
Reports device type, bandwidth, geolocation

Phase 5: DDoS Execution

C2 server commands all bots to flood target simultaneously
Peak attack: 620 Gbps against Dyn DNS (October 2016)
Attack types: UDP flood, TCP SYN flood, HTTP flood

Phase 6: Persistence and Spread

Infected devices scan for new victims (exponential growth)
Reinfection after reboot (malware memory-only, reboots clean device but rescanning continues)

Why It Worked: Combination of OWASP IoT vulnerabilities: - I1: Default credentials never changed - I4: Telnet enabled and exposed to internet - I5: No firmware update mechanism to patch - I10: Insecure default settings (Telnet enabled, UPnP active)

Defense: Any single fix would have broken the attack chain - changing default passwords, disabling Telnet, or enabling automatic updates would have prevented 600,000+ compromises.

The Most Critical IoT Security Risks

The Open Web Application Security Project (OWASP) identifies the top 10 IoT vulnerabilities based on industry-wide research and real-world incident analysis:

Rank	Vulnerability	Description	Real-World Impact	Example
I1	Insufficient Security Configurability	Weak/default passwords, no password requirements	80% of IoT devices fail basic password requirements	Mirai botnet: 600,000+ devices compromised via “admin/admin”
I2	Insecure Web Interface	XSS vulnerabilities, weak session management, exposed admin panels	Allows remote takeover via browser attacks	Unprotected smart camera web interfaces exposing live feeds
I3	Insufficient Authentication	Default credentials never changed	540,000 devices in 2010 using factory defaults	IP cameras with hardcoded username “admin”, password “12345”
I4	Insecure Network Services	Telnet, SSH, UPnP exposed without encryption	70% of IoT devices transmit data unencrypted	Exposed Telnet on port 23 allowing remote command execution
I5	Insecure Software/Firmware	No update mechanism, unsigned updates	“Unpatchable” devices with unfixable vulnerabilities	Devices running 10+ year old Linux kernels with known CVEs
I6	Hardware Limitations	Insufficient CPU/RAM for security features	Debug ports (JTAG) accessible, USB tamper	JTAG ports exposed allowing firmware extraction and modification
I7	Insecure Cloud Interface	Weak API authentication, credential theft	Cloud credentials leaked in mobile apps	Smart lock APIs exposing user location and access history
I8	Unintended Device Usage	Devices used in unintended contexts	Privacy violations, cheating, surveillance	Smartwatch used for exam cheating by students
I9	Privacy Concerns	Excessive data collection, passive tracking	Users tracked without consent or knowledge	Retail beacons tracking shoppers via smartphone MAC addresses
I10	Insecure Default Settings	Debug features enabled, no mandatory password change on first use	Devices shipped in insecure state	UPnP enabled by default allowing network exposure

15.2 Case Studies

15.2.1 Case Study: Mirai Botnet (2016)

Diagram showing botnet architecture with command and control server directing infected IoT devices to launch DDoS attacks against targets — Figure 15.1: Botnet attack architecture

What happened:

Malware scanned for IoT devices with default credentials
Infected 600,000+ cameras, DVRs, routers (peak infection)
Launched 620 Gbps DDoS attack on Dyn DNS (October 21, 2016)
Took down Twitter, Netflix, Reddit, CNN, GitHub, Spotify

Root cause: I1 (default passwords) + I4 (exposed Telnet/insecure network services)

Lesson: A single vulnerability (default password) compromised hundreds of thousands of devices

15.2.2 Case Study: LockState Smart Locks (2017)

What happened:

OTA firmware update had critical bug
Bricked 200 smart locks at AirBnB properties
Guests locked out, hosts couldn’t access properties
Required physical lock replacement

Root cause: I5 (insecure firmware update mechanism) - No rollback capability - No staged rollout - No update verification before deployment

Lesson: IoT updates must be tested, staged, and reversible

15.3 Deep Dive: IoT Botnet Attack Patterns and Defense

IoT botnets represent one of the most significant threats to internet infrastructure. Understanding their architecture, propagation methods, and defense strategies is critical for securing IoT deployments at scale.

15.3.1 Botnet Architecture Evolution

First Generation (Mirai-style, 2016):

Centralized Command & Control server
Single point of failure for takedown
Hardcoded C2 domains

Second Generation (Peer-to-Peer, 2018+):

Decentralized P2P architecture
Commands propagate peer-to-peer
No single point of failure

15.3.2 Attack Lifecycle Phases

Phase	Mirai Method	Modern Variants	Detection Opportunity
1. Reconnaissance	Scan port 23 (Telnet), 22 (SSH)	Port 80/443/8080, UPnP discovery	Unusual port scan patterns
2. Weaponization	Hardcoded 62 default credentials	Dictionary attacks, CVE exploits	Failed login rate spike
3. Delivery	Telnet brute force	Zero-day exploits, supply chain	Exploit signature matching
4. Installation	Memory-resident (doesn’t survive reboot)	Persistent (firmware modification)	File integrity monitoring
5. C2 Communication	Hardcoded C2 domains	DGA (Domain Generation Algorithm)	DNS anomaly detection
6. Actions	DDoS (TCP/UDP floods)	Cryptomining, data exfiltration, ransomware	Traffic volume/pattern analysis

15.3.3 Propagation Techniques

Credential-Based (Most Common):

# Mirai-style credential stuffing (simplified)
DEFAULT_CREDS = [
    ("admin", "admin"), ("root", "root"), ("admin", "1234"),
    ("root", "12345"), ("admin", ""), ("support", "support"),
    # ... 62 credential pairs in original Mirai
]

def scan_and_infect(target_ip):
    for username, password in DEFAULT_CREDS:
        if try_telnet_login(target_ip, username, password):
            download_and_execute_payload(target_ip)
            report_to_c2(target_ip)  # New bot enrolled
            break

Exploit-Based (Increasing):

CVE-2017-17215: Huawei router RCE (Satori botnet)
CVE-2018-10561: GPON router auth bypass (VPNFilter)
CVE-2020-9054: Zyxel NAS command injection
Supply chain: Compromised firmware images, SDK backdoors

15.3.4 DDoS Attack Types Launched by IoT Botnets

Attack Type	Mechanism	Mirai Peak	Mitigation
UDP Flood	High-volume UDP packets	620 Gbps	Rate limiting, scrubbing
TCP SYN Flood	Exhaust connection tables	300k pps	SYN cookies, firewalls
HTTP GET Flood	Application layer requests	1.2M rps	WAF, CAPTCHA
DNS Amplification	Spoofed queries to open resolvers	1.2 Tbps	BCP38 (source validation)
GRE Flood	Tunnel protocol abuse	400 Gbps	Protocol filtering

15.3.5 Network-Level Defense Strategies

Defense-in-Depth Architecture:

DDoS Scrubbing Center (Cloud-based) - Absorbs volumetric attacks
Firewall + IPS/IDS - Block known C2 IPs/domains
Network Segmentation - Limit lateral movement
IoT Gateway - Protocol inspection, anomaly detection

Device-Level Hardening:

# Essential IoT security configuration
# 1. Disable unnecessary services
systemctl disable telnet ssh-legacy
ufw deny 23  # Block Telnet

# 2. Change default credentials (MANDATORY)
passwd root  # Unique, complex password

# 3. Enable automatic updates
apt-get install unattended-upgrades
dpkg-reconfigure -plow unattended-upgrades

# 4. Restrict outbound connections
iptables -A OUTPUT -p tcp --dport 23 -j DROP  # Block Telnet out
iptables -A OUTPUT -p tcp --dport 22 -j DROP  # Block SSH scanning

# 5. Monitor for anomalies
tail -f /var/log/auth.log | grep "Failed password"

15.3.6 Detection Indicators

Host-Based Indicators:

Unexpected processes: /tmp/.x, /var/run/.t
Modified binaries: /bin/busybox checksum mismatch
New cron jobs or startup scripts
Memory-resident processes (no disk footprint)

15.3.7 Implementation Checklist for IoT Manufacturers

No default credentials: Unique per-device password on label
Mandatory password change: Block operation until changed
Disable Telnet/SSH by default: Enable only via physical button
Signed firmware updates: Reject unsigned/tampered images
Secure boot chain: Verify bootloader -> kernel -> userspace
Network behavior allowlist: Alert on unexpected connections
Auto-update mechanism: Silent security patches
Vulnerability disclosure program: Coordinate with researchers
End-of-life security policy: Update commitment period

15.3.8 Regulatory Responses

Regulation	Region	Key Requirements	Effective
ETSI EN 303 645	EU	No default passwords, vulnerability disclosure	2024
California SB-327	US (CA)	Unique passwords, reasonable security	2020
PSTI Act	UK	Password requirements, update period disclosure	2024
NIST IR 8259	US	Baseline capabilities for IoT devices	Voluntary

15.4 Security Tradeoffs

Tradeoff: Continuous Vulnerability Scanning vs Periodic Penetration Testing

Option A: Continuous automated vulnerability scanning - cost ~$5-15K/year for enterprise scanner (Qualys, Tenable), detects known CVEs within 24 hours of disclosure, 15-30% false positive rate, covers 100% of network-accessible assets weekly, minimal human expertise required

Option B: Periodic third-party penetration testing - cost ~$15-50K per engagement, discovers unknown/complex vulnerabilities through manual exploitation, 2-5% false positive rate, quarterly or annual coverage, requires 2-4 week engagement windows

Decision Factors:

Choose continuous scanning for large IoT fleets (1,000+ devices), compliance requirements (PCI-DSS, HIPAA), budget constraints, or rapid CVE patching needs
Choose penetration testing for validating security architecture, assessing complex attack chains, compliance mandates (SOC 2 Type II), or testing physical security

Best practice: Combine both - continuous scanning for breadth (known vulnerabilities), annual penetration testing for depth (unknown vulnerabilities). Budget allocation: 70% scanning infrastructure, 30% expert testing.

Tradeoff: Zero Trust Architecture vs Perimeter-Based Security

Option A: Zero Trust (“never trust, always verify”) - every device request authenticated/authorized regardless of network location, micro-segmentation isolates each device, implementation cost ~$200-500K, operational overhead increases 40-60%, eliminates lateral movement

Option B: Perimeter-based security with trusted internal network - firewall at boundary, devices trust each other within VLAN, implementation cost ~$50-100K, lower operational overhead, vulnerable to insider threats

Decision Factors:

Choose Zero Trust for high-value targets (medical, industrial control), regulatory requirements (IEC 62443), untrusted physical environments, or safety-critical systems
Choose perimeter security for physically secured facilities, low-value sensors, budget constraints, or legacy device compatibility

Key metric: Average breach dwell time drops from 280 days (perimeter) to 30 days (Zero Trust) due to continuous verification detecting anomalies faster.

15.5 Knowledge Checks

Concept Relationships

Concept	Relates To	Nature of Relationship
Default Credentials (I1)	Authentication Bypass	Weak passwords enable immediate unauthorized access
Insecure Network Services (I4)	Attack Surface	Each exposed service is potential entry point
Lack of Updates (I5)	Vulnerability Persistence	Unfixable devices accumulate known exploits over time
Botnet Architecture	Distributed Attacks	Aggregated compromised devices create massive attack capacity
Mirai Botnet	OWASP I1 + I4 + I5	Single vulnerability chain enabled 600K device compromise
DDoS Mitigation	Cloud Scrubbing	On-premise defenses fail against volumetric attacks

15.6 Knowledge Check

Quiz: OWASP IoT Top 10 Vulnerabilities

Worked Example: Securing a Smart Camera Against OWASP Top 10

Device: Wyze Cam v3 (hypothetical security audit before product launch)

OWASP I1 - Weak Passwords: Factory default is unique per-device QR code (strength: 12 alphanumeric characters printed on base). On first setup, app forces user to create account password with minimum requirements (8+ chars, 1 number, 1 special). Pass - no shared default, mandatory change.

OWASP I2 - Insecure Web Interface: Camera exposes web UI on port 80 for local configuration. Audit reveals: - Session cookies lack HttpOnly flag (XSS can steal session) - No CSRF tokens (attacker can forge requests) - Fix: Add HttpOnly; Secure; SameSite=Strict to cookies, implement CSRF tokens, redirect HTTP → HTTPS

OWASP I4 - Insecure Network Services: Telnet enabled on port 23 for “manufacturing diagnostics” (forgot to disable in production firmware). Critical vulnerability - allows root shell with no password. Fix: Remove Telnet entirely, replace with SSH with key-based auth (disabled by default, requires physical button press to enable).

OWASP I5 - Insecure Firmware: OTA updates downloaded over HTTP (not HTTPS), no signature verification. Attacker on network can inject malicious firmware. Fix: 1. HTTPS for download (prevents MITM) 2. ECDSA signature verification before flash 3. Dual-bank bootloader with automatic rollback if new firmware fails to boot

OWASP I6 - Hardware: UART pins exposed on PCB (4-pin header labeled TX/RX/GND/VCC). Attacker with physical access gets root shell in 30 seconds. Partial fix: Disable UART in production fuses, require factory reset + physical button hold to re-enable (reduces casual attacks, won’t stop determined adversary with chip-off attacks).

Quantified Results:

Pre-audit: Vulnerable to 7/10 OWASP IoT categories
Post-fix: Vulnerable to 2/10 (I6 hardware attack still possible, I9 privacy concerns around cloud data retention)
Development cost: 3 weeks additional firmware work ($15,000), $0.40/unit BOM cost (secure boot MCU), $8,000 penetration testing
Total security investment: $23,000 + $0.40/unit
Compare to: One CVE disclosure + mandatory recall = estimated $500,000 (reputation damage, firmware re-spin, customer notifications)

Decision Framework: Penetration Testing vs. Automated Scanning

Option A: Automated Vulnerability Scanning

Tools: Nessus, Qualys, OpenVAS scan network for known CVEs, open ports, weak configs
Cost: $5,000-15,000/year subscription
Coverage: 60-70% of OWASP I4 (Insecure Network Services), I2 (Web Interface), I10 (Defaults)
Speed: Scans 1,000 devices in 2-4 hours
Limitation: Only finds known vulnerabilities; 30-40% false positives

Option B: Manual Penetration Testing

Security researchers manually probe for vulnerabilities, chain exploits
Cost: $15,000-50,000 per engagement (2-4 weeks)
Coverage: 90%+ of OWASP Top 10, discovers novel attack chains
Speed: 1-5 devices in 2-4 weeks
Limitation: Expensive; requires skilled testers

Option C: Hybrid (Recommended)

Automated scanning weekly during development
Manual pentest at 3 milestones: prototype, pre-production, post-launch
Bug bounty program for ongoing discovery

Product Stage	Testing Approach	Budget Allocation
Early prototype	Automated scanning only	$5K/year scanner
Beta / Pre-production	Automated + 1 pentest	$5K + $25K pentest
Launch	Automated + pentest + bug bounty	$5K + $25K + $10K bounty pool
Post-launch (ongoing)	Automated + annual pentest	$5K + $20K/year

Decision factors:

Device count: >1,000 units deployed → automated scanning essential
Risk level: Payment/healthcare data → manual pentest mandatory
Budget: <$20K → automated only; >$50K → hybrid with bounties
Compliance: PCI-DSS, SOC 2 → annual pentest required

Common mistake: Only testing once at launch, then never again. Vulnerabilities appear continuously (new CVEs, dependency updates, firmware changes). Ongoing automated scanning catches regressions.

Common Mistake: Assuming HTTPS Alone Secures API Communication

What practitioners do wrong: Switching an IoT device’s API from HTTP to HTTPS and assuming all communication security problems are solved. The device sends authenticated requests like:

POST https://api.example.com/device/update
Authorization: Bearer abc123-device-token

Why it fails: HTTPS encrypts transport but doesn’t prevent: 1. Token theft: If device is compromised (I6 hardware attack), attacker extracts abc123-device-token from firmware/config 2. Token reuse: That token often has no expiration, allowing indefinite impersonation 3. Missing token rotation: Same token used for months/years 4. No device attestation: Server can’t verify request came from legitimate hardware vs. attacker replaying stolen token

Real-world example - Nest thermostat vulnerability (2014): Researcher extracted OAuth tokens from Nest device firmware. Tokens had no expiration and could be used from any IP address indefinitely. With one stolen token, attacker controlled user’s thermostat permanently until user manually revoked it (which most users never do).

Correct approach - Defense in depth:

HTTPS: Prevents eavesdropping (baseline, not sufficient alone)
Short-lived tokens: Access tokens expire after 1 hour, refresh tokens after 30 days
Token rotation: Device requests new token before expiration
Mutual TLS (mTLS): Server verifies device certificate, device verifies server certificate
Hardware attestation: Secure element (TPM, secure enclave) proves token came from legitimate hardware
Anomaly detection: Server flags token use from unusual geo-location or at unusual times

Practical implementation for IoT:

Consumer devices: HTTPS + token rotation (1-hour expiry) = minimum
High-security devices: mTLS + hardware attestation + rate limiting
Payment terminals: All of above + PCI-DSS compliance audit

The OWASP I7 (Insecure Cloud Interface) category specifically calls out the assumption that HTTPS alone is sufficient. It’s not - tokens must be protected, rotated, and validated.

Putting Numbers to It: Vulnerability Prevalence Statistics

Vulnerability prevalence is the probability that a randomly selected IoT device contains a specific weakness class.

\[P(V_i) = \frac{N_{\text{vulnerable to } i}}{N_{\text{total devices scanned}}}\]

Worked Calculation: Mirai Botnet Infection Rate

Given: 2016 Mirai botnet targeting default credentials (OWASP I1)

Step 1: Calculate credential attack success rate - Devices scanned: $N_{\text{scan}} = 600,000$ - Devices with default credentials: $N_{\text{vuln}} = 540,000$ \[P(\text{default creds}) = \frac{540,000}{600,000} = 0.90\]

Step 2: Calculate exploitation probability - Mirai credential list: 62 username/password pairs - Average attempts to compromise: 12 pairs (median position in list) - Exploitation rate: $P(\text{exploit | vuln}) = 0.85$ (timeout/network factors)

Step 3: Calculate botnet growth rate \[\frac{dI}{dt} = \beta S I - \gamma I\]

where $S$ = susceptible devices, $I$ = infected devices, $\beta$ = infection rate, $\gamma$ = removal rate

With $\beta = 0.0003$ (per-contact infection probability), $\gamma = 0.05$ (daily patch/reboot rate): \[I(t) = \frac{S_0}{1 + \left(\frac{S_0}{I_0} - 1\right) e^{-(\beta S_0 - \gamma)t}}\]

For $S_0 = 600,000$, $I_0 = 100$ (initial infections): \[I(72 \text{ hours}) = \frac{600,000}{1 + 5,999 \times e^{-0.108 \times 72}} \approx 380,000\]

Result: Epidemiological model predicts 380,000 infections in 72 hours, matching observed Mirai growth. The 90% prevalence of default credentials created conditions for exponential spread.

Step 4: Calculate economic impact per vulnerability class | OWASP Category | Prevalence | Avg Exploit Cost | Mitigation Cost | ROI | |—————-|————|——————|—————–|—–| | I1 Default Credentials | 90% | $0 | $500/device | ∞ | | I4 Insecure Services | 70% | $200 (scanner) | $1,000/device | 500% | | I5 No Updates | 85% | $50 (exploit) | $2,000/device | 4,250% |

In practice: OWASP Top 10 ranks vulnerabilities by prevalence × exploitability. I1 (default credentials) ranks #1 because 90% prevalence makes it the path of least resistance for attackers, despite being trivial to fix.

15.6.1 Interactive Calculator: Botnet Growth Simulation

Try adjusting the parameters to see how different factors affect botnet propagation:

Show code

viewof S0 = Inputs.range([10000, 1000000], {
  value: 600000,
  step: 10000,
  label: "Susceptible devices (S₀)"
})

viewof I0 = Inputs.range([10, 1000], {
  value: 100,
  step: 10,
  label: "Initial infections (I₀)"
})

viewof beta = Inputs.range([0.0001, 0.001], {
  value: 0.0003,
  step: 0.0001,
  label: "Infection rate (β)",
  format: x => x.toFixed(4)
})

viewof gamma = Inputs.range([0.01, 0.2], {
  value: 0.05,
  step: 0.01,
  label: "Removal rate (γ)",
  format: x => x.toFixed(2)
})

viewof time_hours = Inputs.range([1, 168], {
  value: 72,
  step: 1,
  label: "Time (hours)"
})

// Calculate infections over time
function calcInfections(t) {
  const exponent = -(beta * S0 - gamma) * t;
  return S0 / (1 + ((S0 / I0) - 1) * Math.exp(exponent));
}

infections_at_time = calcInfections(time_hours)

// Generate time series data
time_series = {
  const points = [];
  for (let t = 0; t <= time_hours; t += 1) {
    points.push({
      time: t,
      infections: calcInfections(t),
      susceptible: S0 - calcInfections(t)
    });
  }
  return points;
}

Plot.plot({
  width: 700,
  height: 400,
  marginLeft: 60,
  marginBottom: 50,
  grid: true,
  style: {
    fontSize: "12px",
    fontFamily: "Arial, sans-serif"
  },
  x: {
    label: "Time (hours) →",
    labelOffset: 40
  },
  y: {
    label: "↑ Number of devices",
    labelOffset: 50,
    tickFormat: d => d >= 1000 ? `${(d/1000).toFixed(0)}K` : d
  },
  color: {
    legend: true,
    domain: ["Infected", "Susceptible"],
    range: ["#E74C3C", "#16A085"]
  },
  marks: [
    Plot.line(time_series, {
      x: "time",
      y: "infections",
      stroke: "#E74C3C",
      strokeWidth: 2.5,
      tip: true
    }),
    Plot.line(time_series, {
      x: "time",
      y: "susceptible",
      stroke: "#16A085",
      strokeWidth: 2.5,
      tip: true
    }),
    Plot.text([{x: time_hours/2, y: S0 * 0.7, label: "Infected"}], {
      x: "x",
      y: "y",
      text: "label",
      fill: "#E74C3C",
      fontSize: 14,
      fontWeight: "bold"
    }),
    Plot.text([{x: time_hours/2, y: S0 * 0.3, label: "Susceptible"}], {
      x: "x",
      y: "y",
      text: "label",
      fill: "#16A085",
      fontSize: 14,
      fontWeight: "bold"
    })
  ]
})

Show code

html`<div style="margin-top: 20px; padding: 15px; background: #f8f9fa; border-left: 4px solid #3498DB; font-family: Arial, sans-serif;">
  <div style="font-size: 16px; font-weight: bold; color: #2C3E50; margin-bottom: 10px;">Results at ${time_hours} hours:</div>
  <div style="font-size: 14px; color: #2C3E50;">
    <strong>Infected devices:</strong> ${infections_at_time.toLocaleString(undefined, {maximumFractionDigits: 0})}
    (${((infections_at_time/S0)*100).toFixed(1)}% of susceptible population)
  </div>
  <div style="font-size: 14px; color: #2C3E50; margin-top: 8px;">
    <strong>Infection rate (R₀):</strong> ${(beta * S0 / gamma).toFixed(2)}
    ${beta * S0 > gamma ? '<span style="color: #E74C3C;">(Exponential growth)</span>' : '<span style="color: #16A085;">(Decline)</span>'}
  </div>
  <div style="font-size: 12px; color: #7F8C8D; margin-top: 12px; font-style: italic;">
    Model: SIR (Susceptible-Infected-Removed) epidemiological dynamics. R₀ > 1 indicates exponential spread. The Mirai botnet achieved R₀ ≈ 3.6 with these parameters.
  </div>
</div>`

Match: OWASP IoT Top 10 Vulnerabilities to Real-World Exploits

Order: OWASP IoT Security Audit Process

Label the Diagram

15.7 What’s Next

If you want to…	Read this
Apply STRIDE to go deeper than the OWASP Top 10	STRIDE Framework
Understand how to assess against the OWASP Top 10	Threats Assessments
See Top 10 vulnerabilities exploited in attack scenarios	Threat Attack Scenarios
Study compliance frameworks built on OWASP principles	Threats Compliance
Return to the security module overview	IoT Security Fundamentals

Common Pitfalls

1. Treating the OWASP Top 10 as a complete security checklist

The OWASP IoT Top 10 covers the most common risks but not all relevant risks for every deployment. For critical infrastructure or medical devices, supplement the Top 10 with sector-specific threat modelling and applicable regulatory requirements.

2. Addressing Top 10 items in numerical order rather than risk order

The Top 10 is not a priority ranking — it is a categorisation of common risks. Assess which items have the highest actual risk in your specific deployment context and address them in risk-priority order rather than by list position.

3. Implementing mitigations for one Top 10 item in isolation

Many Top 10 mitigations are interdependent. Implementing secure update mechanisms (item 4) without device identity (item 10) means updates cannot be authenticated. Address related items together and validate that mitigations work correctly in combination.

4. Not reassessing against the Top 10 after system changes

Adding a new device type, a new cloud integration, or a new management interface creates new potential risks that should be assessed against the Top 10. Schedule OWASP Top 10 reviews whenever the system architecture changes significantly.

💻 Code Challenge