IACS UR E26 and E27 guidance

TL;DR

• A
• B
• C

1. Introduction

The International Association of Classification Societies (IACS) have introduced two new Unified Requirements (UR); E26 “Cyber resilience of ships” and E27 “Cyber resilience of on-board systems and equipment”. These apply to nearly all ships contracted for construction on or after 1^st July 2024.

They both focus on Operational Technology (OT) and systems essential for the safety of the vessel. Information Technology systems are not directly covered, though may be brought into scope.

E26 largely concerns the security of the vessel as a whole, whilst E27 concerns the security of individual Computer Based Systems (CBS) that make up the vessel.

Closely related to E26 and E27 is the older UR E22 “Computer-based systems”. This defines many of the terms in E26 and E27.

Practically, all ocean-going cargo vessels are subject to the new URs via specific class notations.

Most classification societies have ratified E26 and E27 in their own class notations and guidance.

2. Classification Societies

Many of the classification societies that are members of IACS have published updated cyber security guidance and class notations that align with the new URs. Det Norske Veritas (DNV), Bureau Veritas (BV), American Bureau of Shipping (ABS) and ClassNK have made their guidance publicly available, and all have been considered as part of this work. They are all broadly aligned with E26 and E27, although different terms are used, and translation is required at times.

Lloyd’s Register (LR) have explicitly stated that they have not published any documents around E26 and E27, but their current rules (July 2024) are very closely aligned.

3. UR E26

UR E26 concerns the entire vessel. Systems that are part of the vessel should comply with E27.

The primary goal of E26 is to support safe and secure shipping which is operationally resilient to cyber risks. The popular 5-point risk management framework is used:

1. Identify: get oversight of the systems and devices on the vessels.
2. Protect: minimise the scale and frequency of cyber incidents by implementing security controls.
3. Detect: detect and identify the occurrence of a cyber incident onboard.
4. Respond: act if a cyber incident occurs onboard.
5. Recover: get back to an operational state after a cyber incident

Activities and deliverables are defined for each of these points, factoring in the lifecycle of the vessel and the stakeholders involved.

Four stakeholders are identified in E26, and the classification societies have all aligned with these:

• Shipowner
• Systems integrator
• Supplier
• Classification society

Four phases of the vessel’s lifecycle are identified:

• Design
• Construction
• Commissioning
• Operation

Several of the classification societies have added phases. DNV has split the design phase into “high-level design” carried out by the shipowner and systems integrator, and “system design” carried out by the suppliers of the systems.

For each activity in each phase, compliance must be demonstrated. E26 makes it clear which stakeholder should be demonstrating compliance, at which stage and how.

The following activities are defined as part of E26. During the design and construction phase there will be a heavy focus on identify and protect but all systems in scope must support the detect, respond and recover items.

1. Identify

• Vessel asset inventory

2. Protect

• Security Zones and Network Segmentation
• Network protection safeguards
• Antivirus, antimalware, antispam and other protections from malicious code
• Access control
• Wireless communication
• Remote access control and communication with untrusted networks
• Use of mobile and portable devices

3. Detect

• Network operation monitoring
• Verification and diagnostic functions of systems and network

4. Respond

• Incident response plan
• Local, independent and/or manual operation
• Network isolation
• Fallback to a minimal risk condition

5. Recover

• Recovery plan
• Backup and restore capability
• Controlled shutdown, reset, roll-back and restart

Maritime cyber security – in particular OT security – has largely focused on identify and protect in the past, with very little consideration given to detect, respond and recover. Although detect, respond and recover are going to be carried out during the operation phase of the vessel, choices made during the design, including system selection, will influence how easy they are to carry out.

3.1. In-scope Systems

The following systems must be in scope for UR E26:

