8  Cyber Security Methods

8.1 Overview

Cybersecurity methods translate security principles into concrete technical implementations for IoT systems. This comprehensive guide covers cryptographic techniques, authentication mechanisms, access control frameworks, secure communication protocols, firmware verification, and security monitoring - the essential building blocks for protecting IoT deployments against modern threats.

For Kids: Meet the Sensor Squad!

Authentication and Access Control are like having a secret clubhouse with special rules about who can come in and what they can do!

8.1.1 The Sensor Squad Adventure: The Clubhouse Guardians

The Sensor Squad had built an amazing treehouse headquarters! But they needed to make sure only their friends could get in and that everyone followed the rules. Motion Mo the Motion Detector had an idea.

“We need THREE things to keep our clubhouse safe!” said Motion Mo. First, they created a SECRET PASSWORD that only Sensor Squad members knew. When someone wanted to enter, they had to say the password - that’s called AUTHENTICATION (proving who you are).

But Sunny the Light Sensor was worried. “What if someone learns our password?” So Signal Sam the Communication Expert added something even better - a special BADGE that showed your picture AND the password. Now you needed TWO things to get in! (This is like how some apps send a code to your phone after you type your password - that’s called TWO-FACTOR AUTHENTICATION!)

Thermo the Temperature Sensor thought of the final piece. “Even our friends shouldn’t be able to do EVERYTHING in the clubhouse. My little brother can come in, but he shouldn’t touch the snack cabinet!” So they made a list of ACCESS CONTROLS - rules about what each person could do.

8.1.2 Key Words for Kids

Word	What It Means
Authentication	Proving you are who you say you are (like showing your ID)
Access Control	Rules about what you’re allowed to do after you get in
Password	A secret word or phrase that only you know
Two-Factor	Using TWO ways to prove it’s really you
Permission	Approval to do something specific

8.2 Learning Objectives

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

• Implement cryptographic techniques appropriate for resource-constrained IoT devices
• Design secure authentication and authorization systems for device fleets
• Select and apply access control mechanisms suited to IoT deployment scenarios
• Configure secure communication protocols (TLS/DTLS) for MQTT and CoAP
• Evaluate secure boot and firmware verification chains for tamper resistance
• Integrate intrusion detection and prevention systems into IoT monitoring architectures

In 60 Seconds

IoT cyber security methods encompass the techniques, tools, and processes used to protect IoT devices and data from unauthorised access, tampering, and disruption — ranging from cryptographic authentication to network monitoring to secure coding practices. The critical insight is that IoT security requires adapting enterprise security methods to the severe resource, connectivity, and physical constraints of embedded devices.

For Beginners: Cyber Security Methods

Cybersecurity methods are the tools and techniques you use to protect IoT devices and their data. Think of your IoT system as a house – these methods are the locks, alarms, security cameras, and ID checks that keep intruders out and your data safe. This chapter introduces the six key methods (encryption, authentication, access control, secure communications, firmware verification, and monitoring) and guides you through learning each one.

8.3 Chapter Guide

This topic is covered across six focused chapters:

8.3.1 1. Defense in Depth and Security Controls

Learn the foundational security architecture that layers multiple independent controls to protect IoT systems even when individual defenses fail.

Topics covered:

• Eight-layer defense model
• Preventive, detective, and corrective controls
• Security controls by IoT layer

8.3.2 2. Cryptography for IoT

Master the cryptographic primitives that protect IoT data - from symmetric encryption for sensor readings to digital signatures for firmware verification.

Topics covered:

• Symmetric encryption (AES, ChaCha20)
• Asymmetric encryption (RSA, ECC)
• Hash functions and HMAC
• Algorithm selection for constrained devices

8.3.3 3. Authentication Methods

Implement identity verification systems from simple passwords to certificate-based mutual TLS, ensuring only authorized devices and users access your IoT platform.

Topics covered:

• Password-based authentication with secure storage
• Certificate-based mutual TLS (mTLS)
• Token-based authentication (JWT)
• Multi-factor authentication (TOTP)

8.3.4 4. Access Control

Design authorization policies that determine what authenticated entities can do, from simple role-based systems to context-aware attribute-based controls.

Topics covered:

• Role-Based Access Control (RBAC)
• Attribute-Based Access Control (ABAC)
• Principle of least privilege
• Audit logging for compliance

