Mechanisms for Securing Autonomous Shipping Services and Machine Learning Algorithms for Misbehaviour Detection

Abstract

Technological developments within the maritime sector are resulting in rapid progress that will see the commercial use of autonomous vessels, known as Maritime Autonomous Surface Ships (MASSs). Such ships are equipped with a range of advanced technologies, such as IoT devices, artificial intelligence (AI) systems, machine learning (ML)-based algorithms, and augmented reality (AR) tools. Through such technologies, the autonomous vessels can be remotely controlled from Shore Control Centres (SCCs) by using real-time data to optimise their operations, enhance safety, and reduce the possibility of human error. Apart from the regulatory aspects, which are under definition by the International Maritime Organisation (IMO), cybersecurity vulnerabilities must be considered and properly addressed to prevent such complex systems from being tampered with. This paper proposes an approach that operates on two different levels to address cybersecurity. On one side, our solution is intended to secure communication channels between the SCCs and the vessels using Secure Exchange and COMmunication (SECOM) standard; on the other side, it aims to secure the underlying digital infrastructure in charge of data collection, storage and processing by relying on a set of machine learning (ML) algorithms for anomaly and intrusion detection. The proposed approach is validated against a real implementation of the SCC deployed in the Livorno seaport premises. Finally, the experimental results and the performance evaluation are provided to assess its effectiveness accordingly.

1. Introduction

Maritime Autonomous Surface Ships (MASSs) are defined as ships that can operate independently of interaction with humans to a certain degree. According to the International Maritime Organisation (IMO) [1], the international shipping’s global regulatory body, such degrees of autonomy are defined as follows:

• Degree 1: Ship with automated processes and decision support. The seafarers are on board to operate and control shipboard systems and functions. Some operations may be automated and at times be unsupervised, but with seafarers on board ready to take control;
• Degree 2: Remotely controlled ship with seafarers on board. The ship is controlled and operated from another location. Seafarers are available on board to take control and operate the shipboard systems if needed;
• Degree 3: Remotely controlled ship without seafarers on board. The ship is controlled and operated from another location. There are no seafarers on board;
• Degree 4: Fully autonomous ship. The ship’s operating system can make decisions and determine actions by itself without human intervention.

Depending on the degree of autonomy, autonomous ships can offer considerable benefits in terms of safety, efficiency, and improved operation. However, as a novel presence in the global maritime industry (Degree 3 and Degree 4 are not expected until the 2030s and 2040s), they face significant cybersecurity issues. Addressing potential vulnerabilities to cyberattacks and ensuring that robust cybersecurity measures are in place is important to prevent any unauthorised access or manipulation of the ship’s systems.

The cyberattack surface of autonomous vessels is closely related to the level of autonomy, since the attack surface may vary with the complexity of the number of systems to control and monitor the vessels. Although the cyberattack surface is not well-defined yet, it might consist of attacks aiming at intercepting and manipulating communications or on-board IoT devices, attacks on Information and Communication Technology (ICT) systems (on-board or remote), attacks on AI/ML-based systems used for autonomous operations, or even physical attacks aiming at taking control of the uncrewed vessel.

In this paper, we address the security of the digital infrastructure used for enabling autonomous shipping functionalities by considering all the components of this kind of system, that is the ship, the Remote Operations Centre (ROC), and the communication channel between the first two elements. In this perspective, we addressed the security of the system by focusing on two aspects. On one side, we proposed an approach to secure the communication channel between the Shore Control Centre and the vessel, relying on IEC 63173-2 Secure Exchange and COMmunication (SECOM) standard [2] by implementing cryptography techniques, including a Public Key Infrastructure (PKI) and key exchange mechanisms. For autonomous vessels more than conventionally manned ships, efficient and secure ship-to-shore communication is a key aspect for safe operations. The SECOM protocol ensures end-to-end data integrity, data confidentiality, and authentication processes. On the other side, we secured the digital infrastructure on the shore, deployed in the Livorno seaport, which is responsible for hosting and running the SCC applications and data collection, storage, and processing. Therefore, a combination of the Deep Autoencoder and Hierarchical Density-Based Spatial Clustering (HD-DNCAE [3]) ML-based algorithms was developed to provide the digital infrastructure with both anomalies and system intrusion detection capabilities, conforming with the zero-touch approach. The ICT Prototyping Framework [4] was adopted and used as a reference architecture and framework for the development and deployment of the components of the autonomous shipping application used for the experimental validation of the proposed approach.

The first challenge was to implement the SECOM standard to secure the communication channel by adopting a microservice architecture. The use of an ICT framework with a layered structure made possible this approach, which is a novelty in the maritime landscape. Employing a microservice architecture enables the possibility to address the scalability and fault-tolerance aspects, which are crucial in the autonomous shipping context. Furthermore, it has been challenging to develop an anomaly and intrusion detection ML-based algorithm that takes into account misbehaviour coming from the on-shore infrastructure (e.g., anomalous readings from a sensor deployed in the port area or an intrusion on the land-side infrastructure). It is normal to think that systems on board the ship are not designed with cybersecurity as a consideration because of their “air-gapped by default” status [5] and so they are more exposed to cyberattacks, but in the autonomous shipping landscape it is also fundamental to consider the cyber-resilience to attacks for the land-side infrastructure that may be devoted to the remote monitoring and control of the ship during the manoeuvres. In addition, the proposed model is very flexible, as it does not require defining the number of clusters in advance but can learn how to classify data on its own. Therefore, the contribution and novelty of this paper can be summarized in two main points:

