5  Security Architecture & Attacks

5.1 Learning Objectives

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

  • Map security architecture layers across IoT systems (device, network, cloud)
  • Identify and classify common IoT attack surfaces and vulnerabilities
  • Construct defense-in-depth strategies for production IoT deployments
  • Interpret attack trees to prioritize security countermeasures
  • Select layered security controls appropriate for each architectural level
In 60 Seconds

IoT security architecture translates threat models and security requirements into concrete system designs — specifying which security controls are applied at each layer (device, gateway, cloud, management) and how they integrate into a cohesive defence. The key architectural principle is that security must be designed in from the start: retrofitting security onto an insecure architecture is orders of magnitude more expensive than designing it correctly initially.

IoT security threats refer to 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.

“Before you build a house, you need a blueprint,” Max the Microcontroller explained. “Security architecture is the blueprint for protecting our entire IoT system. It shows three main layers: the device layer where I live, the network layer where messages travel, and the cloud layer where data gets stored and analyzed.”

Sammy the Sensor added, “Each layer has its own attack surface – that is a fancy term for all the places where a bad guy might try to break in. At the device layer, attackers might try to physically tamper with me or extract my firmware. At the network layer, they might eavesdrop on messages. At the cloud layer, they might try to hack the API.”

“An attack tree is a really cool way to think about this,” Lila the LED said. “It is like a family tree, but for attacks! At the top is the attacker’s goal – say, stealing sensor data. Then below that are all the different ways they could achieve it, branching out into specific steps. It helps defenders see ALL possible attack paths and block the most dangerous ones.”

“The security maturity model shows how to improve over time,” Bella the Battery explained. “Level 1 is basic – just passwords and firewalls. Level 2 adds monitoring and incident response. Level 3 has automated threat detection. Level 4 is the gold standard with continuous security testing and zero-trust architecture. You do not have to do everything at once, but you should always be climbing to the next level!”

5.2 Defense-in-Depth Layers

Five concentric security layers from outer to inner: perimeter firewall and network segmentation, authentication and access control, encryption and data protection, application security and input validation, and device-level security with secure boot
Figure 5.1: Defense-in-depth showing five security layers that attackers must breach sequentially - failure of one layer does not compromise the system
Try It: Defense-in-Depth Layer Explorer

Explore each security layer in a defense-in-depth architecture. Select a layer to see its controls, typical attacks it defends against, and what happens when that layer is breached.

5.3 IoT Attack Tree

Hierarchical attack tree with root goal compromise IoT system branching into four main attack vectors: physical access branch showing debug port exploitation and firmware extraction; network attack branch showing default credential exploitation and unencrypted traffic interception; software exploit branch showing buffer overflow and SQL injection paths; supply chain attack branch showing compromised components and backdoor insertion
Figure 5.2: IoT attack tree showing common vulnerability paths: physical access (debug ports, firmware extraction), network attacks (default credentials, unencrypted traffic), software exploits (buffer overflow, injection), and supply chain attacks

5.4 Security Maturity Model

Four-level security maturity progression: Level 1 Initial with insecure defaults and no encryption; Level 2 Basic with unique passwords and TLS encryption; Level 3 Managed with PKI infrastructure, secure boot, and automated updates; Level 4 Optimized with zero-trust architecture, hardware security modules, and continuous security testing
Figure 5.3: Security maturity progression from initial (insecure defaults) through basic (unique passwords, encryption) to managed (PKI, secure boot) and optimized (zero-trust, hardware security modules)

5.5 Interactive Security Quiz

Test your understanding of security and privacy concepts with instant feedback.

IoT Security Fundamentals Quiz

\({q1_feedback}\){q2_feedback} \({q3_feedback}\){q4_feedback}

5.6 Knowledge Check

Test your understanding of security and privacy concepts.

5.7 The CIA Triad

⏱️ ~10 min | ⭐ Foundational | 📋 P11.C01.U03