• Propulsion
• Steering
• Anchoring and mooring
• Electrical power generation and distribution
• Fire detection and extinguishing systems
• Bilge and ballast systems, loading computer
• Watertight integrity and flooding detection
• Lighting
• Any required safety system whose disruption or functional impairing may pose risks to ship operations (e.g. emergency shutdown system, cargo safety system, pressure vessel safety system, gas detection system, etc.)
• Navigational systems required by statutory regulations
• Internal (PA, GA) and external communication (radio, GMDSS) systems required by class rules and statutory regulations

In addition any IP systems connected to the above systems are also in scope:

• Passenger or visitor servicing and management systems
• Passenger-facing networks
• Administrative networks
• Crew welfare systems
• Any other systems connected to OT systems, either permanently or temporarily (e.g. during maintenance)

On a cargo vessel, this leaves very few OT systems that can be excluded. Air conditioning and provisions chillers may be excluded. Systems where it is not clear if they have direct safety impact, such as CCTV, should generally be included at the high-level design stage.

Primary essential services are those services which need to be in continuous operation to maintain propulsion and steering. Secondary essential services are those services which need not necessarily be in continuous operation to maintain propulsion and steering, but which are necessary for maintaining the vessel’s safety.

Careful consideration should be given to the impact that secondary essential systems can have on primary essential systems. Systems such as Selective Catalytic Convertors (SCR) can be connected to the main engine and trigger a shutdown or slowdown under certain conditions.

Satellite communication systems are not directly included in E26. However, the impact on vessel operations in the event of loss of satellite communications is normally significant.  It is not expected that the major satellite providers will be type approved to E27, but the importance of the satellite communications should be considered in terms of operational impact.

Firewalls and other network devices will be in scope of E26 if they are connected to other systems that are in scope. This could bring the entire core network of a vessel into scope and could even require the shipowner to obtain approval of their systems under E27.

E26 only considers direct safety and environmental impact. It does not consider disruption to operations due to regulatory compliance issues, such as being detained by port state control. There are several systems onboard a vessel which would result in port state control detention if they were inoperable. This includes the voyage data recorder (VDR) and fire detection system. This should be considered during the design stage.

The concept of an untrusted network is frequently mentioned. This is any network that is outside the scope of E26. Additional requirements are placed on any system that connects to an untrusted network. Untrusted networks include the business network, crew network, and the Internet. A performance monitoring system that can be connected to from the business network, or a system receiving updates from Internet, would both be considered as connecting to an untrusted network.

The individual class notations provide rules for determining which systems are in-scope, but these tend to include additional systems above and beyond those required by UR E26.

Some systems can be excluded as they present negligible risk. DNV provide a simple system selection guide where three questions must be answered:

1. Is the system connected by IP-networks to other systems?
2. Are any devices located in unrestricted spaces?
3. Will software or configuration in the system be updated or modified?

Realistically, this will only exempt air-gapped systems that will never have their software modified. At the initial stages of design, it may not be possible to determine if a system can be exempted as it may not be known if it relies on software components or not. It is possible to add or remove a system from the scope of E26 after the design phase. It is recommended that systems are kept in-scope if there is any doubt.

The answers to each of these questions can be documented for each system on the vessel to determine if it will be selected for examination.

This is a very rudimentary form of risk assessment that looks largely at the likelihood that a system is attacked. It does not consider impact. Some earlier guidance from the DNV did include aspects of impact assessment, but these do not appear to be included in the class notation.

Certain systems can be excluded from the requirements of UR E26 if it can be justified. This must be done by performing a risk assessment to demonstrate the associated risk level is acceptable.

The following specific criteria are mentioned:

• The system shall be isolated (no IP connectivity to other networks)
• The system shall have no accessible physical interface ports
• The system must be located in areas to which physical access is controlled
• The system shall not be an integrated control system serving multiple ship functions i.e. be an integrated control and monitoring system
• The system should not be needed for propulsion or steering
• The system should not serve ship functions primary essential services

At the initial design stage, it would be challenging to exclude a system without details of the implementation.

3.2. Security Zones

Systems that are in scope must be grouped into security zones. Each zone must be a discrete network segment, either logical or physical. Each system in a zone must meet the security requirements of the zone.

