%% fig-alt: "IDS sensor placement strategy showing three network zones with dedicated sensors at each perimeter."
%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#ecf0f1'}}}%%
flowchart TB
subgraph IT["IT Zone<br/>192.168.10.x"]
IT_Dev[Workstations<br/>50 devices]
end
subgraph DMZ["DMZ<br/>192.168.50.x"]
Historian[Historian Server<br/>192.168.50.10]
end
subgraph OT["OT Zone<br/>192.168.100.x"]
OT_Dev[PLCs & Sensors<br/>80 devices]
end
IT_Dev --> Historian
Historian --> OT_Dev
S1[IDS Sensor 1<br/>IT Perimeter<br/>SPAN: Switch P1]
S2[IDS Sensor 2<br/>DMZ Monitoring<br/>SPAN: Switch P2]
S3[IDS Sensor 3<br/>OT Monitoring<br/>SPAN: Switch P3]
IT_Dev -.->|"Monitor IT to DMZ<br/>Detect recon"| S1
Historian -.->|"Monitor DMZ to OT<br/>Unauthorized queries"| S2
OT_Dev -.->|"Monitor intra-OT<br/>PLC anomalies"| S3
style IT fill:#2C3E50,stroke:#16A085,color:#fff
style DMZ fill:#E67E22,stroke:#2C3E50,color:#fff
style OT fill:#16A085,stroke:#2C3E50,color:#fff
style S1 fill:#7F8C8D,stroke:#2C3E50,color:#fff
style S2 fill:#7F8C8D,stroke:#2C3E50,color:#fff
style S3 fill:#7F8C8D,stroke:#2C3E50,color:#fff
1449 Security Control Implementation
1449.1 Learning Objectives
By the end of this chapter, you will be able to:
- Deploy IDS Sensors: Configure intrusion detection systems for industrial IoT and SCADA networks
- Implement Firewall Policies: Design role-based firewall rules for smart city and enterprise IoT deployments
- Configure Monitoring: Set up baseline traffic patterns and anomaly detection thresholds
- Reduce False Positives: Apply alert correlation and tuning techniques for operational environments
TipFor Beginners: Security Controls
What are Security Controls? Security controls are the specific measures you implement to protect systems - the actual firewalls, IDS sensors, access rules, and monitoring systems that enforce your security policies.
Why does it matter? Having a security framework (like NIST) is important, but without proper implementation of technical controls, your security exists only on paper. This chapter covers the practical “how” of security.
Key terms: | Term | Definition | |——|————| | IDS | Intrusion Detection System - monitors network traffic for suspicious activity | | IPS | Intrusion Prevention System - IDS that can also block detected threats | | SIEM | Security Information and Event Management - aggregates and correlates security logs | | Modbus | Industrial protocol for SCADA/OT systems (port 502) | | SPAN Port | Switch Port Analyzer - mirrors traffic for passive monitoring |
NoteKey Takeaway
In one sentence: Effective security controls require protocol-aware detection tuned to your specific environment with correlation rules to reduce false positives.
Remember this rule: Industrial and IoT networks need passive monitoring (SPAN ports) rather than inline blocking to avoid disrupting safety-critical processes.
1449.2 Prerequisites
Before diving into this chapter, you should be familiar with:
- NIST Framework: Understanding of the five core functions provides context for control implementation
- Networking Basics: Knowledge of network architecture helps implement segmentation and firewall rules
- Threat Modelling: Familiarity with attack vectors guides detection rule design
1449.3 Deploying IDS Sensors for Industrial IoT
NoteWorked Example: IDS Sensors for Industrial SCADA Network
Scenario: A water treatment facility operates 80 PLCs and sensors controlling pumps, valves, and chemical dosing systems. The security team must deploy an IDS to detect attacks on the OT (Operational Technology) network while avoiding false alarms that could disrupt 24/7 operations.
Given: - OT network: 80 devices on 192.168.100.0/24 (Modbus TCP, port 502) - IT network: 50 workstations on 192.168.10.0/24 (standard enterprise traffic) - DMZ: Historian server 192.168.50.10 (receives data from OT, accessed from IT) - Compliance: NIST 800-82 (Industrial Control Systems Security) - Constraint: Cannot install agents on PLCs (legacy systems, vendor restrictions) - Detection goals: Unauthorized Modbus commands, reconnaissance, lateral movement - False positive tolerance: <1 alert/day during normal operations
Steps:
1449.3.1 Step 1: Identify Optimal Sensor Placement
1449.3.2 Step 2: Configure Modbus-Aware Protocol Dissection Rules
# Snort/Suricata rules for Modbus TCP (port 502)
# Rule 1: Detect unauthorized function codes (potential attack)
alert modbus any any -> 192.168.100.0/24 502 (msg:"SCADA Modbus Write Coil from non-HMI"; \
modbus_func:write_single_coil; \
!src_ip:192.168.100.10; \ # HMI is only authorized writer
sid:1000001; rev:1;)
# Rule 2: Detect Modbus scanning (reconnaissance)
alert modbus any any -> 192.168.100.0/24 502 (msg:"SCADA Modbus Device Scan"; \
modbus_func:read_device_id; \
threshold:type threshold, track by_src, count 5, seconds 60; \
sid:1000002; rev:1;)
# Rule 3: Detect register read flood (data exfiltration)
alert modbus any any -> 192.168.100.0/24 502 (msg:"SCADA Excessive Register Reads"; \
modbus_func:read_holding_registers; \
threshold:type threshold, track by_src, count 100, seconds 60; \
sid:1000003; rev:1;)
# Rule 4: Detect illegal register addresses (fuzzing attack)
alert modbus any any -> 192.168.100.0/24 502 (msg:"SCADA Invalid Register Address"; \
modbus_func:read_holding_registers; \
modbus_data; content:"|FF FF|"; offset:0; depth:2; \
sid:1000004; rev:1;)1449.3.3 Step 3: Establish Baseline Traffic Patterns
BASELINE METRICS (7-day observation):
| Device Type | Modbus Func Codes | Requests/min | Response Time |
|----------------|-------------------|--------------|---------------|
| Pump PLCs | 0x03, 0x06 | 10-15 | 5-20 ms |
| Valve PLCs | 0x03, 0x05, 0x0F | 5-8 | 10-30 ms |
| Chem dosing | 0x03, 0x10 | 2-4 | 15-50 ms |
| HMI to all PLCs| 0x03, 0x06, 0x10 | 50-80 | 5-100 ms |
ANOMALY THRESHOLDS:
- Requests/min > 2x baseline: WARNING
- Requests/min > 5x baseline: CRITICAL
- New function code not in baseline: CRITICAL
- Response time > 200 ms: WARNING (may indicate DoS)1449.3.4 Step 4: Configure Alert Correlation
CORRELATION RULES (SIEM):
Rule 1: Require 3+ related events within 5 minutes
IF modbus_write_from_unknown AND (count >= 3 in 300 seconds)
THEN alert_severity = HIGH
ELSE suppress_alert
Rule 2: Correlate with authentication logs
IF modbus_anomaly AND failed_login_same_source_in_last_hour
THEN alert_severity = CRITICAL
ELSE alert_severity = MEDIUM
Rule 3: Business hours adjustment
IF alert_time NOT IN (06:00-22:00 weekdays)
AND source_ip NOT IN maintenance_whitelist
THEN alert_severity += 1 level1449.3.5 Step 5: Calculate Detection Coverage
COVERAGE ANALYSIS:
| Attack Type | Detection Method | Coverage |
|--------------------------|----------------------|----------|
| Unauthorized commands | Function code rules | 95% |
| Reconnaissance | Threshold rules | 90% |
| Data exfiltration | Volume anomaly | 85% |
| Man-in-the-middle | Response time anomaly| 70% |
| Insider threat (valid creds)| Behavioral baseline| 60% |
EXPECTED ALERT VOLUME (after tuning):
- Normal operations: 0.5 alerts/day (down from 15 alerts/day untuned)
- During maintenance: 2-3 alerts/day (whitelisted activities)
- During attack: 10-50 alerts/minute (clustered, high confidence)Result: - Detection latency: <5 seconds from attack to alert (inline sensors) - False positive rate: 0.5/day (within operator tolerance) - NIST 800-82 compliance: Network monitoring requirements satisfied - No OT impact: Passive monitoring via SPAN ports (no inline blocking) - Protocol coverage: 100% of Modbus TCP traffic inspected
Key Insight: Industrial IDS deployment requires protocol-aware detection that understands legitimate OT operations. The key difference from IT IDS is the emphasis on anomaly detection (new function codes, timing deviations) rather than signature matching, because attacks on OT often use valid protocol commands in unauthorized contexts. Always use passive monitoring (SPAN/TAP) rather than inline blocking to avoid disrupting safety-critical processes.
1449.4 Implementing Firewall Policies for Smart City IoT
NoteWorked Example: Role-Based Firewall Policies for Smart City
Scenario: A smart city deploys 5,000 IoT devices across traffic management, environmental monitoring, and public safety systems. The network team must design firewall policies that enforce least-privilege access while allowing legitimate inter-system communication.
Given: - Traffic management: 2,000 devices on 10.10.0.0/16 - Environmental monitoring: 1,500 devices on 10.20.0.0/16 - Public safety: 1,000 devices on 10.30.0.0/16 - City operations center (COC): 10.100.0.0/24 - Cloud platform: 52.0.0.0/8 (AWS region for analytics) - Inter-system integration: Traffic signals adjust based on air quality alerts - Constraint: Single firewall cluster (budget limitation)
Steps:
1449.4.1 Step 1: Define Security Zones and Trust Levels
ZONE ARCHITECTURE:
| Zone | CIDR | Trust Level | Description |
|---------------|----------------|-------------|--------------------------------|
| Traffic | 10.10.0.0/16 | Low | High volume, public exposure |
| Environment | 10.20.0.0/16 | Low | Distributed sensors |
| PublicSafety | 10.30.0.0/16 | Medium | Life-safety, higher protection |
| COC | 10.100.0.0/24 | High | Management, full access rights |
| Cloud | 52.0.0.0/8 | External | Third-party, encrypted only |
| Internet | 0.0.0.0/0 | Untrusted | Block all inbound by default |1449.4.2 Step 2: Create Role-Based Policy Groups
ROLE DEFINITIONS:
Role: IoT_Sensor_Telemetry
- Permissions: Send data to designated collector
- Ports: MQTT-TLS (8883), HTTPS (443)
- Direction: Outbound only
Role: IoT_Actuator_Control
- Permissions: Receive commands from authorized controller
- Ports: MQTT-TLS (8883), CoAP-DTLS (5684)
- Direction: Inbound from controller only
Role: Management_Console
- Permissions: Query any device, push configurations
- Ports: SSH (22), HTTPS (443), SNMP (161)
- Direction: Bidirectional to managed zones
Role: Cross_System_Integration
- Permissions: Specific API endpoints between systems
- Ports: HTTPS (443) with URL filtering
- Direction: Bidirectional, logged1449.4.3 Step 3: Implement Firewall Rules
# TRAFFIC ZONE RULES (10.10.0.0/16)
# Sensors to Cloud data platform (telemetry upload)
allow tcp 10.10.0.0/16 52.0.0.0/8 port 8883 comment "Traffic sensors to AWS MQTT"
# Sensors to COC (management queries)
allow tcp 10.10.0.0/16 10.100.0.0/24 port 443 comment "Sensor status to COC"
# COC to Traffic signals (control commands)
allow tcp 10.100.0.0/24 10.10.0.0/16 port 8883 comment "COC control to signals"
# Traffic to Environment (cross-system integration)
allow tcp 10.10.0.0/16 10.20.0.0/16 port 443 comment "Traffic-Env API integration"
# Block all other traffic from Traffic zone
deny ip 10.10.0.0/16 any log comment "Traffic zone default deny"
# PUBLIC SAFETY ZONE RULES (10.30.0.0/16) - Stricter policies
# Safety devices to COC only (no cloud, no other zones)
allow tcp 10.30.0.0/16 10.100.0.0/24 port 443 comment "Safety alerts to COC"
allow tcp 10.30.0.0/16 10.100.0.0/24 port 8883 comment "Safety telemetry to COC"
# COC to Safety devices (emergency commands)
allow tcp 10.100.0.0/24 10.30.0.0/16 port 443 comment "COC emergency commands"
# Block Public Safety from reaching any other zone
deny ip 10.30.0.0/16 10.10.0.0/16 log comment "No Safety to Traffic"
deny ip 10.30.0.0/16 10.20.0.0/16 log comment "No Safety to Env"
deny ip 10.30.0.0/16 52.0.0.0/8 log comment "No Safety to Cloud"
deny ip 10.30.0.0/16 any log comment "Safety zone default deny"1449.4.4 Step 4: Configure Cross-System Integration with URL Filtering
# INTEGRATION POLICY: Traffic adjusts based on air quality alerts
# Allow only specific API endpoint, not general access
# Environment to Traffic: Air quality API only
allow tcp 10.20.0.0/16 10.10.0.0/16 port 443 \
url-filter "/api/v1/air-quality/alerts" \
method GET,POST \
rate-limit 100/minute \
comment "Env air quality alerts to Traffic"
# Traffic to Environment: Acknowledgment only
allow tcp 10.10.0.0/16 10.20.0.0/16 port 443 \
url-filter "/api/v1/traffic/ack" \
method POST \
rate-limit 50/minute \
comment "Traffic ACK to Env"
# Log all cross-system API calls for audit
log tcp 10.10.0.0/16 10.20.0.0/16 port 443 comment "Integration audit log"
log tcp 10.20.0.0/16 10.10.0.0/16 port 443 comment "Integration audit log"1449.4.5 Step 5: Calculate Attack Surface Reduction
BEFORE SEGMENTATION (flat network):
- Possible connections: 5,000 x 5,000 = 25,000,000 device pairs
- Attack lateral movement: Any device can reach any other device
- Single compromise impact: Entire city network at risk
AFTER SEGMENTATION:
- Allowed connections: ~50,000 (0.2% of possible)
- Attack containment: Compromise in Traffic zone cannot reach Public Safety
- Policy rules: 47 explicit rules (manageable for audit)
RULE EFFICIENCY:
| Zone Pair | Before | After | Reduction |
|---------------------|--------|-------|-----------|
| Traffic to Safety | Open | Deny | 100% |
| Traffic to Cloud | Open | 8883 | 99.9% |
| Env to Safety | Open | Deny | 100% |
| Any to Internet in | Open | Deny | 100% |Result: - Attack surface: Reduced from 25M to 50K allowed connections (99.8% reduction) - Compliance: NIST CSF “Protect” function satisfied with documented policies - Integration maintained: Traffic-Environment API connection preserved with rate limiting - Audit capability: All cross-zone traffic logged with source, destination, timestamp - Incident containment: Public Safety zone isolated from all other IoT zones
Key Insight: Smart city firewall design must balance operational integration with security isolation. The solution is to allow only specific, documented API endpoints between zones rather than broad network access. Rate limiting prevents both accidental overload and deliberate abuse. Public safety systems require the strictest isolation because they directly affect human life.
1449.5 Knowledge Check: Security Controls
1449.6 Common Pitfalls
WarningCommon Pitfall: Security Theater
The mistake: Implementing visible security measures that provide little actual protection while neglecting fundamental controls.
Symptoms: - Expensive firewalls with overly permissive rules that allow most traffic - Complex password policies that users circumvent with predictable patterns - Security dashboards generating alerts no one reviews - Encryption without proper key management
Why it happens: Organizations prioritize appearance of security over substance. Vendor demonstrations focus on flashy features. Management measures security by budget spent rather than risk reduced.
The fix: Measure security by attack surface reduction and mean time to detect/respond, not by tools purchased. Conduct regular penetration testing. Ensure every control has an owner responsible for monitoring effectiveness.
WarningCommon Pitfall: Compliance Checkbox Mentality
The mistake: Treating security compliance as the goal rather than as a minimum baseline.
Symptoms: - Security policies that exist on paper but aren’t followed - Annual penetration tests finding the same vulnerabilities year after year - Compliance evidence gathered frantically before audits - “We’re compliant” used as justification for not implementing additional measures
The fix: View compliance as the floor, not the ceiling. Implement continuous compliance monitoring. Map requirements to actual controls and verify those controls work. Use frameworks as starting points for risk-based programs that go beyond minimum requirements.
1449.7 What’s Next
With technical security controls implemented, the next chapter explores Compliance and GDPR where you’ll learn to handle GDPR Article 17 erasure requests across multi-vendor IoT ecosystems, implement GDPR Article 25 Privacy by Design in firmware, and navigate regulatory requirements for IoT systems.
Continue to Compliance and GDPR
NoteRelated Chapters
Security Foundations: - NIST Framework - Framework for organizing security controls - Threat Modelling - Understanding attack vectors
Implementation: - Device Security - Securing IoT devices - Secure Data - Data protection strategies
Privacy: - Compliance and GDPR - Regulatory compliance - Privacy by Design - Building privacy in