Iot m5

Chapter 5
Industrial Internet of Things
5.1 Introduction
The Internet of Things (IoT) has already brought a revolution to our understanding
of applications in a wide range of human activity. This trend is expected to increase
in the near future, as the potential economic impact of IoT is expected to be between
900 billion USD and 2.3 trillion USD on a yearly basis up to 2025 [Man13]. IoT
applications are spreading to various sectors including smart energy, manufactur-
ing, agriculture, health, security and safety, smart cities, smart buildings, and smart
environment. All these application areas repeat the same basic model: a large num-
ber of smart devices, interconnected over wired or wireless media, interacting and
coordinating to achieve a goal.
In the industrial environment, the effort for smart factories [Zue10], the Industrie
4.0 strategy [Ind14], the Industrial Internet [GE17], and the European initiative for
the Factories of the Future [FoF] have initiated the adoption of IoT in industry with
the goals of increasing flexibility and productivity, while reducing production cost.
The developing concept is the Industrial IoT (IIoT).
The Industrial Internet of Things is part of the general IoT evolution. However, it
faces challenges that are unique and differentiate it from the other systems and ser-
vices of IoT due to the need to integrate programmable logic controllers (PLC) and
supervisory control and data acquisition systems (SCADA). PLC and SCADA sys-
tems, together with the related industrial networks that interconnect them, constitute
the infrastructure of operational technology (OT), which has traditionally evolved
independently from the typical IT technology, because it addresses the needs of
systems in the field – industrial floor, energy production facilities, energy distribu-
tion networks, etc. – with strong requirements such as continuous operation, safety,
real-time operation, etc. The capabilities offered by the emerging IIoT technology
pose challenges for the integration of these OT systems with the traditional enter-
prise IT systems at many levels, from enterprise management to cyber security. For
example, enterprise resource planning systems (ERP) need to be expanded to
© Springer International Publishing AG 2018 37

D. Serpanos, M. Wolf, Internet-of-Things (IoT) Systems,
https://doi.org/10.1007/978-3-319-69715-4_5
38 5 Industrial Internet of Things
include manufacturing operations, which are managed currently by manufacturing

execution systems (MES) that have grown independently and present significant
interoperability challenges to their integration. Clearly, an integrated system that
manages the complete enterprise/factory hierarchy, from business processes to sen-
sors, provides significant flexibility and presents new opportunities to enterprises.
Industrial technology is not part only of manufacturing or factories. The maturity
of the technology and its cyber-physical control capabilities has spread its use out-
side traditional factory environments, and now they constitute a significant part of
the critical infrastructure at many fronts. Energy production and distribution infra-
structure includes OT systems, which are the indispensable infrastructure on which
modern smart grids are built. Actually, the energy sector is a high priority in the
evolution of IIoT, not only because there is increasing need to consumers for energy,
especially in light of the population growth, but also because energy management is
a critical factor in the industrial sector and the desired low-cost production of goods
and services. In addition to the energy sector, industrial systems are widespread in
many other sectors of critical infrastructure, such as water management and
transportation.
The interoperability challenges to the convergence of IT and OT are only a part
of the challenges in the emerging IIoT. Appropriate architectures need to be devel-
oped to build and manage effective IIoT systems, technologies for the design and
management of cyber-physical systems, sensors and networks need to be devel-
oped, and, importantly, safety and security need to be addressed in a unified way in
the context of IIoT. Safety and security are significant challenges, because, tradi-
tionally, security has been a concern in the IT sector, while safety has been the major
concern in the OT sector. Bringing the two together has brought the realization that
safety cannot be achieved without security, while, at the same time, security needs
to include technologies that combine dependability and meet strong requirements
for real time and low power in many application domains. Although the security
issues of industrial control systems have attracted attention in the last decade and
standards have been evolving at a much faster pace than in the past, e.g., the ISO/
IEC 27000 and the ISA/IEC 62443 families of standards [IEC16, ISA16], there are
still significant challenges at the technology, architecture, and management fronts to
obtain solutions for the unified IIoT.
In this chapter, we present the concepts and evolution of the IIoT starting from
the Industrie 4.0 strategy and proceeding to the Industrial Internet. We describe the
IIoT reference architectures as they evolve from the ITU effort to the Industrial
Internet Consortium. Finally, we describe some representative challenges in the
evolution and implementation of IIoT focusing on the energy sector. As security and
safety constitute a significant challenge in IIoT as well as in IoT, in general, we
focus on this challenge in the following chapter.
5.2 Industrie 4.0 39
5.2 Industrie 4.0
Industrie 4.0 is a strategic initiative in Germany that targets to bring IoT technolo-
gies to the manufacturing and production sectors [Ind14].The goal is to enable
Germany to keep a leading role in manufacturing achieving efficient and low-cost
production with flexible workflows. The means to achieve this goal is the wide-
spread inclusion of cyber-physical systems in the manufacturing and production
processes, in order to insert intelligence in the systems and processes, to enable their
high connectivity and communication, and to achieve their coordination into more
complex but flexible processes that lead to high-quality, low-cost products.
Industrie 4.0 takes its name from the identification of the new, emerging industry
as the fourth revolution of industrial production. It is widely accepted that industrial
production to date has gone through three (3) revolutions. The first industrial revolu-
tion, between the eighteenth and nineteenth century, is the one where mechanized
production facilities were introduced in the production of goods and services, where
the required energy was provided by water and steam. Electrical energy was intro-
duced during the second revolution, which led to mass production, as electricity
boosted productivity. In the post WWII era, the inclusion of electronics and soft-
ware, i.e., industrial information technology, to the mechanical and electrical com-
ponents led to the third revolution that enabled automation at high levels. Currently,
many industrial stakeholders believe that we are at the verge of the next, the fourth,
industrial revolution, through wide adoption and use of cyber-physical systems that
leads not only to even higher levels of automation but enables mass customized
manufacturing and production of goods and services, due to the flexibility offered
by the easily programmable, configurable, and controllable manufacturing lines.
The effort for Industrie 4.0 is based on the widespread deployment and use of
computational and communication resources. The last two decades have been char-
acterized by significant advances in high performance, low-power processors, mem-
ories, and communication components that enable efficient processing and
networking. These advances have brought significant processing capabilities to a
large number of devices that are deployed to consumers or to the field. Smart con-
sumer devices have become norm. Smartphones provide hundreds of applications
and enable services ranging from identifying travel and transportation routes to
mobile banking and health monitoring. Smart televisions combine and provide vari-
ous types of entertainment and network services, from customized TV channel con-
trol and management to Internet gaming and home device management. Smart
home appliances monitor parameters, from environmental temperatures to water
and energy consumption, enabling citizens to manage their homes efficiently and
effectively leading to the required living quality while reducing operational cost at
various fronts.
The large basis of computational resources and connectivity becomes apparent
by the published numbers of embedded processors and components that are cur-
rently produced. According to [Ind14], the vast majority of produced processors,
approximately 98%, are deployed in embedded systems. Deployed semiconductor
memory is also growing and expected to grow at 40% year over year in 2017
[Mic17]. Furthermore, the significant advances of wired and wireless networks in
the last two decades have led to ubiquitous connectivity, approaching 100% in cities
and towns, through different technologies.
The available processing and communication basis leads to an evolving hierar-
chy of embedded systems and services up to the level of the Internet of Things,
Data, and Services. Examples of this evolution can be identified at several applica-
tion areas. In transportation, for example, embedded systems are widespread con-
trolling functions from car entertainment systems to car seat control. At this level,
embedded processors are programmed to control specific, individual parameters,
e.g., height and movement in car seats, based on user commands. However, embed-
ded systems in cars are also networked, either within the car system or with the
environment, providing networked embedded services; automatic toll payment is
one of them where embedded systems in the car and the toll booths communicate
with each other, in order to complete the electronic payment transaction of the toll
passage. Such payment systems from several tolls, for example, can be further com-
bined in a distributed system that enables traffic and toll management at a wider
scale, leading to more effective transportation infrastructure that achieves lower
waiting times and fuel costs for travelers as well as lower operational cost and, thus,
higher income to transportation management authorities. One can even envision an
even higher level of connectivity of such complex transportation systems to smart
cities that combine transportation management with additional services, such as
energy distribution, civil services, emergency services, etc., as required at different
times, locations, and during special events.
The advances of sensor technologies, in addition to the evolution of embedded
systems and communication networks, make all these scenarios realistic.
Importantly, sensors bridge the gap between the physical world and the digital
world, providing increasingly rich information to digital systems and enabling intel-
ligent control of systems and processes. In that respect, manufacturing and indus-
trial automation has been traditionally employing IT technologies with sensors and
electromechanical systems, leading the development and deployment of technolo-
gies and concepts for intelligent control, systems, and services. Thus, the develop-
ment of the Industrie 4.0 strategy and the related initiatives comes as a natural
evolution step of industrial technologies influencing and being influenced by the
advancement of consumer technologies of the Internet of Things.
The smart factory concept embodies the goals of the Industrie 4.0 strategy to a
large degree. The concept is based on the hierarchy of cyber-physical systems men-
tioned above, where smart production systems are interconnected in a multilevel
hierarchy to achieve a high degree of automation, targeting flexibility, efficiency,
autonomy, resilience, safety, and low cost. Smart machines will be interconnected
to establish smart plants, which, in turn, will be combined to provide smart facto-
ries. Considering the typical components of manufacturing process, smart factories
are targeted to automate efficiently all components and stages. Materials and
resources will be managed and introduced in the process efficiently; production
processing will be managed in real time minimizing the used resources for the
5.3 Industrial Internet of Things (IIoT) 41
p roducts and the operations, while reconfiguration and reorganization of production

