Module 5:

Chapter 1: Industrial Internet of Things

1.1 Introduction
The Industrial Internet of Things (IIoT) represents the adoption of IoT concepts within
industrial environments, driven by strategies like Industrie 4.0 and the Industrial Internet. It
aims to increase flexibility and productivity while reducing production costs.

1.2 Industrie 4.0

Industrie 4.0 is a German strategic initiative aimed at bringing IoT technologies to the
manufacturing and production sectors. The core goal is to ensure Germany maintains a leading
role in manufacturing by achieving efficient, low-cost production with highly flexible
workflows. This is realized through the widespread inclusion of cyber-physical systems
(CPS).
The Four Industrial Revolutions
Industrie 4.0 is named after the identification of the current emerging industry as the fourth
revolution of industrial production:
 First Revolution (18th–19th Century): Introduced mechanized production using water
and steam power.
 Second Revolution (Early 20th Century): Introduced electrical energy, enabling mass
production and boosting productivity.
 Third Revolution (Post-WWII Era): Included electronics and software (industrial IT),
leading to high levels of automation.
 Fourth Revolution (Industrie 4.0): Characterized by the wide adoption of cyber-physical
systems (CPS), leading to even higher levels of automation and enabling mass customized
manufacturing due to flexible, programmable production lines.
Technological Foundation and Evolution
The initiative is built upon the significant advances in computational and communication
resources over the past two decades:
 Computational Power: There's a massive base of processing capabilities, with
approximately 98% of produced processors deployed in embedded systems.
 Connectivity: Advances in wired and wireless networks have led to nearly ubiquitous
connectivity in cities and towns.
 Sensor Technology: Sensors are crucial as they bridge the gap between the physical world
and the digital world, providing the rich information necessary for intelligent control and
process management.
This technological basis drives an evolving hierarchy of networked systems:
1. Embedded Processors: Control individual, specific parameters (e.g., car seat movement
based on user commands).
2. Networked Embedded Services: Systems communicate with each other (e.g., electronic
transaction for automatic toll payment).
3. Distributed Systems: Complex systems combine services for wider-scale management
(e.g., traffic and toll management across a wide area).
4. Internet of Things, Data, and Services (Smart Cities): High-level connectivity of
complex systems, integrating services like transportation management with energy
distribution, civil services, and emergency services.
The Smart Factory Concept
The smart factory embodies the primary goals of Industrie 4.0. It relies on a multilevel
hierarchy of interconnected smart production systems (smart machines, smart plants, smart
factories) to achieve high degrees of flexibility, efficiency, autonomy, resilience, safety, and
low cost.
Smart factories aim to automate all stages of the manufacturing process efficiently:
 Material and Resource Management: Efficient introduction and management of
materials.
 Real-Time Production: Managing production processes in real time to minimize resource
usage.
 Reconfiguration and Customization: Enabling real-time reconfiguration of processes and
customization of products with safety for infrastructure and operators.
 Logistics: Manufacturers optimize their logistics chains while customers can monitor their
product's development progress.

1.3 Industrial Internet of Things (IIoT)

The Industrial Internet of Things (IIoT) is the general concept for applying IoT technologies to
the industrial sector. It is an effective generalization of Industrie 4.0, expanding the focus
beyond process efficiency to include asset management, maintenance, and all other aspects
of industrial operations.
 Fig 1.1: IoT, IIoT, and Industrie 4.0 relationship
IIoT vs. General IoT:
Although both IIoT and general IoT share the same basic model (interconnected smart devices
enabling sensing, data collection, monitoring, and control), the key factors that differentiate
IIoT are:
1. Stricter Requirements: IIoT systems face stronger, more demanding requirements for
continuous operation and safety.
2. Operational Technology (OT): IIoT involves the specialized technology employed in the
industrial sector (e.g., PLCs and SCADA systems).
 Example: Monitoring a steam pump (IIoT) vs. monitoring body temperature on a
smartwatch (Consumer IoT). While both collect and transmit real-time data, a failure
in the steam pump has a significantly more catastrophic potential effect, leading to
costly downtime, human injuries, or loss of life, justifying the stricter requirements.
Scope and Strategy
 The demanding solutions required by these characteristics justify the industrial sector's
focus on a specialized IoT concept.
 The term Industrial Internet was introduced by General Electric (GE) in 2012. GE
identified the main constituents of the IIoT vision as: machine-to-machine
communication, SCADA, HMI, industrial data analytics, and cybersecurity.
 The need for interoperable solutions across devices and services, driven by complex