Navigation and communication systems cannot be placed in the same zone as other systems.

It should be possible to isolate a security zone without affecting the primary functionality of the systems inside the zone.

DNV recommend zoning by:

• Systems supporting similar vessel functions
• Systems in the same physical space
• Systems using the same protocols
• Systems subject to the same security requirements

The zoning of systems should be considered at the initial design stage of the vessel as it will have significant impact on the implementation of the networks and other systems.

A high number of zones could result in better network segmentation as the cost of complexity and increased administrative and maintenance efforts. From past experience, it is common to find that firewalling in complex segmentation schemes is highly permissive and provides little additional security.

Conversely, too few zones can increase the risk each system is exposed to. One system which is compromised could impact another in the same zone. This has been seen on multiple vessels where a single “third-party OT” zone has been created.

Crucially, placing two systems in the same zones means that they all must support the same security requirements. This could make placing two systems with differing levels of security in the same zone challenging.

Issues with zoning and segmentation have been one of the major root causes of issues found during maritime penetration tests. This includes both new build and in service vessels.

3.3. Conduits

A conduit is a communication channel traversing a zone boundary. An example of a zone and conduit diagrams from ClassNK is shown below.

At the initial design stage, it should be possible to determine if two zones need to be connected. It may be challenging to determine the exact method of communication without knowing how systems will be implemented. For example, the fire detection system may be connected to the emergency shutdown system to trigger a shutdown. This could be via discrete signal, Modbus, or even an IP connection. The risk each of these types of connection presents are very different, therefore different risk control measures used.

Poor understanding of how systems are connected and interact has been one of the main sources of issues found during penetration tests of vessels.

4. UE E27

4.1. What Is Required From Suppliers And Systems Integrators?

In an ideal world, the vessel will be built from systems that are all type approved. This would place most of the effort during the design, construction and commissioning phases onto the systems integrator and shipyard.

This is unlikely to be the case for several reasons:

• Some systems are likely to be implemented by the shipowner themselves (such as the core network).
• Most suppliers are not yet type approved and may need guidance, particularly if building customised systems for the shipowner.

From a shipowner’s perspective, it is strongly in your interest to reduce the number of non-type approved systems onboard, as well as keeping as much IT equipment distanced from OT.

It is also worthwhile understanding the requirements under E27, particularly during system selection.

4.2. DNV E27

DNVs guidance on what is required of an E27 is clear and easily understood, therefore is used as an example here.

DNV have three different levels of their Cyber secure class notation:

• Cyber secure is aligned with IMO resolution MSC.428(98) and MSC-FAL.1/Circ.3 (mandatory)
• Cyber secure Essential is aligned with IACS UR E26 and UR E27 (mandatory)
• Cyber secure Advanced exceeds requirements from IMO and IACS (voluntary)

A DNV classified new build vessel, therefore should comply with Cyber secure Essential.

DNV have five security profiles (SP) that loosely align with the four IEC 62443 security levels (SL).

• SP0 – Required for Cyber secure
• SP1 – Protection against casual or coincidental violation (required for Cyber secure Essential)
• SP2 – Protection against intentional violation using simple means
• SP3 – Protection against intentional violation using sophisticated means with moderate resources (required for Cyber secure Advanced)
• SP4 – Protection against intentional violation using sophisticated means with extended resources

These SPs define the threat level against the systems and drive the security requirements. To comply with IACS UR E26 and E27, this means that SP1 or above must be followed.

The complete list of security requirements number around 100. Only around 60 of these apply to SP1 devices. Many of the requirements are simple, but there are also quite a few that are rarely implemented in maritime OT.

Some exceptions are permitted based on operational conditions in the maritime environment, e.g. systems on the bridge where immediate access is required do not need user authentication.

There are two lists of security capabilities in E27. A required list which applies to all systems, and an additional list which covers systems that communicate with untrusted networks (i.e. systems outside the scope of E26). Both SP1 and SP2 have some requirements that are only required if the system is communicating with an untrusted network.