processes and customization of products will be feasible in real time and with safety
for infrastructure and operators, minimizing environmental impact. Customers will
be able to monitor the progress of the development of ordered products, while man-
ufacturers will be optimizing their logistics chains.
5.3 Industrial Internet of Things (IIoT)
The Industrial Internet of Things (IIoT) has emerged as a general concept of the
application of the Internet of Things to the industrial sector. Effectively, it is a gen-
eralization of Industrie 4.0, which appears to focus more on industrial process effi-
ciency. The IIoT vision includes all aspects of industrial operations, focusing not
only on process efficiency but also on asset management, maintenance, etc.
Considering that IIoT is effectively IoT in the industrial sector and that the
Industrie 4.0 concepts are effectively a subset of IIot, as shown in Fig. 5.1, one
needs to identify the difference between IoT and IIoT. Although the basic concepts
are the same, i.e., interconnected smart devices that enable remote sensing, data col-
lection, processing, monitoring, and control, the parameters that identify the IIoT
subset of IoT are the strong requirements for continuous operation and safety as
well as the operational technology employed in the industrial sector. As an example,
one can consider the difference between a consumer service such as a health moni-
toring application on a smart watch and an industrial service such as the monitoring
of a steam pump. Although both applications collect real-time data, e.g., steps or
body temperature in the health application case and pressure or steam volume in the
steam pump case, transmit the data, identify events, and provide feedback or com-
mands to operators/consumers and subsystems, clearly, continuous operation and
safety place stricter requirements in the steam pump case, where the potential effect
of a failure is significantly more catastrophic and may lead to costly operation down
time and even human injuries or loss of life.
These characteristics of the industrial sector – technology and requirements –
lead to specialized, demanding solutions for technology and services, justifying the
focus of the industrial sector on a specialized IoT concept. This has resulted to the
strong interest of the industrial sector in the development of specialized concepts,
from strategy to application and technology. The conventional business develop-
ment models that include numerous interdependencies between stakeholders, from
supply chains to service promotion, lead also to a strong need for interoperable
solutions at many levels, from the device level to services. Thus, there is need for
coordinated activities in the evolution to IIoT, which is addressed by consortia, such
as the Industrial Internet Consortium [IIC14] that provides significant leadership in
this emerging field.
The General Electric company introduced the term Industrial Internet in 2012,
as a leader of the Industrial Internet of Things, identifying also the technologies of
machine-to-machine communication, SCADA, HMI, industrial data analytics, and
Fig. 5.1 IoT, IIoT, and

Industrie 4.0 relationship
IoT IIoT Industrie 4.0
cybersecurity as the main constituents of the IIoT vision [GE17]. Interestingly, they
also calculate the impact of the Industrial Internet to 46% of the global economy,
while in the energy sector they calculate an impact of 100% on energy production
and 44% on energy consumption globally [GE17].
5.4 IIoT Architecture
The development and deployment of IIoT systems and services require the develop-
ment of architectures that enable efficient and effective operations as well as interop-
erability considering the anticipated end-to-end services and the large number of
stakeholders involved for devices, cyber-physical systems, communication systems
and networks, service providers, and business developers. Thus, significant effort is
being spent to develop standards and reference architectures that will be accepted
and adopted by the various stakeholders. The International Telecommunication
Union (ITU) has addressed this issue, publishing in 2012 the ITU-T Y.2060 recom-
mendation, which introduces a reference architecture for IoT, in general, including
explicitly applications that fall in the context of IIoT, such as smart grid, intelligent
transportation systems, e-health, etc. [ITU12]. The Industrial Internet Consortium
(IIC) has also been working on a reference architecture for IIoT and currently has
published Version 1.7 of the Industrial Internet Reference Architecture [IIC17].
This architecture is an elaborated reference architecture, significantly more detailed
than the ITU one, addressing all important aspects to all categories of stakeholders.
Taking into account the details of both reference models, one can consider the IIC
model as a specialized evolution of the ITU model, addressing in more details the
important issues of IIoT relatively to the more generic ITU reference model that
encapsulates the requirements for the general IoT.
The ITU effort has expanded the communications’ vision to include communica-
tion of “anything” to the communication concepts of “any time” and “any place.”
Importantly, it includes all expected applications, including industrial ones, specifi-
cally mentioning smart grids and intelligent transport systems among others. As
“things,” ITU considers physical and virtual objects that are identifiable and able to
5.4 IIoT Architecture 43
T
T
Communication over CN without Gateway
T
Communication Network
(CN)
Direct communication
T G
Communication over CN through Gateway
Fig. 5.2 Communication methods for IoT devices
connect to communication networks, while they have related information that is

either static or dynamic. Importantly, since communication is a critical part of the
whole IoT concept, physical things need to be attached to “devices” that are con-
nected to networks, so that any analog information can be converted to digital and
transmitted through the networks. Devices can be simply data-carrying communi-
cating and storing data, data-capturing interacting with the physical objects through
reader and writers, sensing and actuating devices, or general-purpose devices with
embedded processing and communication resources, such as machines, appliances,
and consumer electronic products.
An important issue in the ITU reference model is the communication model
among devices. As Fig. 5.2 indicates, the model considers three methods of com-
munication, based on the employment of gateways (G) and the use of the commu-
nication network (CN). Devices can communicate without the use of gateways,
directly, over local networks, and/or over the communication network, or they can
communicate over the communication network exploiting gateways.
The ITU model accommodates fundamental characteristics of IoT that are iden-
tified. These fundamental characteristics are interconnectivity, scale, heterogeneity,
services for things and the dynamic nature of device information, and connectivity.
Interconnectivity is a significant characteristic because “anything” can connect to
the global network for any application. As the number of connected devices increases
dramatically, scaling becomes a significant parameter that needs to be addressed at
all levels of IoT and IIoT; the scaling issue relates not only to communication end
points and number of devices but to the size of produced and communicated data as
well as their management in terms of storage and processing. The dynamic nature
of devices, which turns on and off dynamically or connect and disconnect to net-
works, will make the landscape more complex and demanding. The open nature of
(I)IoT and the large number of stakeholders, in addition to the flexible and long
Fig. 5.3 IoT reference

Application Layer
model by ITU
Management
Service support and Application support Layer
Security
Network Layer
Device Layer
supply chains in conventional service provisioning, leads to the need to accommo-

date heterogeneous “things,” devices, platforms, and services. Services for things
also need to be addressed appropriately, not only because of the limited resources of
many “things” but also because of the requirements of several services for security
and safety, including privacy protection and safe actuation that avoids problems and
accidents.
The fundamental characteristics of (I)IoT lead to requirements that need to be
met by the reference architecture. The main requirements mentioned by ITU include
interoperability, identification-based connectivity, autonomy in networking and ser-
vices, accommodation of location-based services, security and privacy, as well as
capabilities for management of things and services, including plug and play.
Figure 5.3 depicts the ITU IoT reference model, which has been introduced to
meet the above requirements. It is a typical layered model with four hierarchical
layers, specifically device, network, application and service support and finally
application layer, and two vertical layers that are crosscutting the four hierarchical
layers, defining management and security functions and properties to all hierarchi-
cal layers.
The device layer, the lowest in the hierarchy, includes the functionality of devices
and communication gateways. Considering the main interest of ITU in communica-
tions, the layer describes communication-centered functionality for the devices: (a)
devices that transmit and receive information over the communication network
directly, i.e., without using any gateway, (b) devices that communicate information
(transmitting and receiving) through gateways, (c) devices that communicate
directly without the use of the communication network but being able to communi-
cate over local networks or to form ad hoc networks, and (d) devices that are able to
selectively turn on and off functionality in order to save operating power. In regard
to gateways, the device layer includes all relevant communication technologies,
wired and wireless, such as CAN bus, Wi-Fi, Bluetooth, Zigbee, etc. Importantly,
the device layer includes protocol conversion, because devices may implement dif-
ferent protocols, and, thus, needs protocol conversion for interoperability.
The network layer provides encapsulation of device data and related protocol
conversion to network layer protocols. The layer includes functionality for the net-
work and transport layers in the OSI protocol reference model. For networking, they
include control functionality for network connectivity, mobility, authentication,

authorization, and accounting, while for transport they anticipate user traffic trans-
port as well as the transport of control and management information for (I)IoT ser-
vice and applications.
The service support and application support layer includes both generic and ser-
vice/application-specific functionality (capabilities) that enable (I)IoT applications
and services. Considering the distributed nature of (I)IoT services and applications,
there exists generic functionality, such as data processing and storage, as well as
specialized functionality, per application and service, since emerging services have
different requirements, for example, smart grid operation places different privacy
requirements than an intelligent toll management system for transportation
services.
Finally, the application layer, the highest hierarchical layer, includes the (I)IoT
applications and services.
The management vertical, crosscutting layer includes both generic and applica-
tion domain-specific functionality. The generic one refers to the typical manage-
ment for configuration, topology, resource, performance, fault, security, and account
management. The application-specific one refers to functions that meet application
requirements, such as smart meter monitoring in smart grids.
Analogously to the management layer, the security vertical, crosscutting layer
includes both generic and application domain-specific functionality. The generic
functionality refers typically to functions related to authorization, authentication,
integrity and confidentiality at all layers, privacy at the application layer, secure
routing at the network layer, access control at all layers, etc. Application-specific
functionality refers to meeting application-specific requirements.
The ITU reference model document presents also a set of business models for
IoT, considering the large number of stakeholders in the area and their different
interests and goals. Importantly, these business models are developed based on the
view of network operators. The business models are based on five main business
roles that the stakeholders may have: (a) device provider, (b) network provider, (c)
platform provider, (d) application provider, and (e) application customer. As the
terms indicate, device providers are the stakeholders that provide devices for (I)IoT,
and network providers provide network systems, gateways, and connectivity for the
(I)IoT. Platform providers provide the unified, distributed IT platform with well-
defined interfaces, over which an application can be served end to end, while appli-
cation providers are the ones who provide the (I)IoT service over the platform,
networks, and devices provided by the corresponding providers. Apparently, the
application customer is the user of the (I)IoT application or service.
Based on these five business roles, ITU identifies five business models depend-
ing on the number of operators that are involved in an application and their specific
roles. Figure 5.4 shows these five models (Models 1–5), presenting the business
roles as stacked boxes – analogously to the vertical layer model – and indicating
operators with different fill patterns in the boxes; boxes (roles) with the same fill
pattern in a stack indicate that the same organization is the operator of these boxes.
In Model 1, for example, the same organization has the roles of device, network,
Application Application Application Application Application