Key Concepts

  • Security reference architecture: A reusable architectural template for a class of IoT systems specifying security controls, protocols, and integration patterns validated against a defined threat model.
  • Layered security model: An architecture where independent security controls are applied at the physical, network, transport, application, and management layers, each providing protection against specific attack categories.
  • Trust boundary: A boundary in the system architecture where data crosses from one security domain to another, requiring explicit security controls (authentication, authorisation, encryption, validation) at the crossing point.
  • Security control placement: The decision of where in the architecture to apply each security control, balancing effectiveness (close to the threat), performance impact, and resource constraints.
  • Residual risk: The risk that remains after all chosen security controls are implemented — accepted by the system owner as the cost of the remaining gap between perfect security and what is practically achievable.

The foundational security principles are Confidentiality, Integrity, and Availability (CIA):

Three interconnected pillars of the CIA triad: Confidentiality with lock icon ensuring only authorized access to data; Integrity with checkmark icon ensuring data accuracy and preventing tampering; Availability with uptime icon ensuring systems remain accessible when needed
Figure 5.4: CIA Triad diagram showing three security pillars

5.7.1 Confidentiality

Definition: Ensuring information is accessible only to authorized parties.

IoT Examples:

  • Smart home camera footage should not be publicly accessible
  • Health data from wearables remains private
  • Industrial sensor data protected from competitors

Threats:

  • Eavesdropping on unencrypted Wi-Fi/Bluetooth
  • Man-in-the-middle attacks
  • Data breaches

Countermeasures:

// Example: AES-128 encryption for sensor data
#include <AES.h>

AES aes;
byte key[] = {0x2b, 0x7e, 0x15, 0x16, /* ... 16 bytes ... */};
byte plaintext[] = "Temperature: 22.5";
byte ciphertext[16];

void setup() {
  aes.set_key(key, 128);
  aes.encrypt(plaintext, ciphertext);
  // Transmit ciphertext instead of plaintext
}

5.7.2 Integrity

Definition: Ensuring information has not been altered or tampered with.

IoT Examples:

  • Firmware updates are authentic and unmodified
  • Sensor readings haven’t been manipulated
  • Command messages from authorized source

Threats:

  • Firmware injection
  • Data tampering
  • Replay attacks

Countermeasures:

// Example: HMAC for message integrity
#include <SHA256.h>

byte message[] = "temperature=22.5";
byte secret[] = "shared_secret_key";
byte hmac[32];

void verifyIntegrity() {
  SHA256 sha256;
  sha256.resetHMAC(secret, sizeof(secret));
  sha256.update(message, sizeof(message));
  sha256.finalizeHMAC(secret, sizeof(secret), hmac, sizeof(hmac));

  // Compare received HMAC with calculated HMAC
  // If match → integrity verified
}

5.7.3 Availability

Definition: Ensuring systems and data are accessible when needed.

IoT Examples:

  • Smart locks always respond to unlock commands
  • Medical devices remain operational
  • Industrial sensors provide continuous monitoring

Threats:

  • DDoS attacks (Mirai botnet)
  • Physical destruction
  • Power/battery depletion attacks

Countermeasures:

// Example: Rate limiting to prevent DoS
unsigned long lastRequest = 0;
const int MIN_REQUEST_INTERVAL = 1000;  // 1 second

void handleRequest() {
  if (millis() - lastRequest < MIN_REQUEST_INTERVAL) {
    // Reject: Too many requests
    return;
  }

  lastRequest = millis();
  // Process legitimate request
}
Try It: CIA Triad Scenario Classifier

Describe an IoT security incident and classify which CIA property (Confidentiality, Integrity, or Availability) is primarily violated. Select a scenario or build your own to test your understanding.

5.8 Videos

Understanding security concepts through real-world examples and emerging technologies provides crucial context for IoT security implementation.

Case study examining how data collection and analysis can compromise user privacy, with lessons applicable to IoT data practices and consent management.

Explore how blockchain technology provides decentralized security and trust mechanisms for IoT networks, including device authentication and data integrity.

Core Cybersecurity Concepts for IoT
Cybersecurity Basics for IoT
From slides — foundational security concepts contextualized for IoT systems.
Threats, Privacy, and Risk
Threats, Privacy, and Risk in IoT
From slides — overview of privacy threats, risk trade-offs, and mitigations.