business models, is addressed by coordinated efforts from consortia like the Industrial
Internet Consortium (IIC).
 GE estimates the impact of the Industrial Internet to be 46% of the global economy, with
a particularly high impact on the energy sector (100% on production, 44% on
consumption).
1.4 IIoT Architecture
The development of Industrial Internet of Things (IIoT) systems requires established
blueprints, or architectures, to ensure everything works efficiently together
(interoperability). The two key architectures are the general one from the ITU and the
specialized one from the IIC.

Fig 1.2: Communication methods for IoT devices

1. ITU-T Y.2060
The International Telecommunication Union (ITU) provided a generic reference architecture
for the whole IoT, including industrial applications like smart grids.
 What is a "Thing"? Anything identifiable, physical or virtual, that can connect to a
network. Physical things need devices attached (like sensors) to convert analog data to
digital.
 Communication: Devices can talk to each other directly, over the main network, or
using a Gateway (G) as a translator.
 Key Challenges Addressed: The architecture recognizes that the system must handle
massive scale, huge heterogeneity (many different devices/platforms), and the
dynamic nature of devices (turning on/off). This leads to requirements like
interoperability and strong security/privacy.
2. IIC Industrial Internet Reference Architecture
The Industrial Internet Consortium (IIC) created a more detailed and specialized architecture,
known as the IIRA.
  Focus: The IIRA is an evolution of the ITU model that specifically addresses the
complex and critical needs of the industrial sector, such as integrating legacy industrial
control systems (OT).
 Purpose: It serves as a comprehensive, detailed guide for all industrial stakeholders,
covering aspects beyond simple connectivity and diving deep into operational issues,
safety, and security crucial for IIoT.

ITU IoT Reference Model

The ITU IoT Reference Model is a typical layered architecture introduced to address the
requirements of large-scale, heterogeneous, and dynamic IoT systems. It features four
hierarchical layers and two vertical, crosscutting layers.

Fig 1.3: IoT reference model by ITU

Hierarchical Layers (Horizontal)
1. Device Layer (Lowest):
 Functionality: Includes the functionality of devices and communication gateways.
 Communication Focus: Describes how devices communicate:
 Directly over the network (no gateway).
 Through a gateway.
 Directly over local or ad hoc networks (not using the main communication
network).
 The ability to selectively turn on and off functionality to save power.
 Interoperability: Includes various wired/wireless technologies (Wi-Fi, Zigbee, CAN
bus) and, importantly, protocol conversion for interoperability between different
device protocols.
2. Network Layer:
  Functionality: Provides encapsulation of device data and protocol conversion to
network layer protocols (covering OSI Network and Transport layers).
 Networking: Includes control functions for connectivity, mobility, authentication,
authorization, and accounting.
 Transport: Anticipates transport for both user traffic and control/management
information for IoT services.
3. Service Support and Application Support Layer:
 Functionality: Hosts capabilities that enable IoT applications and services, spanning
both generic and service/application-specific functions.
 Generic Functions: Includes common needs like data processing and storage.
 Specialized Functions: Customized functions based on specific service requirements
(e.g., smart grid operations have different privacy needs than intelligent toll
management).
4. Application Layer (Highest):
 Functionality: Contains the end user's IoT applications and services themselves.
Vertical Layers (Crosscutting)
These layers define functions that cut across all four hierarchical layers:
1. Management Layer:
 Generic: Refers to typical management functions for configuration, topology,
resource, performance, fault, security, and account management.
 Application-Specific: Functions tailored to meet specific application needs (e.g.,
smart meter monitoring in smart grids).
2. Security Layer:
 Generic: Functions related to authorization, authentication, integrity, and
confidentiality at all layers; privacy at the application layer; and secure routing at the
network layer.
 Application-Specific: Functionality designed to meet unique application-specific
security requirements.
Business Model Roles
The ITU model also presents business models developed from the perspective of network
operators, based on five main roles:
 Device Provider: Stakeholders that supply the devices for the IoT system.
 Network Provider: Stakeholders that provide the network systems, gateways, and
connectivity.
 Platform Provider: Stakeholders that offer the unified, distributed IT platform with
defined interfaces necessary to serve an application end-to-end.
 Application Provider: Stakeholders who deliver the IoT service over the platform,
networks, and devices.
 Application Customer: The end user of the IoT application or service.

ITU Business Models and IIC Viewpoints

The Industrial Internet of Things (IIoT) requires structured architectural models to manage the
complexity of industrial systems and the variety of stakeholders involved. This is achieved
through specific business models (ITU) and structured architectural viewpoints (IIC).

Fig 1.4: IoT business models identified by ITU

