Part of the IDENTIFY Playbook ← Return to Hub

OT Traffic Baselining Procedures

Objective: Capture the “Normal” state of communication to create a blueprint for Firewall Rules (Conduits). This satisfies the IACS UR E26 requirement for verifying network traffic flows and justifying the “Cyber Security Design Description.”

1. The 72-Hour Observation Window

A baseline must cover multiple operational states. For a maritime audit, we recommend a 72-hour capture to include:

Maneuvering

High-frequency thruster control and DP traffic.

Steady State

Consistent navigation (GPS/AIS) and engine telemetry.

Cargo Ops

Pump control and automated valve sequences.

2. Implementation: Passive Capture

To maintain vessel safety, baselining must be passive. Active scanning during voyage can trigger safety-interlocks. Use the following three methods to ingest traffic without introducing latency or risk to the OT network.

A. SPAN / Mirroring

Configure the Managed Switch to duplicate traffic from “Member Ports” (PLCs/Sensors) to a “Destination Port” (Laptop/IDS).

  • Best for: Core switches with high CPU overhead.
  • Risk: Switch may drop mirror packets if CPU exceeds 80% during peak operations.
B. Physical Hardware TAP

Install a physical “Test Access Point” between the Bridge and the Core Switch. This ensures 100% visibility of full-duplex traffic.

  • Best for: Legacy hubs or unmanaged switches common in older engine rooms.
  • Risk: Requires a brief downtime for physical cable insertion.
C. Protocol Dissection

Analyze the PCAP (Packet Capture) files using Wireshark with maritime-specific filters (e.g., mbtcp or nmea_ip).

  • Goal: Identify source/destination pairs and packet frequency.
  • Outcome: This data becomes the “Evidence of Flow” for UR E26 audit compliance.

3. Design Verification (E26 4.2.1.4.1)

Per IACS UR E26, the Systems Integrator must prove that physical data flows match the approved Cyber Security Design Description.

Internal Zone Flows
  • Validate Intra-Zone Protocols
  • Verify Physical Port Mapping
  • Confirm “Least Functionality”
Conduit Flows (Cross-Zone)
  • Verify Zone Boundary Device
  • Match against Firewall ACLs
  • Document Purpose of Data Link
Untrusted Links (Satcom)
  • Identify Outbound Serial/IP
  • Verify Physical Segmentation
  • Block Unauthorized Telemetry

4. Anomaly Resolution Matrix

Observed Baseline Anomaly Maritime Risk Mitigation
Unmapped MAC Address
Device talking on OT but missing from Inventory.		 Isolate port; physical verification required to confirm it is not a “Shadow OT” device. Update Asset Inventory.
Unauthorized Bridge-to-Shore
Direct connection from Navigation VLAN to SATCOM.		 Immediate Firewall Block. Force all bridge-to-shore traffic through a secure Jump Host or DMZ.
PLC-to-PLC “New” Commands
Unusual write requests (Modbus 05/06) not seen in cruise.		 Review logic changes with OEM; ensure no unauthorized engineering software is connected to the OT network.
Multicast/Broadcast Flood
NMEA-0183/IP packets saturating the core switch.		 Implement IGMP Snooping and VLAN segregation to prevent safety-critical lag during maneuvering.

5. Formal Validation & Sign-off

A baseline is only an audit-valid “Target Profile” if reviewed. The following sign-off is required for the Ship Cyber Security Program:

  • Chief Engineer / ETO: Verification that all discovered traffic is operationally necessary.
  • Inventory Link: Confirm every talking IP/MAC has a corresponding entry in the Asset Master List.

Next Section

System Interdependency Matrix

System Interdependency Matrix UR E26 §3.2 (1) & §4.1: The 'Identify' functional element requires developing an underst...

Scroll to Top