MaCySTe: A Virtual Testbed for Maritime Cybersecurity

Abstract

The increasing reliance on technology and automation in the maritime sector has made it more vulnerable to cyberattacks. Cyber threats to ships and offshore platforms can have serious consequences, including accidents leading to loss of life, asset damage, or environmental impact. One primary means of countering these threats is developing and testing countermeasures tailored to the shipboard infrastructures and training the personnel. To this aim, we present MaCySTe, an open-source project that provides a testbed reproducing the network infrastructure and core components of the onboard cyber–physical systems. As it interfaces with ship simulators, it allows for realistic testing and training sessions involving cybersecurity and maritime operators. We expect that MaCySTe will contribute to fostering cybersecurity protection and awareness in this critical sector.

Keywords: Maritime cybersecurity; Digital twin; Testbed; Cyber–physical systems; Cybersecurity testing; Cybersecurity training; Cyber ranges.

Code metadata: Current code version v1.1.1 · Permanent link to code: github.com/ElsevierSoftwareX/SOFTX-D-23-00042 · Legal code license: GNU AGPLv3 · Versioning: git · Languages/tools: C++, Python, Rust, OpenPLC, FUXA, NATS · Requirements: envsubst, flatpak, flatpak-builder, make, Podman, Python, Linux · Documentation: crack-mcr.github.io/MaCySTe · Support: giacomo.longo@dibris.unige.it.

1. Motivation and Significance

Cyber–Physical Systems (CPS) [1] are complex architectures often composed of a plethora of integrated networking and computational technologies [2]. From a cybersecurity standpoint, this complexity makes them a very stimulating target for malicious actors as (i) it is hard to evaluate their real attack surface and, therefore, reliably secure them, and (ii) the effects of successful attacks can severely affect assets, the environment, and people. CPSs apply to several different domains [3] (e.g., critical infrastructures, automotive, avionics, or health care and medicine), each with its own specific set of security and functional requirements. Securing such domains requires, on the one hand, understanding the actual attack surface and, on the other hand, defining proper protection and monitoring solutions. Addressing the first point demands the availability of specific testbeds (see, for example, [4], [5], [6], [7]) that provide a controlled environment in which to simulate threats and evaluate the effectiveness of countermeasures, and—concerning the latter point—support the definition of domain-specific security mechanisms that can reduce the attack surface as much as possible (see, e.g., [8], [9], [10], [11]).

Among such CPS-based domains, it is worth mentioning the maritime sector as one of the most affected by cyberattacks [12], [13]. Ships heavily depend on complex CPSs [14] and are a significant focus for attackers [15], [16], given the continuously expanding threat landscape [17], [18]. Consequently, there is an urgent need for dependable testbeds that can simulate real ships' infrastructures.

In this paper, we present a Maritime Cyber Security Testbed, namely MaCySTe, that provides a virtual environment accurately reproducing the main components of a CPS operating on modern ships. We detail the main features it supports below.

Domain-specific sensors, actuators, and controllers. It can simulate the main onboard sensors, e.g., a Radar antenna, the Electronic Position Fixing System (EPFS), the Speed and Distance Measurement Equipment (SDME), the Compass, the Gyroscope, and the Automatic Identification System (AIS) transponder [19]. Moreover, it integrates a set of characteristic actuators and controllers by providing the digital twin of a Steering Gear Control System (SGCS). Such a controller is representative of one of the core functions, i.e., direction, and works according to the International Convention for the Safety of Life at Sea (SOLAS) [20] regulation and requirements.

Representative and modular physics. The testbed operates in an environment representative of the physical one by connecting with a ship and hydraulic system simulators. The first feeds the data emitted from sensors. The second evolves the characteristic variables of SGCS, e.g., oil temperature, pressure, or pump RPM. It is worth noting that such connections occur through an integration layer that leverages a dedicated Message Queue (MQ) for exchanging data. This architecture simplifies replacing existing solutions, e.g., integrating a different bridge simulator, and adding new components, e.g., integrating a propulsion system and the corresponding physical model simulator.

