Where maritime cyber checklists fail

The coming IMO cyber security regulations are a step in the right direction towards vessel security, but the impracticality of assessing the cyber security of a ship, together with a huge skills shortage, leads classification societies towards checklist based assessments.

Having seen some of these checklists, it’s clear that there are significant gaps in the understanding of maritime cyber security.

To illustrate the point, here are a few examples of security issues in vessels that we have found recently. Any one of them could prevent a ship from sailing, slow it down when at sea, or result in a hull loss.

You decide if a checklist would have found these issues:

Scenario 1: “Shadow IT” makes OT available on the Internet

An equipment room containing PLCs and control gear for critical systems was located some distance from the main engine control room but required frequent adjustments via a local HMI.

To avoid leaving the control room, a PC was installed in the equipment room. Teamviewer was used to enable remote access from the control room.

The remote PC bridged between the corporate network and the OT network. The Teamviewer password was on a label above a monitor in the control room, allowing access to the remote PC from the wider Internet.

A vulnerability discovered in the network switches of the OT equipment allowed a shared password to be recovered. With this, it was possible to wipe the configuration of PLCs and switches, stopping all OT systems from functioning.

Scenario 2: Third-party mistakenly allows access to critical serial networks

The load computer was located on the bridge of the vessel. This required network connectivity between two PCs, and to several remote Serial->IP convertors used to read information from ballast tanks.

The third-party vendor used the available network sockets on the bridge to interface to these. The network design of the vessel meant that any unrecognised or unregistered devices were placed in an isolated VLAN.

This allowed the PCs to interact with the Serial->IP convertors. However, network sockets in the passenger space used the same mechanism.

A laptop connected to a network port in the passenger space could therefore inject traffic onto the serial network used for ballast tank readings. Random data injected here prevented the bridge systems reading ballast tank levels, causing multiple alarms and the requirement to take manual dippings until the problem was resolved.

Scenario 3: Remote firmware update causes operational issues

The NOx scrubber system was installed by a third party and contained significant control gear and remote monitoring.

The ship owner provided a dedicated VLAN for the system to communicate over VSAT. It was found that the HMI providing remote connectivity was also attempting to download a firmware and configuration from a remote server using unsecured HTTP.

It was possible to update the firmware of the HMI to a malicious one, and remotely interact with the control gear of the scrubber. The configuration of the PLCs in the scrubber was wiped, preventing control and monitoring of the scrubber. The engines needed to be operated at reduced power to avoid damage to the scrubber system.

Scenario 4: Accessible HMI leaks high-value passwords

An HMI in a HVAC room on the vessel had access to a limited number of screens, only concerning control of the HVAC equipment and monitoring of power systems on the vessel.

By using the “Print” menu, it was possible to break out of the HMI software and access the underlying operating system.

All HMIs used a shared Windows network, including SMB shares. One of the HMIs in the main control room had a file called “passwords.txt” left on this share.

This contained operator and administrator passwords for all the HMIs and PLCs, left from when the vessel was commissioned. These passwords were found to be common across all vessels using that ICMS (Integrated Control and Monitoring System) vendor.

Conclusion