8.3.5 5. Secure Communications and Firmware Integrity

Protect data in transit with TLS/DTLS and ensure firmware authenticity through secure boot chains and cryptographic verification of OTA updates.

Topics covered:

• TLS/SSL for MQTT
• DTLS for CoAP
• WireGuard VPN for remote access
• Secure boot implementation
• OTA update security

8.3.6 6. Security Monitoring and Intrusion Detection

Detect attacks that bypass preventive controls through signature-based and anomaly-based monitoring, with comprehensive logging for forensic analysis.

Topics covered:

• Signature-based vs anomaly-based IDS
• Security logging and audit trails
• SIEM integration
• Practice exercises

Knowledge Check: Security Method Interdependence

Question: An IoT system uses strong AES-256 encryption for all sensor data but does not implement any authentication mechanism. Why does encryption alone fail to protect the system?

Click to reveal answer

Answer: Without authentication, an attacker can perform a man-in-the-middle attack by presenting their own encryption keys to both the device and the server. The device encrypts data using the attacker’s key (believing it to be the server’s), and the attacker decrypts, reads, potentially modifies, then re-encrypts and forwards the data.

Key Principle: Encryption protects confidentiality but cannot verify identity. Authentication and encryption must work together.

8.4 Quick Reference

Topic	Chapter	Key Concepts
Layered security	Defense in Depth	8 layers, control types
Encryption	Cryptography	AES, RSA, ECC, SHA-256
Identity	Authentication	Passwords, certs, JWT, MFA
Permissions	Access Control	RBAC, ABAC, least privilege
Data protection	Secure Communications	TLS, DTLS, VPN, secure boot
Detection	Monitoring	IDS, logging, SIEM

8.5 Recommended Learning Path

For beginners: Start with Defense in Depth to understand the overall security architecture, then proceed through the chapters in order.

For practitioners: Jump directly to the specific topic you need - each chapter is self-contained with prerequisites clearly noted.

For implementation: The Monitoring chapter includes four comprehensive practice exercises covering RBAC, mTLS, anomaly detection, and secure OTA updates.

8.6 Concept Relationships

How Security Methods Connect

Core Concept	Builds Upon	Enables	Real-World Application
Defense in Depth	Security principles	All other methods	Layered protection ensures single failure doesn’t compromise system
Cryptography	Mathematical foundations	Secure communications, authentication	Protects data confidentiality and integrity
Authentication	Cryptography	Access control, audit logging	Verifies identity before granting access
Access Control	Authentication	Least privilege enforcement	Limits what authenticated users can do
Secure Communications	Cryptography, Authentication	Trusted data exchange	Protects data in transit between devices
Monitoring	All security layers	Breach detection, forensics	Catches attacks that bypass preventive controls

Critical Insight: These methods form an interconnected security ecosystem. Encryption without authentication allows MITM attacks. Authentication without access control grants everyone full privileges. Access control without monitoring prevents breach detection. All six methods must work together for defense-in-depth.

8.7 Videos

Video: Security Vulnerabilities in IoT Systems

Comprehensive overview of common security vulnerabilities in IoT deployments and the methods used to address them through authentication, authorization, and encryption.

Video: Hardware Trojans and Supply Chain Security

Deep dive into hardware trojans - malicious modifications to integrated circuits - and how they threaten IoT device security at the chip level.

Match: Security Methods to Their Primary Purpose

Order: Security Implementation Priority (Most Critical First)

Label the Diagram

8.8 Key Takeaways

• Defense in depth layers multiple independent controls so failure of one doesn’t compromise the entire system
• Cryptography provides confidentiality (AES), integrity (SHA-256), and authentication (RSA/ECC signatures)
• Authentication verifies identity; authorization determines permissions - implement both
• Least privilege grants minimum necessary permissions; audit and remove unused access quarterly
• Secure boot creates chain of trust from immutable hardware through firmware
• Monitoring detects attacks that bypass preventive controls; log everything for forensics

8.9 Knowledge Check

Quiz: Cyber Security Methods

Worked Example: Implementing Multi-Layer Security for Smart Building

Scenario: A smart building system with 500 IoT devices (HVAC, lighting, access control, cameras) experienced a breach when attackers compromised one temperature sensor and gained access to the entire network, including security cameras and door locks.

