Remote considerations: change is in the air

As Palemia Field of ABB explains, the industry has faced a choice: “Vessels have been getting more complex – so the question has been, do we want crews with maintenance skills, or do we switch to personnel that have operational skill sets, bringing in a collaborative approach for specialised systems? In my view, we’ve made the right decision to go with supporting the ship, real-time, with a live connection.”

As a result, remote services – similar to the ‘desktop sharing’ common to PCs – are regularly taken on by the big engineering and platform providers. This can shorten delays from days to hours as even if the troubleshooting can’t fix it there and then, the remedial action has been identified for the next port call, he says. There’s also a safety element: Peter Huntley-Hawkins of Lloyd’s Register adds it’s “becoming commonplace” for onboard systems to have remote connection facilities to provide incident management assistance.

But there are issues.

While the effects of someone fishing around inside the software of a standard PC could compromise a business, it becomes a very different matter when it applies to onboard, operational technology – OT. However, the two are now mingling, and the potential for IT to undermine OT means we are exposing ourselves – and our environment – to a whole new layer of risk.

Take one near miss from the oil and gas industry. The blow out preventer (BOP) is a big, doughnut-shaped device sitting around a wellhead that, in an emergency, can cut the drill string and close the bore. It’s a notably critical system: a BOP failure helped trigger the Deepwater Horizon disaster.

So it’s had a lot of attention. But according to industry sources, just last year a service engineer was updating the software remotely on a pair of BOP control pods. He finished, and rebooted the computers… and received a very angry phone call. In fact the BOP he’d connected to was not the one safely stored on deck between wells, but another, which at that moment was deployed at a live well head on the sea floor.

Considering the dangers it was a remarkably easy mistake to make, just like misdialling a phone number. Most importantly what made it possible was the manufacturer had simply created the same password for all installations.

Chastened, the crews have now unplugged the internet cable and locked-out the connection box: consent – and keys – are required from both the installation manager (OIM) and the maintenance supervisor.

Jan Haul of DNV GL remarks that this is a typical example of “defence in depth”. But, he clarifies, these multiple barriers should be different in nature.

So, for example, along with the firewall, permit-to-work and user authentication, one installation has a panel of mechanical isolating switches on a cabinet labelled with each manufacturer’s system: “You can easily see if a switch is on or off,” he explains, adding that “if a cyber attack is suspected, it’s easy to throw all the switches to disconnect.”

He points out physical barriers make for “a really simple but extremely effective protection layer”; for one, they can’t be circumvented even by the most advanced hackers, but further, they make a visual statement: “Software is kind of hidden, it’s not immediately obvious to the non-expert whether things are connected or not, that requires expertise,” says Haul.

UNSEEN

This lack of visibility, paired with the rising number of digital systems, is giving the maritime industry pause for thought. New vulnerabilities could be either underappreciated or even go completely unnoticed until there’s an issue, says Field’s colleague, Andrea Crosetti.

In fact, as the recently released Guidelines to Cybersecurity notes, “shoreside and onboard personnel may be unaware [that] some equipment producers maintain remote access to shipboard equipment and its network system”. It describes both inadequate controls for access and continued connection of safety critical equipment with the shoreside as “common cyber vulnerabilities”.

As Crosetti explains, “always-on” technology can present a large attack surface, but there are things that a ship should do to mitigate the danger even if it can’t altogether remove it. “Most of it is fairly basic: you have to make sure the firewall and antivirus definitions are up-to-date,” he says. “Then there is user segmentation and administrator rights so access normally stops at read-only.”

Further, Crosetti underlines that any operating system, even smaller OT data connectors, must be kept ‘alive’ – updated to manufacturer’s requirements – during their lifecycle… and while it might seem obvious, “make sure you completely close down remote, one-off connections if not needed”. Haul adds that a process-people barrier is necessary, making sure no-one can climb from, say, the inventory to access the power management system.

When asked about these issues, Dirk Fry of BIMCO points to the step-by-step processes detailed in CIRM/BIMCO’s Software Maintenance of Shipboard Equipment document (about to be translated into an ISO standard).

This includes fundamentals such as: ‘Plan remote maintenance events with owner and captain,’ and make sure you can identify the players. Shipboard equipment should support procedures to roll back to a previous software version and configuration during software maintenance. Where applicable, it should include a mechanism to generate an on-the-spot diagnostic report after maintenance has been performed, which also identifies the software version. There should also be a means to check that interfaces and functionality are operating as expected after an update has been completed.

And last but not least, the system integrator ‘should specify how to ensure continuity of compatibility of individual shipboard equipment… [and] each software update to be performed on an integrated system should be assessed to determine and describe any impacts or effects on existing software’.

However, it all becomes more complicated if systems are sending information to a data collector. Then, says Crosetti, computers running firewalls to segment the various networks “absolutely must be put in place – even if the data gathering point is apparently ‘inside’ the vessel”. It helps, he adds, to think of it terms of various zones with different levels of accessibility.

RESISTANCE