• The implementation of the SECOM standard using a microservice-based approach allowed us to ensure end-to-end data integrity, confidentiality (data encryption), non-repudiation (employing private keys), and authentication mechanisms (for data and services through JSON Web Tokens—JWT) by establishing a secure communication channel between the ship and the SCC to mitigate traditional cybersecurity vulnerabilities of the maritime communication systems (e.g., man-in-the-middle and distributed denial-of-service);
• The implementation of the HD-DNCAE deep learning algorithm on top of the ICT infrastructure of the Livorno seaport allowed us to detect known and novel cyberattacks on the existing digital infrastructure without predefining the number of clusters and to provide an optimal Area Under the Curve (AUC) score leading to a better clustering of data.

The rest of this paper is organised as follows: Section 2 addresses relevant related works; Section 3 describes the reference architecture used for the application development as well as the application itself; Section 4 is focused on the SECOM standard by describing how it was applied to the considered scenario; Section 5 describes ML algorithms and how they were applied to detect anomalies and intrusions within the underlying digital infrastructure; in Section 6 experimental setup and performance evaluation are described; finally, Section 7 presents a discussion of the main findings of the paper and future works.

2. Related Works

Anomaly detection within the maritime domain has been researched through the use of Automatic Identification System (AIS) data, trajectory analysis, cloud-based frameworks, and ML-based techniques to enhance the level of security and situational awareness in the maritime environment.

Wolsing et al. (2022) [6] made note that the methods for detecting anomalies in the AIS tracks are course deviation and unexpected port arrivals as features for showing suspicious operations and keeping the maritime domain safe. Recently, Nguyen et al. (2024) [3] proposed an approach for network intrusion detection using deep autoencoders in a Deep Nested Clustering Autoencoder (DNCAE) model to enhance anomaly detection through the learning of a better representation of normal network data in latent space and creating tighter regions of clusters using the K-means clustering technique. Al-Khazraji et al. (2022) [7] proposed a solution to estimate the Remaining Useful Life for aircraft engines adopting an autoencoder-based Deep Belief Network model.

Kim et al. (2021) [8] conducted research for the detection of sensor data anomalies from maritime engines. They used ensemble learning techniques to combine various machine learning models to increase the overall accuracy and robustness of the developed anomaly detection system, especially in accurately identifying network intrusion among IT systems used in the maritime industry. Farahnakian et al. (2023) [9] demonstrated that the K-means clustering method was able to effectively detect ships or those sets of vessels that turn off the AIS transceivers to perform illegal activities.

Other studies focused on the trajectories’ analysis instead of focusing on the AIS data to discover anomalous behaviours and intrusions. Hu et al. (2023) [10] developed a Transfer Learning-based Trajectory Anomaly Detection strategy for IoT-empowered Maritime Transportation Systems to explore the spatial similarity between normal trajectories and train the trajectory anomaly detection model. Anneken et al. (2020) [11] proposed a novel approach to model the uncertainty of the vessels’ movements while following a route by adopting clustering techniques based on the estimation of the probability of a deviation from the given trajectory.

On the other side, cybersecurity threats affecting the communication channel between the ship and the shore, as well as the ones affecting the land information system, must be considered. Nganga et al. (2023) [5] researched to better understand both enabling factors and challenges impacting the effectiveness of Maritime Security Operation Centres (M-SOC), which are the ancestors of the Remote Operations Centres. Ashraf et al. (2022) [12] and Tabish et al. (2024) [13] conducted studies to identify the cyberthreats affecting the maritime domain in its entirety and discuss risk assessment methods and possible recommendations and countermeasures. Balduzzi and Pasta (2014) [14] conducted a security evaluation of the AIS implementations and communication protocols specifications by identifying a set of threats related to both the software and the hardware equipment such as ship spoofing, hijacking, or availability disruption (e.g., frequency hopping, timing attacks, or slot starvation). Zhang et al. (2023) [15] proposed a blockchain-based architecture with a reputation voting mechanism for making the consensus process able to improve anti-attack capabilities. The proposed mutual authentication scheme was validated through simulation studies, which phase out the performance benefits in terms of data integrity and confidentiality. Furthermore, Chung et al. (2018) [16] proposed a route plan exchange scheme based on a blockchain, pointing out the need for a distributed PKI for the port community actors to guarantee a secure information exchange mechanism.

These studies demonstrate the need for appropriate security measures for protecting and securing both the autonomous ships and the land digital infrastructures they rely on for data exchange, as well as the communication channel between them.

3. The Reference Architecture

The Port Authority of Livorno has invested in the standardisation of an ICT reference stack structured as a private cloud, as described in [4]. The infrastructure allows for the development of Platform-as-a-Service (PaaS) and Software-as-a-Service (SaaS) functions in the shape of microservices and exposes them through a standard set of Application Programming Interfaces (APIs) for the development of smart applications. Network and computing resources are organised in tenants, serving end users according to their needs. We relied on the above-mentioned architecture for the implementation, validation, and development of the Shore Control Centre applications as well as of the ML-based algorithms.