5.8.1 Extended Security Properties for IoT

Beyond CIA, IoT systems require:

Property Description IoT Example
Authentication Verify identity of users/devices Device certificates, 2FA
Authorization Control what authenticated entities can do Role-based access control
Non-repudiation Prevent denial of actions Digital signatures, audit logs
Accountability Track who did what and when Logging, blockchain ledgers
Privacy Protect personal information Data anonymization, consent
Try It: Security Properties Maturity Assessment

Evaluate your IoT system’s maturity across all security properties. Rate each property to get a visual maturity profile and prioritized recommendations for improvement.

5.9 IoT Security Architecture Layers

⏱️ ~12 min | ⭐⭐ Intermediate | 📋 P11.C01.U04

IoT security must be addressed at every layer:

Three-tier security architecture pyramid with Device Layer at base showing physical security and secure boot, Network Layer in middle showing encrypted communications and authentication, and Cloud/Application Layer at top showing API security and access control
Figure 5.5: Three-layer IoT security architecture showing Layer 3 Cloud/Application (cloud platforms, databases, web dashboards) with security controls for API authentication, input validation, and data encryption; Layer 2 Network/Communication (Wi-Fi, Bluetooth, Cellular, LoRa) with TLS/DTLS encryption and network segmentation; Layer 1 Device/Perception (sensors, actuators, embedded devices) with secure boot, tamper detection, and hardware root of trust

5.9.1 Layer 1: Perception/Device Layer

Components: Sensors, actuators, embedded devices

Security Concerns:

  • Physical tampering and theft
  • Side-channel attacks (power analysis)
  • Lack of secure boot
  • Debug ports left enabled

Countermeasures:

// Secure boot verification
#include <esp_secure_boot.h>

void setup() {
  if (esp_secure_boot_enabled()) {
    Serial.println("Secure boot ENABLED");
    // Firmware signature verified before execution
  } else {
    Serial.println("WARNING: Secure boot DISABLED");
  }
}

// Hardware root of trust
#include <esp_efuse.h>

void checkDeviceKey() {
  uint8_t mac[6];
  esp_efuse_mac_get_default(mac);
  // Use hardware-unique MAC as device identity
}

5.9.2 Layer 2: Network/Communication Layer

Components: Wi-Fi, Bluetooth, Cellular, LoRa, Zigbee

Security Concerns:

  • Unencrypted communications
  • Weak authentication protocols
  • Man-in-the-middle attacks
  • Replay attacks

Countermeasures:

// TLS/SSL for MQTT over Wi-Fi
#include <WiFiClientSecure.h>
#include <PubSubClient.h>

WiFiClientSecure espClient;
PubSubClient client(espClient);

// Load CA certificate
const char* ca_cert = \
"-----BEGIN CERTIFICATE-----\n" \
"MIIDrzCCApegAwIBAgIQCDvgVpBCRrGhdWrJWZHHSjANBgkqhkiG9...\n" \
"-----END CERTIFICATE-----\n";

void setup() {
  espClient.setCACert(ca_cert);  // Verify server identity
  client.setServer("mqtt.example.com", 8883);  // Port 8883 = MQTT over TLS
}

5.9.3 Layer 3: Cloud/Application Layer

Components: Cloud platforms, databases, web dashboards

Security Concerns:

  • Weak API authentication
  • SQL injection, XSS attacks
  • Insecure data storage
  • Inadequate access controls

Countermeasures:

# Secure API with JWT authentication
from flask import Flask, request, jsonify
import jwt
import datetime

app = Flask(__name__)
SECRET_KEY = "your-secret-key"

@app.route('/api/sensor-data', methods=['POST'])
def receive_data():
    # Verify JWT token
    token = request.headers.get('Authorization')

    try:
        payload = jwt.decode(token, SECRET_KEY, algorithms=['HS256'])
        device_id = payload['device_id']

        # Validate and store data
        data = request.json
        # ... sanitize inputs, prevent injection ...

        return jsonify({"status": "success"}), 200

    except jwt.InvalidTokenError:
        return jsonify({"error": "Invalid token"}), 401
Try It: Security Layer Attack Simulator