Despite Crosetti’s emphasis of the need for “bug fixes” for both defence software and operational technologies, updates are currently circumscribed: “At present, class and flag rules limit system changes over the web to modifying existing parameters,” says Svein Kleven of Kongsberg Maritime. More profound changes prompted by the occasional, suddenly-revealed glitch need to be given the go-ahead by class.

Moreover, Field says that there is “suspicion” from the masters and engineering chiefs about the reach of this technology. “Major optimisation upgrades over the airwaves are just not seen as acceptable”, he underlines. Instead, he says: “Speak to ship’s staff, and update with an OEM the same way as ‘regular’ maintenance”.

However, it looks as if the pressures will eventually force a change: “The technology is ready, and it’s a short step to flow not just monitoring data but modifications,” says Kleven. “Basically, whether the engineers are on the ship itself or remotely connected, they are still looking at a screen, so it’s not such a big jump.”

However, he insists: “What is important is to ensure that diagnostic and supervision activities follow these remote upgrades. For this, you need to have the same access to information remotely as you do onboard, right down to seeing, say, the specific board for the frequency converter.” And, he adds, similarly seamless communication with the crew as if you’d flown someone out to the vessel.

There are certain elements put in place by the big platform providers that ease the process and make it more secure: for example, remote support that doesn’t require public or static IP addresses, able to work on low bandwidth / high latency links.

In Kleven’s view, if shipping is to continue to develop along this pathway, it has to be a controlled evolution. While he emphasizes that he “expects the industry to take all necessary measures as far as reasonably practical to avoid critical incidents”, don’t take this entirely for granted: there is a chance that it could miss its footing and fail to create the right technological parameters and accompanying regulations. “If we get it wrong,” says Kleven, “there could be a negative impact on safety.”

RESPONSIBILITY

While this collaborative approach is effective, in no way does any of this imply that overall responsibility shifts away from the captain, even during remote access events explains Crosetti. Huntley-Hawkins adds that the activation procedures still keep the ship in “standby mode” so the connection can be severed: he underlines that “control continues to reside on the ship”.

Still… that doesn’t mean that decision making won’t become more nuanced and interlaced, says Field: “We will soon see a lot more information going back and forth… I believe that we are in a situation where the delineations between shoreside and onboard decisions stand to get quite fuzzy, although there is an element of culture change implicated in all this.”

And then there’s the ‘A’ word. “By starting to talk about autonomous ships, we can begin to consider pieces of the associated, remote discussion. Because from my perspective, in five or ten years, autonomous technology may well be used to support ship operations directly,” concludes Field.

ONSHORE VERIFICATION

A big part of the picture is what happens onshore, as there’s a demand for exhaustive lab analyses on all the vessel’s software, whether it’s remotely or physically accessed says Crosetti. This is where Kleven believes a digital twin or its equivalent becomes a necessity: “You have to be able to test it all out before it gets to the ship.”

But for this to be effective, the real and virtual vessels need to be kept in parallel. “Some modifications can seem harmless – until you are sitting with different versions of the software. It requires protocols to make sure everything is properly synchronised.” Consequently, this entails security for three, very different areas: onboard, onshore… and finally, the Cloud.

And while the quantity of data flooding in from various sensors may occasionally seem excessive, it can help to nail issues. Kleven explains that some redundancy in the information stream is likewise necessary in order to spot, for example, a failing sensor: “If there are divergences the flows can be compared, you can see if there’s something that’s not telling you the same story as the rest.”

KEEPING OUT

A lot of vessels are still trying to keep out of the game entirely, though that means keeping the ship sealed off from any kind of connectivity.

There’s good reason for this approach: “A very large number of ships – probably tens of thousands – are still using Windows XP,” says Crosetti. That went out of support back in 2014. “The separation strategy works if the automation computers are ‘air-gapped’, that is, no external connections, he explains. “It is arguably OK if the system remains isolated,” says Haul, but both agree it’s hard to keep it that way.

“The largest successful attack vector now is an infection spread by a USB device. The crew on a cargo ship might not even notice, and carry it from one system to another,” he adds.

It’s going to be a growing issue catching more and more vessels as time, tide – and operating systems – wait for no one. As Haul points out, the next swathe running Windows 7 will lose support in January next year. So they too will be faced with a decision: upgrade… or remove themselves from the connected network. Certainly, more than a few will likely find they have trouble: “You can’t just update to a newer system the way you can with an office computer… the system hardware might not run it and your equipment might not recognise it. It’s a definite problem.”

A MOVEABLE FEAST

Therefore it’s probably not overstating it to say the most significant challenge facing the maritime world is that shipboard engineering has turned into a moveable feast.

As software controlled systems can change their operational parameters, “so organisations such as classification societies and flag state administrations can no longer assume the system functionality to be cast in stone”, says Huntley-Hawkins.

Finally, all this affects how the industry moves forward: it won’t just entail looking into previously unexamined corners but a sea change that requires us to become aware of the processes at work. He concludes that beyond investigating the practices adopted by software creators, “reliance has to be placed upon the organisations undertaking the changes in an acceptable manner” and adds that we need to be sure “the process generate[s] sufficient evidence to demonstrate acceptability later”.