ITU Business Models
The ITU identifies five business models based on how the five key business roles (Device,
Network, Platform, Application Provider, and Application Customer) are managed and
operated.
 Same Organization, Same Fill Pattern: Roles with the same fill pattern in the diagram
are performed by the same single organization (the operator).
 Different Fill Patterns: Roles with different fill patterns are performed by different
organizations (multiple operators).
 Model 1 (Single Operator): One organization handles the roles of Device, Network,
Platform, and Application Provider. This represents full vertical integration.
 Model 2 (Two Operators): One stakeholder is the Device, Network, and Platform
Provider, while a separate stakeholder is the Application Provider. This separates the
infrastructure provision from the service provision.
 Other Models (3-5): Involve further specialization and separation of roles (e.g., separating
the Network Provider from the Platform Provider) among different operators.
IIC Architectural Viewpoints
The Industrial Internet Consortium (IIC) uses four architectural viewpoints to address the
concerns of different stakeholders at different levels of abstraction, ensuring all aspects of an
IIoT system are considered.
1. Business Viewpoint:
 Concerns: Business stakeholders (developers, system engineers, product managers)
who define and specify systems based on factors like Return on Investment (ROI) and
cost of maintenance.
 Mechanism: Defines visions and values that translate into key objectives and then into
high-level business tasks called fundamental capabilities.
2. Usage Viewpoint:
 Concerns: How the system is actually used, implementing the objectives defined in
the Business Viewpoint. Stakeholders include engineers, product managers, and end
users.
 Mechanism: Describes the system's activities, the involved parties (humans or
machines) and their roles, and precisely specified tasks (actions executed by parties).
Tasks are detailed using functional and implementation maps.
3. Functional Viewpoint:
 Concerns: System and subsystem developers, product developers, managers, and
system integrators.
 Mechanism: Presents the functional architecture of the IIoT system, detailing its
components, dependencies, and coordination to meet the requirements set by the Usage
Viewpoint.
4. Implementation Viewpoint (Implied Context): Addresses the real-world technologies
and components needed for deployment.
Functional Viewpoint and OT-IT Integration
The IIC Functional Viewpoint is specifically focused on the integration of Industrial Control
Systems (ICS)—which are the core of Operational Technology (OT)—with classical
Information Technology (IT) systems.
 OT's Independent Evolution: OT systems (developed by control engineers) evolved
separately from IT due to their primary goals of continuous operation, safety, and real-time
constraints. They use different technologies to directly interface with the physical
environment via sensors and actuators.
 The Convergence Challenge: While modern ICS now have the capabilities for complex
IT operations (e.g., high-volume data analysis and optimization), their increased
complexity makes them more vulnerable to failures and cyber-attacks. The IIC model aims
to provide a unified model that effectively integrates these disparate systems while meeting
stringent IIoT requirements.

IIC Functional Domains

Fig 1.5: The IIC reference architecture functional domains

The five domains group functionality required for distinct, high-level system operations,
showing the data and control flow among them.
1. Control Domain
 Functionality: Represents the core control loop realized by Industrial Control Systems
(ICS).
  Components: Contains the sensors, logic, and actuation that constitute a physical plant
or process.
2. Operations Domain
 Functionality: Includes functions required for the efficient monitoring, management,
and optimization of the industrial control systems in the Control Domain.
 Goal: Ensures continuous operation, meets real-time requirements, and achieves low-
power objectives.
3. Information Domain
 Functionality: Responsible for collecting and analyzing data from all other domains.
 Goal: Enables high-level decisions for system-wide coordination and optimization (e.g.,
coordinating multiple control loops).
4. Application Domain
 Functionality: Includes application-dependent functionality, such as the models and
operation rules specific to the IIoT application at hand.
 Interfaces: Contains the APIs and user interfaces that allow other applications or human
users to interact with the system.
5. Business Domain
 Functionality: Includes systems and functions for management and decision-making at
the business level.
 Examples: Systems like Enterprise Resource Planning (ERP) and Manufacturing
Execution Systems (MES).
IIC and ITU Complementarity
The IIC functional decomposition is centered around the concept of a control plant and can
be applied hierarchically. While not a layered model itself, the IIC architecture also identifies
"crosscutting functions" (e.g., connectivity, distributed data management, analytics,
intelligent control).
 These crosscutting functions effectively constitute a layered architecture analogous to the
one defined by the ITU.
 Complementary Viewpoints: The IIC approach is considered a generalization of the ITU
