📋 Compliance
IACS UR E26/E27
Ship OT Monitoring
3-Part Series · Part 2
Ship OT Monitoring for IACS E26/E27: Required Functions, Scope, and Protocols
Ship OT Cybersecurity — A Practitioner's Guide for Vessel Operators
Captain Paul (In Sung Lee)
Maritime Cybersecurity Consultant · CRSI Specialist
In Part 1, we covered the regulatory structure of IACS E26 and E27 — the CBS inventory, Zone/Conduit model, Security Levels, and Type Approval process. That framework tells you what the rules require. This post addresses what you actually need to deploy on board to meet those requirements in practice. The market is full of vendors claiming "E26/E27 compliant." That phrase means almost nothing without specifics — compliance is not a feature, it is an outcome.
Ⅰ. Why OT Monitoring Is Different From IT Security
Shipboard OT monitoring is not enterprise IT security deployed at sea. The differences are fundamental:
Real-Time
OT systems operate with deterministic timing requirements. An active network scan routine in IT can crash a PLC or trigger a spurious alarm on a vessel control system.
Protocols
Legacy protocols like Modbus and NMEA 0183 have no built-in authentication — designed for reliability in isolated environments, not security in connected ones.
Lifecycle
Many shipboard CBS have operational lifespans of 15–25 years and cannot be patched on the same cycle as office software.
Core Architectural Principle
Passive-first. The monitoring solution must achieve full network visibility through traffic capture (SPAN ports or network TAPs) — without injecting any active queries into the OT network. Active scanning is a last resort, used only in controlled maintenance windows with explicit authorization.
Ⅱ. The Three Monitoring Zones
Following the Zone model established by E26, monitoring scope must span three distinct layers — each with different characteristics, protocols, and risk profiles.
OT ZONE · L0–1
Field Layer
PLCs, DCS, sensors — any compromise here has direct safety consequences. Monitoring detects unauthorized command writes, abnormal polling patterns, and communications from devices not in the approved CBS inventory.
Key constraint: you cannot place a monitoring agent directly on most L0–1 devices. Monitoring is exclusively network-based via aggregation points or protocol converters.
CONTROL ZONE · L2
Supervisory Layer
ECDIS, VDR, AMS, SCADA, HMI — run Windows or Linux, communicate over TCP/IP, and are the most common entry points for cyber attacks. Monitoring combines network traffic analysis with host-based telemetry (Windows Event Logs, application audit trails, OPC-UA session monitoring). Traffic crossing either boundary must be validated against the approved Conduit policy.
IT / ADMIN · L3
Connectivity Layer
Crew internet, VSAT, shore-to-ship remote access gateways — where external threats enter the vessel. E26 requires: all remote access sessions must be logged with sufficient detail to reconstruct what was accessed and what actions were taken.
Ⅲ. The Eight Functions Your Solution Must Deliver
Mapping to the E26 five-function framework, an effective ship OT monitoring solution must deliver the following capabilities:
1
Asset Inventory and Change Detection
Live inventory of all CBS (IP, MAC, firmware, open ports) with alerts on any deviation from the approved baseline — new device, firmware version change, or previously closed port becoming open. Becomes the technical ground truth measured against during Annual Survey.
2
Network Topology Visualization
Continuously updated topology map showing all CBS, zone assignments, and communication paths. A solution that can automatically show approved topology vs. current state converts a manual, time-consuming Survey process into a structured evidence package.
3
OT Protocol Deep Packet Inspection
Decode and inspect OT protocol content at the application layer — not just detect traffic on a port, but understand what commands are issued, to which devices, and whether they fall within normal operational parameters. Without this, the E26 Detect function cannot be fulfilled at a meaningful level.
4
Anomaly and Intrusion Detection
Baseline modeling of normal communication patterns, process values, and polling rates on the specific vessel. A Modbus write to a normally read-only register is suspicious even if the protocol is expected. A GPS position jump of 50 NM in 30 seconds is a spoofing indicator even if the NMEA sentence is syntactically valid.
5
Log Collection and SIEM Integration
All security-relevant events captured, timestamped, and stored in tamper-evident manner. Log retention must cover at least 12 months (survey interval). For shore SOC integration: syslog/CEF/LEEF forwarding with bandwidth management to avoid impacting operational communications.
6
Vulnerability and Patch Status Tracking
Track patch status of all CBS against known vulnerability databases with current CVE identifiers and risk ratings. For SBOM-capable vessels, ingest SBOM data and cross-reference component versions against vulnerability feeds. The Surveyor will ask: what vulnerabilities are known, remediation status, and compensating controls.
7
Remote Access Session Monitoring
Capture session initiation, authentication events, commands/actions executed, and session termination — with forensic reconstruction capability. Covers all access vectors: VPN tunnels, jump servers, vendor satellite connections, and any remote desktop or industrial remote access tools in use.
8
Compliance Reporting and Evidence Packaging
Generate structured compliance reports mapped to specific E26/E27 requirements — not generic security dashboards, but evidence packages organized around the survey checklist. This converts OT monitoring from an operational tool into a compliance asset.
Ⅳ. OT Protocol Coverage: The Technical Requirement
Essential — Required for E26/E27 Survey Evidence
NMEA
NMEA 0183 / NMEA 2000 — Navigation data (GPS, AIS, heading, speed, depth). Must detect anomalous position jumps (spoofing), unusual PGN injection, and unexpected talker identifiers.
MODBUS
Modbus TCP / Modbus RTU — Most widely deployed in shipboard OT. Deep inspection must cover Function Code analysis — writes to normally read-only registers, and diagnostic/special function codes outside maintenance windows.
DNP3
DNP3 — Power generation and electrical distribution. Must detect unsolicited response floods, authentication failures, and direct control commands not from the authorized master station.
IEC 61850
IEC 61850 (GOOSE / MMS) — Modern power distribution and protection. GOOSE message flooding is a known attack vector against protection relays. Must validate StNum sequences and detect unexpected GOOSE publishers.
SATCOM
VSAT / SATCOM IP Traffic — The external attack surface. All traffic transiting the satellite link must be inspected for C2 patterns, unauthorized outbound connections, and data exfiltration indicators.
Recommended — Risk-Based Application
OPC-UA
OPC-UA — Integration layer between L2 control systems. Cover session authentication, certificate validity, and unauthorized node browsing or subscription requests.
S7 / EIP
S7comm / EtherNet/IP — Siemens and Rockwell Allen-Bradley respectively. Both have documented attack tools (Metasploit modules, PLCScan) that generate distinctive traffic patterns requiring deep inspection.
PROFINET
PROFINET / PROFIBUS — Common in European-built vessels with Siemens or ABB automation. Must detect device impersonation and unexpected DCP broadcasts.
Selective — Vessel Type Dependent
BACnet
BACnet — Vessels with building automation (HVAC, accommodation). Not safety-critical, but compromise has been used as a lateral movement vector in shore-based OT incidents.
CAN/J1939
CANbus / J1939 — Smaller vessels and engine ECU networks. Monitoring typically requires a dedicated gateway device rather than direct network capture.
Ⅴ. The Connectivity Reality: Two Different Operating Environments
The architectural requirements for ship OT monitoring differ significantly depending on the vessel's satellite connectivity environment. These are not the same design problem — and solutions must address both cases explicitly.
📡 Traditional VSAT Vessels
Connectivity measured in hours per day at bandwidths that preclude real-time log streaming to a shore SOC.
- ▸Fully capable onboard analysis engine required — detection must run locally without cloud dependency
- ▸Shore sync during port calls or scheduled windows with bandwidth management
- ▸Log buffering with integrity protection for up to 30+ days offline
🛰 Starlink-Equipped Vessels
Near-continuous broadband connectivity (100–200+ Mbps) enables architectures previously impossible at sea.
- ▸Real-time log streaming to shore SOC becomes viable
- ▸Continuous threat intelligence feed updates and cloud-assisted detection
- ▸Remote analyst access for live incident response while at sea
However, Starlink connectivity introduces its own risk surface. Always-on broadband expands the attack window — a vessel that was previously unreachable during deep-sea transits is now continuously exposed. This makes robust OT monitoring more critical, not less. The monitoring scope must now explicitly cover the Starlink terminal itself as a network boundary device within the IT/Administrative Zone.
The design principle remains the same regardless of connectivity: the onboard analysis engine must be capable of operating independently. Starlink enhances what is possible — it does not eliminate the need for local detection capability. Reliance on shore connectivity for core detection functions is an architectural vulnerability, not a feature.
Ⅵ. Selecting a Solution: The Questions That Matter
The questions that distinguish capable solutions from marketing claims:
-
Can you demonstrate passive-only monitoring with zero active queries to the OT network?
-
Which OT protocols do you decode at the application layer — can you show the parser logic for NMEA 2000 and IEC 61850 GOOSE?
-
How does the solution operate during satellite link outage — what functions degrade and what remains available?
-
Can it generate an Annual Survey evidence package mapped to E26/E27 clauses — not generic compliance reports?
-
Does the solution hold Type Approval from any Classification Society, and if so, at what Security Level?
As Classification Societies mature their E26/E27 assessment processes, the monitoring solution itself becomes subject to scrutiny — not just the data it produces.
📚 Series Navigation — 4 Parts
#IACS_E26
#IACS_E27
#OTMonitoring
#ShipCybersecurity
#PassiveMonitoring
#Modbus
#NMEA
#IEC61850
#DNP3
#Maritime40
Captain Paul
Maritime Cybersecurity Consultant · CRSI Specialist
Captain Paul is the editorial voice of ShipPaulJobs — an independent Maritime Industry 4.0 platform for shipbuilding and maritime professionals. Views expressed are based on independent consulting practice and do not represent any Classification Society or vendor position.
Comments
Post a Comment