customer customer customer customer customer
Application Application Application Application Application

provider provider provider provider provider
Platform Platform Platform Platform Platform

Network Network Network Network Network

Device Device Device Device Device

Model 1 Model 2 Model 3 Model 4 Model 5
Operator A Operator A Operator C
Fig. 5.4 IoT business models identified by ITU
platform, and application provider, while, in Model 2, one stakeholder has the roles
of device, network, and platform provider and another one has the role of the appli-
cation provider.
The Industrial Internet Consortium (IIC) focuses on similar concepts and devel-
ops a reference IIoT architecture that has several similarities with the ITU approach
and reference model. Clearly, the IIC approach to the architecture development
addresses the interests and concerns of all types of stakeholders in an integrated
way, originating from use cases and focusing on complete business models and
applications at all levels, from devices to IIoT services. IIC follows the approach
that different stakeholders who need to make different decisions have architectural
viewpoints that are at different levels of abstraction. These viewpoints enable stake-
holders to focus on the parameters of interest and develop appropriate architectures
that achieve their goals and address the problems they have identified. For this pur-
pose, IIC has identified four different viewpoints: (a) business, (b) usage, (c) func-
tional, and (d) implementation.
The business viewpoint addresses the concerns of business stakeholders, who
define and specify IIoT systems and services in their organizations or for customers.
These concerns, such as return on investment, cost of maintenance, and similar, are
addressed through a model that enables the definition of visions and values which
are translated to key objectives and then to high-level specifications of business
tasks, named fundamental capabilities. The stakeholders involved include business
developers as well as system engineers and product managers.
The usage viewpoint describes how the system is used, implementing the key
objectives and the capabilities that have been specified through the business view-
point. The viewpoint is described with a model that identifies the system and its
activities, the involved parties – humans or machines – and their roles, and, finally,
tasks, i.e., actions that are executed by parties with a specific role. As tasks are the
actions in the system, they are precisely specified and described per role with, so
called, functional and implementation maps that specify the exact functions and
implementation subsystems that are necessary for a task’s complete execution. The
stakeholders involved in the usage view include not only the systems engineers and
the product managers of the related employed products but all stakeholders that are
involved in IIoT system and service specification, including the end users.
The functional viewpoint presents the functional architecture of the IIoT system,
describing its components, dependencies, and coordination, meeting the require-
ments and specifications that have been developed through the usage viewpoint. The
stakeholders involved in this viewpoint are system and subsystem developers, prod-
uct developers, and managers as well as system integrators.
Considering the focus of IIC on IIoT and the increasing adoption of industrial
control systems (ICS) within the industries of several sectors and in the operation
and management of critical infrastructure, the IIC reference model focuses on its
functional architecture of IIoT systems on the integration of ICS with classical
information technology (IT) systems in a unified, effective model that meets the
requirements of all stakeholders – as specified in the business and usage view-
points – and enables their effective decisions. The inclusion of ICS and IT in a uni-
fied model presents several challenges. Industrial control systems, the systems of
Operational Technology (OT), have been developed following a different evolution
path from typical IT systems, because of their goals and requirements that typically
include continuous operation, safety, and real-time constraints; OT systems have
been mostly developed and owned by control and operations engineers, they employ
different technologies for processing, communications, and interfaces because they
interface directly with the environment through sensors and actuators, and they are
managed by their owners independently, since they are typically part of demanding
systems and services in terms of dependability, continuous operation, real time, and
safety. As a result, their technologies, practices, and standards have evolved inde-
pendently from the ones for IT. However, the increasing capabilities offered by
advanced sensors and actuators, processors, and memories have enabled ICS to
execute highly complex operations that have been developed for complex IT sys-
tems, such as high-volume data collection and analysis, multivariable modeling and
optimization, etc. Importantly, at the same time, the increased capabilities and the
increasing complexity of ICS have led them to be more vulnerable to failures and
cyber-attacks, leading to additional functional requirements for their correct and
efficient operation.
In order to address the integration of IT and OT in a unified model, the IIC
approach to the reference architecture divides IIoT systems in five domains, each
one grouping the functionality required for a logically distinct high-level operation
of the system. These five domains are (a) control, (b) operations, (c) information,
(d) application, and (e) business. Figure 5.5, from [IIC17], illustrates the decompo-
sition of the functional representation of an IIoT system into the five domains and
Business
Control flow
Data flow
Information
Application
Operations
Control
Sense Actuate
Physical system
Fig. 5.5 The IIC reference architecture functional domains
shows the data and control flow among the domains, as specified by IIC. The control
domain effectively represents the control loop realized by industrial control sys-
tems, i.e., it contains the sensors, the logic, and the actuation that constitute a plant
implemented by one or more industrial control systems. The operations domain
includes the functions that are required for the operation of the industrial control
systems in the control domain; the operation includes system monitoring and man-
agement as well as optimization for the efficient operation of the systems, especially
considering the requirements of several application domains for continuous opera-
tion, meeting real-time requirements, and achievement of low-power objectives.
The information domain is responsible for collecting data from all domains and
analyzing them to enable high-level decisions for the system, e.g., coordinating and
optimizing the end-to-end operation of several industrial control systems in the con-
trol domain. The application domain includes functionality that is application-
dependent and effectively includes the models and operation rules of the application
at hand; an important part of this domain is the set of APIs and user interfaces so that
other applications or human users can use the application effectively. Finally, the
business domain includes systems and functions that enable management and deci-
sion making at the business level, e.g., with enterprise resource planning systems
(ERP), manufacturing execution systems (MES), etc.
5.5 Basic Technologies 49
It is important to note that the IIC approach is centered around the concept of a
control plant, i.e., it addresses all viewpoints around a control loop that implements
a plant. Since control loops can be simple, with one system, or complex with mul-
tiple systems typically organized in a hierarchy, the IIC functional domain decom-
position can be applied at all levels of a hierarchy. Thus, the decomposition of an
IIoT system in the domains does not represent a layered approach as the ITU
approach, but rather a logical functional decomposition within a layer or across lay-
ers in a hierarchy. Because of this, the IIC reference architecture identifies “cross-
cutting functions” that are effectively hierarchical (or layered) IT infrastructure
functions necessary for the development of a complete IIoT application. These
functions include connectivity, distributed data management, analytics, intelligent
and resilient control, and any other application function that is necessary for the
specific application domain or use case. For example, connectivity has to be imple-
mented in a hierarchical fashion, following standards and practices, interconnecting
components within an industrial control system or across several such systems,
where each system can be viewed as a collection of functions from all five specified
domains. Observing the crosscutting functions mentioned, one can realize that they
effectively constitute a layered architecture analogous to the one by ITU. In that
respect, one can consider the IIC approach and the ITU approach as complementary,
with the IIC reference architecture being a generalization of the ITU one, since it
includes crosscutting functions analogous to the ITU layers, while it enables the
development of more detailed functional models per layer addressing complete con-
trol loops and providing support to all types of stakeholders – from device designers
to business developers – for effective decision making.
This analogy and complementarity becomes more apparent with the implemen-
tation viewpoint, which addresses the implementation details of the functional
viewpoint developed for an IIoT system. The implementation viewpoint includes all
the necessary technical and technological details that are necessary for the imple-
mentation of a complete IIoT system and its application, including system function-
ality, technological requirements, communication and network protocols, all types
of interfaces, and a mapping of the functional blocks that are specified in the func-
tional viewpoint onto typical implementation architectures, such as the three-tier
architecture (where the three tiers are the edge, platform, and enterprise) and the
layered databus architecture.
5.5 Basic Technologies
The basic technologies that enable the evolution of IIoT are the sensors, cyber-
physical systems, and the related communications and networking technologies that
enable their connectivity, among them or to other systems, including enterprise net-
works. As basic technologies, we designate the ones that are all common to all
application domains and use cases.
A fundamental technology for IIoT, and IoT in general, is the technology of