The scenario considered in this paper is depicted in the block diagram in Figure 1. As it can be seen, the communication channel between the vessel and the SCC we are interested in securing is using a 5G private terrestrial network, while the anomalies and intrusions detection mechanisms are applied to the machine-to-machine platform, which is part of the digital infrastructure of the Livorno seaport.

All the applications of the SCC (e.g., SenseNOES, digital twin, and Vessel Companion) are developed on top of the machine-to-machine platform, which is responsible for gathering and storing raw data coming from the distributed monitoring network deployed in the Livorno seaport. As these datasets are shared with the vessel for remote operations, data integrity, availability, and confidentiality must be guaranteed and any potential anomaly or intrusion within the digital infrastructure aimed at manipulating existing datasets needs to be detected and prevented in time.

The Shore Control Centre (SCC)

In 2006, the Maritime Safety Committee (MSC) first brought to attention the concept of e-navigation and, since then, has been coordinating the work on the development of a strategy with active participation from relevant IMO sub-committees, member states, international organisations (e.g., IALA and IHO), and industry representatives. E-navigation ([17]) is the harmonised collection, integration, exchange, presentation, and analysis of marine information on board and ashore by electronic means to enhance berth-to-berth navigation and related services for safety and security at sea and protection of the marine environment. The standardisation process will follow high-level directives for three invariants: Remote Operations Centre (ROC) functionalities, ship assets for a digital ship, and the seaport physical/digital infrastructure.

The vessels interact with the ports offering and consuming a wide range of digital services like functionalities exposed by the Port Community Systems (PCSs) and Terminal Operating Systems (TOCs) and representing the Day X Maritime Services [18] such as the following:

• Real-time vessel tracking and monitoring in deep sea sailing and port waters;
• Plans for operating the vessel, updated according to changes and feedback;
• Vessel Collision Avoidance (e.g., early detection of dangerous situations and recalculation of the best path for the vessel);
• Vessel Arrival Slot Management (e.g., Just-In-Time arrival, pre-booking of berths and yard resources, customs pre-clearing, etc.);
• Calculation and measurement of pollution levels (e.g., COx and noise) and changes to the routing plan of the vessel;
• Containerised and general cargo pervasive monitoring and control in port areas and along the logistics chain.

The Remote Operations Centre is the natural evolution of the Maritime Security Operation Centre [5] and is supposed to be an infrastructure placed ashore (hence why we refer to it as the Shore Control Centre), which is accessible and fully integrated with the port digital infrastructure. It must also be able to combine the information from the land side with that coming from the vessel to enable all the required services and functionalities for the monitoring and the direct control of the ship, the handling of communication, the planning and the organisation of activities in the port area, and the production of documentation.

We implemented and deployed a prototype of the SCC at the Joint Laboratory for Seaports (JLAB-Ports [19]) in Livorno, in the context of the 5G MASS project [20] activities. The SCC is structured as a set of applications running as Software-as-a-Service in a private cloud. The architecture includes an Authentication and Authorisation server to monitor and manage access to the services through user profiling. The communication between the SCC and the ship approaching the port is guaranteed by a 5G millimetre-wave private network in a stand-alone configuration operating in the n258 frequency band (26 GHz) with a nominal bandwidth of up to 10 Gbps. The 5G Core Network is hosted at the JLab-Ports premises, in Livorno.

The applications composing the Shore Control Centre are based on the real-time availability of the information coming from the ship to the shore and vice versa, which is exchanged through the 5G private network. In particular, the SCC makes use of port-related data and a snapshot of the seaport area through the high-definition monitoring network (10 cameras) and the data coming from the sensor network of the Port of Livorno (bathymetric probes, weather stations, anemometers, current meters, wave meters, noise, and environmental sensors). Moreover, the SCC can exploit the information coming from the shipboard as well as from the sensors installed on board (e.g., cameras and Light Detection and Ranging sensors—LIDARs). The exact positioning of the ship (in the order of 10 cm) is guaranteed by the presence of a Real-Time Kinematics (RTK) network.

Figure 2 shows some of the applications composing the SCC in Livorno that enable the control and monitoring of the ship while approaching the berth as well as the current weather and marine conditions to detect potential security and safety issues and support the risk assessment based on IMO/EU standards. The applications we are going to present below are only examples of the subset of functionalities that can be provided considering the data at our disposal, without claims of completeness.

The Shore Control Centre application (Figure 2a) is a 2D map visualising the vessels within the port area and the ship that is entering the port. The application shows the trajectory and includes a real-time computation of the optimal route that a given ship should follow to reach the assigned berth. The application can also visualise eventual alerts and alarms that may arise during the manoeuvre in case the ship deviates from the optimal route. Figure 2b shows the digital twinof the ship on a 3D map during the approach to the berth together with the information coming from the shipboard in real-time, e.g., the NMEA 0183 [21] sentences shown on the Electronic Chart Display and Information System (ECDIS) on board the ship. The Vessel Companion Chat(Figure 2c) has a counterpart running on a portable device used on board the ship and allows for the real-time exchange of information from the ship to the shore and vice versa, together with the visualisation on the SCC of information coming from the ship side. Finally, Figure 2d shows the SenseNOES application that allows the visualisation of all the sensors installed in the port area for monitoring purposes, including their position and the last reading they produced.