Simulate attacks against each IoT architecture layer and observe how security controls respond. Adjust the attacker skill level and see which controls hold and which may fail.

5.10 Common IoT Attack Surfaces

⏱️ ~15 min | ⭐⭐ Intermediate | 📋 P11.C01.U05

5.10.1 Device Firmware and Software

Radial attack surface diagram with IoT System at center and five branches showing Firmware/Software vulnerabilities including hardcoded credentials and buffer overflows, Network Communication threats like unencrypted protocols, Web/Mobile Application risks including exposed APIs, Cloud Infrastructure weaknesses such as misconfigured S3 buckets, and Supply Chain threats including compromised components
Figure 5.6: IoT attack surfaces diagram showing five main attack vectors: 1) Firmware/Software with hardcoded credentials, buffer overflows, outdated libraries, and unsigned firmware; 2) Network Communication with unencrypted protocols, weak Wi-Fi passwords, and missing certificate validation; 3) Web/Mobile Applications with weak password policies, no rate limiting, exposed APIs, and XSS vulnerabilities; 4) Cloud Infrastructure with misconfigured storage buckets, weak database credentials, no encryption at rest, and inadequate logging; 5) Supply Chain with compromised components, fake devices, chip backdoors, and untrusted third-party libraries

Vulnerabilities:

  • Hardcoded credentials
  • Buffer overflows
  • Outdated libraries
  • No code signing

Example:

// VULNERABLE CODE - Buffer overflow
char username[32];
strcpy(username, user_input);  // No bounds checking!

// SECURE CODE
strncpy(username, user_input, sizeof(username) - 1);
username[sizeof(username) - 1] = '\0';

5.10.2 Network Communication

Vulnerabilities:

  • Unencrypted protocols (HTTP, MQTT without TLS)
  • Weak Wi-Fi passwords (WEP, short WPA2)
  • No certificate validation

Attack Example: Man-in-the-Middle

Device ──[plain text]──> Attacker ──[plain text]──> Cloud
         "temp=22.5"     [intercept]     "temp=99.9" (modified!)

Defense:

// Always use encrypted protocols
// ❌ BAD: http://api.server.com/data
// ✅ GOOD: https://api.server.com/data

// ❌ BAD: mqtt://broker:1883
// ✅ GOOD: mqtts://broker:8883 with certificate validation

5.10.3 Web/Mobile Applications

Vulnerabilities:

  • Weak password policies
  • No rate limiting
  • Exposed APIs without authentication
  • Cross-site scripting (XSS)

Example: Insecure Direct Object Reference

GET /api/camera/feed?deviceId=12345
// Attacker changes: deviceId=12346 → Access someone else's camera!

// Fix: Verify ownership
if (deviceOwner != currentUser) {
    return 403 Forbidden;
}

5.10.4 Cloud Infrastructure

Vulnerabilities:

  • Misconfigured S3 buckets (public access)
  • Weak database credentials
  • No encryption at rest
  • Inadequate logging

5.10.5 Supply Chain

Vulnerabilities:

  • Compromised components
  • Fake devices
  • Backdoors in chips/firmware
  • Untrusted third-party libraries

5.11 Interactive DREAD Calculator

Use this calculator to assess the risk level of different attack vectors in your IoT system.

DREAD Risk Assessment 

${dreadScore.toFixed(1)}
${dreadLevel}
<strong>Interpretation:</strong>
<ul style="margin: 10px 0 0 0; padding-left: 20px;">
  <li><strong>CRITICAL (8.0-10.0):</strong> Immediate action required. High business impact, easily exploitable.</li>
  <li><strong>HIGH (6.0-7.9):</strong> Prioritize mitigation. Significant risk to operations or data.</li>
  <li><strong>MEDIUM (4.0-5.9):</strong> Plan mitigation. Moderate risk, should be addressed in roadmap.</li>
  <li><strong>LOW (0-3.9):</strong> Monitor and review. Low immediate risk, periodic reassessment needed.</li>
</ul>

5.12 Worked Example: Attack Surface Assessment of a Connected Vehicle Fleet