RFID (radio-frequency identification) which enables the transmission of a micro-
chip’s identification information to a reader over wireless media. It is one of the first
technologies that enabled and supported the IoT concept, because RFID technology
enabled the automatic identification, monitoring, and operation execution related to
RFID-equipped tags. For this reason, RFID technology spread widely since the
1980s in the applications for logistics and supply chain management [Fuq15].
Wireless sensor networks (WSN) constitute another fundamental technology for
IIoT, considering their widespread employment in industrial automation and their
increasing deployment in critical infrastructures. The solutions for effective WSNs
need to address a large number of issues, ranging from communication reliability
and real-time requirements to low-power communication due to the deployment of
a large number of battery-operated sensors in the field. The significant advances in
the area have resulted to a large number of potential solutions and standards for reli-
able and efficient communication in various environments, e.g., WLAN, Zigbee
[Zig], Bluetooth [Blu], 6LoWPAN [Mon07, Hui11, She12], etc. Importantly, they
have led to the development of smart (intelligent) sensors, even ones that are auton-
omous and do not need recharging [Eno].
In addition to the low-level communication protocols that are necessary for con-
nectivity, additional, higher-level protocols are necessary to support distributed
computing operations and IIoT applications. Such protocols include service discov-
ery, e.g., multicast DNS (mDNS) [Che13], as well as application protocols that are
suitable for the various IIoT application domains such as Constrained Application
Protocol (CoAP) [She14], Message Queue Telemetry Transport (MQTT) [Mqt16],
and Advanced Message Queuing Protocol (AMQP) [Amq14].
5.6 Applications and Challenges
IIoT applications span a wide range of IoT application domains. Operational tech-
nology (OT) systems have become the basic computation platform for the operation
and management of most critical infrastructure. The high processing and storage
capacity of PLCs, their ability to manage real-time applications with high availabil-
ity, and their easy management by available SCADA systems have made them quite
popular as building blocks of large infrastructures beyond the manufacturing floor,
for which they were originally introduced. Today, a large portion of infrastructure is
based on industrial control systems (ICS) and makes this critical infrastructure a
potential provider of IIoT services and user of IIoT technology. The energy sector is
probably the most demanding one on the use of ICS, since the production and pro-
cessing of energy is part of a country’s heavy industry and thus, naturally, includes
large ICS platforms. In addition, ICS are used heavily in power distribution net-
works, such as the electricity network. Considering the emerging smart grids that
provide monitoring devices, i.e., PLC-like systems, to customers, it becomes appar-
ent that ICS are the main computing infrastructure in power systems end to end,
from production to consumption.
5.6 Applications and Challenges 51
A large number of distribution networks follows this ICS-based model of opera-

tion, including water distribution and management networks and water processing
sites. Importantly, oil and gas distribution networks use this technology managing
pipelines and storage tanks as well as the overall network’s operation. Transportation
also presents a significant area of application, where ICS and other cyber-physical
systems are used for traffic management, i.e., operation and management of traffic
lights, for toll payment, etc.
All these application areas of IIoT will require additional deployment and adop-
tion of components, especially cyber-physical and ICS in particular, in order to
provide the envisioned services at a large enough scale to improve the lives of citi-
zens significantly. The IIoT revolution is still at its beginning. In this evolution
process, the sectors that currently depend on ICS technology will be the forerunners
of IIoT technology and will provide the leadership in IIoT development. Currently,
the power sector and especially the electricity production, distribution, and con-
sumption processes are the most mature ones, having large bases of ICS at most
stages of the service provisioning infrastructure. Despite its maturity, the sector
presents quite challenging problems for its next generations. We present some of
these challenges here, as a sample illustration of the continuous challenges that need
to be resolved in the path to IIoT. Analogous problems exist in other IIoT applica-
tion areas as well, but the scope of our presentation is to illustrate directions and not
to enumerate problems in all application domains.
Stability and continuous operation of the power production and distribution sys-
tems constitutes a critical requirement for the development of modern economies.
Monitoring the state of the power grid system is a challenging process that is fea-
sible through advanced techniques for fault diagnosis and identification. In this
direction and considering the advances in smart grids, we need more advanced tech-
niques for fault detection and isolation in environments with distributed, intercon-
nected power generators. Detection methods based on χ2 distribution statistics
enable one to identify, with a high degree of confidence, whether the grid operates
well or if there is a fault; furthermore, fault localization and isolation can be achieved
by applying such techniques in segments of the grid. Conventional methods for
distributed fault diagnosis are limited though, because they do not address the non-
linear dynamics of the grid’s behavior, using either algebraic methods that do not
address the dynamics or sets of linear differential equations that do not address the
nonlinear characteristics. Currently, there is significant effort to develop methods
for distributed fault diagnosis taking into account the nonlinear dynamics, focusing
on nonlinear modeling, nonlinear state estimation, nonparametric state estimation,
development for statistical criteria for fault diagnosis and isolation as well as observ-
ability, and diagnosis with distributed sensor networks in the power grid [Rig11,
Rig13, Rig15, Rig17].
Power optimization of large consumers, such as large organizations or buildings
like hospitals, etc., is a significant challenge which can be addressed by IIoT. Data
collection and preparation for processing are critical to the implementation of
innovative power management and control. Actually, data preparation is emerging
as a critical, time-consuming process especially in heterogeneous environments,
requiring the adoption of new and innovative methods for data cleaning, accounting,
grouping, and conversion, so that data are presented to processing in a homoge-

neous fashion. A promising direction to the optimization of power consumption is
the identification of patterns in consumption, based on the collected data. Pattern
recognition methods play an important role here in two directions, specifically rec-
ognition of patterns based on real consumer behavior and development of desired
patterns that lead to lower consumptions [Kok09, Hat11, Kou11].
Installation of IoT technologies at a large scale, as in the case of buildings, energy
networks, and production lines, requires appropriate processes, mechanisms, and
tools. The tools for deployment and configuration for the IoT, and especially IIoT,
subsystems constitute a challenge because of the high complexity and heterogeneity
of the cyber-physical systems used [Ant16]. The problem becomes more acute
when considering the limited resources of wireless embedded systems, the strict
requirements for initialization of secure wireless connections, and the requirements
for monitoring the parameters that are used for scheduling in real-time wireless
networks, such as IEEE 802.15.4e, IETF 6TiSCH6top, and ISA 100.11a [Kou16].
In contrast with small-scale deployments, e.g., in home environments, installation
processes at a large scale are error prone, despite their formalization, and lead to
installations that have significant costs for reinstallation or reconfiguration when
new devices are added or when changes are made, e.g., an office floor reconfigura-
tion. A characteristic example of a formalized, but error-prone, installation method
is the “outside-in” installation sequence, where sensors, actuators, and controllers
can be installed by technicians before the network, and IT infrastructure in the
building is installed. Clearly, it is necessary to develop effective tools for the man-
agement of IIoT resources such as wireless sensors and their networks.
IoT technologies, in general, are easily adopted in the industrial and enterprise
environments [Bi14], while the addition of wireless cards for the identification of
products and materials enables the management of their complete life cycle
[CEP10]. Thus, there is a need to integrate these smart and identifiable objects in the
industrial enterprise infrastructure and processes. Considering the heterogeneity
that characterizes industrial enterprise environments and its layered management,
from high-level ERP systems to low-level production management systems, the
integration of these devices achieving interoperability is a clear challenge. However,
when the challenge is met, the resulting system enables the flexibility of industrial
processes and their mapping and distribution on “things” of the IIoT, increasing
autonomy within the enterprise.
References
[Amq14] ISO/IEC 19464:2014 (2014). Information technology: Advanced message queuing pro-
tocol (AMQP) v1.0 specification.
[Ant16] Antonopoulos, C., et al. (2016). Integrated toolset for WSN application planning devel-
opment commissioning and maintenance: The WSN-DPCM ARTEMIS-JU Project. MDPI
Sensors.
Chapter 6
Security and Safety
6.1 Introduction
The Internet of Things (IoT), including the Industrial Internet (IIoT), refers not only
to the connectivity of systems and devices but to the related applications and ser-
vices that provide monitoring and control of complex systems and services. The
application domain spans a wide range of industries, from health to industrial con-
trol and from transportation to surveillance systems. Its expansion and growth
incorporate several technologies and disciplines, such as electronics, embedded net-
works, hybrid systems, and control. The inclusion of information technology (IT) as
well as operational technologies (OT) creates a challenge for the development of
systems and services that are technologically interdisciplinary. The resulting chal-
lenges to integrate these technologies in new design methodologies for robust and
effective IoT systems and services are significant. Currently, even the terminology
used by different stakeholders presents challenges and inconsistencies to the com-
mon understanding of properties and goals of IoT infrastructure and applications.
Considering the targeted applications and services of IoT, in this chapter, we
address security and safety of IoT systems and services with an approach that spans
from systems to applications (services or processes) in a unified way, using termi-
nology that originates from computing, networking, and control, since these disci-
plines constitute the main pillars of IoT technologies in all IoT application domains.
This approach is consistent with the reference architectural models of both ITU and
the Industrial Internet Consortium, as presented in Chap. 5. For convenience, we
address security in this chapter following the ITU model, which divides security
mechanisms in two parts, one for generic security and one that is application depen-
dent; we use the terms application dependent and process dependent
interchangeably.
IoT applications, in general, collect data through sensing devices, process this
data, and take actions that range from sending notification and raising alarms to tak-
ing actions through actuators on physical systems. A simple generic model for this
© Springer International Publishing AG 2018 55

D. Serpanos, M. Wolf, Internet-of-Things (IoT) Systems,
https://doi.org/10.1007/978-3-319-69715-4_6
56 6 Security and Safety
Control Center
(C)
Control commands Data acquisition
Control
actions Measurements
Device
Actuators Sensors
(D)
Fig. 6.1 Control loop
operation is the model of the control loop that is used across many application
domains and is depicted in Fig. 6.1. In this model, a device D is controlled by a
control center C. Measurements of the parameters of interest are collected from D
through sensors and delivered to C which makes the necessary calculations and
takes the necessary decisions and actions for the application; if the application
requires automatic actions, C sends the necessary commands to actuators that con-
trol D. The model is generic and covers application across domains ranging from
health to transportation and from aerospace to manufacturing. In a health applica-
tion, for example, sensors measure patient parameters, such as temperature and glu-
cose levels, and send them to a monitoring program – analogous to the control
center – and decisions are made depending on the application; a message may be
sent to attract a patient’s or a doctor’s attention, or an insulin pump may be opened
to administer more insulin. In a manufacturing floor, sensors may detect the arrival
of a component and send the data to a control center which, in turn, sends the appro-
priate commands to the machine that will process the component accordingly.
The control loop model shown in Fig. 6.1 is implemented on a computational
platform that has a different structure from the one indicated in the control model.
Figure 6.2 shows a typical hierarchical computational structure for industrial sys-
tems, an important class of IoT systems, showing how the computing systems, net-
works, sensors, and actuators are typically used to implement the operational
computing infrastructure of the control loop. Sensors and actuators are attached to
the controlled device (D in Fig. 6.1), programmable logic controllers (PLCs) imple-
ment simple controls – one per PLC typically – and the supervisory control and data
acquisition (SCADA) system implements the control loop for the complete process,
also denoted as plant. The PLCs in the structure are simple industrial computers,
and their number differs according to the application. In a smart grid, for example,
different PLCs may take actions locally per transformer, while SCADA controls the
6.1 Introduction 57
Fig. 6.2 Hierarchical