4. The SECOM Standard

The increase in reliance on digital systems in the maritime domain has paved the way for a wide range of cyberattacks. These cyberattacks can lead to compromised operational security, potential disruptions to business operations, and data breaches. One key aspect in mitigating these concerns is the adoption of standardised procedures and protocols for secure data transmission and communication, such as the SECOM standard [2]. IEC 63173-2 SECOM is an international standard defining a secure communication protocol between a ship and an SCC, which provides capabilities for secure data exchange with technical services that are defined by IALA [22] and partly included in the IHO S-100 standard [23]. The standard includes information service interfaces (APIs) for the data exchange, and information security measures using a Public Key Infrastructure (PKI), covering communication channel security and data protection aspects. The exchange of messages between the ship and the SCC relies on IP-based web services.

The SECOM components provide measures to meet the security requirements of the applications such as data authentication and integrity, service authentication and mutual TLS, data confidentiality and secure communication channels, access control, and identification through a common registry for unique identities.

Due to the complexity of maritime networks, in addition to a secure communication protocol capability between the ship and SCC, there is a need for a framework that can properly address scalability as well as fault-tolerance-related aspects. Hence, the SECOM standard is implemented relying on a microservice architecture (namely MSA-based SECOM). The MSA-based SECOM is deployed on the SCC, and it comprises different microservices, as shown in Figure 3. Some are employed for non-functional requirements, such as the API Gateway, the discovery server, the authentication and authorisation server, the distributed tracing mechanism, and the message broker. Then, there is a suite of microservices that are required to implement the SECOM functionalities, such as the symmetric encryption and symmetric decryption, the asymmetric encryption and signature, the asymmetric decryption and signature verification, the key generator, and WebSocket. The main purpose of the SECOM standard is to enable the exchange of information that is consistent with the S-100 data model from the ship to the SCC and vice versa in such a way that the security requirements are fulfilled.

As shown in Figure 4, the SECOM system architecture has three main blocks: the ship side, the MSA-based SECOM suite, and the SCC side. On the ship side, users are connected through a browser and can exploit the functionalities provided by the ship-side microservices. They are provided with a digital certificate and a private key to encrypt messages to be sent to the shore. The SCC operator also has his own certificate and a private key and can send encrypted messages to the ship side.

To achieve the capability of exchanging messages, the ship sends an HTTP request to the API Gateway acting as a proxy. The gateway in turn redirects the request to the authentication server that has to authorise it. If the request is approved, it is redirected to the microservice that allows the ship to establish a WebSocket connection and make a digital copy of all the services on its side. At this point, the microservice starts to interact with the other microservices to finally provide the user with a shared key, enabling end-to-end encryption between the two entities. Having the shared key, the ship sends an encrypted and authenticated message to the SCC. Assuming the SCC has undergone the authentication step and has established a WebSocket connection, the SCC can receive the messages, verify that they arrived from the ship, and decrypt them using the shared key.

4.1. Data Integrity and Confidentiality

The data protection scheme of the SECOM standard is provided by a suite of microservices, first generating a shared key between the ship and the SCC, then using this key to encrypt the information and ensure confidentiality by adding a tag for integrity and authenticity of the message. In this schema, each entity authenticates with the authentication server through the API Gateway and then obtains an ID token as well as an access token. Then, each side establishes a WebSocket with the support of the WebSocket microservice for dual communication between the parties. The ship side first requests to the CA the certificate of the other party; it then requests the key generator microservice to generate a pair of Diffie–Hellman (DH) private and public keys. It obtains the public key of the shore side, encrypts the message with its public key, generates a signature with the asymmetric encryption and signature microservice, and forwards it to the SCC together with its CA-signed public key. At this point, the SCC side also requests the key generator microservice to generate a DH private and public keys pair. First, it retrieves the ship-side certificate from the previous message and verifies and decrypts the received message through the asymmetric decryption and signature verification microservice. Then, the shore side signs its public key and the message with its private key and forwards it back, concatenating with its certificate. From now on, the SCC can generate the shared key by combining the ship’s public DH key that was received and its generated DH private key, through the key generator microservice. Since the ship has also received the message, it first decrypts and verifies it, retrieves the DH public key of the SCC, combines it with its own DH private key, and generates the shared key. At this point, both parties have the same shared key that can be used to encrypt the messages and generate integrity tags to send the information from one side to the other through the symmetric encryption microservice. Through these interactions, the message is confidential, and its integrity is guaranteed. The other side uses a Symmetric Decryption microservice to verify the tag and decrypt the message by using the shared key.

To establish a secure communication channel, we have implemented mutual authentication on each side, as both sides act as a service provider and a consumer at the same time. Each microservice has its certificate and private key stored in a key store and a CA certificate in a trust store. Whenever a microservice wants to serve a request, it has to provide the certificate to authenticate itself but, on the other hand, it needs to authenticate the service requester by asking for the certificate and verifying it against the CA certificate in the trust store. This allows the system to establish a secure communication channel, providing data integrity and confidentiality capabilities.