model. It uses the ITU-like layers for infrastructure (crosscutting functions) but adds the
detailed five functional domains within or across those layers, providing a complete model
for all stakeholders, from business leaders to device designers.
Implementation Viewpoint
The Implementation Viewpoint addresses the technical and technological details needed to
build a complete IIoT system based on the Functional Viewpoint.
 It includes technical requirements, communication protocols, interfaces, and importantly,
the mapping of functional blocks onto typical implementation architectures, such as:
 The three-tier architecture (Edge, Platform, and Enterprise).
 The layered databus architecture.

1.5 Basic Technologies

The evolution of the Industrial Internet of Things (IIoT) is built upon several basic
technologies common across all application domains, primarily focused on sensing, cyber-
physical systems, and connectivity.
1. RFID (Radio-Frequency Identification)
 Function: Enables the wireless transmission of a microchip's identification information
to a reader.
 Significance: It was one of the first technologies to support the IoT concept, allowing
for the automatic identification, monitoring, and operation execution related to
tagged items.
 Application: Widely adopted since the 1980s, especially in logistics and supply chain
management.
2. Wireless Sensor Networks (WSN)
 Function: Networks of smart, often battery-operated, sensors widely employed in
industrial automation and critical infrastructures.
 Challenges: WSN solutions must address:
 Communication reliability and real-time requirements.
 Low-power communication (due to battery dependence).
 Advancements: Significant progress has led to numerous standards for reliable and
efficient communication in various environments, including:
 WLAN
 Zigbee
 Bluetooth
 6LoWPAN
 Result: This evolution has resulted in the development of smart (intelligent) sensors,
some of which are autonomous and do not require recharging.
3. Communication Protocols (Higher Level)
Beyond the low-level protocols necessary for basic connectivity, higher-level protocols are
essential to support distributed computing and IIoT applications:
 Service Discovery: Protocols like multicast DNS (mDNS) are used to find and locate
services on the network.
 Application Protocols: These are specifically designed to be suitable for various IIoT
application domains:
 Constrained Application Protocol (CoAP): Designed for constrained devices and
networks.
 Message Queue Telemetry Transport (MQTT): A lightweight messaging protocol
often used for sensor data transmission.
 Advanced Message Queuing Protocol (AMQP): Used for robust, interoperable
messaging in enterprise systems.

1.6 IIoT Applications and Challenges

Industrial Internet of Things (IIoT) applications are widespread in critical infrastructure, using
Industrial Control Systems (ICS) like PLCs and SCADA as the basic computing platform
due to their high processing capacity, real-time management ability, and high availability.
Key IIoT Application Areas
 Energy Sector (Forerunner): The most demanding sector, using ICS platforms end-to-
end from power production and processing to distribution networks (electricity, smart
grids) and consumption.
 Other Critical Infrastructure: Includes water distribution and management networks, oil
and gas distribution (pipelines, storage), and transportation (traffic light management, toll
payment).
Illustrative Challenges in the Power Sector
The path toward full IIoT realization presents several complex challenges, illustrated here by
the power sector:
1. Grid Stability and Fault Diagnosis:
 Problem: Monitoring the state of the power grid with distributed, interconnected
generators to ensure continuous operation.
 Challenge: Conventional distributed fault diagnosis methods are limited because they
don't adequately address the nonlinear dynamics of the grid's behavior.
  Solution Focus: Developing advanced techniques for fault detection and isolation
based on nonlinear modeling, state estimation, and statistical criteria using distributed
sensor networks.
2. Power Optimization for Large Consumers:
 Problem: Efficiently managing and controlling power consumption in large
organizations (e.g., hospitals).
 Challenge: Data preparation (cleaning, accounting, grouping, conversion) is a critical,
time-consuming process due to heterogeneous environments.
 Solution Focus: Using pattern recognition methods to identify actual consumer
behavior patterns and develop desired consumption patterns that lead to lower energy
use.
3. Large-Scale Deployment and Configuration:
 Problem: Installing and configuring IIoT components at a massive scale (e.g.,
buildings, energy networks).
 Challenge: The high complexity and heterogeneity of cyber-physical systems, strict
requirements for secure wireless connections in resource-limited devices, and the
error-prone nature of large-scale installation processes (like the "outside-in" sequence).
 Solution Focus: Developing effective tools for the management and simplified
deployment of IIoT resources, such as wireless sensors and their networks.
4. Integration and Interoperability:
 Problem: Integrating smart, identifiable objects (with wireless cards for product
lifecycle management) into the layered industrial enterprise infrastructure.
 Challenge: Achieving interoperability across the highly heterogeneous industrial
environment, which spans from high-level ERP systems down to low-level production
management systems.
 Benefit: Meeting this challenge enables increased flexibility and autonomy within the
