Safe, but sailing nowhere. Can you stop a fleet of ships?

TL;DR

• Fire pumps, steering gear and propulsion are obviously critical, and the rules are built around them
• Nothing examines whether a ship can keep commercially operating, and the IT that decides it gets no assurance work at all
• Nine years of ransomware against shipping has taken out offices, booking systems and terminals without ever being confirmed on a vessel’s own computers
• Back then there was less IT on board, less of it connected, fewer Windows domains, and communications links were slow
• All four have changed. No ransomware incident has been reported as reaching vessel computers, and that is unlikely to be the whole story

What systems are needed for the safe operation of a vessel?

Most people in shipping can answer that without pausing. The fire pumps, the steering gear, the main engine, the power management system, and many more. Everyone agrees on those. The rules are built around them, they are certified and surveyed, and crews drill on running them in a degraded state.

The other question gets asked far less often, which is whether the ship can do her job without the office computers.

We often compromise those computers during a test. On a single vessel the loss of IT systems can be managed. The ship runs degraded, she is late, and one late ship is not much of a problem. The impact becomes significant when we point out that the same systems can be taken out on every ship in the fleet at once.

Off the shelf ransomware

Ask most people about a ship being hacked and they picture a container ship hitting a bridge. Protecting against that matters, and a capable state actor could work towards it. The more likely attack is ransomware.

An attacker gets onto one machine on one vessel, maybe by convincing an officer to install malicious software that looks like an update. That machine is an ordinary workstation and the account is an ordinary user account. From there the attacker moves around the network, taking whatever access they can get to servers and file shares, and then encrypts every file and database they can reach and demands payment to decrypt it.

The people who do this are financially motivated, and the software is generic rather than built for any particular industry. They may not know they are on a ship and they certainly do not care. To them it is another Windows network.

What lets them move is the Windows domain, the shared login and management system that lets one set of credentials work across many machines and makes a fleet centrally manageable at all. There are other routes, including reused local passwords and remote management tools, but the domain is the fast one. Administrator rights in a domain can mean the attacker runs their software on every machine in that domain at once.

A fleet-wide Windows domain is a sensible design and it is where the industry is going, because managing ninety ships any other way does not work. But it also concentrates the consequence. Compromise of that domain can mean compromise of every workstation, every server and every system running on them, on every vessel and in the shore office.

Nine years of incidents

Shipping has been hit repeatedly and publicly.

These were either attacks against ports, or attacks against shipping companies and ship managers that hit shoreside systems. No publicly reported ransomware incident has been confirmed to have run on a vessel’s own computers. Maersk is the odd one out, because NotPetya was a wiper rather than ransomware, and it is here because the pattern held anyway.

In every one of these cases the organisation kept trading. Some worked by hand, some moved to other channels, and some stopped the affected operation and caught up afterwards. In most of them the cost was still significant, and Maersk put the hit to its results at $200 million to $300 million.

These are also only the incidents that became public. Ransomware against shipping companies, managers and ports is routine and most of it is never disclosed, because disclosure follows what customers notice. Silence does not mean there have been no successful ransomware attacks.

Why that is changing

None of the ransomware incidents in that table reached the fleet. That says more about the conditions at the time than about the ships, and those conditions have been going away.

• More IT on board. Every function that came off paper arrived as another application
• Those systems talk to shore. Data replicates ashore, and the office works from the same records the ship does
• Fleet-wide Windows domains are now common. We used to find standalone machines, or a domain per vessel with nothing joining them together
• The links got faster. VSAT made a usable connection possible. Starlink changed the speed completely

A vessel now looks far closer to a branch office than to an isolated site.

One ship, or a fleet

Ransomware on the shore office is survivable. As has been seen, it can be painful and expensive, and companies have come through it with their ships still operating.

Ransomware on one ship is survivable too. Operations on that vessel are degraded and the rest of the fleet carries on.

Ransomware across the whole fleet and the shore office at the same time is the case nobody has yet dealt with.

We think we know why that has not happened yet. The shipping company incidents in that table are all from 2020 or earlier. The later ones are ports, which never had vessels in their networks to begin with.

We have tested merchant fleets dozens of times. In all but one instance, starting from a single machine on one ship with an ordinary user account, we finished with every Windows machine and every server across the entire fleet, which includes the machines that the systems below run on.

Some fleets are more resilient to attack. Some have segmentation between vessels, firewalling, and the ability to notice an attack and respond to it. Those measures slow us down, and in one case they stopped us entirely.

Systems nobody looks at

Shipboard systems get categorised in more than one way.

Class rules sort services by what has to keep running:

• Primary essential services, needed continuously to maintain propulsion and steering
• Secondary essential services, needed for the safety of the vessel but not continuously
• Non-essential services, which is everything else

IACS UR E22 sorts computer-based systems by the consequence of failure:

• Category III, where failure could immediately cause a dangerous or catastrophic situation
• Category II, where failure could eventually lead to one
• Category I, where it will not

