What goes into testing a ship?

TL;DR 

• Testing a ship involves identifying and mitigating cybersecurity risks using the “Identify, Prevent, Detect, Respond, Recover” framework. 
• Guidelines include MSC.428(98), BIMCO, IACS UR E26/E27, and ISO standards. New builds and existing vessels require proper documentation and network security measures. 
• Key focus areas include corporate IT systems, OT security, network segmentation, perimeter security, and Windows domain security. Testing should prioritize high-risk, fleet-wide vulnerabilities and is usually conducted during low operational periods like drydock. 

Introduction

Testing a ship’s cybersecurity, is a complex process aimed at ensuring the vessel’s safety, security, and operational readiness. Both new-build vessels and existing ships must comply with maritime cybersecurity guidelines, and the process typically focuses on key areas like risk identification, systems connectivity, network segmentation, and the resilience of IT and OT (Operational Technology) systems. 

Existing vessels

Existing vessels generally must follow MSC.428(98) and MSC-FAL.1/Circ.3/Rev. “GUIDELINES ON MARITIME CYBER RISK MANAGEMENT”. This is very high-level guidance that focuses on using risk management within the 5-point framework of Identify, Prevent, Detect, Respond, Recover framework. In turn, it references Flag Administration’s guidance, BIMCO “The Guidelines on Cyber Security Onboard Ships” and IACS “Recommendation on cyber resilience (Rec 166)”, ISO 27001 and the NIST framework. 

New-build vessels

New-build vessels are also now subject to IACS UR E26 and E27. These place a strong emphasis on the same 5-point framework, but formally establishes the responsibilities of the ship owner, systems integrator (the shipyard generally), suppliers and classification societies. It covers the design, construction, commissioning and operation phases. E26 concerns the vessel as a whole, with E27 covering subsystems provided by suppliers. Simplistically, the goals are for most subsystems to be E27 certified by classification societies, connected together securely and in a documented manner under E26. 

The major classification societies have all published guidance for new-build vessels and class notations for existing vessels. All of these place a strong emphasis on understanding the systems on board – what they are comprised of and what they are connected to. This can be challenging for older vessels, where documentation is lacking, and many changes have been made over the years. 

In terms of Identify, Prevent, Detect, Respond, Recover, maritime has focused on “prevent”, with very little effort expended on the other phases. Fundamental to all points are documentation, oversight, and understanding interconnections between systems. 

Don’t believe the movies

If you have an existing fleet of vessels, it is recommended that initial efforts are spent on identifying the systems onboard and then determining how exposed to risk they are. We always focus on high-impact, high-likelihood attacks during these initial engagements. An issue that could impact the entire fleet from the Internet is clearly of higher risk than one that impacts a single vessel when the attacker needs to be onboard. 

Whilst the movie plot scenario of taking remote control of a vessel is exciting, we do not believe the resulting risk of such an attack is high: 

• Attack feasibility is low – for many types of vessels, it is virtually impossible to remotely operate the steering and propulsion. When it is possible, it often involves long and complex attack paths that would be difficult to discover without spending time on the vessel. 
• Wide impact is challenging – in the instances we have managed to gain significant control over steering or propulsion, it been a unique situation impacting a single vessel. The differences between each ship would likely mean that an attacker would need to develop attack paths for each vessel. 
• Attack window is low – at any given time, most vessels in a fleet will be deep sea or alongside. If you take remote control over steering deep sea, the crew have time to notice and react. When alongside, the propulsion will be locked out using physical controls. The only time there would be significant impact is when the vessel is manoeuvring or in a busy channel.
• Detection and response are possible – the crew are highly likely to notice remote operation and, in nearly all situations, can take back manual control.

Corporate systems

We still believe that corporate systems compromise is the most significant risk – for a vessel to operate, email and other IT systems must be available. Without email, how will the vessel receive orders? Without being able to complete cargo paperwork, how can the vessel sail? The corporate network is a significant risk due to a combination of factors: 

