1456  Intrusion Detection for IoT

1456.1 Intrusion Detection Systems for IoT

This chapter covers intrusion detection and prevention systems (IDS/IPS) for IoT environments, including signature-based and anomaly-based detection, deployment strategies, and practical knowledge checks.

1456.2 Learning Objectives

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

  • Compare signature-based and anomaly-based detection methods
  • Choose between network-based and host-based IDS for IoT
  • Design IDS deployment architectures for IoT networks
  • Tune detection thresholds to balance alerts and false positives
  • Respond to detected security incidents

1456.3 IDS/IPS Fundamentals

1456.3.1 Detection Methods

Method Description Strengths Weaknesses
Signature-Based Matches known attack patterns Low false positives, fast Cannot detect unknown attacks
Anomaly-Based Detects deviations from baseline Catches novel attacks Higher false positives
Hybrid Combines both approaches Best coverage More complex to tune

1456.3.2 IDS vs IPS

Aspect IDS (Detection) IPS (Prevention)
Action Alert only Alert + block
Position Passive (copy of traffic) Inline (traffic flows through)
Latency None Adds processing delay
Risk May miss attacks May block legitimate traffic
IoT Use Monitoring, forensics Critical asset protection
TipTradeoff: Signature-Based IDS vs Anomaly-Based IDS
Factor Signature-Based Anomaly-Based
Known Attacks Excellent detection May detect if behavior anomalous
Unknown Attacks Cannot detect (no signature) Can detect if behavior differs
False Positives Low (precise matching) Higher (baseline drift, edge cases)
Tuning Effort Low (vendor updates signatures) High (establish baselines, tune thresholds)
Resource Usage Low (pattern matching) Higher (statistical analysis, ML)
IoT Suitability Good for known IoT malware Better for behavioral changes

Recommendation: Use both methods. Signature-based catches known threats with high confidence; anomaly-based provides safety net for novel attacks.

TipTradeoff: Network-Based IDS vs Host-Based IDS for IoT
Factor Network-Based (NIDS) Host-Based (HIDS)
Visibility All network traffic Only host activities
Deployment Central (span port, tap) Per-device agent
Resource Impact None on IoT devices CPU/memory on constrained devices
Encrypted Traffic Cannot inspect (without TLS termination) Can see decrypted data on host
Scalability One sensor monitors many devices Agent per device (thousands)
IoT Suitability Excellent (no device changes) Limited (resource constraints)

Recommendation: NIDS for IoT (centralized monitoring, no device overhead). HIDS only for gateway devices with sufficient resources.

1456.4 IDS Deployment Architecture for IoT

%% fig-alt: "IDS deployment architecture showing network taps at zone boundaries capturing traffic, IDS sensors analyzing traffic for threats, centralized SIEM aggregating alerts from multiple sensors, and security operations center (SOC) responding to incidents."
%%{init: {'theme': 'base', 'themeVariables': {'primaryColor':'#2C3E50','primaryTextColor':'#fff','primaryBorderColor':'#16A085','lineColor':'#16A085','secondaryColor':'#E67E22','tertiaryColor':'#7F8C8D'}}}%%
flowchart TB
    subgraph network["NETWORK INFRASTRUCTURE"]
        subgraph iot["IoT Zone"]
            D1["Sensors"]
            D2["Actuators"]
            D3["Cameras"]
        end
        subgraph gw["Gateway Zone"]
            GW["IoT Gateway"]
            TAP1["Network Tap"]
        end
        subgraph corp["Corporate Zone"]
            SRV["Servers"]
            TAP2["Network Tap"]
        end
    end

    subgraph security["SECURITY MONITORING"]
        IDS1["IDS Sensor 1"]
        IDS2["IDS Sensor 2"]
        SIEM["SIEM Platform"]
        SOC["Security Operations"]
    end

    D1 & D2 & D3 --> GW
    GW --> TAP1
    TAP1 -->|"Copy"| IDS1
    TAP2 -->|"Copy"| IDS2
    IDS1 & IDS2 --> SIEM
    SIEM --> SOC

    style iot fill:#16A085,stroke:#2C3E50,stroke-width:2px,color:#fff
    style gw fill:#E67E22,stroke:#2C3E50,stroke-width:2px,color:#fff
    style corp fill:#2C3E50,stroke:#16A085,stroke-width:2px,color:#fff
    style security fill:#7F8C8D,stroke:#2C3E50,stroke-width:2px,color:#fff

1456.5 Knowledge Check Exercises

1456.5.1 Exercise 1: Network Segmentation and Firewall Configuration

Scenario: You’re the security architect for a smart factory with 500 IoT sensors, 50 PLCs (Programmable Logic Controllers), and 200 employee workstations. Recent threat intelligence indicates that attackers are targeting industrial IoT networks by compromising workstations via phishing, then pivoting to PLCs to disrupt manufacturing.

Current State: - All devices on flat network: 192.168.0.0/16 - No VLANs or internal firewalls - PLCs communicate with sensors via Modbus TCP (port 502) - Workstations access PLC HMI dashboards via HTTP (port 80)

Task: Design a segmented network architecture and firewall rules that prevent workstation compromises from reaching PLCs while maintaining operational functionality.

Click to reveal solution

Proposed Architecture:

VLAN Name Subnet Devices
10 Corporate 10.10.10.0/24 Workstations
20 OT-DMZ 10.10.20.0/24 HMI servers, historians
30 OT-Control 10.10.30.0/24 PLCs
40 OT-Field 10.10.40.0/23 500 IoT sensors

Firewall Rules:

# Sensors → PLCs: Modbus only
allow tcp 10.10.40.0/23 10.10.30.0/24 port 502

# PLCs → OT-DMZ: Data to historian
allow tcp 10.10.30.0/24 10.10.20.0/24 port 3000

# Workstations → OT-DMZ: HMI access only
allow tcp 10.10.10.0/24 10.10.20.0/24 port 443

# Workstations → PLCs: DENIED
deny ip 10.10.10.0/24 10.10.30.0/24

# All other inter-VLAN: DENIED
deny ip any any log
Key Security Improvements: 1. Phishing pivot blocked: Compromised workstation cannot reach PLCs (deny rule) 2. Defense in depth: HMI access through DMZ (never direct to PLCs) 3. Lateral movement limited: Sensors can only reach PLCs on Modbus port 4. Audit trail: All denied traffic logged for incident response

1456.5.2 Exercise 2: IDS Deployment Strategy

Scenario: A hospital is deploying 200 medical IoT devices across 10 floors. The security team must implement intrusion detection while complying with HIPAA requirements for audit logging and incident detection.

Constraints: - Limited budget: Can deploy 3 IDS sensors - Medical devices cannot have agents installed (FDA regulations) - Network spans 10 VLANs (one per floor plus servers)

Question: Where should the IDS sensors be placed for maximum visibility?

Click to reveal solution

Optimal IDS Placement:

  1. Sensor 1: Core switch span port
    • Sees all inter-VLAN traffic
    • Detects lateral movement between floors
    • Catches north-south traffic to servers
  2. Sensor 2: Internet edge (behind firewall)
    • Monitors incoming threats
    • Detects C2 communication attempts
    • Catches data exfiltration
  3. Sensor 3: Medical device aggregation point
    • Monitors IoT-specific traffic patterns
    • Baseline normal device behavior
    • Detects anomalous device activity
HIPAA Compliance: - All sensors log to centralized SIEM with 6-year retention - Alerts forwarded to 24/7 security operations - Quarterly review of IDS rules and baselines

1456.5.3 Quiz: IDS Concepts

Question 1: A smart agriculture system monitors soil moisture across 500 sensors. The IDS uses Z-score anomaly detection with a threshold of 3 standard deviations. During the first week of deployment, the system generates 200+ alerts daily, most from sensors in a newly irrigated field showing moisture readings outside the historical baseline. How should the security team respond?

Click to reveal answer

Answer: Retrain the baseline for affected sensors to reflect the new normal operating conditions after irrigation.

Anomaly detection requires accurate baselines. When operating conditions legitimately change (new irrigation patterns), the baseline must be updated. Many production systems have “learning mode” periods after environmental changes to establish new baselines. This maintains detection capability while eliminating false positives.

Question 2: An IPS protecting an IoT gateway is configured to block sources that exceed 100 requests per minute. A legitimate IoT dashboard sends 95 requests per minute during normal operation. During a security incident investigation, an analyst queries the same dashboard 10 times in one minute to review sensor data. What happens?

Click to reveal answer

Answer: The dashboard and analyst are both blocked because combined traffic (105 requests) exceeds the threshold.

Rate limiting counts all requests from a source. 95 (dashboard) + 10 (analyst) = 105 requests/minute exceeds the 100 threshold. This illustrates a real-world challenge: security controls can block legitimate activity during incidents. Production systems often have analyst-specific exceptions or elevated limits for investigation periods.

Question 3: A manufacturing plant’s IPS is configured in inline mode to block malicious traffic to protect PLCs. During a firmware update, the IPS incorrectly identifies the update traffic as a potential attack and blocks it, causing the update to fail. What architectural change would prevent this scenario?

Click to reveal answer

Answer: Implement a maintenance mode or change window policy that temporarily reduces IPS sensitivity for planned updates.

Production IPS deployments require change management integration. During planned maintenance windows, IPS can operate in “detect-only” mode or with relaxed rules for known update traffic patterns. This balances security with operational requirements.

1456.6 Threat Detection Techniques

1456.6.1 Statistical Anomaly Detection

Z-score anomaly detection is fundamental in IoT security:

Z-score = (Value - Mean) / Standard Deviation

How it works:

  1. The system maintains a baseline of recent sensor readings
  2. Each new reading is compared to the baseline using Z-score
  3. Values with Z-score > 3 are flagged as anomalies (99.7% confidence)

Why it matters for IoT:

  • Detects sensor tampering (injected false readings)
  • Identifies equipment malfunctions before failure
  • Catches data exfiltration through sensor channels
  • Works without predefined attack signatures

1456.6.2 Pattern-Based Attack Detection

Correlating multiple events to detect multi-stage attacks:

Port Scan Detection: - Tracks connection attempts to different ports - 5+ ports probed in 5 seconds = scan detected - Indicates reconnaissance phase of attack

Brute Force Detection: - Monitors authentication failure sequences - 3+ failures from same source = attack detected - Triggers account lockout

Event Correlation: - Severity scores assigned to each event - Multiple medium events = elevated threat - Single critical event = immediate response

1456.7 Summary

This chapter covered intrusion detection for IoT:

  • Detection Methods: Signature-based (known attacks), anomaly-based (novel attacks)
  • IDS vs IPS: Detection only vs. active blocking
  • NIDS for IoT: Centralized monitoring without device overhead
  • Deployment: Strategic sensor placement at zone boundaries
  • Tuning: Balance detection sensitivity with false positive rates

1456.8 What’s Next

The next chapter provides Hands-On Labs using Wokwi ESP32 simulators to practice implementing authentication, rate limiting, and threat detection in IoT devices.

Continue to Hands-On Labs →