Some systems may not comply with all the requirements, such as a system that cannot implement user authentication. For these systems, a compensating countermeasure can be used. A compensating countermeasure could be to lock the devices inside

The specific requirements from DNV state that the compensating countermeasure must:

• Protect against the same threats as the original requirement
• Provide an equal level of protection as the original requirement
• Not be a security control that is required by other requirements in this UR (it is not clear exactly what this means)
• Not introduce higher security risk

From experience, it is expected to find that many suppliers will use physical access security controls to attempt to mitigate issues in their system. These claims should be carefully examined, as often a reliance on physical protection is misguided.

4.3. Type Approval of Systems

The only classification society providing public detail around the type approval process that suppliers must follow for E27 systems is ClassNK, but it is suspected that all societies will be similar.

ClassNK allows their type approval database to be searched for E27 approved systems. As of November 2024, only four systems are approved. DNV allows their database to be searched for systems that have “cyber included”, which shows only 20 systems are approved. Bureau Veritas does not have an easy mechanism to search for E27 approved systems, but a few can be found by manual examination of certificates.

Systems that have type approval will require significantly less effort during the design, construction, commissioning and operation phase. In particular, from the shipowner’s perspective, the effort required for ongoing surveys will be significantly reduced.

A system that is not type approved will need to present a similar amount of documentation as would be required to obtain type approval. It is therefore strongly suggested that all systems obtain type approval.

An E27 type approved system is only secured against ”casual or coincidental access”. A skilled or dedicated attacker could still compromise systems and cause impact.

5. Challenges and Commentary

5.2 Compliance May Not Result in Security

Although E26 and E27 will result in improvements in security, a fully compliant vessel could still be vulnerable to attack. Individual systems are only stated to be secure against “casual or coincidental access”, so skilled or dedicated attackers could still compromise them.

E26 does not bring IT systems into scope. The impact of losing IT systems should not be underestimated.

5.2 Non-Maritime Suppliers

There is potential for systems to be installed on a vessel by non-maritime suppliers. For example, there are various data collection platforms intended for the manufacturing space but can be used in maritime environments. Under E26, they will be classified as an untrusted system.

This means that any trusted system in scope of E26 that connects to it would need to meet the additional security requirements under E27.

This may present challenges, as some E27 certified systems state that they cannot be connected to untrusted networks. Notably, all systems certified to E27 by ClassNK as of November 2024 state they cannot be connected to untrusted networks. It should be noted that there are only four systems certified to E27 by ClassNK, so this is only a very small sample size.

5.3 Trusted to Untrusted Gateways

It is expected that connections will need to be made from trusted to untrusted systems, such as with non-maritime suppliers. It is suspected that E27 type-approved gateways will be developed to handle this situation. This would be a device specifically designed to connect a trusted system to an untrusted system. This would mean that a system that cannot be connected to untrusted networks could still feed data to other systems. It also would allow a trusted system to only comply with the less stringent E27 security requirements.

There are two “data diodes” that are E27 type approved by Bureau Veritas that appear to be for the purposes of connecting networks of different classifications.

There are currently a number of “460 gateways” listed by DNV that comply with IEC 61162-460 “Digital interfaces for navigational equipment within a ship”. This standard is relatively closely aligned to E27, so these devices could be repurposed for use under E27 with relatively low effort.

5.4 Suppliers Behind the Curve

Currently, most suppliers do not have type approval at the required level for E27.

Many systems have received type approval under IEC62443 (for automation) and IEC61162-460 (for navigation). These are closely aligned with E27 which should allow an easy transition.

It is expected that most mainstream suppliers will start to obtain type approval over the next 18 months.

If a system installed on a vessel is not type approved, then there will be significantly more work during the design, construction and commissioning phase. However, there is also likely to be more ongoing effort with each survey requiring additional effort.

5.5 Suppliers

It is likely that the ship owner will want relatively consistent OT systems onboard their vessels, including their older fleets. There are preferred vendors for these systems.

