By the end of this chapter, you will be able to:
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 |
“Frameworks tell you WHAT to do, but security controls are HOW you actually do it!” Max the Microcontroller said, rolling up his sleeves. “These are the real tools: firewalls, intrusion detection systems, encryption implementations, and monitoring dashboards.”
Sammy the Sensor described the detection tools. “An IDS watches network traffic like a security guard watching surveillance cameras. It compares what it sees against known attack patterns and alerts when something suspicious happens. An IPS goes one step further – it can automatically BLOCK the suspicious traffic, like a guard who locks the door when they see an intruder.”
“SIEM systems are the command center,” Lila the LED explained. “They collect logs from every device, every firewall, every server, and correlate them together. A failed login attempt on one device might not be alarming, but ten failed attempts across five different devices in two minutes? That is a coordinated attack, and only a SIEM that sees the big picture can catch it.”
“For industrial IoT, Modbus protocol monitoring is critical,” Bella the Battery added. “Modbus was designed in 1979 with NO security. It is used in factories, power plants, and water treatment facilities. Adding monitoring on SPAN ports lets you watch this traffic without disrupting operations. Security controls bridge the gap between policy and protection!”
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.
Before diving into this chapter, you should be familiar with:
Deploying IDS sensors in industrial IoT requires a fundamentally different approach than traditional IT networks. Here’s the step-by-step process:
Step 1: Passive Monitoring via SPAN Ports Industrial networks cannot tolerate inline security devices that might add latency or create single points of failure. Instead, deploy sensors on SPAN (Switch Port Analyzer) or TAP (Test Access Point) ports that mirror traffic without disrupting it. The sensor sees every packet but never touches the production data flow.
Step 2: Protocol-Aware Detection Industrial protocols like Modbus TCP, BACnet, and EtherNet/IP have specific command structures. Configure the IDS with protocol dissectors that understand valid Modbus public function codes (0x01-0x06 for data access, 0x0F-0x10 for multiple writes, 0x11 for server ID, etc.) and flag invalid or unauthorized commands. A temperature sensor shouldn’t send “write coil” commands; a PLC shouldn’t perform reconnaissance scans.
Step 3: Baseline Normal Behavior Spend 30 days learning what “normal” looks like for each device type. Industrial devices are highly predictable: a PLC sends the same packet size every N seconds to the same destination for years. Deviations from this pattern (10x traffic volume, new destination, unusual timing) indicate compromise or malfunction.
Step 4: Tune for False Positives Initial deployment generates hundreds of alerts per day. Apply correlation rules: require 3+ related events within 5 minutes before alerting. Whitelist legitimate maintenance windows. Adjust thresholds based on operational reality. Target <1 alert per day during normal operations.
Step 5: Integrate with SIEM Forward alerts to a Security Information and Event Management system that correlates IDS events with authentication logs, firewall blocks, and physical access records. A Modbus anomaly combined with a failed login attempt from the same source IP within the hour elevates severity to CRITICAL.
Why Passive Monitoring Matters: In a water treatment plant, an inline security device that crashes could prevent emergency shutdown commands from reaching valves. Passive monitoring observes everything, blocks nothing, and lets operators maintain safety-critical control loops.
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:
192.168.100.0/24 (Modbus TCP, port 502)192.168.10.0/24 (standard enterprise traffic)192.168.50.10 (receives data from OT, accessed from IT)Steps:
# 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;)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)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 levelCOVERAGE 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:
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.
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:
10.10.0.0/1610.20.0.0/1610.30.0.0/1610.100.0.0/2452.0.0.0/8 (AWS region for analytics)Steps:
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 |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, logged# 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"# 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"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:
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.
Understanding how security control implementation connects to other security concepts:
| Security Control Concept | Relates To | Connection |
|---|---|---|
| IDS/IPS Deployment | NIST DETECT Function | Provides real-time threat identification capability |
| Firewall Policies | Zero Trust Segmentation | Enforces least-privilege network access |
| SPAN Port Monitoring | Defense in Depth | Observes traffic without disrupting production |
| Protocol Dissection | Application-Layer Security | Validates protocol-specific command sequences |
| Behavioral Baselines | Anomaly Detection | Establishes normal patterns to identify deviations |
| SIEM Integration | Continuous Monitoring | Correlates events across multiple security layers |
| Rate Limiting | DoS Prevention | Protects against both malicious and accidental overload |
| Micro-Segmentation | NIST PROTECT Function | Limits lateral movement after initial compromise |
Explore how network segmentation reduces attack surface. Adjust the number of devices and zones to see how firewall policies limit potential attack paths.
Intrusion detection performance is measured using confusion matrix metrics. Precision quantifies actionable alert quality.
True Positive Rate (TPR) / Sensitivity: \[\text{TPR} = \frac{\text{TP}}{\text{TP} + \text{FN}}\]
False Positive Rate (FPR): \[\text{FPR} = \frac{\text{FP}}{\text{FP} + \text{TN}}\]
Precision (Positive Predictive Value): \[\text{Precision} = \frac{\text{TP}}{\text{TP} + \text{FP}}\]
Working through an example:
Given: Smart city IDS over 30 days - True Positives (TP): 847 real attacks detected - False Positives (FP): 12,340 false alarms - False Negatives (FN): 23 real attacks missed - True Negatives (TN): 4,580,000 normal events correctly classified
Step 1: Calculate TPR (detection rate) \[\text{TPR} = \frac{847}{847 + 23} = \frac{847}{870} = 0.9736 = 97.4\%\]
Step 2: Calculate FPR (false alarm rate) \[\text{FPR} = \frac{12340}{12340 + 4580000} = \frac{12340}{4592340} = 0.0027 = 0.27\%\]
Step 3: Calculate Precision (actionable alert quality) \[\text{Precision} = \frac{847}{847 + 12340} = \frac{847}{13187} = 0.0642 = 6.4\%\]
Result: TPR = 97.4% (good detection), but Precision = 6.4% means only 6.4% of alerts are real—causing alert fatigue. For every 100 alerts, 93.6 are false positives.
In practice: Low precision (6.4%) means SOC analysts ignore alerts (“cry wolf”). Target precision >50% for actionable systems. Tuning IDS baselines (30-day learning, correlation rules) improves precision from 6% to 45% without reducing TPR.
Adjust the confusion matrix values to explore how true positives, false positives, false negatives, and true negatives affect IDS detection metrics. Observe how alert tuning (reducing FP) dramatically improves precision.
Scenario: A city deploys 2,400 traffic signal controllers, 800 intersection cameras, and 150 variable message signs across 600 intersections. Design the security control stack and calculate detection performance.
Step 1: Traffic Baseline Characterization
Establish normal communication patterns to distinguish attacks from legitimate traffic:
| Device Type | Count | Protocol | Msg Interval | Payload Size | Daily Traffic |
|---|---|---|---|---|---|
| Signal controllers | 2,400 | NTCIP/SNMP | 5 sec | 128 bytes | 5.0 GB |
| Cameras | 800 | RTSP/H.264 | Continuous | 2 Mbps avg | 17.3 TB |
| Message signs | 150 | NTCIP/SNMP | 30 sec | 256 bytes | 0.1 GB |
| Central management | 1 | HTTPS | On-demand | Variable | 2.1 GB |
Total daily traffic: ~17.3 TB (99.97% is camera video).
Step 2: IDS Sensor Placement and Cost
NTCIP/SNMP traffic (signal control) is safety-critical and low-bandwidth. Camera traffic is high-bandwidth but less safety-critical. Optimize sensor placement:
| Deployment Option | Sensors | Annual Cost | Coverage |
|---|---|---|---|
| A: Every intersection | 600 | $1.8M | 100% — full visibility |
| B: Aggregation switches only | 48 | $192K | 100% — monitors aggregated links |
| C: District gateways + sampling | 12 + sampling | $72K | 85% — misses intra-district attacks |
Recommended: Option B. At aggregation switches, one IDS sensor monitors 12-15 intersections. All NTCIP traffic passes through these points, so coverage is 100% for signal-control commands at 1/12th the cost of Option A.
Step 3: False Positive Analysis
With 2,400 controllers sending every 5 seconds = 41.5M messages/day:
| Detection Method | Raw Alerts/Day | True Positives | False Positive Rate |
|---|---|---|---|
| Signature-only (known attacks) | 1,200 | 8 | 99.3% (operator overload) |
| + Protocol validation (valid NTCIP) | 340 | 8 | 97.6% (still noisy) |
| + Timing anomaly (±2 sec window) | 45 | 7 | 84.4% (manageable) |
| + Cross-intersection correlation | 12 | 7 | 41.7% (actionable) |
Each additional detection layer reduces false positives dramatically. Cross-intersection correlation catches coordinated signal timing changes (e.g., all-green attack) while filtering isolated glitches.
Step 4: Firewall Policy Design
Segment the network into security zones with explicit allow rules:
Zone 1: Signal Controllers (NTCIP only)
ALLOW: Controller → Central (SNMP GET-RESPONSE, port 161)
ALLOW: Central → Controller (SNMP SET, port 161)
DENY: Controller → Controller (no peer communication)
DENY: Controller → Internet (air-gapped from WAN)
Zone 2: Camera Network (video only)
ALLOW: Camera → Video Server (RTSP, port 554)
DENY: Camera → Signal Controllers (cross-zone blocked)
DENY: Camera → Internet (no cloud streaming)
Zone 3: Management (authenticated only)
ALLOW: Ops Center → Central (HTTPS, port 443, with MFA)
ALLOW: Central → All Zones (management traffic only)
DENY: All → Ops Center (no inbound from field devices)Critical rule: Signal controllers MUST NOT communicate with cameras. A compromised camera should never be able to send commands to traffic signals.
Step 5: Detection Performance Summary
| Metric | Before Controls | After Controls |
|---|---|---|
| Attack surface (open ports) | 12,400 | 3,350 (73% reduction) |
| Mean time to detect signal tampering | Never (no monitoring) | 4.2 minutes |
| Actionable alerts per day | 0 | 12 |
| Cross-zone attack paths | 8 (camera↔︎signal) | 0 (segmented) |
| Annual control cost | $0 | $192K (Option B) |
Key lesson: Network segmentation (firewall zones) provides the highest security return for traffic systems. Blocking camera-to-signal-controller communication eliminates the most dangerous attack path at zero per-device cost.
The mistake: Implementing visible security measures that provide little actual protection while neglecting fundamental controls.
Symptoms:
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.
The mistake: Treating security compliance as the goal rather than as a minimum baseline.
Symptoms:
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.
Expand your knowledge of security control implementation and related topics:
Security Implementation:
Network Security:
Device Security:
Monitoring and Response:
Data Protection and Privacy:
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
| ← NIST Framework | GDPR Compliance → |