• A large pool of attackers are familiar with Windows, with many off-the-shelf tools and techniques available for attack. 
• Complete Windows domain compromise can impact an entire fleet, not just a single vessel. 
• Security awareness is often weak, with many poor-quality passwords being used and phishing attacks often succeeding. 
• The loss of corporate systems often has extreme impact on operations. 
• Breaching IT systems is often the first step towards gaining remote access to OT systems. 

In terms of impact, we consider the following: 

• Immediate safety of the vessel and crew – can an essential or safety critical system be affected? Examples would be steering, propulsion, generators, power management system, ECDIS etc. 
• Operational impact – can we stop or hinder day-to-day operations of the vessel? Cargo management systems, corporate machines, and offboard communications are good examples. 
• Regulatory impact – can we affect the vessel by breaching regulations? If the vessel is detained by Port State Control or electronic logs are deleted, what is the outcome? 
• Environmental impact – can we cause direct environmental impact or associated regulatory impact? Disabling exhaust gas cleaning systems or tampering with oily water discharge logs could be a trigger. 

Vessel security in a nutshell

We have extensive experience working with existing and new-build vessels and believe that the following core areas are key to the security of a vessel: 

• Oversight – every vessel is unique, and it is important to understand what is onboard, how it is connected, what impact it has if compromised, and how change is managed. 
• Network segmentation – modern vessels often have multiple gateways between IT and OT and it is crucial that these are secured. 
• Perimeter security – for an attacker to have deep impact, they need to carry out attacks from afar and across multiple vessels, bypassing perimeter security such as firewalls and malware detection. 
• Windows domain security – although IT should not have direct impact on OT, initial access to OT is nearly always obtained by compromising a Windows account. 

What does a testing engagement involve?

If there has been no previous penetration testing carried out, it is recommended that a sample of vessels are tested. Initially, a “typical” vessel should be chosen and examined in-depth. This will often identify issues that could impact the entire fleet and can be solved fleet-wide with simple fixes. 

A typical engagement would involve the following stages: 

• Assessing the maturity of the company in terms of the identify, protect, detect, respond, recover framework, normally using interviews and documentation review. This helps to direct further testing. 
• Gaining understanding of the systems onboard the vessel. This would normally use a combination of documentation review, interviews, network exploration, and physical survey of the vessel. 
• Network segmentation testing to ensure that IT and OT are adequately isolated. This would normally involve basic checks alongside efforts to compromise any gateways between systems. 
• Testing of the core network on the vessel the satellite communications equipment, firewalls, switches and other infrastructure. 
• Testing of any Wi-Fi networks available, confirming that network segmentation is in place, and passwords are adequate. Alongside this, a survey for any rogue devices will be carried out. 
• A conventional Windows IT infrastructure test, normally aiming to achieve widespread compromise, starting from either an unauthenticated or normal crew account. 
• Proportionate checks of OT systems to ensure that they do not present excessive risk. It is acknowledged that many OT systems are poorly secured, and focus should generally be on preventing initial access using network segmentation. 
• Checks of the external attack surface of the vessel, such as exposed external IPs and Wi-Fi. 
• Examination of any third-party systems, as far as is possible, to understand the risk they present. This would typically cover maritime specific software and some IT / OT gateways or monitoring devices. 

Recommendations

Testing will always be carried out using a risk-averse approach, aiming to avoid causing disruption or making permanent changes to any systems. Continuous risk assessment is used, involving the crew where required. 

Pen testing still carries a risk of disruption. If possible, work should be carried out when there will be minimal impact. Ideally this would be during a drydock or layup. Accommodations can be made for when the vessel is in operation or underway, but this will generally slow down testing. 

The number of days required to test a vessel varies. Good coverage can be obtained on a conventional cargo vessel in 5 days, whereas more complex vessels such as dynamic positioning or scientific research may require 8 or more.

A debrief is strongly recommended to aid in understanding and answer any questions.