It is crucial that these systems are certified to E27. ClassNK have only certified four products as of November 2024, and DNV around 20, suggesting that most suppliers have been slow to obtain E27 certification. It is recommended that the preferred suppliers are approached during the design phase to ensure that E27 certification is underway.

If a system is expected to meet E27, but for some reason fails to gain certification, this may cause issues during commissioning. None of the classification societies have provided any guidance should this happen.

5.6. Understanding Conduits

Systems are increasingly interconnected. On older vessels, particularly those without integrated bridge and automation systems, these connections were often made with discrete signals or using a protocol over serial (such as NMEA or Modbus). Newer vessels are increasingly using IP networks, either using conventional IT protocols or serial-to-IP converters.

Discrete signals and serial connections normally only allow two connected systems to operate as intended (i.e. in their normal scope of operation). For example, a pump can be started or stopped, or a request made to change the engine speed. IP networks might be intended to allow the same actions, but can also allow other protocols such as web, telnet or SSH. If the systems are compromised, anuse IP connections to move from one device or system to another. Discrete signals normally only allow two directly connected systems to interact, but IP connections are often routable, allowing an attacker to move further across systems.

It is common to find that suppliers are not fully transparent about the physical network medium, what is carried over it, and what the intended actions are.

Fully understanding the communication between different systems and appropriately securing them is vital.

5.7. Hidden Connections

In several instances, the implemented systems have conduits that were not documented during the design or construction phase. In one case, a power distribution unit connected to the business network could also control the power of some OT networking equipment. This allowed someone on an untrusted network to stop an OT system working.

In another case, the cloud connected Exhaust Gas Cleaning System (EGCS) could trigger a main engine shutdown.

On some large vessels, the loading computer is used to translate from tank depth gauges into volumes. Tampering with the loading computer can cause the automation system to display false readings. Once these issues had been discovered, they were challenging to fix without significant effort. If they had been identified at the design stage, it would have been far easier.

5.8. Remote Connectivity

Many of the OT systems are likely to have remote connectivity of some form. It is not always obvious what actions can be performed over the connection, and suppliers have not historically been fully transparent.

Examples of intended actions that can be performed over a remote connection include:

• Diagnostics and logging outbound.
• Firmware or software updates.
• Configuration updates.
• Non-interactive command execution.
• Interactive remote sessions for troubleshooting.

Crucially, each of these is an intended action. An attacker does not care what the connection is meant to be used for; they care what they can use it for. From their perspective, a remote connection can often be abused to achieve command execution in some form.

It is important to consider the risk that these connections can present. It is common for the ship owner to only consider the risk from an unauthenticated and unauthorised attacker with Internet access, ignoring the risk that the authenticated and authorised third-party supplier presents. The risk from the third-party supplier includes actions they can carry out that are expected and within their contracted or legal remit, but they could also potentially turn malicious.

It is common to find that remote connectivity has some means to either disconnect the system or approve a remote connection. These are not always effective or obvious. A common mechanism is a physical switch connected to a router. In one case, the switch was found to take no action at all on the system. In another, it enabled and disabled a VPN connection, but left the web and SSH server exposed to the vessel’s network. The switches are also often unlabelled, so it is unclear which direction is safe and which is unsafe. They are also prone to being left enabled after the connection has been used, with no timeout.

It is recommended that a physical means of ensuring disconnection is implemented for each system. This could take the form of a patch cable that can be unplugged or a means of isolating the power.

5.9. Energy Monitoring Systems

With the largest operating cost to most vessels being fuel, the monitoring of performance of systems has become important to most shipowners. Cloud-connected energy monitoring systems are incredibly common. By their nature, they must gather data about navigation, fuel flow, engine performance, power management etc. They are Internet-connected devices that are, in turn, connected to multiple critical OT systems.

The means by which these connections are made is often poorly documented or insecure. As a result, they can put vessels at risk.

As these systems are relatively new, they have often been retrofitted to vessels, with a lack of oversight or change management.

It is strongly recommended that the energy monitoring system and the means by which it is connected to multiple other systems is considered during the design stage.

