Ship-to-Shore Security Monitoring with Maritime SIEM

Why Maritime Monitoring Is Genuinely Hard

Security monitoring in an enterprise assumes cheap, always-on connectivity, log sources that speak well-understood protocols, and a SOC that receives events within seconds. A vessel breaks all three assumptions. Connectivity is satellite-based: intermittent, latency-heavy, metered by the megabyte and sometimes lost entirely in certain sea areas. The log sources include bridge and engine operational technology that speaks NMEA 0183, IEC 61162 and proprietary equipment protocols that no off-the-shelf SIEM parses out of the box. And the SOC may be thousands of nautical miles from the asset it is supposed to watch.

These constraints do not make monitoring impossible, but they make naive monitoring fail expensively. An operator who simply points a vessel's log forwarder at a shore SIEM will either blow the satcom budget streaming raw logs or starve the SOC by sending almost nothing. The right answer is an architecture designed around the constraint, not in spite of it.

There is also a regulatory driver. The IMO framework, through MSC-FAL.1/Circ.3, lists detect as one of the five functions a fleet must address. A flag state or class auditor reviewing the detect function wants to see that the fleet can actually notice an anomaly on a vessel, not just that the policy mentions monitoring. A working maritime SIEM is the most credible evidence of the detect function.

The Ship-to-Shore SIEM Architecture

A maritime SIEM is a tiered system. The defining design choice is to push collection and first-pass triage onto the vessel, and forward to shore only what justifies the satcom cost. This keeps monitoring continuous even when the link is down, and keeps the data bill predictable.

The reference architecture has four tiers that work together:

• On-vessel collection: a hardened collector appliance or VM that ingests logs from bridge OT, engine OT, vessel IT, firewalls, satcom terminals and crew network access points
• On-vessel triage: local rules that classify events, suppress noise, and raise high-priority alerts immediately even on a degraded link
• Store-and-forward: a buffered, compressed, prioritised forwarding layer that sends critical alerts first, batches routine data for off-peak transmission, and survives link loss without dropping events
• Shore-side SIEM and SOC: the central platform that correlates across the whole fleet, runs deeper analytics, holds the long-term log store and drives the analyst workflow

Vessel Log Sources and Maritime Parsers

The value of any SIEM is bounded by the quality of its log sources, and a vessel has sources that no generic deployment understands. A maritime SIEM must be built to parse and normalise the data a ship actually produces.

The core sources are: bridge OT traffic (NMEA 0183 sentences, IEC 61162-450 multicast on the bridge Ethernet, ECDIS and ARPA system logs where exposed), engine and machinery systems (alarm and monitoring system logs, automation controller events), satcom terminal logs (authentication, configuration changes, firmware events, outbound connection records), vessel IT (workstation and server logs, planned maintenance system activity), network infrastructure (firewall allow and deny logs at zone boundaries, switch and router events), and the crew network (access point associations, captive portal events).

Each of these needs a parser that understands its format and a normalisation step that maps it into a common schema so that shore-side correlation can reason across them. NMEA and IEC 61162 in particular are not in any standard SIEM content pack; the value of a maritime-specific SIEM is precisely that someone has done this parsing and built the maritime context. Without it, the bridge OT data is an unreadable stream that the SOC cannot act on.

Detection Use Cases That Matter at Sea

Raw collection is not monitoring. Monitoring is a curated set of detection use cases tuned to the maritime threat picture, each with a defined response. A handful of well-built use cases delivers more than terabytes of unwatched logs.

High-value maritime detection use cases include the following, each phrased as a question the SIEM answers continuously:

• GNSS anomaly: own-ship position jumps inconsistent with speed and heading, or position freezes, suggesting spoofing or jamming
• New device on a protected zone: a previously unseen MAC or device appears on the bridge or engine network
• Vendor access outside the change window: a remote diagnostic session starts when no approved change is scheduled
• Satcom management anomaly: configuration change, firmware downgrade, or authentication burst on the satcom terminal
• Cross-zone traffic: traffic crossing a segmentation boundary that policy says should be blocked, especially crew network reaching IT or OT
• Removable media event: a USB mass-storage device mounted on an ECDIS or engineering workstation
• Authentication anomaly: brute-force patterns or off-hours logins on vessel IT or shore-integrated systems

Working Within the Satcom Budget

Bandwidth discipline is the difference between a maritime SIEM that the fleet keeps running and one the commercial team switches off after the first data bill. The design principle is simple to state and demanding to engineer: spend satcom only on data that earns its cost.

The techniques that make this work: triage on board so only classified events leave the vessel; prioritise the forwarding queue so critical alerts go first and bulk logs follow in off-peak windows; compress aggressively because log data compresses extremely well; sample or summarise high-volume low-value sources rather than streaming every line; and store the full fidelity log on board for a defined retention period so that, if an incident is confirmed, the SOC can pull the complete record on demand rather than paying to stream it speculatively.

Coastal links change the calculus. When a vessel is within range of a cheaper 4G or 5G connection in port or near shore, the maritime SIEM can opportunistically flush its buffered backlog and pull richer telemetry. A good design is link-aware: it knows when bandwidth is cheap and behaves differently. This opportunistic flushing means the shore SOC gets near-complete fidelity for the periods the vessel spends in coastal waters, with priority-only coverage on the expensive open-ocean legs.

Correlating Across the Fleet at Shore

The shore-side tier is where individual vessel events become fleet intelligence. A single new-device alert on one ship is a vessel-level event. The same alert appearing across five vessels managed from the same office within a week is a fleet-level signal that may indicate a common vendor compromise, a shared misconfiguration, or a coordinated campaign. Only the shore SIEM, correlating across hulls, can see that pattern.

The shore platform also holds the long-term log store for forensics and audit, runs the analyst workflow (alert triage, case management, escalation to the vessel and the company crisis team), and produces the evidence that the IMO detect function actually operates. For a flag state or class audit, the ability to show a dated, fleet-wide alert and response history is far stronger evidence than any policy paragraph.

Codesecure designs and helps operate ship-to-shore maritime SIEM deployments: selecting and hardening the on-vessel collector, building the maritime parsers and detection use cases, engineering the bandwidth-disciplined forwarding, and standing up the shore SIEM and SOC workflow. The result is monitoring that an auditor recognises and a finance director tolerates, which is the only kind that lasts.