Scenario: An automotive OEM manages 15,000 connected vehicles with these IoT components per vehicle: telematics control unit (TCU), OBD-II diagnostic port, infotainment system with Wi-Fi/Bluetooth, cellular modem (4G LTE), 6 CAN bus ECUs, GPS module, and a companion mobile app. Assess the attack surface and prioritize defenses.

Step 1: Attack Surface Enumeration

Attack Surface Entry Points Impact if Compromised Accessibility
Cellular modem Remote (internet-facing API) Fleet-wide: OTA commands, location tracking Remote, scalable
OBD-II port Physical (diagnostic connector) Single vehicle: CAN bus injection, ECU reprogramming Physical access required
Infotainment Wi-Fi Proximity (50m range) Vehicle: pivot to CAN bus via gateway Must be near vehicle
Bluetooth Proximity (10m range) Infotainment: phone data, audio injection Must be very near
Companion app Remote (app store) User account: location history, remote start Remote via phishing
CAN bus Internal (no auth) Safety-critical: steering, brakes, throttle Requires gateway breach
GPS module Remote (RF spoofing) Navigation: misdirection, fleet confusion Requires RF transmitter

Step 2: Risk Scoring (DREAD)

Cellular modem attack (remote fleet compromise):
  Damage: 9 (fleet-wide command injection)
  Reproducibility: 8 (once found, reusable across fleet)
  Exploitability: 6 (requires API vulnerability)
  Affected Users: 10 (all 15,000 vehicles)
  Discoverability: 5 (requires reverse engineering)
  DREAD Score: (9+8+6+10+5)/5 = 7.6 CRITICAL

OBD-II physical attack:
  Damage: 8 (full CAN bus access)
  Reproducibility: 9 (standard protocol)
  Exploitability: 7 (off-the-shelf tools)
  Affected Users: 1 (single vehicle)
  Discoverability: 9 (well-documented)
  DREAD Score: (8+9+7+1+9)/5 = 6.8 HIGH

Infotainment Wi-Fi attack:
  Damage: 6 (depends on gateway isolation)
  Reproducibility: 7 (common Wi-Fi exploits)
  Exploitability: 5 (need proximity + specific exploit)
  Affected Users: 1 (single vehicle)
  Discoverability: 6 (requires scanning)
  DREAD Score: (6+7+5+1+6)/5 = 5.0 MEDIUM

Step 3: Defense Prioritization by Cost-Effectiveness

Defense Addresses Cost/Vehicle Risk Reduction Priority
API gateway hardening + mTLS Cellular (7.6) $2.50 (certificate) -3.0 DREAD 1st (highest ROI)
CAN bus gateway firewall CAN injection (via any entry) $8.00 (hardware) -2.5 DREAD 2nd
OBD-II port authentication Physical access (6.8) $1.50 (secure connector) -2.0 DREAD 3rd
Infotainment isolation Wi-Fi/BT pivot (5.0) $3.00 (dual-MCU design) -1.5 DREAD 4th
GPS signal validation Spoofing (4.2) $0.50 (software) -1.0 DREAD 5th

Step 4: Fleet-Wide Security Budget

15,000 vehicles x $15.50/vehicle = $232,500 total
  API hardening: $37,500 (protects entire fleet from remote attack)
  CAN firewall: $120,000 (prevents safety-critical compromise)
  OBD-II auth: $22,500 (deters opportunistic physical attacks)
  Infotainment isolation: $45,000 (limits lateral movement)
  GPS validation: $7,500 (prevents navigation spoofing)

Compare to breach cost:
  Jeep Cherokee recall (2015): $105 million for 1.4 million vehicles
  Per-vehicle recall cost: $75/vehicle
  Security investment: $15.50/vehicle = 5x cheaper than one recall

Result: A $232,500 investment ($15.50/vehicle) across five defense layers reduces the fleet’s aggregate DREAD score from 30.6 to 20.6, with the cellular API hardening providing the highest ROI by protecting all 15,000 vehicles from remote attacks for just $2.50 each.