enterprise by mapping processes onto IIoT "things."
 Chapter 2: Security and Safety
2.1 Introduction
This chapter introduces the critical challenge of securing and ensuring the safety of IoT and
IIoT systems, given the interdisciplinary nature resulting from the convergence of Information
Technology (IT) and Operational Technology (OT).
1. The Control Loop Model
IoT applications generally follow a control loop model

Fig 2.1: Control loop

 Process: Measurements from a controlled Device (D) are collected by Sensors and sent to
a Control Center (C). C performs calculations, makes decisions, and sends necessary
Control Actions to Actuators on D.
 Examples:
 Health: Sensors measure patient parameters (e.g., glucose), C (monitoring program)
decides to notify a doctor or command an insulin pump (actuator).
 Manufacturing: Sensors detect a component's arrival; C sends commands to the
machine (actuator) for processing.
3. Hierarchical Computing Structure (For Industrial Systems)
 Fig 2.2: Hierarchical computing structure for control loop
The control loop is often implemented on a hierarchical structure, especially in industrial
settings:
 Lowest Level: Sensors and Actuators are attached to the physical device (D).
 Control Level: Programmable Logic Controllers (PLCs) implement simple, localized
controls (e.g., one per pump or transformer).
 Supervisory Level: The SCADA (Supervisory Control and Data Acquisition) system
implements the complete control loop for the entire process or "plant."
3. Safety, Security, and Dependability
Achieving required system properties (like avoiding grid overload or tank overflow) relies on
meeting multiple core security and dependability goals.
Safety and Security Interdependence:
 Safety Requirements: Are often expressed as requirements on the control loop based on
assumptions about the infrastructure (e.g., temperature measurements are correct).
 Security as a Prerequisite for Safety: An explicit security property (e.g., personal data
protection) and an implicit one (data integrity) are necessary for safety. If data integrity is
compromised (a security failure), the system can become unsafe.
Core Security Requirements (Addressing All Stakeholders)
The following core requirements are essential across IoT/IIoT:
1. Confidentiality: Protecting stored or transmitted data from disclosure.
2. Integrity: Verifying the correctness and completeness of related data.
3. Authentication: Identifying any party (producer, processor, transmitter, receiver) involved
in a transaction.
4. Access Control: Ensuring service is provided only to authorized users.
5. Non-repudiation: Preventing participants from denying their actions or participation in a
transaction.
6. Dependability: Provisioning system functionality continuously, even in the presence of
errors, failures, and strict real-time requirements.
7. Safety: A service/process requirement that warrants service provisioning without hazard to
users.
8. Privacy: Protecting personal information from unauthorized access.

4. Differentiating Factors in IoT/IIoT Security

Traditional IT security methods are insufficient because of unique characteristics in the

IoT/IIoT context:
 Vast Scale & Resource Constraints: Embedded and CPS systems are deployed in
significantly larger numbers than typical IT systems, are often resource-limited
(computation, communication, power), and have strong low-cost requirements.
 Diverse & Hostile Environments: Systems are deployed in various environments,
including hostile ones where malicious users can tamper with them for extended periods.
 Strict Safety Requirements: Domains like automotive, industrial, and medical have high
stakes for safety.

5. Security Property Layering

Fig 2.3: Security property layers

Security requirements are organized into layers to define their dependencies:
 System-Level (Primitives): Security (Confidentiality, Authentication, etc.) and
Dependability (Reliability, Availability). These focus on technical resilience against
malicious attacks and accidental failures, respectively, and are often complementary.
 Application/Process-Level (Goals): Safety and Privacy, these are achieved by employing
the system-level mechanisms (e.g., safety depends on data integrity, which is a security
mechanism).
 Note: Privacy is a safety issue in certain contexts (e.g., financial transactions).
6. IoT/IIoT Threat Model
The threat model includes:
 Computational Attacks: Malicious actions that affect program execution or lead to
information leakage.
 Data Attacks: Attacks on input or communicated data.
 False Data Injection (FDI) Attacks: An emerging class of attacks where
inappropriate data is maliciously input to a control system to force a wrong decision.
These are primarily safety attacks.
 Example: Inputting a false high temperature reading to an HVAC system to trick
it into lowering the temperature unnecessarily, potentially creating hazardous
conditions.
2.2 Systems Security
IoT systems are embedded computing systems with a typical structure comprising four main
subsystems: processing, memory, input/output (I/O), and power. Securing an IoT system
requires protecting the system as a whole and protecting all of its individual components based
on the operational environment and expected attacker capabilities.