A ship’s IT lands at the bottom of both. It is non-essential under the class rules, and E22 either does not reach it at all or puts it in Category I. Category I gets no design appraisal, no type approval and no certificate, and anything outside E22’s scope never got looked at by class at all.

That is not an oversight. Class, port state control and other surveyors are not there to examine how a computer stands up to an attack. What they check is that the system is present and working, which is a reasonable thing to check, and it works right up to the morning that the system is not available.

Cyber risk is not outside the rules entirely. MSC.428(98) has required it to be addressed in the safety management system since 2021, and it gets checked at audit. IACS UR E26 and E27 add cyber resilience requirements, but only for ships contracted for construction from 1 July 2024, which leaves most of the world fleet outside them. None of it examines the machines in the list below.

Depending on vessel type and trade, these are the IT systems a vessel needs in order to operate:

• Ship to shore mail
• The planned maintenance system (PMS) and procurement
• Safety management system (SMS) document control
• Permit to work, risk assessment and enclosed space entry
• Hours of rest
• Crew certification and the manning matrix
• Drill and training records
• Electronic record books, such as the Oil Record Book
• The machine that receives chart and publication updates
• Cargo documentation and port clearance
• Cargo compatibility and previous cargo history on a product tanker
• The loading computer

Everything at once

Picture every Windows machine on every vessel and in the shore office stopping on the same morning. Not the planned maintenance system on one ship, but all of the systems in that list, across the whole fleet, together.

Attackers look for the backups as well as the live systems. Once they have spread across the estate they go after the backup servers, the replicas and the shore copy of the vessel data, because a working restore is the thing that stops them being paid.

Impact on vessel operations

The loss of different systems has different impacts to vessel operations.

Take the loading computer. It works out the stability and strength of the vessel for the cargo the ship is actually going to load, and shows whether they sit inside the approved limits. Nothing goes aboard until it can be demonstrated that the vessel is going to be stable.

There is a fallback, but it is narrower than it looks. The approved stability booklet is on board, and intact stability and strength can be worked through by hand. The booklet covers a simple homogeneous cargo well enough, and much less well for several grades in a tank arrangement the charterer has set. Damage stability for a condition the booklet does not already cover is another matter, and on many ships the route there is to have the office run it and send the result back. In this scenario that is gone too.

Now take the SMS and the PMS. A port state control officer coming aboard when none of your systems can produce the certificates, the crew list and the records is likely to cause you problems. That means deficiencies, and detention in the worst case. Shoreside should retain a copy, but that does not help if the attack has taken out the shoreside systems as well. Paper copies have been withdrawn on a lot of ships.

Then take SIRE, the global tanker inspection programme. A tanker trades on the back of an acceptable inspection report. The question set for each inspection is generated in advance from data the operator has to keep current, and the inspection checks operational evidence as well as certificates: drills, training, maintenance actions, and corrective actions with dates against them. That evidence comes out of the PMS and the document control system. There is a paper contingency process, but it covers the inspection tablet not being usable rather than the operator having no records to show. The impact here is worse than a delay or a deficiency, because it can take the ship off hire.

Then there is ship to shore mail, which is the one people underestimate. Almost everything a modern vessel does with the shore goes through it: cargo instructions, port paperwork, crewing, technical support, and every exchange with the agent. The fallback is a mobile telephone alongside and a satellite telephone at sea, which is fine for a conversation and useless for a forty-tank ullage report. On one ship that is an irritation. Across a fleet, with the office in the same state, everything that used to be email becomes a queue of telephone calls that nobody has the people to answer.

Some of these have a manual fallback. Some still have paper records, and where paper is cheap to keep it is worth keeping, even where nothing requires it. The rest just hold up the day to day work, for people who are already under pressure. When were those fallbacks last exercised, and would they work across the whole fleet at once?

Where to start

• Get assurance on the domain itself. Tiered administration, no excessive domain administrators, unique local administrator passwords, and multi-factor on the accounts that matter
• Work on network segmentation. Limit what one machine can reach, so that if it is compromised it cannot take out the whole fleet
• Get detection in place. Endpoint detection and response, and network monitoring, have slowed us down significantly
• Make sure the individual vessels have backups available locally, and that the shoreside backups are properly isolated from the Windows domain
• Document what IT systems you have, on board and ashore
• Work out the impact of each one stopping across the whole fleet at once
• Work out how the ship operates if that system is unavailable, and what manual working actually involves
• Separate fallback from recovery. A fallback is something the crew operates this afternoon. Recovery is a restore, and it takes far longer than anyone expects
• Write playbooks so everybody knows what their duties are when something goes wrong, and where their authority runs out
• Carry out cyber drills, in the same way the crew drills everything else
• Get further assurance on the systems that matter, and keep the basics in place on everything else

The rules tell you what could hurt someone, damage the ship or harm the environment, and they do that well. They were never meant to tell you what stops her working. For nine years nobody has needed them to, and the reasons for that are quietly going away.