=Paper=
{{Paper
|id=Vol-2940/paper27
|storemode=property
|title=A Systematic Approach for the definition of countermeasures in industrial IoT: An Automotive Case
|pdfUrl=https://ceur-ws.org/Vol-2940/paper27.pdf
|volume=Vol-2940
|authors=Massimiliano Masi,Tanja Pavleska,Simone Pezzoli,Massimiliano Calani,Giovanni Denaro,Alberto Leporati,Manuel Cheminod,Luca Durante,Lucia Seno,Adriano Valenzano,Mario Ciampi,Fabrizio Marangio,Giovanni Schmid,Mario Sicuranza,Marco Zuppelli,Giuseppe Manco,Luca Caviglione,Massimo Guarascio,Marzio Di Feo,Simone Raponi,Maurantonio Caprolu,Roberto Di Pietro,Paolo Spagnoletti,Federica Ceci,Andrea Salvi,Vincenzo Carletti,Antonio Greco,Alessia Saggese,Mario Vento,Gabriele Costa,Enrico Russo,Andrea Valenza,Giuseppe Amato,Simone Ciccarone,Pasquale Digregorio,Giuseppe Natalucci,Giovanni Lagorio,Marina Ribaudo,Alessandro Armando,Francesco Benvenuto,Francesco Palmarini,Riccardo Focardi,Flaminia Luccio,Edoardo Di Paolo,Enrico Bassetti,Angelo Spognardi,Anna Pagnacco,Vita Santa Barletta,Paolo Buono,Danilo Caivano,Giovanni Dimauro,Antonio Pontrelli,Chinmay Siwach,Gabriele Costa,Rocco De Nicola,Carmelo Ardito,Yashar Deldjoo,Eugenio Di Sciascio,Fatemeh Nazary,Vishnu Ramesh,Sara Abraham,Vinod P,Isham Mohamed,Corrado A. Visaggio,Sonia Laudanna
|dblpUrl=https://dblp.org/rec/conf/itasec/MasiPP21
}}
==A Systematic Approach for the definition of countermeasures in industrial IoT: An Automotive Case==
https://ceur-ws.org/Vol-2940/paper27.pdf
A Systematic Approach for the Definition of
Countermeasures in Industrial IoT: An Automotive
Case
Massimiliano Masi1 , Tanja Pavleska2 and Simone Pezzoli1
1
Autostrade Per L’Italia S.p.A. 50, Via Alberto Bergamini - 00159 Roma, Italy
2
Jozef Stefan Institute, Ljubljana, Slovenia
Abstract
Inter-dependencies in critical industrial systems pose huge security challenges, which are tightly linked
to the problems of interoperability and trustworthiness within and among those systems. In this paper,
we try to establish the interconnection between these system properties in a way that allows the
establishment of one property to positively affect and facilitate the establishment of the other. For that
purpose, we design a methodology based on standardized and well-known models and frameworks,
which are upgraded as needed and integrated into a single generic framework. Although this approach
is meant to primarily help the security experts and the architects in their design practices, it also aims to
facilitate the dialogue on important (cyber and physical) security issues among all relevant levels in an
industrial IoT organization. The formal value and the practical applicability of the methodology are also
demonstrated through a use case in the domain of road transportation and automotive industry.
Keywords
Critical Infrastructure, C-ITS, Cybersecurity Framework
1. Introduction
Industrial Automation and Control Systems (IACS) are usually physically located in remote, often
unsupervised sites where they enable safety-critical processes. They are often managed remotely
from a control room and are supervised by trained personnel via commands to sense and actuate
the physical world either through the Internet (via cloud environments) or through a dedicated
network. Some assets are also designed to preserve safety in case of networked systems. For
example, in the road transportation sector, the tunnels or the Cooperative Intelligent Transport
Systems (C-ITS) [1, 2] are such sites, whereas ventilators in the tunnels and the Infrastructure-
to-Vehicle (I2V) messages have the role of an IACS. Malfunctioning of those IACS may result in
traffic congestion and, ultimately, loss of lives.
Cyber-attacks in IACS have been on the rise [3]: critical infrastructures in general face
continuous attacks, ranging from low-skilled and person-motivated to state-sponsored attacks.
Loss of availability in one infrastructure may result in loss of availability in others as a result of
ITASEC’21: Italian Conference on Cybersecurity, April 7–9, 2021, Online
Envelope-Open mmasi@autostrade.it (M. Masi); atanja@e5.ijs.si (T. Pavleska); simone.pezzoli@autostrade.it (S. Pezzoli)
GLOBE https://www.autostrade.it/ (M. Masi); https://www.e5.ijs.si/ (T. Pavleska)
Orcid 0000-0003-4737-7107 (M. Masi)
© 2021 Copyright for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).
CEUR
Workshop
Proceedings
http://ceur-ws.org
ISSN 1613-0073
CEUR Workshop Proceedings (CEUR-WS.org)
cascading effects propagating throughout the interconnected sites [4]. Establishing trust and
interoperability in the shared cybersecurity practices, as well as an optimal security posture of
the Essential Services [5] can dramatically improve the coordination of defenses and responses
to attacks in the affected infrastructures.
IACS are composed of both cyber and physical assets, each having their own life-cycle.
Detecting and protecting against cybersecurity events cannot be based solely on the expertise
of the cybersecurity practitioner, nor evaluated ex-post through vulnerability assessment and
penetration testing. The process of securing IACS shall be rigorous, measurable, and performed
systematically1 , not only from a cyber, but also from a physical perspective. Although critical
infrastructures are mandated to maintain a Cybersecurity department [7], vendors of IIoT
systems are not, exposing the infrastructure to supply-chain based attacks [8]. Hence, the
security architecture of system components cannot be addressed with typical cybersecurity
countermeasures: patching systems may not always be possible, the protocols may be unknown
and proprietary or their legacy systems may not be designed with security in mind.
Considering the growing complexity of the IIoT due to the interconnected systems of systems,
deciding what to protect and how becomes a challenge and an important open question. Risks
are usually elicited by publications [3, 9] or by performing a qualitative risk analysis on the
IACS. But how to attain the same risk level across the interconnected critical infrastructures;
and how to achieve the same technical level of trust when the selection of countermeasures are
subject to the talent of the practitioner? There are some generic best practices guiding critical
infrastructures towards a cybersecurity posture on their IACS [10, 11]. However, selecting the
right countermeasures or defining the processes implementing a Cyber Security Management
System (CSMS) is also problematic and requires qualitative risk-analysis. The NIST Cybersecu-
rity Framework [12] helps the security architects by defining guidelines and a set of controls
that can be profiled for a specific context. Profiling the framework requires high skills and
competence of both the business and the cybersecurity context.
With this work, we aim to make the following contributions: i) we define a systematic
approach to catalogue the relevant cyber and physical assets composing an IACS, including
their interconnections, and over the entire life-cycle of each asset, ii) based on that, we design
a model that elicits the high level security goals by interacting with all the stakeholders of
the IACS, and iii) we define a profile based on the NIST Cybersecurity Framework which is
repeatable and measurable, thus offering a way to practically implement the proposed elements
and we show how to apply for defining the security posture of C-ITS. The higher goal is attaining
the required level of trust within a system of interconnected critical infrastructures.
To achieve the goals outlined above, the paper is structured as follows: in Section 2, we
overview relevant related studies and fit our work within the state of the art. Section 3 introduces
the theoretical background needed to understand the methodology proposed in Section 4. This
is further supported with an application to the C-ITS use case in Section 5. Finally, in Section 6
we conclude and provide some insights into other current and future updates of the presented
work.
1
In fact, the EU Police Department, EUROPOL, requires that the constantly evolving threats are addressed in a
holistic and effective manner [6].
2. Related work
When IT/OT systems grow in complexity, it is recommended to adopt modularity and layering
as the principles of decomposition in order to attain security [13]. Such decomposition can
be facilitated by the use of enterprise architectures (EA), which define strategies and practices
for logical grouping of assets with shared values. EAs achieve modularity by employing
the concept of a building block, which represents a reusable module defining the life-cycle
of a specific functionality. By combining building blocks in different manners, a variety of
technologically and economically sustainable architectures can be created. In the context of
interconnected critical infrastructures, deciding which (architectural) layers to use is crucial for
the harmonization of security countermeasures, as architectural models can be devised only for
a specific context. For instance, the SGAM[14] is defining a layering approach for the energy
sector, while the EIRA [15] defines views for the European public administrations. Although
our methodology is parametric with respect to the architectural model used, the choice of the
particular model to be used still remains to be made. In this paper, we use RAMI 4.0 [16], as the
de-facto EA for IIoT.
The use of Enterprise Architectures as facilitators for a systematic approach to devise security
assessment in critical infrastructures is not new. For instance, Gottschalk et al. [17] describe
how to use the SGAM for developing architectures in the Energy, Healthcare, and Smart City
domains. The same has been done for the eAgriculture domain in [18]. In their book, the authors
concentrate on applying the methodology to devise generic requirements and interoperability
problems, leaving security to sector-specific analysis [19, 20]. However, extending IT assessment
methodologies to IIoT does not automatically consider the specificity of the domain, thereby
leaving out important security aspects [21]. We take this point as a starting premise in our
work and propose a systematic approach that is specifically designed for the OT and IIoT
domain. In that context, the US Cybersecurity and Infrastructure Security Agency profiled the
Cybersecurity Framework (CSF) for the transportation sector [22], defining guidelines for the
companies in the transportation sector to adopt the NIST CSF. However this guide was made
for the previous version of the CSF, and it does not entail a systematic approach. Our work
extends previous attempts to apply the same methodology to other sectors such as energy and
healthcare [23, 24].
3. Preliminaries
To establish a sound theoretical base, we first introduce RAMI 4.0 in as the underlying architec-
tural model. Then, we present the Reference Model for Information Assurance and Security
(RMIAS), which will complement RAMI 4.0 to elicit the high level security goals for each stage
of the assets’ life cycles. Following a standardized process of designing architectural profiles
with a sound security posture, we rely on the NIST recommendations and the NIST CSF profile.
Finally, we describe IEC 62443 as the best practice used following the NIST CSF as informative
reference in the context of OT/IIoT.
3.1. RAMI 4.0 for Defining the Architectural Model
The Reference Architectural Model for Industrie 4.0, RAMI 4.0 [16] is the de-facto standard
for the design of IT architectures for Industrial interconnected systems [25]. It has been
devised as a reference architecture model for the international projects involving Industrie 4.0
automation,whose supply chain of intermediate goods is composed of several companies with
own security posture and legal context. Guaranteeing consistent trust levels and interoperability
of processes, as well as secure information sharing in such heterogeneous contexts is a complex
task. A single company or project alone cannot establish a governance scheme without having
a systematic approach agreed upon by all stakeholders and implemented as a practice. RAMI
4.0 guarantees the interoperability of data flows, security processes, and data management in a
holistic manner.
RAMI 4.0 is composed of 3 dimensions and 6 layers. The first dimension, the architectural
viewpoints or Layers, groups the EA concepts into two models: physical (the asset and integration
layers) and digital (all other layers). The Asset layer is where all the definitions of hardware
components are contained. The Integration layer connects the physical with the logical world.
Each item in the Asset layer has a counterpart in the Integration layer that serves as an interface
to support the transition towards a fully digitized system. The Communication layer contains all
the communications among industrial components (e.g., OPC-UA, MQTT). The communication
protocols in this layer can be secured, as they either have their own security profile or they are
part of the requirements for compliance with international standards. The Information layer
defines the syntax and the semantics of the information shared by the industrial component.
The Functional layer, on the other hand, defines the functionalities and processes supporting
the business use cases and are typically subject to security reviews. Finally, the Business layer
contains the business processes needed to build the use case in which each asset should be put
in production.
The second dimension (Life Cycle and Value Stream) is used to categorize assets by their
purpose - as either (proto) type or instance/production. The last dimension represents a typical
automation pyramid [26]. There, the typical Industry 4.0 characteristics are defined as part
of the Connected World, integrating the description of all cross-cutting concerns about the
connection of the automation assets to the Internet. As a result, enabling remote access to
the legacy operational technology exposes the systems (that were initially not designed with
security in mind) to a series of new threats that can occur in each RAMI layer [27].
3.2. RMIAS: Risk-Based Countermeasures for Assets’ Life-cycles
Each item in the RAMI 4.0 cube has its own life cycle: PLCs are designed, installed, and
decommissioned; SCADAs are installed, patched, managed, and decommissioned, etc. To grasp
the peculiarities of the assets’ life cycles, we rely on the Reference Model for Information
Assurance & Security (RMIAS) [28, 29] and integrate it within RAMI’s layers.
The RMIAS cycle has four stages: an Information Taxonomy of the item’s components and
data; high level representation of the desired Security Goals (elicited through a risk assessment
together with field’s experts); selected relevant security Countermeasures to fulfill the security
goals; and a Security information Development Life Cycle. It essentially defines a method to
elicit security countermeasures for each stage of a life cycle in view of its four dimensions.
3.3. NIST Cybersecurity Framework: Automating the Subcategory Choice
The NIST Cybersecurity framework (CSF) [12] provides guidelines for the critical infrastructures
in assessing their security posture and for defining a roadmap for potential improvements. It
introduces 5 high level functions, 23 categories, and 108 subcategories, each of which points to
a set of informative references from best practices. In the context of industrial IoT systems, the
NIST approach is integrated into the IEC 62443 standard, which is described in Section 3.4.
The NIST framework covers the necessary activities to identify the assets, flows, and require-
ments, to protect the items and the infrastructure, to detect anomalies, to recover and to respond
to an incident. A framework profile (NIST CSF profile) is a subset of the 108 categories relevant
in a specific context (e.g., road transport, tunnels, or intelligent transport systems, as discussed
in Section 5). In fact, defining a profile for a specific context enables its stakeholders to share
the same security posture, facilitating the trust establishment among them. The NIST CSF
also defines a way to perform risk-based enhancements from the current security posture to a
desired one, by selecting and enhancing those subcategories and the related countermeasures
according to the profiling methodology. However, defining a profile is not an easy task [23].
Profiles creation is guided by the business objectives, the threat context (environment), and the
security policies peculiar to the context.
In order to lower the extent of relying on cybersecurity experts for the selection of a proper
subcategory, in our methodology we propose to elicit the profiling requirements in a way that
creates a cybersecurity posture harmonised across the actors realising a given concept (for e.g.,
a road operator and a car manufacturer in C-ITS. This results in a process that is repeatable and
measurable, as demonstrated in Section 4.
3.4. IEC 62443: Enhancing the profiling of NIST Subcategories
The IEC 62443 standard series addresses IT cyber and physical security requirements for IACS
that had once represented a closed system, but are now exposed to both public and private
networks. IEC 62443 encompasses the security requirements for both the systems and the
components and is a set of informative references selected from the NIST framework. It allows
to perform gap analysis between the current and the target security posture (as defined by NIST).
To do that, IEC 62443 defines the concept of Security Level Target - the IACS’ desired posture
based on the risk analysis and a specific attacker profile For each requirement, at least three
additional Requirement Enhancements, (REs) are defined that show how the security posture is
revised.
One of the pillars of IEC 62443 is the subdivision in zone and conduits. A zone is a grouping
of logical or physical assets that share the same security requirements, while a conduit is a
grouping of communication assets that protect the security of the channels contained in the
conduit.
Our methodology helps the architect in defining the ways to enhance the profiling process
for each subcategory. Thus, the application of the IEC 62443 starts by carrying out discussions
with the business experts, with the aim to obtain the necessary items (devices, protocols,
semantic information, and business requirements). These are then categorized in the RAMI 4.0
cube according to the specific use cases. The process results with a first initial review of the
requirements and its design.
4. The Methodology
The goal of the methodology is to obtain a profile of the framework devised for a specific
context with a rigorous, measurable, and repeatable process to attain trust among different
interconnected infrastructures. Although the methodology is parametric with respect to the
architectural model chosen, RAMI 4.0 is used to define the architectural layers and viewpoints
as the de-facto standard for the IIoT sector. The formal representation of this approach is shown
in Algorithm 1. With the notation 𝑑𝑙,𝑗,𝑘 we identify the item 𝑑 grouped in the layer 𝑙, with life
cycle 𝑗 (type/instance) and automation level 𝑘. For each of them, an RMIAS taxonomy entry (a
tuple) is created, indicating the stage of the categorized item in its life cycle (e.g., a PLC that
stays in layer Asset, life cycle Type/Development, automation level Field Device has different
security requirements during the design, operation, and decommission stages.
Algorithm 1: The methodology
Result: A profile of the NIST CSF
1 Input: Business Objectives, Relevant Literature, Threat Environment, Regulations;
// Perform interviews with business experts, and obtain items and use cases
2 𝐷 ← item list, 𝑈 ← use cases ;
// Create RAMI matrices
3 foreach 𝑑 ∈ 𝐷 do
// Assign each architectural item to its RAMI 4.0 layer
4 assign d to its layer 𝑙, life cycle 𝑗, and automation level 𝑘 ;
// For each RAMI identified location
5 foreach 𝑑𝑙,𝑗,𝑘 do
6 Create a RMIAS tuple 𝑡 ∶=;
7 foreach 𝑡 and item’s life cycle stage do
// Elicit security requirements
8 create a high level goal, 𝐺 ← 𝑔;
9 end
10 end
11 end
// Define the requirements
12 foreach 𝑔 ∈ 𝐺 do
13 create a requirement 𝑟 ∈ 𝑅 using language defined in rfc 2119;
14 assign 𝑟 to the NIST subcategory;
15 end
16 Create the digital twin, simulate, and re-evaluate the posture;
Then, for each tuple 𝑡, the high level security goals are elicited (such as Availability of the
data) This stage is also performed with interviews, focusing on what to protect instead of how
Figure 1: The auto-generated NIST CSF categories from the methodology.
to protect it. Then, the security architect performs a trade off analysis to define the requirement
fulfilling the particular goal using the common rfc 2119 language. The resulting requirements
are placed in the right subcategory of the CSF, resulting in the desired profile. Finally, a digital
twin of the architecture is composed using a threat modeling tool (see Section 4.2). Security
simulations are made and, whenever a new possible attack is found or a new device enters into
the system, the architecture is updated and the posture is re-evaluated.
4.1. Relation to the NIST CSF
Although the connection between the methodology and the NIST guidelines and recommen-
dations seems implicit, each of the stages of applying the reference models and standards can
be traced back to a NIST requirement. For example: the iteration through RAMI layers fulfills
the subcategory ID.AM-3 from the NIST CSF. Similarly, the risk analysis performed during the
RMIAS cycle fulfills the ID.RA-4,5 and ID.RM-1. Furthermore, using a life cycle for each asset
fulfils the requirements PR.DS-3, IP-2, IP-6, and PT-5. RAMI 4.0’s hierarchy level dimension,
on the other hand, elicits the risks related to supply chain, thus fulfilling ID.CS-1,2,3. Finally,
the simulation on the digital twin fulfills the PR-IP.10. This concept of automatically selecting
the NIST categories based on the architectural account of the assets’ security through their
life-cycles with our methodology is presented in Figure 1. The NIST CSF categories with bold
contour contain subcategories whose requirements define actions and activities which are parts
of the methodology.
4.2. The digital twin: Practical remarks
IEC 62443-2-1 requires the definition of zones and conduit to form the reference architecture(see
Section 3.4). As part of our methodology, we model the reference architecture in securiCAD [30].
This model greatly supports the use of the reference architecture and enables the concept of
refactoring: by defining high value assets that we want to protect (e.g., actuators, or private data),
we reason over abstract architectural assets to check for potential attack paths, thus performing
the cost-effective analysis required by RMIAS to evaluate the countermeasures. Typically, the
MITRE ATT&CK for ICS matrix [31], which contains a list of attackers’ techniques to reach
high value assets, is used as a reference model for testing and proving that the architecture is
resilient with respect to known attacks. The SecuriCAD model can be extended and further
tailored to the context of the profile, as it is supported by a formal toolbox for that purpose [32].
This not only enables adaptability of the methodology, but it also allows for testability and
repeatability of its results.
5. Use case: C-ITS and the Automotive Industry
Cooperative Intelligent Transport Systems (C-ITS) are an example of a critical infrastructure
with strong inter-dependencies, where a security breach can trigger cascading effects. For
instance, if an attacker forges messages impersonating a road operator, its message may cause
vehicle crash in the motorway, while a failure in synchronizing the semaphores in a municipality
to facilitate the journey of the emergency vehicle may lead to casualties. C-ITS are networks
of ITS stations cooperating to deliver a set of use cases like: notification of road works ahead,
danger in the motorway, and emergency vehicle approaching. They also represent the backbone
of the next-generation automotive industry. Cooperation in these systems is established between
municipalities, road and public transportation operators, vehicle manufacturers and users in
order to attain the security and safety qualities in multi-modal transportation [33].
As essential services, C-ITS require high security posture and trustworthy operational envi-
ronment, as they enable vehicles and the road infrastructure to ”talk” to each other (Vehicle-
to-Anywhere, V2X communications). This is done via messages (e.g., traffic notifications)
generated by sensors installed on the road. The messages are then collected by a Central ITS
Station [34] and wrapped in a standard-format message [35] to be forwarded to the devices
installed on the road (at every 2 to 5 kilometres). Those devices, in turn, broadcast the mes-
sages to vehicles that act accordingly, by e.g., displaying a message on the driver’s dashboard,
actuating brakes or platooning trucks. Although this message exchange is highly regulated,
some aspects of the value chain are left unspecified. ETSI TS 102 94 [35] defines the security
for the messages broadcasted from the road devices to the vehicles, while other specifications
describe best practices to secure the back-end environment. However, the attack surface is still
uncovered in many aspects and left to be dealt with by the individual operators.
The EU Commission fosters trust by defining requirements that each C-ITS operator has
to obey [36, 37]. However, the requirements do not address the entire life cycle of a message,
from creation to usage, but only the communication interfaces between the operators. The
remaining intermediaries and the definition of their security postures are left to the operator
and may require bilateral trust agreement within a set of interconnected infrastructures, such
as operators and car manufacturers.
By employing our methodology, this problem can be overcome by providing a generic inter-
operable approach among the stakeholders of C-ITS. Starting from a road operator standpoint,
initially all the data flows are systematically mapped in RAMI 4.0: road devices are Assets, while
the ETSI standards [35] are Communication and Information layer’s items. Then, for each asset,
its life-cycle is evaluated with the RMIAS: for each item in RAMI, a risk assessment is performed
with the traffic control experts to elicit the high level security goals, creating a taxonomy of all
the architectural assets (road sensors, central ITS stations, communication protocols to road
devices, etc). For each tuple in the taxonomy a cost-effectiveness analysis is performed of the
off-the-shelf security countermeasures guided by the informative reference found and the legal
context. As a results, a security architecture is proposed by the Security Architect, where each
requirement, control, or process is categorized in the NIST CSF subcategories, as stated in
Section 4. Finally, an initial security posture is obtained that is ready to be communicated to
all other stakeholders. Car manufacturers build their posture by applying the methodology in
the same way (defining the data flows of their on board equipment, performing risk analyses,
and creating their own CSF profile). The profiles, once shared, facilitate the gap analysis,
fostering the trust in the system and between the stakeholders. Interoperability is achieved as
stakeholders are obliged to use best practices as informative sources (e.g., 62443, ETSI, or ISO),
yet remaining at a sufficient high level to maintain confidentiality of the aspects that critical
infrastructures cannot disclose [7].
6. Conclusions and Future works
In this paper we introduced a methodology that facilitates the creation of security postures using
a systematic approach guided by the RAMI 4.0 architectural model that analyses each asset’s
life cycle eliciting security countermeasures. The output of the methodology is a profile of the
NIST Cybersecurity framework that is then proposed as a method to attain interoperability
and measurability of security postures when they have to be shared among interconnected
infrastructures.
Although we relied on RAMI 4.0 for layering and module definition, the methodology itself is
independent from the reference model used, as long as it has a clearly defined architecture. In
future works we will investigate further the possibility of generalisation to other architectures,
such as ISO IoT RA developed by ISO JTC 1/SC 41 or the Industrial Internet Architecture. That
would allow implementation of the methodology in contexts other than the Industrial IoT.
References
[1] European Parliament and of the Council, DIRECTIVE 2004/54/EC on minimum safety
requirements for tunnels in the trans-european road network, 2004.
https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32004L0054, Last Ac-
cessed Feb 15, 2021.
[2] The C-ITS Platform, C-ITS platform phase II, final report, Technical Report,
The European Commission, 2017. https://ec.europa.eu/transport/sites/transport/files/
2017-09-c-its-platform-final-report.pdf, Last Accessed Feb 15, 2021.
[3] ENISA, From January 2019 to April 2020, The year in review, ENISA Threat Landscape,
Technical Report, ENISA, 2020.
[4] K. Moulinos, A. Drougkas, K. Dellios, P. Kasse, Good practices on interdependencies
between OES and DSPs, Technical Report, ENISA, 2018.
[5] European Parliament and of the Council, DIRECTIVE 2016/1148 concerning measures for
a high common level of security of network and information systems across the union,
2016.
https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32016L1148, Last Ac-
cessed Feb 15, 2021.
[6] Europol, Attacks on critical infrastructure, 2021. URL: https://www.europol.europa.eu/
iocta/2015/attacks-on-ci.html.
[7] The European Parliament and the Council of the European Union, Directive (eu) 2016/1148,
2016.
[8] J. F. Miller, Supply Chain Attack Framework and Attack Patterns, Technical Report, MITRE
Technical Report, 2013.
[9] G. Ayoade, S. Chandra, L. Khan, K. Hamlen, B. Thuraisingham, Automated threat report
classification over multi-source data, in: 2018 IEEE 4th International Conference on
Collaboration and Internet Computing (CIC), 2018, pp. 236–245. doi:1 0 . 1 1 0 9 / C I C . 2 0 1 8 .
00040.
[10] IEC 62443 2009-2018, IEC 62443 Security for Industrial Automation and Control Systems.
Standard., Technical Report, Internation Electrotechnical Commission, 2009.
[11] B. Leander, A. Čaušević, H. Hansson, Applicability of the iec 62443 standard in industry
4.0 / iiot, in: Proceedings of the 14th International Conference on Availability, Reliability
and Security, ARES ’19, Association for Computing Machinery, New York, NY, USA, 2019.
URL: https://doi.org/10.1145/3339252.3341481. doi:1 0 . 1 1 4 5 / 3 3 3 9 2 5 2 . 3 3 4 1 4 8 1 .
[12] National Institute of Standards and Technology, Framework for Improving Critical Infras-
tructure Cybersecurity, Version 1.1, Technical Report, NIST, 2018.
[13] R. Ross, M. McEvilley, J. C. Oren, Systems Security Engineering: Considerations for a
Multidisciplinary Approach in the Engineering of Trustworthy Secure Systems, Special
Publication (NIST SP) - 800-160, Technical Report, NIST, 2018.
[14] C. Neureiter, G. Eibl, D. Engel, S. Schlegel, M. Uslar, A concept for engineering smart
grid security requirements based on sgam models, Comput. Sci. 31 (2016) 65–71. URL:
https://doi.org/10.1007/s00450-014-0288-2. doi:1 0 . 1 0 0 7 / s 0 0 4 5 0 - 0 1 4 - 0 2 8 8 - 2 .
[15] EIRA, Views, viewpoints and architecture building blocks, 2021. URL: https:
//joinup.ec.europa.eu/collection/european-interoperability-reference-architecture-eira/
solution/eira/chapter-3-views-viewpoints-and-architecture-building-blocks.
[16] R. Heidel, M. Hoffmeister, M. Hankel, U. Döbrich, Industrie 4.0, The Reference Architectural
Model RAMI 4.0 and the Industrie 4.0 component, Beuth Verlag GmbH, 2019.
[17] M. Gottschalk, C. Delfs, , M. Uslar, The Use Case and Smart Grid Architecture Model
Approach: The IEC 62559-2 Use Case Template and the SGAM applied in various domains,
SpringerBriefs in Energy, springer ed., Springer, ???? URL: http://www.springer.com/de/
book/9783319492285. doi:1 0 . 1 0 0 7 / 9 7 8 - 3 - 3 1 9 - 4 9 2 2 9 - 2 .
[18] B. Weinert, M. Uslar, Challenges for system of systems in the agriculture application
domain, in: 2020 IEEE 15th International Conference of System of Systems Engineering
(SoSE), 2020, pp. 000355–000360. doi:1 0 . 1 1 0 9 / S o S E 5 0 4 1 4 . 2 0 2 0 . 9 1 3 0 5 5 2 .
[19] M. Uslar, C. Rosinger, S. Schlegel, Security by design for the smart grid: Combining the
sgam and nistir 7628, 2014. doi:1 0 . 1 1 0 9 / C O M P S A C W . 2 0 1 4 . 2 3 .
[20] CEN-CENELEC-ETSI Smart Grid Coordination Group, Smart Grid Information Secu-
rity, Technical Report, 2012. URL: https://ec.europa.eu/energy/sites/ener/files/documents/
xpert_group1_security.pdf.
[21] J. Nurse, S. Creese, D. Roure, Security risk assessment in internet of things systems, IT
Professional 19 (2017). doi:1 0 . 1 1 0 9 / M I T P . 2 0 1 7 . 3 6 8 0 9 5 9 .
[22] U.S. Department of Homeland Security, Transportation Systems Sec-
tor Cybersecurity Framework Implementation Guidance, Technical Re-
port, CISA, 2015. URL: https://www.cisa.gov/sites/default/files/publications/
tss-cybersecurity-framework-implementation-guide-2016-508v2_0.pdf.
[23] T. Pavleska, H. Aranha, M. Masi, G. P. Sellitto, Drafting a cybersecurity framework profile
for smart grids in EU: A goal-based methodology, in: S. Bernardi, V. Vittorini, F. Flammini,
R. Nardone, S. Marrone, R. Adler, D. Schneider, P. Schleiß, N. Nostro, R. L. Olsen, A. D. Salle,
P. Masci (Eds.), Dependable Computing - EDCC 2020 Workshops - AI4RAILS, DREAMS,
DSOGRI, SERENE 2020, Munich, Germany, September 7, 2020, Proceedings, volume 1279
of Communications in Computer and Information Science, Springer, 2020, pp. 143–155. URL:
https://doi.org/10.1007/978-3-030-58462-7_12. doi:1 0 . 1 0 0 7 / 9 7 8 - 3 - 0 3 0 - 5 8 4 6 2 - 7 \ _ 1 2 .
[24] H. Aranha, M. Masi, T. Pavleska, G. P. Sellitto, Securing mobile e-health environments by de-
sign: A holistic architectural approach, in: 2019 International Conference on Wireless and
Mobile Computing, Networking and Communications, WiMob 2019, Barcelona, Spain, Oc-
tober 21-23, 2019, IEEE, 2019, pp. 1–6. URL: https://doi.org/10.1109/WiMOB.2019.8923479.
doi:1 0 . 1 1 0 9 / W i M O B . 2 0 1 9 . 8 9 2 3 4 7 9 .
[25] Reference Architecture Model Industrie 4.0 (RAMI 4.0), english translation of DIN SPEC
91345:2016-04, Technical Report, DIN, 2016.
[26] R. Cupek, M. Drewniak, A. Ziebinski, M. Fojcik, “digital twins” for highly customized
electronic devices – case study on a rework operation, IEEE Access PP (2019) 1–1. doi:1 0 .
1109/ACCESS.2019.2950955.
[27] E. D. Knapp, J. T. Langill, Industrial Network Security: Securing Critical Infrastructure
Networks for Smart Grid, SCADA, and Other Industrial Control Systems, 2nd ed., Syngress
Publishing, 2014.
[28] Y. Cherdantseva, J. Hilton, A reference model of information assurance security, in:
2013 International Conference on Availability, Reliability and Security, 2013, pp. 546–555.
doi:1 0 . 1 1 0 9 / A R E S . 2 0 1 3 . 7 2 .
[29] A. Mosenia, N. K. Jha, A comprehensive study of security of internet-of-things, IEEE
Transactions on Emerging Topics in Computing 5 (2017) 586–602. doi:1 0 . 1 1 0 9 / T E T C . 2 0 1 6 .
2606384.
[30] Foreseeti, Foreseeti securicad solutions, 2021. URL: https://foreseeti.com/securicad/.
[31] MITRE, Att&ck for industrial control systems, 2021. URL: https://collaborate.mitre.org/
attackics/index.php/Main_Page.
[32] MAL, Meta attack language, 2021. URL: https://mal-lang.org/.
[33] E. Commission, Collaborative its, 2021. URL: https://ec.europa.eu/transport/themes/its/
c-its_en.
[34] G. Wilhelm, H. Fouchal, K. Thomas, M. Ayaida, A c-its central station as a communication
manager, in: M. Hodoň, G. Eichler, C. Erfurth, G. Fahrnberger (Eds.), Innovations for
Community Services, Springer International Publishing, Cham, 2018, pp. 33–43.
[35] ETSI, ETSI TS 102 941, Trust and Privacy management, Technical Report, 2019.
[36] Security Policy & Governance Framework for Deployment and Operation of European
Cooperative Intelligent Transport Systems, Technical Report, C-ITS Platform, 2017.
[37] Certificate Policy for Deployment and Operation of European Cooperative Intelligent
Transport Systems, Technical Report, C-ITS Platform, 2018.