DOCTORA L T H E S I S
Security Standard Compliance
in
System of Systems
Ani Bicaku
Cyber-Physical Systems
Security Standard Compliance
in
System of Systems
Ani Bicaku
Luleå University of Technology
Department of Computer Science, Electrical and Space Engineering
EISLAB
Luleå, Sweden
Supervisors:
Professor Jerker Delsing and Prof(FH) Dr. Markus G. Tauber
ii
To Silia and my family
iii
iv
Abstract
The world we live in is becoming digitalized by transforming our society and economy
in an unpredicted way. Digital technologies are transforming products, manufacturing
assets, and entire supply chains. These technologies revolutionize how organisations engage with customers, other partners, and society depending on the ability to connect
people, technology, and processes. Distributed services through different platforms, organisations, and even regions are becoming very common with the digital transformation
of industrial processes. More and more systems are being constructed by interconnecting
existing and new independent systems. The transformation from traditional and isolated
systems to connected components in a System of Systems (SoS), provides many advantages such as flexibility, efficiency, interoperability, and competitiveness. While it is clear
that digital technology will transform most industries, there are a number of challenges
to be addressed, especially in terms of standards and security.
In the past, providing a secure environment meant isolation from external access and
providing physical protection, usually based on proprietary standards. Nowadays, with
the development of state-of-the-art technologies, these systems have to meet and provide
proof of fulfilling several requirements and involving many stakeholders. Thus, to assure
that organisations can move towards this multi-stakeholder cooperation, security is one of
the challenges that need to be addressed. With the increasing number of devices, systems,
and services in these complex systems and the number of standards and regulations
they should fulfill, the need for automated standard compliance verification is of utmost
importance. Such verification will ensure that the components included in their business
processes comply with the imposed standards, laws and regulations.
The research presented in this thesis targets the automated and continuous standard
compliance verification in SoS. Standard compliance verification provides evidence that
processes and their components satisfy the requirements defined by national and international standards. The thesis proposes an automated and continuous standard compliance
verification framework that provides evidence if SoS components fulfill security standards’
requirements based on extracted measurable indicator points. Since these systems evolve
over time, the standard compliance is verified in design time and continuously monitored
and verified during run time after the SoS has been deployed.
v
vi
Contents
Part I
Chapter 1 – Introduction
1.1 Introduction . . . . . . .
1.2 Motivation . . . . . . . . .
1.3 Research Questions . . .
1.4 Research Methodology . .
1.5 Thesis Scope and Outline
1
.
.
.
.
.
3
3
8
9
10
10
for Digitalisation
. . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . .
13
13
14
17
Chapter 3 – Standardization Landscape
3.1 Standardization Bodies and Standards . . . . . . . . . . . . . . . . . . .
3.2 ISA/IEC 62443 series overview . . . . . . . . . . . . . . . . . . . . . . .
3.3 IEC 62443-3-3: System security requirements and security levels . . . . .
23
23
28
42
Chapter 4 – Monitoring and Standard Compliance Verification
4.1 Standard Compliance Verification . . . . . . . . . . . . . . . . . . . . . .
4.2 Monitoring and Standard Compliance Verification Framework . . . . . .
4.3 Security Standards Evaluation . . . . . . . . . . . . . . . . . . . . . . . .
4.4 Monitoring and Standard Compliance Verification Integrated in Industrial
Internet of Things . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.5 Monitoring and Standard Compliance Verification Integrated in Service
Oriented Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
47
48
50
Chapter 5 – Summary of Contributions
5.1 Summary of Appended Papers . . . . . . . . . . . . . . . . . . . . . . . .
5.2 Additional Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
55
60
Chapter 6 – Conclusions and Future Work
6.1 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
61
61
64
References
65
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Chapter 2 – Security: The challenge
2.1 Standards and Digitalisation . . .
2.2 Digitalisation and Security . . . . .
2.3 Digitalisation Related Technologies
vii
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
52
53
Part II
73
Paper
1
2
3
4
5
6
7
A
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Property Analysis and Evaluation . . . . . . . . . . . . . . . . . . . . .
Monitoring Overview and Related Work . . . . . . . . . . . . . . . . .
Overview of Security/Assurance Support in Existing Monitoring Tools .
Evidence Gathering Mechanism Design . . . . . . . . . . . . . . . . . .
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
Paper
1
2
3
4
5
6
7
B
Introduction . . . . . . . . . .
Related Work . . . . . . . . .
Security Related Baselines . .
ENISA Evaluation . . . . . .
Assessment of IAAS Platforms
Conclusion and Future Work .
Acknowledgment . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
91
. 93
. 94
. 95
. 97
. 98
. 102
. 103
Paper
1
2
3
4
5
6
C
Introduction . . . . . . . . . .
Related Work . . . . . . . . .
The CPPS Meta-model . . . .
Security in CPPS . . . . . .
Conclusions and Future Work
Acknowledgement . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
105
107
108
113
116
120
122
Paper
1
2
3
4
5
6
7
D
Introduction . . . . . . .
Related Work . . . . . .
Proposed Authentication
Security Analysis . . . .
Performance evaluation .
Conclusion . . . . . . . .
Acknowledgment . . . .
. . . . . . .
. . . . . . .
Mechanism
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
125
127
128
131
135
137
139
140
Paper
1
2
3
4
5
6
7
E
Introduction . . . . . . . . . . . . . . .
Related Work . . . . . . . . . . . . . .
Operations Security . . . . . . . . . . .
Standards and Best Practice Guidelines
Operations Security Controls . . . . . .
Assessment of Cloud Platforms . . . .
Conclusions . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
145
147
148
149
150
152
154
159
viii
75
77
79
80
83
84
88
88
8
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Paper
1
2
3
4
5
6
F
Introduction . . . . . .
Related Work . . . . .
Arrowhead Framework
On-boarding Procedure
Conclusion . . . . . . .
Acknowledgment . . .
Paper
1
2
3
4
G
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Monitoring and Standard Compliance Verification Framework . . . . .
A representative set of MIPs for the Monitoring and Standard Compliance
Verification Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
179
181
183
184
H
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Monitoring and Standard Compliance Verification Framework . . . . .
A representative set of MIPs for the Monitoring and Standard Compliance
Verification Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
197
199
201
203
5
6
Paper
1
2
3
4
5
6
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Paper
1
2
3
4
5
6
7
8
9
I
Paper
1
2
3
4
5
J
Introduction . . . . . . . . . . . . . .
Related Work . . . . . . . . . . . . .
Monitoring and Standard Compliance
Eclipse Arrowhead Framework . . . .
Measurable Security Indicators . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
163
165
166
168
173
176
176
189
192
192
208
212
213
217
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
Standardization Landscape . . . . . . . . . . . . . . . . . . . . . . . . . . 227
Standards and Best Practice Guidelines Evaluation . . . . . . . . . . . . 232
Metric Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
Monitoring and Standard Compliance Verification Framework - Architecture237
IIoT Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
ix
. . . . . . .
. . . . . . .
Verification
. . . . . . .
. . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
251
253
255
256
259
262
6
7
8
Security Standard
ation Time . . . .
Conclusion . . . .
Acknowledgement
Compliance
. . . . . . .
. . . . . . .
. . . . . . .
Verification during Onboarding and
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
x
Oper. . . . 266
. . . . 272
. . . . 272
Acknowledgments
This PhD thesis is the result of the effort and support of several people, universities, and
other institutions to whom I am incredibly grateful.
Firstly, I would like to express my gratitude to the University of Applied Science
Burgenland that allowed me to pursue my research while employed.
Secondly, I would like to thank my supervisors, Prof (FH) Dr. Markus Tauber and
Professor Jerker Delsing, for their guidance, feedback, and advice. I enjoyed working
with you and would like to thank you for helping me grow as a researcher and engineer.
I enjoyed and appreciated the opportunity of being part of several European funded
projects such as SemI4.0, Productive 4.0, and Arrowhead Tools project, where I had the
chance to know, collaborate and discuss with academic and industrial partners. I want
to thank all the researchers, experts, and students who contributed to the appended
papers and helped conduct my research. I also want to thank the EISLAB team for their
support, even though our offices are separated by more than 2500 kilometers.
My warm gratitude goes to my family for supporting me throughout my life in general. Finally, I would like to thank Silia for her advice, motivation, and patience she has
given me. Without her support, it would not have been possible to make this journey.
Vienna, October 2020
Ani Bicaku
xi
xii
List of Abbreviations
AO Asset Owner
API Application Programming Interface
AUTOSTAR Automotive Open System Architecture
AWS Amazon Web Services
CIA Confidentiality, Integrity, Availability
CPS Cyber Physical Systems
CPPS Cyber Physical Production Systems
CR Component Requirements
CRM Customer Relation Manager
DCS Distributed Control Systems
ECSE Experimental Computer Science and Engineering
ETSI European Telecommunications Standards Insti-tute
EU European Union
FR Foundational Requirements
GSM Global System for Mobile Communication
HIPPA Health Insurance Portability and Accountability
HMI Human Machine Interface
IAAS Infrastructure as a Service
1
IACS Industrial Automation and Control Systems
IDS Industrial Data Space
IEC International Electrotechnical Commission
IoT Internet of Things
ICS Industrial Control Systems
ISO International Organization for Standardization
IT Information Technology
ISA International Society of Automation
MIP Measurable Indicator Points
MOI Measurable Organizational Points
MSCV Monitoring and Standard Compliance Verification
MSI Measurable Security Indicator
MSFI Measurable Safety Indicator
NIST National Institute of Standards and Technology
OCF Open Connectivity Foundation
OT Operational Technology
PaaS Platform as a Service
PLC Programmable Logic Controller
PS Product Supplier
RA Risk Assessment
RTU Remote Terminal Unit
2
SA Security Assurance
SaaS Software as a Service
SCADA Supervisory Control and Data Acquisition
SI System Integrator
SM Maintenance Service Provider
SPR Security Program Rating
SoA Service oriented Architecture
SoS System of Systems
SuC System under Consideration
TPM Trusted Platform Module
TR Technical Report
TS Technical Specification
3
4
Part I
1
2
Chapter 1
Introduction
”The only system which is truly secure is one which
is switched off and unplugged, locked in a titanium
safe, buried in a concrete bunker, and is surrounded
by nerve gas and very highly paid armed guards.
Even then, I wouldn’t stake my life on it”
Gene Spafford
1.1
Introduction
The technological progress is changing the way we live. Recent industrial production developments are revolutionizing our economy and society by preparing strong foundations
for efficiency, sustainability, and usability. As the digital transformation is on its rise,
today’s society relies more and more on connected services utilizing embedded sensors
and actuators. This creates new business opportunities, but the ability of traditional
systems (such as Operational Technology (OT) systems) to cope with new technologies
will be a significant factor to success in the business [1]. Even though many OT have
been initially set up in isolation, they are getting interconnected following digital transformation. Thus, it is critical to exploit technologies that can integrate and operate
with legacy systems. These technologies will facilitate the development of new systems.
Still, at the same time, they will maintain in operation legacy systems by increasing
their efficiency, real-time capabilities, and resource usage by interconnecting processes,
people, and technology [2]. Digitalisation affects not only the industry but organizations
across all domains. Several European research projects have been funded on this topic.
Productive 4.0 [3], ArrowheadTools [4], SemI40 [5], Ai4Di [6], CPS4EU [7], iDev40 [8],
and many others, address the topic of Industry 4.0 and automation enabling technologies
to transform the potentials of the digital revolution into business success [9]. The digital transformation facilitates the adaption of new technologies with new products and
services. Therefore, organizations have to decide if they should migrate into Industry
4.0 and which technologies are appropriate by considering initial costs and benefits on
3
4
Introduction
productivity. To support the digital transformation of industry, the implementation of
standards and compliance with their requirements is of utmost importance. This will ensure the compatibility and interoperability of products by endorsing digital technologies.
Interoperability is the guarantee that connected devices, systems, and services communicate with each other regardless of the manufacturer, location, operating system, or
hosted services [10], as shown in Figure 1.1.
Figure 1.1: Communication across several organisations providing interoperability between devices, systems, and services via a trust center and certificate authorities (CA)
Automation systems and service platforms play a significant role in digital transformation. They enable connectivity, monitoring, analysing and controlling of processes.
The digitalisation of industry is supported by emerging technologies such as Internet
of Things (IoT), Cyber-Physical Systems (CPS), Service Oriented Architectures (SoA),
Systems of Systems (SoS), and Cloud Computing, which are the main enablers for the digital transformation [11]. They enable interoperability, customized production, predictive
maintenance, develop new products or improve older ones (e.g., industrial manufacturers
use sensors to collect data about processes and analyse the collected data to improve the
quality of products, minimize errors and reduce time to market) [12]. A brief introduction of these technologies is provided here, and they are further discussed in chapter 2.
CPS provides full integration of Information Technology (IT) and control systems with
physical objects, software, sensors and connectivity to optimize manufacturing processes.
They provide advanced functionalities in control and communication for an infrastructure
that automatically handles different tasks in different locations [13], [14]. IoT provides
the connection and network capabilities that help integrate the physical world by collecting, processing, and analysing the gathered data by IoT devices. The data collected
1.1. Introduction
5
from the sensors are converted into digital payloads, which are sent over the network using communication protocols to cloud computing services (e.g., databases, maintenance
services, etc.) where they will be further processed and analysed [15].
SoS is a composition of independent systems configured to interact with one or several
systems, which provide capabilities that a single system cannot achieve [16], [17]. SoS can
operate in different regions or platforms and can have various applications or production
elements, as shown in Figure 1.2.
Figure 1.2: Schematic representation of SoS. Each component can operate in different
regions and consists of platforms, applications, or physical production elements
ISO/IEC/IEEE 21839 defines SoS as :
“System of Systems (SoS) - Set of systems or system elements that interact to
provide a unique capability that none of the constituent systems can accomplish on
its own. Note: Systems elements can be necessary to facilitate the interaction of
the constituent systems in the system of systems” [18].
“Constituent Systems - Constituent systems can be part of one or more SoS. Note:
Each constituent is a useful system by itself, having its own development, management goals and resources, but interacts within the SoS to provide the unique
capability of the SoS” [18].
Examples of SoS, either existing or proposed, can be found in diverse domains, such as
manufacturing, transportation, energy, healthcare, telecommunication, etc.
6
Introduction
Despite the benefits of adopting digital transformation technologies, many challenges
are still to be addressed. These challenges increase continuously due to a large number of
products, complexity, and ability to orchestrate processes in different platforms or even
regions. In such environments, assuring interoperability and establishing a secure and
robust communication is a vital element. Therefore, security is one of the main challenges
for such complex systems, which is more critical for systems that previously have been
isolated and highly protected, and now are exposed to the internet [10].
In cloud computing, it is essential not only to offer a user friendly access to the data
but also to assure that security techniques are in place in physical infrastructure (infrastructure level), virtual infrastructure (tenant level) and applications (service level). In
IoT, it is important to show that it is possible to support several application domains
and ecosystems while providing secure communication and secure storage [19]. The data
collected by sensors are mostly critical infrastructure data stored in the organisation’s
internal systems, meaning that several departments or roles can access them. Their security is essential because, without proper security measures, non-authorised access will
result in high costs and leaks in critical data. In SoS, it is essential to take into account
the security aspects not only to ensure business operations, but also managing security
objectives (e.g., confidentiality, availability, integrity, authenticity, non-repudiation, reliability, etc). If someone compromise any of these objectives, the consequences would be
from an incident to an unsafe situation or system performance degradation.
Recent studies and surveys show that many organisations need to address better
their security since the interconnection of devices, systems, and services through IoT
platforms increases the possibility of security being compromised [20], [21], [22], [23]. As
a consequence, cyberattacks on industrial environments have become more common and
even more sophisticated than they have been in the past. The Stuxnet (named the world’s
first digital weapon) was the first attack on OT systems. In difference from other attacks,
it targets supervisory control and data acquisition (SCADA) systems, more specifically
the programmable logic controller (PLC) used to control the centrifuges of Iran’s nuclear
facility in Natanz [23], [24]. After the report of Stuxnet attack in 2010, cybersecurity has
become a major concern for critical infrastructures. Since then, several vulnerabilities
have been identified and have demonstrated that critical infrastructure operate in an
unsecure environment. The Night Dragon, reported in 2010, used sophisticated malware
to attack global oil, gas, and petrochemical organisations [25]. In 2015, Ukraine Power
Grid attack was the first known attack on a country power grid, where attackers were
able to compromise information systems of energy distribution [26]. Also, in 2016 a
second attack compromised the Ukraine power grid again by cutting electricity to 225.000
customers. Triton/Trisis (named the wold’s most murderous malware) in 2017, targeted
the safety instrumented systems of an energy plant in the Middle East [27]. It was the
first time that a safety instrumented system was directly attacked with the objective
of disabling them. But fortunately, there was an error in the code that caused a safe
shutdown of the facility, and this was how they discovered the cyberattack.
The consequences of these attacks can vary from interruption or modification of an
operational process to sabotage with the intention to cause harm. They can lead to
1.1. Introduction
7
the financial impact, loss of brand loyalty, loss of reputation, espionage, environmental
damage, injury, or even loss of life depending on the attack’s severity. These attacks
could have been detected or even prevented if security techniques could have been in
place. ISA/IEC series proposes defense-in-depth, separation of physical and logical assets
in different zones, and other countermeasures [28] (more details in section 3.2).
To efficiently respond to these types of threats against critical infrastructure and
OT systems, and to benefit from digitalisation technologies, it is crucial that security
decisions are made based on international standards. It is not only important to securely
access the data, but also to securely exchange the data and make possible that only
authorised persons access them without reducing the security level. This avoids security
incidents by assuring that all security measures are in place. Measurable indicator points
(e.g., security metrics or security controls) from recognized standards can be used by
devices, systems and services to measure and if needed to improve security. There are
several national and international security standards that organizations can choose to
comply with, such as: (i) information security standards - COBIT, ITIL, ISO 27001 etc.,
(ii) cybersecurity standards - NIST SP 800-series, ISO/IEC 27000 family of standards,
ISA/IEC 62443 series, etc., (iii) web services security standards - OASIS, OWSM, etc.
Standards are agreed publications and can be implemented as a preferred way or as
mandatory requirements to comply with specific policies by providing rules or guidelines
including tests, methods, reference data, and analysis [23], [29]. They provide a common
language and agreements for individuals and organizations to avoid misunderstanding.
Complying with standards is important for communication, trade, and production since
they ensure compatibility and interoperability of products between multiple stakeholders.
Standards provide advantages to organizations and users by reducing costs, avoiding redundancy, minimizing errors, reducing time to market, and improving security. As they
usually are not mandatory (organizations are not legally constrained to fulfill them), they
facilitate compliance with other legal requirements such as those documented in European Directive [30]. With the development and adaption of new technologies, existing
standards need to be adapted or new ones need to be drafted and published.
Usually, an organisation needs to comply with more than one standard for specific
domains and products. Most of them are subject to at least one security regulation. An
organisation’s difficulty is to select a proper standard and provide evidence of compliance
with its requirements and security metrics. There are several challenges in selecting
and understanding standards because they are not written so that every person can
easily understand it. An experienced security professional is employed to implement the
standard to show if the organisation is compliant with it or not. Another challenge is
to automatically verify compliance since most of the standards do not provide technical
ways to implement the measurable indicator points.
This thesis provides an automatic way to continuously monitor standard compliance
verification for a transparent, efficient, and effective interoperable system of systems
based on international security standards and recommendations. This will guarantee the
parties that devices, systems, and services within the organisation operate in a secure
and standard compliant way without compromising the underlying infrastructure.
8
1.2
Introduction
Motivation
The industrial environment is experiencing a radical digital transformation relying on
innovative technologies that cannot work in isolation. Standards, recommendations and
best practices facilitate the ongoing digitalisation of industry by providing interoperability and liability across technologies, while providing means to assess security.
Standards are guidelines that provide specifications, reports, and best practices on
devices, systems, services, and processes. The development of a standard involves professionals with different backgrounds and roles, from normal users to public authorities.
The role of standard compliance can be easily illustrated in the telecommunication domain. The development of the Global System for Mobile Communication (GSM), first
deployed in 1983, showed a mobile phone’s ability to operate in different countries. After
the acceptance and publication by the European Telecommunications Standards Institute (ETSI), it was adopted by most EU countries, and the GSM network soon expanded
all over the world (193 countries in 2010) by achieving 90% of market share. Moreover,
standards regulate and impact competition by providing for every producer equal opportunities and market access. They also make it possible that all types of organizations
can access national and international markets and compete. An example is the Android
and iOS operating system, where developers published 1.1 million new iOS apps and 1.3
million new Android apps in 2016 [31]. In the context of digital transformation, there is
no boundary between the connection of objects, devices, people, and the environment.
Proprietary standards may provide advantages for single organizations within a specific
market, but they will limit their broader market opportunities. A wrong implementation
or interpretation of standards can limit interoperability and can also have a negative impact on users. International standards that are available for all industries provide generic
specifications (protocols, data format, interfaces, etc.) to ensure interoperability across
industries in different countries and push the usage of new technologies. Compliance with
these standards ensures that components and processes are operating in accordance with
well known and globally agreed set of norms and recommendations. Non-compliance
may not result only in financial impact, loss of reputation, and loss of brand loyalty, but
can also lead to legal actions and fines. If standard compliance is verified, it helps legal
cases to show that there was no negligence at any point in time, and the system has been
compliant to security standards.
The security standards involve many requirements and security controls (e.g., ISA/IEC
62443 series include different standard for system requirements and other for component
requirements). Achieving compliance with these standards can be complicated and costly,
based on the nature of the standard. Many organisations find it difficult to maintain standard compliance and are investing effort and resources in order to be compliant. Usually,
the compliance verification is done via manual audits maintaining several documents as
checklist [32]. The standards provide requirements listed in this checklist and verified
against the devices, systems, and services. Several works such as, [33], [34], and [35]
outline the issues with manual compliance audits, the ability to build the checklist, and
humans’ need to interpret them [23].
1.3. Research Questions
1.3
9
Research Questions
Considering the problem formulation and motivation presented in the previous section,
the following research questions are formulated:
Q1: What existing standards can be considered relevant to address security from
edge devices to the back-end infrastructure, including their communication and what
are the difficulties of implementing them?
Given the large number of existing standards, organisations have to comply with
different rules from different standardization bodies, and they find it challenging
to choose the right standards to comply with. The components in an end-to-end
communication from edge devices to the backend infrastructure should fulfill several standards to provide secured communication and interoperability. To identify
the best standards to comply with, security requirements of the system under consideration should be defined and documented in a structured way. Several security
standards should be evaluated and measurable security indicator points should be
extracted based on the system requirements. Therefore, standard compliance depends on whether the standards can provide technical implementation possibilities.
Q2: How can standard compliance be verified, and how can the requirements of an
already implemented solution be addressed in standard compliance?
In order to provide an automated approach to check standard compliance verification, the standards should be written in such a form that all the requirements,
metrics, controls or countermeasures should be technically implemented. Most of
them currently do not provide an implementation solution, and most of the metrics
can not be technically implemented. To have an automated standard compliance
verification, the standard requirements should be translated into technically measurable indicator points based on the collection of devices, systems, and services.
Q3: How to integrate standard compliance verification in a dynamic and evolving
system of systems (SoS) environment?
SoS has the ability to collaborate with different systems by providing new capabilities that the independent systems can not achieve. They have dynamic behaviour
and consist of systems that can be configured to join or leave the SoS without
interrupting the main process. The individual systems are operated from different
organisations under different security policies. If a single system does not provide
the required security level, the entire SoS can be vulnerable to security breaches.
These incompatibilities can be easily discovered if they provide evidence of compliance to security standards. Standard compliance of these systems should be verified
during design time, but this is not sufficient since SoS evolve over time and new
security requirements need to be addressed during operation time. Therefore, standard compliance should be continuously verified in different time frames or when a
new component is added/removed from the SoS.
10
1.4
Introduction
Research Methodology
The research methodology used in the thesis is Experimental Computer Science and
Engineering (ECSE) defined as “the building of, or the experimentation with or on, nontrivial hardware or software systems” [36], considering properties such as complexity of
artifacts, technology dependence, universality and the non-reliance on theory [37].
The first step is to formulate the research questions to define the research area. Based
on the research questions and the research area, an investigation of state of the art should
be conducted, including literature review, scientific publications, projects, presentations,
etc., with the scope to distinguish and extend previous works. After a comprehensive
state of the art investigation, the hypothesis is formulated. The hypothesis’s scope is to
clarify and focus on the research problem defined by the research questions. It should be
simple, specific, related to existing knowledge, and measurable.
The next step is to plan a structured way to conduct experiments by designing approaches to test the hypothesis. The experimental plan should include the experiment’s
goal, measurable variables, how to gather, present the results, and make them repeatable.
Identifying possible techniques to develop the solution is performed through a series of
experiments, prototypes, and evaluations. The results are collected and analysed if they
support the hypothesis. The result achieved during the experiments are presented to domain experts and other researchers during scientific meetings, reviewed by the scientific
community, and published in scientific papers and articles.
The methodology and the prototype are applied in different use cases considering several levels of complexity in order to demonstrate that the results support the hypothesis
even if implemented in different scenarios and they are repeatable.
1.5
Thesis Scope and Outline
Digitalisation and SoS are broad areas of research, and they have a significant interest
in standard compliance to achieve interoperability and secure communication. These
systems demand deep knowledge in other domains, technologies, and topics such as IoT
platforms, modelling, secure communication protocols, end-to-end communication, cloud
computing, legacy devices, IoT devices, standards, regulations, best practice guidelines,
etc. Experiments in different testbeds with different technologies are necessary to produce
results that can better understand the importance and need for standard compliance
verification of these systems. This thesis’s work was performed in close collaboration
with other researchers, industrial partners, and experts in several domains.
The research work presented in the thesis shows the benefits and challenges of automated and continuous standard compliance verification in SoS. In this thesis are evaluated
several aspects of the digital transformation by investigating secure communication protocols (Paper C and D), reference architectures to show the dependability of connected
components in a dynamic environment (Paper C), different monitoring tools and frameworks (Paper A and I), and cloud computing technologies (Paper B and E). Overall
trustworthiness of SoS can be achieved by proofing that the components are compliant
1.5. Thesis Scope and Outline
11
to standards, and they communicate and operate based on the requirements and controls
documented in these regulations [23]. Compliance proves the fulfillment of regulations
by including all measures imposed by standards. Every device, application, or service
implements several technologies at many levels, and standards support interoperability
across them [23]. Thus, several standards that address security are investigated (Paper
C, G, H, I, and J). Based on the investigation, measurable indicator points (MIP) are
extracted and documented in a metric model. The metric model’s objective is to provide
a common understanding and show the relation between standards, requirements, and
MIPs. The MIPs are used as input for the Monitoring and Standard Compliance Verification (MSCV) framework, which aims to show and verify if a specific component or use
case is compliant to one/several standards based on the MIPs [23]. The MSCV within
this thesis is used to verify the continuous standard compliance of security standards, but
it has a generic architecture and can be used to show the standard compliance verification of other aspects. This research has the scope to enhance trustworthiness and provide
interoperability by proofing that the components involved in a SoS operate in a standard
compliant manner during design and run time, without compromising the underlying
infrastructure. The relevant research areas that are not within the scope of this thesis
are: providing security solutions, risk assessment, security levels, safety aspects, safety
standards, legal aspects, legal standards, organizational aspects, process management
standards, communication protocols development, big data analysis, semantics related
activities and hardware (sensors, actuators, IoT devices, etc.) technologies.
This compilation thesis consists of two parts. Part I introduces the research area,
formulates the research questions, and provides the thesis’s motivation, research methodology, and scope. Part II consists of ten appended papers containing the core research
contribution of the thesis. They have been reformatted for the layout of the thesis but
without any modification of the content. The appended papers have been published,
accepted or submitted for publication in peer-reviewed conferences or journals.
Part I is divided into six chapters. Chapter 2 provides an overview of the current challenges of digital transformation. It further describes the digitalisation related technologies
such as IoT, CPS, SoS and cloud computing. Additionally, the differences between IT
and OT and the security of legacy systems are presented. Chapter 3 addresses the current standardization landscape and provides an overview of standardisation bodies and
standards. It focuses on the importance of standards in everyday life and shows different
standards, standard structure, and how to read a standard and their lifecycle. It further
provides an introduction of ISA/IEC 62443 series and in particular, describes in more
detail the IEC 62443-3-3: Systems security requirements and security levels. Chapter
4 addresses the monitoring and standard compliance verification, and the evaluation of
security standards is presented, including an example that shows how measurable indicator points are extracted from the standards and documented. Further, the Monitoring
and Standard Compliance Verification (MSCV) framework and its application in two
different use cases to show its applicability is presented. Chapter 5 summarizes the appended papers, including additional publications and the research contribution of the
thesis. Chapter 6 presents the thesis conclusions and shows directions for future work.
12
Introduction
Chapter 2
Security: The challenge for
Digitalisation
The main goal of security in an industrial environment is to protect essential functions,
even if malicious attackers threaten them. Modification or non-authorised access of data
and running processes in these systems may force interruption of operational processes,
malfunction, sensitive information loss, or sabotage to cause harm. This chapter provides
the related technologies of digital transformation in more detail, including IoT, CPS,
SoA, SoS, and cloud computing technologies. Also, the difference between Information
Technology (IT) and Operational Technology (OT) is shown, because when dealing with
an industrial system it is important to know their differences in terms of security.
2.1
Standards and Digitalisation
Industry 4.0 connects people, technologies, processes, and flow of goods along the value
chain. This requires an overall security architecture considering all component and participants. Security should be assured during the whole lifecycle (from specification until
decommissioning). The digital transformation can be effective if all involved parties can
trust the security of their data, as well as the protection of their industrial property.
As defined in NIST SP 800-152, trust is “a characteristic of an entity that indicates its
ability to perform certain functions or services correctly, fairly and impartially, along
with assurance that the entity and its identifier are genuine” [38]. ISA/IEC 62443 series
defines trust as “confidence that an operation, data transaction source, network or software process can be relied upon to behave as expected”, note 1 to entry: an entity can be
said to “trust” a second entity when it (the first entity) makes the assumption that the
second entity will behave as the first entity expects [39], [40]. Digital trust should be an
essential part of the digital transformation since it will enable decisions to be made between the organisations that want to interact with each other. These decisions are based
on the organizations security levels provided by each entity via standards and guidelines.
International standards help organisations to connect services outside their proprietary
13
14
Chapter II
systems towards system interoperability. Therefore, governments, industry and science
have the responsibility to establish security guidelines to trust the new technologies. This
can be guaranteed by standards and the development of secure solutions specific to digitalisation. For this to be possible, security experts from different industrial domains
are involved in preparing regulations for new and existing services in order to establish
standardized rules to guarantee secure and digital business models.
2.2
Digitalisation and Security
The development of new technologies is leading to new security threats. Cyberattacks
are continuously trying to find new vulnerabilities of systems and technologies with the
scope to destroy, steal, or gain unauthorized access to industrial assets. These attacks
are improving and getting more sophisticated against OT systems due to insufficient
computing resources for additional security capabilities. Creating and maintaining an
overall security model to include all components involved in these complex systems is
becoming more difficult. Due to the number of components involving different legacy and
IoT devices, platforms, and processes, security will always remain a moving target. With
the digitalisation, these components are introducing new vulnerabilities because they are
not designed to provide security or take into consideration other life cycle dependencies.
Most of the security countermeasures today focus on network security. Industries use
principles such as defense-in-depth, which is a layered security mechanism with the scope
to provide security in different layers, and if one of these layers is compromised, the next
layer will provide other security countermeasures [39]. Also, secure elements (to provide
hardware security as a root of trust), CCTV, locks, keys, fences, and other physical
security measures are used to assure the devices and systems’ integrity. It is crucial to
have a separation in different zones of physical and logical assets sharing the same security
requirements, and these zones should have boundary protection and a good hardening
of the devices. Another security principal used in the industrial environment is the least
privileged, where users and accounts should have as few privileges as possible [41].
2.2.1
Differences between IT and OT systems
Information Technology (IT) and Operational Technology (OT) systems have different
security perspectives, and it is important to know them when dealing with industrial
systems. A major difference is that OT is the technology interacting with the physical
world, focusing on automation of machines, process assets, and safety systems; and IT
systems focus on business operations and enterprise systems that store and manage data.
Other differences are in terms of performance, availability, risk management, operating system, resources, communication protocols, and lifetime as shown in Table 2.1.
OT systems are designed to be offline and stand-alone solutions. Examples of OT
include Supervisory Control and Data Acquisition (SCADA), Distributed Control Systems (DCS), Programmable Logic Controller (PLC), Human Machine Interface (HMI),
Remote Terminal Unit (RTU), etc., as part of Industrial Control Systems (ICS) [42].
15
2.2. Digitalisation and Security
Requirements
•
•
•
•
•
•
•
•
IT
Non real time
Response consistent
Rebooting acceptable
Outages tolerated
Confidentiality and integrity primary
Fault tolerance not very important
Typical operating systems
Possible to upgrade if available
Resources
•
•
Enough memory and storage
Computing resources can be added
Communication
Lifecycle
•
•
Several communication protocols
Three to five years
Performance
Availability
Risk Management
Operating system
•
•
•
•
•
•
•
•
•
•
•
•
•
•
OT
Real time
Response time critical
Rebooting non-acceptable
Outages must be planned in advance
Human safety and processes primary
Fault tolerance is essential
Proprietary operating systems
Upgrades only from the vendor support
Resource constrained
Used only for a specific process
Not possible to integrate third party solutions
May not possible to add computing resources
Proprietary communication protocols
Ten to fifteen years
Table 2.1: IT systems and OT systems differences
They are implemented in several industries, such as transportation, oil, and gas, energy,
buildings, and healthcare, to mention a few.
These industrial environments are controlled and monitored via several IoT devices
and use IT technologies, which provide real-time status of the OT devices and make it
possible to respond in time for any malfunction. The digitalisation technologies make
possible the cooperation of IT and OT by providing more efficiency and interoperability.
One of the most significant advantages of IT and OT convergence is the decision making
based on real-time data of devices and systems.
The biggest challenge of this convergence is security. The connection of OT will introduce new security vulnerabilities, and IT/OT have different security needs. OT has
traditionally used proprietary technologies and only a few connections to other systems,
making them less likely to be attacked. On the other hand, IT systems have enough resources to integrate security solutions and have a higher risk acceptance level. To benefit
from IT and OT systems’ advantages, security standards can be used to adequately secure and protect these systems. Chapter 3 introduces ISA/IEC 62443 series, and security
measures such as defense in depth and zone models are presented.
2.2.2
Security in Legacy Systems
Legacy systems are based on proprietary technologies (operating systems, communication
protocols), but they are critical for day-to-day operations [43], [44]. A number of these
technologies are still used today. An example is the pager (also known as beeper), which
is developed in 1960 and became very popular in 1980, especially in the health industry
and other emergency services [45]. A recent review in hospitals found that the most used
technology is the pager instead of secure mobile communication [46]. There are several
reasons for still using this technology, e.g., in natural disasters, pagers do not rely on the
phone transmitters but communicate via high frequency radio signals and do not count
on the nearest tower. Other reasons are battery life and security since they transmit only
text and digits, and it is not possible to send files or critical data. Nevertheless, they
have their disadvantages (e.g., no reply is possible), and many hospitals want to move
16
Chapter II
towards secure text messaging applications compliant with HIPPA [47], but this is very
expensive for the health industry. Other examples of such legacy systems can be found
in other domains used for specific functions.
Industry 4.0 is based on the use of new technologies with computational and communication capabilities. Using these technologies out of the box instead of legacy systems
is not economically feasible for most scenarios because organizations will need to build
entire industrial fabs from scratch. Replacing legacy systems with new technologies is not
an easy task. Planning, designing, implementing, and validating a new application needs
expertise and time; usually, their design and development team is no longer available
or does not support the system anymore. At the same time, the existing legacy system
should be maintained. Instead, a transition phase is possible by incorporating legacy
devices and systems to cope with digital technologies. Several studies have investigated
the engineering effort and costs needed to implement new architectures and approaches
without replacing the legacy systems [48], [49], [50], and [51]. As a result, replacing these
systems requires a significant amount of work and resources. With the use of technologies
such as IoT, CPS, SoS, and cloud computing it is possible to communicate with legacy
systems and devices by providing a digital representation of the physical world.
As mentioned in the previous sections, the industrial environment consists of several
devices, systems, and services where a single solution is not feasible in terms of security. In
general, industrial devices need further security protection by extending existing concepts
like CIA (confidentiality, integrity, and availability), usually restricted to IT systems’
protection. For legacy devices, objectives unique to production environments should be
fulfilled, such as human safety, equipment, and process protection.
These systems should fulfill other objectives such as authenticity (the property that
an entity is what it claims to be) [52], accountability (the property ensuring that the
actions of a system can be traced) [53] and non-repudiation (the property that an entity
can be claimed responsible for its actions by proofing the origin) [54]. Therefore, legacy
devices need to be secured, and their communication encrypted [55].
In principle, the data could be encrypted by simply using available security APIs.
Unfortunately, software-based encryption is prone to attacks that reveal the used encryption key. A dedicated hardware module often referred to as secure element, should
be integrated into the industrial devices and ideally into all devices involved in the critical
communication flow to overcome this issue [55]. Secure elements provide tamper-resistant
storage holding cryptographic keys. This storage is designed to protect the key from any
kind of attack, even physical access to the device. Secure elements can also perform signing, encryption, or decryption, and check the validity of signatures. In general, a Trusted
Platform Module (TPM) hardware is a particular variant of a secure element with a
standardized feature set for integration into various computing platforms [56], [9]. TPMs
can be used to identify a device and check the device’s software on startup to ensure that
the operating system and programs are not manipulated. It uses a non-volatile memory
able to securely store cryptographic material. This material can be used to encrypt or
sign data to ensure integrity, confidentiality, authenticity, and non-repudiation [9].
2.3. Digitalisation Related Technologies
2.3
2.3.1
17
Digitalisation Related Technologies
Internet of Things
As defined by ISO/IEC JTC 1, the Internet of Things (IoT) is “an infrastructure of
interconnected objects, people, systems and information resources together with intelligent services to allow them to process information of the physical and the virtual world
and react” [57]. Thus, IoT is a platform used to connect heterogeneous and distributed
things embedded with electronics, software, and sensors to the internet, enabling them
to collect and exchange vast amounts of data. These data are then analyzed to build
business intelligence and new business models to improve user experience. There is no
standardised architecture for IoT that is agreed universally because different users have
different requirements. However, a basic architecture includes: (i) the perception layer,
where sensors are used to sense and gather information from the environment, (ii) the
network layer, which is responsible for connecting things and for transmitting and processing sensor data, and (iii) the application layer, which is responsible for delivering
application specific services to the users [55]. IoT utilizes the available resources efficiently, reduces human intervention, and saves time. Applications of IoT can be found
in our everyday life, such as healthcare, smart cities, agriculture, industrial automation,
etc. IoT applied to industrial production systems is knows as Industrial IoT (IIoT).
2.3.2
Cyber-Physical Systems
Cyber-Physical Systems (CPS) integrate information processing (communication, computation, and control) with physical processes. Information processing is performed
using embedded systems, which provide fundamental technologies, e.g., A/D converters,
sensors, actuators, control systems, and robots, to ensure real-time and dependability.
Embedded systems monitor and control physical processes, usually with feedback loops,
where physical processes affect computations and vice versa [58] [59]. Thus, a CPS is an
entire system containing the embedded systems and the physical environment. CPS must
be dependable because everything happening in the information processing part will impact the physical environment. Making CPS dependable should be considered from the
very beginning by addressing reliability, maintainability, availability, safety, and security.
CPS must meet real-time constraints. Thus they must respond to external changes within
the time interval directed by the environment. CPS are reactive and dynamic systems,
thus they adapt to rapid changes in the environment and system itself, and they meet a
number of agreed requirements. CPS are dedicated to a specific application. CPS application areas include communication, energy, infrastructure, health care, manufacturing,
military, robotics, transportation, etc. CPS applied to industrial production systems are
known as Cyber-Physical Production Systems (CPPS) [55].
18
2.3.3
Chapter II
System of Systems
The technologies mentioned above, CPS, IoT, and cloud computing, allow for creating
an integrated and self-regulating SoS. SoS are large-scale integrated systems that are
independently operable on their own but are networked together for a period of time to
achieve a higher goal, e.g., costs, performance, robustness, etc [16]. They are distributed
systems composed of several components. SoS architecture examples are applied in public
transportation [60], health care systems [61], cloud services [62], etc. They have several
characteristics that distinguish them from traditional systems, such as: (i) operational independence, (ii) managerial independence, (iii) evolutionary development, (iv) emergent
behaviour, (v) geographic distribution and other characteristics including autonomy, belonging, connectivity, diversity and emergence [63]. These characteristics should be taken
into consideration when designing an SoS. Since these systems evolve during the time,
security is a major challenge since a SoS can integrate systems with different security
requirements where systems with a low security level can compromise systems requiring
a high level of security. To enable interoperability between systems in SoS and provide
evidence that they fulfill the security requirements to share information, security standard compliance should be verified. Considering the nature of SoS, standard compliance
should be verified during the entire lifecycle.
Figure 2.1, shows the lifecycle processes from ISA/IEC 62443 series, based on the
IEC 24748 lifecycle [64] with the difference that the production phase is divided into
implementation and verification and validation phase. It is important to know what
are the implications of each phase in order to be able to address standard compliance
verification in run time [65].
Figure 2.1: System life cycle phases and their interactions
The lifecycle phases are described in more detail in section 3.2.6. The following are
explained the security requirements that each phase should accomplish to maintain a
desired security level through the entire lifecycle.
Specification: determines the desired level of security that the system should achieve.
Design: defines the technical measures and metrics to achieve the desired security level.
Implementation: tests the technical security measures applied to the system.
Verification and validation: verifies and validates the security measures.
Operation: assures that the security measures are performed effectively.
Maintenance: update the security measures to achieve the desired security level.
2.3. Digitalisation Related Technologies
19
Decommissioning: disposes the system by maintaining the desired security level.
Based on the lifecycle phases, the system should show that it has the desired security
level by proofing that the security requirements are fulfilled during the entire lifecycle.
2.3.4
Cloud Computing
As defined by NIST SP 800-145, cloud computing is “a model for enabling ubiquitous,
convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly
provisioned and released with minimal management effort or service provider interaction” [66]. Thus, cloud computing offers the possibility to store data/applications on
remote servers, process data/applications from servers, and access data/applications via
the Internet. Cloud providers offer three different service models: (i) Software as a Service (SaaS), cloud users can consume a software that is handled by cloud providers e.g.,
Salesforce provides the CRM (Customer Relation Manager) on a cloud infrastructure to
its users and charges them for it, (ii) Platform as a Service (PaaS), cloud providers give
the ability to the users to deploy user created applications using programming languages,
tools, etc. that are provided by the cloud provider, but the users have no control over the
underlying architecture, e.g., OS, storage, servers, etc., (iii) Infrastructure as a Service
(IaaS), the cloud provides the entire infrastructure to the users to create their own applications. Also, there are three different cloud deployment models: (i) public cloud, which
makes the resources available to the general public over the Internet, e.g., pay for what
you use, (ii) private cloud, which offers services to a limited number of users, e.g., firewall
is used to reduce security concerns, and (iii) hybrid cloud, which uses a combination of
on-premises, private and public cloud services to help leverage the best of both worlds.
2.3.5
Architectures and platforms
To show the Monitoring and Standard Compliance Verification (MSCV) functionality,
several existing architectures, frameworks, and IoT platforms based on scientific publications, white papers, and technical articles are evaluated and documented in the appended papers. The evaluation highlights the need for an automated and continuous
standard compliance verification solution. Some well-known frameworks for IoT are
Eclipse Arrowhead Framework, Automotive Open System Architecture (AUTOSAR),
BaSys, FIWARE, Industrial Data Space (IDS), Open Connectivity Foundation (OCF),
and IoTivity [67]. Also, well-known cloud platforms are Amazon Web Services (AWS),
Microsoft Azure, Google Cloud Platform, IBM Cloud, OpenStack, VMware, etc.
Following is presented in more detail the Eclipse Arrowhead framework where is
implemented the MSCV as a service, and the OpenStack cloud platform used to build
several use cases and show the functionality of the MSCV [23].
20
Chapter II
Eclipse Arrowhead framework
The Eclipse Arrowhead framework is an IoT based automation solution, using the SoA
principles to create local automation clouds. The framework’s objective is to provide
interoperability, real-time performance, scalability, and secure communication through
multi-cloud interaction [10], [67]. The architecture is built based on the SoA fundamentals
such as (i) loose coupling, the property that makes possible to implement services in
several devices and they are not supervised services, (ii) late binding, the property of
connecting to the known resource at a specific time, and (iii) lookup, the property that
makes possible to publish, register and lookup existing services [9].
“The architecture addresses the move from large monolithic organisations towards
multi-stakeholder cooperations, thus addressing the high level requirements in today’s society, such as sustainability, flexibility, efficiency, and competitiveness” [10]. In order
to be able to develop Eclipse Arrowhead compliant devices, systems, and services, it is
important to know their definition based on the Eclipse Arrowhead framework:
Device is a piece of hardware equipment with computational and communication capabilities. The device can dynamically host one or several systems, including their services.
All Arrowhead compliant devices should be registered within the DeviceRegistry [9].
System is the software system that is hosting and/or consuming one or multiple services.
An Arrowhead compliant system can be the provider/consumer of one or several servicesA
at the same time. All systems should be registered within the SystemRegistry [9].
Service is the information exchanged with a providing system to a consuming system.
It is produced by a system, can have metadata and should support functional and nonfunctional requirements. All services should be registered within the ServiceRegistry [10].
Local cloud is a self-contained network containing at least the three mandatory core
systems and at least one application system deployed [10].
The Eclipse Arrowhead architecture is composed from a number of systems classified
in mandatory core systems, automation support core systems and application systems [9],
as shown in Figure 2.2. The mandatory core systems are:
ServiceRegistry system, color coded in blue, provides the database of all running and
registered services within the Eclipse Arrowhead local cloud. This system makes possible
to register, unregister and lookup a service in the ServiceRegistry.
Authorisation system, color coded in red, provides authentication, authorisation and
optionally accountability. It defines and provides the rules for consumption of services.
Based on these rules a specific device, system or service is allowed or not to consume
other services registered within the local cloud.
Orchestrator system, color coded in green, provides the necessary mechanisms for
distributing orchestration rules and endpoints to dynamically allow the consumption of
existing services and systems to create new functionalities [9].
The automation support core systems, such as SystemRegistry, DeviceRegistry,
PlantDescription [68], EventHandler [69] etc., are used to facilitate automation application design, engineering and operation [9]. They are used to provide support for automation, security, interoperability and many other features of the local cloud.
The application systems are the systems aiming to consume the registered services
2.3. Digitalisation Related Technologies
21
Figure 2.2: Eclipse Arrowhead framework architecture, where a service is what used to
exchange information from a providing system to a consuming system
in the ServiceRegistry or providing new services for the local cloud. In order to build an
Eclipse Arrowhead compliant local cloud it is mandatory to consume at least the three
mandatory core systems and at least consuming or producing one application system.
The Eclipse Arrowhead framework is used to develop the MSCV during secure onboarding
and run time of devices, systems, and services within the local cloud [9].
OpenStack Cloud Platform
OpenStack is an open-source cloud computing platform providing an IaaS and used to
deploy scalable public and private clouds with the objective of controlling large resources
of computing, storage, and networking. Rackspace and Nasa first launched it in July
2010, and it has more than twenty releases. The architecture contains a number of
components providing APIs to access the resources.
Each service in OpenStack has a unique code name, some important services are:
• Keystone is the identity service, which provides authentication and authorisation
of the services and their API endpoints.
• Glance is the image service, where it is possible to register, unregister, and lookup
virtual machine images.
• Nova is the network service, which manage all the networking within OpenStack.
• Horizon is the web based user interface of OpenStack .
• Cinder is the block storage service, used to create, attach, and deattach block
devices to servers.
OpenStack offers a number of features for the cloud environment, but in order to have
it running, at least Keystone, Glance, Nova, and Horizon should be installed. The main
22
Chapter II
characteristics of Openstack are (i) scalability, gives the possibility to deploy massively
scalable machines, (ii) compatibility and flexibility, supports most of the virtualization
solutions, and (iii) open, the source code can be modified based on the needs.
An OpenStack cloud testbed is used to develop and test IIoT use case monitored by
the MSCV for standard compliance verification in different time intervals.
Chapter 3 introduces standards and standardisation bodies and, in more detail the
ISA/IEC 62443 series that address security for such architectures and platforms necessary
for the secure implementation of Industrial Automation and Control Systems (IACS).
Chapter 3
Standardization Landscape
The role of standards is well recognized as one of the key enablers towards digitalisation and automation. Several working groups from several standardization bodies are
contributing towards the automation of industrial systems. They address the requirements in a broad spectrum of solutions for several domains such as railway, telecommunication, healthcare, production, energy, etc. This chapter introduces the world of
standards, standardization bodies, and standards in specific domains. It is shown why
standards are necessary, and how they are categorized, how to read a standard, and their
lifecycle. Also, it provides a representative list of security standards evaluated in several
aspects to understand how they can be used to check standard compliance verification in
an automated manner. It is also presented an overview of principals and fundamentals
of ISA/IEC 62443 series and a detailed description of IEC 62443-3-3.
3.1
Standardization Bodies and Standards
A standardization body is an organization responsible for gathering together all the experts and stakeholders (for specific standards also other interested groups) who will draft,
approve, vote, and publish the standard. Also, they are responsible for updating, revise,
and distribute the standard. The industrial community has a large number of standards
and standardization bodies. Below are listed several organizations that aim to publish
standards in numerous application areas [70], also shown in Figure 3.1. To show the importance of standard compliance, it is important to know from which groups of interest
they are drafted and published [23].
In Europe there are three well known standardization bodies:
• CEN (European Committee for Standardization)
• CENELEC (Comité Européen de Normalisation Electro-technique)
• ETSI (European Telecommunications Standards Institute)
23
24
Chapter III
Figure 3.1: Standardization bodies
Other international standardization bodies:
• ISO (International Standards Organisation)
• IEC (International Electro-technical Commission)
• IEEE-SA (Institute of Electrical and Electronics Engineers Standard Association)
• OMG (Object Management Group)
• ISA (Instrument Society of America)
• OSGi Alliance
• OASIS (Organization for Advancement of Structures Information Standards)
• ASI (Accellera Systems Initiative)
Paper I provides more information for each standardization body, their expertise and the
number of standards published.
3.1.1
Standards and their importance
“The primary objective of standardization is the definition of voluntary technical or quality specifications with which current or future products, production processes or services
may comply. Standardization can cover various issues, such as standardization of different grades or sizes of a particular product or technical specifications in product or services
markets where compatibility and interoperability with other products or systems are essential” [71]. A standard is a report used to set requirements and definitions for a specific
component, system, or service approved by a recognized evaluation authority [23].
3.1. Standardization Bodies and Standards
25
Standards support society’s everyday life much more than people think by making life
safe, simple, comfortable, and efficient (e.g., building where we live are constructed based
on construction standards, electrical equipment we use are based on specific standards,
etc.). They make sure that products and services are safe and reliable, and they can
interconnect for a better experience. There is not a single day that we are not in contact
with standards. To understand the number of standards we use in our everyday life, in
Figure 3.2 are shown some of the most important standards used by the smartphone.
Figure 3.2: Standards involved when using a smartphone
Standards have existed since the beginning of recorded history by recognizing the
importance of standardized measurements such as weight, distance, and length (e.g.,
King Henry I of England standardized the ell as a measurement in 1120 AD equivalent
to the length of his arm) [72]. Engineering Standards Committee developed the first
official standards established in 1901 as the world’s first national standardization body.
3.1.2
Types of standards
There are several different types of standards and more than 35 000 different CEN,
CENELEC, ISO, and IEC standards, and more than 10 000 national standards. Some
of the standards cover requirements and cover subjects for a specific product, service, or
process. Other types of standards consider testing methods, terminology, and definitions,
or compatibility of connections. One way to categorize them is by requirements such as
(i) dimension, (ii) performance, (iii) testing methods, (iv) management systems, (v)
symbols, (vi) terminology, etc.
26
Chapter III
Another categorization is based on the development process:
• De Jure standards are formal standards endorsed by a formal international standard development organization such as ISO, IEC, CEN, CENELEC, ETSI, etc., or
national and endorse standards through official procedures and approve them.
• De Facto standards are not developed by the standard development organizations
but are adopted by a specific industry or accepted by public acceptance. Microsoft,
MP3 audio format, HTML, etc., are several well known de facto standards.
Several standards can be developed as de facto standards and be approved as de jure
standards. An example is the pdf, which started as a de facto and was approved by ISO
3200 as de jure standard.
3.1.3
Standard life cycle
Standards are developed in several technical committees, and their working groups and
their members contribute to standardization to address their interests (usually from specific communities, organizations, or stakeholders). The membership and participation
are open for everyone, is voluntary work, and members can have different roles (participating, contributing, or observing). Publishing a standard goes through different steps
from draft to publishing and implementation, as shown in Figure 3.3.
Figure 3.3: Standard development stages
These steps can have minor differences in different standardization bodies.
3.1.4
Standard structure
The de jure standards are all structured in the same format to make it easier to provide
and overview and find specific information within the standard. A typical standard
structure [73] is shown in Table 3.1. If the reader is familiar with this structure, it is
easier to understand the scope of the standard and use it without spending time reading
non-relevant parts or sections [42].
The title page contains the title and number of the document. The table of contents
includes lists clauses and annexes, bibliography, summary, figures, and tables. The foreword gives information about the committee included in preparing the document and
3.1. Standardization Bodies and Standards
27
Table 3.1: Standard structure
Standard Elements
Preliminary informative
General normative
Technical normative
Supplementary informative
Elements in the document
Title page
Table of contents
Foreword
Introduction
Title
Scope
Normative references
Terms, acronyms, and conventions
Abbreviated terms and acronyms
Informative annex
Bibliography
information regarding approval of the document. The introduction provides the content
of the document and the goal for the preparation and some background information.
The scope provides the subject and what are the covered aspects. Normative references
give the list of referenced documents for the preparation. Terms and definitions give
the necessary definitions to understand and read the document. Abbreviated terms and
acronyms are the lists of abbreviations used through the document.
Figure 3.4: Standard number and title
Figure 3.4 shows how to understand a standard based on its number and name.
28
3.2
Chapter III
ISA/IEC 62443 series overview
There are two standardization bodies involved in developing ISA/IEC 62443 series:
(i) International Society of Automation (ISA)
(ii) International Electrotechnical Commission (IEC)
The ISA/IEC 62443 is a series of standards, including technical specifications (TS) and
technical reports (TR) organized in four groups, as shown in Figure 3.5. Each group
includes several standards and addresses specific aspects and topics necessary for the
secure implementation of Industrial Automation Control Systems (IACS). The ISA/IEC
62443 series and their development are originated from ISA, which organizes different
working groups in charge of different parts of the standard. IEC adopts the standards,
contributes to the standard, votes, and publish the standard. The purpose of ISA/IEC
62443 series is to improve and provide guidance for implementing secure Industrial Automation and Control System (IACS) with the scope to reduce the risk of compromising
information or causing failure of components (hardware or software) of systems under
consideration (SuC) [74]. The intended audience of the series: (i) Asset Owners (AO),
(ii) Product Suppliers (PS), (iii) Integration Service Providers (SI), and (iv) Maintenance
Service Providers (SM). Several ISA/IEC 62443 standards have already been published.
Others are still under development, reviewed, or planned (standards in gray are under
development or review) [28].
Figure 3.5: ISA/IEC 62443 series (October 2020)
3.2. ISA/IEC 62443 series overview
3.2.1
29
ISA/IEC 62443 group - General
This group focuses on terminology, references, metrics and models with the scope to
establish a baseline of fundamentals and general concepts that are used through the
entire series. The standards included in this group are shown in Figure 3.6.
Figure 3.6: ISA/IEC 62443 General
• Part 1-1: Terminology, concepts, and models introduces concepts and models that
are described and applied in more details in subsequent standards in the ISA/IEC
62443 series. It includes general security elements unique to IACS [39].
• Part 1-2: Master glossary of terms and definitions defines terms and abbreviations
used through the ISA/IEC 62443 series. When possible these definitions are taken
from available sources such as ISO standards [40].
• Part 1-3: System security conformance metrics is a process based standard to specify ISA/IEC 62443 system security conformance metrics for managing a security
program throughout the lifecycle of IACS.
• Part 1-4: IACS security lifecycle and use cases provides a more detailed description of the underlying lifecycle for IACS security, as well as several use cases that
illustrate various applications [75].
3.2.2
ISA/IEC 62443 Group - Policies and Procedures
This group focuses on the necessary policies and procedures including patch management
and security requirements needed for the creation of an effective IACS security program.
The standards included in this group are shown in Figure 3.7.
Figure 3.7: ISA/IEC 62443 Policies and Procedures
30
Chapter III
• Part 2-1: Establishing an IACS security program defines the requirements and
provides guidance to develop an IACS security program. This document uses the
definitions and scope of IACS as described in part 1-1 [76].
• Part 2-2: IACS protection levels describes security program rating (SPR) and
provides guidance on how to assess this rating. It addresses the cybersecurity
evaluation of IACS from a holistic protection scheme.
• Part 2-3: Patch management in the IACS environment provides guidance on patch
management for IACS. Specifies requirements for AO, SI, and SM that have established and are now maintaining an IACS patch management program [77].
• Part 2-4: Security program requirements for IACS service specifies a set of requirements for security capabilities for IACS service providers (SI, SM) that they can
offer to the AO during integration and maintenance activities [78], [75].
• Part 2-5: Implementation guidance for IACS asset owners provides guidance on
what is required to operate an effective IACS cybersecurity program [75].
3.2.3
ISA/IEC 62443 Group - System
This group focuses on cybersecurity technologies addressing available technologies, risk
assessment, security levels and design methodologies of IACS. The standards included in
this group are shown in Figure 3.8.
Figure 3.8: ISA/IEC 62443 System
• Part 3-1: Security technologies for IACS provides a survey of various tools and
technologies for cybersecurity that are applied to electronically based IACS used
to control and monitor different industries [79].
• Part 3-2: Security risk assessment for system design provides requirements and recommendations for (i) defining a system under consideration (SuC), (ii) partitioning
the SuC into zones and conduits, (iii) assessing risk, (iv) establishing security levels
and (v) documenting the security requirements [80] [75].
• Part 3-3: System security requirements and security levels provides detailed technical control system requirements (SRs) associated with the seven foundational
3.2. ISA/IEC 62443 series overview
31
requirements (FRs) described in part 1-1 and assigns security levels for the defined
zones and conduits in part 3-2 [81] [75].
3.2.4
ISA/IEC 62443 Group - Component
This group focuses on the secure development of components, including detailed technical
requirements and lifecycle requirements to establish a secure development lifecycle for
IACS components. The standards included in this group are shown in Figure 3.9.
Figure 3.9: ISA/IEC 62443 Component
• Part 4-1: Product security development life cycle requirements specifies process
requirements for the secure development of products used in IACS. Also it defines
a secure development life cycle for developing and maintaining secure products [82].
• Part 4-2: Technical security requirement for IACS components provides detailed
technical control component requirements (CRs) associated with seven foundational requirements described in part 1-1 and also assigns component security levels [83] [75].
3.2.5
ISA/IEC 62443 general principles
There are several general principles that are important for IACS cybersecurity. The
following general principles are applicable to all ISA/IEC 62443 series:
• Security Context
• Security Objectives
• Response Elements
• Risk-Based Approach
• Compensating Countermeasures
• Least Privilege
• Defense in Depth
• Supply Chain Security
• Security and Safety
32
Chapter III
Security Context
“The security context describes a simple model for establishing the relationships between
various components of the security management system”. Figure 3.10 shows how the elements are related within the two interconnected processes of security assurance (SA) and
risk assessment (RA). On the right side are included threats (events with the potential to
impact in organizational operations), vulnerabilities (weakness of system design, implementation, operation or management that could be exploited), countermeasures (action,
device, procedure or technique that reduces a threat, a vulnerability or an attack by
preventing it), and assets (everything that has a value in the organization) as well as
the relationships between them [84]. On the left side, we have the necessary confidence
requested by the AO, based on assurance and delivered from evaluation activities and
related techniques or methods [85].
Figure 3.10: Security context [39]
Security Objective
“Security objectives describes the three essential objectives of confidentiality, integrity and
availability (CIA) as the three main objectives of IT security and how they are typically
prioritized”. The priority of these three factors are in the order of CIA in IT. In the
IACS the priority is often different: availability, integrity and confidentiality (AIC) as
shown in Figure 3.11. Security in these systems is primarily concerned with maintaining
3.2. ISA/IEC 62443 series overview
33
the availability of all system components “Besides, the integrity and confidentiality are
respectively second and third in priority since the data is raw in form and must be analyzed within context to have any value”[86].
Figure 3.11: Confidentiality, Integrity and Availability priority in IT and IACS
Response Elements
The analysis of a complex system often leads to expressing the desired response in terms
of the people, processes, and technology, presented in Figure 3.12. Each of these elements
must be addressed to respond to the challenges associated with IACS cybersecurity [39].
Figure 3.12: Response elements
• People category includes the management, staff, and other personnel included in
developing and managing the components of the IACS cyber security program.
34
Chapter III
• Processes category is governed by policies, procedures, guidelines and other documentation associated with the IACS Security Management System.
• Technology category includes the technical security capabilities and controls in
place to ensure the availability, integrity, and confidentiality of the IACS [87].
Within the ISA/IEC 62443 series, the technical security controls are grouped into
seven foundational requirements.
Risk Based Approach
Risk based approaches are used to identify, prioritize, mitigate, and manage cybersecurity risks of IACS. There is no single method for securing an IACS because security is
a matter of risk management. Every IACS presents a different risk to the organization
depending upon (i) the threats it is exposed to, (ii) the likelihood of those threats arising,
(iii) the inherent vulnerabilities in the system, and (iv) the consequences if the system
were to be compromised [88]. Every organization that owns and operates an IACS has a
different tolerance for risk [39].
Compensating Countermeasures
In ISA/IEC 62443 series requirements state that the control system shall provide the
capability to support a specific security level. If specific elements of the control system
do not have the inherent capability to meet a specific security level it is acceptable to
employ additional measures to provide this capability. This is referred to as applying a
compensating countermeasure [83].
Least Privilege
Least privilege gives a user or application only those privileges which are essential to
complete the necessary tasks. When applied to users, the terms least user access or
least-privileged user account (LUA) are also used, referring to the concept that all user
accounts should always run with as few privileges as possible, and launch applications
with as few privileges as possible [76].
Supply Chain Security
A comprehensive approach to ensuring the cybersecurity of an IACS cannot be limited
to its operation and maintenance but must also address system and product assessment
and selection. It is essential to consider the security implications across the entire supply
chain, including management of cybersecurity requirements for information technology
systems, software, networks [39], [76]. Typical supply chain security activities for minimizing risks:
• buying only from trusted vendors
• disconnecting critical machines from outside networks
• educating users on the threats and protective measures they can take
3.2. ISA/IEC 62443 series overview
35
Defense in Depth
Defense in Depth is a layered security mechanism enhancing the security of the whole
system, as shown in Figure 3.13. The defense in depth approach’s principle is to ensure
that countermeasures are still in place even if a security breach has occurred. Involves
applying multiple countermeasures in a layered manner to delay or prevent an attack.
Figure 3.13: Defense in depth
This mechanism’s benefit is that during an attack if one layer gets affected, other layers
can still hold on assisting to protect, detect, and react to attacks [82].
Security and Functional Safety
Without addressing cybersecurity throughout the entire safety lifecycle, it is not possible
to adequately understand the relative independence and integrity of the various layers
of protection that involve instrumented systems. Both functional areas (security and
functional safety) need to understand the differences and overlaps. It is important to
understand the typical differences in how the IT professional views their requirements
versus how a process control engineer views theirs [39]. Essential functions are general
principles unique to ISA/IEC 62443 series, mainly addressed in part 3-2. The essential
function is the function or capability required to maintain the safety of the environment,
and availability for the equipment under control. Essential functions include the protection, control, and view of the equipment under control. The definition also says that
security measures shall not affect the essential functions.
36
Chapter III
3.2.6
ISA/IEC 62443 Fundamental concepts
There are several fundamental concepts that are essential to the formulation and execution of an IACS security program. The following general principles apply to all ISA/IEC
62443 series:
• System Taxonomy
• Principal Roles
• Life Cycles and Processes
• Zones and Conduits
• Security Levels
• Foundational requirements
• Maturity Levels
• Models
System Taxonomy
ISA/IEC 62443 series addresses elements such as system, solution, and product through
a simple taxonomy that describes the relationships between these elements. At each level
of the taxonomy, there are standards and technical reports relevant to the element. To
understand an IACS, we need to understand each component in the system taxonomy [39].
Figure 3.14 shows the components, which make up the system and can be:
• embedded devices (PLC, field device)
• host devices (workstatons and servers)
• network devices (switches and routers)
• software applications
Components are used to build systems. Moreover, the system includes the hardware and
software components of an IACS such as:
• Distributed Control Systems (DCS)
• Safety Instrumented Systems (SIS )
• Supervisory Control and Data Acquisition Systems (SCADA)
3.2. ISA/IEC 62443 series overview
37
Figure 3.14: System taxonomy [39]
Systems typically consist of several solutions, each with a specific purpose and area of
application. The automation solution is a specific implementation of the system for a
specific AO at a particular location. The configuration of the system is the automation
solution. The last element that we have is the IACS. This is the collection of people,
processes (like policies and procedures), and technology, forming the IACS. The IACS
is the automation solution and the security program that the AO has to manage the
automation solution.
Principal Roles
To fully understand the processes that make up a cybersecurity management system, it is
necessary to understand the roles involved in executing these processes. A role is defined
by responsibilities and/or accountabilities as well as associated activities to be fulfilled
by an organization. An organization can be an individual or a legal entity and can fulfill
one or several roles [39].
38
Chapter III
Asset Owner/Operator (AO) as defined in [39] is accountable for:
• IACS including its cybersecurity posture and the associated risks throughout the
life cycle
• Defining acceptable cybersecurity risk as an input requirement for all activities
along the IACS life cycle. While remaining accountable, the organization fulfilling this role may delegate specific responsibilities and the associated activities to
organizations fulfilling other roles
• Operation of the IACS. In many cases the company which operates the IACS is
also the legal owner and is accountable for the IACS. In this case the accountable
role belongs to the business management and responsibility for operation is with
the production department of the company
Integration Service Provider (SI) as defined in [39] is responsible for:
• the design, deployment, commissioning and validation of the security measures of
the Automation Solution
• development and validation of a holistic protection scheme to match acceptable
cybersecurity risk
• development of technical measures and guidelines for organizational measures to
be implemented during operation and maintenance
Maintenance Service Provider (SM) , as defined in [39] is responsible for the maintenance
and decommissioning of the Automation Solution. A regular schedule triggers the maintenance activities for (i) actualizing virus patterns and reviewing user accounts during
scheduled maintenance, (ii) updating the holistic protection scheme due to changes, and
(iii) reviewing the technical as well as the organizational measures of the holistic protection scheme to hold the achieved cybersecurity posture. Also, decommissioning parts or
the whole Automation Solution.
Product Supplier (PS) is responsible for:
• the development and support of products used in the Automation Solution
• development of security capabilities to be used for the deployment of the security
measures of the holistic protection scheme
• supplying integration and hardening guidelines as well as establishing a process for
incident handling and vulnerability management applied to its products
IACS Lifecycle
The IACS life cycle phases are mapped to the stages of the general representative system
life cycle model of IEC 24748 Systems and software engineering - Life cycle management
and is shown in Figure 3.15. The concept of a holistic protection scheme recognizes that
3.2. ISA/IEC 62443 series overview
39
the protection of IACS in operation includes a combination of technology, processes,
and people. Furthermore, all roles (AO, SI, SM, PS) must contribute to developing,
operating, and maintaining a holistic protection scheme.
Figure 3.15: IACS lifecycle processes
• Specification
The objective of this phase is the determination of the desired protection for the
IACS in operation and the development of a first partitioning of the automation
solution which has the potential to meet the tolerable cybersecurity risk.
• Design
The objective of this phase is to generate a design of a holistic protection scheme
including technical and organizational measures which have the potential to meet
the tolerable cybersecurity risk defined by the AO in its role as accountable for the
IACS. The overall responsible is the SI.
• Implementation
The objective of this phase is to deploy and test the technical security measures
applied to the automation solution. The activities are performed when a new design
has been developed in which the SI has the overall responsibility of the activities.
• Verification and Validation
The objective of this phase is to verify and validate on site the holistic protection
scheme for the IACS in operation
• Operation
The activities in this phase are focused on ensuring that security measures included
in the holistic protection scheme are performed effectively when operating the IACS.
• Maintenance
The objective of this phase is to adapt the security measures achieving the overall
holistic protection scheme.
40
Chapter III
• Decommissioning
The objective of this phase is to assure that the security measures are still achieved
even during decommissioning and provides the guidelines to take out of service the
IACS.
Zones and conduits
“Every IACS has a different acceptable level of security. These differences can be addressed by using the concept of zones and conduits. A Zone is defined as a grouping of
logical or physical assets that share common security requirements. Zones may be defined
in physical terms (i.e., a physical zone), in logical terms (i.e., virtual zone), or some
combination. A Conduit is defined as a logical grouping of communication channels that
share common security requirements connecting two or more zones. A Channel is defined
as the specific communication links established within a communication conduit” [81].
Security levels
Security levels are defined from SL 0 (no security) to SL 4 (resistant against nation-state
attacks), as shown in Figure 3.16. They provide an approach to addressing security for a
zone, conduit, component, or system. Also, a measure of confidence that IACS or a component thereof is free from vulnerabilities and functions in the intended manner [81], [83].
Figure 3.16: Security levels
3.2. ISA/IEC 62443 series overview
41
Foundational requirements
The seven Foundational Requirements (FRs) are the foundation for defining the control
system or component security capability levels. All aspects associated with meeting
a desired IACS security level (people, processes, and technology) are derived through
meeting the requirements associated with these 7 FRs:
• FR1 - Identification and authentication control (IAC)
• FR2 - Use control (UC)
• FR3 - System integrity (SI)
• FR4 - Data confidentiality (DC)
• FR5 - Restricted data flow (RDF)
• FR6 - Timely response to events (TRE)
• FR7 - Resource availability (RA)
Maturity levels
Maturity levels define the benchmark required to be met by the requirements defined by
the standards IEC 62443-2-4 and IEC 62443-4-1. Each level is progressively more advanced than the previous level. The service providers and the asset owners must identify
the maturity level associated with the implementation of each requirement. Maturity
levels are applied to processes and document how mature an organization is at carrying
out a given process[39]. They can be described as:
• Maturity Level 1 - Ad-hoc process
• Maturity Level 2 - Documented process, but not necessarily repeatable
• Maturity Level 3 - Documented process that is repeatable and consistently followed
• Maturity Level 4 - Documented process that is repeatable, consistently followed,
measured, and improved
Models
The models are needed to provide the necessary details for addressing security issues. To
identify the security need and to address security issues, several the following models are
used in ISA/IEC 62443:
• The Contextual model establishes a frame of reference for more detailed information that follows
• The Physical model describes the hardware components and how they are connected
42
Chapter III
• The Zone model is derived from the activity and physical models, providing the
context for assessing common threats, vulnerabilities, and the corresponding countermeasures needed to attain the SL required to protect the grouped assets [89]
3.3
IEC 62443-3-3: System security requirements and
security levels
This standard is part of the ISA/IEC 62443 series and addresses the security requirements
and security levels for IACS. It provides the technical system requirements based on the
seven foundational requirements (FRs) described in the previous section and shown in
Table 3.2. Other ISA/IEC standards referenced within the IEC 62443-3-3 are IEC 624431-1 and IEC 62443-2-1 [81].
Table 3.2: Foundational requirements
For each FR, this standard provides several system requirements (SRs), and each SR
includes or not several requirement enhancements (REs), as shown in Figure 3.17. Also,
for each SRs and REs are provided the security levels [81].
IEC 62443-3-2 describes the activities required to perform a security risk assessment.
Risk assessment in ISA/IEC 62443 series is defined as “process that systematically identifies potential vulnerabilities to valuable system resources and threats to those resources,
quantifies loss exposures and consequences based on probability of occurrence, and (optionally) recommends how to allocate resources to countermeasures to minimize total
exposure” [40]. The risk assessment goal is to define the necessary countermeasures that
have to be in place in order to achieve an acceptable risk level. The countermeasures
3.3. IEC 62443-3-3: System security requirements and security levels 43
Figure 3.17: Relation between Foundational Requirements, System Requirements and
Requirement Enhancements
are necessary to determine the security levels. IEC 62443-3-3, based on the seven FRs,
defines a set of security countermeasures to achieve the target SL due to the risk assessment in IEC 62443-3-2. Following are shown the FRs from FR 1 to FR 7. For each FR,
a general description is provided, and the list of respective SRs is shown. IEC 62443-3-3
provides the REs for each SR and the respective security levels.
FR 1 - Identification and authentication control
“Identify and authenticate all users (humans, software processes and devices) before allowing them to access to the control system” [81]. FR1 includes the SRs listed in Table 3.3:
Table 3.3: FR 1 - Identification and authentication control
44
Chapter III
FR 2 - Use control
”Enforce the assigned privileges of an authenticated user (human, software process or
device) to perform the requested action on the IACS and monitor the use of these privileges” [81]. This FR includes the SRs listed in Table 3.4:
Table 3.4: FR 2 - Use control
FR 3 - System integrity
”Ensure the integrity of the IACS to prevent unauthorized manipulation” [81]. This FR
includes the SRs listed in Table 3.5:
Table 3.5: FR 3 - System integrity
3.3. IEC 62443-3-3: System security requirements and security levels 45
FR 4 - Data confidentiality
“The control system shall protect audit information and audit tools (if present) from
unauthorized access, modification and deletion” [81]. FR 4 includes the SRs listed in
Table 3.6:
Table 3.6: FR 4 - Data confidentiality
FR 5 - Restricted data flow
“Segment the control system via zones and conduits to limit the unnecessary flow of
data” [81]. This FR includes the SRs listed in Table 3.7:
Table 3.7: FR 5 - Restricted data flow
FR 6 - Timely response to events
“Respond to security violations by notifying the proper authority, reporting needed evidence of the violation and taking timely corrective action when incidents are discovered” [81]. This FR includes the SRs listed in Table 3.8:
Table 3.8: FR 6 - Timely response to events
46
Chapter III
FR 7 - Resource availability
“Ensure the availability of the control system against the degradation or denial of essential
services” [81]. This FR includes the SRs listed in Table 3.9:
Table 3.9: FR 7 - Resource availability
IEC 62443-3-3 provides the system requirements, but the implementation is to be
done by the service provider. This standard looks to the actual capabilities of the system
under consideration and how to evaluate if the overall system and the subsystems meet
the security targets based on the security levels. The ISA/IEC 62443 series define three
types of security levels: (i) Target Security Levels (SL-T), is the desired security level for a
zone or conduit based on the risk assessment performed in IEC 62443-3-2, (ii) Capability
Security Levels (SL-C) are the levels defined by IEC 62443-3-3 and IEC 62443-4-2. They
define the system and component requirements, and if adequately configured, this will be
the security level they can achieve without any other countermeasure, and (iii) Achieved
Security Levels (SL-A) is the security level reached by the system under consideration [39].
Following, in Table 3.10 is shown an example of the FR1s, SR1s, RE1 - RE3 and their
perspective security levels, from SL 1 the lowest to SL 4 the highest security level.
Table 3.10: FR 1 including SRs, REs and the security levels
Applying IEC 62443-3-3 provides methods and possibilities to identify the security
for a specific zone. It is possible to check the system’s security levels, and it is used as a
check list to meet the SL-T based on the risk assessment.
Chapter 4
Monitoring and Standard
Compliance Verification
Ensuring that the components integrated into industrial processes are compliant to the
standards, procedures, recommendations and best practice guidelines are essential. They
support the interoperability of these components at different levels. Regular monitoring
of the systems against the verified standards ensures that the organization fulfills the
requirements to exchange data and meets the required security levels. In this chapter,
the Monitoring and Standard Compliance Verification framework (MSCV) is presented,
and the results of security standards evaluation are shown. Additionally, the use cases
where the MSCV is implemented and their results are presented.
4.1
Standard Compliance Verification
An increasing number of studies [90], [91], [92], [93] show the increased awareness of
security in SoS. Unfortunately, the ability of these systems to address security is still
not mature enough. With the rise of attacks against industrial processes, the need for
standards and regulations is increasing, and existing standards or guidelines are used, or
new ones are drafted. The evaluated standards in the thesis, and many others are drafted
from different bodies and provide many recommendations, but they all have the same
goal - to address security in emerging technologies. Their requirements usually overlap,
and in many cases, the same requirement has different meanings, so it is the organisation
decision to find the best standard to address their needs and implement it.
Standard compliance in SoS means complying with standards and recommendations
that apply to distributed systems. To provide standard security compliance for SoS their
evolving nature and long life should be considered because this will impact security activities. This leads to a framework that continuously monitors and evaluates compliance
towards one or several standards during design and operation time. Moreover, standard
compliance results must give an overall description of the system and its current state
for the security standards.
47
48
Chapter IV
This thesis proposes an automated monitoring and standard compliance verification
framework (MSCV). The MSCV can provide standard compliance verification for a single component or several components based on a single standard or many standards [23].
The solution provides the possibility to monitor security standards and other aspects
such as safety, organisational, etc., which have not been addressed by the thesis but
could be added in the future. It can be used to monitor any device, system, or service by
providing a monitoring agent (monitoring possibility) for the technically implementable
metrics extracted from any standard. The MSCV is used to provide automated and continuous standard compliance verification from onboarding to the orchestration of devices,
systems, or services in a SoS environment.
The following section describes the MSCV architecture designed to monitor different
use cases based on the MSIs, and to provide standard compliance verification.
4.2
Monitoring and Standard Compliance Verification Framework
Generally, compliance requirements are provided from several sources (standards, best
practices, laws, recommendations, guidelines, etc.). The first step to provide standard
compliance verification is to identify and address the security requirements. These requirements should be extracted or provided by the SoS to meet their overall objective.
To achieve this, a structured way of assessing them is necessary to provide interoperability and usability. Also, the frequent change of technologies and the possible updates of
standards should be considered.
The next step is to evaluate a set of security standards that fulfill the identified requirements. The standards should be selected based on the requirements and the implementation possibilities they provide. After the proper standard or standards addressing
the requirements are defined, the requirements should be transformed in measurable metrics, and each of them should be documented to provide the necessary information to
implement the specific metric. A metric model shows the relation between the requirements, standards, and metrics to simplify this process. The metric model can also be
used to classify standards and MIPs in security standards and MSIs, safety standards
and measurable safety indicators (MSFI) or organizational standards, and measurable
organizational indicators (MOI). It can be used to map any domain’s requirements, but
for the scope of the thesis, the security standards and MSIs are documented (Paper I
provides an example of the metric model) [23]. Each MSI extracted from the standards
is documented as follows:
[ID] - unique ID of the MIP
[Name] - name of the MIP based on the standard
[Source] - the standard from where the MIP is extracted
[Definition] - definition of the MIP based on the standard and other sources
[Monitoring value] - result of the monitored MIP
[Monitoring solution] - a customized script or existing monitoring plugin
4.2. Monitoring and Standard Compliance Verification Framework
49
To verify the compliance, a verification module is needed to assure that the specific
component or number of components are fulfilling the standard MSIs. The MSCV framework is proposed to address this, which could be used by all security actors involved in
the industrial environment, such as security experts, auditors, certification bodies, system integrators, industrial manufacturers, etc. The MSCV framework is the verification
tool used to check a specific component or number of components if they fulfill the MIPs
of a single standard or many standards. The MIPs are the metrics, controls, or countermeasures extracted from the standard. They should be technically implementable,
measurable, and should provide a logic value.
The MSCV presented in this thesis has an architecture based on three main modules:
• Monitoring agents module: customized scripts or existing plugins from monitoring tools (e.g., Nagios, Zabbix, Cactus, etc.) [23], [94], [14]. They are pluggable
agents and can be added or removed without affecting the architecture.
• Evidence gathering mechanism (EGM) module: has three components, (i) the
EGM used to store, analyze and map the MIPs results, (ii) the monitoring agent
manager, which includes a monitoring scheduler used to decide when to monitor
the target system, (iii) monitoring source standard, responsible for providing the
standard source for each MIP and (iv) bitwise MIPs used to assign to each metric
a binary value [23], [94], [14].
• Compliance module: collects the information from the EGM and, based on requirements of the target system, assigns a weight value to each MIP and provides
the compliance result. Each MSI has the source from which standard is extracted
and a binary value 1 or 0 that indicates if the metric is fulfilled or not. After gathering all the required evidence, it verifies the compliance [%] for a single standard
as the ratio between the sum of each MSI measured value, multiplied by its weight
value and the total number of metrics per standard, or it verifies the total compliance [%] as the ratio between the sum of each standard compliance and the total
number of standards [23]. The compliance result can be shown either for component or the entire system and is based on a single or a number of standards [23],
[94], [14].
The MSCV framework is documented in: Paper A, where the EGM is proposed, Paper
G defines the components of the MSCV and security standards are evaluated, Paper H
extends the MSCV with organizational standards, Paper I shows the MSCV integrated
in an IIoT use case, and Paper J shows the MSCV integrated into a SoS use case.
50
4.3
Chapter IV
Security Standards Evaluation
The standardization bodies described in section 3.1 show their specific expertise in different domains. Based on their main domain, many security standards are selected to
check if they address the back-end infrastructure, communication layer, or cyber physical devices. The following are listed the security standards selected for this evaluation.
Paper I provides the results of the security standard evaluation.
NIST SP 800-82 - Guide to Industrial Communication Systems Security
NIST SP 800-184 - Guide for Cybersecurity Event Recovery
NIST CSF - Framework for Improving Critical Infrastructure Cybersecurity
ISO/IEC 27001 - Information technology - Security techniques - Information security
management systems - Requirements
ISO/IEC 27002 - Information Technology - Security Techniques - Code of Practice for
Information Security Controls
ISO/IEC 27005 - Information Technology - Security Techniques - Information Security
Risk Management
ISO/IEC 27017 - Information Technology - Security Techniques - Code of Practice for
Information Security Controls
ISO/IEC 15408 - CC - Information technology - Security techniques - Evaluation criteria for IT security - Part 2: Security functional requirements
CCSC - CIS Critical Security Controls for Effective Cyber Defense
NISPOM - National Industrial Security Program Operating Manual
CTP - Cloud Trust Protocol
CSA-ICS - Cyber Security Assessment of Industrial Control Systems
NAMUR NA115 - IT Security for Industrial Automation Systems: Constrains for
measures applied in process industries
VDI/VDE 2182 - IT Security for Industrial automation - General Model
IEC 62443-3-3 - Industrial communication networks - Network and system security -
4.3. Security Standards Evaluation
51
Part 3-3: System security requirements and security levels
The purpose of evaluating these standards is to understand if they can be used to
address the security requirements of industrial use cases, implement the security standards in an established system, and have a better overview of the gaps and overlaps
between different standards. Also, to make use of these standards to monitor and verify
standard compliance, they are evaluated based on the documentation of the metrics,
countermeasures, or controls provided. Another important aspect of an industrial environment is the dependability of components in terms of other aspects such as safety and
organisational. The thesis’s scope is to show security standard compliance but to check
security and safety, and organisational dependencies should be considered. Based on the
evaluations, a summary of the standards and best practice guidelines is provided with
the main findings:
i. The standards address a specific domain. A security standard hardly considers other
aspects and dependabilities (e.g., safety or organizational aspects), but they provide
references to other standards. The same result is shown when safety or process
management standards are evaluated, they hardly consider other aspects.
ii. There is not a single standard that addresses security considering all main enablers
of digitalisation (from edge devices to backend services).
iii. The standards hardly provide guidelines or implementation possibilities how to fulfill
their metrics, countermeasures or controls.
iv. If a new version of the standard is published the requirements may be updated.
These results highlighted that there is no one-size-fits-all standard considering the
three main enablers of digitalisation, such as cyber physical devices (e.g., sensors, actuators), communication layer (e.g., protocols), and backend infrastructure (e.g., cloud
services) [23]. Therefore, several security standards should be harmonized to provide automated standard compliance verification. Also, to implement any security standard, the
organisation should transform the metrics into measurable and machine-readable metrics depending on the device, system, or service under consideration. The results of the
evaluation are documented in Paper I.
52
4.4
Chapter IV
Monitoring and Standard Compliance Verification Integrated in Industrial Internet of Things
The Monitoring and Standard Compliance Verification (MSCV) framework is used to
verify continuous and automated standard compliance verification and has been designed
to support different use cases and viewpoints considered in industrial environments [11].
To show this, an Industrial IoT (IIoT) end-to-end communication use case is investigated.
This use case was evaluated as part of the H2020 research project named SemI40 (www.
semi40.eu) “Power Semiconductor and Electronics Manufacturing 4.0”, funded from the
ECSEL Joint Undertaking under grant agreement No 692466.
The IIoT use case represents the secure data exchange from the edge devices, such
as cyber physical devices (e.g., IoT and legacy devices in the industrial environment) to
the backend infrastructure (e.g., cloud services) via IIoT gateways. The secured communication from the edge devices to the IIoT gateway is done via the MQTT protocol
for IoT devices, and a translator is used to translate proprietary protocols to MQTT for
the legacy devices [55]. The IIoT gateway uses a MQTT broker as a cloud gateway to
send data to a database in the local cloud for further analysis. The MSCV monitors all
the components of the end-to-end communication (edge devices, translator, IIoT gateway, MQTT broker, and cloud application) via existing monitoring agents or customised
scripts if there is no existing monitoring possibility.
To build and evaluate the IIoT use case, a local cloud using the OpenStack platform
is implemented. The OpenStack cloud platform makes it possible to control large pools
of computing, storage, and networking resources through a datacentre managed from the
OpenStack dashboard. OpenStack works with open-source technologies, making it ideal
for building, testing, and investigating the use case and the MSCV framework [23].
The above mentioned use case is checked for standard compliance verification based on
the access control requirement. To address the requirements, ISO 27002 and IEC 624433-3 standards are used. Also, two standards are selected to show that MSCV can provide
standard compliance for more than one standard. ISO 27002 provides 15 metrics, and IEC
62443-3-3 provides 12 MSIs addressing access control. The requirements, standards, and
MSIs are documented in the metric model, used as input for the MSCV framework [23].
To show the functionality of the MSCV, a representative set of the overall metrics are
selected, and the use case is verified for two scenarios: in different time frames and when
adding a new component [23].
The first scenario considers the components already addressing access control requirements, and the standard compliance is shown for each component. Moreover, overall
compliance from both standards is provided. In the second scenario, a new component is
added to the use case (MQTT broker) with no access control implemented. The difference in the overall standard compliance verification in different time slots is shown. This
provides the necessary information to the security engineers to harden their system regarding access control requirements. Paper I shows the results of the MSCV implemented
in the IIoT use case.
4.5. Monitoring and Standard Compliance Verification Integrated in
Service Oriented Architecture
53
4.5
Monitoring and Standard Compliance Verification Integrated in Service Oriented Architecture
The MSCV as a service is implemented in the Eclipse Arrowhead framework for standard
compliance verification during onboarding and run time of devices, systems, and services.
This use case was evaluated as part of two H2020 research projects, Productive 4.0, funded
from the ECSEL Joint Undertaking under grant agreement No 737459, and Arrowhead
Tools funded from the ECSEL Joint Undertaking under grant agreement No 826452.
The secure onboarding procedure of the Eclipse Arrowhead provides a chain of trust
from the device, systems, and services when interacting for the first time with the Eclipse
Arrowhead local cloud documented in Paper F [9]. This procedure engages: (i) the core
systems (ServiceRegistry system, Authorisation system, and Orchestrator system) and
(ii) automation support core systems (OnboardingProcedure system, DeviceRegistry system, SystemRegistry system, and CertificateAuthority system) [9]. To provide continuous and automated standard compliance verification during this procedure, the MSCV
system is implemented as an automation support core system. It checks the device, software systems on top of the device, and the running services if they fulfill the MSIs of a
specific standard. If they fulfill the MSIs and are compliant to the standard, they can
be registered respectively in DeviceRegistry, SystemRegistry, and ServiceRegistry. The
MSCV will provide the standard compliance, and based on the outcome, the Authorisation system will decide if they are allowed to be registered within the local cloud. This will
provide the necessary information if the device, systems, and services fulfill the security
requirements to consume already existing or register new services in ServiceRegistry.
During run time, the MSCV system can be used in two different scenarios. To provide
the requested endpoints from a device, system, or service to consume an already registered
service, the Orchestrator system will check for standard compliance verification via the
MSCV system. Based on the MSCV system’s result, the Orchestrator will decide if the
device, system, or service can get the requested endpoint. Another scenario of the usage of
MSCV is via EventHandler, which monitors the local cloud and, based on specific events,
send out notifications. This system can check for standard compliance verification at any
time and provide the result to the necessary requests from any Eclipse Arrowhead system.
The MSCV system verifies the MSIs extracted from IEC 62443-3-3 and IEC 62443-42, classified in seven categories. Paper J provides the results of the MSCV implemented
in the Eclipse Arrowhead framework.
54
Chapter IV
Chapter 5
Summary of Contributions
This chapter includes the summary of appended papers and the author’s contribution, also a summary of additional publications that are related to but not included in
the thesis. The appended publications are presented in chronological order.
5.1
Summary of Appended Papers
Paper A: Harmonized Monitoring for High Assurance Clouds
Authors: Ani Bicaku, Silvia Balaban, Markus Tauber, Aleksandar Hudic, Andreas
Mauthe and David Hutchison
Published in: 2016 IEEE International Conference on Cloud Engineering Workshop
Summary: This paper presents an analysis of state of the art in cloud monitoring concerning high assurance. It evaluates existing cloud monitoring solutions based on their
ability to support high assurance clouds. Each solution is assessed based on monitoring
type and the ability to monitor a specific property at a specific layer. Individual existing
tools can monitor some but not all properties. In this paper, the set of security properties
associated with specific security classes (e.g., confidentiality, integrity, and availability)
are analyzed at various layers (e.g., infrastructure, tenant, and service). In this paper is
proposed the Evidence Gathering Mechanism (EGM) to monitor cloud computing critical infrastructure for high assurance.
Contribution: The author was responsible for identifying existing monitoring solutions
and evaluating if they can monitor confidentiality, integrity, and availability metrics in
infrastructure, tenant, and service layers. Also, to design the EGM approach and show
how the identified metrics can be monitored via existing agents or customized scripts.
55
56
Chapter V
Paper B: Towards a Security Baseline for IaaS-Cloud Back-Ends in Industry 4.0
Authors: Elisabeth Bauer, Oliver Schluga, Silia Maksuti, Ani Bicaku, David Hofbauer,
Igor Ivkic, Markus Tauber
Published in: 2017 12th International Conference for Internet Technology and Secured
Transactions (ICITST)
Summary: In this paper, ENISA guidelines are evaluated concerning the security assessment of IaaS solutions. The extracted set of security parameters is used to assess the
commercial VMware platform and the open source OpenStack platform. The results are
a first step towards the technical definition of a security baseline for IaaS cloud backends,
which can be used for Industry 4.0 environments.
Contribution: The author has contributed to assess ENISA guidelines in OpenStack
platform.
Paper C: Towards Trustworthy End-to-End Communication in Industry 4.0
Authors: Ani Bicaku, Silia Maksuti, Silke Palkovits-Rauter, Markus Tauber, Rainer
Matischek, Christoph Schmittner, Georgios Mantas, Mario Thron and Jerker Delsing
Published in: 2017 IEEE 15th International Conference on Industrial Informatics (INDIN)
Summary: This paper provides a detailed state of the art investigations for industrial reference architectures and secure communication protocols. In this paper, a Cyber
Physical Production System (CPPS) meta-model is derived used as a tool to identify the
dependencies among different CPPS components. Providing a clear view of the dependencies can help to define monitoring points for the whole system. A use case addressing
the communication from the edge devices to the back-end infrastructure via IIoT gateways is considered to show this.
Contribution: The author was responsible for investigating secure messaging protocols
and reference architectures. Also, to map the end-to-end communication use case in the
CPPS meta-model and show the dependability between components in case of security
breaches.
5.1. Summary of Appended Papers
57
Paper D: A Lightweight Authentication Mechanism for M2M Communications in Industrial IoT Environment
Authors: Alireza Esfahani, Georgios Mantas, Rainer Matischek, Firooz B. Saghezchi,
Jonathan Rodriguez, Ani Bicaku, Silia Maksuti, Markus Tauber, Christoph Schmittner,
and Joaquim Bastos
Published in: IEEE Internet of Things Journal 2018
Summary: In this paper, a lightweight authentication mechanism, based only on hash
and XOR operations for M2M communications in Industrial IoT environment is proposed.
Contribution: The author has contributed with the evaluation and investigation of the
features of possible M2M protocols for IoT. Also, has contributed in the protocol comparison.
Paper E: Operations Security Evaluation of IaaS-Cloud Backend for Industry 4.0
Authors: Oliver Schluga, Elisabeth Bauer, Ani Bicaku, Silia Maksuti, Markus Tauber
and Alexander Wöhrer
Published in: Proceedings of the 8th International Conference on Cloud Computing
and Services Science (CLOSER)
Summary: This paper presents an overview of standards and best practice guidelines
with a focus on operations security. The ISO 27017 standard is evaluated, with particular
focus on clause (12) Operations Security to check if open source or commercial platforms
such as OpenStack and VMware address these objectives.
Contribution: The author has contributed with the applicability of operation security
controls in OpenStack and the comparison with VMware.
Paper F: Interacting with the Arrowhead Local Cloud: On-boarding Procedure
Authors: Ani Bicaku, Silia Maksuti, Csaba Hegedus, Markus Tauber, Jerker Delsing
and Jens Eliasson
Published in: 2018 IEEE Industrial Cyber-Physical Systems (ICPS)
58
Chapter V
Summary: This paper introduces two additional automation support core systems of the
Eclipse Arrowhead Framework: SystemRegistry and DeviceRegistry systems to provide
storage for the systems and devices. These systems are needed to create a chain of trust
from the hardware device to its hosted SW-systems and their services whenever a new
device wants to interact with the Eclipse Arrowhead local cloud. To address is presented
a step-by-step on-boarding procedure, including the Arrowhead mandatory core systems.
Contribution: The author was responsible for the design and the concept of the DeviceRegistry system. Also, responsible for the communication of the DeviceRegistry with
the other systems in the Eclipse Arrowhead framework.
Paper G: Monitoring Industry 4.0 Applications for Security and Safety Standard Compliance
Authors: Ani Bicaku, Christoph Schmittner, Markus Tauber and Jerker Delsing
Published in: 2018 IEEE Industrial Cyber-Physical Systems (ICPS)
Summary: This paper presents the monitoring and standard compliance verification
framework for Industry 4.0 application scenarios to provide an automated and continuous standard compliance verification.
Contribution: The author was responsible for designing the Monitoring and Standard
Compliance Verification (MSCV) architecture and its component. Also, to define the security standard compliance verification algorithm to calculate standard compliance for a
single standard or several standards. The author was responsible for defining the Measurable Security Indicators (MSIs) for the end-to-end communication use case and providing
monitoring solutions for MSIs.
Paper H: Security Safety and Organizational Standard Compliance in Cyber Physical
Systems
Authors: Ani Bicaku, Christoph Schmittner, Patrick Rottmann, Markus Tauber and
Jerker Delsing
Published in: Infocommunication Journal 2019
Award: Pollák-Virág award of HTE (Scientific Association for Info-communications
Hungary) (https://www.hte.hu/pollak-virag-dij)
5.1. Summary of Appended Papers
59
Summary: In this paper, the Monitoring and Standard Compliance Verification (MSCV)
framework is extended to include organizational aspects (MOI) in order to provide automated standard compliance, including process management standards.
Contribution: The author was responsible for the principle idea and the proposed architecture. Also, was the main contributor of the text.
Paper I: Security Standard Compliance and Continuous Verification for Industrial IoT
Authors: Ani Bicaku, Markus Tauber and Jerker Delsing
Published in: International Journal of Distributed Sensor Networks Journal 2020
Summary: This work presents the monitoring and standard compliance verification
framework results applied in an Industrial IoT use case. The continuous standard compliance verification is shown for all the use case components in different time frames and
when a device is added/removed from the use case.
Contribution: The author was the main contributor of the text and was responsible
for the standardization landscape (evaluating several security, safety, and organisational
standards to check if they consider the edge devices, communication protocols or the
backend infrastructure and to evaluate if the security, safety, and organizational standards consider the dependability between each other). Also, to conduct the experiments
in the use case and provide standard compliance verification.
Paper J: Security Standard Verification in System of Systems
Authors: Ani Bicaku, Mario Zsilak, Peter Theiler, Markus Tauber and Jerker Delsing
Submitted to: IEEE Systems Journal
Summary: This work presents an automated standard compliance verification framework used to check devices, systems, and services for standard compliance during onboarding and run time. Also, a case study for the Eclipse Arrowhead framework is used
to demonstrate the functionality of the standard compliance in system of systems.
Contribution: The author was responsible for the principle idea and the proposed
system. Also, was the main contributor of the text.
60
5.2
Chapter V
Additional Publications
This section lists publications containing contributions from the author’s research work
which are related to, but not included in this thesis.
Paper 1: Towards Modelling a Cloud Application’s Life Cycle
Authors: Reginald Butterfield, Silia Maksuti, Markus Tauber, Christian Wagner and
Ani Bicaku
Published in: 6th International Conference on Cloud Computing and Services (CLOSER)
Summary: This work presents modeling of a cloud based application lifecycle. Since
the lifecycles usually are IT focused, it is proposed a model with focus on business and
its operating environment considering security through each phase of the lifecycle.
Paper 2: Towards Resilience Metrics for Future Cloud Applications
Authors: Marko Novak, Syed Noorulhassan Shirazi, Aleksandar Hudic, Thomas Hecht,
Markus Tauber, David Hutchison, Silia Maksuti and Ani Bicaku
Published in: 6th International Conference on Cloud Computing and Services (CLOSER)
Summary: This paper investigates technological and security trends and their potential to become future threats by systematically examining industry reports on existing
technologies. A cloud computing use case is considered to identify potential resilience
metrics that can be used to provide the security properties of the system
Paper 3: Towards Flexible and Secure End-to-End Communication in Industry 4.0
Authors: Silia Maksuti, Ani Bicaku, Markus Tauber, Silke Palkovits-Rauter, Sarah
Haas and Jerker Delsing
Published in: 2017 IEEE 15th International Conference on Industrial Informatics
Summary: This work proposes a self adaptation solution for secure end-to-end communication in Industry 4.0. A metamodel is used to describe the use case and identify
the self-adaptation points. Also, a business process performance and security trade-off is
provided to show the need for an efficient balance between performance and security.
Chapter 6
Conclusions and Future Work
The thesis presents finding and challenges in the domain of SoS regarding automated
standard compliance verification during design and run time. It investigates digitalization technologies, standardisation bodies, security standards and provides a framework
for automated continuous standard compliance verification by considering requirements,
standards, and measurable security indicator points. This chapter presents conclusions
and future work.
6.1
Conclusions
This thesis’s contribution is relevant to the academic and industrial community towards
achieving compliance to existing standards by providing a framework that could be used
and adapted in different use cases. By analysing the digitalization technologies and
the security standards that can be technically implemented, including their gaps and
overlaps, a comprehensive result demonstrating the need for more than one standard is
presented. Also, the documentation of the MSIs, including their definition from several
standards and how to implement them, is helpful for future research in the academia.
Moreover, the methodology to show standard compliance verification, the obtained
results, and the description on how to achieve it (necessary methods and tools) is relevant for industries that want to show evidence of compliance with a specific standard
or a number of standards. This will provide security evidence and interoperability of
services in SoS. The MSCV framework provides an opportunity for system integrators
and security experts to identify possible weaknesses and vulnerabilities of their systems
and give them the possibility to improve their security process. Also, it demonstrates
that traditional manual audits can be automated and digitized, which reduces time and
resource usage.
The research contributions are summarized below:
61
62
Chapter VI
Q1: What existing standards can be considered relevant to address security from
edge devices to the back-end infrastructure, including their communication and what
are the difficulties of implementing them?
The thesis results and the evaluation of several security standards demonstrated
that there is no one-size-fits-all solution, and there is not a single standard addressing security from the back-end infrastructure to the edge devices, including
their communication. The findings of the evaluation indicate that even within the
same family of standards, more than one standard is required, for example, within
ISA/IEC 62443 series, if the scope is to address security requirements of the system, IEC 62443-3-3 is required; to address security requirements of components,
IEC 62443-4-2 is required; if the scope is to provide a detailed risk assessment,
IEC 62443-3-2 is required. Also, within ISO 27000 family, ISO 27001 provides the
framework for information security, but ISO 27002 is required to implement the security controls, ISO 27005 for risk assessment, and ISO 27017 is required to address
security requirements for cloud services.
Several standards need to be engaged to provide secured end-to-end communication
from backed infrastructure to the edge devices because the components should fulfill many security requirements from different standards. After the selection of the
security standards to comply, the next challenge is their implementation. Standards
provide requirements, countermeasures, and controls, but do not give information
how to implement them. To address this, the requirements, countermeasures, and
controls are transformed in measurable indicator points, and possible ways to implement them are provided. This is achieved via existing monitoring agents or
customized scripts. Since more than one standard is considered, a mechanism to
collect and filter the monitored data is designed and implemented, the Evidence
Gathering Mechanism (EGM). EGM is one of the building modules of the MSCV.
This research is presented in the following papers:
Paper A provides a comprehensive evaluation of existing monitoring tools and
frameworks that can be used to gather events from several components. It proposes the EGM as a single management point of the results gathered from different
security standards. Several security standards are evaluated, such as NIST and ISO,
to extract MSIs for critical infrastructure clouds, and their monitoring possibilities
are provided. In Paper C, an end-to-end communication use case is implemented,
and a set of representative MSIs from ISO, ISA/IEC, and NIST are presented to
address security from edge devices to the backend infrastructure. Paper D investigates different secure communication protocols that can be used in industrial
environments. Also, Paper E, G, H, and J provide standard evaluations. In Paper
I, a comprehensive evaluation of security standards is conducted, and based on this
evaluation, it highlights the need for more than one standard to address security
from the edge devices to the backend infrastructure.
6.1. Conclusions
63
Q2: How can standard compliance be verified and how the requirements of an already implemented solution can be addressed in standard compliance?
Standardization bodies publish standards in different domains. Choosing the right
standard to implement and comply with, it is not an easy task. To understand
security standard compliance, it is important to know the difference with security. Security involves all the countermeasures, mechanisms and policies to protect
devices, systems, and services regarding confidentiality, availability, and integrity.
Security standard compliance is the fulfillment of security countermeasures, mechanisms, or policies extracted from standards by the devices, systems, and services.
The industrial environment is composed of legacy and new devices, which are already implemented in different solutions. They are part of different systems and
usually have different security requirements. Standards are used to provide interoperability and security for these existing systems.
This thesis shows that it is possible to provide automated and continuous standard
compliance verification for one or several standards. Also, standard compliance
can be verified for one or several components by transforming the extracted metrics in MSIs. Detailed documentation is provided for each MSI, including ID, name,
source, definition, and implementation possibility. The MSCV framework shows the
continuous standard compliance verification for one or several components based
on one or several standards. These results are provided for an end-to-end communication use case for different time frames and when devices are added or removed
from the use case. A set of representative MSIs extracted from ISO 27002, and
IEC 62443-3-3 are used to show the standard compliance verification. The compliance results are shown in a dashboard that provides real time verification of the
individual components and the entire use case.
This research is presented in the following papers:
Paper B and E investigate open-source and commercial cloud platforms. Based
on this evaluation, the OpenStack cloud platform is selected to build the cloud
testbed and evaluate the MSCV for the end-to-end communication use case. Paper
G proposes the architecture of the MSCV and its components. The algorithm used
to calculate standard compliance verification is presented in this paper.
Paper H extends the MSCV framework with process management standards and
measurable organizational indicators (MOI) by concluding that the MSCV framework can be easily extended with any other domain for standard compliance verification if the standard can provide metrics that can be technically implemented.
Paper I implements and shows the results of the MSCV in an end-to-end communication use case for different time frames and when devices are added or removed
from the use case.
64
Chapter VI
Q3: How to integrate standard compliance verification in a dynamic and evolving
system of systems (SoS) environment?
SoS typically evolves over time, which can introduce security vulnerabilities that
the SoS or its components do not address or are not aware of during design time.
Therefore, the security mitigations in place for an evolving SoS will be difficult to
be completely specified at design time and will need to evolve as the SoS evolves.
The thesis proposes the MSCV as a service implemented in a SoA framework, in
this case, the Eclipse Arrowhead framework. The MSCV provides the ability to
check for standard compliance verification during onboarding of devices, systems,
and services. It enhances the security features of Eclipse Arrowhead framework by
adding a new service named StandardComplianceVerification.
Since SoS evolve over time, this service provides standard compliance verification
during onboarding and operation time until the device, system, or service is removed from the local cloud. The MSCV is implemented in the Eclipse Arrowhead
framework, and the standards IEC 62443-3-3 and IEC 62443-4-2 are selected to
extract the MSIs.
This research is presented in the following papers:
Paper F provides the secure onboarding procedure for the Eclipse Arrowhead framework and the sequence diagram showing the necessary steps to securely onboard a
new device, system, and service in the local cloud. In Paper J, the role of MSCV
in a SoS during onboarding and operation time as part of the Eclipse Arrowhead
framework is presented.
6.2
Future Work
Future work includes support of other standard compliance domains, such as safety
standard compliance, organisational standard compliance, and legal standard compliance. Safety and organizational standard compliance are already investigated during
this work, but safety and process management standards that can be technically implemented should be investigated.
Another area of future work can be towards standardization bodies and standards
to define the metrics, countermeasures, requirements or controls in such a way that can
be machine readable (technically implementable). This will provide the ability to have
a holistic protection scheme, quickly deploy security measures, and provide digital and
continuous compliance evidence via the MSCV framework.
References
Bibliography
[1] K. Stouffer, J. Falco, and K. Scarfone, “Guide to industrial control systems (ics)
security,” NIST SP, vol. 800, no. 82, pp. 16–16, 2011.
[2] D. Ivanov, A. Dolgui, and B. Sokolov, “The impact of digital technology and industry
4.0 on the ripple effect and supply chain risk analytics,” International Journal of
Production Research, vol. 57, no. 3, pp. 829–846, 2019.
[3] “Productive 4.0 - a european co-funded innovation and lighthouse project on digital
industry,” [Online]. Available: https://productive40.eu/, (Accessed on 07/06/2020).
[4] “Arrowheadtools,” [Online]. Available: https://www.arrowhead.eu/arrowheadtools,
(Accessed on 07/06/2020).
[5] “Semi40 - power semiconductor and electronics manufacturing 4.0,” [Online]. Available: https://semi40.eu/, (Accessed on 07/06/2020).
[6] “Ai4di - artificial intelligence for digitizing industry,” [Online]. Available: https:
//ai4di.automotive.oth-aw.de/index.php, (Accessed on 07/06/2020).
[7] “Cps4eu,” [Online]. Available: https://cps4eu.eu/, (Accessed on 07/06/2020).
[8] “idev40 - integrated development 4.0,” [Online]. Available: http://www.idev40.eu/,
(Accessed on 07/06/2020).
[9] A. Bicaku, S. Maksuti, C. Hegedűs, M. Tauber, J. Delsing, and J. Eliasson, “Interacting with the arrowhead local cloud: On-boarding procedure,” in 2018 IEEE
industrial cyber-physical systems (ICPS). IEEE, 2018, pp. 743–748.
[10] J. Delsing, Iot automation: Arrowhead framework. CRC Press, 2017.
[11] A. Bicaku, C. Schmittner, M. Tauber, and J. Delsing, “Monitoring industry 4.0
applications for security and safety standard compliance,” in 2018 IEEE Industrial
Cyber-Physical Systems (ICPS). IEEE, 2018, pp. 749–754.
65
66
Chapter VI
[12] A. J. Trappey, C. V. Trappey, U. H. Govindarajan, J. J. Sun, and A. C. Chuang,
“A review of technology standards and patent portfolios for enabling cyber-physical
systems in advanced manufacturing,” IEEE Access, vol. 4, pp. 7356–7382, 2016.
[13] J. Lee, B. Bagheri, and H.-A. Kao, “A cyber-physical systems architecture for industry 4.0-based manufacturing systems,” Manufacturing letters, vol. 3, pp. 18–23,
2015.
[14] A. Bicaku, S. Maksuti, S. Palkovits-Rauter, M. Tauber, R. Matischek, C. Schmittner,
G. Mantas, M. Thron, and J. Delsing, “Towards trustworthy end-to-end communication in industry 4.0,” in 2017 IEEE 15th International Conference on Industrial
Informatics (INDIN). IEEE, 2017, pp. 889–896.
[15] Q. Zhu, R. Wang, Q. Chen, Y. Liu, and W. Qin, “Iot gateway: Bridgingwireless sensor networks into internet of things,” in 2010 IEEE/IFIP International Conference
on Embedded and Ubiquitous Computing. Ieee, 2010, pp. 347–352.
[16] M. W. Maier, “Architecting principles for systems-of-systems,” Systems Engineering:
The Journal of the International Council on Systems Engineering, vol. 1, no. 4, pp.
267–284, 1998.
[17] U. Dod, “Systems engineering guide for systems of systems,” Washington, DC, US
Department of Defense, Office of the Deputy Under Secretary of Defense for Acquisition and Technology, 2008.
[18] ISO/IEC/IEEE, “21839 systems and software engineering â system of systems (sos)
considerations in life cycle stages of a system,” ISO/IEC/IEEE, Tech. Rep., 2019.
[19] A. Bicaku, C. Schmittner, P. Rottmann, M. Tauber, and J. Delsing, “Security safety
and organizationalstandard compliance in cyber physicalsystems,” Infocommunications Journal, vol. 11, no. 1, pp. 2–9, 2019.
[20] K. E. Hemsley, E. Fisher et al., “History of industrial control system cyber incidents,” Idaho National Lab.(INL), Idaho Falls, ID (United States), Tech. Rep.,
2018.
[21] J. Weiss, “Industrial control system (ics) cyber security for water and wastewater
systems,” in Securing Water and Wastewater Systems. Springer, 2014, pp. 87–105.
[22] M. J. Assante and R. M. Lee, “The industrial control system cyber kill chain,” SANS
Institute InfoSec Reading Room, vol. 1, 2015.
[23] A. Bicaku, M. Tauber, and J. Delsing, “Security standard compliance and continuous
verification for industrial internet of things,” International Journal of Distributed
Sensor Networks, vol. 16, no. 6, p. 1550147720922731, 2020.
[24] D. E. Denning, “Stuxnet: What has changed?” Future Internet, vol. 4, no. 3, pp.
672–687, 2012.
Bibliography
67
[25] B. Miller and D. Rowe, “A survey scada of and critical infrastructure incidents,”
in Proceedings of the 1st Annual conference on Research in information technology,
2012, pp. 51–56.
[26] D. E. Whitehead, K. Owens, D. Gammel, and J. Smith, “Ukraine cyber-induced
power outage: Analysis and practical mitigation strategies,” in 2017 70th Annual
Conference for Protective Relay Engineers (CPRE). IEEE, 2017, pp. 1–8.
[27] M. Mesbah and M. Azer, “Cyber threats and policies for industrial control systems,” in 2019 International Conference on Smart Applications, Communications
and Networking (SmartNets). IEEE, 2019, pp. 1–6.
[28] J.-P. Hauet, “Isa99/iec 62443: A solution to cybersecurity issues,” in ISA Automation Conference, 2012.
[29] E. Aroms et al., “Nist special publication 800-30 risk management guide for information technology systems,” 2012.
[30] H. Abdelkafi, R. Bolla, A. Rodriguez-Ascaso, M. Thuns, C. J. Lanting, and M. Wetterwald, “Understanding ict standardization: Principles and practice,” ETSI 2018.
[31] “App stores start to mature â 2016 year in review — app store insights from appfigures,”
[Online]. Available:https://blog.appfigures.com/
app-stores-start-to-mature-2016-year-in-review/, (Accessed on 07/10/2020).
[32] C. S. Wright, The IT regulatory and standards compliance handbook: How to survive
information systems audit and assessments. Elsevier, 2008.
[33] M. Ge, J. B. Hong, W. Guttmann, and D. S. Kim, “A framework for automating security analysis of the internet of things,” Journal of Network and Computer
Applications, vol. 83, pp. 12–27, 2017.
[34] N. Racz, E. Weippl, and A. Seufert, “A process model for integrated it governance,
risk, and compliance management,” in Proceedings of the Ninth Baltic Conference
on Databases and Information Systems (DB&IS 2010). Citeseer, 2010, pp. 155–170.
[35] N. S. Safa, R. Von Solms, and S. Furnell, “Information security policy compliance
model in organizations,” computers & security, vol. 56, pp. 70–82, 2016.
[36] N. R. Council et al., Academic careers for experimental computer scientists and
engineers. National Academies Press, 1994.
[37] P. J. Denning, “Acm president’s letter: performance analysis: experimental computer science as its best,” Communications of the ACM, vol. 24, no. 11, pp. 725–727,
1981.
68
Chapter VI
[38] E. Barker, D. Branstad, and M. Smid, “A profile for us federal cryptographic
key management systems (ckms),” National Institute of Standards and Technology,
Tech. Rep., 2015.
[39] IEC, “Ts 62443-1-1: 2009, terminology, concepts, and models,” 2009.
[40] IEC, “Tr 62443-1-2: 2018, master glossary of terms and definitions,” 2018.
[41] B. Guttman and E. Roback, “Nist special publication 800-12. an introduction to
computer security: The nist handbook,” NIST, Tech. Rep, vol. 800, pp. 800–12,
2011.
[42] F. P. D. Rocha, “Cybersecurity analysis of a scada system under current standards,
client requisites, and penetration testing,” 2019.
[43] “Definition of legacy application or system - gartner information technology glossary,” [Online]. Available: https://www.gartner.com/en/information-technology/
glossary/legacy-application-or-system, (Accessed on 08/06/2020).
[44] K. Bennett, “Legacy systems: Coping with success,” IEEE software, vol. 12, no. 1,
pp. 19–23, 1995.
[45] “Pager - wikipedia,” [Online]. vailable:https://en.wikipedia.org/wiki/Pager, (Accessed on 08/06/2020).
[46] R. C. Wu and D. M. Liebovitz, “Hospital-based cliniciansâ use of technology for patient care-related communication: a national survey,” Journal of Hospital Medicine,
vol. 12, no. 7, 2017.
[47] I. G. Cohen and M. M. Mello, “Hipaa and protecting health information in the 21st
century,” Jama, vol. 320, no. 3, pp. 231–232, 2018.
[48] S. Matthiesen and P. Bjørn, “Why replacing legacy systems is so hard in global
software development: An information infrastructure perspective,” in Proceedings
of the 18th ACM Conference on Computer Supported Cooperative Work & Social
Computing, 2015, pp. 876–890.
[49] N. Govindarajan, B. R. Ferrer, X. Xu, A. Nieto, and J. L. M. Lastra, “An approach
for integrating legacy systems in the manufacturing industry,” in 2016 IEEE 14th
International Conference on Industrial Informatics (INDIN). IEEE, 2016, pp. 683–
688.
[50] O. Givehchi, K. Landsdorf, P. Simoens, and A. W. Colombo, “Interoperability for
industrial cyber-physical systems: An approach for legacy systems,” IEEE Transactions on Industrial Informatics, vol. 13, no. 6, pp. 3370–3378, 2017.
Bibliography
69
[51] S. Tedeschi, D. Rodrigues, C. Emmanouilidis, J. Erkoyuncu, R. Roy, and A. Starr,
“A cost estimation approach for iot modular architectures implementation in legacy
systems,” Procedia Manufacturing, vol. 19, pp. 103–110, 2018.
[52] ISO/IEC, “27001 information technology - security techniques - information security
management systems - requirements,” ISO/IEC, Tech. Rep., 2013.
[53] G. Stoneburner, “Nist special publication 800-33, underlying technical models for
information technology security-recommendations of the national institute of standards and technology,” 2001.
[54] D. R. Kuhn, V. Hu, W. T. Polk, and S.-j. H. Chang, “Sp 800-32. introduction to
public key technology and the federal pki infrastructure,” 2001.
[55] S. Maksuti, A. Bicaku, M. Tauber, S. Palkovits-Rauter, S. Haas, and J. Delsing,
“Towards flexible and secure end-to-end communication in industry 4.0,” in 2017
IEEE 15th International Conference on Industrial Informatics (INDIN). IEEE,
2017, pp. 883–888.
[56] S. M. Bajikar, L. E. Girard, K. C. Silvester, and F. X. McKeen, “Method and system
and authenticating a user of a computer system that has a trusted platform module
(tpm),” Sep. 25 2007, uS Patent 7,275,263.
[57] I. Action, “Iso/iec jtc 1 n8010 2005-11-30,” 2005.
[58] E. A. Lee, “Cyber physical systems: Design challenges,” in 2008 11th IEEE International Symposium on Object and Component-Oriented Real-Time Distributed
Computing (ISORC), 2008, pp. 363–369.
[59] E. A. Lee, “Cyber physical systems: Design challenges,” in 2008 11th IEEE International Symposium on Object and Component-Oriented Real-Time Distributed
Computing (ISORC). IEEE, 2008, pp. 363–369.
[60] D. DeLaurentis, “Understanding transportation as a system-of-systems design problem,” in 43rd AIAA Aerospace Sciences Meeting and Exhibit, 2005, p. 123.
[61] Y. Hata, S. Kobashi, and H. Nakajima, “Human health care system of systems,”
IEEE Systems Journal, vol. 3, no. 2, pp. 231–238, 2009.
[62] W. Mathlouthi and N. B. B. Saoud, “Flexible composition of system of systems on
cloud federation,” in 2017 IEEE 5th International Conference on Future Internet of
Things and Cloud (FiCloud). IEEE, 2017, pp. 358–365.
[63] V. Chiprianov, L. Gallon, M. Munier, P. Aniorte, and V. Lalanne, “Challenges in
security engineering of systems-of-systems,” in Troisième Conférence en IngénieriE
du Logiciel, 2014, p. 143.
70
Chapter VI
[64] I. ISO, “Iso/iec 15288: Systems and software engineeringâsystem life cycle processes,” ISO, IEC, pp. 24 748–1, 2008.
[65] O. Carlsson, P. P. Pereira, J. Eliasson, J. Delsing, B. Ahmad, R. Harrison, and
O. Jansson, “Configuration service in cloud based automation systems,” in IECON
2016-42nd Annual Conference of the IEEE Industrial Electronics Society. IEEE,
2016, pp. 5238–5245.
[66] P. M. Mell and T. Grance, “Sp 800-145,” The NIST Definition of Cloud Computing,
National Institute of Standards & Technology, Gaithersburg, MD, 2011.
[67] C. Paniagua and J. Delsing, “Industrial frameworks for internet of things: A survey,”
IEEE Systems Journal, 2020.
[68] O. Carlsson, D. Vera, J. Delsing, B. Ahmad, and R. Harrison, “Plant descriptions
for engineering tool interoperability,” in 2016 IEEE 14th International Conference
on Industrial Informatics (INDIN). IEEE, 2016, pp. 730–735.
[69] P. Varga, F. Blomstedt, L. L. Ferreira, J. Eliasson, M. Johansson, J. Delsing, and
I. M. de Soria, “Making system of systems interoperable–the core components of the
arrowhead framework,” Journal of Network and Computer Applications, vol. 81, pp.
85–95, 2017.
[70] CENELEC, “Standards and your business. how your business can benefit from standards and participate in standardization activities,” 2013.
[71] E. Union, “Regulation (eu) no 1025/2012 of the european parliament and of the
council of 25 october 2012 on european standardisation, amending council directives
89/686/eec and 93/15/eec and directives 94/9/ec, 94/25/ec, 95/16/ec, 97/23/ec,
98/34/ec, 2004/22/ec, 2007/23/ec, 2009/23/ec and 2009/105/ec of the european
parliament and of the council and repealing council decision 87/95/eec and decision
no 1673/2006/ec of the european parliament and of the council,” 2012.
[72] K. Krechmer, “Technical standards: Foundations of the future,” StandardView,
vol. 4, no. 1, pp. 4–8, 1996.
[73] CENELEC, “Principles and rules for the structure and drafting of cen and cenelec
documents,” 2019.
[74] E. Marszal and J. McGlone, “Security pha review for consequence-based cybersecurity,” International Society of Automation (ISA), 2019.
[75] “Maritime
security
perspectives
for
a
comprehensive
approach,”
[Online].
Available:
https://www.missionsecure.com/
maritime-security-perspectives-for-a-comprehensive-approach,
(Accessed
on
09/06/2020).
Bibliography
71
[76] IEC, “62443-2-1: 2009, providing an industrial automation and control systems
security program,” 2009.
[77] IEC, “Tr 62443-2-3: 2015, patch management in the industrial automation and
control system environment,” 2015.
[78] IEC, “Amd 62443-2-4: 2017, security program requirements for industrial automation and control systems service providers.”
[79] IEC, “Tr 62443-3-1: 2009, security technologies for industrial automation and control
systems,” 2009.
[80] IEC, “62443-3-2: 2018, security risk assessment for system design,” 2018.
[81] IEC, “62443-3-3: 2013, system security requirements and security levels,” 2013.
[82] IEC, “62443-4-1: 2018, – secure product development lifecycle requirements,” 2018.
[83] IEC, “62443-4-2: 2019, technical security requirements for iacs components,” 2019.
[84] “Cyrail recommendations on cybersecurity of rail signalling and communication systems - google search,” [Online]. Available: https://www.google.com/
search?q=CYRail+Recommendations+on+cybersecurity+of+rail+signalling+
and+communication+systems&rlz=1C1GCEU enDE906DE906&oq=CYRail+
Recommendations+on+cybersecurity+of+rail+signalling+and+communication+
systems&aqs=chrome..69i57j69i60.365j0j7&sourceid=chrome&ie=UTF-8,
(Accessed on 09/06/2020).
[85] ISO, “Iec 15408-1: 2009 information technologyâsecurity techniquesâevaluation criteria for it securityâpart 1: Introduction and general model,” Geneva: IEC, 2009.
[86] ISA, “62443-2-2: 2018,iacs security program rating (draft),” 2018.
[87] M. Gergeleit, H. Trsek, T. Eisert, and M. Ehrlich, “Modeling security requirements
and controls for an automated deployment of industrial it systems,” in Kommunikation und Bildverarbeitung in der Automation. Springer Vieweg, Berlin, Heidelberg,
2020, pp. 217–231.
[88] “What is the isa/iec 62443 framework?” [Online]. Available: https://www.tripwire.
com/state-of-security/regulatory-compliance/isa-iec-62443-framework/.
[89] “D1.1 regulative baseline,” [Online]. Available:https://certmils.eu/downloads/
certMILS-D1.1-RegulativeBaseline-PU-M06.pdf, month = , year = , note = (Accessed on 09/06/2020).
[90] M. J. Saylor, A. Slavin, and J.-P. H. Martin, “System and method for monitoring
security systems by using video images,” Jun. 4 2002, uS Patent 6,400,265.
72
Chapter VI
[91] D. Ki-Aries, S. Faily, H. Dogan, and C. Williams, “Assessing system of systems security risk and requirements with oasosis,” in 2018 IEEE 5th International Workshop
on Evolving Security & Privacy Requirements Engineering (ESPRE). IEEE, 2018,
pp. 14–20.
[92] D. J. Bodeau and C. D. McCollum, “System-of-systems threat model,” The Homeland Security Systems Engineering and Development Institute (HSSEDI) MITRE:
Bedford, MA, USA, 2018.
[93] P. Nejib, D. Beyer, and E. Yakabovicz, “Systems security engineering: what every
system engineer needs to know,” in INCOSE International Symposium, vol. 27, no. 1.
Wiley Online Library, 2017, pp. 434–445.
[94] A. Bicaku, S. Balaban, M. G. Tauber, A. Hudic, A. Mauthe, and D. Hutchison,
“Harmonized monitoring for high assurance clouds,” in 2016 IEEE International
Conference on Cloud Engineering Workshop (IC2EW). IEEE, 2016, pp. 118–123.
Department of Computer Science, Electrical and Space Engineering
Division of EISLAB
ISSN 1402-1544
ISBN 978-91-7790-632-2 (print)
ISBN 978-91-7790-633-9 (pdf)
Luleå University of Technology 2020