Initial (Insecure) Architecture:

All 500 devices on single flat network (192.168.1.0/24)
→ Default passwords on 60% of devices
→ No encryption between devices and server
→ Single admin account for all devices
→ No monitoring or logging
→ Result: One compromised sensor = full network access

Redesign Using Defense-in-Depth (8 Layers):

Layer 1: Perimeter Security (Firewall)

# Linux iptables firewall rules
# Block all inbound except VPN
iptables -P INPUT DROP
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp --dport 1194 -j ACCEPT  # VPN only

# Rate limiting (prevent DDoS)
iptables -A INPUT -p tcp --syn -m limit --limit 10/s -j ACCEPT

Layer 2: Network Segmentation (VLANs)

VLAN 10: HVAC sensors (192.168.10.0/24)
VLAN 20: Lighting controllers (192.168.20.0/24)
VLAN 30: Access control (192.168.30.0/24)
VLAN 40: Security cameras (192.168.40.0/24)
VLAN 99: Management (192.168.99.0/24)

# Firewall rules between VLANs:
VLAN 10 → VLAN 99: MQTT port 8883 only (TLS)
VLAN 10 → VLAN 20: BLOCKED (HVAC cannot talk to lights)
VLAN 30 → VLAN 40: Allowed (access control triggers cameras)

Layer 3: Device Authentication (Certificate-Based)

# MQTT broker: Require client certificates
mqtt_config = {
    'cafile': '/etc/mqtt/ca.crt',           # Certificate Authority
    'certfile': '/etc/mqtt/server.crt',     # Server cert
    'keyfile': '/etc/mqtt/server.key',      # Server key
    'cert_reqs': ssl.CERT_REQUIRED,         # Require client certs
    'tls_version': ssl.PROTOCOL_TLS_CLIENT   # TLS 1.2+ (auto-negotiates highest)
}

# Each device has unique certificate (no shared passwords)
# If one device compromised: revoke its cert, others unaffected

Layer 4: Encryption (TLS/DTLS)

// ESP32 device code: MQTT over TLS
#include <WiFiClientSecure.h>
#include <PubSubClient.h>

WiFiClientSecure espClient;
PubSubClient mqtt(espClient);

// Load device-specific certificate
espClient.setCACert(ca_cert);
espClient.setCertificate(device_cert);
espClient.setPrivateKey(device_key);

// Connect with encryption
mqtt.setServer("mqtt.building.local", 8883);  // Port 8883 = MQTT over TLS
mqtt.connect("hvac-sensor-042");

Layer 5: Access Control (RBAC)

# MQTT ACL (Access Control List)
# User: hvac_sensors (read-only to settings, write-only to readings)
user hvac_sensors
topic read building/hvac/+/settings
topic write building/hvac/+/readings

# User: admin (full access)
user admin
topic readwrite #

# User: dashboard (read-only)
user dashboard
topic read building/#

# Result: Compromised sensor cannot:
# - Read other sensors' data (no read permission)
# - Control actuators (no write to /commands)
# - Access security systems (VLAN isolation + ACL)

Layer 6: Secure Boot (Firmware Integrity)

# ESP32 secure boot configuration (sdkconfig)
CONFIG_SECURE_BOOT_ENABLED=y
CONFIG_SECURE_BOOT_V2_ENABLED=y
CONFIG_SECURE_SIGNED_APPS_SCHEME="ECDSA"

# Boot chain verification:
# 1. ROM bootloader verifies Bootloader signature (RSA-3072)
# 2. Bootloader verifies App firmware signature (ECDSA-256)
# 3. If ANY signature fails → device refuses to boot

# Result: Attacker cannot install malicious firmware
# Even with physical access, modified firmware is rejected

Layer 7: Intrusion Detection (Anomaly Monitoring)

Suricata IDS rules for IoT traffic:

alert mqtt any any -> any 8883 (msg:"MQTT: Unusual topic pattern"; \
    content:"building"; pcre:"/\.\./"; sid:1000001;)

alert tcp $HVAC_VLAN any -> $CAMERA_VLAN any (msg:"HVAC to Camera: Unauthorized cross-VLAN"; \
    flags:S; sid:1000002;)

Behavioral anomaly detection (Python):