computing structure for
Supervisory Control
control loop and Data Acquisition
(SCADA)
Network
PLC PLC PLC
Network
Valve Pump
complete smart grid; in a water management system, a different PLC may control
each pump, while SCADA controls the water system of an industrial site.
In this environment, there are several properties we want to achieve. From the
control point of view, these properties are typically safety properties. For example,
we want to avoid overloading of a smart grid, to avoid the overflow of a fluid tank,
or to avoid overdose of a pharmaceutical substance that is automatically adminis-
tered to a patient. These properties can be violated because of several reasons. A
programmer may have introduced a bug in the program, the requirements of the
system may have missed a condition that should had be taken into consideration, the
middleware of the system may give the wrong priorities to control processes, or,
simply, a malicious party may attack the system and cause it to take the wrong
actions.
The safety requirements for applications are typically expressed as requirements
on the control loop which implements applications. These expressions are based on
assumptions about properties of the infrastructure on which the application is imple-
mented. For example, an HVAC control system assumes that the temperature mea-
surements that are input to the system are correct within some approximation. This
implies that the safety properties are based on assumptions for data integrity that
need to be satisfied by the infrastructure. In general, safety requirements include
infrastructure security ones, such as integrity, implicitly or explicitly. A typical
explicit security property is the protection of personal information in a health man-
agement system. Thus, it becomes clear that security is a requirement for safety as
well, since data integrity is necessary at least.
IoT technologies involve several stakeholders, including vendors, service pro-

viders, regulators, and customers. Although the interests of the independent stake-
holders are different and, thus, the security requirements they place on IoT
technologies may differ, there is a set of core security requirements that, in general,
addresses the requirements of all different categories of the stakeholders. This set of
requirements includes (1) confidentiality, (2) integrity, (3) authentication, (4) access
control, (5) non-repudiation, (6) dependability, (7) safety, and (8) privacy [Ser13].
Confidentiality is the property that provides protection of data, stored or trans-
mitted, from being disclosed, while integrity enables the confirmation (verification)
of the correctness of the related data. Authentication enables the identification of
any party involved in a transaction, whether producing, processing, transmitting, or
receiving data. Access control ensures service provision to authorized users, while
non-repudiation disables participants to transactions to deny actions or their partici-
pation. Dependability requires provision of system and service functionality with
specific properties such as continuous service even in the presence of errors and
failures, meeting specific real-time requirements, etc. Safety is a service and process
requirement that warrants service provisioning so that there is no hazard to users.
Finally, privacy protects personal information from access by unauthorized actors.
Scientific and engineering methods and techniques to meet these requirements
are known, in general, because such requirements have been long addressed in sev-
eral IT systems in a wide range of application domains. However, meeting the
requirements in the IoT and IIoT context with OT characteristics requires new
approaches, because of several additional factors. These factors include the models
of component failures, the available resources for security provisioning, as well as
the profile of attackers, including their potential resources. These factors are strong
differentiators in the process of security provisioning in the IoT and IIoT context,
for several reasons. First, embedded and CPS systems have already been deployed
in significantly larger numbers than the non-embedded (typical IT) systems such as
servers, laptops, etc. Second, most of these systems are resource limited in terms of
computational, communications, and power resources, and their manufacturers
place strong low-cost requirements in order to penetrate large consumer markets. As
a result, these systems are deployed in various environments, including hostile ones
where malicious users get access to these systems for unspecified lengths of time
and with unspecified capabilities to tamper with them. A final reason is the strict
requirement for safety in several domains such as automotive, industrial, aeronau-
tics, etc.
These differentiating factors of embedded systems place significant demands on
their security, because their large deployment numbers and the diverse operating
environments, with many unknown or unanticipated characteristics, lead to a large
number of potential attackers with varying capabilities. In addition, many applica-
tion domains place security requirements that are relevant to safety, dependability,
and privacy, as in the case of transportation systems, medical systems, surveillance,
etc. The necessity to meet all these requirements on systems with limited resources
and low targeted cost leads to highly challenging problems and the need for low cost
technologies that achieve the required goals.
6.1 Introduction 59
Privacy Safety Layer 2: Properties
Security Dependability Layer 1: Mechanisms
Fig. 6.3 Security property layers
In order to identify the requirements and mechanisms that are required to provide
the necessary security properties in the IoT and IIoT context, we follow the layering
shown in Fig. 6.3, which has been introduced in [Ser13]. Figure 6.3 defines our view
of the relationship between application and process properties, such as safety and
privacy, and security and dependability mechanisms which are provided at the sys-
tem level and are used as primitives to provide the application and process
properties.
The depicted layering is based on our approach to differentiate system level
properties, such as secure storage, secure communication, tamper resistance, etc.,
from properties that are required and provided at the application level. In this
approach, we consider that (embedded) systems and their interconnections are built
to operate resiliently overcoming failures, accidental or malicious, that lead to infor-
mation loss, leakage, and availability. Dependability mechanisms focus more on the
aspects of reliability and availability considering accidental failures, using probabi-
listic models for the failures, while security mechanisms focus on the provision of
alternative properties, e.g., confidentiality, authentication, availability, etc., based
on defined malicious attack models. Although some dependability and security
properties, such as the availability of information, are common between the two
disciplines, others, such as confidentiality or continuous operation, are complemen-
tary. In general, dependability is complementary to security, because an attacker can
insert faults and failures – analogously to launching attacks on security mecha-
nisms – that the dependability mechanisms cannot recover from. Clearly, the com-
bination of dependability and security mechanisms at the system level provides
trusted platforms that are both secure and available under accidents and attacks.
Safety and privacy are often described as security requirements in many applica-
tion domains, although they are different from the typical security considerations in
many ways. Typically, privacy protection and safety are requirements for processes,
applications, and services, rather than for generic systems. In our approach, privacy
and safety are dependent on security, because they employ security mechanisms for
their implementation, such as data integrity and confidentiality. Interestingly, safety
and privacy are overlapping, because privacy is a safety issue in some contexts, such
as the financial transactions. It is important to note that, as Fig. 6.3 indicates, secu-
rity and dependability are requirements for privacy and safety. If security mechanisms
are lacking, an attacker can violate privacy by easily collecting data or can alter
processes and applications, leading to unsafe conditions.
The threat model we consider for IoT systems is one that includes both compu-
tational attacks and data attacks. Computational attacks include all malicious actions
in a computing system that affect the correct execution of a program and/or lead to
information leakage. Data attacks constitute all attacks on input or communicated
data. We extend the concept of data attacks to include false data injection attacks,
which are malicious interventions that input inappropriate (illegal) data to a system.
False data injection (FDI) attacks are an emerging class of attacks to IoT systems,
which do not attack the IoT systems themselves but input wrong data to a control
system in order to lead it to a wrong decision. In that respect, they are mostly safety
attacks. For example, in an HVAC system, a false data injection attack would be to
input a higher temperature to the system, instead of the correct measure, in order to
lead it to lower the temperature further. Clearly, this type of attacks can lead to haz-
ardous conditions that may endanger processes and systems, even human life.
6.2 Systems Security
IoT systems are embedded computing systems that employ architectures analogous
to general-purpose ones. A typical structure of an IoT system is shown in Fig. 6.4,
where the system contains four main subsystems: (i) processing, (ii) memory, (iii)
input/output, and (iv) power. In general, a secure system requires protection as a
whole in addition to protection of all its components individually. The specific
requirements are placed depending on the operational environment and the expected
capabilities of attackers. In a surveillance system, for example, optical sensors
(cameras) need to be secured individually, but the whole network needs to operate
dynamically in case individual cameras are compromised or destroyed.
The security of stand-alone systems is achieved with several levels of protection
that include physical and hardware security as well as trusted computing platforms.
Anti-tampering techniques enable different levels of physical protection ranging
Fig. 6.4 Organization of a