4.2. Authentication

Similarly to data integrity and confidentiality, in the SECOM implementation the authentication is achieved at three levels: through the adoption of an authentication and authorisation server, data protection, and a secure communication channel. Authentication is the process by which a user or service proves to a system its identity. When a user or a service wants to use the SECOM standard, it first has to authenticate itself through the authorisation server by providing the credentials and has to obtain a JWT access token for the microservices interfaces. The second level of authentication is through the data protection scheme, with the establishment of the shared key between the ship and the SCC. Parties exchange certificates signed by the CA, which is a trusted third party and can verify the authenticity of the messages. Finally, the third level of authentication is achieved through the SECOM secure communication channel, which provides service authentication on top of data integrity and confidentiality. It also provides a secure channel for the authentication of the functionalities exposed by each microservice.

5. Machine Learning Algorithms

As presented in Section 2, existing machine learning algorithms still have some limitations. To overcome such limitations, we propose an approach to integrate HDBSCAN into DNCAE during the clustering of the latent space and label it HDBSCAN Deep Nested Clustering Autoencoder(HD-DNCAE). Our approach can exploit the benefits of deep autoencoders in learning compact and meaningful data representations, where the current cluster configurations can be adapted in the latent space without prior determination of the number of such clusters. This increases not only the ability of the model to capture the underlying structure of data but also its adaptability to changing patterns of the data, which is crucial for network intrusion detection systems in highly dynamic contexts, such as ports.

5.1. Model Architecture

The HD-DNCAE model is a re-engineered model from the novel DNCAE proposed in [3], which is to serve as a reference algorithm fitted to detect anomalies in a dynamically changing cloud environment with dynamically changing datasets.

Figure 5 shows the architectural view of the HD-DNCAE, which consists of the outer encoder, inner encoder, inner decoder, and outer decoder. The architecture also contains some functions that perform specific tasks such as calculating the clustering loss, calculating reconstruction loss for both the inner and outer deep autoencoders, and a co-training function.

The DNCAE model tries to capture the underlying clustered architecture so as to minimise the “normal region” on the latent space representation; this is achieved by using K-means clustering techniques. We propose the use of Hierarchical Density-Based Spatial of Applications with Noise (HDBSCAN) [24] for the following reasons:

• HDBSCAN is capable of clustering a variety of datasets with varying cluster sizes and densities;
• Using HDBSCAN we have to set only one parameter as compared to K-means, thereby allowing us to maintain a zero-touch approach.

5.2. The Deep Autoencoder

The DAE trains in such a way that it tries to reduce the reconstruction error between the data given as the input and the data obtained as the output. The DAE in the HD-DNCAE includes the inner DAE and the outer DAE. A single DAE consists of an encoder and a decoder. The encoder takes inputs $\mathbf{X}$ and maps these inputs from the input space to the latent space using the function $\mathbf{F}(·)$, while the decoder tries to reconstruct the output $\widehat{\mathbf{X}}$ from the latent space into the output space using the function $\mathbf{G}(·)$. The Equations (1) and (2) are a general representation of the encoder and decoder functions:

$$\mathbf{H}={\mathbf{F}}_{\mathrm{\Theta }}\left(\mathbf{X}\right)$$

(1)

$$\widehat{\mathbf{X}}={\mathbf{G}}_{\mathrm{\Phi }}\left(\mathbf{H}\right)={\mathbf{G}}_{\mathrm{\Phi }}\left({\mathbf{F}}_{\mathrm{\Theta }}\left(\mathbf{X}\right)\right)$$

(2)

In the HD-DNCAE, the first outer encoder takes the input $\mathbf{X}$ and maps it into the latent space $\mathbf{H}={\mathbf{F}}_{\mathrm{\Theta }}\left(\mathbf{X}\right)$. Then, the inner encoder takes $\mathbf{H}$ and maps it into a second latent representation $\mathbf{Y}={\mathbf{F}}_{\mathrm{\Theta }}\left(\mathbf{H}\right)$. The output of the first encoder serves as input for the second encoder. From this point, the inner decoder takes $\mathbf{Y}$ (a latent space representation) and reconstructs $\widehat{\mathbf{H}}={\mathbf{G}}_{\mathrm{\Phi }}\left(\mathbf{Y}\right)$, and the outer decoder takes $\widehat{\mathbf{H}}$ (a latent representation) and reconstructs $\widehat{\mathbf{X}}={\mathbf{G}}_{\mathrm{\Phi }}\left(\widehat{\mathbf{H}}\right)$.

The DAE is a deep neural network with a non-linear activation function. $\mathrm{\Theta }$ represents the weights of the encoder, while $\mathrm{\Phi }$ represents the biases of the decoder. The HDBSCAN clustering algorithm is integrated into the latent layer of the outer DAE. This algorithm clusters the data points within this layer into optimal subclusters. The inner DAE refines the important and core features while simultaneously trying to reduce the normal region in the latent layer.

5.3. Clustering and Reconstruction Loss