def detect_anomaly(sensor_id, value):
    historical_avg = db.get_avg(sensor_id, days=30)
    historical_std = db.get_std(sensor_id, days=30)

    if abs(value - historical_avg) > 3 * historical_std:
        alert(f"Sensor {sensor_id}: Value {value} is 3-sigma outlier")
        # Auto-quarantine: Move device to isolated VLAN
        firewall.move_to_quarantine_vlan(sensor_id)

Layer 8: Logging and Forensics

# Syslog to SIEM (Security Information Event Management)
import logging
import logging.handlers

syslog = logging.handlers.SysLogHandler(address=('siem.building.local', 514))
logger = logging.getLogger('iot_security')
logger.addHandler(syslog)

# Log ALL authentication attempts
logger.info(f"AUTH_SUCCESS: device={device_id} ip={client_ip} method=cert")
logger.warning(f"AUTH_FAIL: device={device_id} ip={client_ip} reason=invalid_cert")

# Log ALL access control decisions
logger.info(f"ACL_ALLOW: user={user} topic={topic} action={action}")
logger.warning(f"ACL_DENY: user={user} topic={topic} action={action}")

# Result: Full audit trail for forensics
# Can reconstruct attack timeline from logs

Attack Scenario: Compromised Temperature Sensor

Before Defense-in-Depth:

Attacker compromises HVAC sensor (default password)
→ Gains access to flat network
→ Scans for other devices (nmap)
→ Finds security cameras with default admin/admin
→ Views camera feeds, unlocks doors
→ Full building compromise in 20 minutes

After Defense-in-Depth:

Attacker compromises HVAC sensor (somehow bypassed cert auth)
→ Sensor isolated in VLAN 10
→ Cannot reach cameras (VLAN 40) due to firewall rules
→ Cannot read other sensors (ACL: write-only to own topic)
→ Cannot install malware (secure boot rejects unsigned firmware)
→ IDS detects anomalous traffic pattern
→ Auto-quarantine moves device to isolated VLAN
→ Logs capture full attack timeline for forensics
→ Attack contained: Only 1 sensor compromised, 499 others safe

Cost-Benefit Analysis:

Security Investment	Annual Cost	Breach Cost Prevented
Network segmentation (VLANs)	$2,000	$50,000 (data breach)
Certificate infrastructure	$5,000	$100,000 (ransomware)
IDS/SIEM deployment	$15,000	$200,000 (downtime)
Security training	$3,000	Priceless
Total Investment	$25,000	$350,000+ prevented

Key Lesson: Defense-in-depth doesn’t prevent all attacks, but it contains them. One compromised device no longer means total system compromise.

Decision Framework: Prioritizing Security Controls for IoT

Use this framework to determine which security controls to implement first based on your risk profile:

Priority	Control	When Required	Implementation Cost	Risk Reduction
P1: Critical	Encryption (TLS/DTLS)	Always	Low ($0-500)	High (60%)
P1: Critical	Authentication (certs or tokens)	Always	Low ($0-1k)	High (50%)
P1: Critical	Network segmentation (VLANs)	>50 devices	Medium ($1-5k)	High (40%)
P2: High	Access control (RBAC)	>10 users	Low ($500)	Medium (30%)
P2: High	Secure boot	Physical access possible	Low ($0, built-in)	High (70% for tampering)
P3: Medium	Intrusion detection	Compliance required	High ($5-20k)	Medium (20%)
P3: Medium	SIEM logging	>1,000 devices	High ($10-50k)	Low (10%, forensics)
P4: Low	Honeypots	Advanced threat intel	Medium ($2-10k)	Low (5%, detection)

Decision Tree:

Do you handle sensitive data (PII, health, financial)?
├─ YES → Implement P1+P2+P3 (full defense-in-depth)
└─ NO → Is physical access controlled?
    ├─ YES → Implement P1+P2 (encryption + auth + segmentation + RBAC)
    └─ NO → Implement P1+P2 + Secure Boot (prevent tampering)

Budget-Constrained Prioritization ($5k budget):

1. TLS/DTLS encryption ($500): Protects data in transit
2. Certificate-based auth ($1k): Unique credentials per device
3. Network segmentation ($2k): VLAN isolation with firewall rules
4. RBAC on MQTT broker ($500): Least-privilege access
5. Basic logging to syslog ($0): Forensic capability
6. Total: $4k, $1k buffer for contingency