Fig 2.4: Organization of a typical IoT system

Physical and Hardware Security
Security for stand-alone IoT devices starts with protecting the hardware itself through anti-
tampering techniques:
 Anti-Tampering Techniques: These address physical and hardware attacks by providing
different levels of protection:
 Tamper Evidence: Simply indicates if a device has been tampered with.
 Tamper Response: Combines detection with a reaction, such as taking appropriate
action (e.g., destroying stored sensitive data) after tampering is detected.
 Tamper Resistance: Methods designed to prevent tampering and protect sensitive data
from attacks.
 Defending Against Advanced Attacks: Traditional encryption is often insufficient in
resource-limited systems. Defenses must counter sophisticated hardware attacks:
 Side-Channel Attacks: These exploit physical implementation parameters of
cryptographic algorithms, such as timing and power consumption, rather than attacking
the algorithm itself.
 Fault Injection: Introducing faults during cryptographic computations to compromise
the system.
 Hardware Defenses: Complex hardware systems require specialized solutions:
 Execute-Only Memory: A specialized design that allows instructions to be
executed but prevents any other manipulation (protecting sensitive programs).
 Encrypted Buses: Protect data from leakage while being transferred between a
processor and memory.
 Decay Caches: Protect against side-channel attacks by preventing cache
information leakage.
 Hardware Trojans: Malicious circuitry that can be planted during the design and
manufacturing phase, making systems insecure before deployment.

Software Security and Trusted Platforms

Defending against the wide range of attacks on embedded and cyber-physical systems requires
a combination of hardware and software techniques, especially in more complex systems
that include operating systems or specialized middleware.
 Establishing System Integrity: Essential software techniques include:
 Secure Booting: Used to establish the integrity of the system at startup.
 Process Isolation: Separating running processes to limit damage from a compromise.
  Process Level Attestation: Techniques used to verify the integrity of running
processes.
 Managing Complex Systems: Security must also be considered for core operating system
functions like context switching, exception handling, inter-process communication, and
memory management.
 Trusted Computing: Combining software techniques with trusted computing modules
enables the development of trusted computing platforms for applications and services,
offering a cost advantage over purely hardware-based security solutions.

2.3 Network Security

Secure communication in IoT relies on three main areas: using the right encryption, managing
secret keys, and defending against massive attacks like DDoS.
1. Encryption and Resource Limits
Traditional encryption (like AES or RSA) is often too computationally heavy for the small,
limited-resource IoT devices.
 Better Option: Elliptic Curve Cryptography (ECC) is preferred because it offers high
security with lower computational demands.
 Standards: New standards like SHA-3 are being developed specifically for the limited
resources of IoT environments.
 Sensor Networks: These use very simple, low-power encryption, sometimes prioritizing
link-layer security and varying the security strength based on the data's importance.
2. Key Management
If the secret keys are weak or exposed, the best encryption is useless.
 Problem: Simple global keys are too easy to compromise.
 Solutions: Systems must use secure methods to generate and share keys, such as:
 Using temporary global keys to establish a main key, then destroying the global key
to prevent leakage.
 Random key distribution, where communication uses random subsets of a large key
pool.
3. Traffic Filtering and Attacks
 Firewalls: Since IoT devices have very specific communication needs, firewalls can be
strictly configured to allow only legitimate traffic. For small, ad hoc networks,
protection must be at the device level (node), while larger networks can use centralized
protection.
  Denial-of-Service (DoS/DDoS): This is a huge threat where attackers overload a
system's resources (network, processor) to shut it down.
 Vulnerability: IoT devices are often exploited because they are not automatically
updated (unpatched) and can be easily infected with malware (like the Mirai botnet)
to become part of a massive attack on a global target.
 Defense: Involves Intrusion Detection to spot the attack and Traceback schemes to
find the source.
2.4 Generic Application Security
Generic application security focuses on protecting the foundational services and infrastructure
that support all distributed IoT/IIoT applications, primarily addressing the client-server model
and the necessary process of system updating and upgrading.
Distributed Application Model
Most IoT applications use a client-server model where remote IoT devices (clients) connect
to servers or the cloud to exchange information.
 Clients (IoT Devices/PLCs): Execute simpler, local control loops. They collect data,
monitor local parameters (e.g., patient vital signs, engine status), and send reports/alarms
to the server.
 Servers (Cloud/SCADA): Execute hierarchically higher level operations. They collect and