Bus
typical IoT system Processor Memory
I/O
Power (Battery)
6.2 Systems Security 61
from tamper evidence to tamper response and tamper resistance and are employed
accordingly depending on the security requirements of the system and its opera-
tional environment. Techniques for tamper evidence simply indicate whether a
device has been tampered with. Tamper-response methods combine tamper detec-
tion with tamper reaction, where appropriate actions are taken after tamper detec-
tion; for example, they destroy stored sensitive data. Tamper resistance methods
prevent tampering with devices and protect any sensitive data in the device from
attacks.
Anti-tamper technologies have been developed to protect systems after their
deployment, so they need to address physical and hardware attacks of attackers with
variable capabilities in a wide range of hostile environments, especially for critical
applications such as surveillance. They need to combine physical as well as algo-
rithmic mechanisms. Traditional encryption of data, for example, is not a sufficient
solution to data protection nowadays, especially in limited-resource systems, where
encryption can be overcome with simple attacks. Side-channel attacks have changed
the attacks on cryptosystems exploiting physical parameters of the implementations
of cryptographic algorithms, such as timing and power consumption, rather than
attacking the algorithms themselves [Koc96, Koc99, Qui01] or introduce faults dur-
ing cryptographic computations [Bar06, Joy09].
Complex hardware systems such as processors and micro-controllers are suscep-
tible to physical and hardware attacks similarly to dedicated circuits, such as cryp-
tographic circuits [And96, Bly93]. Defenses against such attacks require dedicated
hardware, specialized design techniques, or even new architectural concepts. For
example, a sensitive program can be protected from attacks by storing it in a special
design of execute-only memory that allows instructions stored in memory to be
executed only and does not allow any other manipulation [Lie00]. Encrypted buses
protect data from leakage during data transfers between a processor and its memory
[Bes81, Kuh97]. Decay caches can protect from side-channel attacks avoiding
cache information leakage [Ker08].
Anti-tampering techniques protect against attacks after system deployment. New
business environments can drive embedded systems insecure by planting hardware
Trojans during the design and manufacture phase [Jin10].
Embedded and cyber-physical systems, in general, are widespread and have
attracted a large range of attacks [Rav04]. Defense against them requires a combina-
tion of software and hardware techniques, in order to cover all potential attacks.
This is especially important in emerging cyber-physical and IoT systems, which
include operating systems or specialized middleware. More complex programmable
systems require adoption of such methods as secure booting [Arb97] to establish
system integrity, process isolation, and process level attestation techniques [Mic11]
to protect running processes as well as techniques for context switching, exception
handling, inter-process communication, and memory management [Lie03, Gar03].
Overall, the increasing programmability of these systems requires appropriate soft-
ware security techniques. Software techniques also offer a cost advantage over
hardware techniques. Furthermore, the combination of software techniques with
trusted computing modules [Pea02] enables the development of trusted computing

platforms for applications and services.
6.3 Network Security
Secure communication requires encryption and authorization mechanisms as well

as a secure routing method in a network. Traditional encryption schemes, such as
AES [AES01], RSA [RSA78], etc., provide a high level of security, as has been
proven in general-purpose computing systems, but they are quite demanding in
computational and memory resources. Clearly, they are becoming more viable can-
didates for adoption in environments where embedded systems obtain increased
computational resources. However, today, they are still too demanding computa-
tionally for most embedded applications and services. Elliptic curve cryptography
provides a promising solution to IoT environments, because it requires lower com-
putational resources than algebraic public key cryptography while providing a high
level of security [Miller1986]. Importantly, significant effort is spent to develop and
standardize appropriate algorithms for cryptographic primitives for IoT environ-
ments, taking into account their characteristics. The development of the Secure
Hash Algorithm-3 (SHA-3) by NIST is a significant step in this direction, providing
a family of hash functions and extendable output functions that are useful for pseu-
dorandom bit generation, key derivation, and digital signatures in IoT environments
[Mor15].
Sensor networks are an important class of IoT subnets that need special atten-
tion, because they usually form ad hoc sub-networks with large number of nodes
that have very limited computational resources. Thus, sensor network protocols
often need to satisfy stricter performance requirements than more complex embed-
ded systems. These limitations typically lead sensor networks to implement crypto-
graphic mechanisms at the link layer. In such limited environments, a good
encryption strategy is to use mechanisms with different complexity, depending on
the value of the communicated information [Zhu03].
Key management is a critical component of secure IoT communication because
keys are the base of cryptographic mechanisms. If key management has weak-
nesses, keys will be compromised (disclosed or leaked) leading to ineffectiveness of
any cryptosystem independently of its strength. The use of global communication
keys provides a solution, but such keys cannot be predefined in networked systems
usually, because the security of the network can be easily compromised. This leads
to the necessity to develop and adopt effective methods to generate and distribute
keys. There exist such effective methods mainly using temporary global keys and
random key distribution. One such method uses temporary global keys and a global
permanent key to establish a main key; then, it destroys the global key in order to
avoid key leakage, i.e., the main risk with global keys [Per04]. In an alternative
approach, one can use random key distribution. In this case, the system uses a large
number of keys and performs communication choosing random subsets of keys.
6.3 Network Security 63
When the key set sizes are chosen appropriately, all network end points of a network
can communicate successfully [Cha03].
Networked systems, especially through the Internet, need to ensure that data are
being communicated only among authorized users and processes and that these
exchanged data are “legal.” This is usually achieved through the use of firewalls,
which are typically implemented at the network and application layers, in end point
systems or in the network infrastructure [Bol95]. IoT systems typically have very
well-defined communication needs, and thus, firewalls can be easily configured to
allow strictly the limited type of legitimate communication. The decision about
where the firewall should be implemented, i.e., at the network or application layer,
at the end system, or in the network, depends on the end point system, the network
and their available resources, as well as on the network topology. For example, ad
hoc networks need protection at the node level, while more centralized systems can
rely more on network level protection [Sli02].
Denial-of-service (DoS) and distributed denial-of-service (DDoS) attacks are a
significant threat against IoT systems or exploiting IoT systems. DoS attacks over-
load resources, such as processor, memory, and network, of the targeted system, in
order to prevent it from performing its intended functionality or serving its users.
In general, there are two basic types of DoS attacks [Hus03]. The first type of
attack exploits vulnerabilities, hardware or software, by sending carefully con-
structed packets to the target system; the typical goal is to crash the target system.
Often, such vulnerabilities are exploited because systems are not patched. This
makes IoT systems especially vulnerable to these attacks, because many IoT sys-
tems are not configured to update their software automatically and a wide popula-
tion of users is not sufficiently aware of the risks and actions they need to take to
protect their systems accordingly
In the second type of attacks, the distributed denial-of-service (DDoS) ones, a
large population of compromised systems create vast amounts of network traffic
toward a victim system; this traffic is combined with legitimate traffic as well. The
overload of the aggregated arriving traffic at the target system overloads its resources
and renders it incapable to serve its legitimate users. The recent incident of the Mirai
botnet attack [New16] demonstrated clearly that IoT devices are vulnerable to mal-
ware injection and they can be effectively used to launch DDoS attacks; in the Mirai
case, they attacked an Internet directory service, causing significant and costly dis-
ruptions to Internet connectivity worldwide.
DDoS attacks are difficult to stop because they exploit shared network services
that are accessed by all systems connected to a network. The current version of the
Internet Protocol (IPv4) allows systems to send IP packets with arbitrary values in
the source IP address field, making it difficult to identify sources of offending IP
packets in many attacks [Wan07]. Current efforts to defend against DDoS attacks
are usually based on intrusion detection and traceback schemes for detection, filter-
ing, and tracing of an attack [Pen07]. Intrusion detection employs signature- and
anomaly-based detection techniques [Cab01, Wan02], while packet marking [Bel03,
Sav01] and packet logging [Sno02] are used for attack traceback.
6.4 Generic Application Security
Interconnected IoT systems provide the infrastructure for distributed applications

and services. Currently, the vast majority of deployed and emerging applications
follows the client-server model, where remote devices (clients) are connected to
servers or the cloud, in general, to deliver information, such as collected data and
alarms. The servers typically collect data, monitor the operation and processes of
IoT connected devices, and send to the devices control programs or data, in order to
adapt their operation accordingly. For example, a medical device may collect infor-
mation about a monitored patient, deliver it to a centralized server, and receive from
the server tuning information to adapt its operation appropriately, e.g., to change the
frequency of collected data or to change an algorithm used in its local data process-
ing. A connected car may send reports and alarms related to engine operation and
receive a prompt to execute a more detailed test, in case of an alarm or suspicious
data degradation.
Considering the emerging application and service models, it becomes clear that
IoT systems are distributed systems that execute coordinated processes, where each
process is typically a control loop, i.e., a process that, in general, receives sensor
data and transmits actuator commands. When the client-server model is adopted, the
IoT devices execute simpler control loops, while servers execute hierarchically
higher level operations, when they are not simply collecting data. In the Industrial
IoT, this hierarchy is expressed through the programmable logic controllers (PLCs)
as the local, simpler, and lower level devices (clients) and the supervisory control
and data acquisition (SCADA) system as the centralized, higher level server system
that monitors and coordinates the complete supervised process.
Based on this hierarchical application model, we consider two levels of distrib-
uted application for security purposes. The first level, generic application security
support, is the one that provides generic services to the IoT environment, such as
system update and upgrade, while the second one, process, is the one that imple-
ments the specific process for the specific IoT system, e.g., health, car, industrial,
etc.
Generic application security support includes mechanisms to defend against
attacks to distributed denial-of-service, secure upgrading, etc. Distributed denial-of-
service solutions exploit mechanisms at the network layer, as described in the previ-
ous section, extending them where necessary to include specifics from the application
configuration at hand, such as the location of the servers.
Upgrading and patching IoT systems constitute another challenge that requires
inclusion of security mechanisms, because upgrading and patching open systems up
to security risks. The functionality for upgrading and patching is necessary for many
reasons; software bugs of deployed software need to be fixed, and new features may
need to be added to an IoT system’s functionality. However, the ability to transmit
code to an IoT system raises the risk that one may attack the system by inserting
malicious code instead of the legitimate, intended code. Thus, security mechanisms
need to be included in the upgrading services to warrant the secure and safe
6.5 Application Process Security and Safety 65
u pgrading of the IoT systems. There are several approaches to this challenge. One
can limit or prevent the ability to upgrade software components that manage critical
system resources in highly hostile application environments. Alternatively, in safer
environments, strict access control mechanisms can be used to enable upgrades of
different software components by different operators. Mobile code transmission
may be prevented, while wired code transmission may be allowed when connectiv-
ity is in a controlled environment. In general, remote management of systems, espe-
cially IoT systems with limited resources, requires a secure architecture that
addresses the operational environment as well as the profiles of the potential
attackers.
6.5 Application Process Security and Safety
Application processes, such as control processes in an industrial environment, are

