%% fig-alt: "Network anomaly detection flow showing baseline comparison and alert escalation. Network Packet goes through metric extraction (size, interval, destination), compared against baseline using z-score. If within 3 standard deviations, classified as Normal Traffic and baseline updated. If beyond 3 standard deviations, severity assessed: 3-5 sigma triggers MEDIUM alert (log and monitor), above 5 sigma triggers HIGH alert (block and notify security team)."
%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#E67E22', 'secondaryColor': '#16A085', 'tertiaryColor': '#E67E22', 'fontSize': '13px'}}}%%
graph TD
A[Network Packet] --> B[Extract Metrics<br/>Size, Interval, Destination]
B --> C{Compare to<br/>Baseline}
C -->|Within 3 sigma| D[Normal Traffic<br/>Update Baseline]
C -->|Beyond 3 sigma| E{Severity<br/>Assessment}
E -->|3-5 sigma| F[MEDIUM Alert<br/>Log + Monitor]
E -->|Above 5 sigma| G[HIGH Alert<br/>Block + Notify]
G --> H[Security Team<br/>Email/SMS/SIEM]
style A fill:#2C3E50,stroke:#16A085,color:#fff
style B fill:#2C3E50,stroke:#16A085,color:#fff
style C fill:#E67E22,stroke:#d35400,color:#fff
style D fill:#16A085,stroke:#0e6655,color:#fff
style E fill:#E67E22,stroke:#d35400,color:#fff
style F fill:#f39c12,stroke:#e67e22,color:#fff
style G fill:#e74c3c,stroke:#c0392b,color:#fff
style H fill:#c0392b,stroke:#a93226,color:#fff
1383 Security Monitoring and Intrusion Detection
1383.1 Learning Objectives
By the end of this chapter, you should be able to:
- Distinguish between signature-based and anomaly-based intrusion detection
- Design anomaly detection systems for IoT device behavior monitoring
- Implement comprehensive security logging and audit trails
- Integrate security events with SIEM systems
- Apply security concepts through hands-on exercises
TipFor Beginners: Understanding Security Monitoring
What is Security Monitoring? Security monitoring continuously observes systems for signs of attack or compromise. It’s like having security cameras and guards watching for suspicious behavior, but for digital systems.
Why does it matter for IoT? Even with strong preventive controls (firewalls, encryption), attacks can still succeed. Detection systems catch attacks in progress, enabling rapid response before significant damage occurs. The average time to detect a breach is 197 days - monitoring aims to reduce this dramatically.
Key terms: | Term | Definition | |——|————| | IDS | Intrusion Detection System - monitors for attacks | | IPS | Intrusion Prevention System - blocks detected attacks | | SIEM | Security Information and Event Management - correlates events | | Anomaly Detection | Detecting unusual behavior vs. established baseline | | Signature-based | Detecting known attack patterns |
1383.2 Prerequisites
Before diving into this chapter, you should be familiar with:
- Defense in Depth: Where monitoring fits in the security architecture
- Access Control: Understanding what constitutes an access violation
1383.3 Intrusion Detection Systems
Intrusion detection systems monitor network traffic and system activity for malicious activity or policy violations.
1383.3.1 Signature-Based vs Anomaly-Based Detection
| Aspect | Signature-Based | Anomaly-Based |
|---|---|---|
| How it works | Match patterns against known attack signatures | Compare behavior against established baseline |
| Detection | Known attacks only | Novel attacks + known attacks |
| False positives | Low | Higher (requires tuning) |
| Setup effort | Low (use vendor signatures) | High (must establish baseline) |
| Maintenance | Update signature database | Retrain models periodically |
| Best for | Detecting known malware, exploits | Detecting zero-day attacks, insider threats |
1383.3.2 Signature-Based Detection Example
# Signature-based IDS for MQTT
class SignatureBasedIDS:
def __init__(self):
self.signatures = [
{
"name": "MQTT_Injection",
"pattern": r"[\x00-\x1f]", # Control characters
"action": "block"
},
{
"name": "SQL_Injection",
"pattern": r"(SELECT|INSERT|DELETE|DROP)\s",
"action": "alert"
},
{
"name": "Command_Injection",
"pattern": r"[;&|`$]", # Shell metacharacters
"action": "block"
},
{
"name": "Port_Scan",
"pattern": "5+ connection attempts in 10 seconds",
"action": "alert"
}
]
def analyze_traffic(self, packet):
for sig in self.signatures:
if re.search(sig["pattern"], packet.payload):
self.trigger_alert(sig, packet)
def trigger_alert(self, signature, packet):
alert = {
"type": signature["name"],
"severity": "HIGH" if signature["action"] == "block" else "MEDIUM",
"source_ip": packet.source_ip,
"timestamp": datetime.now()
}
self.send_to_siem(alert)1383.3.3 Anomaly-Based Detection Example
# Anomaly-based IDS using statistical analysis
class AnomalyBasedIDS:
def __init__(self):
self.baseline = {} # device_id -> baseline metrics
def establish_baseline(self, device_id, historical_data):
"""Build baseline from 7-14 days of normal traffic"""
self.baseline[device_id] = {
"packet_size": {
"mean": np.mean(historical_data["sizes"]),
"std": np.std(historical_data["sizes"])
},
"interval": {
"mean": np.mean(historical_data["intervals"]),
"std": np.std(historical_data["intervals"])
},
"destinations": set(historical_data["destinations"])
}
def analyze_traffic(self, device_id, current_data):
"""Compare current behavior to baseline"""
if device_id not in self.baseline:
return # No baseline yet
baseline = self.baseline[device_id]
# Check packet size anomaly (z-score > 3)
z_size = (current_data["size"] - baseline["packet_size"]["mean"]) / \
baseline["packet_size"]["std"]
if abs(z_size) > 3:
self.trigger_alert("PACKET_SIZE_ANOMALY", device_id, z_size)
# Check for new destinations
if current_data["destination"] not in baseline["destinations"]:
self.trigger_alert("NEW_DESTINATION", device_id,
current_data["destination"])
# Check transmission interval
z_interval = (current_data["interval"] - baseline["interval"]["mean"]) / \
baseline["interval"]["std"]
if abs(z_interval) > 3:
self.trigger_alert("INTERVAL_ANOMALY", device_id, z_interval)
def trigger_alert(self, alert_type, device_id, details):
alert = {
"type": alert_type,
"device_id": device_id,
"details": details,
"severity": "HIGH" if "NEW_DESTINATION" in alert_type else "MEDIUM",
"timestamp": datetime.now()
}
self.send_to_siem(alert)1383.4 Attack Detection Scenarios
| Attack Type | Normal Behavior | Anomalous Behavior | Detection Method |
|---|---|---|---|
| Data Exfiltration | 1 KB packets | 10 MB packets | Packet size z-score > 5 |
| DDoS Participation | 1 packet/min | 1000 packets/sec | Interval z-score > 5 |
| C&C Beaconing | No C&C contact | Contact unknown IP every 5 sec | Unknown destination IP |
| Cryptomining | 5-10% CPU | 95% CPU sustained | CPU usage z-score > 3 |
| Port Scanning | MQTT:8883 only | Scan ports 1-65535 | Connection count > 10 |
1383.5 Security Logging and Audit Trails
Comprehensive logging enables incident investigation, compliance verification, and forensic analysis.
1383.5.1 What to Log
| Event Category | Specific Events | Retention |
|---|---|---|
| Authentication | Login success/failure, session start/end | 1 year |
| Authorization | Access granted/denied, permission changes | 1 year |
| Configuration | Setting changes, firmware updates | 7 years |
| Network | Connection attempts, data transfers | 90 days |
| Security | IDS alerts, policy violations | 2 years |
| System | Boot, shutdown, errors | 90 days |
1383.5.2 Security Log Schema
{
"event_id": "uuid-v4",
"timestamp": "2026-01-10T14:32:15.234Z",
"event_type": "AUTHENTICATION_ATTEMPT",
"outcome": "FAILURE",
"severity": "MEDIUM",
"source": {
"device_id": "sensor-42",
"ip_address": "192.168.1.100",
"mac_address": "AA:BB:CC:DD:EE:FF"
},
"target": {
"service": "MQTT_BROKER",
"endpoint": "mqtt.company.com:8883"
},
"details": {
"reason": "INVALID_CERTIFICATE",
"certificate_cn": "sensor-42.factory.com",
"certificate_expiry": "2025-12-31T23:59:59Z"
},
"context": {
"session_id": "sess-123456",
"request_id": "req-789012"
}
}1383.5.3 SIEM Integration
Security Information and Event Management (SIEM) systems correlate events across multiple sources to detect complex attacks.
%% fig-alt: "SIEM integration flow showing event collection from multiple sources (IoT devices, network devices, applications, cloud services) aggregated into SIEM platform for correlation, analysis, and alerting. SIEM outputs to Security Dashboard, Automated Alerts, and Incident Response workflows."
%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#E67E22', 'secondaryColor': '#16A085', 'tertiaryColor': '#E67E22', 'fontSize': '13px'}}}%%
graph LR
subgraph Sources["Event Sources"]
A[IoT Devices]
B[Network Devices]
C[Applications]
D[Cloud Services]
end
subgraph SIEM["SIEM Platform"]
E[Event Collection<br/>& Normalization]
F[Correlation<br/>Engine]
G[Alert<br/>Management]
end
subgraph Output["Outputs"]
H[Security<br/>Dashboard]
I[Automated<br/>Alerts]
J[Incident<br/>Response]
end
A --> E
B --> E
C --> E
D --> E
E --> F
F --> G
G --> H
G --> I
G --> J
style A fill:#2C3E50,stroke:#16A085,color:#fff
style B fill:#2C3E50,stroke:#16A085,color:#fff
style C fill:#2C3E50,stroke:#16A085,color:#fff
style D fill:#2C3E50,stroke:#16A085,color:#fff
style E fill:#E67E22,stroke:#d35400,color:#fff
style F fill:#E67E22,stroke:#d35400,color:#fff
style G fill:#E67E22,stroke:#d35400,color:#fff
style H fill:#16A085,stroke:#0e6655,color:#fff
style I fill:#16A085,stroke:#0e6655,color:#fff
style J fill:#16A085,stroke:#0e6655,color:#fff
1383.6 Practice Exercises
NoteExercise 1: Implementing Role-Based Access Control (RBAC)
Objective: Design and implement a role-based access control system for an IoT platform.
Scenario: You’re building a smart building management system with 3 user types: Administrators, Operators, and Viewers.
Tasks:
Define Role-Permission Matrix:
Role Read Sensors Write Data Control Actuators Manage Devices Admin Panel Admin Yes Yes Yes Yes Yes Operator Yes No Yes No No Viewer Yes No No No No Design Access Control Flow:
%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#E67E22', 'secondaryColor': '#16A085', 'tertiaryColor': '#E67E22', 'fontSize': '13px'}}}%%
graph LR
A[API Request] --> B{Extract JWT Token}
B --> C{Verify Token Signature}
C -->|Invalid| D[401 Unauthorized]
C -->|Valid| E{Extract User Role}
E --> F{Check Role Permissions}
F -->|Missing| G[403 Forbidden]
F -->|Has Permission| H[Execute Action + Log]
style A fill:#2C3E50,stroke:#16A085,color:#fff
style D fill:#e74c3c,stroke:#c0392b,color:#fff
style G fill:#e74c3c,stroke:#c0392b,color:#fff
style H fill:#16A085,stroke:#0e6655,color:#fff
Test RBAC Enforcement:
Test User Role Action Expected Result 1 Viewer Unlock door 403 Forbidden 2 Operator Delete device 403 Forbidden 3 Admin Unlock door 200 Success 4 (Invalid token) Any 401 Unauthorized
Expected Outcome: Working RBAC implementation with complete audit trail.
NoteExercise 2: Mutual TLS (mTLS) Authentication
Objective: Implement mutual TLS authentication for device-to-server communication.
Scenario: Your smart factory has 100 industrial sensors connecting to an MQTT broker. Implement mTLS so only authorized devices can connect.
Tasks:
Create Certificate Authority:
# Generate CA openssl genrsa -out ca.key 4096 openssl req -new -x509 -days 3650 -key ca.key -out ca.crt \ -subj "/C=US/ST=CA/O=MyCompany/CN=MyCompany Root CA" # Generate server certificate openssl genrsa -out server.key 2048 openssl req -new -key server.key -out server.csr \ -subj "/C=US/ST=CA/O=MyCompany/CN=mqtt.mycompany.com" openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key \ -CAcreateserial -out server.crt -days 365 # Generate device certificate openssl genrsa -out device1.key 2048 openssl req -new -key device1.key -out device1.csr \ -subj "/C=US/ST=CA/O=MyCompany/CN=device-001" openssl x509 -req -in device1.csr -CA ca.crt -CAkey ca.key \ -CAcreateserial -out device1.crt -days 365Configure MQTT broker for mTLS:
listener 8883 certfile /etc/mosquitto/certs/server.crt keyfile /etc/mosquitto/certs/server.key cafile /etc/mosquitto/certs/ca.crt require_certificate true use_identity_as_username trueTest Security:
- Device with valid certificate connects successfully
- Device without certificate is rejected
- Device with wrong certificate is rejected
- Device rejects connection to fake broker
Expected Outcome: Bidirectional authentication with full audit trail.
NoteExercise 3: Intrusion Detection with Anomaly Detection
Objective: Implement anomaly-based intrusion detection for IoT devices.
Scenario: Your smart home temperature sensors normally send 1KB every 60 seconds. Build a system to detect unusual behavior.
Tasks:
Establish Normal Baseline:
Metric Normal Value Purpose Packet Size 1024 bytes +/- 50 Detect data exfiltration Interval 60 sec +/- 5 Detect beaconing/DDoS Destinations mqtt.company.com only Detect C&C communication Implement Detection:
def detect_anomaly(current, baseline): z_score = (current - baseline['mean']) / baseline['std'] if abs(z_score) > 3: return "MEDIUM" if abs(z_score) <= 5 else "HIGH" return NoneTest Detection Scenarios:
Attack Normal Anomalous Detection Exfiltration 1 KB 10 MB z > 5 DDoS 1/min 1000/sec z > 5 C&C Known IP Unknown IP New destination
Expected Outcome: Working anomaly detection with tuned thresholds and false positive analysis.
NoteExercise 4: Secure OTA Updates with Signature Verification
Objective: Build a secure over-the-air update system with cryptographic verification.
Scenario: You have 1,000 IoT sensors deployed. Push a security patch without physical access.
Tasks:
Generate signing keys:
openssl genrsa -out firmware_signing_key.pem 2048 openssl rsa -in firmware_signing_key.pem -pubout -out firmware_public_key.pemSign firmware:
openssl dgst -sha256 -sign firmware_signing_key.pem \ -sigopt rsa_padding_mode:pss \ -out firmware_v2.0.sig \ firmware_v2.0.binVerify on device (before installation):
- Compute SHA-256 hash of downloaded firmware
- Verify RSA signature with embedded public key
- Reject if signature invalid
- Install only if verification passes
Test Security:
- Correct signature: Installation succeeds
- Modified firmware: Signature fails, blocked
- Wrong key signature: Verification fails, blocked
- Old firmware (downgrade): Version check fails
Expected Outcome: Secure OTA with anti-rollback protection.
1383.7 Knowledge Checks
1383.8 Chapter Summary
Security monitoring provides visibility into system behavior, enabling detection of attacks that bypass preventive controls. Signature-based detection identifies known attack patterns with low false positive rates, while anomaly-based detection catches novel attacks by comparing current behavior against established baselines.
Comprehensive logging creates audit trails for incident investigation, compliance verification, and forensic analysis. SIEM systems correlate events across multiple sources to detect complex, multi-stage attacks that individual systems might miss.
The practice exercises reinforce key concepts: RBAC implementation, mTLS configuration, anomaly detection system design, and secure OTA update verification. Together, these monitoring capabilities complete the defense-in-depth security architecture.
1383.9 What’s Next
This completes the Cybersecurity Methods series. For the complete overview and links to all topics, see the Cybersecurity Methods Overview.
For deeper exploration of related topics:
- Threats and Vulnerabilities - Understanding what you’re monitoring for
- Threat Modeling - Systematic approach to identifying risks