Network Security Monitoring for Industrial Protocols

January 18, 2026 ⏱ 3 min read OT/ICS Security

Objective

Build a network security monitoring solution specifically designed for OT/ICS environments — one that understands industrial protocols like Modbus, DNP3, and S7comm, and can distinguish between normal process communication and potentially malicious activity.

The Challenge

Standard IT security tools are often blind to OT protocols. A typical enterprise IDS might see Modbus traffic as “unknown TCP on port 502” and ignore it entirely. OT environments need monitoring tools configured to parse, understand, and baseline industrial protocol behavior.

Architecture

1
2
3
4
5
6
7
8
[PLC Simulator] ←→ [Managed Switch w/ SPAN port] ←→ [HMI/SCADA]
                     [Mirror Port]
                   [Monitoring Station]
                   ├── Zeek (protocol analysis)
                   ├── Suricata (IDS/IPS)
                   └── ELK Stack (log aggregation)

Tools & Configuration

Zeek for Industrial Protocol Logging

Zeek (formerly Bro) has built-in analyzers for several industrial protocols. I configured it to log:

  • Every Modbus read/write transaction with register addresses and values
  • DNP3 request/response pairs
  • Connection metadata (who talks to whom, how often, and what function codes)

This creates a communication baseline — essential for detecting anomalies in OT environments where traffic patterns are highly predictable.

Suricata with OT-Specific Rulesets

I loaded the Emerging Threats ICS ruleset alongside custom rules:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
# Alert on Modbus write to holding registers from unexpected source
alert modbus any any -> $PLC_NET 502 (msg:"Unauthorized Modbus Write";
  modbus.function: 6; # Write Single Register
  flow:to_server,established;
  sid:2000001; rev:1;)

# Alert on Modbus device identification scan
alert modbus any any -> $PLC_NET 502 (msg:"Modbus Device ID Scan";
  modbus.function: 43;
  flow:to_server,established;
  sid:2000002; rev:1;)

ELK Stack for Visualization

I built Kibana dashboards showing:

  • Communication matrix — Which devices communicate and how often
  • Function code distribution — Normal operations use a small set of Modbus function codes; new ones appearing could indicate reconnaissance
  • Register value trends — Process values plotted over time to spot manipulation
  • Alert timeline — Suricata IDS alerts correlated with Zeek connection logs

Key Findings

Normal Traffic Baseline

In a healthy ICS environment, traffic is remarkably predictable:

  • The HMI polls the PLC every 500ms using Modbus function code 0x03 (Read Holding Registers)
  • Register addresses 0-20 are read in sequence
  • Values change slowly and within expected ranges
  • No other devices initiate Modbus connections to the PLC

Anomalies I Detected

By running attack simulations from my Kali machine, the monitoring system successfully identified:

  1. New Modbus source — An IP address that had never previously communicated with the PLC
  2. Unusual function codes — Function code 0x05 (Write Single Coil) which wasn’t part of normal operations
  3. Register write outside normal range — Writes to register addresses that the legitimate HMI never accesses
  4. Scan patterns — Sequential connection attempts to multiple Modbus unit IDs

Relevance to OT Security Careers

Network monitoring is the first line of defense in OT environments where you often cannot patch, cannot install endpoint agents, and cannot disrupt operations. This project demonstrates the ability to deploy and tune monitoring specifically for industrial environments — a skill set that’s directly applicable to roles in OT security operations, critical infrastructure protection, and ICS incident response.

Resources


Replace with your actual Zeek logs, Suricata alerts, Kibana dashboard screenshots, and detection findings.

← Threat Modelling a Water Treatment SCADA … Building an OT/ICS Home Lab with … →