programs that execute the necessary code to calculate the required outputs and
implement the process’s actions. For example, in an HVAC system, an application
process may take as input a request to increase the temperature of the controlled
environment, and, as a result, it will calculate the necessary increase for the extracted
hot air temperature and its volume and will control and adjust the related actuators
accordingly to achieve the result. In a more complex environment such as a smart
grid, an identified need or a request to add power to the network will lead to the
calculations for the necessary power, the identification of the appropriate generators
to activate and, finally, the control of the appropriate actuators that will add the
generators to the grid. Such application processes in the (I)IoT environment have
safety requirements, which are typically expressed as properties that need to be met;
for example, in the HVAC system, the temperature of the hot air needs to be within
a specified temperature range. Clearly, security of the involved computing and net-
work systems is a prerequisite for meeting the safety requirements; a compromise
of these subsystems can lead to wrong calculations and, thus, to wrong actions that
violate the safety properties that are required to be met.
Provision of security and safety in (I)IoT environments is one of the areas where
the interdisciplinary nature of IoT expresses itself: safety requirements are applica-
tion dependent and are set, in most cases, by the engineering of the controlled sys-
tems, while security – a prerequisite of safety – requires methods of computer and
network security, since the IoT systems themselves are distributed computing sys-
tems effectively. Bringing all safety and security requirements together is a chal-
lenge that has motivated a lot of research and development work recently and will
require significant effort in the future to lead to effective solutions that are easily
deployed in the field.
The most promising integrated approach to safety and security, from a computa-
tional perspective, is to view the problem as a verification and monitoring one.
Since application processes are implemented with programs and safety properties
are set by the application designers, e.g., control engineers, one can view the p rocess
of developing the application programs as one where the application designers pro-
vide the specifications of the application, including the safety properties, and then
the software is developed accordingly to meet these specifications and be secure
from vulnerabilities overall. In this fashion, the safety and security problem becomes
a verification and monitoring problem: first is the verification of the produced appli-
cation software, i.e., that it meets the set requirements, and second the monitoring
of the execution of the verified program in order to ensure that it is not altered and
executes as expected, based on the specification.
This approach is a behavioral approach to safety and security, since it is based on
the specification of the application process. In this context, application behavior is
defined by the executable specification that is the starting point of the approach, and
this is the way the term is used in the remainder of this text.
6.6 Reliable-and-Secure-by-Design IoT Applications
The concept of secure-by-design applications is an extension to the principle of

correct-by-construction programs introduced half a century ago [Dij67]. The chal-
lenge posed by IoT applications is that IoT systems typically include a cyber-
physical subsystem that interacts with the environment. Thus, in contrast to the
original concepts developed for behavioral models of programs with discrete and
linear characteristics, the models for cyber-physical and IoT systems need to accom-
modate continuous and nonlinear characteristics. A model of the environment is
also necessary but challenging, because there exist uncertain environmental varia-
tions that affect the behavior of physical subsystems; furthermore, it is necessary to
model the environment at different levels of abstraction.
The development of reliable and secure-by-design applications has attracted the
attention of several efforts, which focus on the development of effective program-
ming language environments. Ur/Web [Chl96] is a language that enables develop-
ment of reliable and secure web applications by design. For security, Ur/Web
ensures that the produced application does not have vulnerabilities, such as for code
injection attacks and SQL injections, while for reliability it ensures that the applica-
tion will not crash during generation of web pages, it will not produce dead intra-
application links, etc. The language guarantees these reliability and security
properties through an enriched type system based on dependent. In this fashion, Ur/
Web achieves an important result: it provides a unified web model, where a pro-
grammer develops web applications in a single programming language that can be
compiled to other web standards. In another effort, the Jeeves language focuses on
run-time, enabling enforcement of security policies and guarantees that programs
do not violate security properties by design [Yan12]. Analogous efforts have been
made to apply these approaches in the cyber-physical systems application domain.
The ROSCoq framework [Ana15] employs the Coq proof assistant [Ber04] to model
cyber and physical resources of robots through an extended logic of events and then
to prove various properties of the model. VeriDrone [Mal16, Cha16], a reasoning
6.7 Run-Time Monitoring 67
framework also developed in Coq, ensures security of cyber-physical system mod-

els at different but independent levels, i.e., from high level models to C
implementations.
6.7 Run-Time Monitoring
Run-time monitoring systems for security can be classified based on two parame-
ters: (i) the method that describes the behavior, i.e., profile based or model based,
and (ii) the method that compares the behaviors, i.e., matching to bad behavior or
deviation from good behavior. This leads to a classification with four classes, as
shown in Fig. 6.5.
Profile-based approaches monitor parameters of the observed system and build a
profile of system operation. Class 1 monitoring systems that detect attacks by
matching with bad behavior (Class 1 in the figure) typically use statistical methods
and machine learning methods to build profiles of bad behavior and statistical pro-
files of attacks [Hod04, Val00]. They are more robust than model-based systems
(Class 2 systems) because machine learning typically generalizes from the collected
data, but they suffer from high false alarm rates, and they do not provide rich infor-
mation for diagnosis when an alarm is raised. Systems in Class 3, which detect
deviations from good behavior, usually build a statistical profile of good behavior
and detect deviations from that [Kim04, Lak05].These systems are actually more
robust than the ones in Class 1, because they do not depend on any past information
of attacks and, thus, they raise alarms when new attacks are launched, because all
deviations from good behavior are detected. However, not only do they provide
limited diagnosis information, i.e., only that something extraordinary has happened,
but they suffer from high false alarm rates, because the deviation may not be mali-
cious or accidental, but it can also be normal but just out of the statistically accepted
profile behavior.
Model-based monitoring systems, Class 2 and Class 4 systems, use a model of
the behavior of the monitored system. Such systems are popular in highly secure
Fig. 6.5 Classification of Behavioral description

run-time security
monitoring systems Profile based Model based
Bad behavior Class 1 Class 2

matching
Behavioral
comparison
Good behavior Class 3 Class 4

deviation
environments, where successful attacks have high cost. Because they use a behav-
ioral model of the observed system, these monitors provide rich diagnostic informa-
tion when alarms are raised, in contrast to profile-based monitors. Despite this rich
information though, Class 2 monitors are limited because they can detect only
known attacks; this originates from their bad behavior models which are already
known by definition, i.e., the attacks exist [Pax99, Roe99]. Signature-based systems
are typical examples in this class. Class 4 monitors detect deviations from a good
behavior model [Wat07, Gol07] and thus provide even higher diagnostic informa-
tion, because there is adequate knowledge of the exact problem, e.g., the exact
instruction, that led to a detected deviation. However, the execution overhead of the
models of good behavior poses limitations to run-time system performance.
6.8 The ARMET Approach
A promising approach that addresses safety and security in a unified way in IoT
systems and cyber-physical systems is the ARMET approach [Kha17]. ARMET is
based on three basic concepts: (i) we can build secure-by-design systems, (ii) we
can monitor these systems at run-time for correct operation to detect attacks or fail-
ures, and (iii) when there is a failure or an attack, we can have plans to recover,
depending on the problem and how much information we have about it. ARMET
has been developed focusing on industrial control systems, but it is applicable to
other IoT systems as well, since their software complexity is comparable to that of
industrial control systems.
With the ARMET approach, an IoT application is developed starting from an
executable specification which is provably consistent with the safety properties set
for the application. From this executable specification, the application code is
derived. Given the executable application specification and the application code for
the target system, ARMET monitors the behavior of an application while it exe-
cutes, by comparing its observed behavior to the expected behavior based on the
application’s specification; to achieve this, a middleware executes the executable
specification in parallel with the application execution on the IoT system and calcu-
lates predictions of the application’s behavior. Figure 6.6 shows the structure of the
ARMET middleware system, which is composed of several components: (i) the
run-time security monitor, (ii) the diagnosis module, (iii) the recovery module, (iv)
the trust model, (v) the adaptive method selection module, and (vi) the backup mod-
ule. The run-time security monitor is a critical component of the middleware, which
takes as input the executable specification of the application and the state of the
system that executes the code of the application. The monitor observes the behavior
of the application execution, and, in parallel, it predicts the state of the application
execution by executing its specification; the specification execution defines the
expected “good behavior” of the application and, optionally, known “bad behavior”
of the application that includes known attacks. Comparing the predictions with the
observations, the monitor can detect deviations that indicate a failure of the
6.8 The ARMET Approach 69
ARMET
Recovery Adaptive method selection
Diagnosis Trust model Backup
Run-time security monitor

(RSM)
Application Application
specification code
Fig. 6.6 The ARMET system
a pplication or an attack. When such a detection is made, ARMET proceeds to a