Industry-Specific Requirements:

Industry	Mandatory Controls	Compliance Driver
Healthcare	P1+P2+P3 + Audit logs	HIPAA
Financial	P1+P2+P3 + MFA	PCI-DSS
Industrial	P1+P2 + Secure boot	IEC 62443
Smart Home	P1 (encryption + auth)	Consumer trust

Checklist:

• Encryption enabled (TLS 1.2+ or DTLS 1.2+)
• Authentication configured (certs preferred, tokens acceptable)
• Network segmented (critical devices isolated from others)
• Access control enforced (RBAC with least privilege)
• Logging enabled (authentication, access attempts, errors)
• Secure boot configured (if physical access possible)
• Monitoring alerts configured (failed auth, anomalies)

Common Mistake: Implementing Encryption Without Authentication

The Mistake: An IoT system encrypts all MQTT traffic with TLS but does not require client certificates or authentication tokens. Attackers perform man-in-the-middle (MITM) attacks by presenting their own TLS certificates, establishing encrypted channels to both the device and server, and decrypting/re-encrypting all traffic.

Why It Happens:

• Misunderstanding that “encryption = security”
• Skipping certificate configuration (perceived as “too complex”)
• Believing TLS alone prevents all attacks
• Not testing with attacker mindset (MITM scenarios)

Real-World Attack:

Device                     Attacker                     Server
   |                          |                            |
   |-- TLS Handshake -------->|                            |
   |<- Attacker's Cert -------|                            |
   |                          |                            |
   |== Encrypted Channel #1 ==|                            |
   |                          |                            |
   |                          |-- TLS Handshake ---------->|
   |                          |<-- Server's Cert ----------|
   |                          |                            |
   |                          |== Encrypted Channel #2 ====|
   |                          |                            |