Integrated Bridge System. Like any modern ship, it simulates an Integrated Bridge System (IBS), i.e., interconnected hardware and software systems allowing centralized access to navigational, control, and monitoring information. In particular, it hosts the core equipment of an Integrated Navigation System (INS) [21], namely an Electronic Chart Display and Information System (ECDIS) and a Radar Plan Position Indicator (PPI), and creates their interconnection to centralize the access to sensor information. Moreover, it provides a host that can monitor and control the SGCS. It simulates a primary function of an Integrated Platform Management System (IPMS).

Domain-specific network configuration and protocols. Network zones and components connections follow the typical layout of a ship area network. It complies with the IEC 61162–450 standard [22] as it adopts the NMEA-0183 [23] protocol and Multicast UDP for communications between equipment and onboard sensors. Moreover, the antenna can transmit Radar video information using the Navico Broadband Radar BR24 [24] or the Eurocontrol standard ASTERIX Cat−240 [25] protocols. Lastly, communications between Programmable Logic Controllers (PLC) and interactions with the IPMS work using the de-facto standard MODBUS [26] protocol.

Human-in-the-loop. Integrating a ship simulator, marine equipment, and shipboard-like controls enables the seafarer to interact with the testbed. Moreover, we added to the ship simulator a scenario set on the Ligurian Sea and the Port of Genoa (Coordinates: 44°24′10″ N, 8°55′0″ E) to run the simulations in a realistic environment. These capabilities can support training and testing sessions to fill the cybersecurity awareness gap onboard [27], [28] and prepare operators to respond appropriately to cyber threats.

Several literature works considered testbeds for maritime cybersecurity. Sicard et al. [29] develop a physical testbed of a warship. Their primary emphasis revolves around direction, energy, artillery, and propulsion. Although MaCySTe uses only virtual components, it implements the direction function closely resembling their approach. Amro et al. [30] present a hybrid testbed representing an autonomous passenger ship. They use traditional virtualization to execute software that MaCySTe already includes or can easily integrate. They establish interfaces integrating physical components using various technologies, including USB and Wi-Fi. Currently, MaCySTe does not have such functionality, but we plan it for future work due to the flexibility of the containerization solution. In [31], the authors model a bridge network with a BR24 Radar unit, PPI, and navigation sensors. MaCySTe provides support for all these features. Tam et al. [32] discuss simulation, emulation, and live systems for maritime training and research by presenting their hybrid Cyber-SHIP Lab. As they stated, although simulation can be limited by conceptual models, solutions like MaCySTe are cheaper and quicker to develop. Testbeds can also be used as a cornerstone in maritime cyber ranges. As MaCySTe partially implements features described in [33], [34], we are also working on integrating it into a multi-domain scenario for cyber ranges. While serving similar functionalities of the above works, MaCySTe offers distinctive features, as follows: (i) available as an open-source project, (ii) self-contained in a single Linux machine and accessible via a web browser, and (iii) simulates a Radar unit and PPI with ASTERIX CAT240 protocol support.

2. Software Description

MaCySTe runs on Linux using containerization as the pillar technology. The recommended system requirements are 4 CPUs, 12 GB of RAM, 50 GB of storage, and a graphic card supporting OpenGL. We detail below its internals.

2.1. Testbed Architecture

Fig. 1 depicts the architecture of MaCySTe. It consists of four networks, namely Bridge, Control, Field, and Integration. The Bridge network hosts components of the IBS. The Data Collection Unit (DCU) and the Radar Antenna receive sensor data from the ship simulator and transmit them as multicast UDP packets using NMEA and BR24/Asterix protocols. Such data feed the ECDIS, the Radar PPI, and the Autopilot. This network also connects the IPMS for controlling and monitoring the onboard systems from the bridge (Fig. 1).

The Control network hosts controllers of the vessel automation. The Autopilot processes navigation data and automatically controls the rudder and speed according to preset values. The IPMS uses the connection with this network to interact with controllers. The Engine Order Telegraph changes the speed by supervising the PLCs, i.e., Left and Right, connected with engines. The Helm steers the ship through the PLC Master Rudder. This PLC controls oil tanks and pumps of SCGS via five PLCs connected by a dedicated Field network. It measures SGCS variables using the SGCS Sensors component.

Integration is an internal management network not tied to the ship infrastructure. It hosts a Message Queue for interfacing simulators, i.e., Ship and SGCS Model, with the ship's sensors and controllers. Lastly, it connects the management Graphical User Interface (GUI) for accessing the testbed.