stage of diagnosis, in order to identify the failure or attack based on a trust model
that it includes. After the diagnosis phase is concluded, all available information is
used by the recovery module. Based on the diagnostic information, the recovery
module chooses an appropriate adaptive method for recovery and enables the sys-
tem to recover, taking into consideration previous states, as stored by the backup
module. It is important to note that the system will operate under all scenarios of
failures and attacks, even unknown ones, i.e., failures and attacks that have not been
anticipated and are not included in the trust model. In a worst-case scenario, when
no useful information is provided by the diagnosis module, the system will recover
by returning to a previous clean state. Furthermore, the approach is based on one
assumption: the executable application specification is executed in a safe environ-
ment and cannot be attacked, i.e., its predictions are always correct; although this
may seem as a strong assumption, conventional trusted platforms enable the devel-
opment of a low-cost IoT platform that meets this requirement and makes the
assumption realistic, such as Intel SGX [Cos16] and ARM TrustZone [ARM05].
The process to develop executable specifications and prove its properties is a
typical program verification process that can be implemented with various existing
tools that enable automated or semiautomated proofs. In the case of ARMET
[Kha17], the process is based on Fiat [Del15] and employs deductive synthesis to
develop reliable-and-secure-by-design industrial control applications through inter-
active stepwise refinement of declarative specifications; cyber and physical resources
are included as first class models, and nonfunctional properties, such as security and
performance, are modeled integrated with functional properties. Apparently, the
in_pump
h wh
out_pump
Fig. 6.7 Water tank
executable specification can produce automatically executable code for the target
system, IoT or industrial.
The ARMET run-time security monitor (RSM) successfully identifies inconsis-
tencies between predictions, produced by the execution of the specification, and
observations of the application code execution, because of its executable specifica-
tion language [Kha15]; importantly, the predictions are generated automatically.
The run-time security monitor (RSM) is the first one to be formally proven as sound
and complete [Kha15]; the proof means that the monitor is also free of false alarms
(detections), an important, desirable property in practical systems, where false
alarms lead to lost resources that are used to explore the false alarms. Importantly,
ARMET’s specification language allows the specification of faulty behaviors as
well as attack plans, which can be used by the monitoring system for threat
detection.
The ARMET approach is based on the concept that a system can be specified
with an executable specification. Based on an appropriate functional specification
for a system, one can express the safety and security properties that the system
should meet as conditions of the specification and include them in the specification
as well. As an example, let us consider the case of a water tank which has a height
h, as shown in Fig. 6.7, and two pumps that are controlled, one for filling the tank
with water, denoted in_pump, and one, out_pump, for draining the water out; each
of the two pumps has only two possible states, i.e., open or closed. Furthermore, we
assume that there is a sensor that measures the water height, denoted wh, in the tank.
We want to have a water management system, where a user issues commands to
pour water or drain water from the tank. For simplicity, we consider that a user can
perform three actions, FILL, DRAIN, or NOTHING, and that the system operates
in cycles, synchronously with a clock. So, during every cycle (clock tick), one
action can be performed. A FILL action implies that in_pump opens, out_pump
closes, and for this one time unit water is poured in the tank. A DRAIN action
means that in_pump closes, out_pump opens, and for this one time unit water drains
out of the tank. When the action is NOTHING, then both pumps are closed and the
state of the tank remains the same. In an environment like this, an obvious safety
property is that we do not want the tank to overflow under any conditions.
6.8 The ARMET Approach 71
«Enumeration»
Action
- FILL
- DRAIN
- NOTHING
«StereoType»
WaterTankSpec
- water_level : Integer :=0
- SENSOR_ACCURACY : Real := 0.01
- FILL_RATE : Integer := 1
- DRAIN_RATE : Integer := 1
- TANK_MAX : Integer := 10
+ readValue (reading : Integer) : void
+ doAction (water_level : Integer ) : Action
context WaterTankSpec ::readValue(reading : Integer)

+ pre: reading – self_water > SENSOR_ACCURACY
+ post: self_water = reading
context WaterTankSpec :: doAction(water_level : Integer) : Action

+ pre: forall( a : Action | (a = FILL implies water_level + FILL_RATE <= TANK_MAX) and
(a = DRAIN implies water_level - DRAIN_RATE >= 0))
+ post: result = FILL implies self.water_level= old(self.water_level)+ FILL_RATE and
result = DRAIN implies self.water_level= old(self.water_level) - DRAIN_RATE
Fig. 6.8 Water tank control executable specification
Figure 6.8 shows one executable specification, written in UML, which imple-
ments the three defined actions, assuming that each action FILL or DRAIN has as a
parameter an integer value for the variable water_level, which specifies the target
height of the water that the user wants to obtain; furthermore, the specification
ensures that the water tank never overflows. In the specification, the three actions
are defined in enumeration: SENSOR_ACCURACY defines the measurement
accuracy of the reading sensor for the water level in the tank, FILL_RATE is the
incoming water rate through in_pump, and DRAIN_RATE is the rate of the outgo-
ing water when out_pump opens. TANK_MAX is the height h of the tank.
When an action is issued by the user, the system first takes a reading of the water
level with the sensor, as specified in readValue, and identifies whether the target
water height differs from the measured height within the sensor’s accuracy bounds.
If the target height is different, then the corresponding action is performed, pouring
water in or draining water out until the target height is achieved. The safety property
is enforced, because of the precondition that is expressed in doAction(), which
ensures that a FILL action is performed when its result leads to a water height that
is less or equal to TANK_MAX.
Since RSM is sound and complete, it is proved that it will detect all computa-
tional attacks on the application. This means that any attack that influences the
execution of the application and leads to wrong calculations will be detected. This
has been confirmed with several computational attacks [Kha17]. Importantly, RSM
captures a wide range of false data injection attacks as well. For example, if an
attacker wants to overflow the water tank of the example and alters the reading of
the sensor to a lower value – with the purpose to cause insertion of larger volumes
of water – RSM will identify the attack, because the execution of the specification
will calculate a different value for the water level than the one measured with the
sensor. The difference between the expected water level and the one read will lead
to a detection of the deviation; it will raise an alarm and, eventually, will cause the
action to be stopped. Although there exist complex false data injection attacks that
are not detected by RSM, its detection of common attacks combined with the proof
that it detects all computational attacks makes the ARMET behavioral approach a
powerful tool for the protection of processes and applications in the IoT space.
6.9 Privacy and Dependability
Privacy protection is one of the most significant challenges in IoT systems because
of the legal requirements in many application domains such as home environments,
smart grids, and health systems. There are increasing restrictions and constraints on
the collection, storage, and processing of personal information involved in all appli-
cations, including IoT. Privacy protection solutions may need to integrate a range of
methods and techniques, such as time-limited storage of sensitive information,
access control systems to enable access only for authorized personnel, accounting
systems to enable auditing, etc. The burden to comply with the required policies and
laws is further increased by the increasing amount of information considered as
personal or private, which leads to a need for adaptive and scalable solutions that
accommodate new policies as the relevant legal requirements emerge [Mul06]. The
ARMET approach provides a powerful solution to the problem of privacy protec-
tion, when privacy protection is viewed as a safety property. Privacy protection
originates from legal requirements that can be expressed as conditions in an infor-
mation system, i.e., they can be expressed as preconditions, postconditions, or

Iot m5

Uploaded by

Copyright:

Available Formats

Iot m5

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Iot m5

Uploaded by

Copyright:

Available Formats

Chapter 5

Industrial Internet of Things

© Springer International Publishing AG 2018 37

include manufacturing operations, which are managed currently by manufacturing

5.2 Industrie 4.0

p­ roducts and the operations, while reconfiguration and reorganization of production

5.3 Industrial Internet of Things (IIoT)

Fig. 5.1 IoT, IIoT, and

IoT IIoT Industrie 4.0

5.4 IIoT Architecture

Communication over CN without Gateway

Fig. 5.2 Communication methods for IoT devices

connect to communication networks, while they have related information that is

Fig. 5.3 IoT reference

supply chains in conventional service provisioning, leads to the need to accommo-

include control functionality for network connectivity, mobility, authentication,

Application Application Application Application Application

Application Application Application Application Application

Platform Platform Platform Platform Platform

Network Network Network Network Network

Device Device Device Device Device

Model 1 Model 2 Model 3 Model 4 Model 5

Operator A Operator A Operator C

Fig. 5.4 IoT business models identified by ITU

Fig. 5.5 The IIC reference architecture functional domains

5.5 Basic Technologies

A fundamental technology for IIoT, and IoT in general, is the technology of

5.6 Applications and Challenges

A large number of distribution networks follows this ICS-based model of opera-

grouping, and conversion, so that data are presented to processing in a homoge-

© Springer International Publishing AG 2018 55

Control commands Data acquisition

Fig. 6.1 Control loop

Fig. 6.2 Hierarchical

PLC PLC PLC

IoT technologies involve several stakeholders, including vendors, service pro-

Privacy Safety Layer 2: Properties

Security Dependability Layer 1: Mechanisms

Fig. 6.3 Security property layers

6.2 Systems Security

Fig. 6.4 Organization of a

trusted computing modules [Pea02] enables the development of trusted computing

6.3 Network Security

Secure communication requires encryption and authorization mechanisms as well

6.4 Generic Application Security

Interconnected IoT systems provide the infrastructure for distributed applications

6.5 Application Process Security and Safety

Application processes, such as control processes in an industrial environment, are

6.6 Reliable-and-Secure-by-Design IoT Applications

The concept of secure-by-design applications is an extension to the principle of

framework also developed in Coq, ensures security of cyber-physical system mod-

6.7 Run-Time Monitoring

Fig. 6.5 Classification of Behavioral description

Bad behavior Class 1 Class 2

Good behavior Class 3 Class 4

6.8 The ARMET Approach

Recovery Adaptive method selection

Diagnosis Trust model Backup

Run-time security monitor

5.2 Industrie 4.0

p roducts and the operations, while reconfiguration and reorganization of production

5.3 Industrial Internet of Things (IIoT)

5.4 IIoT Architecture

5.5 Basic Technologies

5.6 Applications and Challenges

6.2 Systems Security

6.3 Network Security

6.4 Generic Application Security

6.5 Application Process Security and Safety

6.6 Reliable-and-Secure-by-Design IoT Applications

6.7 Run-Time Monitoring

6.8 The ARMET Approach

a pplication or an attack. When such a detection is made, ARMET proceeds to a

6.9 Privacy and Dependability