Device thinks it's talking to server (encrypted!)
Server thinks it's talking to device (encrypted!)
Attacker reads/modifies ALL messages (decrypts #1, re-encrypts #2)

Why Device Doesn’t Detect MITM:

• Device does not validate the server certificate against a pinned CA → Accepts any certificate (including attacker’s self-signed cert)
• Device doesn’t verify the certificate’s Common Name or Subject Alternative Name → Accepts certs for any hostname
• No mutual authentication → Server doesn’t verify device identity either

The Fix: Mutual TLS (mTLS):

Server Configuration (MQTT Broker):

# mosquitto.conf - Require client certificates
listener 8883
cafile /etc/mosquitto/ca.crt        # CA that signed client certs
certfile /etc/mosquitto/server.crt  # Server cert
keyfile /etc/mosquitto/server.key   # Server key
require_certificate true            # ← CRITICAL
use_identity_as_username true       # Use cert CN as username

# Result: Server rejects clients without valid certs
# Server verifies client cert signed by trusted CA

Device Configuration (ESP32):

#include <WiFiClientSecure.h>

WiFiClientSecure client;

// Load certificates
client.setCACert(ca_cert);          // Verify server cert
client.setCertificate(client_cert);  // Present client cert
client.setPrivateKey(client_key);    // Client private key

// Connect with mutual TLS
client.connect("mqtt.example.com", 8883);

// Now BOTH sides authenticate:
// 1. Device verifies server cert (signed by CA, correct hostname)
// 2. Server verifies device cert (signed by CA, unique serial number)

MITM Attack Fails:

Device                     Attacker                     Server
   |                          |                            |
   |-- TLS Handshake -------->|                            |
   |<- Attacker's Cert -------|                            |
   |                          |                            |
Device checks: "Is this cert signed by MY trusted CA?"
→ NO (attacker's CA is different)
→ REJECT connection, log error
→ Attack FAILS

Even if attacker steals server's cert:
Server checks: "Does client have valid cert?"
→ NO (attacker doesn't have device's private key)
→ REJECT connection
→ Attack FAILS

Certificate Management:

# Generate CA (once, keep private key VERY secure)
openssl req -new -x509 -days 3650 -key ca.key -out ca.crt

# Generate device certificate (per device)
openssl req -new -key device-001.key -out device-001.csr
openssl x509 -req -in device-001.csr -CA ca.crt -CAkey ca.key \
    -CAcreateserial -out device-001.crt -days 3650

# Flash to device during manufacturing
# Store private key in secure element (TPM, ATECC608)

Validation Test:

# Test 1: Connect without client cert (should FAIL)
client = mqtt.Client()
client.tls_set(ca_certs="ca.crt")  # Only CA, no client cert
result = client.connect("mqtt.example.com", 8883)
assert result != 0, "Server accepted unauthenticated client!"

# Test 2: Connect with wrong CA (should FAIL)
client.tls_set(ca_certs="wrong_ca.crt", certfile="device.crt", keyfile="device.key")
result = client.connect("mqtt.example.com", 8883)
assert result != 0, "Device accepted server cert from wrong CA!"

# Test 3: Connect with valid mutual TLS (should SUCCEED)
client.tls_set(ca_certs="ca.crt", certfile="device.crt", keyfile="device.key")
result = client.connect("mqtt.example.com", 8883)
assert result == 0, "Valid mutual TLS connection failed!"

Checklist to Avoid This Mistake:

• TLS configured with require_certificate true on server
• Device configured with CA cert for server verification
• Device configured with client cert + private key
• Tested connection fails without client cert
• Tested connection fails with wrong CA
• Tested MITM attack scenario (fails with proper mTLS)
• Private keys stored in secure element (not flash memory)

Rule of Thumb: Encryption without authentication = locked door with no key check. Anyone can present a key (valid cert) and gain access. Always implement mutual authentication (mTLS or token-based) alongside encryption.

Putting Numbers to It: Cost-Benefit Analysis of Security Investments

Security investment ROI quantifies the expected annual loss (EAL) prevented by implementing security controls, enabling data-driven prioritization of defensive measures.

\[\text{ROI} = \frac{\text{EAL}_{\text{before}} - \text{EAL}_{\text{after}} - \text{Investment}}{\text{Investment}} \times 100\%\]

Working through an example:

Given: Smart factory with 500 IoT sensors (current state: flat network, default credentials, no encryption)

Step 1: Calculate Expected Annual Loss (Before) \[\text{EAL}_{\text{before}} = \sum_{i=1}^{n} P_i \times C_i\]

Where \(P_i\) = probability of attack scenario \(i\), \(C_i\) = cost if attack succeeds

\[\text{EAL}_{\text{before}} = (0.6 \times \$25{,}000) + (0.15 \times \$4{,}950{,}000) + (0.05 \times \$3{,}860{,}000)\] \[= \$15{,}000 + \$742{,}500 + \$193{,}000 = \$950{,}500 \text{ per year}\]

Step 2: Calculate Security Investment Cost \[\text{Investment} = \$162{,}500 \text{ (one-time)} + \$35{,}000 \text{ (annual maintenance)}\]

Step 3: Calculate Risk Reduction

After implementing unique credentials, network segmentation, firmware updates, and device isolation: \[\text{EAL}_{\text{after}} = (0.0 \times \$25{,}000) + (0.03 \times \$4{,}950{,}000) + (0.005 \times \$3{,}860{,}000)\] \[= \$0 + \$148{,}500 + \$19{,}300 = \$167{,}800 \text{ per year}\]

Step 4: Calculate ROI \[\text{Annual Savings} = \$950{,}500 - \$167{,}800 = \$782{,}700\] \[\text{ROI}_{\text{Year 1}} = \frac{\$782{,}700 - \$162{,}500}{\$162{,}500} \times 100\% = 382\%\] \[\text{Payback Period} = \frac{\$162{,}500}{\$782{,}700} = 0.21 \text{ years} = 76 \text{ days}\]

Result: For every $1 spent on basic security hygiene, the factory avoids $4.82 in expected losses. The investment pays for itself in 2.5 months.

In practice: Unlike traditional IT, IoT security ROI is often 300-500% because: 1. Attack probabilities are high (60% chance of botnet recruitment without rate limiting) 2. Breach costs are extreme (ransomware = days of downtime × thousands of devices) 3. Implementation costs are low (VLAN configuration = $0, unique credentials = $0.50/device)

The math demonstrates that not implementing basic security is economically irrational.

Try adjusting the parameters yourself:

viewof prob_botnet = Inputs.range([0, 1], {value: 0.6, step: 0.05, label: "Botnet probability"})
viewof cost_botnet = Inputs.range([0, 100000], {value: 25000, step: 1000, label: "Botnet cost ($)"})
viewof prob_ransom = Inputs.range([0, 1], {value: 0.15, step: 0.01, label: "Ransomware probability"})
viewof cost_ransom = Inputs.range([0, 10000000], {value: 4950000, step: 50000, label: "Ransomware cost ($)"})
viewof prob_breach = Inputs.range([0, 1], {value: 0.05, step: 0.01, label: "Data breach probability"})
viewof cost_breach = Inputs.range([0, 10000000], {value: 3860000, step: 50000, label: "Data breach cost ($)"})
viewof investment = Inputs.range([10000, 500000], {value: 162500, step: 5000, label: "Security investment ($)"})
viewof risk_reduction = Inputs.range([0.5, 0.99], {value: 0.80, step: 0.01, label: "Risk reduction factor"})

eal_before = prob_botnet * cost_botnet + prob_ransom * cost_ransom + prob_breach * cost_breach
eal_after = (prob_botnet * (1 - risk_reduction)) * cost_botnet + (prob_ransom * (1 - risk_reduction)) * cost_ransom + (prob_breach * (1 - risk_reduction)) * cost_breach
annual_savings = eal_before - eal_after
roi_pct = ((annual_savings - investment) / investment) * 100
payback_days = Math.round((investment / annual_savings) * 365)

html`<div style="background: var(--bs-light, #f8f9fa); padding: 1rem; border-radius: 8px; border-left: 4px solid #3498DB; margin-top: 0.5rem;">
<p><strong>Expected Annual Loss (before):</strong> $${eal_before.toLocaleString('en-US', {minimumFractionDigits: 0, maximumFractionDigits: 0})}</p>
<p><strong>Expected Annual Loss (after):</strong> $${eal_after.toLocaleString('en-US', {minimumFractionDigits: 0, maximumFractionDigits: 0})}</p>
<p><strong>Annual Savings:</strong> $${annual_savings.toLocaleString('en-US', {minimumFractionDigits: 0, maximumFractionDigits: 0})}</p>
<p><strong>Year 1 ROI:</strong> ${roi_pct.toFixed(0)}%</p>
<p><strong>Payback Period:</strong> ${payback_days > 0 ? payback_days + " days" : "N/A (savings do not exceed investment)"}</p>
<p style="margin-top: 0.5rem; font-size: 0.9em; color: #7F8C8D;"><em>Adjust the sliders above to model different threat scenarios and security budgets.</em></p>
</div>`

8.10 What’s Next

If you want to…	Read this
Understand defense-in-depth strategy	Defense in Depth
Learn about security monitoring and alerting	Security Monitoring
Study specific IoT security fundamentals	IoT Security Fundamentals
Explore hardware vulnerability methods	Hardware Vulnerabilities
Learn about OTA update security methods	Secure OTA Updates

8.11 See Also

Related Security Concepts:

• Security and Privacy Overview - Foundational security principles and threat models
• Threats and Vulnerabilities - Attack vectors these methods defend against
• Threat Modeling - Systematic risk identification process

Implementation Guides:

• Network Segmentation - Isolating IoT devices for defense in depth
• Intrusion Detection - Monitoring techniques for breach detection

Advanced Topics:

• Zero Trust Security - Never trust, always verify architecture
• Hardware Security - Physical device protection

---

← IoT Devices and Network Security

Defense in Depth Controls →

Common Pitfalls

1. Applying enterprise security tools directly to IoT devices

Enterprise endpoint security agents (antivirus, DLP, EDR) require gigabytes of RAM and a general-purpose OS — incompatible with MCU-based IoT devices. Adapt security methods to the device’s actual resources: hardware security modules, cryptographic co-processors, and firmware signing instead of software agents.

2. Prioritising perimeter security over device security

Focusing entirely on securing the network perimeter while leaving device firmware unsigned, credentials hardcoded, and debug interfaces exposed creates a situation where a single device compromise provides full access to the internal network.

3. Treating security as a deployment-time task

Security methods applied only at initial deployment without ongoing monitoring, patching, and auditing degrade rapidly. IoT deployments require continuous security operations throughout the device lifetime.

4. Not documenting the implemented security methods

An IoT security architecture that exists only in engineers’ heads cannot be audited, reproduced, or handed off. Document all implemented controls, their configurations, and the threats they address.

💻 Code Challenge