0% found this document useful (0 votes)
22 views22 pages

SCASS Breaking Into SCADA Systems Security

The document discusses SCASS, a modular and open-source cybersecurity testbed designed to enhance the security assessment of Industrial Control Systems (ICS) and SCADA systems. It addresses the limitations of conventional testbeds by offering a customizable platform that integrates both physical and virtual components, enabling the evaluation of various attack scenarios. SCASS aims to improve accessibility and scalability in cybersecurity testing while fostering collaboration among researchers in the field.

Uploaded by

A Glaum
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
22 views22 pages

SCASS Breaking Into SCADA Systems Security

The document discusses SCASS, a modular and open-source cybersecurity testbed designed to enhance the security assessment of Industrial Control Systems (ICS) and SCADA systems. It addresses the limitations of conventional testbeds by offering a customizable platform that integrates both physical and virtual components, enabling the evaluation of various attack scenarios. SCASS aims to improve accessibility and scalability in cybersecurity testing while fostering collaboration among researchers in the field.

Uploaded by

A Glaum
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 22

Computers & Security 151 (2025) 104315

Contents lists available at ScienceDirect

Computers & Security


journal homepage: www.elsevier.com/locate/cose

Full length article

SCASS: Breaking into SCADA Systems Security



Nicola d’Ambrosio , Giulio Capodagli, Gaetano Perrone , Simon Pietro Romano
University of Napoli Federico II, Department of Electrical Engineering and Information Technology, Via Claudio 21, 80125 Napoli, Italy

ARTICLE INFO ABSTRACT

Keywords: Industrial Controls Systems (ICS) represent a relevant target for attackers. In order to prevent such critical
ICS cybersecurity security threats, ICS security assessment activities should be conducted. Conventional vulnerability assessment
SCADA systems and penetration testing within ICSs are not practicable due to safety risks and cost constraints. To overcome
ICS cyber-ranges
these challenges, security researchers have developed cybersecurity testbeds. However, these testbeds com-
ICS testbeds
monly rely on closed components, cannot be extended, and are very expensive. This research investigates
how a modular, open-source framework can enhance the development of robust cybersecurity testbeds and
facilitate the implementation of digital twins for securing Industrial Control Systems. We present SCASS, a fully
customizable testbed designed to replicate complex SCADA and ICS environments with high fidelity. SCASS
addresses the need for accessible, scalable platforms by supporting both physical and virtual components while
enabling the evaluation of heterogeneous attack scenarios and security methodologies. By combining advanced
attack scenarios with an objective comparative analysis against existing testbeds, SCASS demonstrates its ability
to fill critical gaps in the ICS security landscape, fostering collaboration and advancing security assessment
methodologies.

1. Introduction capable of virtualizing the networking stack. Leveraging Linux con-


tainer technology, SCASS creates a lightweight and high-performance
Cybersecurity incidents significantly damage industrial systems virtualization environment that effectively simulates the components
(Fortinet, 2024), as confirmed by the spread of relevant attacks against and network interactions of ICSs.
sensitive Industrial Control System (ICS) infrastructures (Langner, 2011; The work is structured as follows. Section 2 introduces the domain
Fidler, 2011; Kara and Aydos, 2019; Anon, 2023j,b,i). of Industrial Control Systems and related security practices. Section 3
Security researchers aim to address such challenges by developing examines related works, with a particular focus on the EPIC testbed
digital twins, i.e., detailed simulations that accurately replicate the and its digital twin named EPICTWIN. Section 4 illustrates the SCASS
complexities of real-world Industrial Control Systems through virtual- architecture, while Section 5 exemplifies the testbed’s efficacy through
ization, simulation, and physical reproduction (Dietz and Pernul, 2020; the replication of the EPIC testbed. Section 6 illustrates an ICS attack
He et al., 2019; Varghese et al., 2022). scenario against the replicated EPIC testbed, validating how SCASS
Despite the advantages offered by full virtualization, careful con- can effectively reproduce real-world cybersecurity challenges. Section 7
siderations are necessary when replicating Industrial Control Systems, provides an in-depth analysis of SCASS, benchmarking it against other
particularly with respect to maintaining domain fidelity of the repli- hybrid testbeds and highlighting both its limitations and proposed
cated physical system (Howard, 2019). Hybrid testbeds aim to address improvements. Section 8 concludes the paper by summarizing the
such a problem by combining both physical and virtual elements. contributions of this research while also offering thoughtful recom-
However, most current testbeds neither publicly release their source mendations for future enhancements and extensions of the proposed
methodology.
code nor provide in-depth details for reproducing the networking layer
and attack scenarios. We aim to fill this gap by presentingSCADA Sys-
2. Background
tems Security (SCASS), a compact, hybrid, and lightweight environment
designed for creating security testbeds for ICSs. Housed within a small
This section provides an overview of the foundational concepts
cabinet, SCASS integrates physical components commonly employed
related to Industrial Control Systems (ICS), covering key industrial
in ICSs alongside a Raspberry Pi – a small, single-board computer

∗ Corresponding author.
E-mail addresses: [email protected] (N. d’Ambrosio), [email protected] (G. Capodagli), [email protected] (G. Perrone),
[email protected] (S.P. Romano).

