OT Network Security Monitoring Guide: Passive Detection with Zeek ICS Parsers and Malcolm

Most controllers, RTUs and safety systems cannot run an endpoint agent or send useful logs, so the network is the only place an OT security team can reliably see an attacker change a setpoint or download a program. Passive network security monitoring (NSM) reads a copy of industrial traffic, decodes the protocols and flags behaviour that should not happen, without adding a single packet to the control network. This guide explains how to build that capability with free, government-backed tooling: Zeek with CISA's ICSNPP protocol parsers, the ACID indicator scripts, and the Malcolm analysis platform with its Hedgehog sensor. It covers sensor placement, which ICS events to alert on and how they map to ATT&CK for ICS, safe deployment, metrics, and when a commercial OT platform is the better choice. It is written for OT security engineers, SOC analysts taking on OT and control engineers who need to approve the design. Asset discovery is covered in the OT Asset Visibility Guide and general Zeek use in the Zeek Network Monitoring Guide; this page focuses on detection.

Key takeaways

• Passive monitoring is the primary OT detection layer. It works for devices that cannot log, adds no risk to the process, and sees engineering actions such as program downloads and mode changes as they cross the wire.
• Protocol depth matters more than packet volume. Default Zeek sees Modbus and DNP3; CISA's ICSNPP adds full parsers for S7comm, EtherNet/IP and CIP, BACnet, OPC UA Binary, Profinet IO CM and others, with logs down to function code and register.
• Alert on engineering actions first. Program download and upload, operating mode changes, parameter writes and new engineering peers are rare, high-value and easy to tie to change tickets.
• Malcolm packages the stack. CISA and Idaho National Laboratory publish it free as open source: Zeek, Suricata, Arkime, OpenSearch dashboards, file scanning and NetBox asset enrichment, with a Hedgehog Linux sensor for remote sites.
• The sensor is a sensitive asset. It holds full packet captures of the plant, including cleartext credentials in legacy protocols. Treat it as a Level 3 system with its own access control.

Why passive monitoring leads in OT

IT detection leans on endpoint agents and system logs. In OT, Level 0 to 2 devices (sensors, actuators, PLCs, RTUs, IEDs) mostly have neither, and those that do are often vendor locked against third-party software. The network, by contrast, carries every command that changes the process. Passive NSM therefore gives three things nothing else does:

• Process-level visibility: which station wrote which register or tag, which project was downloaded to which controller, and whether a controller was put into program or stop mode.
• Safety by design: a SPAN port or network tap copies traffic without injecting any, so it can run on networks where active scanning is forbidden.
• Evidence for response: stored packet captures and protocol logs let responders reconstruct what was sent to a controller, which matters when deciding whether logic must be restored. See the OT Incident Response Guide.

Its limits are equally clear: encrypted traffic shows only metadata, serial links need converters, and traffic that never crosses a monitored switch is invisible. Plan coverage with that in mind.

Sensor placement and capture

• SPAN or tap: SPAN is fast to configure but can drop packets when the switch is busy and can be changed by anyone with switch access. Passive or aggregating taps do not drop packets but may need a short outage to insert. Use taps on the links that carry controller traffic for your most critical units.
• Sensor at the edge, analysis in the middle: Malcolm's Hedgehog Linux is built to monitor interfaces, capture PCAP, extract and scan transferred files, and forward Zeek logs and Arkime sessions to a central Malcolm instance. From Malcolm v25.12.0 it is a preconfigured flavour of the Malcolm installer, which simplifies patching both.
• Bandwidth: at remote sites on thin links, forward Zeek logs and keep PCAP locally on the sensor for retrieval during an investigation.
• Sizing: Malcolm's documentation gives a minimum of 8 CPU cores and 24 GB RAM for a dedicated server, with 16 or more cores and 32 GB or more recommended; storage decides how many days of PCAP you can keep.
• Time: sync sensors to the same time source as the plant historian so events line up during response.

The open toolchain: Zeek, ICSNPP, ACID and Malcolm

Logs that matter most in OT (names from the ICSNPP repositories):

• Modbus: modbus.log from Zeek, plus modbus_detailed.log (function, addresses and values), modbus_mask_write_register.log (function code 0x16), modbus_read_write_multiple_registers.log (0x17) and modbus_read_device_identification.log. Non-standard ports can be added in local.zeek.
• Siemens S7: cotp.log, s7comm.log, s7comm_read_szl.log, s7comm_upload_download.log and s7comm_plus.log. Upload and download logs are the record of program transfers.
• EtherNet/IP and CIP: enip.log, cip.log, cip_io.log and cip_identity.log. Identity logs give vendor, product and revision passively.
• DNP3: dnp3.log from Zeek, plus dnp3_control.log for control relay output block commands in select and operate sequences, and dnp3_objects.log. The ICSNPP readme notes that detailed logging covers 6 of the 30 data-carrying DNP3 functions, so do not assume full coverage.

What to detect: ICS behaviours mapped to ATT&CK for ICS

ACID's indicators were derived from traffic in controlled testing, so treat them as starting points to tune, not as a complete rule set. Malcolm adds severity scoring on Zeek logs (cross-segment traffic, cleartext passwords, insecure or outdated protocols, file transfers, long connections) recorded in event.severity and event.severity_tags, which helps triage before custom rules exist. In D3FEND terms this is D3-NTA Network Traffic Analysis, with D3-NTCD Network Traffic Community Deviation for baseline alerts and D3-NTSA Network Traffic Signature Analysis for Suricata rules.

Baselines and allowlists

OT traffic is repetitive, which makes allowlist detection practical in a way it rarely is in IT:

1. Record a baseline for two to four weeks per zone, including a planned maintenance window so legitimate engineering traffic is captured.
2. Build the communication matrix: source, destination, protocol, function codes used. This is also the evidence for conduit rules under IEC 62443; see the OT Network Segmentation, Purdue Model and IEC 62443 Zones and Conduits Guide.
3. Load the asset inventory into NetBox: Malcolm's Zeek Known Summary and Asset Interaction Analysis dashboards then show uninventoried hosts and services observed on the wire. Malcolm's documentation warns against letting it auto-populate NetBox from traffic without care, because a misconfiguration would then become the documented state.
4. Alert on deviation: new peers, new function codes (for example a first write after months of reads), new protocols in a zone, and engineering protocols from non-engineering hosts.
5. Re-baseline after approved changes through the change process, not by silently accepting new traffic.

Deploying it safely

1. Design review with control engineering: agree capture points, how taps are inserted, and that sensors are receive-only on capture interfaces.
2. Pilot one zone (weeks 1 to 4): deploy one Hedgehog sensor on a SPAN, forward to a lab Malcolm instance, and check parser coverage against the protocols you expect.
3. Tune (weeks 4 to 8): enable ACID notices, write allowlist rules, and agree with operations which alerts page someone and which go to a daily review.
4. Expand by criticality: add taps on critical unit links, the DMZ and remote access paths, then remaining sites.
5. Integrate: forward notices and high-severity events to the SOC SIEM with the asset context attached. See the SIEM Guide.
6. Rollback: a passive sensor can be disconnected at any time without process impact; removing a tap needs the same outage planning as inserting it.

Data handling: PCAP from OT contains process values, recipes and, for legacy protocols such as Telnet, FTP and some HMI protocols, cleartext credentials. Restrict Malcolm access through its authentication (it bundles Keycloak and supports LDAP), encrypt forwarding between Hedgehog and Malcolm, set retention by policy, and keep the platform inside the OT security zone rather than on the corporate network.

Where identity fits

Passive monitoring is one of the few ways to see OT identity in use. Zeek's Kerberos, NTLM, SMB, RDP and SSH logs show which accounts move between Level 3 hosts; ICS protocol logs show which stations act as engineering clients. Use this to find shared engineering accounts used from many hosts, vendor accounts active outside their window, service accounts for historians and OPC servers logging on interactively, and cleartext credentials flagged by Malcolm's severity scoring. Feed findings into account clean-up as described in the Identity for OT Environments Guide. Remember the reverse risk: an attacker who reaches a monitoring sensor gains a passive view of every credential on the wire, which ATT&CK for ICS tracks as T0842 Network Sniffing.

Open source or commercial OT platform

Many organisations run both: a commercial platform for fleet-wide coverage and Malcolm as a response and hunting tool. See the OT Security Platform Buyer's Guide.

Metrics that show it is working

• Coverage: percentage of critical zones and conduits with a working capture point, and percentage of inventoried Level 1 and 2 assets seen on the wire in the last 30 days.
• Parser coverage: percentage of observed OT traffic (by bytes or sessions) decoded by a protocol parser rather than seen only as TCP or UDP.
• Change correlation: percentage of program downloads and mode changes matched to an approved change ticket within 24 hours.
• Unknowns: count of uninventoried hosts and services seen per month, trending down.
• Sensor health: capture drop rate and hours of sensor outage per month.
• Response: median time from an engineering-action alert to operations confirmation.

Framework mapping

NIST SP 800-82 Rev. 3 treats security monitoring as part of the OT security architecture; in IEC 62443-3-3 terms this supports FR 6, timely response to events. See the NIST SP 800-82 OT Security Guide and the MITRE ATT&CK for ICS Guide.

Common failure patterns

• Boundary-only sensors: a sensor on the IT/OT firewall sees north-south traffic but none of the controller writes that matter.
• No protocol parsers: running Zeek without ICSNPP on a network of S7 or CIP devices produces connection logs and little else.
• Alerting on everything: turning on every severity category without a baseline floods the SOC; start with engineering actions and unknown hosts.
• No link to change management: program download alerts that nobody can match to a ticket get ignored within weeks.
• An unprotected sensor: a monitoring server with default credentials and full PCAP becomes the best reconnaissance asset an attacker could find.
• Dropped packets unnoticed: SPAN oversubscription during peak load silently removes the traffic you most need. Monitor drop counters.

Practitioner checklist

• Map capture points to Level 1 and 2 aggregation, the DMZ, remote access and safety networks.
• Use taps on critical unit links and monitor SPAN drop rates elsewhere.
• Install ICSNPP parsers for every OT protocol in use and confirm parser coverage.
• Enable ACID notices and tune them against a two to four week baseline.
• Alert on program download and upload, mode changes and writes from non-allowlisted hosts.
• Load the asset inventory into NetBox and review uninventoried hosts monthly.
• Match every engineering-action alert to a change ticket and track the rate.
• Restrict access to sensors and PCAP, encrypt forwarding and set retention.
• Forward high-value notices to the SIEM with asset and zone context.
• Exercise the PCAP retrieval and analysis path as part of OT incident drills.

Standards and references

• CISA: Industrial Control Systems Network Protocol Parsers (ICSNPP)
• CISA: Malcolm network traffic analysis tool suite
• CISA: Malcolm
• CISA and MITRE: ATT&CK-based Control-system Indicator Detection (ACID)
• NIST: SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security
• MITRE ATT&CK for ICS: Program Download
• MITRE D3FEND: Network Traffic Analysis
• NIST: Cybersecurity Framework 2.0

Related NHI Mgmt Group resources: OT Asset Visibility Guide · Zeek Network Monitoring Guide · NDR Guide · OT Security Guide