2.2. Components, Modules, and Scenarios

MaCySTe revolves around the concepts of component, module, and scenario. A component is the basic building block for elements of the testbed. Each component is designed to be reusable and has parameters that must be specified before use. A module comprises one or more components, fixes their parameters, and can be instantiated in the testbed. For example, openplc is the component providing a software PLC that requires a Ladder Logic [35] program to run as a parameter. sgs_master is the module corresponding to the PLC Master Rudder. It includes the openplc component and specifies which program to run. Implementing components and modules leverages Pods [36] or Flatpak [37] apps.

Moreover, the testbed can be executed with different customizations, namely scenarios. Briefly, a scenario consists of a network infrastructure that connects running modules. Each customization specifies the included modules and their IP addressing. A scenario starts with custom shell scripts that use Podman [38] for creating networks and executing Pods and Flatpak to run apps. MaCySTe ships with two scenarios: (i) the core one that implements the architecture in Fig. 1, and (ii) an extension that adds an instance of a Security Information and Event Management (SIEM) and a malware executing targeted attacks, as presented in Section 3.

2.3. Components and Modules Implementation

This section discusses the components and modules implementation of the core scenario. In Table 1, for each component, we detail (i) the name, (ii) the implementation approach (cf. Impl. column), (iii) the modules including it, and (iv) a brief description (see [35], [39], [40], [41], [42], [43]). In particular, the approach specifies whether the implementation is built-from-scratch, patched off-the-shelf/framework, or off-the-shelf software. We used JavaScript, Python, or Rust for all the built-from-scratch software. We patched an existing ship simulator, i.e., Bridge Command [39], to exchange simulation data with an MQ, among other improvements. We used process visualization software, i.e., FUXA [40], as the framework for implementing the Human Machine Interface (HMI) of IPMS. We customized multiple instances of a software PLC, i.e., OpenPLC [35], with Ladder Logic programs controlling the automation of SGCS. We integrated NATS [41], OpenCPN [42] with plugin [43] for Navico Broadband Radars (BR24) to provide the functionalities of MQ and ECDIS with Radar overlay, respectively. Lastly, we highlight that all the components are distributed as containers except for bridgecommand, which we packaged as a Flatpak app. Flatpak ensures broader compatibility with graphic cards to the ship simulator.

2.4. Configure and Manage the Testbed

MaCySTe comes with two main directories, namely doc and src, that keep the documentation and artifacts for configuring and managing the testbed, respectively. The src directory includes: configs (configuration files for modules, e.g., electronic charts for ECDIS); containers (Containerfile scripts for building container images); flatpaks (manifest files for building components as Flatpak apps); pods (YAML files for defining components as Pods); scenarios (the 00-modules subdirectory keeps module definitions with config.Makefile for required components and vars.Makefile for parameter values; other subdirectories keep scenario definitions with required modules and alloc.Makefile IP allocations); state (stateful data generated by modules during executions, e.g., the MQ message buffer). The src directory also includes settings.Makefile (main configuration: scenario to start, remote registries, headless ship simulator mode for systems without a graphic card) and Makefile (GNU make targets: build, run-bc to start the ship simulator, up/down to start/stop the testbed, open-home to open the GUI).

2.5. Management Graphical User Interface

MaCySTe provides a web management GUI for accessing its modules. Fig. 2 shows one possible configuration: a resizable 2×2 grid. In the first frame, ship controls (autopilot maintaining constant heading 30 degrees and speed 6 knots). In the second, ECDIS showing the ship's position and AIS targets with the electronic chart of the Gulf of Genoa overlaid with the full Radar image. In the third, the ASTERIX Radar PPI display. In the fourth, the HMI from IPMS showing and monitoring pump and rudder oil-tank status in real time, allowing control of pump activation and rudder position.

3. Illustrative Examples

To show the cybersecurity capabilities of MaCySTe, we represent a context-specific Attack/Defense scenario. In Fig. 3, we present the extension made to the core architecture: six gray-highlighted modules and two networks, namely SIEM network and Simulated Internet. The SIEM network is a local network hosting a Security Information and Event Management (SIEM) solution and probes for capturing NMEA and MODBUS traffic (NMEA Probe, MODBUS Probe). Simulated Internet mimics the ship connection to the public Internet via a dedicated (satellite) Router.