As per Equation (3), we train the DAEs with the Mean Squared Error (MSE) used for reconstruction loss. This metric helps to measure the difference between the original input data and the reconstructed output from the autoencoder. The reconstruction loss is important since it directly affects the capacity of the autoencoder to capture and reproduce the underlying data distribution.

$$\mathrm{MSE}={\displaystyle \frac{1}{n}}\sum _{i=1}^n{\left(Y_i-{\widehat{Y}}_i\right)}^2$$

(3)

We then add a clustering lossbased on the HDBSCAN algorithm. This is an unsupervised learning technique that helps to find density-based clusters within the latent space features generated by the autoencoder. The loss is simply the clustering loss based on the score given by the cluster validity scores of HDBSCAN. It applies a penalty if the clustering results in only one cluster, as it is necessary to form multiple, distinct clusters to distinguish among the different patterns inside the data. The total loss function of the HD-DNCAE model is a combination of these three kinds of losses (outer DAE Loss, inner DAE Loss, and clustering loss), where the scheme’s control hyperparameters are $\alpha$, $\beta$, and $\gamma$. Such a scheme allows fine-tuning between accurate data reconstruction and effective clustering. Balance in the importance of each of these aspects acquired in the developed model is achieved by adjusting these weights, hence optimising its performance for some datasets. We performed a grid search using the values 0.1, 0.5, and 1 for each hyperparameter to select their best value.

5.4. Co-Training

In the training phase, we used a co-training method to train the HD-DNCAE by considering only normal data from the dataset. Figure 6 shows the training flow during the co-training phase.

Various optimisers such as Stochastic Gradient Descent (SGD) with momentum, Adaptive Delta (Adadelta),and Adaptive Moment Estimation (Adam) were tested and their AUC Scores were compared. The results showed that SGD with momentum and Adadelta performed better, as shown in Figure 7. We updated the weights and biases of our deep neural network (HD-DNCAE) by using each of the chosen optimisers. The HD-DNCAE was trained to learn the information and meaningful representations in the latent layers of normal data fed into the neural network. Then, the model was used to train a simple One-Class Classifier, such as a Support Vector Machine (SVM), with a variety of kernels (Linear, Poly, RBF, and Sigmoid). Furthermore, we trained using Isolation Forest (IF), Local Outlier Factor (LOF), Elliptic Envelope (EP), Centroid (CEN), and Kernel Density Estimation (KDE). These classifiers were chosen based on the work performed by [3].

In the post-training stage, anomaly detection is carried out by adopting both trained latent representations and clustering configurations. The detection of anomalies uses deviations from normal data patterns, as they have been modelled in the latent spaces with dynamic clustering to add more granularity and point out outliers.

6. Performance Evaluation

6.1. SECOM Implementation and Validation

6.1.1. Experimental Setup

The implementation of each component of the SECOM standard is performed using a Javascript framework called Spring Boot [25]. The framework follows a layered architecture that consists of a presentation layer, a business layer, and a persistence layer running on a 4-core Linux server with 8GB RAM and installed using the JDK (Java development kit), Docker engine and Docker-compose in the Livorno ICT stack.

The proposed SECOM implementation is composed of different microservices organised in three layers: the API access layer, the aggregation layer, and the application logic layer. The API access layer includes the Spring Cloud API Gateway [26] and the Keycloak [27] server for authentication and authorisation. The aggregation layer includes the Eureka [28] discovery server, the Kafka [29] message broker, and the Zipkin [30] distributed tracing system. Finally, the application logic layer consists of the ship and the SCC microservices as well as of the SECOM security suite (WebSocket, encryption, decryption, asymmetric encryption and signature creation, asymmetric decryption and signature verification, and key generator microservices). All these microservices are working independently and running in their dedicated Docker-containerised environment. To containerise all microservices, we relied on a Maven plugin called JIB [31]. Then, we added the configuration of each microservice to a Docker-compose file to be able to orchestrate the multiple interconnected services in our system implementation. Some of the dependencies used are JCA (Java Cryptographic Cypher) and JSE (Java security), which provide the core security functionalities such as secret key generation, DH public and private key generation, and encoding. In addition to these Java libraries, we also used (i) Spring Boot dependencies, such as Starter Web and Lombok [32], which provide necessary components for building web applications using the Spring MVC framework; (ii) Web Client dependency for HTTP requests; (iii) Kafka dependencies; (iv) OAuth2 client and OAuth2 resource server dependencies, which allow the client to interact with the authorisation server; and (v) dependencies for the discovery server registration.

After configuring all this, our main purpose was to generate a shared key (using an authenticated Diffie–Hellman key) to be exchanged among the ship and the SCC for encrypting and sending an authenticated and confidential message over an unsecured public network. To achieve this, the users make a request through the API Gateway and become subscribed to the topics required for the key exchange (functionality provided by the WebSocket microservice). Consequently, it is possible to make a copy (a digital twin) of the ship and SCC microservices. However, this operation is successful only if the users are authenticated and authorised through the Keycloak server and, subsequently, are provided with an ID and an access token accordingly. In addition to the trust and key stores used for establishing the mutual TLS channel between the digital twin of the ship and the SCC microservices, we also prepared certificates and private keys using OpenSSL [33]. Once a secure communication channel is established, all microservices can interact with the SECOM security suite, synchronously or asynchronously, using the Kafka message broker, and establish a shared key. During this interaction, the Eureka discovery server is used, together with Spring Cloud API Gateway, to discover all the microservices that have been pre-registered, while the routes and interactions among the microservices are traced using Zipkin.

