40 IoT Security Visual Resources
Learning Objectives
After reviewing this visual resource gallery, you will be able to:
- Classify key components of encryption architectures including symmetric, asymmetric, and multi-layer approaches
- Analyze common IoT attack patterns including botnet architectures, man-in-the-middle, and side-channel attacks
- Calculate residual breach probability across layered defense-in-depth security architectures
- Map security concepts across device, network, and cloud layers by interpreting trust boundary diagrams
For Beginners: IoT Security Visual Resources
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 Security Picture Book!
“A picture is worth a thousand words!” Lila the LED said, lighting up her brightest display. “Sometimes security concepts are hard to understand just from reading about them. That is why this chapter is full of diagrams and pictures that show how attacks and defenses actually work.”
Sammy the Sensor pointed to an encryption diagram. “Look at this one! It shows how a message gets scrambled into secret code. On one side you have the plain message, then it goes through the encryption machine, and out comes gibberish that only the right key can decode. Seeing it drawn out makes it so much easier to understand than just reading about it!”
“My favorite diagrams are the ones showing attack scenarios,” Max the Microcontroller admitted. “They show step by step how a hacker might try to break in – first they scan for open ports, then they try default passwords, then they move sideways through the network. When you can SEE the attack path, you can figure out where to put your defenses to block it.”
“Think of these visuals like a map of a maze,” Bella the Battery suggested. “The attacker is trying to find a path through to the treasure, and the diagrams help you see all the possible routes so you can put walls and locks in the right places. Explore these pictures and you will understand security concepts much faster!”
Key Concepts
- Attack tree: A visual representation of an attacker’s goals and the alternative paths to achieve them, arranged in a tree structure with the root as the attacker’s ultimate objective and leaves as individual exploitable conditions.
- Kill chain diagram: A visual model of the sequential stages of a cyberattack (reconnaissance, weaponisation, delivery, exploitation, installation, C2, actions on objective), used to identify defensive opportunities at each stage.
- Threat model diagram: A visual representation of an IoT system showing data flows, trust boundaries, and identified threats at each boundary, typically using the STRIDE framework categories.
- Security architecture diagram: A diagram showing the security controls applied at each tier of an IoT architecture (device, gateway, cloud, management) and how they collectively address identified threats.
- Risk heat map: A matrix visualising security risks by their likelihood and impact, prioritising which risks require immediate mitigation versus acceptance or monitoring.
40.1 Introduction
Security diagrams serve a dual purpose: they communicate architecture to stakeholders and they expose implicit trust assumptions to threat modelers. This chapter collects visual resources covering encryption mechanisms, attack scenarios, protocol security, access control, and hardware vulnerabilities across IoT systems. Each diagram section includes context on when and why that visual pattern matters for IoT security analysis.
Putting Numbers to It
Defense-in-depth diagrams become actionable when translated into residual breach probability:
\[ P_{\text{breach}} = \prod_{i=1}^{n} p_i \]
where \(p_i\) is the probability an attacker bypasses layer \(i\). This assumes layers are independent – a simplifying assumption, since in practice an attacker who bypasses one layer may gain information that helps with subsequent layers.
Worked example: Suppose the bypass probabilities for perimeter filtering, segmentation, authentication, and payload protection are \(0.20\), \(0.15\), \(0.10\), and \(0.05\).
\[ P_{\text{breach}} = 0.20 \times 0.15 \times 0.10 \times 0.05 = 0.00015 \]
That is 0.015% residual probability for full compromise. A single-layer design at 20% bypass risk is over 1,300x weaker (\(0.20 / 0.00015\)). This is the quantitative value of layered security visualized in this chapter.
40.2 Encryption and Cryptography
Asymmetric Encryption
Asymmetric encryption uses mathematically related key pairs to enable secure communication without shared secrets, essential for IoT device provisioning and authentication.
Encryption Levels for IoT
IoT systems implement encryption at multiple levels, from local device communication to cloud connectivity, each with different security and performance characteristics.
AES Encryption Process
The AES encryption process transforms data through multiple rounds of confusion and diffusion operations. Each round applies substitution (SubBytes), transposition (ShiftRows), mixing (MixColumns), and key addition (AddRoundKey) to create ciphertext that is computationally infeasible to reverse without the correct key. AES-128 uses 10 rounds, AES-192 uses 12 rounds, and AES-256 uses 14 rounds.
Multi-Layer Encryption Architecture
Defense-in-depth encryption applies protection at multiple OSI layers. Even if one encryption layer is compromised, other layers continue protecting data integrity and confidentiality. This approach is especially important for IoT systems where data traverses untrusted network segments between constrained devices and cloud endpoints.
40.3 Attack Scenarios
IoT Attack Scenarios
Understanding attack scenarios helps security teams anticipate threats and implement appropriate countermeasures. These diagrams trace the complete attack lifecycle from initial reconnaissance through exploitation, lateral movement, and data exfiltration.
Attack Tree Analysis
Attack trees provide a structured methodology for analyzing IoT security threats. By decomposing complex attacks into hierarchical sub-goals, security teams can identify critical paths and prioritize countermeasures based on cost, likelihood, and impact.
Man-in-the-Middle Attack
Man-in-the-Middle attacks exploit the trust relationship between IoT devices and their backend services. Without proper mutual authentication and encrypted channels, attackers can intercept sensor data, inject malicious commands, and compromise entire IoT deployments.
Botnet Architecture
The Mirai botnet demonstrated the catastrophic potential of unsecured IoT devices. By exploiting default credentials on cameras, routers, and DVRs, attackers assembled an army of over 600,000 compromised devices capable of generating attack traffic exceeding 1 Tbps in the October 2016 Dyn DNS attack.
DDoS Attack Visualization
Distributed Denial of Service attacks leverage the collective bandwidth of thousands of compromised IoT devices to overwhelm target infrastructure. The volumetric nature of these attacks makes them particularly difficult to mitigate without upstream filtering or content delivery network protection.
40.4 Security Architecture
Network Segmentation Architecture
Network micro-segmentation isolates IoT devices into security zones, limiting lateral movement when a device is compromised. Each zone has dedicated firewall rules controlling inter-zone traffic based on the principle of least privilege.
PKI Infrastructure for IoT
PKI infrastructure provides certificate-based device authentication through a trust hierarchy from Root Certificate Authority through Intermediate CAs to individual device certificates, enabling scalable identity management across large IoT deployments.
Device Security Bootstrap
Device security bootstrap establishes hardware-based trust during provisioning, chaining verification from the hardware root of trust through firmware integrity checks to secure key provisioning.
Secure IoT Framework
Compliance frameworks such as NIST SP 800-183, ISO 27001, and IEC 62443 provide structured security requirements for IoT deployments, mapping regulatory obligations to specific technical controls.
40.5 Protocol Security
DTLS Handshake
DTLS (Datagram Transport Layer Security) provides TLS-equivalent security for UDP-based protocols, essential for constrained IoT devices using CoAP. The handshake includes a cookie exchange to prevent denial-of-service amplification, followed by certificate verification and key establishment.
MQTT Security
MQTT security combines transport encryption (TLS), authentication (username/password or client certificates), and topic-based authorization (ACLs) for pub/sub messaging in IoT systems.
CoAP Security
CoAP provides REST-like security for resource-constrained IoT devices with DTLS protection. It supports both pre-shared key (PSK) and certificate-based authentication modes, with resource-level access control.
40.6 Data Protection
Data Lifecycle Security
IoT data requires protection throughout its lifecycle – from collection at the sensor through transmission, storage, processing, and eventual disposal. Each phase has distinct security requirements and attack surfaces.
Differential Privacy
Differential privacy enables IoT analytics while protecting individual data points by injecting calibrated noise. The privacy guarantee ensures that including or excluding any single record changes query results by at most a bounded amount (\(\epsilon\)).
Homomorphic Encryption
Homomorphic encryption allows computation on encrypted IoT data in untrusted cloud environments. The cloud processes ciphertexts and returns encrypted results that only the data owner can decrypt, eliminating the need to trust the cloud provider with plaintext data.
40.7 Access Control
Access Control Matrix
Access control matrices provide a foundational model for managing IoT device permissions by mapping subjects (users, devices, services) to objects (resources, endpoints, data) with explicit permission assignments.
Authentication Flow
IoT authentication flows must balance security strength with the computational constraints of resource-limited devices. Lightweight token-based approaches reduce per-request overhead while maintaining session integrity.
OAuth 2.0 Authentication Flow
OAuth 2.0 provides delegated authorization for IoT applications, allowing devices to access cloud resources on behalf of users without handling user credentials directly. The Device Authorization Grant (RFC 8628) is specifically designed for input-constrained IoT devices.
40.8 Hardware Security
Combinational Hardware Trojan
Hardware trojans can be inserted during manufacturing to enable backdoor access when specific conditions are met. Combinational trojans activate based on rare input combinations, making them difficult to detect through standard testing because the trigger condition may never occur during verification.
Differential Power Analysis
Differential Power Analysis (DPA) attacks extract cryptographic secrets by statistically correlating power consumption traces with data-dependent operations inside a chip. Collecting thousands of power traces during encryption operations allows attackers to recover secret keys without any knowledge of the algorithm internals.
HSM Integration
Hardware Security Modules (HSMs) provide tamper-resistant key storage and cryptographic operations for high-security IoT deployments. Keys never leave the HSM boundary, protecting them from software-based extraction attacks.
40.9 Concept Relationships
How Security Visual Concepts Connect
| Visual Category | Maps To Security Property | Reveals Attack Surface | Informs Defense Strategy |
|---|---|---|---|
| Encryption Diagrams | Confidentiality | Data in transit, at rest | TLS/AES implementation decisions |
| Attack Trees | Multiple (CIA + auth) | All possible attack paths | Defense prioritization by likelihood |
| Network Segmentation | Isolation, least privilege | Inter-VLAN communication paths | Firewall rule design |
| Defense-in-Depth | All CIA properties | Layer boundaries | Redundant control placement |
| Authentication Flows | Authentication, non-repudiation | Token/session management | OAuth/JWT implementation |
Critical Insight: Visual security diagrams are tools for threat modeling, not just documentation. They expose implicit assumptions about trust boundaries and reveal attack paths that text descriptions miss.
Common Mistake: Assuming Encryption Diagrams Show Complete Security
The Mistake: Teams look at encryption architecture diagrams showing “TLS” or “AES-256” and conclude the system is secure, without verifying implementation details like key management, certificate validation, or cipher suite selection.
Why Diagrams Can Be Misleading: A diagram showing “Sensor –[TLS]–> Cloud” tells you NOTHING about:
- Is certificate validation enabled? (Many IoT libraries default to disabled)
- Which TLS version? (TLS 1.0 and 1.1 are deprecated per RFC 8996; TLS 1.2+ is required)
- Which cipher suites? (RC4, DES, and 3DES are broken)
- How are keys managed? (Hardcoded keys = broken)
- Is certificate pinning used? (Prevents MITM with rogue CAs)
Real-World Failure Example:
Company: Smart camera manufacturer
Diagram Claim: "End-to-end AES-256 encryption from camera to mobile app"
Actual Implementation (discovered in security audit):
1. Camera generates AES-256 key on first boot
2. Key stored in plaintext in /etc/camera/config.txt
3. Camera sends key to mobile app over HTTP (unencrypted) during pairing
4. Attacker on same Wi-Fi intercepts key
5. All video streams decryptable by attacker
Result: "End-to-end encryption" was technically true (AES-256 used),
but implementation was completely broken. Diagram showed encryption,
audit revealed it was security theater.What to Verify Beyond the Diagram:
| Diagram Shows | Must Verify in Implementation |
|---|---|
| “TLS encryption” | TLS 1.2+ only? Certificate validation enabled? Proper cipher suites? |
| “AES-256 encryption” | Where are keys stored? How are they generated (RNG quality)? Key rotation schedule? |
| “End-to-end encryption” | Is key exchange authenticated? Is it actually E2EE or just client-server TLS? |
| “Secure communication” | What protocol? What mode (ECB is broken)? Authentication tag verified? |
Correct Approach:
- Treat diagrams as architecture intent, not implementation proof
- Require implementation details: Key lengths, modes, storage, rotation
- Demand code review or pentest: Verify crypto actually works as claimed
- Check for common anti-patterns:
- Hardcoded keys in firmware
verify=FalseorInsecureRequestWarningignored- ECB mode (patterns leak information)
- Null cipher suites accepted
Key Lesson: A beautiful encryption diagram with “AES-256” and “TLS 1.3” labels can represent anything from excellent security to complete snake oil. Always verify the implementation matches the architecture, especially for IoT where developers often disable security features during development and forget to re-enable them for production.
Decision Framework: Choosing Encryption Architecture for IoT Systems
| Criterion | Link-Layer (802.15.4 AES) | Network-Layer (IPsec) | Transport-Layer (TLS/DTLS) | Application-Layer (AES-GCM) | End-to-End (E2EE) |
|---|---|---|---|---|---|
| Overhead | Low (16-byte MIC per frame) | High (ESP header + auth) | Medium (TLS record + MAC) | Low (16-byte GCM tag) | Low (app-specific) |
| Latency | Minimal (<1ms) | High (key exchange 100ms+) | Medium (handshake 50-200ms) | Minimal | Minimal |
| Complexity | Low (hardware-accelerated) | Very High (kernel-level) | Medium (libraries available) | Low | High (custom) |
| Interoperability | Protocol-specific (Zigbee, Thread) | Any IP protocol | Any TCP/UDP | Application-defined | Application-defined |
| Protection Scope | Single wireless hop | All network hops | Device to server | App data only | User to user |
| Best For | Zigbee/Thread mesh networks | VPNs, site-to-site tunnels | Cloud APIs, HTTPS | Sensor data payloads | Messaging, health data |
Decision Tree:
- Is data human-readable (PHI, PII, credentials)?
- YES: Require Transport-Layer (TLS) or End-to-End minimum
- NO: Continue to step 2
- Is device extremely constrained (<32 KB RAM, <1% power budget for crypto)?
- YES: Use Link-Layer (hardware AES) or lightweight Application-Layer
- NO: Continue to step 3
- Must protect against untrusted network infrastructure (public Wi-Fi, cellular)?
- YES: Use Transport-Layer (TLS) or End-to-End
- NO: Continue to step 4
- Is device using IP-based protocol (Wi-Fi, Ethernet, cellular)?
- YES: Use Transport-Layer (TLS/DTLS) – industry standard
- NO: Use Link-Layer (802.15.4 AES) for Zigbee/Thread
Example Applications:
- Smart thermostat (Wi-Fi, cloud API): Transport-Layer (TLS) – Standard HTTPS, broad support
- Zigbee door sensor (mesh network, constrained): Link-Layer (802.15.4 AES-128) – Protocol built-in
- Medical wearable (sensitive health data): End-to-End (E2EE) – Privacy regulation (HIPAA)
- Industrial sensor (Modbus TCP, sensitive SCADA data): Network-Layer (IPsec) – Site-to-site VPN
Multi-Layer Recommendation: For sensitive data (medical, financial), use Transport-Layer PLUS Application-Layer (defense-in-depth). Example: TLS for network protection + AES-GCM for data-at-rest encryption in database.
Worked Example: Interpreting Network Segmentation Diagrams for Security Audit
Scenario: A security consultant is auditing a smart hospital deployment with 1,200 IoT medical devices. The network architect provides a segmentation diagram showing 4 VLANs. Calculate whether the segmentation adequately protects patient safety devices from compromise.
Network Diagram Analysis:
VLAN 10 (Guest Wi-Fi): 200 devices - Patient/visitor smartphones
VLAN 20 (Medical IoT): 800 devices - Infusion pumps, patient monitors
VLAN 30 (Non-Critical IoT): 400 devices - Smart thermostats, occupancy sensors
VLAN 40 (Admin/Corporate): 150 devices - Staff workstations, EHR serversFirewall Rules:
Rule 1: VLAN 10 -> VLAN 20: DENY ALL (guests cannot reach medical devices)
Rule 2: VLAN 20 -> VLAN 40: ALLOW port 443 (medical devices send data to EHR)
Rule 3: VLAN 30 -> VLAN 20: ALLOW port 1883 (MQTT broker for sensor data)
Rule 4: VLAN 40 -> ALL: ALLOW (admins can reach all devices)Security Assessment:
Finding 1: Critical Vulnerability in Rule 3
Issue: Non-critical IoT (thermostats) can communicate with medical IoT
Attack Path:
1. Attacker compromises smart thermostat (VLAN 30) via known vulnerability
2. From thermostat, attacker pivots to MQTT broker (port 1883)
3. MQTT broker has access to medical device network (VLAN 20)
4. Attacker injects malicious commands to infusion pumps
Risk Calculation:
- Probability: 15% (thermostats have poor security, vendors slow to patch)
- Impact: CRITICAL (patient safety - incorrect medication dosage)
- Risk Score: 0.15 x 10 (max severity) = 1.5 / 10 (HIGH RISK)Finding 2: Overprivileged Admin Access (Rule 4)
Issue: Admin workstations have unrestricted access to ALL VLANs
Attack Path:
1. Phishing email compromises admin laptop (VLAN 40)
2. Attacker has full access to medical devices (VLAN 20)
3. Can disable life-support systems, exfiltrate patient data
Risk Calculation:
- Probability: 25% (phishing success rate in healthcare)
- Impact: CRITICAL (patient safety + HIPAA breach)
- Risk Score: 0.25 x 10 = 2.5 / 10 (CRITICAL RISK)Recommended Segmentation (defense-in-depth):
VLAN 10 (Guest): -> INTERNET ONLY (no internal access)
VLAN 20 (Critical Medical): -> Isolated, no inbound except from VLAN 50
VLAN 30 (Non-Critical IoT): -> Isolated, separate MQTT broker from VLAN 20
VLAN 40 (Corporate): -> NO direct access to VLAN 20
VLAN 50 (Jump Server): -> Gateway for admin access with MFA + audit logging
Updated Firewall Rules:
Rule 1: VLAN 10 -> ALL: DENY (except internet gateway)
Rule 2: VLAN 20 -> VLAN 40: ALLOW port 443 OUTBOUND ONLY
Rule 3: VLAN 30 -> VLAN 20: DENY ALL (separate MQTT brokers)
Rule 4: VLAN 40 -> VLAN 50: ALLOW (admins go through jump server)
Rule 5: VLAN 50 -> VLAN 20: ALLOW with MFA + session recordingRisk Reduction After Fixes:
Critical Medical Device Compromise Probability:
Before: ~36% combined attack surface (union of thermostat and admin paths)
After: <5% (only through hardened jump server with MFA)
Cost to Implement:
- Jump server VM: $200/month
- MFA licenses: $5/user x 50 admins = $250/month
- Firewall rule changes: 4 hours x $150/hr = $600 one-time
Total annual cost: $5,400 + $600 = $6,000
Avoided Cost (single breach):
- HIPAA violation: $50,000-$1.5M fine
- Patient harm lawsuit: $500K-$10M
- Reputational damage: Estimated $5M+ in lost patients
Expected annual savings: 0.31 x $2M (median breach cost) = $620,000
ROI: $620,000 / $6,000 = 10,333% return in year oneKey Insight: Visual network diagrams reveal attack paths that text descriptions miss. The thermostat-to-MQTT-to-medical-device path was non-obvious until diagram analysis showed the transitive trust relationship. Segmentation without proper firewall rules is security theater.
40.10 Knowledge Check
Common Pitfalls
1. Creating security diagrams that show the ideal architecture rather than the actual one
Security diagrams intended for risk assessment must accurately reflect the implemented architecture, not the intended or aspirational design. Diagrams showing controls that are not actually deployed create a false impression of security.
2. Omitting trust boundaries from architecture diagrams
Trust boundaries — where data crosses from one security zone to another — are where the most critical security controls are needed. Architecture diagrams without explicit trust boundaries miss the most important security design decisions.
3. Using visual resources to obscure rather than communicate risk
Security diagrams that use complex symbols, excessive detail, or misleading colour coding make risk harder to understand rather than easier. Design security visualisations for the audience: simplified risk heat maps for executives, detailed threat models for engineers.
40.11 Summary
This chapter presented visual resources spanning six key areas of IoT security: encryption architectures, attack scenarios, security architecture patterns, protocol security, data protection mechanisms, and hardware security. The central theme across all diagrams is that visual analysis reveals trust boundaries and attack paths that text descriptions alone can miss.
Key takeaways:
- Defense-in-depth provides multiplicative protection: four layers with 20%, 15%, 10%, and 5% bypass probabilities yield a combined breach probability of just 0.015%
- Encryption diagrams show intent, not implementation – always verify TLS versions, cipher suites, key storage, and certificate validation behind the diagram labels
- Network segmentation diagrams expose transitive trust relationships that create non-obvious attack paths, as demonstrated in the hospital VLAN analysis
- Attack trees decompose complex threats into prioritizable sub-goals, making systematic defense planning possible
- Hardware security concerns (trojans, side-channel attacks) require physical-layer defenses that complement software security measures
40.12 Further Reading
- NIST SP 800-183: Networks of ‘Things’ – reference architecture and security model for IoT systems
- OWASP IoT Security Project – community-maintained testing guides and vulnerability catalogs
- IEC 62443 – industrial automation and control system security standard
- RFC 6749: OAuth 2.0 Authorization Framework – delegated authorization for connected devices
- NIST Cybersecurity Framework – visual risk management guides applicable to IoT deployments
40.13 What’s Next
Continue exploring IoT security topics:
- Security Fundamentals – Core security concepts for IoT systems
- Threat Modeling and STRIDE – Systematic threat identification framework
- OWASP IoT Top 10 – Critical IoT vulnerabilities and mitigations
- Network Segmentation – Implementing segmentation architectures
- Secure Boot and Firmware – Device security implementation
- Hands-On Security Labs – Practical security exercises
| Network Segmentation | Security Fundamentals |