5.10. Logical vs Physical Network Segmentation

Larger vessels have been increasingly moving towards using a “converged” network, where trunked VLANs are used to carry multiple networks down a single cable or fibre. This reduces cabling and increases flexibility.

Whilst modern logical and virtual network segmentation such as VLANs are considered adequate for many use cases, there is still a strong argument for using physical network segmentation for systems where the impact, if compromised, is severe. This could include primary essential services such as the IAMCS (automation) system or propulsion. Consideration should be given to cabling the vessel to support physically segmented networks, including regard for modification or additional systems in the future.

Running additional physical cabling also allows for future expansion and easier repairs.

5.11. Network Infrastructure

During the lifetime of a ship, changes will need to be made to the networks on board. It is common to find that the vessel is built without future-proofed network infrastructure. This includes:

• Too few wall ports.
• Racks too small for any expansion.
• Sections of the vessel with no structured cabling or infrastructure.

This has resulted in many issues found during penetration tests, mostly involving putting OT systems onto the business network as it is the only network available between two locations.

5.12. Time-pressure on Maintenance and New Installs

Over the vessel’s life, various changes will have to be made. This could be maintenance or adding new systems. The field engineers doing this work will often be under time pressure – they will often only have a single port stay to fix or install something. Their priority is making things work, not making them work securely.

This has been a root cause of many serious security issues found on vessels.

Consideration should be given to ongoing maintenance and new installs.

5.13. Cyber Attack Not Considered

Most vessels have two ECDIS for redundancy, with no paper charts. Redundancy is considered in terms of hardware failure and power, but not cyber-attack. The ECDIS are often connected together on the same network, protected by a single gateway unit. An attacker who manages to bypass the gateway could impact both ECDIS at the same time.

Similarly, the VDR rarely has any redundancy from a network perspective. Once an attacker has gained access to the network, the different components can be highly vulnerable.

For any systems that have redundancy in terms of failure, power, fire or flooding, consideration should be given to redundancy from cyber-attack.

5.14. Cascading or Coordinated Failures

E26 and E27 have multiple requirements that ensure that systems will fail to a minimal risk condition, can be operated manually or locally, and can continue to operate if the network zone is isolated. These are sensible requirements, but do not consider the impact on crew workload if many systems require manual control at the same time.

For example, if the entire automation system were to go offline, requiring manual or local control, would the crew be able to safely operate? On large and complex vessels with minimum crew, this could be very challenging.

5.15. Choice of Classification Society

Although all classification societies are implementing E26 and E27, the details and the process varies. It could be the case that one classification society has requirements that are easier to meet during one or more of the phases. For ship owners, this is of particular concern during the operation phase, where the depth and coverage during an annual survey could have significant impact on the effort required.

The requirements for DNV, Bureau Veritas, ABS and ClassNK have been examined. Whilst there are differences, none of them stand out as being clearly easier or lower effort.

5.16. Requirements for Systems Integrator

It is expected that the systems integrator (shipyard) and suppliers will carry out the bulk of the detailed design work during the design and construction phases. However, they are likely to try to minimise costs as far as is practical, which could result in a technically E26 compliant ship that is not genuinely secure and is hard to maintain during the operation phase. For this reason, it is recommended that detailed design requirements are provided by the ship owner at the design stage.

The systems inventory process in Bureau Veritas NR659 “RULES ON CYBER SECURITY FOR THE CLASSIFICATION OF MARINE UNITS” is a good process for detailing the expected systems onboard and how they are connected.

A provisional systems inventory should be provided, and could be categorised into the following groups:

• Machinery systems (in E26 scope) e.g. engines, steering gear, integrated automation systems, incinerator.
• Navigation systems (in E26 scope) e.g. ECDIS, DGPS, AIS, NavTex, radar, sonar, VDR
• Communication systems (in E26 scope) e.g. satellite communications, VHF, satellite phones, ship security alert systems
• Cargo management systems (in E26 scope) e.g. cargo control, ballast water treatment, loading PC
• Operations systems e.g. gateway, domain controller, safety management system, enterprise resource planning, crew workstations, emailing systems
• Users’ systems e.g. crew Wi-Fi, passengers Wi-Fi