6.1.2. Experimental Results

After spinning all the containers using Docker-compose commands, SECOM can be used as a secure infrastructure by the users (from the ship and ashore). Both end users (the bridge team and the seafarers) bootstrap the application and are redirected to the Keycloak login page for authentication. Assuming each user has been authenticated successfully, they are provided with an ID and an access token so that they can use every microservice. After that, users are redirected to the home page of the application. From this point on, each user can establish a shared key when they want to send a message to the other side. In our case, the bridge team wants to send a sample vessel routing plan to the seafarers, as can be seen in Figure 8 and Figure 9.

The same shared key is established in both parties using the Diffie–Hellman key exchange protocol. The bridge team uses this key to encrypt the message, generate a tag, and finally send the message to the seafarers. The seafarers authenticate the tag, decrypt the message, and can view the message in clear text. During the data exchange process, data integrity and confidentiality, as well as service authentication, are guaranteed by the SECOM standard. The implemented system is also fault-tolerant and scalable, since each microservice is independent and can be easily scaled by running multiple instances. On top of this, all the requests can be load-balanced by the API Gateway in case of high naval traffic and traced by Zipkin.

6.2. Machine Learning Algorithms’ Implementation and Validation

6.2.1. Experimental Setup

The test bed for building the machine learning algorithms for anomaly detection consists of both hardware and software configurations. The proposed models were built and tested on a machine with Intel Core i78700 CPU, which operates with 12 cores at a speed of 3.20 GHz, has RAM of 16 GB, and a dedicated Graphical Processing Unit (GPU) of type NVIDIA GeForce RTX 2060 Rev. This setup helps with multitasking, management of our large dataset, and intensive computation that are parallelisable. The operating system of the test bed is Ubuntu 22.04.4 LTS 64-bit; Python3.8 is installed on the OS and Jupyter Notebook [34] is utilised as a development environment. The libraries used for building the neural network are PyThorch [35], which helps us utilise the GPU to accelerate the development process and HDBSCAN from Scikit-learn [24], which is compatible with Python and is used for clustering. In the preprocessing phase, Numpy [36] and Pandas [37] were used, while Matplotlib [38] and Seaborn [39] were used for plots.

6.2.2. Experimental Results

To evaluate the efficiency of our models, we employed the use of Area Under the Curve-Receiver Operating Characteristics (AUC-ROC). The AUC-ROC was selected because our model tries to classify between two classes (anomalous and benign), and the AUC-ROC has the ability to perform binary classification. The ROC plots a graph of the True Positive Rate (TPR) against the False Positive Rate (FPR) at various thresholds. Both TPR and FPR are defined in the Equations (4) and (5):

$$\mathrm{TPR}={\displaystyle \frac{\mathrm{TP}}{\mathrm{TP}+\mathrm{FN}}}$$

(4)

$$\mathrm{FPR}={\displaystyle \frac{\mathrm{FP}}{\mathrm{FP}+\mathrm{TN}}}$$

(5)

where TP stands for true positive, FN stands for false negative, FP stands for false positive, and TN stands for true negative

$$\mathrm{AUC}={\int }_0^1\mathrm{TPR}\left(t\right)d\mathrm{FPR}\left(t\right)$$

(6)

The AUC measures the area under the ROC and provides a value that shows how well the model is able to distinguish between positive and negative classes. When the value is equal to 1, it has perfectly classified the object; instead, when the value is equal to 0.5, it performs a random guess; finally, when the value is less than 0.5, it performs worse than a random guess, and we can assume the model is confused and not learning any useful pattern. The AUC is calculated using the equation in Equation (6), where t is the decision threshold.

The datasets used for the evaluation of the proposed algorithm (HD-DNCAE) include benchmark data such as the NSL-KDD [40], UNSW-NB15 [41], and CIC-IDS2017 [42]. The NSL-KDD dataset is based on the data captured in the DARPA’98 Intrusion Detection System (IDS) evaluation program and has been the most widely used dataset for the evaluation of anomaly detection methods. UNSW-NB15 is a comprehensive dataset for network intrusion detection systems, which contains raw network packets and includes nine different attacks. The CIC-IDS2017 dataset contains benign data and the most up-to-date common attacks, which resemble true real-world data. It also includes the results of the network traffic analysis with labelled flows based on the time stamp, source, and destination IPs, source and destination ports, protocols, and attacks. These datasets were used as a baseline for the benchmarking of the outcomes of the proposed model.

Finally, network-related datasets have been collected from the Livorno ICT stack as well as from the underlying machine-to-machine platform (namely Mobius oneM2M [43]), which is used to collect and store data coming from the IoT monitoring network deployed in the Livorno seaport (e.g., weather conditions, noise and pollution levels, etc.). The main parameters that are taken into consideration include IP address and port, protocol, timestamps, flow duration and rate, packet count and length, inter-arrival times, and several TCP tags.