Key lesson: Attack surface assessment must weight both impact and scalability. The OBD-II port has a higher per-vehicle DREAD score than the companion app, but the companion app affects all 15,000 users remotely while OBD-II requires physical presence at each vehicle. Prioritize defenses against remote, fleet-wide attack surfaces first.

Annualized Loss Expectancy for attack surface risk

\[\text{ALE} = \text{SLE} \times \text{ARO}\]

Where SLE = Single Loss Expectancy, ARO = Annual Rate of Occurrence

Working through an example:

Given: Connected vehicle fleet with 7 attack surfaces from case study

Step 1: Calculate risk for cellular modem attack DREAD Score = 7.6 (from case study) \(\text{SLE} = \$2,000,000\) (fleet-wide OTA compromise impact) \(\text{ARO} = 0.10\) (10% probability per year, remote exploit) \(\text{ALE}_{\text{cellular}} = 2,000,000 \times 0.10 = \$200,000\text{ per year}\)

Step 2: Calculate risk for OBD-II attack DREAD Score = 6.8 \(\text{SLE} = \$50,000\) (single vehicle compromise + investigation) \(\text{ARO} = 0.02\) (2% probability, requires physical access) \(\text{ALE}_{\text{OBD}} = 50,000 \times 0.02 = \$1,000\text{ per year}\)

Step 3: Defense cost-benefit for cellular hardening Defense cost: \(\$2.50\text{ per vehicle} \times 15,000 = \$37,500\) one-time Risk reduction: \(\text{ARO } 0.10 \rightarrow 0.01\) (90% reduction) \(\text{ALE after} = 2,000,000 \times 0.01 = \$20,000\) \(\text{Annual savings} = 200,000 - 20,000 = \$180,000\) \(\text{Payback period} = \frac{37,500}{180,000} = 0.21\text{ years} = 2.5\text{ months}\)

Result: Cellular API hardening has 2.5-month payback, while OBD-II auth ($22,500 cost) would take 22.5 years to break even. Prioritize defenses by ALE reduction per dollar, not DREAD score alone.

In practice: Security budgets are finite. Quantifying risk with ALE enables rational prioritization. High DREAD scores don’t justify spending if ARO is low (physical attacks). Focus on remote, scalable attack vectors with high ARO first.

5.13 Concept Relationships

How Security Architecture Concepts Connect
Architectural Layer Security Controls Attack Surface Defense Strategy
Device/Perception Secure boot, tamper detection Physical access, JTAG Hardware root of trust
Network/Communication TLS/DTLS, network segmentation Eavesdropping, MITM Encryption + isolation
Cloud/Application Authentication, input validation API vulnerabilities Defense-in-depth
Attack Surface Minimization, principle of least privilege All exposed interfaces Disable unnecessary services
Maturity Progression Initial → Basic → Managed → Optimized Varies by maturity level Continuous improvement

Layered Defense Principle: Attackers must breach multiple independent layers. Compromising one layer (e.g., network encryption) does not compromise others (e.g., application authentication, device secure boot).

5.14 See Also

Related Security Topics:

Architecture Standards:

  • NIST Cybersecurity Framework: Identify, Protect, Detect, Respond, Recover
  • IEC 62443: Industrial automation and control systems security
  • Cloud Security Alliance IoT Security Framework

Implementation Resources:

  • AWS IoT Security Best Practices
  • Azure IoT reference architecture security guidance
  • Google Cloud IoT Core security overview

5.15 What’s Next

Continue your security learning journey:

Security Foundations Security Frameworks

Common Pitfalls

A security architecture not grounded in a specific threat model makes arbitrary control choices that may protect against low-risk threats while missing high-risk ones. Always begin with threat modelling before designing controls.

Reference architectures are designed for typical scenarios. If your deployment has unusual physical accessibility, regulatory requirements, or attacker capabilities, validate that the reference architecture adequately addresses your specific threats.

Security architecture decisions made without documentation cannot be reviewed, reproduced, or handed off. Document each security control, why it was chosen, what threat it addresses, and what risk remains if it is bypassed.

IoT system architectures evolve over time as new devices are added, integrations are built, and threats change. Schedule periodic architecture reviews (annually at minimum) to ensure the architecture continues to match the current threat model.