aggregate data, monitor overall processes, and send control programs or tuning information
back to the devices (e.g., changing data collection frequency, coordinating a complete
industrial process). In IIoT, this hierarchy is often seen between PLCs (clients) and the
SCADA system (server).
Generic Security Support
Generic application security provides shared services necessary for the IoT environment,
independent of the specific process (e.g., health, industrial). This includes:
1. Defense Against Distributed Denial-of-Service (DDoS)
 Function: Mechanisms to protect the application from being overwhelmed by traffic.
 Implementation: These solutions leverage the network- layer mechanisms (as
discussed in the previous section) but extend them to account for the specifics of the
application configuration, such as the location of the servers.
2. Secure Upgrading and Patching
  Challenge: The ability to transmit code for fixing bugs or adding new features raises
the security risk of a malicious party inserting harmful code instead of legitimate
software.
 Security Requirements: Mechanisms must be included in upgrade services to warrant
secure and safe updating of IoT systems.
 Approaches to Secure Upgrading:
 Limiting Critical Updates: Prevent or limit the ability to upgrade software
components that manage critical system resources in highly hostile environments.
 Strict Access Control: Use strict control mechanisms to allow different operators
to upgrade different software components in safer environments.
 Controlled Transmission: Prevent mobile code transmission, while allowing wired
code transmission only when the connection environment is controlled.
2.5 Application Process Security and Safety
Application processes in IoT/IIoT, such as control loops in industrial or smart grid
environments, execute code to calculate outputs and implement actions. They inherently have
safety requirements that must be met (e.g., hot air temperature must stay within a specified
range).
The Interdisciplinary Challenge
Providing security and safety in IIoT is a major interdisciplinary challenge:
 Safety Requirements are application-dependent and typically set by control engineers
based on the physics and engineering of the controlled system (OT domain).
 Security Requirements (a prerequisite for safety) come from computer and network
security since the systems are distributed computing platforms (IT domain).
 The Link: Security is a prerequisite for safety. A compromise of computing or network
security can lead to wrong calculations and, consequently, wrong actions that violate the
required safety properties.
The Verification and Monitoring Approach
The most promising integrated approach to handling both safety and security from a
computational perspective is to treat the problem as one of verification and monitoring based
on application specifications:
1. Specification: Application designers (e.g., control engineers) first provide a precise
executable specification of the application, including all required safety properties.
2. Verification: The produced application software is verified to ensure it meets all the set
requirements (including security from vulnerabilities).
3. Monitoring (Runtime Assurance): The execution of the verified program is monitored to
ensure it is not altered and executes exactly as expected based on the initial specification.
This is a behavioral approach to safety and security, where the required and expected
application behavior is defined by the executable specification itself.

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

The concept of reliable-and-secure-by-design extends the old idea of correct-by-
construction programming to the complexity of IoT and Cyber-Physical Systems (CPS).
Core Challenges in IoT/CPS
Unlike traditional programs with simple, discrete behaviors, IoT systems face unique
challenges:
 Cyber-Physical Interaction: IoT systems interact with the real world, meaning their
behavioral models must handle continuous and nonlinear characteristics.
 Environmental Modeling: It's challenging to model the uncertain variations of the
environment that affect physical subsystems.
Approaches to Secure-by-Design
Recent efforts focus on creating programming environments that ensure reliability and security
are built in, often using advanced mathematical logic and proofs:
 Ur/Web Language: This environment is designed for reliable and secure web applications.
It uses an enriched type system to guarantee the application won't have vulnerabilities (like
code injection) and won't crash.
 Jeeves Language: This language focuses on run-time security, ensuring programs do not
violate defined security policies during execution.
 Cyber-Physical System (CPS) Frameworks: These use formal proof assistants to verify
complex models:
 ROSCoq: Uses the Coq proof assistant to model robot resources and prove various
properties about the cyber and physical model.
 VeriDrone: A reasoning framework that ensures the security of CPS models at different
levels, from high-level models down to the underlying C code implementation.
2.7 Run-Time Monitoring
Run-time monitoring systems are classified into four types based on two questions: What is
the behavior description based on? (Profile or Model) and How is the threat detected?
(Match Bad Behavior or Deviate from Good Behavior).

Fig 2.5: Classification of run-time security monitoring systems

Behavior Described by a Profile (Statistical Approach)

These systems build a statistical picture of the system's operation.
1. Match Bad Behavior (Class 1):
 How it Works: Creates a statistical profile of known attacks using machine learning.
 Trade-offs: It's robust because it generalizes from data, but it has a high false alarm
rate and gives limited information about why the alarm went off.
2. Deviate from Good Behavior (Class 3):
 How it Works: Creates a statistical profile of normal/good operation and flags
anything outside that norm.
 Trade-offs: It's the most robust against new, unknown attacks (since any change is