The table in Figure 10 shows the results of the DNCAE algorithm from the work in [3]. Figure 11 and Figure 12 show the result of the HD-DNCAE algorithm using two different optimisers. From a simple glance, the DNCAE performs better in most of the one-class classifiers across the datasets. However, when we look closely, we can see that in areas where the DNCAE performs poorly, the HD-DNCAE mostly has doubled its accuracy. When we take the Local Outlier Factor (LOF), HD-DNCAE outperforms DNCAE across all the datasets.

Figure 13 shows the best scores obtained across the datasets for each of the algorithms. As we can see from the plot, HD-DNCAE performs similarly to DNCAE while not requiring setting the number of clusters in advance. This brings us closer to the zero-touch approach for our security module being deployed inside the Livorno ICT stack.

7. Conclusions and Future Work

In this paper, we addressed the security challenges related to the maritime domain by implementing the SECOM standard for securing the communication channel between the ship and the Shore Control Centre and by testing the machine learning algorithms for anomaly detection on the ICT reference stack of the Port of Livorno.

The proposed implementation of the SECOM standard uses a secure and scalable microservice architecture and provides data and service authentication, confidentiality, integrity, identification, and non-repudiation. Confidentiality was achieved as the shared key was only known to the parties involved in the encryption step (ship and SCC). This property is guaranteed since each public key is signed by the sender and encrypted with the receiver’s certificate. Hence, it will be difficult for the parties not involved in the communication to intercept the shared key, unless they have the private key of both sides. In addition, messages cannot be repudiated, as we can verify that the message encrypted and sent over the channel came from the entity that holds the same shared key as the receiver. Data integrity and authentication were also guaranteed as the message is encrypted using AES with GCM mode and so has a tag attached to it that can be generated only by the key pair holders. On top of this, the implementation of a mutual authentication procedure for the authentication among the microservices provides service authentication property. Moreover, the scalability and robustness of our system addresses security challenges faced in the communication relying on the IHO S-100 [23] compliant messages. Scalability and robustness enable improved fault tolerance and better performance and efficiency for services in case of high traffic loads and multiple requests. Finally, the identification was achieved as each service consumer needs to be authenticated with the pre-registered credentials using only valid access and JWT tokens. Hence, the implementation of the SECOM standard based on a microservice architecture addresses the security challenges existing in the maritime sector and traditional monolithic applications. On one side, our implementation provides a mutual authentication procedure to guarantee service authentication among microservices. On the other side, it provides the capability to generate and share keys among the parties (e.g., ship and the SCC) so that the information travelling through untrusted public networks can be exchanged securely.

The future direction of the proposed implementation of the SECOM standard involves orchestrating microservices using advanced tools like Kubernetes. This approach aims to improve system resilience, fault tolerance, and scalability, especially under heavy network traffic or system failure conditions. Additionally, integrating a centralised log-tracing system and automated configuration management is recommended. These enhancements will streamline monitoring, facilitate quicker troubleshooting, and simplify environment variable management, making the system more reliable and easier to maintain.

Furthermore, this paper introduced HD-DNCAE, an enhancement to the DNCAE model, implemented with SGD momentum and Adadelta optimisers. We repeated the experiments across multiple datasets to demonstrate HD-DNCAE’s performance in anomaly detection tasks. On the NSL-KDD dataset [40], HD-DNCAE (SGD momentum) with KDE and CEN classifiers achieved an AUC of 0.955, as with DNCAE’s performance. For the UNSW-NB15 dataset [41], HD-DNCAE (SGD momentum) with LOF reached 0.831 AUC, outperforming DNCAE’s 0.542. Moreover, HD-DNCAE showed improvements in several CIC-IDS [42] scenarios:

• Tuesday: HD-DNCAE (Adadelta) with LOF achieved an AUC of 0.935 against 0.476 with DNCAE.
• Wednesday: HD-DNCAE (Adadelta) with OCSVM (linear and poly) maintained an AUC of 0.717, while DNCAE obtained 0.398.
• Thursday Morning: HD-DNCAE (SGD momentum) with OCSVM Sigmoid attained an AUC of 0.884, matching DNCAE’s performance.
• Friday BOT: HD-DNCAE (Adadelta) with IF reached AUC of 0.802 against 0.712 DNCAE.
• Friday PortScan: HD-DNCAE (SGD momentum) with LOF outperformed with an AUC of 0.975 against DNCAE with 0.467.
• Friday DDoS: HD-DNCAE (Adadelta) with LOF achieved an AUC of 0.947 outperforming DNCAE of 0.461.

These results demonstrate HD-DNCAE’s capability in detecting diverse anomalies, with notable improvements in specific scenarios, particularly when using the Adadelta optimiser. The performance across multiple datasets and classifiers establishes HD-DNCAE as a viable alternative in anomaly detection for cybersecurity applications, offering comparable or improved results in most cases.

In the future, rigorous testing of both DNCAE and HD-DNCAE is expected to be conducted by simulating real-world attacks on the ICT stack of the seaport of Livorno. This activity will help us to determine how robust these algorithms are to never-before-seen attack scenarios, and, by undergoing this, we will be able to update the collected network dataset from the ICT stack to include not only normal data but other categories of attack.