https://doi.org/10.1016/j.cose.2025.104315
Received 3 February 2024; Received in revised form 22 November 2024; Accepted 4 January 2025
Available online 11 January 2025
0167-4048/© 2025 The Authors. Published by Elsevier Ltd. This is an open access article under the CC BY license (http://creativecommons.org/licenses/by/4.0/).
N. d’Ambrosio et al. Computers & Security 151 (2025) 104315

2.2. Communication protocols for industrial control systems


Nomenclature

AMI Advanced Metering Infrastructure While Operational Technology (OT) networks share fundamental
ARP Address Resolution Protocol principles with Information Technology (IT) networks, subtle distinc-
DCS Distributed Control System tions do exist. OT networks, akin to IT networks, rely on the TCP/IP
DT Digital Twin stack and common application-level protocols. However, over the
ETA Event Tree Analysis decades, dedicated industrial protocols based on TCP/IP were designed
FDI False Data Injection to facilitate rapid, efficient, and reliable communication between de-
FMEA Failure Mode and Effects Analysis vices (Decotignie, 2005). Table 1 illustrates the most relevant TCP/IP
industrial protocols by also underlying their common use cases.
FTA Failure Tree Analysis
GOOSE Generic Object Oriented Substation Events
HAZOP HAZard and OPerability analysis 2.3. ICS cybersecurity approaches
HCA Hazardous Control Action
HMI Human Machine Interface ICSs play a crucial role in managing critical infrastructures, making
ICS Industrial Control System them susceptible to significant attack vectors (Makrakis et al., 2021).
IDE Integrated Development Environment Moreover, the contemporary trend toward adopting cloud-based envi-
IDS Intrusion Detection System ronments and leveraging the cloud computing paradigm escalates the
risk of cyber attacks (Chan and Reith, 2022). Consequently, various
IED Intelligent Electronic Device
techniques (often based on machine learning) have been implemented
IT Information Technology
to detect attacks (Bhamare et al., 2020a). Given the impracticality
MITM Man In The Middle
of conducting security testing directly on SCADA systems, the design
MQTT Message Queue Telemetry Transport
of formal methodologies becomes essential for defining cyber attacks
OT Operational Technology on ICSs. Numerous methodologies have been developed to model cy-
PLC Programmable Logic Controller bersecurity threats in the ICS domain (Bhamare et al., 2020b). How-
RTU Remote Terminal Unit ever, the predominant approaches often involve integrating security
SCADA Supervisory Control And Data Acquisition considerations into established safety models (Kriaa et al., 2015).
SCASS SCADA Systems Security
STAMP Systems Theoretic Accident Model and Process 2.3.1. STAMP, STPA and STP-Sec
STPA Systems Theoretic Process Analysis Systems Theoretic Accident Model and Process (STAMP) is an accident
STPA-Sec Systems Theoretic Process Analysis for Security causality model developed by Leveson (2004) that imposes constraints
TCP Transmission Control Protocol on the behavior and interactions of system components. The model was
VM Virtual Machine extensively adopted across various domains, including air traffic con-
trol (Niu et al., 2018), nuclear power (Lee et al., 2020), automobiles,
medical devices, and hospital safety.
Systems Theoretic Process Analysis (STPA) is a hazard analysis
protocols, SCADA systems, and commonly used cybersecurity practices
methodology that builds upon STAMP and is employed to study the
within the ICS domain.
dynamics of accidents through several steps.:

2.1. Industrial control systems • Identifying accidents and hazards (precondition);


• Drawing the control structure (precondition);
An Industrial Control System (ICS) refers to several types of con- • Identifying unsafe control actions;
trol components (electrical, mechanical, hydraulic, pneumatic) acting • Identifying causal factors and creating scenarios.
together to accomplish an industrial goal (NIST, 2020).
The effectiveness of STPA surpasses that of traditional safety models
The ICS architecture can be organized into three main groups of like Failure Tree Analysis (FTA), HAZard and OPerability analysis (HA-
components. Field devices, such as sensors and actuators, gather data ZOP), Failure Mode and Effects Analysis (FMEA), and Event Tree Analysis
from physical processes and forward them to the control layer, which
(ETA) in uncovering overlooked causes, especially in complex systems
consists of simple components such as Programmable Logic Controllers
incorporating computer controls (Yan et al., 2016).
(PLCs) or even more complex setups involving Distributed Control Sys-
Young and Leveson (2014) address security concerns by proposing
tems (DCSs). The supervisory layer gathers data from the control sys-
the Systems Theoretic Process Analysis for Security (STPA-Sec) model, an
tems and provides interfaces for monitoring and controlling industrial
STPA extension that identifies and analyzes security risks related to
processes through Human Machine Interfaces and Supervisory Control
critical control processes. Friedberg et al. (2017) have also contributed
And Data Acquisition (SCADA) systems, which provide a comprehen-
through STPA-SafeSec, a unified process offering a comprehensive ap-
sive overview of the system’s operations (Cui et al., 2024). SCADA
proach to address both safety and security aspects.
systems are designed specifically for remote monitoring and control
of industrial processes through a centralized management platform
that encompasses supervisory control, data acquisition, and real-time 3. Related works
processing capabilities. A typical SCADA system consists of special-
ized industrial automation computers (Programmable Logic Controllers In this section, we explore pertinent related works on the ap-
(PLCs)), industrial control devices (Remote Terminal Unit s (RTUs)), plication of digital twins. We also discuss simulated environments
human operator interfaces (Human Machine Interface), data historians addressing cybersecurity challenges for ICS systems, with a focus on the
for historical records, communication networks for seamless data ex- physical Electrical Power and Intelligent Control (EPIC) testbed (Adepu
change, and the central control system, which processes data from et al., 2019) and its virtualized twin known as EPICTWIN (Kandasamy
remote locations and takes control decisions. et al., 2021).

2
N. d’Ambrosio et al. Computers & Security 151 (2025) 104315

Table 1
TCP/IP protocols and their use cases in industrial settings.
Protocol Use case description
Modbus/TCP (Wang et al., 2022) Facilitates communication among industrial devices, often used for
real-time monitoring and control in automation systems.
Profinet (Anon, 2023g) Supports real-time communication in automation systems, widely used
in factory automation.
MQTT (Anon, 2023a) A lightweight messaging protocol for Industrial Internet of Things
(IIoT) environments, enabling communication between remote devices
with minimal network bandwidth.
DNP3 (Anon, 2023c) Reliable protocol for communication between supervisory systems and
remote terminal units, commonly used in power substations and water
utilities.

3.1. Digital twins Another example of a physical testbed is the Secure Water Treat-
ment (SWaT) (Mathur and Tippenhauer, 2016) system. The platform
Digital Twin (DT) systems enable the creation of digital representa- comprises a six-stage water treatment process, with each stage con-
tions of systems by mirroring physical entities, while at the same time trolled by a dedicated PLC, evaluated against multiple attack scenarios.
minimizing costs (Haag and Anderl, 2018). Digital twin systems have
been adopted to replicate production or manufacturing systems for 3.2.2. Virtual testbeds
cybersecurity purposes (Park et al., 2020/01/01; Zhang et al., 2018). Virtual testbeds are composed of virtual machines or containers and
In the cybersecurity field, digital twins are adopted to model com- are more cost-effective as they do not require the deployment of real
plex systems. Olivares-Rojas et al. (2022) demonstrate their utility in components.
assessing vulnerabilities of an intelligent metering system in a smart Maynard et al. (2018) propose a scalable framework designed
home environment. Masi et al. (2023) construct an ICS digital twin for deploying multiple virtual machines to create a SCADA network.
based on cybersecurity requirements. They leverage such a system to This open-source framework (Maynard, 2018) leverages components
derive attacks and identify the related countermeasures. like Human Machine Interfaces (HMIs) and RTUs, which communicate
Despite the numerous benefits of digital twins, several authors em- through OT network protocols and are created with OpenPLC (Anon,
phasize their security risks (Holmes et al., 2021; Mark Hearn, 2019). In 2023f) on VirtualBox virtual machines configured through Vagrant.
particular, attackers might exploit Digital Twin vulnerabilities to gather This framework might be easily extended to support SCASS. For in-
information about the replicated real infrastructure. Besides that, the stance, deploying the SCASS network on a cloud infrastructure using
simulated system may not be able to reproduce severe threats affecting Maynard SCADA would enhance scalability and offer a more realistic
the mirrored physical systems.
execution in both hybrid cloud and on-premises environments. We
SCASS hybrid infrastructure addresses these concerns by integrating
finally observe that the EPIC infrastructure was virtually replicated
both virtual and physical components that allow for defining the degree
through the digital twin EPICTWIN, which will be described in detail
of realism in the SCASS system. On one hand, this allows to reduce im-
in Section 3.3.1.
plementation costs, as well as hardware and software expenses. On the
other hand, it guarantees adherence to the replicated physical system.
3.2.3. Hybrid testbeds
Hybrid testbeds combine physical and virtual components to lever-
3.2. ICS testbeds
age the strengths of both approaches, ensuring a realistic simulation
Cyber ranges are simulated platforms mainly developed for train- within a controlled environment.
ing security personnel. Nowadays, they are extensively adopted for Mallouhi et al. (2011) propose a testbed to analyze cyber–physical
other purposes, such as the security evaluation of new solutions and interactions and vulnerabilities in SCADA environments. The testbed
strategies (Yamin et al., 2020). prioritizes the simulation of real-time events and combines physical and
An extensive analysis of testbeds for industrial cybersecurity is virtual elements to imitate SCADA processes.
provided by Conti et al. (2021), who categorizes over 50 systems based The Mississippi State University presents a SCADA security labora-
on parameters like sector, cost, and license. It is possible to classify tory (Morris et al., 2011) which combines process control systems from
industrial testbeds into three categories, namely, physical, hybrid, or multiple critical infrastructure industries, enabling laboratory exercises,
virtual, with virtual testbeds being more flexible yet less customizable as well as functional demonstrations and experimentation. No source
due to the replacement of physical components. code is available for this laboratory, and the cited work does not
describe the analized attacks in detail.
3.2.1. Physical testbeds Singh et al. (2015) simulate a SCADA power system encompassing
Physical testbeds offer a more realistic simulation of events but are simulated RTUs that generate traffic through several communication
often expensive and time-consuming to build. A relevant example is the protocols. The testbed introduces interesting security controls, such as
EPIC (Anon, 2021) physical testbed, which mimics a real-world power comparator modules to detect intrusions, but it is mainly focused on
system via real PLCs, with communication implemented through the physical attacks and does not take relevant networking scenarios into
IEC 61850 protocol. In the EPIC system, it is possible to reproduce account.
various security attacks, such as False Data Injection and power supply Koutsandria et al. (2015) developed a hybrid testbed using phys-
interruption, and assess related mitigation techniques. ical systems and PLCs, Simulink for Operational Technology, and a
The Smart Grid Test Bed (Anon, 2017) stands out as the world’s first Raspberry Pi network tap for traffic statistics and packets exchanges.
full-scale replication of a smart grid within a physical testbed, demon- Although the source code is not accessible, they offer an attack scenario
strating the scalability of such environments from smaller dimensions example that provides valuable insights for replicating different types
to real-world counterparts. of attacks.

3
N. d’Ambrosio et al. Computers & Security 151 (2025) 104315

Keliris et al. (2016) integrate machine learning defenses into the ICS stages,i.e., generation, transmission, smart home, and microgrid. These
process by proposing a solution that combines hardware and software stages are linked to a controller PLC, establishing connections to a
components to analyze attacks. It supports comprehensive vulnerability SCADA system. A more detailed description of the testbed is available
analysis and impact assessment. Unfortunately, the analysis does not in Fig. 2. Within each stage, every generator is linked to a motor,
include network-specific attacks such as ARP spoofing and packet and control over the motors is facilitated by Variable Frequency Drive
sniffing. (VFD) devices. The power line can be disconnected from the main grid
SCADA-SST (Ghaleb et al., 2016) is a versatile testbed for SCADA through Circuit Breakers, which are operated by an array of Intelligent
security, enabling the modeling of hybrid architectures with both sim- Electronic Devices (IEDs).
ulated and real components. The testbed is characterized by its light
3.3.1. EPICTWIN
weight, ability to scale, and inclusion of security analysis capabilities,
The EPIC architecture serves as an excellent model for reproduc-
such as the ability to capture traffic and simulate network attacks. It
ing cybersecurity scenarios, but its dependence on expensive physical
facilitates communication between simulated and real devices, which
components complicates experimental reproduction (Tao et al., 2019).
is essential for conducting realistic tests on SCADA systems under dif-
To address these limitations, Kandasamy et al. (2022) leverage the
ferent attack conditions, such as Denial of Service (DoS) and Distributed digital twin approach to achieve full virtualization of the testbed by
Denial of Service (DDoS) attacks. Rosa et al. (2017) describe an active realizing EPICTWIN (Kandasamy et al., 2021, 2022), a digital twin
learning approach guiding users through a SCADA cyber-range. The allowing the assessment and mitigation of threats and vulnerabilities
work describes interesting attack scenarios, but technical information within the replicated plant. It is based on network protocols such as
about hardware and networking configuration is not detailed enough Message Queue Telemetry Transport (MQTT), IEC 61850 Manufacturing
to facilitate the training reproduction. Message Specification (MMS), and Generic Object Oriented Substation
HYDRA (Bernieri et al., 2016) is a cost-effective, modular, and Events (GOOSE). The approach proves valuable for generating twins
flexible open-source testbed that replicates the functioning of a basic of testbeds or plants for cybersecurity studies. SCASS adopts a similar
water distribution system. The product offers a high level of modu- electric layout with some variations that will be further discussed in
larity and flexibility, enabling effortless attachment and detachment of the paper.
components. Arduino boars are used, in conjunction with the Modbus
communication protocol. The paper lacks specific networking details 4. The SCASS architecture
and, though focusing on cyber attacks, does not provide any illustrative
SCASS is implemented as a hybrid testbed, composed of physical
example of a real-world attack scenario.
and virtual components, which operates within a single cabinet that
Foglietta et al. (2019) present a testbed that combines physical
houses a collection of industrial devices, such as PLCs and RTUs, col-
components with virtualized environments to support integrated fault
laborating with virtual components implemented through the Docker
diagnosis and cybersecurity research. While it effectively addresses
virtualization technology. This allows to reliably replicate a smart
fault diagnosis, it does not provide a range of attack scenarios as diverse
grid industrial environment. A hybrid architecture offers cost and size
as other testbeds. reduction benefits while maintaining a certain level of realism in
The VTET Virtual Testbed (Xie et al., 2018) offers a hybrid en- simulations.
vironment combining virtualization with process simulations such as
the Tennessee Eastman Process. It supports several ICS protocols, but 4.1. Physical components
the attack description lacks relevant ICS attacks, such as ARP spoofing
and traffic sniffing. KYPO4INDUSTRY is an educational establishment The cabinet is made of metal and has DIN mountings. It includes
located at Masaryk University (Čeleda et al., 2020), with the purpose (Fig. 3) the following physical components:
of instructing computer science students on how to tackle cybersecurity
risks in Operational Technology networks. The system employs Rasp-
• One IDS-409-1SFP Industrial Managed Switch by Perle Systems
berry Pi devices to emulate Programmable Logic Controllers, enabling
Inc.;
the automated creation of attack scenarios using YAML files, as well
• Two UNO-PS/1AC/24DC/60 W Power supply units by Phoenix
as the seamless deployment of virtual machines through Ansible play- Contact;
books. Despite its scientific relevance and similarity with our work, the • Four PM554-TP-ETH PLCs by ABB Ltd (Fig. 4);
source code is not available, and no networking details are provided. • One Raspberry PI4, equipped with a 64 GB SD card by Samsung;
The cited work also lacks examples of potential attack scenarios. Cruz
and Simões (2021) propose a novel method for active learning by • One C60N magneto thermic switch by Merlin Gerin (Schneider
guiding users through a SCADA cyber range, enhancing their under- SA);
standing of system vulnerabilities and defenses, and equipping them • One 12HD7 monitor by Beetronic;
for real-world cybersecurity challenges. • One Stabilized power supply by Mean Well.
Most of the cited works neither include cost considerations, nor
The monitor is connected to the Raspberry Pi, which implements
release the source code. Furthermore, just few of them include network-
virtual elements and manages the virtual networks. The PM554-TP-ETH
ing and hardware configuration details, as well as provide a thorough
is a low to mid-end PLC that includes an AC500 e-Co CPU, an Industrial
description of the implemented attacks. This makes the replication
Ethernet port, an RS-485 serial port, and a set of six digital inputs and
challenging. The SCASS testbed was designed with the purpose of
eight digital outputs. In addition, accessories can be mounted to expand
providing a testbed that embraces all of the relevant features of related
the capabilities of the device. PLCs can be configured through the
works. In Section 7, we provide a comparison between SCASS and ABB Automation Builder Integrated Development Environment (IDE),
related hybrid testbeds. a robust toolset based on CodeSys (CODESTS, 2021), that allows the
development, testing, and commissioning of automation solutions and
3.3. A focus on the Electrical Power and Intelligent Control (EPIC) testbed communication networks compliant with the IEC 61131-3 standard
programming language.
The Electric Power and Intelligent Control (EPIC) testbed faithfully In this work, we have configured the physical PLCs in such a way as
replicates a smart-grid architecture. The authors present this work to replicate the EPIC infrastructure. However, the SCASS architecture is
to enable researchers to devise new cyber-attacks against smart-grid general enough and can be arbitrarily extended by configuring PLCs as
systems and evaluate the efficacy of defense mechanisms. Fig. 1 il- controllers of either virtualized or physical components, hence realizing
lustrates the high-level architecture of EPIC, which comprises four any testbed architecture.

4
N. d’Ambrosio et al. Computers & Security 151 (2025) 104315

Fig. 1. EPIC high-level architecture.

Fig. 2. Electric layout in the EPIC architecture. Four areas can be distinguished: Generation, Micro-Grid, Transmission, Smart Home. Prefixes match device names.
Source: EPICTWIN architecture by Kandasamy et al. (2022, 2021).

4.2. Virtual components 4.2.1. The HMI


The HMI component of the testbed is implemented through either
The Raspberry Pi runs a Docker daemon (Boettiger, 2015), facili- ad-hoc Node-RED libraries1 (see Fig. 5(a)), or by leveraging an alter-
tating the deployment of lightweight containers based on developed native open-source SCADA/HMI framework named FUXA (frangoteam,
Docker images.
2020) (see Fig. 5(b)). These components are interchangeable, enabling
We implement different Docker images:
users to select the solution that best suits their needs. In this case,
• ‘‘IED’’ is a Docker image implemented in Python, functioning as the HMI displays the implemented architecture layout, with all control
a Modbus TCP server leveraging the Pymodbus library (Mehta and monitoring elements that can be managed through a web-enabled
et al., 2015) that awaits commands on TCP port 501. interface. Node-RED offers the highest grade of customization but
• ‘‘Router’’ refers to the router image used to replicate the EPIC requires higher programming and configuration effort than FUXA. On
configuration. Two instances of the router element are employed: the other hand, FUXA allows for the effortless integration of new
one connects the Controller PLC with the worker PLCs, and the protocols, as well as the addition of new features, with no advanced
other links the Controller PLC with the SCADA system. programming knowledge. However, FUXA does not provide the same
• The ‘‘SCADA-System’’ container that is a part of the overall depth of customization as its Node-RED counterpart.
SCADA system developed using Node-RED, a flow-based program-
ming tool commonly used to model industrial processes (Ferencz
and Domokos, 2019; Tabaa et al., 2018; Nicolae and Korodi,
1
2018). The node-red-contrib-ui-led library and the
node-red-dashboard library

5
N. d’Ambrosio et al. Computers & Security 151 (2025) 104315

Fig. 3. The cabinet: the array of PLCs can be observed below; the Raspberry PI 4 is located under the industrial switch.

Fig. 4. The array of PLCs. In the current SCASS configuration, physical PLCs are used as workers, while the general PLC controller is virtualized. Such a configuration can be
changed, and it is possible to configure physical PLCs as both controllers and workers.

4.3. Networking The Docker engine manages VLANs, and the Macvlan network driver
assigns each Docker container an IP address associated with a specific
Layer-2 interconnection of SCASS components is facilitated by the VLAN. This approach facilitates the establishment of a unified network-
IDS-404-1SFP Industrial Managed Switch, that is responsible for man- ing stack, seamlessly interconnecting physical and virtual components.
aging communications among all of the physical PLCs in the cabinet. Certain containers serve as default gateways, enabling the construc-
A dedicated ‘‘OUT’’ line allows the integration of external systems tion of intricate infrastructures comprising multiple networks. Fig. 6
for more complex attack scenarios. VLANs are configured within the provides an illustrative example of the networking configuration that
physical switch, with each physical PLC residing on a specific VLAN. interconnects both virtual and physical components.

6
N. d’Ambrosio et al. Computers & Security 151 (2025) 104315

Fig. 5. HMI designs using Node-RED and FUXA.

4.3.1. Containers and cyber-attack scenarios


The Raspberry Pi, being a compact embedded device, benefits from
an efficient container-based virtualization. However, containers present
different challenges, such as replicating specific attack scenarios in-
volving Windows machines or exploiting vulnerabilities in the Linux
kernel. One further significant challenge, highlighted by Kandasamy
et al. (2021), is the difficulty to simulate physical Man In The Middle
(MITM) attacks at the data link layer using containers. This feature is
fundamental for replicating cyber attacks against ICSs. To address this
issue, we leverage the Macvlan network driver in Docker, a solution we
previously employed in our work (Caturano et al., 2020). This feature
allows the creation of a shared network that connects physical and
virtual components by configuring containers with a virtual Network
Interface Controller (NIC) that emulates a direct connection to the
physical network. By integrating concepts from our previous work, we
establish an ICS networking stack that seamlessly connects physical and
lightweight virtual elements.

5. Reproducing the EPIC architecture through SCASS

To showcase the system’s adaptability, we configure SCASS to repli-


cate the Electric Power and Intelligent Control (EPIC) testbed (Adepu
et al., 2019) using a methodology akin to that proposed by Kandasamy
et al. (2021). The virtual components are created using the ‘‘Infrastruc-
ture as Code (IaC)’’ methodology (Artac et al., 2017). Specifically, a
Fig. 6. SCASS networking layer example. The SCASS switch is configured with two
‘‘docker-compose’’2 file is employed to define the virtual components.
VLANs that implement a controller–worker architecture commonly adopted in SCADA In the compose file, the following ‘services’ are specified:
systems. The controller PLC is responsible for issuing commands to the worker PLCs,
which manage the IEDs. A dedicated protocol such as Modbus TCP can take care of
all message transfers, and all the components can be either containerized or physical. 2
https://docs.docker.com/compose/

7
N. d’Ambrosio et al. Computers & Security 151 (2025) 104315

Fig. 7. EPIC networking through SCASS.

Each network features a physical PLC controlling a set of virtual


IEDs simulating circuit breakers. The Control Gateway separates the
• one IED for the generation phase;
SCADA environment from the other networks, facilitating communi-
• three IEDs for the transmission phase;
cation between the SCADA system and the Controller PLC. Fig. 8
• four IEDs for the smart-home phase; illustrates the communication flows among components, utilizing a
• two IEDs for the micro-grid phase. controller–worker paradigm. The SCADA system issues commands to
The networking is planned based on the concepts elucidated in the containerized Controller PLC, which oversees physical PLCs. Each
Section 4.3. Six VLANs are defined in the physical switch and mapped PLC manages multiple virtual IEDs, emulating the EPIC architecture.
to virtual networks generated through the Docker engine. Physical ele- Communications within the system rely on the Modbus TCP pro-
ments connect to tagged VLAN ports, while virtual components acquire tocol. Modbus TCP was chosen for two primary reasons: (i) it is one
the designated VLAN through the Docker configuration. Specifically, of the most widely used protocols in the ICS domain, and (ii) it is the
the Raspberry Pi is configured to access all VLANs in trunk mode, protocol utilized by the ABB devices available in the cabinet we used,
enabling a generic configuration that links virtual and physical devices. which is of particular interest to the COR interforce command. That
Virtual networks have either 24-bit (such as the ‘‘scass-microgrid’’ being said, the SCASS architecture is designed to be general enough to
network below) or 28-bit (for all other networks) subnet masks and allow the seamless replacement of Modbus TCP with any other protocol
are organized as follows: for communication between industrial electronic devices.
The physical PLCs are programmed using CodeSys, whereas the
• ‘‘scass-microgrid’’: 10.0.0.0-10.0.0.0.255 virtual elements are created using Python modules that implement
• ‘‘scass-smarthome’’: 10.0.1.32-10.0.1.47 Modbus TCP servers, as detailed in Section 4.
• ‘‘scass-trasmission’’: 10.0.1.48-10.0.1.63
• ‘‘scass-plc’’: 10.0.1.64-10.0.1.79 5.1. Differences with EPICTWIN
• ‘‘scass-generation’’: 10.0.1.80-10.0.1.95
• ‘‘scass-scada’’: 10.0.1.96-10.0.1.111 The SCASS architecture differs from the EPICTWIN testbed in vari-
The network architecture is reported in Fig. 7. Two router contain- ous aspects. Table 2 provides a comparison of the EPICTWIN and SCASS
ers serve as default gateways for the multiple VLANs defined in the implementations.
physical switch. The internal gateway segregates the four networks, As evident, our implementation extensively employs container-
enabling the realization of the four stages in the EPIC architecture. based virtualization for networking and controllers. In EPICTWIN, the

8
N. d’Ambrosio et al. Computers & Security 151 (2025) 104315

Fig. 8. EPIC components’ flows.

Table 2 above. This is actually a minor difference since both digital testbeds
EPICTWIN - SCASS comparison.
can easily support a wide set of ICS communication suites.
EPIC testbed’s EPICTWIN SCASS Implementation Unfortunately, the implementation details of the EPICTWIN infras-
element
tructure are not publicly available. In our case, to facilitate the repli-
Network switch Ubuntu VM Docker container hosted
cation and extension of the SCASS architecture within the community,
on a Raspberry Pi
we have released the source code, encompassing both real and virtual
PLC controller Ubuntu VM Physical (except for
PLCs. The source code for the EPIC replication is openly accessible on
Controller PLC, not present
in EPICTWIN) GitHub.3 This allows security researchers to enhance the foundational
IED controllers Ubuntu VM Docker containers hosted
EPIC infrastructure for replicating more intricate scenarios.
on a Raspberry Pi We can summarize the distinguishing features of SCASS as follows:
AMI controllers Docker Not implemented
• Hybrid Architecture: the SCASS infrastructure integrates both
SCADA Node-RED Node-red process running
physical and virtual elements, leveraging the advantages of hy-
process running on a Windows VM
on a Linux VM brid architectures (Qassim et al., 2017);
• Container-Based Virtualization: SCASS implements its virtual
layer using container-based virtualization, overcoming the net-
working limitations inherent to this approach by utilizing the
authors acknowledge the advantages of Docker virtualization but face Macvlan feature (Caturano et al., 2020);
limitations when using containers to fully replicate a network stack • Open Source: the SCASS source code is publicly available, enhanc-
environment capable of reproducing Man In The Middle (MITM) attacks. ing the reproducibility of the testbed.
As mentioned earlier, we utilize the Docker Macvlan network driver to
directly connect the container to the physical network, fully virtualizing
6. Breaking into SCASS
the network stack and connecting real PLCs with virtual components in
the Raspberry Pi.
In this section, we demonstrate the capability of the SCASS system
This approach allows us to leverage the benefits of container-based
to replicate realistic scenarios in SCADA systems. This involves the en-
virtualization, including performance, scalability, and portability. In
tire process, from identifying an attack path for the target infrastructure
our case, the networking stack runs on a small Raspberry Pi, and the en-
to executing attack operations.
tire infrastructure is contained in the compact cabinet shown in Fig. 3.
We do not emulate the Advanced Metering Infrastructure (AMI) con-
6.1. Threat analysis
trollers since we do not simulate any physical process. Indeed, SCASS
employs physical PLCs that can connect to real devices, offering a
A threat analysis utilizing the STAMP/STPA method has been con-
faithful replication of a real-world scenario. A significant distinction in
ducted to identify vulnerabilities within SCASS. By leveraging the
our EPIC replication is the inclusion of the Controller PLC. Our system
insights and framework provided by Castiglione et al. (2022), we aim
replicates the typical ‘‘controller-workers’’ architecture presented in the
to effectively identify and address potential security vulnerabilities and
EPIC testbed. In the EPICTWIN architecture, the ‘‘Controller PLC’’ does
threats within the SCASS system. The STAMP model for SCASS can be
not seem to be present.
established by considering the components of the target infrastructure.
EPICTWIN employs the Open vSwitch technology for virtualization,
In this model, the control chain of the system is represented as a
whereas our approach utilizes Docker’s networking layer, configured sequence of associations, as illustrated in Fig. 9. These associations
to work in tandem with the physical switch that supports multiple are established based on the specific responsibilities assigned to each
VLANs. This distinction in networking technologies underscores the individual component. For brevity, this analysis will focus exclusively
flexibility and adaptability of virtualization solutions across different on the MicroGrid zone.
implementations.
At the protocol layer, EPICTWIN leverages the IEC 61850 (GOOSE)
3
potocol, whereas SCASS relies on Modbus TCP, as already discussed https://github.com/NS-unina/SCASS

9
N. d’Ambrosio et al. Computers & Security 151 (2025) 104315

Step 2: define the control structure


In this step, Control Actions and Feedback will be specified, starting
from the STAMP model (Fig. 10).
The Control Actions for the system are:

• 𝐶 𝐴1 : sends open/close signals to Controller PLC in order to


control MIEDs;
• 𝐶 𝐴2 : relays open/close signals from Controller PLC to MicroGrid
PLC;
• 𝐶 𝐴3 : relays open/close signals from MicroGrid PLC to MIED1;
• 𝐶 𝐴4 : relays open/close signals from MicroGrid PLC to MIED2;
• 𝐶 𝐴5 : applies open/close actions at CB4;
• 𝐶 𝐴6 : applies open/close actions at CB5.
The Feedback signals are:

• 𝐹1 : receive measurements from generators, state from IEDs;


• 𝐹2 : relay measurements from generators, state from IEDs;
• 𝐹3 : MIED1 state, measurements from the generator controlled by
MIED1;
• 𝐹4 : MIED2 state, measurements from the generator controlled by
MIED2.

Step 3: identify hazardous control actions


The Hazardous Control Actions leading to accidents A1 and A2 are
listed below:

• 𝐻 𝐶 𝐴1 : 𝐶 𝐴1 is applied with incorrect parameters, shutting down


the generator controlled by MIED1 → 𝐻3 , 𝐻4 ;
• 𝐻 𝐶 𝐴2 : 𝐶 𝐴1 is applied with incorrect parameters, shutting down
the generator controlled by MIED2 → 𝐻3 , 𝐻5 .
• 𝐻 𝐶 𝐴3 : 𝐶 𝐴2 is applied with incorrect parameters, shutting down
the generator → 𝐻3 , 𝐻4 , 𝐻5 ;
• 𝐻 𝐶 𝐴4 : 𝐹2 is applied with incorrect parameters, giving incorrect
feedback to the Controller PLC → 𝐻1 ;
• 𝐻 𝐶 𝐴5 : 𝐹3 is applied with incorrect parameters, giving incorrect
Fig. 9. Entities associations to identify the control chain in SCASS. The operator feedback to the MicroGrid PLC → 𝐻1 , 𝐻2 ;
interacts with the SCADA HMI to monitor and control the status of all Circuit Breakers
• 𝐻 𝐶 𝐴6 : 𝐹4 is applied with incorrect parameters, giving incorrect
(CBs) within the testbed. The Controller PLC relays the commands received from the
SCADA HMI to the corresponding zone-specific PLCs. Notably, the figure illustrates feedback to the MicroGrid PLC → 𝐻1 , 𝐻2 ;
only the MicroGrid PLC, which is responsible for disconnecting generator units from • 𝐻 𝐶 𝐴7 : 𝐶 𝐴3 is applied with incorrect parameters, shutting down
the electrical network. The intelligent devices MIED1 and MIED2 execute commands the generator controlled by MIED1 → 𝐻4 ;
from the MicroGrid PLC to open or close Circuit Breakers CB4 and CB5, respectively.
• 𝐻 𝐶 𝐴8 : 𝐶 𝐴4 is applied with incorrect parameters, shutting down
the generator controlled by MIED2 → 𝐻5 .

Once the control chain has been identified, the next step involves Step 4: associate attack steps with hazardous control actions
executing the hazard analysis using STPA, conducted across a series of In this phase, attack steps are associated with HCAs. This operation
steps. leads to the definition of a list of attack steps. An attack step is a tuple
𝑎𝑖 = (𝑡, 𝑒, 𝑣)𝑖 where:
Step 1: Identify accidents and hazards
The first step entails identifying potential accidents and hazards • 𝑡 is the type of threat;
within the target architecture. Accidents refer to unintended and un- • 𝑒 is the targeted control action or feedback;
desired events that can lead to adverse consequences, while hazards • 𝑣 is the value injected.
are conditions or situations that can contribute to the occurrence of
accidents (Leveson, 2016). Values can be injected through forgery. The element can be a
The accident list is as follows: Control Action or Feedback and, therefore, either a command or a
measurement. Possible attack steps against SCASS can be grouped in
• 𝐴1 : uncontrolled generator overload (with damage); a table ( Table 3) and associated with HCAs.
• 𝐴2 : undesired generator shutdown. These attack steps can be properly combined to reach a possible
A list of hazards is given below: attack goal through an attack path.

• 𝐻1 : Controller PLC not synchronized with physical process; 6.2. Deriving the attack graph with MulVal
• 𝐻2 : MicroGrid PLC not synchronized with physical process;
• 𝐻3 : unsafe configuration of MicroGrid PLC; The attack graph for the discussed SCASS configuration can be
• 𝐻4 : unsafe configuration of MIED1; derived using MulVAL (Anon, 2023e), a logic-based enterprise network
• 𝐻5 : unsafe configuration of MIED2. security analyzer. MulVAL requires a rule file containing the rules to
generate the attack graph and an input file describing network elements

10
N. d’Ambrosio et al. Computers & Security 151 (2025) 104315

Fig. 10. STAMP model, identifying Control Actions and Feedback.

Table 3
Attack steps and related HCAs. To disrupt legitimate feedback from reaching the MicroGrid PLC
Attack step Description HCAs device, the following preconditions must be fulfilled:
𝑎1 (𝑓 𝑜𝑟𝑔 𝑒𝑟𝑦, 𝐶 𝐴1 , 𝑐 𝑚𝑑) 1, 2
𝑎2 (𝑓 𝑜𝑟𝑔 𝑒𝑟𝑦, 𝐶 𝐴2 , 𝑐 𝑚𝑑) 3 • a data flow between the MIED and the MicroGrid PLC device must
𝑎3 (𝑓 𝑜𝑟𝑔 𝑒𝑟𝑦, 𝐶 𝐴3 , 𝑐 𝑚𝑑) 7 be present;
𝑎4 (𝑓 𝑜𝑟𝑔 𝑒𝑟𝑦, 𝐶 𝐴4 , 𝑐 𝑚𝑑) 8 • the attacker should have the ability to forge feedback messages
𝑎5 (𝑓 𝑜𝑟𝑔 𝑒𝑟𝑦, 𝐹1 , 𝑣)
̄ 4 to the area supervisory control device;
𝑎6 (𝑓 𝑜𝑟𝑔 𝑒𝑟𝑦, 𝐹2 , 𝑣)
̄ 5
𝑎7 (𝑓 𝑜𝑟𝑔 𝑒𝑟𝑦, 𝐹3 , 𝑣)
̄ 6
• the protocol being utilized lacks authentication mechanisms.
MulVAL, indeed, provides a method to clearly identify how to ex-
ploit these preconditions and attack SCASS successfully. By understand-
and vulnerabilities.4 The output is an attack graph that visualizes all ing and addressing these vulnerabilities, appropriate countermeasures
possible steps an adversary might leverage to alter a specific Control can be implemented to enhance the security and resilience of the SCASS
Action or Feedback and, therefore, trigger one of the aforementioned system.
HCAs. In this context, the leaves represent the necessary preconditions
for the attack, while the root represents the desired attack goal. Each 6.2.2. Multi-stage false data injection attack
step toward the attack goal corresponds to a successful exploitation of This scenario shows a multi-stage attack against the Main Router to
vulnerabilities, which may have a certain probability of execution. The take the control of Control Action 𝐶 𝐴3 . In detail, there are two stages
generated attack graphs are depicted in Fig. 11 and are further analyzed in the attack graph shown in Fig. 11(a):
in Section 6.2.1 and Section 6.2.2.
1. the attacker takes control of the General-PLC to gain network
visibility on the Main Router (blue path);
6.2.1. False data injection through ARP poisoning 2. the attacker gets access to the network device through the SSH
The tree in Fig. 11(a) models a False Data Injection (FDI) attack. To server (red path).
successfully execute the attack on SCASS, the attacker needs to satisfy
In the first step, the hacker takes advantage of the Shellshock
specific preconditions within the OT network, where the IEDs and the
vulnerability (node 8-9) found in the web HMI operating on the General
area supervisory control device are located. The preconditions for the
PLC. The web HMI (node 7 ) shows the real-time device status remotely
attack include:
using a dynamic web page. Specifically, the HTTP server employs the
• the attacker must have access to the OT network; CGI (Common Gateway Interface) technology to run a bash script that
• the devices within the network must support the Address Resolu- gathers information to be displayed on the web page. However, our
tion Protocol (ARP) protocol. system runs the script using a bash version vulnerable to Shellshock,
which enables the attacker to execute unauthorized code on the ma-
To forge messages to the area supervisory control device, the fol- chine (node 5-6). Then the attacker can use the General PLC as a
lowing preconditions need to be met: stepping stone to compromise the Main Router. Indeed, this attack step
gives the attacker network access to all OT network subnets. Next, the
• the ARP Poisoning attack must have been successfully executed; attacker can contact the Secure Shell (SSH) service (node 13) exposed
• a data flow should exist between the IED and the area supervisory by Main Router. SSH is a widely-used protocol for secure remote
control device; access and control of computer systems and servers (node 13 to 15).
• the protocol being used does not employ encryption. Unfortunately, the configuration made by an inexperienced technician
(node 10 to 12) maintained the default credentials (node 18), making
the system vulnerable to unauthorized access and compromising its
4
The complete source file associated with the architecture description can security. By exploiting this security issue, the attacker can run arbitrary
be found on the project’s github repository code with elevated privileges on this machine (node 13). In this context,

11
N. d’Ambrosio et al. Computers & Security 151 (2025) 104315

Fig. 11. The SCASS attack graph. The attack path can be represented by connecting leaves with a root.

the attacker can intercept all network traffic on the machine and attack is carried out between the microgrid PLC and one of the IEDs
alter the control flow data (node 22-23). The final steps of the attack responsible for controlling the generators. The objective is to manipu-
graph (highlighted in purple) follow the same sequence described in late the data flow, specifically introducing false measurements into the
Section 6.2.1. physical PLC, thereby causing the generation of incorrect commands.
The first step involves conducting a MITM attack using ARP spoof-
6.3. Attacking SCASS ing and Modbus TCP server impersonation (Fig. 13). A rogue Modbus
TCP server can be easily implemented using Py-Modbus,6 a Python
In this section, we implement the two attack scenarios associ- library specifically designed for Modbus TCP communication and ma-
ated with the attack paths identified through the previously descried nipulation. By employing this setup, the attacker can intercept Modbus
methodology.5 TCP messages and redirect them to his/her own Modbus TCP server, en-
suring that the operator terminal receives plausible values and remains
6.3.1. False data injection through ARP poisoning unaware of the injected data. This allows the attacker to maintain
The attack involves a malicious actor that employs a TCP injection control and prevent detection while manipulating the operational data
attack to alter generator operations and manipulate monitor-control within the system.
cycles by injecting false Modbus TCP messages containing fabricated The second step involves packet sniffing, which is aimed at under-
measurements. The architecture implemented to replicate an ICS cyber- standing the communications within the plant, especially the control
security attack is depicted in Fig. 12. We suppose that the attacker al- actions. By examining the captured traffic, the attacker may notice
ready compromised the microgrid network (i.e., 10.0.0.0/24 in Fig. 7), a periodic exchange of values between the IP addresses 10.0.0.192
and their purpose is now to harm the system by manipulating the (the microgrid PLC) and 10.0.0.21 (the microgrid IED). The attacker
commands between the microgrid PLC and the intelligent device MIED1 may infer that the data sent by the IED represents some form of
driving one of the circuit breakers (CB4). measurement, while the data flowing in the opposite direction may
To conduct the attacks, a Kali Linux (Anon, 2023d) Virtual Machine correspond to commands issued by the physical PLC to the IED, aimed
(VM) instance is utilized (the ‘‘Attacker’’ rectangle in Fig. 12), to exe- at maintaining the generator G1 properly powered through the closure
cute TCP injection attacks and manipulate the operations of generators of the circuit breaker CB4. The circuit breaker in question is, in fact,
within the target architecture. In the context of this study, we use driven by the intelligent electronic device MIED1, which is in turn
Scapy (Anon, 2023h) to implement a Transmission Control Protocol controlled through the microgrid PLC (see Fig. 2).
(TCP) Injection technique for the False Data Injection (FDI) attack. The The third step involves executing TCP Injection to introduce false
measurements into the physical PLC, thereby triggering the generation

5
For detailed instructions and examples of all the exploits discussed, refer
6
to the walkthrough provided in the GitHub repository https://pymodbus.readthedocs.io

12
N. d’Ambrosio et al. Computers & Security 151 (2025) 104315

Fig. 12. Deployed architecture for attacking SCASS.

Fig. 13. Man-in-the-middle attack scenario. In this scenario, the attacker blocks the legitimate Modbus TCP write requests sent to keep CB4 closed and rather forces it to open,
thus disconnecting the generator.

13
N. d’Ambrosio et al. Computers & Security 151 (2025) 104315

of incorrect values into the physical PLC, and eventually disrupting Table 4
Criteria for SCADA testbed evaluation - Characteristics.
the control process. As a result, the attacker intercepts and blocks
legitimate commands sent through the microgrid PLC, generating false Feature Description

Modbus TCP write commands to MIED1. This malicious action forces Reproducibility The testbed is reproducible and reusable by other
researchers.
the opening of CB4, disconnecting the controlled generator and disrupt-
ing the system, which can no longer be properly powered, potentially Scalability The testbed supports a diverse array of devices
without any need to redesign the system.
causing significant damage.
Domain fidelity The testbed uses physical hardware and is
configured realistically.
6.3.2. Multi-stage false data injection attack
Process simulation The testbed mimics a real-time process.
The attack scenario begins with a scanning of the Industrial Network
under attack. This activity reveals the presence of hosts within the Multiple ICS protocols The testbed supports more than one ICS protocol.

SCADA and PLC networks. These findings align with our expectations, Cost-effectiveness The testbed is affordable for use in SCADA
security research.
since the attacker cannot contact internal networks, such as the Micro-
Grid subnet, from the SCADA network. Furthermore, the service enu-
meration analysis reveals that the General-PLC, located in the PLC net- Table 5
work, is vulnerable to the Shellshock RCE vulnerability (Panchal et al., Criteria for SCADA testbed evaluation - Application areas.
2018). As a result, the attacker can craft a malformed HTTP request Feature Description
to the URL http://10.0.1.66/cgi-bin/stats/ to execute arbitrary code on Vulnerability analysis The testbed is designed for discovering weaknesses
the vulnerable machine. Specifically, they can exploit this vulnerability in simulated SCADA systems.
to open a reverse shell and gain control over the target endpoint. Security validation The testbed is designed for evaluating the
The next step in the attack scenario focuses on redirecting network vulnerability impact reduction after the application
of security controls.
traffic using the compromised machine as a pivot to exploit other hosts
that before were unreachable. This task is achieved by establishing Impact analysis The testbed can be used to analyze the impact of
cyberattacks against a SCADA system.
a port forwarding session between the compromised machine and
the attacker node. After completing the pivoting process, the attacker
performs reconnaissance activities on the newly accessible network Table 6
segment. In this case, they discover that the Internal Gateway has a Criteria for SCADA testbed evaluation - Testing capabilities.
misconfigured SSH service allowing login with default credentials. In Feature Description
detail, the attacker can exploit this vulnerability to gain root access to Reconnaissance Capability to replicate network scanning and
this endpoint. With these elevated privileges, it is possible to upload probing activities.
a malicious payload that can manipulate the encrypted traffic pass- (Cloud-based) brute Can simulate brute force attacks from cloud-based
ing through the router. Consequently, the attacker gains control over force attack platforms.
control action 𝐶 𝐴3 within the Microgrid Subnet. Command injection Supports the emulation of command injection
attacks.

7. Discussion MITM Enables the replication of Man-In-The-Middle


(Man-In-The-Middle) attacks.

A SCADA testbed evaluation is a complex task that requires a ARP Spoofing Capable of simulating ARP spoofing to mimic
network-level attacks.
detailed analysis of various aspects. Alanazi et al. (2023) conducted a
DoS (Denial of Can reproduce Denial of Service attack scenarios.
comprehensive review of SCADA vulnerabilities and attacks while also
Service)
proposing a structured methodology for evaluating SCADA testbeds.
Wireless Attacks Allows replication of various wireless-based
Their approach builds on the requirements proposed by Mallouhi et al.
attacks.
(2011), which serve as a foundation for assessing the capabilities of
Sniffing Attacks Supports the simulation of packet sniffing
SCADA security testbeds. In addition, they examine the security focus
activities.
(application area) and security testing capabilities of each reviewed
Vulnerability Provides tools for simulating vulnerability
testbed. discovery discovery techniques.
Following this methodology, we evaluate the SCASS features from
three distinct perspectives:

• Characteristics: the testbed functionality according to the re- ponents in A. This transparency is intended to enhance the reusability
quirements defined by Mallouhi et al. (2011) (as detailed in and extendibility of the testbed, making it easier for researchers and
Table 4). practitioners to adapt and build upon our work.
• Application areas: which type of security analysis is conducted SCASS scalability is ensured through the use of container-based
on the proposed testbed (as detailed in Table 5). virtualization, which offers several advantages, including flexibility,
• Testing capability: which types of attack scenarios can be imple- resource efficiency, and ease of deployment. This approach allows for
mented with the testbed (as detailed in Table 6). the rapid scaling of the testbed to accommodate diverse and complex
industrial control system configurations without compromising perfor-
mance. The application of a hybrid design improves domain fidelity
7.1. SCASS features in detail by combining both virtual and physical components. This allows for
more realistic simulations. Fidelity can be further enhanced by either
The SCASS testbed is evaluated against the illustrated features, integrating additional components or connecting the system to real
providing a comprehensive analysis of its strengths, limitations, and physical processes, hence providing an even closer representation of
potential in the ICS cybersecurity domain. real-world ICS environments.
Through SCASS, we demonstrate the ability to replicate the EPIC
7.1.1. Characteristics testbed, which simulates smart-grid processes. However, our goal ex-
The SCASS source code is publicly available, and we have included tends beyond mere replication. We aim to enhance the testbed by
electrical schematics and hardware details of the physical testbed com- conducting a detailed analysis of process simulations and providing

14
N. d’Ambrosio et al. Computers & Security 151 (2025) 104315

Table 7
Characteristics evaluation components.
Reproducibility
Source code availability No
Yes
Hardware configuration details Few details
Some details
Many details
Network configuration details Few details
Some details
Many details
Scalability
Virtualization type V Classic virtualization
C Container-based virtualization
Domain fidelity
Presence of real devices No
Yes
Hardware configuration details Few details
Some details
Many details
Process simulation
Component Values Details
Process type S Simulated
P Physical
Multiple ICS protocols
Component Values Details
Implemented protocols Modbus, DNP3, etc. The implemented protocols
Cost-effectiveness
Component Values Details
Cost details No details
Cost details

formal verifications to ensure the fidelity of the representation of real- of sniffing attacks. However, the testbed has limitations when it comes
world processes. As discussed in previous sections, this work currently to cloud-based brute force attacks and wireless scenarios. Indeed, the
supports only the Modbus protocol, which represents a limitation given testbed is wired and lacks cloud components, which restricts the imple-
the presence of newer protocols in modern SCADA infrastructures. mentation of cloud-based attacks. To incorporate cloud-based offensive
However, in Section 7.3.1, we provide detailed instructions on how scenarios, integration with the MQTT protocol could be considered,
SCASS can be configured to either replace physical devices or inte- enabling publish–subscribe architectures with a cloud-based broker.
grate virtual ones, without compromising the overall architecture of Nevertheless, this integration might conflict with the design goals of
the testbed. This flexibility allows for future adaptability to support cost-effectiveness and portability. As to wireless attacks, while they
additional protocols as needed. are relatively simple to implement given the onboard WiFi capabilities
SCASS has been designed with portability and cost-effectiveness in of Raspberry Pi 3 (or through cost-effective USB WiFi adapters), we
mind, making it relatively affordable for security researchers. have not focused on them within SCASS, as of yet. This aspect requires
Table A.13 provides an estimated breakdown of the total cost. It is further study to create representative wireless attack scenarios for
important to note that the overall cost can be further reduced by SCADA systems. These limitations will be explored in future works.
replacing physical devices with virtual counterparts, although this
would come at the expense of domain fidelity.
7.2. Comparison with other testbeds
7.1.2. Application areas
In Section 3, we have reviewed various related works that employ
The modular design of the SCASS testbed facilitates the creation
different approaches, including physical, virtual, and hybrid designs.
of digital twins, as demonstrated in Section 5. This capability allows
for the vulnerability analysis of real SCADA systems, with an example According to the analysis by Qassim et al. (2017), hybrid architectures
scenario detailed in Section 6.3. While our focus was not exclusively offer significant advantages by combining the scalability and cost bene-
on validating security control solutions, we provide insights into in- fits of virtual components with the domain fidelity provided by physical
tegrating security solutions, such as Intrusion Detection Systems (IDS) elements.
and Intrusion Prevention Systems (IPS), within the SCASS framework in In this section, we compare our SCASS solution with other hybrid
Section 7.3.1. We are also exploring the use of SCASS for experimenting solutions, utilizing the features outlined in Section 7.1 to evaluate and
with Moving Target Defense (MTD) techniques, particularly through contrast their capabilities and benefits.
the application of the Software Defined Networking (SDN) paradigm. For each feature of each category, we define a set of parameters to
These aspects will be addressed in future developments of SCASS. evaluate the testbeds and obtain a rating score of their characteristics,
application areas, and testing capabilities, as per the mentioned taxon-
7.1.3. Testing capabilities omy defined in Mallouhi et al. (2011). Tables 7, 8, and 9 illustrate the
Reconnaissance, ARP spoofing, and Man In The Middle (MITM) detailed criteria adopted for evaluating hybrid testbeds.
attacks are feasible within the SCASS network architecture due to the The features related to the testbed characteristics are benchmarked
unencrypted nature of the Modbus protocol, allowing for the replication in Tables 10 and 11. Table 12 instead summarizes the results of the

15
N. d’Ambrosio et al. Computers & Security 151 (2025) 104315

or prevention systems. Addressing this gap could enhance the testbed’s


utility in evaluating and developing comprehensive security solutions.
These limitations and potential improvements are discussed in detail
in the following section, where we explore strategies for enhancing the
capabilities of our testbed and address its current constraints.
Table 8 Additionally, it is important to note that while the testbeds reviewed
Application areas evaluation components. in our analysis, including SCASS, offer various features and functional-
Component Values Details ity, none of them specifically addresses cloud-based brute force attacks.
Vulnerability No attack scenarios This is an area that remains underexplored, yet presents significant
analysis research opportunities. Furthermore, although some testbeds could
Attack scenarios presented potentially be adapted to include wireless attacks, there remains a need
Security validation No security controls integrated for dedicated solutions that address the unique challenges posed by
into the testbed
this specific type of attack scenarios. We encourage future research to
Not present in the current
architecture, but suggestions on focus on these areas to advance the development of comprehensive and
how to integrate them. adaptable security testing environments.
Security controls integrated in the
testbed
Impact analysis Impact analysis not performed 7.3. SCASS limitations and proposed solutions
Impact analysis performed

A careful analysis of the SCASS testbed allows us to identify a


few issues and challenges that are still to be faced. In the follow-
ing subsections, we summarize our findings and propose potential
Table 9
solutions.
Testing capabilities evaluation components.
Component Values Details
7.3.1. Limited set of communication protocols
Coverage level (per Troublesome implementation
attack category)
SCASS components rely exclusively on the Modbus communication
Potentially implementable protocol. Although Modbus is an old protocol, its continued preva-
Not implemented but discussed lence in industrial systems (largely due to the widespread deploy-
Covered ment of legacy infrastructures) justifies this choice. Supporting this
decision, a study (Irmak and Erkek, 2018) reports that Modbus still
accounts for 50% of protocol usage in SCADA enterprise systems.
Though, recent studies show that industrial systems are gradually
shifting toward newer communication protocols. To remain effective,
SCASS should hence cover them. To address this limitation, we inves-
comparative evaluation for both the ‘‘Application areas’’ category and
tigated two possible approaches for substituting industrial protocols.
the ‘‘Testing capabilities’’ category.
The first approach involves replacing the existing physical devices
The SCASS testbed demonstrates significant strengths in repro-
with ones that inherently support the desired modern protocols. This
ducibility and transparency. Its source code is publicly available, which
facilitates replication and further development by other researchers. method would enhance domain fidelity, even though it might increase
Additionally, SCASS provides detailed information about both hard- costs. The second approach involves virtualizing all physical PLCs.
ware and networking configurations, which enhances its usability and This technique enables the system to support multiple communication
transparency. protocols without requiring additional physical hardware. A variety
Another key advantage of SCASS is its cost-effectiveness. By includ- of community-developed libraries are available to help construct the
ing a comprehensive cost estimation of the physical components (as necessary programming logic.
detailed in Table A.13), the testbed allows researchers and security Modbus and DNP3 utilize master/slave communication protocols.
practitioners to assess the budgetary implications and feasibility of Consequently, this substitution would require little effort. However,
replicating the setup. Cost transparency aids in informed decision- integrating Profinet may demand additional adjustments due to its
making and reduces entry barriers for those utilizing or building upon consumer/producer communication paradigm. Notably, zone PLCs act
SCASS for research or security testing purposes. Despite SCASS ad- as I/O controllers in a Profinet-based network. Indeed, they produce
vantages, there are limitations that need to be addressed. One such the configuration working parameters for the I/O devices, while simul-
limitation is the current domain fidelity of SCASS. The testbed primarily taneously consuming the state information coming from them. On the
simulates industrial control processes rather than replicating them with
other hand, IEDs act as I/O devices within the network. Therefore, they
high accuracy. Although this approach provides valuable insights, the
will be consumers of output data from I/O controllers and producers of
fidelity could be significantly enhanced by incorporating additional
state information. Similarly, integrating MQTT requires modifications
physical devices into the SCASS setup. However, this enhancement
to the network infrastructure due to its publisher/subscriber nature. In
would come with increased costs, which must be carefully weighed
against the benefits of improved domain fidelity. this context, each node operates both as a publisher and a subscriber,
Furthermore, SCASS is currently designed with support for a single depending on the topics. Controlled devices would publish their state
ICS protocol, specifically Modbus. As discussed in the previous sections information on specific topics to which the controller device subscribes.
of the paper, this choice reflects both the widespread use of Mod- Conversely, the controller device publishes configuration parameters to
bus in ICS environments and the practical constraints of the testbed. topics to which the controlled devices subscribe. GOOSE follows the
However, the inclusion of other modern protocols could broaden the same publish/subscribe architecture but does not require a centralized
applicability of SCASS. Additionally, the current implementation does message broker as it relies on multicast messaging over Ethernet for
not incorporate integrated security controls, such as intrusion detection communicating.

16
N. d’Ambrosio et al.
Table 10
Comparison in terms of characteristics evaluation components.
Mallouhi et al. Morris et al. Singh et al. Koutsandria Keliris et al. Ghaleb et al. Rosa et al. Bernieri et al. Foglietta et al. Xie et al. Čeleda et al. Cruz and SCASS
(2011) (2011) (2015) et al. (2015) (2016) (2016) (2017) (2016) (2019) (2018) (2020) Simões
(2021)
Source code
availability
Hardware
configuration
details
Network
17

configuration
details
Virtualization V V V V V V V V V V C C C
type
Presence of real
devices
Hardware
configuration
details
Process type S P S P P S P P P S P P S
Cost details

Computers & Security 151 (2025) 104315


N. d’Ambrosio et al. Computers & Security 151 (2025) 104315

safety, cost-savings, fidelity, and scalability (Qassim et al., 2017).

• We replicate the EPIC architecture through SCASS by integrat-


ing container-based virtualization through the adoption of the
Macvlan feature, which addresses the networking challenges iden-
tified by the authors of the related EPICTWIN (Kandasamy et al.,
Table 11 2021) testbed.
Comparison in terms of implemented ICS protocols. • We showcase a threat analysis methodology and a practical exam-
Work Supported ICS protocols ple of how it is possible to configure a system to realize offensive
Mallouhi et al. (2011) Modbus, DNP3 scenarios.
Morris et al. (2011) Modbus, DNP3 • We benchmark our testbed against valuable alternatives proposed
Koutsandria et al. (2015) Modbus, IEC 61580
in the literature, by relying on the features identified by the
Ghaleb et al. (2016) Modbus
Keliris et al. (2016) Modbus
inspiring works of Mallouhi et al. (2011) and Alanazi et al.
Singh et al. (2015) DNP3, IEC-60870-5-101, and (2023).
Blowfish encryption. • We identify and discuss SCASS limitations, while also proposing
Rosa et al. (2017) Modbus effective solutions for addressing them.
Bernieri et al. (2016) Modbus
(Foglietta et al., 2019) Modbus In our future investigations, we aspire to enhance the capabilities
Xie et al. (2018) OPC, Modbus, Siemens S7 of the testbed by reproducing a complete grid within the cabinet,
(Čeleda et al., 2020) Modbus utilizing a, heterogeneous set of physical devices. Additionally, we
Cruz and Simões (2021) Modbus aim to broaden the scope of the target architecture by incorporating
SCASS Modbus
other commonly used protocols in OT systems, such as MQTT or IEC
61850. We plan to diversify the range of both physical and virtual
devices, exploring alternatives like IFTTT and n8n.io, and incorporating
libraries such as PyModbusTCP and OpenPLC.
In the context of modeling cybersecurity threats in the ICS domain,
various methodologies and approaches have been developed (Bhamare
7.3.2. Security validation et al., 2020b). Notably, security contextualization of well-established
Unlike other testbeds, SCASS does not include integrated security safety models (Kriaa et al., 2015; Leveson, 2004; Yan et al., 2016;
controls. This is because SCASS was not specifically designed to eval- Young and Leveson, 2013, 2014) has been widely adopted. In our
uate the effectiveness of protection measures in reducing the risks upcoming work, we aim to practically apply such methodologies within
associated with ICS systems. As such, the ‘‘Security controls presence’’ SCASS to identify comprehensive attack graphs.
application area is not a key focus of the SCASS platform. However, this Through the SCASS platform, we have explored attack scenarios
does not mean that security capabilities cannot be incorporated into the within the ICS domain. Alanazi et al. (2023) offer a comprehensive
system. On the contrary, SCASS is designed with flexibility in mind, taxonomy of attacks against SCADA systems. In future work, we plan
allowing for the seamless integration of network security measures to leverage this taxonomy to formally verify the SCASS testbed’s ability
without altering the core architecture. to reproduce diverse and complex attack scenarios. This will provide
In SCASS, routing is managed by headless containers, which sim- a more rigorous validation of SCASS as a platform for cybersecurity
plifies the integration of security mechanisms like Intrusion Detection experimentation and defense analysis in the SCADA domain.
Systems (IDSs). Thanks to container-based networking, incorporating Moreover, the SCASS environment benefits from the integration of
intrusion detection systems into the platform is straightforward and can cyber-range functionality, including scoring or monitoring systems. The
enhance the overall security analysis. inclusion of these features would facilitate the reproduction of red-team
versus blue-team cyber simulation scenarios, offering a holistic testing
7.3.3. Attack complexity ground for cybersecurity measures. This can be further enhanced by
One of the attacks (namely, the False Data Injection with ARP integrating security controls in the architecture.
poisoning) illustrated in Section 6 is intentionally basic and does not Looking ahead, we plan to expand SCASS by deploying lightweight
components, such as Wazuh agents (Katulić et al., 2024), across the
capture the full complexity of modern SCADA systems. The second at-
testbed infrastructure. These agents will systematically collect critical
tack (i.e., the Multi-stage False Data Injection) does represent a concrete
data, including raw network traffic, system performance metrics, and
example of a more advanced scenario that proceeds through multiple
logs. This data will be invaluable for deepening our understanding of
stages of the so-called cyber kill chain, including lateral movement
attacker activities, as well as assessing the impact of cyberattacks on
and privilege escalation. We chose these two attack categories in order
ICS environments. The insights gained through such improvements will
to demonstrate SCASS ability to seamlessly reproduce scenarios with
support more comprehensive security evaluations and contribute to a
different complexity levels. We have demonstrated in the paper that the better understanding of threats targeting both SCADA and ICS systems.
threat analysis task leveraging the STAMP/STPA-Sec framework serves Finally, we are also planning to enhance SCASS by incorporating
as a functional validation of the testbed’s effectiveness. The flexibility Moving Target Defense (MTD) functionality through the application of
of the approach allows it to be easily employed both for basic and for Software Defined Networking (SDN). This approach will add a dynamic
more advanced attack simulations. security layer to SCASS, allowing for continuous changes in the system’s
attack surface to make it more resilient against cyberattacks. The
8. Conclusions current organization of the testbed lends itself well to this upgrade, as
the integration of SDN can be easily accomplished using containerized
This work has introduced SCASS as a robust and versatile architec- versions of Open vSwitches.7
ture for replicating heterogeneous security testbeds. The SCASS design The continuous evolution and refinement of SCASS align with the
is based on a hybrid approach, combining both physical and virtual dynamic landscape of cybersecurity, ensuring its relevance and ef-
elements. Our contributions can be summarized as follows: fectiveness in addressing emerging threats and challenges in the ICS
domain.
• We propose a hybrid and modular (Alves et al., 2018) testbed
for SCADA cybersecurity based on lightweight virtualization, a
7
combination that offers several benefits in terms of repeatability, https://www.openvswitch.org/

18
N. d’Ambrosio et al.
Table 12
Comparison in terms of Application areas and Testing capabilities.
Mallouhi et al. Morris et al. Singh et al. (Koutsandria Keliris et al. Ghaleb et al. Rosa et al. Bernieri et al. Foglietta et al. Xie et al. Čeleda et al. Cruz and SCASS
(2011) (2011) (2015) et al., 2015) (2016) (2016) (2017) (2016) (2019) (2018) (2020) Simões
(2021)
Application areas
Vulnerability
analysis
Security
validation
Impact analysis
19

Testing capabilities
Reconnaissance
Cloud-based
brute force
Command
injection
MITM
ARP Spoofing
Wireless attacks
Sniffing attacks
Vulnerability
discovery

Computers & Security 151 (2025) 104315


N. d’Ambrosio et al. Computers & Security 151 (2025) 104315

Fig. A.14. SCASS circuit diagram.

CRediT authorship contribution statement Table A.13


SCASS physical components and related costs.

Nicola d’Ambrosio: Writing – review & editing, Validation, Soft- Number Component Estimated price
in dollars (2024)
ware, Methodology, Conceptualization. Giulio Capodagli: Writing –
1 CIRCUIT BREAKER Merlin Green C60N 6,7
original draft, Visualization, Validation, Software, Methodology, For-
4 PLC ABB PM554-TP-ETH 660
mal analysis, Conceptualization. Gaetano Perrone: Writing – origi- 1 PERLE Switch IDS-409-1SFP 1.605,00
nal draft, Validation, Software, Methodology, Formal analysis, Con- 1 Raspberry Pi 4 60
ceptualization. Simon Pietro Romano: Writing – review & editing, 2 Switching power supply Phoenix Contact 55
Supervision, Project administration, Methodology. UNO-PS 220V-24V
1 Switching power supply MEAN WELL RS15S 13,9
220V 5V
Declaration of competing interest 1 Switching power supply MEAN WELL NDR 66,72
24024 220V 24V
The authors declare that they have no known competing finan-
cial interests or personal relationships that could have appeared to
influence the work reported in this paper.
facilitate the testbed replicability, we developed virtual components of
Acknowledgment programmable logic controllers (PLCs) to enable the deployment of the
testbed without relying on physical PLCs, albeit with reduced fidelity.
The development of SCASS has been carried out in collaboration Finally, we released several video clips with deployment instructions.8
with ‘‘Comando per le Operazioni in Rete’’ (COR), the main Ital-
ian military interforce unit specializing in cyber defense and cyber Data availability
security operations. COR has provided the necessary hardware re-
quired for the project’s implementation. This work has been funded We aim to share publicly the source code on GitHub.
by the project Azione IV.4 - Dottorati e contratti di ricerca su tem-
atiche dell’innovazione - DM 1061 del 10 agosto 2021, Italy (CUP:
E65F21003690003). References

Adepu, S., Kandasamy, N.K., Mathur, A., 2019. EPIC: An electric power testbed for
Appendix A. Hardware configuration details
research and training in cyber physical systems security. In: Computer Security.
Springer International Publishing, pp. 37–52. http://dx.doi.org/10.1007/978-3-
In this appendix, we provide detailed information about SCASS 030-12786-2_3.
hardware components. In particular, Fig. A.14 illustrates the SCASS cir-
cuit diagram, while Table A.13 provides the list of currently employed
8
hardware components with associated costs. Moreover, in order to https://github.com/NS-unina/SCASS/tree/master/docs/video

20
N. d’Ambrosio et al. Computers & Security 151 (2025) 104315

Alanazi, M., Mahmood, A., Chowdhury, M.J.M., 2023. SCADA vulnerabilities and Dietz, M., Pernul, G., 2020. Unleashing the digital twin’s potential for ICS security.
attacks: A review of the state-of-the-art and open issues. Comput. Secur. IEEE Secur. Priv. 18, 20–27. http://dx.doi.org/10.1109/MSEC.2019.2961650.
125, 103028. http://dx.doi.org/10.1016/j.cose.2022.103028, URL https://www. Ferencz, K., Domokos, J., 2019. Using node-RED platform in an industrial environment.
sciencedirect.com/science/article/pii/S0167404822004205. In: XXXV. Jubileumi Kandó Konferencia, Budapest. pp. 52–63.
Alves, T., Das, R., Werth, A., Morris, T., 2018. Virtualization of SCADA testbeds for cy- Fidler, D.P., 2011. Was stuxnet an act of war? Decoding a cyberattack. IEEE Secur.
bersecurity research: A modular approach. Comput. Secur. 77, 531–546. http://dx. Priv. Mag. 9 (4), 56–59. http://dx.doi.org/10.1109/msp.2011.96.
doi.org/10.1016/j.cose.2018.05.002, URL https://www.sciencedirect.com/science/ Foglietta, C., Masucci, D., Palazzo, C., Santini, R., Panzieri, S., Rosa, L., Cruz, T., Lev, L.,
article/pii/S0167404818304905. 2019. From detecting cyber-attacks to mitigating risk within a hybrid environment.
Anon, 2017. Idaho national laboratory (INL) smart grid test bed revision 2. IEEE Syst. J. 13 (1), 424–435. http://dx.doi.org/10.1109/JSYST.2018.2824252.
IdahoSmartGrid, https://www.energy.gov/sites/prod/files/2017/10/f38/CX- Fortinet, 2024. 2024 state of operational technology and cybersecurity report.
270322.pdf. https://www.fortinet.com/content/dam/fortinet/assets/reports/report-state-ot-
Anon, 2021. ElectricPower and intelligent control (EPIC) testbed. EPICiTrust, https: cybersecurity.pdf Online; 15-Nov-2024.
//itrust.sutd.edu.sg/itrust-labs-home/itrust-labs_epic. frangoteam, 2020. FUXA. https://github.com/frangoteam/FUXA Online; 18-Nov-2024.
Anon, 2023a. ISO/IEC 20922:2016(en) information technology — Message queuing Friedberg, I., McLaughlin, K., Smith, P., Laverty, D., Sezer, S., 2017. STPA-SafeSec:
telemetry transport (MQTT) v3.1.1 (preview). MQTTprotocol https://www.iso.org/ Safety and security analysis for cyber-physical systems. J. Inf. Secur. Appl. 34,
obp/ui/#iso:std:iso-iec:20922:ed-1:v1:en. 183–196. http://dx.doi.org/10.1016/j.jisa.2016.05.008.
Anon, 2023b. Drago, chernovite’s PIPEDREAM malware targeting industrial con- Ghaleb, A., Zhioua, S., Almulhem, A., 2016. SCADA-SST: a SCADA security testbed.
trol systems (ICS). Drago https://www.dragos.com/blog/industry-news/chernovite- In: 2016 World Congress on Industrial Control Systems Security. WCICSS, pp. 1–6.
pipedream-malware-targeting-industrial-control-systems/. http://dx.doi.org/10.1109/WCICSS.2016.7882610.
Anon, 2023c. IEEE standard for electric power systems communications-distributed Haag, S., Anderl, R., 2018. Digital twin – proof of concept. Manuf. Lett. 15, 64–66.
network protocol (DNP3). http://dx.doi.org/10.1109/ieeestd.2012.6327578, http://dx.doi.org/10.1016/j.mfglet.2018.02.006.
DNP3protocol. He, R., Chen, G., Dong, C., Sun, S., Shen, X., 2019. Data-driven digital twin technology
Anon, 2023d. Kali linux home page. KaliLinuxDistribution. https://www.kali.org/. for optimized control in process systems. ISA Trans. http://dx.doi.org/10.1016/j.
Anon, 2023e. MulVal, a multi stage Vulnerability Analysis tool. MulVal. https://github. isatra.2019.05.011.
com/risksense/mulval/. Holmes, D., Papathanasaki, M., Maglaras, L., Ferrag, M.A., Nepal, S., Janicke, H., 2021.
Anon, 2023f. OpenPLC site. OpenPLC https://openplcproject.com/. Digital twins and cyber security – solution or challenge? In: 2021 6th South-East
Anon, 2023g. PROFINET system description. PROFINETprotocol http://us.profinet.com/ Europe Design Automation, Computer Engineering, Computer Networks and Social
wp-content/uploads/2012/11/PROFINET_SystemDescription_ENG_2014_web.pdf. Media Conference (SEEDA-CECNSM). pp. 1–8. http://dx.doi.org/10.1109/SEEDA-
Anon, 2023h. Scapy project. Scapyproject https://scapy.net/. CECNSM53056.2021.9566277.
Anon, 2023i. Wired, fed’s uncover a ’swiss army knife’ for hacking industrial control
Howard, D., 2019. The digital twin: Virtual validation in electronics development and
systems. WiredPipedream, https://www.wired.com/story/pipedream-ics-malware/.
design. In: 2019 Pan Pacific Microelectronics Symposium (Pan Pacific). pp. 1–9.
Anon, 2023j. Wired, Russia’s sandworm hackers attempted a third black-
http://dx.doi.org/10.23919/PanPacific.2019.8696712.
out in Ukraine. WiredIndustroyer https://www.wired.com/story/sandworm-russia-
Irmak, E., Erkek, I., 2018. An overview of cyber-attack vectors on SCADA systems.
ukraine-blackout-gru/.
In: 2018 6th International Symposium on Digital Forensic and Security. ISDFS, pp.
Artac, M., Borovssak, T., Di Nitto, E., Guerriero, M., Tamburri, D.A., 2017. DevOps: In-
1–5. http://dx.doi.org/10.1109/ISDFS.2018.8355379.
troducing infrastructure-as-code. In: 2017 IEEE/ACM 39th International Conference
Kandasamy, N.K., Venugopalan, S., Wong, T.K., Leu, N.J., 2022. An electric power
on Software Engineering Companion (ICSE-C). pp. 497–498. http://dx.doi.org/10.
digital twin for cyber security testing, research and education. Comput. Electr.
1109/ICSE-C.2017.162.
Eng. 101, 108061. http://dx.doi.org/10.1016/j.compeleceng.2022.108061.
Bernieri, G., Moro, F.D., Faramondi, L., Pascucci, F., 2016. A testbed for integrated
Kandasamy, N.K., Venugopalan, S., Wong, T.K., Nicholas, L.J., 2021. EPICTWIN: An
fault diagnosis and cyber security investigation. In: 2016 International Conference
electric power digital twin for cyber security testing, research and education.
on Control, Decision and Information Technologies (CoDIT). IEEE, pp. 454–459.
arXiv:arXiv:2105.04260.
http://dx.doi.org/10.1109/codit.2016.7593605.
Kara, İ., Aydos, M., 2019. The ghost in the system: technical analysis of remote access
Bhamare, D., Zolanvari, M., Erbad, A., Jain, R., Khan, K., Meskin, N., 2020a. Cybersecu-
trojan. Int. J. Inf. Technol. Secur. 11 (1), 73–84.
rity for industrial control systems: A survey. Comput. Secur. 89, 101677. http://dx.
Katulić, F., Groš, S., Sumina, D., Erceg, I., 2024. Enhancing industrial automation
doi.org/10.1016/j.cose.2019.101677, URL https://www.sciencedirect.com/science/
and control systems cybersecurity using endpoint detection and response tools.
article/pii/S0167404819302172.
In: Auer, M.E., Langmann, R., May, D., Roos, K. (Eds.), Smart Technologies for a
Bhamare, D., Zolanvari, M., Erbad, A., Jain, R., Khan, K., Meskin, N., 2020b.
Sustainable Future. Springer Nature Switzerland, Cham, pp. 186–197.
Cybersecurity for industrial control systems: A survey. Comput. Secur. 89, 101677.
Keliris, A., Salehghaffari, H., Cairl, B., Krishnamurthy, P., Maniatakos, M., Khorrami, F.,
http://dx.doi.org/10.1016/j.cose.2019.101677.
2016. Machine learning-based defense against process-aware attacks on industrial
Boettiger, C., 2015. An introduction to docker for reproducible research. Oper. Syst.
control systems. In: 2016 IEEE International Test Conference. ITC, pp. 1–10.
Rev. 49 (1), 71–79.
http://dx.doi.org/10.1109/TEST.2016.7805855.
Castiglione, L.M., Hau, Z., Get, P., Co, K.T., Munoz-Gonzalez, L., Teng, F., Lupu, E.,
2022. HA-grid: Security aware hazard analysis for smart grids. In: 2022 IEEE Koutsandria, G., Gentz, R., Jamei, M., Scaglione, A., Peisert, S., McParland, C., 2015.
International Conference on Communications, Control, and Computing Technologies A real-time testbed environment for cyber-physical security on the power grid. In:
for Smart Grids (SmartGridComm). IEEE, pp. 446–452. http://dx.doi.org/10.1109/ Proceedings of the First ACM Workshop on Cyber-Physical Systems-Security and/Or
smartgridcomm52983.2022.9961003. PrivaCy. ACM, pp. 67–78. http://dx.doi.org/10.1145/2808705.2808707.
Caturano, F., Perrone, G., Romano, S.P., 2020. Capturing flags in a dynamically Kriaa, S., Pietre-Cambacedes, L., Bouissou, M., Halgand, Y., 2015. A survey of
deployed microservices-based heterogeneous environment. In: 2020 Principles, approaches combining safety and security for industrial control systems. Reliab.
Systems and Applications of IP Telecommunications (IPTComm). pp. 1–7. http: Eng. Syst. Saf. 139, 156–178. http://dx.doi.org/10.1016/j.ress.2015.02.008.
//dx.doi.org/10.1109/IPTComm50535.2020.9261519. Langner, R., 2011. Stuxnet: Dissecting a cyberwarfare weapon. IEEE Secur. Priv. Mag.
Čeleda, P., Vykopal, J., Švábenský, V., Slavíček, K., 2020. KYPO4indUStry. In: Proceed- 9 (3), 49–51. http://dx.doi.org/10.1109/msp.2011.67.
ings of the 51st ACM Technical Symposium on Computer Science Education. ACM, Lee, S.H., Shin, S.-M., Hwang, J.S., Park, J., 2020. Operational vulnerability iden-
pp. 1026–1032. http://dx.doi.org/10.1145/3328778.3366908. tification procedure for nuclear facilities using STAMP/STPA. IEEE Access 8,
Chan, J., Reith, M., 2022. Cyber concerns with cloud computing. Eur. Conf. Cyber 166034–166046. http://dx.doi.org/10.1109/access.2020.3021741.
Warf. Secur. http://dx.doi.org/10.34190/eccws.21.1.429. Leveson, N., 2004. A new accident model for engineering safer systems. Saf. Sci. 42
CODESTS, 2021. CODESYS development system. https://help.codesys.com/webapp/ (4), 237–270. http://dx.doi.org/10.1016/s0925-7535(03)00047-x.
_cds_f_development_system_introduction;product=codesys;version=3.5.17.0 Online; Leveson, N., 2016. Engineering a Safer World. The MIT Press.
27-Jul-2023. Makrakis, G.M., Kolias, C., Kambourakis, G., Rieger, C., Benjamin, J., 2021. Industrial
Conti, M., Donadel, D., Turrin, F., 2021. A survey on industrial control system testbeds and critical infrastructure security: Technical analysis of real-life security incidents.
and datasets for security research. IEEE Commun. Surv. Tutor. 23 (4), 2248–2294. IEEE Access PP, http://dx.doi.org/10.1109/ACCESS.2021.3133348, 1–1.
http://dx.doi.org/10.1109/comst.2021.3094360. Mallouhi, M., Al-Nashif, Y., Cox, D., Chadaga, T., Hariri, S., 2011. A testbed for
Cruz, T., Simões, P., 2021. Down the rabbit hole: Fostering active learning through analyzing security of SCADA control systems (TASSCS). In: ISGT 2011. pp. 1–7.
guided exploration of a SCADA cyber range. Appl. Sci. 11 (20), 9509. http: http://dx.doi.org/10.1109/ISGT.2011.5759169.
//dx.doi.org/10.3390/app11209509. Mark Hearn, S.R., 2019. Cybersecurity Considerations for Digital Twin. Industrial
Cui, H., Hong, J., Louden, R., 2024. An overview of the security of programmable logic Internet Consortium.
controllers in industrial control systems. Encyclopedia 4 (2), 874–887. http://dx. Masi, M., Sellitto, G.P., Aranha, H., Pavleska, T., 2023. Securing critical infrastructures
doi.org/10.3390/encyclopedia4020056, URL https://www.mdpi.com/2673-8392/ with a cybersecurity digital twin. Softw. Syst. Model. 22 (2), 689–707.
4/2/56. Mathur, A.P., Tippenhauer, N.O., 2016. SWaT: A water treatment testbed for research
Decotignie, J., 2005. Ethernet-based real-time and industrial communications. Proc. and training on ics security. In: 2016 International Workshop on Cyber-Physical
IEEE 93, 1102–1117. http://dx.doi.org/10.1109/JPROC.2005.849721. Systems for Smart Water Networks (CySWater). IEEE, pp. 31–36.

21
N. d’Ambrosio et al. Computers & Security 151 (2025) 104315

Maynard, P., 2018. Peter Maynard’s GitHub. https://github.com/PMaynard/ICS- Singh, P., Garg, S., Kumar, V., Saquib, Z., 2015. A testbed for SCADA cyber security
TestBed-Framework. and intrusion detection. In: 2015 International Conference on Cyber Security
Maynard, P., McLaughlin, K., Sezer, S., 2018. An open framework for deploying of Smart Cities, Industrial Control System and Communications. SSIC, pp. 1–6.
experimental SCADA testbed networks. In: Electronic Workshops in Computing. BCS http://dx.doi.org/10.1109/SSIC.2015.7245683.
Learning & Development, pp. 92–101. http://dx.doi.org/10.14236/ewic/ics2018. Tabaa, M., Chouri, B., Saadaoui, S., Alami, K., 2018. Industrial communication based
11. on modbus and node-RED. Procedia Comput. Sci. 130, 583–588. http://dx.doi.org/
Mehta, K., Joshi, R., Kulkarni, S., Soni, B., 2015. Implementation of PLC based software 10.1016/j.procs.2018.04.107, URL https://www.sciencedirect.com/science/article/
prototype for 45.6 MHz, 100 kW, ICRH DAC using EPICS control system. Int. J. pii/S1877050918304691. The 9th International Conference on Ambient Systems,
Sci. Eng. Res. 6. Networks and Technologies (ANT 2018) / The 8th International Conference on
Morris, T., Vaughn, R., Dandass, Y.S., 2011. A testbed for SCADA control system Sustainable Energy Information Technology (SEIT-2018) / Affiliated Workshops.
cybersecurity research and pedagogy. In: Proceedings of the Seventh Annual Tao, Y., Xu, W., Li, H., Ji, S., 2019. Experience and lessons in building an ICS security
Workshop on Cyber Security and Information Intelligence Research. CSIIRW ’11, testbed. In: 2019 1st International Conference on Industrial Artificial Intelligence
Association for Computing Machinery, New York, NY, USA, http://dx.doi.org/10. (IAI). pp. 1–6. http://dx.doi.org/10.1109/ICIAI.2019.8850804.
1145/2179298.2179327. Varghese, S.A., Ghadim, A.D., Balador, A., Alimadadi, Z., Papadimitratos, P., 2022.
Nicolae, A., Korodi, A., 2018. Node-red and OPC UA based lightweight and low-cost Digital twin-based intrusion detection for industrial control systems. In: 2022 IEEE
historian with application in the water industry. In: 2018 IEEE 16th International International Conference on Pervasive Computing and Communications Workshops
Conference on Industrial Informatics. INDIN, pp. 1012–1017. http://dx.doi.org/10. and other Affiliated Events (PerCom Workshops). pp. 611–617. http://dx.doi.org/
1109/INDIN.2018.8471928. 10.1109/PerComWorkshops53856.2022.9767492.
NIST, 2020. Industrial control system. https://csrc.nist.gov/glossary/term/industrial_ Wang, Y., Peng, D., Qi, E., Wang, H., 2022. Modbus/TCP data acquisition system
control_system Online; 27-Aug-2024. based on industrial ethernet technology. In: 2022 4th International Conference
Niu, H., Ma, C., Wang, C., Han, P., 2018. Hazard analysis of traffic collision avoidance on Electrical Engineering and Control Technologies. CEECT, pp. 746–750. http:
system based on STAMP model. In: 2018 IEEE International Conference on Progress //dx.doi.org/10.1109/CEECT55960.2022.10030131.
in Informatics and Computing (PIC). IEEE, pp. 445–450. http://dx.doi.org/10.1109/ Xie, Y., Wang, W., Wang, F., Chang, R., 2018. VTET: A virtual industrial control system
pic.2018.8706283. testbed for cyber security research. In: 2018 Third International Conference on
Olivares-Rojas, J.C., Reyes-Archundia, E., Gutiérrez-Gnecchi, J.A., Molina-Moreno, I., Security of Smart Cities, Industrial Control System and Communications. SSIC, pp.
Cerda-Jacobo, J., Méndez-Patiño, A., 2022. Towards cybersecurity of the smart 1–7. http://dx.doi.org/10.1109/SSIC.2018.8556732.
grid using digital twins. IEEE Internet Comput. 26 (3), 52–57. http://dx.doi.org/ Yamin, M., Katt, B., Gkioulos, V., 2020. Cyber ranges and security testbeds: Scenarios,
10.1109/MIC.2021.3063674. functions, tools and architecture. Comput. Secur. 88, http://dx.doi.org/10.1016/j.
Panchal, A.C., Khadse, V.M., Mahalle, P.N., 2018. Security issues in iIoT: A com- cose.2019.101636.
prehensive survey of attacks on iIoT and its countermeasures. In: 2018 IEEE Yan, F., Tang, T., Yan, H., 2016. Scenario based STPA analysis in automated urban
Global Conference on Wireless Computing and Networking. GCWCN, pp. 124–130. guided transport system. In: 2016 IEEE International Conference on Intelligent Rail
http://dx.doi.org/10.1109/GCWCN.2018.8668630. Transportation (ICIRT). IEEE, pp. 425–431. http://dx.doi.org/10.1109/icirt.2016.
Park, K.T., Lee, J., Kim, H.-J., Noh, S.D., 2020/01/01. Digital twin-based cyber physical 7588764.
production system architectural framework for personalized production. Int. J. Young, W., Leveson, N., 2013. Systems thinking for safety and security. In: Proceedings
Adv. Manuf. Technol. 106 (5), 1787–1810. http://dx.doi.org/10.1007/s00170-019- of the 29th Annual Computer Security Applications Conference. ACSAC ’13,
04653-7. Association for Computing Machinery, New York, NY, USA, pp. 1–8. http://dx.
Qassim, Q., Jamil, N., Zainal Abidin, I., Ezanee Rusli, M., Yussof, S., Ismail, R., doi.org/10.1145/2523649.2530277.
Abdullah, F., Ja’afar, N., Che Hasan, H., Daud, M., 2017. A survey of SCADA Young, W., Leveson, N.G., 2014. An integrated approach to safety and security based on
testbed implementation approaches. Indian J. Sci. Technol. 10 (26), 1–8. http: systems theory. Commun. ACM 57 (2), 31–35. http://dx.doi.org/10.1145/2556938.
//dx.doi.org/10.17485/ijst/2017/v10i26/116775. Zhang, H., Zhang, G., Yan, Q., 2018. Digital twin-driven cyber-physical production
Rosa, L., Cruz, T., Simões, P., Monteiro, E., Lev, L., 2017. Attacking SCADA systems: system towards smart shop-floor. J. Ambient Intell. Humaniz. Comput. 10 (11),
A practical perspective. In: 2017 IFIP/IEEE Symposium on Integrated Network 4439–4453. http://dx.doi.org/10.1007/s12652-018-1125-4.
and Service Management. IM, pp. 741–746. http://dx.doi.org/10.23919/INM.2017.
7987369.

22

You might also like