flagged). However, it has a high false alarm rate (a deviation might be normal, just
rare) and provides limited diagnosis.
Behavior Described by a Model (Formal Approach)
These systems use a formal, predefined blueprint of the system's expected behavior.
1. Match Bad Behavior (Class 2):
 How it Works: Uses a model of known malicious behaviors (like signature-based
detection).
  Trade-offs: Provides rich diagnostic information when an attack matches a known
signature. However, it can only detect known attacks.
2. Deviate from Good Behavior (Class 4):
 How it Works: Uses a detailed model of correct/safe behavior and flags any step that
deviates from the blueprint.
 Trade-offs: Provides the highest diagnostic information (can pinpoint the exact fault,
like a specific instruction). However, creating and running this detailed model causes
significant execution overhead, limiting performance.
2.8 The ARMET Approach
The ARMET approach is a promising method for unifying safety and security in IoT/IIoT
systems, based on three core concepts: secure-by-design development, run-time monitoring,
and adaptive recovery.
The ARMET Structure and Process
ARMET is built around the idea of executing a formal application specification in parallel with
the actual application code to ensure correctness.
 Secure-by-Design: An IoT application starts with an executable specification that is
provably consistent with the application's safety properties. The final application code is
derived from this specification.
 Run-Time Monitoring: The ARMET middleware monitors the executing application by
running the executable specification in parallel to calculate predicted behavior.

Fig 2.6: The ARMET system

Figure 2.6 shows the structure of the ARMET middleware system, which is composed of the
run-time security monitor, diagnosis, recovery, trust model, adaptive method selection, and
backup modules.
 Recovery: When a deviation (failure or attack) is detected, the system uses the diagnostic
information and a backup of previous states to choose an adaptive recovery method. Even
for unknown failures or attacks, the system can recover by reverting to a previous clean
state.
 Key Assumption: The executable specification must run in a safe environment (e.g.,
using trusted platforms like Intel SGX) so its predictions are always correct.
ARMET's Effectiveness and Verification
 RSM Properties: The Run-Time Security Monitor (RSM) has been formally proven to
be sound and complete. This means the monitor is guaranteed to detect all
computational attacks (complete) and is free of false alarms (sound).
 Example: Water Tank Control
o Consider a water tank with pumps to control water height.

Fig. 2.7: Water tank

Figure 2.7 illustrates this setup. The system operates based on an executable specification,
which includes the safety property that the tank never overflows.
 Fig. 2.8: Water tank control executable specification
Figure 2.8 shows one executable specification (written in UML) that implements the three
defined actions (FILL, DRAIN, NOTHING). Attack Detection: If an attacker attempts a False
Data Injection (FDI) attack by altering the sensor reading to a lower value (to cause
overfilling), the RSM detects the attack. The monitor identifies the deviation between the
false sensor reading and the expected water level calculated by the specification, raising an
alarm and stopping the unsafe action.
The ARMET approach provides a powerful behavioral tool for protecting complex processes
and applications in the IoT space.
2.9 Privacy and Dependability
Privacy protection and system dependability are two significant, yet often overlapping,
challenges in IoT/IIoT. The behavioral approach to security provides a way to unify solutions
for both.
Privacy Protection
Privacy is a major challenge due to increasing legal requirements (e.g., in health, smart grids,
and home environments) restricting the collection, storage, and processing of personal data.
 Solutions Needed: Require adaptive and scalable solutions that integrate methods like
time-limited data storage, access control, and accounting systems for auditing.
 Privacy as a Safety Property: The ARMET approach views privacy requirements as
safety properties.
 Legal requirements can be expressed as conditions (preconditions, postconditions, or
invariants) within the application's program.
 These conditions can be enforced by a run-time monitor (like ARMET's RSM), which
detects any attempt to violate them.
 This programmability allows for dynamic adjustment of monitors as new legal
frameworks emerge.
Dependability and Security Unification
Traditional dependable systems are based on accidental fault models (e.g., random hardware
failures), which are fundamentally different from the malicious faults inserted by security
attackers.
 The Behavioral Advantage: The behavioral approach (which monitors for deviation from
expected program behavior) unifies these two challenges:
 It focuses only on the deviation from the correct behavior (the "attack model") and is
not influenced by its origin (accident or malice).
 It detects accidental faults and malicious attacks using the same method.
 Attribution: Attribution of the fault (determining if it was accidental or malicious) is done
only after detection and is based on available information and the system's trust model
(as seen in ARMET).
 Conclusion: This approach provides a powerful unified framework for security and
dependability.