Vessel Penetration Testing: Ship Network Assessment

Why Vessel Penetration Testing Is a Distinct Discipline

A vessel built or retrofitted in the last decade is an operational technology environment that happens to float. The bridge alone hosts ECDIS workstations, ARPA radar, an AIS transceiver, GMDSS terminals, a multi-GNSS receiver, gyrocompass, voyage data recorder, autopilot and integrated bridge displays. Behind the bridge sit engine monitoring and alarm systems, machinery automation, cargo control on tankers and gas carriers, ballast water treatment and shore-connected planned-maintenance systems. Almost all of these are networked, almost all run Windows or embedded Linux underneath, and almost none were designed for a hostile internet.

A vessel penetration test therefore brings together several disciplines that are usually scoped as separate engagements: enterprise IT pentest for the ship office, OT pentest for the bridge and engine systems, wireless pentest for crew WiFi, network pentest for the vessel LAN, and supply-chain review of the chart, satcom and maintenance vendors. Treating them as one coherent engagement is how the resulting report can satisfy IMO cyber expectations, BIMCO guidance and the flag state in a single document.

The defining constraint is safety. A web application pentest can fuzz a login form. A vessel OT pentest cannot fuzz a propulsion alarm, an autopilot loop or a cargo control valve while the vessel is operational. The methodology is built around what is safe to do when, which usually means passive observation at sea plus deeper active testing during a port stay or in dock.

Scope Definition and Rules of Engagement

Scoping is the most important hour of the engagement. Customers usually arrive with one of three positions: test everything, test the vessel only, or test the IT only. None is precise enough. The rules of engagement must enumerate each environment and each permitted test method per environment, with explicit go and no-go conditions tied to the vessel's operational state.

Our standard model covers five environments and three test depths each. The three depths are passive observation (capture and review only), active non-disruptive (low-rate discovery, read-only configuration review, no writes to OT), and active intrusive (exploitation attempts, reserved for IT and crew networks or for OT only in dry dock with the vendor present).

• Bridge OT: ECDIS, AIS, GMDSS, GNSS, ARPA, autopilot, VDR. Passive at sea, active non-disruptive at port, intrusive only in dock
• Engine and machinery OT: monitoring, alarms, automation, cargo and ballast control. Passive at sea, active non-disruptive at port
• Vessel IT: ship office workstations, planned maintenance system, document management. Standard pentest depth
• Crew network: welfare WiFi, BYOD segment, captive portal. Standard wireless pentest depth
• Satcom and remote access: VSAT terminal, 4G/5G failover, vendor diagnostic paths. Configuration and exposure review, controlled active testing

Mapping the Real Vessel Network Topology

Once on board, the first task is mapping the network as it actually exists, not as the network drawing claims. Real vessel networks drift over their service life as vendors add equipment, technicians patch in temporary links, and crew devices appear on segments they were never meant to reach. We begin with passive observation using a SPAN or mirror port where available, capturing on the bridge LAN, the satcom segment, the engine room network and the crew network.

The capture reveals every device that talks, every protocol in use, every vendor remote diagnostic session, and every cross-zone path the firewall is supposed to be blocking. On bridge networks this typically surfaces IEC 61162-450 multicast traffic, NMEA 0183 over Ethernet, and the chatter between ECDIS, radar and the position source. On engine and cargo networks it often surfaces Modbus and proprietary automation protocols that should never be reachable from anywhere outside their zone.

Active discovery follows only where it is safe. We use constrained host discovery with low packet rates and no aggressive service probing against OT-bearing hosts, targeted protocol checks, and configuration walk-throughs of every accessible switch, router and firewall. The output is a corrected network diagram, a complete asset inventory with vendor and version, and a list of every cross-zone path showing both the intended policy and the actual observed traffic.

Testing Bridge and Engine OT Safely

Bridge and engine OT is where the safety-first discipline earns its keep. For ECDIS we examine the chart update workflow, the integrity verification chain for ENC files, the USB media handling, the underlying operating system patch state, and the segregation of the ECDIS workstation from crew and vendor networks. We do not inject tampered charts on a live system. Where the customer wants update-integrity validation demonstrated, it is done on a spare or shore-based unit, never on the navigating ECDIS.

