This guide establishes continuous monitoring of CBS health and availability, providing the baseline needed to detect degraded performance that may indicate a cyber incident before it becomes a safety event. Monitoring must follow a passive-first approach — OT devices are not general-purpose computers and active probing carries real risk.
In the Identify Phase, we created the Asset Inventory. In this playbook, we turn that static list into an Active Watchlist. The goal is to know — in near real time — when any CBS goes silent, loses network presence, or behaves outside its established baseline.
Why Active Polling Requires Caution in OT Networks
Unlike IT systems, many OT devices — PLCs, IEDs, HMIs, alarm panels, legacy SCADA RTUs — were engineered for deterministic control traffic, not general network communication. Their TCP/IP stacks are often minimal implementations bolted onto real-time operating systems. This has two practical consequences:
Device Fragility
Certain PLCs and IEDs will fault, slow down, or reboot when subjected to unexpected ICMP traffic — especially from an IP they have never communicated with. This is documented behaviour with specific Siemens S7 generations and older Modbus/TCP stacks. Your monitoring station sending a ping is, from the device’s perspective, indistinguishable from a reconnaissance packet.
Baseline Pollution
Continuous active polling generates a steady synthetic traffic baseline. This makes real anomaly detection harder — your IDS or anomaly detection tool needs to be trained to ignore the poller, creating a blind spot that a sophisticated attacker can exploit. Passive monitoring avoids injecting this noise entirely.
IEC 62443 Principle: Zone-based security architecture (IEC 62443-3-3) and the monitoring guidance underpinning IACS UR E26 both favour passive observation as the primary method, with active probing reserved for scheduled maintenance windows and limited to protocol-native queries that the target device already expects to handle.
The Monitoring Hierarchy: Passive First
Availability monitoring for CBS should follow a defined priority order. Start at the top and only descend when the layer above is insufficient or unavailable for a given device type.
1
Passive Traffic Analysis (Primary Method)
Mirror OT switch traffic to a passive sensor (SPAN port or TAP). The sensor observes all conversations and detects when a device stops appearing in traffic. Zero packets are injected into the OT network. Commercial tools (Nozomi Networks, Claroty, Dragos Platform, OTbase) operate this way by default. Even a lightweight open-source option like Zeek on a TAP delivers passive presence detection with no device interaction.
✔ Safe for all device types — no polling, no injection, no fragility risk.
2
Protocol-Native Heartbeats
Where the vendor supports it, use the device’s own protocol keep-alive or status register as the availability signal. Examples: Modbus Function Code 43 (Read Device Identification), EtherNet/IP List Identity broadcast, Profinet DCP Identify, OPC-UA subscription keep-alives, or a known Modbus coil/register the controller already writes on every scan cycle. Reading a register the device already maintains is fundamentally different from injecting external ICMP — the device expects and handles it natively.
✔ Vendor-supported, protocol-correct, and safe. Confirm support in device documentation first.
3
Switch-Level Link State (SNMP Traps)
Configure managed OT switches (Hirschmann, Cisco IE, Moxa, Phoenix Contact FL Switch) to push linkDown SNMP traps to your monitoring station the instant a port loses physical connectivity. This detects cable disconnect, device power loss, and physical removal without sending a single packet to the device itself.
✔ Instant notification — no 60-second polling delay. No traffic to the end device.
4
ICMP Ping — Selective and Justified Use Only
ICMP ping is acceptable only for devices where layers 1–3 are unavailable and the vendor has confirmed the device handles ICMP without adverse effect. This typically means: IT/OT boundary devices (firewalls, DMZ servers, jump hosts), managed switches already handling SNMP, and ruggedised server-class HMIs running Windows or Linux. ICMP should never be the default choice for PLCs, IEDs, or legacy serial-gateway devices without explicit vendor approval.
⚠ Justify per device type. Document vendor confirmation. Do not apply blindly across the Asset Inventory.
What Modern OT Monitoring Agents Actually Do
Commercial OT security platforms (Nozomi Networks Guardian, Claroty Continuous Threat Detection, Dragos Platform, Radiflow iSID) are often marketed as “active monitoring” tools. In practice, their architecture precisely mirrors this hierarchy:
Passive by Default
All major platforms default to passive traffic mirroring. The sensor processes a copy of network traffic — no packets are sent to OT devices during normal operation. Device presence is inferred from observed traffic patterns.
Selective Active Queries
When additional device detail is needed (firmware version, module configuration), platforms use protocol-native queries — EtherNet/IP List Identity, Profinet DCP Identify, BACnet Read Property — not ICMP. Query rates are conservative and device-type-aware. Fragile PLCs can be individually excluded.
Maintenance-Window Scanning
Any deeper active enumeration (full asset fingerprinting, vulnerability scanning) is scheduled for defined maintenance windows — never run continuously during vessel operations. This is not a limitation of the tools; it is deliberate design aligned with IEC 62443 and IACS UR E26 principles.
For ETOs without a commercial platform: The same principles apply manually. A Zabbix or PRTG deployment on your OT monitoring VLAN should use SNMP traps from switches as the primary detection mechanism, protocol-native checks where the device supports them, and ICMP only as a last resort for confirmed-safe device types — not as the default template applied to every IP in the inventory.
Audit Evidence Preparation
When an auditor asks, “How do you know if a critical system has been tampered with or removed?”, provide the following:
Evidence Item
Description
Method
Availability Report
30-day presence log for Category III systems showing continuous network visibility.
Passive traffic analysis or SNMP trap log
Rogue Device Log
Alert history showing the monitoring system detected an unknown MAC address on the OT LAN and notified the ETO.
Passive MAC table monitoring from switch SNMP or mirrored traffic
Link-Down Event Log
Switch trap log showing every physical port event — timestamp, port ID, and associated asset from the inventory.
SNMP linkDown/linkUp traps from managed switches
Monitoring Scope Justification
Document showing which monitoring method was selected for each device type, and why — including vendor confirmation for any device subject to active polling.
Monitoring Config SOP (TAG-OT-SOP-04)
Approved MAC / IP Inventory Check
Detecting rogue devices without active scanning.
Rogue device detection should not require active network scanning. Instead, configure your managed OT switches to push MAC table changes via SNMP traps. Cross-reference new MAC addresses against your approved Asset Inventory automatically:
SNMP MAC Notification Traps: Most managed switches support mac-address-table notification change — enabling this pushes an alert every time a new MAC appears on the network.
Passive sensor correlation: If running a passive traffic sensor, it will identify new MAC/IP pairs automatically by observing traffic — no active query needed.
Monitoring tool MAC allowlisting: Zabbix, PRTG, and similar tools support MAC-based discovery filtering. Configure the known-good inventory list as the allowlist; anything outside it generates an alert.
“A device that appears on your OT switch that isn’t in your inventory is an incident — not a discovery.”
Compliance Documentation Previews
Standardized templates and technical logs. All fillable forms and SOPs are free with a registered account.
Follow these steps to establish the monitoring baseline for UR E26 compliance:
Step-by-Step Configuration
1. Define the Monitoring Scope and Method Per Device TypeList every Category III and Category II asset from the CBS inventory. For each device, assign a monitoring method (passive traffic, protocol-native, SNMP trap, ICMP) based on device type and vendor confirmation. Document the justification. Do not apply a single method uniformly across all devices.
2. Configure SNMP Link Traps on All Managed OT SwitchesEnable linkDown and linkUp SNMP traps on every managed switch in the OT LAN. Map switch port numbers to asset names from the inventory so that a link-down event generates a human-readable alert: “Port 5 — ECDIS Controller — link lost.”
3. Enable MAC Change Notification for Rogue Device DetectionConfigure managed switches to alert on new MAC addresses. Load the approved MAC list from the Asset Inventory into your monitoring tool as the allowlist. Any MAC not on the list triggers an immediate alert — this is rogue device detection without active scanning.
4. Set Up Protocol-Native Checks for Supported DevicesFor PLCs and controllers where the vendor documents support for keep-alive or status register polling, configure these as the primary availability check. Consult the device manual or vendor support to confirm safe polling intervals — typically no faster than 30 seconds, and only for registers the device writes continuously during normal operation.
5. Apply ICMP Only Where Justified and DocumentedFor boundary devices, firewalls, jump servers, and HMIs confirmed to handle ICMP safely: configure a polling interval of 60 seconds minimum, 5-second timeout, alert after 3 consecutive failures. Record the vendor confirmation or risk acceptance in the Monitoring Config SOP.
6. Establish the Monitoring Baseline and Test Alert DeliveryOnce configured, physically disconnect one non-critical device (during a port call, with permission) and verify the alert reaches the ETO within the expected timeframe. Log this test as evidence. The monitoring system is only as good as the last time it was validated.
The specific regulatory requirements this playbook satisfies. Use these references when preparing for Class survey or responding to a surveyor's checklist.
E26 §4.3
Detect functional element — Appropriate measures must be developed and implemented to detect and identify cyber incidents affecting computer-based systems and networks on board.
E27 §4.1
Required security capabilities (all CBSs) — All in-scope computer-based systems must implement 30 defined security capabilities covering: identity and authentication, access control, audit logging, malware protection, communication integrity, denial-of-service protection, backup and recovery.