From the attacker's perspective, we simulate malicious software (Malware) installed on the INS [44]. It can overhear Bridge network traffic, inject packets, and interact with a remote Command & Control (C&C) server in the public Internet. C&C identifies the ship's state, i.e., telemetry and positions of nearby vessels, with data from the malware, and leverages injection capabilities to execute targeted attacks. Malware provides two sample attacks against INS. They exploit weaknesses in its communication protocols by injecting (i) high-frequency NMEA packets to fake the heading value [45] and (ii) ASTERIX packets aiming at disrupting the Radar image [46]. C&C is managed using a dedicated GUI named GUI Attack (Fig. 4 visualizes the ship's state and nearby vessels on a nautical chart with malware control and attack facilities).

In Fig. 5, MaCySTe is configured with a 2×1 grid: GUI Attack with the attack form (start/stop buttons; the ASTERIX attack is started, covering the Radar image—a denial of service; the NMEA attack is stopped, requiring a heading value and injection frequency) and a PPI display showing the covered Radar image.

From the defender's perspective, we implement network probes capturing Bridge and Field network traffic. Such traffic is parsed to extract sensor data and setpoints from field devices and fed to SIEM for ingestion, visualization, and analysis. In Fig. 6, we demonstrate the NMEA attack effect and a possible detection strategy with a 2×1 grid: ECDIS has an active route (red arrows) tracked by the autopilot, while the NMEA heading-sensor attack forces the autopilot to veer off the expected course; the SIEM dashboard plots sampled heading averages (green) and average±3σ statistics (purple/light blue), and the visible deviation from the previous trend highlights the attack. In Table 2, we extend Table 1 with new component details (all built from scratch in JS/Python except mini_router with custom firewall Linux and opensearch_preseeder auto-deploying OpenSearch [47] index/search/dashboard configuration).

The presented scenario allows MaCySTe to be exploited in different testing and training conditions: testing whether existing monitoring solutions (e.g., Intrusion Detection Systems) can analyze domain-specific protocols and detect anomalies from targeted attacks; providing attack assets and artifacts for tailoring SIEMs to the maritime context; and improving ships' cyber resilience by training cybersecurity operators on domain-specific knowledge and seafarers on understanding the effects and consequences of such cyberattacks.

4. Impact and Conclusions

MaCySTe provides a testbed replicating the network infrastructure, core systems and equipment, domain-specific protocols, and configurations of a reference CPS onboard ships. The component of MaCySTe that interfaces external simulators—with an emphasis on the ship simulator—allows the testbed to operate in a highly realistic environment. The above features are essential for researchers to simulate and analyze complex and targeted cyberattacks against ships and study necessary countermeasures. Moreover, MaCySTe represents a suitable environment for training cybersecurity operators in the maritime domain, increasing seafarers' awareness and cooperation to counter threats.

Regarding the above capabilities, MaCySTe has already been exploited in different contexts. Specifically, we utilized it to conduct an adversarial analysis of the ASTERIX protocol, devise attacks targeting the Radar system [46], assess their effects, and create a defensive monitoring solution. The ASTERIX Radar unit was also used as the data source for testing a novel ship-to-shore communication framework [48]. In [49], we argued the need for a specialized security operation center to assist the ships underway. We used MaCySTe to present a training program for their operators using realistic hands-on activities. In the future, we hope a community of developers and users around MaCySTe can grow. As a result, the tool can improve in terms of supported components and use-case scenarios and become a research and industrial reference asset for cybersecurity tests and training in the maritime domain.

Declarations, Acknowledgments, and Data Availability

Declaration of competing interest: The authors declare that they have no known competing financial interests or personal relationships that could have appeared to influence the work reported in this article.

Acknowledgments: This work was partially funded by the NextGenerationEU project “Security and Rights in CyberSpace” (SERICS) and supported by research funding from Fincantieri E-phors S.p.A. It was carried out while Giacomo Longo was enrolled in the Italian National Doctorate on Artificial Intelligence run by the Sapienza University of Rome in collaboration with the University of Genoa.

Data availability: No data was used for the research described in the article.