Smart Marine Consultant (4/4): Cyber Threats I've Actually Stood in Front of
Why This Post Exists
Most maritime cybersecurity content describes threats in the abstract. Attack vectors. Threat actor categories. MITRE ATT&CK frameworks adapted for OT environments.
That content is useful. It is not sufficient.
What changes how you think about vessel security is standing in front of a real incident — or a near-miss — and understanding exactly how it happened, what the exposure was, and what would have prevented it.
This is a record of threat patterns I have observed directly or investigated in the course of my work. Vessel identities, operators, and specific technical details have been anonymized or generalized. The threat patterns are real. IACS UR E26/E27 references are included where the regulation directly addresses the vulnerability — and where it doesn't.
A vessel's engine monitoring system required remote access from the manufacturer for a scheduled diagnostic. The manufacturer connected via the ship's VSAT link, ran the diagnostic, and left the session open — not maliciously, not intentionally. The technician finished the task, closed the application on their end, and moved on.
The session remained active on the vessel side for eleven days. During that window, the remote access path was visible on the network. It was not exploited in this case. In another case, under similar conditions, it would be.
UR E26 requires that remote access to onboard systems be controlled, logged, and terminated when no longer required. UR E27 requires that individual systems have documented remote access procedures.
A general policy statement that remote access must be authorized. No automated session timeout. No monitoring capability that would have detected an open session. No process for verifying session closure after vendor work.
Automated session timeout enforced at the network boundary. A post-maintenance checklist that includes remote access session verification. An OT monitoring system with visibility into active connections.
Remote access is how equipment manufacturers provide warranty support, how service engineers diagnose faults, and how software updates are delivered. On a vessel with fifteen to twenty CBS vendors, each with their own remote access path, the management of those sessions is a full-time operational task — and it is rarely treated as one.
A port call. A service engineer from a navigation equipment supplier arrives to perform a software update on the ECDIS. Standard procedure. The engineer connects a USB drive to the ECDIS terminal. The update runs. The engineer leaves.
Three weeks later, the vessel's IT administrator notices unusual outbound traffic on the network during port calls. Investigation traces it to a process running on the ECDIS that was not part of the original software.
The USB drive had been used on multiple vessels and multiple shore-side systems before arriving on this vessel. The malware was opportunistic — designed to establish persistence on whatever system it landed on.
UR E27 requires that removable media used for software updates be controlled and verified. UR E26 requires that change management procedures cover software updates to CBS.
A policy that software updates must come from approved sources. No technical control preventing USB connection. No malware scanning capability on the ECDIS itself. No network monitoring that would have detected the malware's initial execution.
A removable media control policy with technical enforcement — disabling USB ports on CBS terminals or requiring media to be scanned on an isolated system before use. A software integrity verification process for all updates, whether delivered by USB or remote access.
ECDIS and other bridge systems are often treated as closed, standalone systems. They are not. They receive software updates. They connect to chart update services. On modern vessels, they integrate with vessel performance monitoring platforms. Each of those connections is a potential entry point — and the systems themselves often have minimal endpoint security because they were designed for reliability, not security.
A shipowner's technical superintendent was reviewing a vessel's network during a dry dock. The original security zone diagram showed clean segmentation: navigation systems isolated from machinery systems, both isolated from the crew welfare network.
The network scan told a different story. Navigation and machinery systems were on the same subnet. The crew welfare network — which crew members connected personal devices to — had a path to the vessel management system through a misconfigured switch. No incident had occurred. The exposure had existed for four years.
This vessel predated the July 2024 mandatory application of UR E26/E27. IMO MSC.428(98) required cyber risk management in the SMS, but did not mandate specific technical architecture. The flat network was legal, compliant with all applicable regulations, and a significant operational risk.
The dry dock provided an opportunity for network remediation. The switch configuration was corrected. A basic network monitoring capability was deployed. The security zone diagram was updated to reflect reality — for the first time since the vessel was delivered.
This vessel was one of dozens in the same fleet, all built to the same design, all with the same network architecture. The dry dock audit was not fleet policy — it was the initiative of one technical superintendent who had attended a cybersecurity seminar six months earlier. The rest of the fleet continues to operate with the same exposure.
A vessel's power management system — controlling load distribution across the vessel's generators — was running on an operating system version that had reached end-of-life three years prior. The OS vendor no longer issued security patches. The equipment manufacturer had not released an updated version compatible with the vessel's hardware.
The vessel's operator had a written acceptance from the equipment manufacturer acknowledging the end-of-life status, and a documented compensating control: enhanced monitoring of the system's network traffic. The enhanced monitoring had never been implemented.
UR E27 requires that patch management procedures for CBS address cases where patches are unavailable — including compensating controls and risk acceptance documentation. The documented compensating control was compliant with the requirement.
The documentation was compliant. The implementation was not. This is the gap between the VCSP and reality — in a context where the system in question controls the vessel's electrical power.
Implementation of the documented compensating control. A verification process that checks whether compensating controls are operational, not just documented. An annual review of end-of-life system status and the effectiveness of risk mitigations.
End-of-life operating systems on safety-critical OT systems are endemic in the maritime sector. The hardware lifecycles of vessel systems — fifteen to twenty-five years — are fundamentally mismatched with the software support lifecycles of the operating systems they run on. IACS UR E27 creates a framework for managing this mismatch. It does not make the mismatch disappear.
A crew change in a major port. A new engineer joins the vessel. During the handover period, he connects a personal laptop to the vessel's maintenance network to transfer work files from a previous vessel — a practice he had used routinely on his previous postings.
The personal laptop was running outdated software. The files transferred included a directory containing compressed archives from a previous vessel's network. The vessel's IT administrator discovered the connection during a routine network audit two weeks later. No exploitation was detected. The exposure window was unknown.
UR E26 requires that access control procedures cover crew and visitor access to onboard networks. UR E27 requires that CBS have controls preventing unauthorized connection of external devices.
A policy prohibiting personal devices on the maintenance network. No technical enforcement. No network access control requiring authentication before a device could connect. No monitoring that would have detected the connection in real time.
The engineer was not malicious. He was following a practice he had used across his entire career without incident. The policy existed. The culture that would make him check the policy before plugging in his laptop did not. This is the human factor. It cannot be fully addressed by regulation, documentation, or technical controls alone — it requires a security culture that treats vessel networks with the same caution as safety-critical physical systems.
What These Patterns Have in Common
Five different threat patterns. Five different vessels. Five different operators. The same underlying structure in every case:
A documented requirement that was not implemented. Remote access controls. Removable media procedures. Network segmentation. Compensating controls for unpatched systems. Device connection policies. Every one of these was covered by a policy or a plan. None of them were functioning as designed.
No detection capability. In four of the five cases, the issue was discovered by a manual audit or a human observation — not by a technical monitoring system. The window between initial exposure and discovery was measured in weeks or years.
No one whose job it was to check. The VCSP was written. The zone diagram was approved. The compensating control was documented. But nobody had a standing mandate to verify that the implementation matched the documentation, on an ongoing basis, as the vessel and its systems changed.
What IACS UR E26/E27 Addresses — and What It Doesn't
IACS UR E26/E27 is the most significant advance in maritime cybersecurity regulation in the industry's history. It establishes mandatory architecture requirements, documentation standards, and supplier responsibilities that did not exist before July 2024.
It addresses the newbuild design problem. It creates a framework for CBS documentation. It defines the CRSI role. It requires survey evidence that can be checked.
It does not — because no regulation can — guarantee implementation. It does not address the existing fleet. It does not create the detection capabilities that most vessels currently lack. It does not build the security culture that turns documented procedures into practiced behavior.
The regulation is necessary. It is not sufficient. The gap between necessary and sufficient is where a Smart Marine Consultant works.
The threat patterns in this post are the operational reality behind the regulatory framework. IACS UR E26/E27 exists because these patterns exist — because connected ships create attack surfaces that weren't there before.
Understanding why maritime cybersecurity became a system engineering issue — the deeper architecture of the regulation, the stakeholder dynamics, the technical requirements at the system level — is what the next series covers.
→ Start Here: Why Maritime Cybersecurity Became a System Engineering IssueReal threats are not exotic. Unclosed sessions, unscanned USB drives, misconfigured switches, unimplemented compensating controls, personal laptops — these are the actual attack surface.
Policy without technical enforcement is not a control. Every case here had a policy. None had the implementation to match.
Detection capability is the missing layer. In four of five cases, discovery came from manual audit — not monitoring. Exposure windows of weeks or years are the result.
IACS UR E26/E27 is necessary, not sufficient. The gap between the two is where the work happens.
Comments
Post a Comment