The advantages of having a single homogenous architecture for every vessel across the fleet is obvious. However this requires significant capex. Perhaps there are some practical steps towards partial standardisation that can make a real difference in simplifying management and improving cybersecurity.

Sign up here to receive future articles and tools on powering up your journey to managing the cyber risks on-board your vessels.

It is time for Vessel IT to grow up.

In the past there were two major factors that were holding it back:

  • Limited satellite bandwidth

  • Lack of onboard IT skills

The first of these made it essentially impossible for the vessel to rely on any shore-based services and so the IT was designed to be self-contained. The second of these means the self-contained IT was necessarily maintained by non-experts and thus rapidly diverged from any nominal build baseline.

Usual security hygiene like regular automatic updates and centralised security policy and identity management were not feasible. Although limited remote access might be available; any major changes or upgrades would require a technician to physically go onboard. And the crew would have local administrative rights so they could attempt to fix problems while at sea.

The availability of VSAT in recent years has made remote connectivity more reliable and raised the prospect of being able to integrate vessel and shore networks. But the legacy of all the manually built and maintained systems that are currently in service on vessels is a huge challenge. Remote access is now commonly available but often only used to carry out the same manual maintenance procedures that would previously have been done when a technician went on board.

Standardising vessel architectures takes work, but the benefits are clear

There are some big issues preventing shipping companies from properly dealing with this legacy IT estate:

  • Significant upfront cost (financial investment and resources).

  • Keeping vessels in operation whilst changes are carried out.

  • Having confidence in a chosen target architecture.

  • Lack of in-house skills to design and implement changes.

  • Need to retraining seafarers.

But it’s clear that a more centrally managed, homogeneous network would deliver some key long-term benefits

  • Improved operational efficiency because changes can be automated and applied across the whole fleet.

  • Fewer outages and less fire fighting.

  • Flexibility to test and deploy new digital applications and deliver benefits more quickly.

  • Improved security from secure baselines, updates and centralised monitoring.

So where is the best place to start?

As with any major change programme you need to have a clear understanding of where you are today and where you want to be in the future.

Developing the target architecture will take some effort but since VSAT allows vessels to adopt more familiar enterprise approaches there is plenty of best practice guidance to help. There are however still some key areas to consider where it might still be sensible to deviate from shore-based architectures. These include:

  • Using thin-client PCs for terminals on the vessel with desktops hosted in the server room. This provides a high level of control to deploy patches and reset desktops that have a problem. It also enables you to give seafarers elevated permissions to make temporary changes that may be required for operations because it’s possible to revert afterwards.

  • The identity management system will need careful planning to enable both online and offline operations. There are principles from Zero Trust networking which may be helpful here. Zero Trust networking for vessels deserves a whole separate article, but if you’d like some guidance on this, please get in touch.

  • Limiting onboard hosting of applications to only those critical to operations. Other applications can be centralised, or SaaS delivered which makes them easier to maintain.

Start small. Measure success. Then improve.

It isn’t necessary to commit to a full rollout of a vessel architecture standardisation programme upfront. If this is a big change to the current architecture of your fleet, you have a lot to learn and prove before you commit to a business case for fleet-wide change. Pick a couple of vessels, clearly agree the business objectives for this initiative and experiment with these first to prove the concept.

Defining metrics and an approach for data-driven analysis are essential. By putting these in place from the outset you benefit from having:

  • Evidence of current inefficiencies to use in the business case for change.

  • Confidence in the inventory of current systems and applications so that same or better capability will be delivered by the new architecture.

  • A baseline against which improvements can be demonstrated.

  • Ability to track progress and show success.

One way to achieve this is through putting in place some simple asset and network monitoring. This could be integrated into your target architecture, then you can have ongoing visibility through the deployment of changes to check they are working as expected.

Furthermore, since you can also use this data for security and compliance monitoring then you can deliver other short-term benefits alongside enabling the architecture transformation.

CyberOwl are developing a series of practical advice articles and tools that are free to access and designed to help fleet operators start or “power up” their journey to managing the cyber risks to their vessels. Sign up here to receive future articles and tools.