For the position source we look at how GNSS feeds ECDIS, radar and AIS, and whether the bridge team has briefed and drilled cross-checking against radar fixes, visual bearings and dead reckoning. GNSS spoofing is now common in several geographies, and a vessel that depends on a single uncrossed position source is exposed regardless of its network controls.

For engine and machinery OT we work alongside the chief engineer. We review the segmentation between the automation network and everything else, the remote diagnostic access used by engine and equipment vendors, the credential hygiene on the alarm and monitoring systems, and the exposure of any Modbus or proprietary control protocols. Testing is read-only against live machinery. Anything that could perturb an alarm, a setpoint or a control loop is deferred to dock with the vendor present and the plant in a safe state.

Satcom Exposure and Crew WiFi: The Common Entry Points

The satcom terminal is the dominant remote-access route to a vessel. Modern VSAT and L-band terminals are general-purpose computers with a web management interface, default credentials documented in vendor manuals, and connectivity back to the ship LAN. We check for retained default credentials, exposed management interfaces, firmware versions against current vendor advisories, and whether the terminal sits in its own restricted segment or shares trust with the rest of the vessel. Many shipowners cannot say which firmware version runs on which vessel, so building that inventory is itself a deliverable.

Crew welfare WiFi is the single most-exploited vessel attack path we see. The crew network is by design lower-trust than the ship office or the bridge, but if it shares a physical switch with no VLAN separation, if the captive portal logic can be bypassed, or if the access points expose management to the crew segment, then a crew device or a visitor can pivot into higher-trust zones. Standard tests enumerate from a crew-network position and attempt to reach the ship office subnet, the bridge OT subnet and the satcom management interface, and attempt captive-portal bypass through DNS tunnelling, MAC spoofing and similar techniques.

These findings are usually straightforward to remediate, through proper VLAN separation, firewall enforcement between zones, access-point management isolation and changed default credentials, and difficult to argue against once demonstrated. A different SSID is not network separation. VLAN tagging plus firewall enforcement is the actual control.

Aligning Findings to IEC 62443 and IMO Expectations

Raw findings are more useful when they are mapped to the frameworks the customer is judged against. We structure the vessel network into IEC 62443 zones and conduits, with bridge OT in the most restrictive zone, engine OT in its own zone, cargo OT where present in another, vessel IT separated, and the crew network as the least trusted. Each segmentation gap becomes a conduit finding with a clear target state, which makes the remediation roadmap concrete rather than abstract.

On the regulatory side, IMO Resolution MSC.428(98) requires cyber risk to be addressed within the ship Safety Management System, and the operational guidance in MSC-FAL.1/Circ.3 frames this around Identify, Protect, Detect, Respond and Recover. A vessel pentest provides direct evidence for the Identify and Protect functions and informs the Detect function. We map each finding to these functional elements so the report doubles as risk-assessment evidence the flag state and class society expect to see.

For newbuild and significantly retrofitted tonnage delivered from mid-2024, the IACS Unified Requirements E26 and E27 add design-stage cyber expectations for ships and onboard equipment. In-service vessels are not directly bound by them, but applying the same segmentation and secure-update principles operationally is the pragmatic path, and our recommendations are written to be consistent with that direction of travel.

Reporting for Flag State, Class, P&I and Charterer

A vessel penetration test report must serve several audiences at once. The flag state and class society want cyber risk-assessment evidence mapped to the IMO functional elements and BIMCO control areas. The P&I club and hull insurer want a risk posture statement that informs premium and excess. The charterer wants answers that close their security questionnaire. The internal IT team and the designated person ashore want the technical detail with prioritised remediation.

Our reports therefore carry two parallel severity views. CVSS v3.1 with environmental modifiers gives the standard technical risk number. Alongside it sits a maritime-specific overlay that labels each finding Safety-Impacting, Operations-Impacting or IT-Only, so the master and the chief engineer can read the report as easily as the CISO. Each finding maps to the IMO Identify-Protect-Detect-Respond-Recover elements, to BIMCO control areas, to IEC 62443 zones and conduits, and to ISO/IEC 27001:2022 Annex A controls where relevant.

Remediation is sequenced by a mix of safety impact and effort, so the vessel and the shore office can close the highest-risk, lowest-effort items first, often within a single port stay. A free re-test within 90 days confirms closure and gives the customer clean evidence to hand to the next auditor or charterer.