For each system, the following should be provided:

• Name of system (and a description if required)
• If the system is specific to the ship owner or generic (e.g. a company internal energy monitoring system is specific, main engine is likely to be generic)
• Impact if the system is compromised (e.g. essential service impacted, operational impact, regulatory impact, inconvenience)
• Link to ashore, cloud or internet (e.g. connected to ashore for remote monitoring)
• Link to other onboard systems (e.g. Energy Management System is connected to Voyage Data Recorder).
• Expected to be in or out of scope of E26.
• Indication if the vendor is not expected to obtain E27 approval (i.e. highlight non-maritime vendors)

An example zone and conduit diagram could be provided to the systems integrator. This could constrain the design and potentially increase costs if it causes the system integrator to deviate from an already established plan of action or design.

5.17. Tracking of Information

There will be a significant amount of information gathered during the four phases of E26. Concerns were raised around tracking of this information. During the design, construction and commissioning phases, it is expected that the shipyard will track this information. Once responsibility passes to the ship owner, this information will need to be transferred. It is likely that the shipyard will use either a proprietary system (for example an ERP), or ad-hoc methods that may not be easily transferred to the ship owner.

From previous experience of new builds, the transfer could involve thousands of documents in a directory structure. This is hard to search, update and validate.

Currently, there is not a clear solution to the issue of information management under E26.

5.18. Testing

In E26 and E27 there is a heavy focus on demonstrating that systems have been securely implemented using tests defined by the supplier and systems integrator. Whilst these may demonstrate that the systems have been implemented as designed, they do not demonstrate that systems are secure.

It is vital that systems undergo conventional penetration testing. Ideally, each supplier will undertake this rather than the shipowner.

5.19. Operational Phase Considerations

The ship owner will only have limited involvement during the design, construction, and commissioning phase. The bulk of the ship owner’s work will be during the operational phase, which will be over the remaining lifespan of the vessel.

Management of change – a significant contributor to vulnerabilities found in existing fleets is poor management of change. Maritime is particularly challenging in this respect. Changes are rarely applied to an entire fleet at one time due to operational constraints, leading to each vessel having slightly different configurations. Changes are frequently made by third parties under time pressure during port stays, with no direct supervision by those knowledgeable in security. Having an effective change control process that can be used by crew and third-party suppliers is crucial.

Architecting for change – another significant contributor to vulnerabilities are network architectures and implementations that do not easily allow for change. Examples of this can include a lack of switch ports, causing people to install secondary unmanaged switches, or the inability to quickly change the VLAN a given port is on, causing someone to plug an OT system into the business network. A lack of physical cabling between spaces and across decks can lead to use logical rather than physical network segmentation. Limited rack space in the server or comms room often results in inappropriate installation of equipment in insecure locations. It is strongly recommended that the vessel’s network is architected to allow easy change over the lifetime of the vessel.

Backups for OT – a significant part of operation phase is respond and recover, which involves the backup of OT systems. Previously, obtaining backups of OT systems, particularly those configured by third parties, has been challenging. It is hoped that suppliers will provide backups as part of E27, but this should be enforced by the systems integrator so that the ship owner has adequate backups as they enter the operation phase.

Depth and coverage of survey – currently surveyors have only limited training with respect to cyber security issues. They are looking for the most basic of issues such as passwords on labels and clearly incorrect or missing documentation. This is expected to change, but to what extent? How much depth will surveyors examine vessels?

Suppliers going out of business – Any supplier providing a system under E27 must be able to provide security updates. ClassNK have suggested that if a supplier goes out of business, then the system must be replaced. This is a concern, as the vessels are expected to have a lifespan of 15 years, during which it is highly likely that some vendors will go out of business. Is there a means to reduce the impact of this, should it happen?