deliverable d2.4 architecture and technical specifications · 2019. 9. 22. · john soldatos,...

This document is part of a project that has received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement No 779899. It is the property of the SecureIoT consortium and shall not be distributed or reproduced without the formal approval of the SecureIoT Management Committee.

Project Acronym: SecureIoT

Grant Agreement number: 779899 (H2020-IoT03-2017 - RIA)

Project Full Title: Predictive Security for IoT Platforms and Networks of Smart

Objects

DELIVERABLE D2.4 – Architecture and

Technical Specifications Deliverable Number D2.4 Deliverable Name Architecture and Technical Specifications Dissemination level Public

Type of Document Report

Contractual date of delivery 30/09/2018

Deliverable Leader AIT

Status & version V1.00

WP / Task responsible WP2(FUJITSU) / Task T2.4(AIT)

Keywords: Security, Architecture, Probes, Data Collection, Security

Monitoring

Abstract (few lines): This deliverable presents the first version of the architecture of

the SecureIoT security monitoring platforms. The architecture

is primarily presented in terms of a logical view, which includes

its main components and the interactions between them. Other

views (implementation, process, deployment) are also

discussed, while early examples on how this architecture can be

used for implementing the project’s use cases are given.

Deliverable Leader: Athens Information Technology (John Soldatos, Sofoklis

Efremidis)

Contributors:

Daniel Calvo (ATOS), George Moldovan (SIEMENS), David Evans

(IDIADA), Nikos Kefalakis (INTRA), Jérôme François (INRIA),

Abdelkader Lahmadi (INRIA), David Schubert (Its-OWL),

Sofianna Menesidou (UBI), Sofoklis Kyriazakos (iSprint),

Pouyan Ziafati (LuxAI)

Reviewers: Giannis Ledakis (SiLO), Nechifor, Cosmin-Septimiu (SIEMENS)

Approved by: George Koutalieris (INTRA)

Page |2

Project Title: SecureIoT Contract No. 779899 Project Coordinator: INTRASOFT International S.A.

D2.4 – Architecture and Technical Specification of SecureIoT Services

Version: v1.0 - Final, Date 30/09/2018

Executive Summary This deliverable introduces the SecureIoT architecture for the security of IoT systems. The

architecture is presented as a set of modules, along with the structuring principles that drive their

integration in an IoT security system that emphasizes security monitoring, security analytics and

security automation. In order to define these modules and their structuring principles, SecureIoT

has taken into account a number of reference architectures for IoT systems (like RAMI4.0 and

the Reference Architecture of the Industrial Internet Consortium), as well as related security

frameworks (such as the Industrial Internet Security Framework). The reference IoT architectures

have been exploited as means of understanding the structure of the IoT systems to be monitored

and protected, while the security frameworks have been used as basis for defining building blocks

for security data collection and analysis, as well as security monitoring and automation.

The SecureIoT architecture is a data-driven architecture, which is defined as an overlay layer that

protects all assets of an IoT system. It collects security-related information for IoT devices

through a number of probes, while at the same time analyzing this information in order to

identify abnormal behaviors and instigate alerts or invoke security automation functions. The

architecture specifies a powerful “templates” mechanisms, which allows for the characterization

and identification of abnormal or suspicious behaviors, based on the execution of advanced data

analytics algorithms over the security-related data that are collected from the various probes. It

also provides the means for customizing and contextualizing the various templates according to

the status of the IoT system that is being protected. Furthermore, the SecureIoT architecture

introduces an IoT security knowledge base component, which can be used to match identified

abnormal or suspicious behaviors with known vulnerabilities or attacks.

The architecture provides also the means for collecting and analyzing information from different

IoT devices and platforms based on appropriate probes and a common modelling of the security-

related information regardless of the platform for which it is collected. As such it can also support

monitoring and protection of IoT systems and applications that span multiple platforms, as part

of security interoperability scenarios. This is in-line with one of the main objectives of the project,

which is to support security for applications that span multiple, diverse IoT platforms.

As part of the deliverable, the various components of the SecureIoT architecture are described

along with the interactions and information flows between them. To this end, the architecture is

introduced in terms not only of its logical viewpoint, but also in terms of its process viewpoint as

well. Furthermore, development and physical deployment aspects are briefly discussed as well,

as part of 4+1 views approach to introducing the SecureIoT architecture.

Based on the SecureIoT architecture, the project will create an IoT security platform which will

be used to support the project’s services and use cases. This platform will expose a set of APIs to

developers and deployers of IoT security services. These APIs are briefly outlined in the

Page |3




deliverable, along with the structure of the SECaaS (Security as a Service) services that will make

use of them, notably risk assessment, compliance auditing and developers support services. It is

also discussed how the SecureIoT architecture can be used to produce alerts and notifications as

part of a security monitoring system. Moreover, the present deliverable provides some early

insights on the technologies and frameworks that will exploiting towards implementing the

SecureIoT platform in-line with the introduced architecture.

As part of the deliverable we also illustrate the high-level structure of the security systems that

will support the project’s use cases. The design of these systems will be detailed and elaborated

as part of WP6 of the project. Nevertheless, this early mapping has been performed a vehicle for

confronting the use cases requirements against the capabilities and functionalities that are

offered by the SecureIoT architecture. Moreover, it boosts adherence to the 4+1 methodology

that has been selected as a vehicle for presenting the SecureIoT architecture.

Overall, the present deliverable provides insights on the structure and main components of

SecureIoT compliant security systems. It can therefore serve as a blueprint for the integration of

IoT security services and use cases in the scope of WP5 and WP6 respectively. However, the

security components of the architecture will be specified in detailed and accordingly

implemented as part of WP3 (dealing with the data collection components) and WP4 (dealing

with the security analytics components). Note also that the present deliverable provides the first

version of the architecture. A second and final version will be also delivered in M18 of the project

as part of deliverable D2.5. The final version of the architecture will enhance and fine-tune the

one introduced in this deliverable in order to meet new and updated requirements. It will also

incorporate feedback from the actual deployment and use of the architecture in WP5 and WP6

of the project.

Page |4




Document History

Version Date Contributor(s) Description

V0.11 16/05/2018 Sofoklis Efremidis (AIT) Initial Structure

V0.14 11/06/2018 John Soldatos (AIT) Revisions following discussions during

the Bilbao Meeting

V0.15 29/06/2018 John Soldatos (AIT) Information about the scope and

methodology

V0.16 03/07/2018 Sofianna Menesidou (UBI) Inputs in Section 2

V0.20 04/07/2018 John Soldatos (AIT), Sofoklis

Efremidis (AIT)

Updated Structure based on

comments on released version

V0.21 19/07/2018 John Soldatos (AIT) First Draft of Section 3 (Logical View

of the SecureIoT architecture)

V0.23 17/08/2018 Daniel Calvo (ATOS)

Analysis of IoT RAs: IoT-A, ISO/IEC

30141 and IDS.

Analysis of FIWARE IoT platform

V0.24 20/08/2018 John Soldatos (AIT) Updates to Section 3

V0.25 21/08/2018 John Soldatos (AIT)

Inputs to Section 5 on implementation

technologies for probes and data

routing

V0.26 29/08/2018 Sofianna Menesidou (UBI) Inputs in Sub-Section 4.2

V0.27 05/09/2018 David Evans (IDIADA) Connected Cars Use Cases, Section 6

V0.28 05/09/2018 John Soldatos (AIT) Inputs on RAMI V4.0

V0.30 06/09/2018 John Soldatos, Sofoklis Efremidis

(AIT) Enhancements to Section 2

V0.32 10/09/2018 Daniel Calvo (ATPS) Connected Cars Use Cases, Section 6

V0.33 13/09/2018 Jérôme François (Inria),

Abdelkader Lahmadi (Inria)

Security Knowledge Base Inputs in

Sections 4 & 5

V0.34 13/09/2018 David Schubert (Its-OWL) Inputs to Section 6.1

V0.35 14/09/2018 John Soldatos (AIT) Addition of Information in Section 2

and editing

V0.36 15/09/2018 Nechifor, Cosmin-Septimiu

(SIEMENS) Inputs to Section 2

V0.37 17/09/2018 Pouyan Ziafati (LuxAI) Description of LuxAI Use Case

Architecture in Section 6

Page |5




V0.38 25/09/2018 Nikos Kefalakis (INTRA) Risk Assessment and mitigation

Specifications

V0.40 25/09/2018 John Soldatos (AIT) Conclusions; Information on

Alignment to other RAs in Section 2

V0.50 26/09/2018 John Soldatos (AIT) Preparation of version for Quality

Review/Control

V0.52 26/09/2018 John Soldatos (AIT) Updates to the four views of the

architecture in Section 3

V0.55 27/09/2018 John Soldatos (AIT) Comments from Quality Review

Implemented

V1.0 30/09/2018 Mariza Konidi (INTRA) Final version to be submitted

Page |6




Table of Contents Executive Summary ......................................................................................................................... 2

Definitions, Acronyms and Abbreviations .................................................................................... 10

1 Introduction ........................................................................................................................... 12

1.1 Scope and Purpose........................................................................................................ 12

1.2 Background and Vision ................................................................................................. 13

1.3 Methodology ................................................................................................................. 14

1.4 Document Structure ..................................................................................................... 16

2 Analysis of State of the Art and SecureIoT Reference Architecture ..................................... 18

2.1 Standard Reference Architectures and Reference Architecture Models ..................... 18

2.1.1 RAMI 4.0 .................................................................................................................... 18

2.1.2 Industrial Internet Consortium Reference Architecture (IIRA) ................................. 20

2.1.3 Industrial Internet Security Framework (IISF) ........................................................... 23

2.1.4 OpenFog Reference Architecture ............................................................................. 24

2.1.5 IoT-A .......................................................................................................................... 26

2.1.6 ISO/IEC 30141 ........................................................................................................... 29

2.1.7 Industrial Data Space – IDS ....................................................................................... 31

2.2 Review of Architectures from Related R&D Projects and Initiatives ............................ 33

2.2.1 H2020 PaasWord ...................................................................................................... 33

2.2.2 FP7 RERUM ............................................................................................................... 34

2.2.3 H2020 GHOST ............................................................................................................ 35

2.3 Architectures and Security Features of Relevant IoT Platforms ................................... 35

2.3.1 SIEMENS MindSphere ............................................................................................... 35

2.3.2 FIWARE ...................................................................................................................... 37

2.3.3 CloudCare2U ............................................................................................................. 41

2.4 Driving Requirements ................................................................................................... 42

2.5 The SecureIoT RA .......................................................................................................... 43

2.5.1 Overview ................................................................................................................... 43

2.5.2 Tiers ........................................................................................................................... 44

2.5.3 Cross-Cutting Functions ............................................................................................ 45

3 SecureIoT Platform Architecture ........................................................................................... 47

Page |7




3.1 Overview ....................................................................................................................... 47

3.2 Logical View .................................................................................................................. 47

3.2.1 Overview ................................................................................................................... 47

3.2.2 The Data Collection and Actuation Layer ................................................................. 50

3.2.3 The Security Intelligence Layer ................................................................................. 53

3.2.4 The SECaaS Layer ...................................................................................................... 56

3.2.5 The Use Cases Layer .................................................................................................. 56

3.3 Development View ........................................................................................................ 56

3.4 Process View ................................................................................................................. 57

3.5 Physical View ................................................................................................................. 58

4 SecureIoT Security Services Specifications ............................................................................ 60

4.1 Risk Assessment and Mitigation ................................................................................... 60

4.1.1 Data collection specifications ................................................................................... 60

4.1.2 Data Analytics Specifications .................................................................................... 60

4.1.3 Security Policy Enforcement Points Specification .................................................... 60

4.1.4 Cross Layer Data Exchange Specifications ................................................................ 61

4.1.5 Cross Platform Data Exchange Specifications ........................................................... 61

4.2 Developer Support Services .......................................................................................... 62






4.3 Compliance Auditing ..................................................................................................... 64






4.4 IoT Security Knowledge Base ........................................................................................ 65


Page |8









4.5 SECaaS Services Management and Configuration ........................................................ 67

5 Candidate Implementation Technologies ............................................................................. 69

5.1 Overview and Purpose .................................................................................................. 69

5.2 Implementation Technologies for the Data Collection and Automation Layer ........... 69

5.2.1 Probes and Data Collection Agents .......................................................................... 69

5.2.2 Data Routing and Data Bus ....................................................................................... 70

5.2.3 Data Persistence ....................................................................................................... 70

5.2.4 Management, Configuration and Visualization Tools .............................................. 70

5.3 Implementation Technologies for the Security Intelligence Layer ............................... 70

5.3.1 Data Analytics Engines .............................................................................................. 70

5.3.2 Security Knowledge Base .......................................................................................... 70

5.4 Technologies for Continuous Integration and Configuration of Services at the SECaaS

Layer 71

6 SecureIoT Use Cases Architectures: Initial Approach ............................................................ 72

6.1 Industry4.0 Security Use Cases ..................................................................................... 72

6.1.1 Logical View .............................................................................................................. 75

6.2 Healthcare and Socially Assistive Robots Use Cases .................................................... 75

6.2.1 Logical View .............................................................................................................. 76

6.3 Connected Car and Autonomous Driving Use Cases .................................................... 78

6.3.1 Logical View .............................................................................................................. 79

7 Conclusions ............................................................................................................................ 82

References .................................................................................................................................... 84

Table of Figures FIGURE 1: MAIN METHODOLOGICAL STEPS FOR THE SECUREIOT ARCHITECTURE SPECIFICATION AND VALIDATION ............................... 15 FIGURE 2: REFERENCE ARCHITECTURE MODEL INDUSTRY 4.0 (RAMI 4.0) .................................................................................. 19

Page |9




FIGURE 3: FUNCTIONAL DOMAINS IN IIRA ............................................................................................................................ 21 FIGURE 4: THREE TIER ARCHITECTURE FOR IIOT SYSTEMS – IMPLEMENTATION VIEWPOINT FOR IIRA ............................................... 22 FIGURE 5: SECURITY FUNCTIONALITIES OF THE IISF ................................................................................................................. 23 FIGURE 6: ALIGNMENT OF AN IIOT SYSTEM WITH IIRA AND IISF ............................................................................................... 23 FIGURE 7: BREAKDOWN OF SECURITY MONITORING AND ANALYSIS ............................................................................................ 24 FIGURE 8: OPENFOG REFERENCE ARCHITECTURE DESCRIPTION INCLUDING DIFFERENT PERSPECTIVES ................................................ 25 FIGURE 9: IOT-A ARM UML DOMAIN MODEL. SECTION 3.3.2.2 OF [CARREZ13] ........................................................................ 26 FIGURE 10: FUNCTIONAL COMPONENTS (FCS) FOR EACH FUNCTIONALITY GROUP (FG) OF THE IOT-A ARM [CARREZ13] ................... 27 FIGURE 11: MAPPING OF SECUREIOT MAIN FUNCTIONAL COMPONENTS TO IOT-A ARM MODEL - FIGURE IS JUST AN EXTENSION OF THE

ONE INCLUDED IN SECTION 4.2.2.1 OF [CARREZ13] ...................................................................................................... 28 FIGURE 12: MAPPING OF SECUREIOT MAIN FUNCTIONAL COMPONENTS TO ISO/IEC 30141 MODEL - FIGURE IS JUST AN EXTENSION OF

THE ONE INCLUDED IN SECTION 4.2.2.1 OF [CARREZ13] ................................................................................................. 29 FIGURE 13: ISO/IEC 30141 FUNCTIONAL VIEW OF THE REFERENCE ARCHITECTURE. SECTION 4.2.2.1 OF [ISO/IEC CD 30141-2]....... 30 FIGURE 14: FUNCTIONAL VIEW OF IDS ARCHITECTURE, INCLUDING THE INTERACTION BETWEEN COMPONENTS [HIERRO18] .................. 31 FIGURE 15: IDS ARCHITECTURE RELIES ON IDS COMMUNICATION PROTOCOL TO ENFORCE SECURITY IN DATA EXCHANGES. SECTION 4.1.2

OF [IDS-RA] .......................................................................................................................................................... 32 FIGURE 16: MINDSPHERE CONCEPTUAL ARCHITECTURE ........................................................................................................... 36 FIGURE 17: FIWARE HIGH-LEVEL ARCHITECTURE [FIWAREDEV] ............................................................................................. 38 FIGURE 18: FIWARE IOT STACK WITH IOT AGENTS AND CONTEXT BROKERS AS MAIN FUNCTIONAL COMPONENTS [CALVO18] ............. 39 FIGURE 19: AUTHORIZATION BASED ON OAUTH2.0 FOR FIWARE COMPONENTS [ALONSO18] ...................................................... 40 FIGURE 20: ACCESS CONTROL FOR FIWARE IOT AGENTS AND CONTEXT BROKER ......................................................................... 40 FIGURE 21: SECUREIOT RA (REFERENCE ARCHITECTURE) ......................................................................................................... 44 FIGURE 22: SECAAS PARADIGM OVERVIEW .......................................................................................................................... 47 FIGURE 23: HIGH LEVEL LOGICAL VIEW OF THE SECUREIOT ARCHITECTURE AND MAPPING TO TECHNICAL WORKPACKAGES ................. 49 FIGURE 24: ANATOMY OF THE DATA COLLECTION AND ACTUATION LAYER .................................................................................. 52 FIGURE 25: ANATOMY OF THE SECURITY INTELLIGENCE LAYER ................................................................................................... 54 FIGURE 26: EXAMPLE OF TEMPLATE EXTRACTION AND CONTEXTUALIZATION ............................................................................... 56 FIGURE 27: HIGH-LEVEL DEVELOPMENT VIEW OF SECUREIOT – PACKAGE DIAGRAM .................................................................... 57 FIGURE 28: PLATFORM AND PROBES REGISTRATION – DATA COLLECTION ................................................................................... 58 FIGURE 29: TEMPLATE EXTRACTION AND EXECUTION PROCESS ................................................................................................. 58 FIGURE 30: HIGH-LEVEL SECUREIOT DEPLOYMENT DIAGAM .................................................................................................... 59 FIGURE 31: RISK ASSESSMENT & MITIGATION INTERACTIONS ................................................................................................... 61 FIGURE 32: DEVELOPERS SUPPORT SERVICE MAPPING TO THE SECUREIOT PLATFORM ARCHITECTURE ............................................... 63 FIGURE 33: THE DIFFERENT COMPONENTS OF THE IOT SECURITY KNOWLEDGE BASE ...................................................................... 65 FIGURE 34: THE CLASSES OF THE CTI DATABASE AND THEIR RELATIONSHIPS ................................................................................. 66 FIGURE 35: INDUSTRY 4.0 USE CASE OVERVIEW .................................................................................................................... 72 FIGURE 36: EXAMPLE DIAGNOSTIC DATA PROBE .................................................................................................................... 73 FIGURE 37: EXAMPLE HMD DATA PROBE ............................................................................................................................. 73 FIGURE 38: EXAMPLE CONFIGURATION DATA PROBE .............................................................................................................. 74 FIGURE 39: HIGH LEVEL LOGICAL VIEW OF THE SECUREIOT ARCHITECTURE AND MAPPING ............................................................. 75 FIGURE 40: OVERVIEW OF THE DIFFERENT SUBSYSTEMS INVOLVED IN THE SOCIALLY ASSISTIVE ROBOTS AND IOT APPLICATIONS SCENARIOS

........................................................................................................................................................................... 76 FIGURE 41: LOGICAL VIEW OF SAR SECURITY SYSTEM ............................................................................................................. 77 FIGURE 42: EXAMPLE VEHICLE SPEED PROBE - IDAPT OBU .................................................................................................... 79 FIGURE 43: HIGH LEVEL LOGICAL VIEW OF THE SECUREIOT ARCHITECTURE AND MAPPING ............................................................. 80 FIGURE 44: ANATOMY OF THE DATA COLLECTION AND ACTUATION LAYER INCLUDING THE SYSTEM AND APPLICATION PROBES TO BE

DEVELOPED AND DEPLOYED FOR THE CONNECTED CAR AND AUTONOMOUS DRIVING USE-CASES. ............................................ 81

Page |10




List of Tables TABLE 1: SUMMARY OF FIWARE GES ................................................................................................................................. 38 TABLE 2: FIWARE SECURITY GES ....................................................................................................................................... 39 TABLE 3: SECAAS SERVICES FOR SAR SCENARIOS ................................................................................................................... 77

Definitions, Acronyms and Abbreviations Acronym Title

AI Artificial Intelligence

API Application Programming Interface

AWS Amazon Web Services

CAPEC Common Attack Pattern Enumeration

CAN Controller Area Network

CI Continuous Integration

CMDB Configuration Management Database

CPU Central Processing Unit

CTI Cyber Threat Intelligence

CVE Common Vulnerability and Exposure

CWE Common Weakness Enumeration

ETSI European Telecommunications Standards Institute

GSMA Global System for Mobile Communications Association

IAM Identity and Access Management

IDS Industrial Data Space

IIC Industrial Internet Consortium

IOSK IoT Security Knowledge Base

IIoT Industrial Internet of Things

IoT Internet of Things

IISF Industrial Internet Security Framework

IP Internet Protocol

ISBK IoT Security Knowledge Base

ISTE IoT Security Template Extraction

JSON JavaScript Object Notation

KPI Key Performance Indicator

LDM Local Data Manager

ML Machine Learning

MR Merge Request

NIST National Institute of Standards and Technology

NGSI Next Generation Services Interface

OBU On Board Unit

OrBAC Organisation-based Access Control

OSI Open Systems Interconnection

Page |11




PDP Policy Decision Point

PEP Policy Enforcement Point

PR Pull Request

P-RBAC Privacy-aware Role Based Access Control

RA Risk Assessment

RAM Risk Assessment and Mitigation

RAMI4.0 Reference Architecture Model Industrie 4.0

RArch Reference Architecture

ROS Robotics Operating System

SAR Socially Assistive Robots and IoT Applications

SECaaS Security as a Service

SCM Source Code Management

SKB Security Knowledge Base

SPEP Security Policy Enforcement Point

SPoC Single Point of Contact

TCP Transmission Control Protocol

TEE Template Execution Engine

UMA User-Managed Access

XACML eXtensible Access Control Markup Language

Page |12




1 Introduction 1.1 Scope and Purpose The main goal of the SecureIoT project is to introduce, validate and promote a novel approach to the security of IoT applications, which emphasizes a timely, predictive and intelligent approach to the identification and mitigation of security threats and incidents. One of main characteristics of this approach will be its ability to deal with smart objects, while at same time supporting security interoperability in supply chain scenarios that involve multiple IoT systems and platforms with diverse security capabilities. The project will reflect its approach to an architectural concept, which will serve as a basis for implementing predictive and intelligent security systems. Based on this overarching architectural concept, the project will develop concrete security services that will be validated in the scope of the project’s use cases.

In this context, the purpose of the present deliverable is to introduce the SecureIoT architecture, along with the architecture of the security platform that will be developed in the project. The latter architecture will be introduced and presented based on a number of interrelated modules and the interfaces between them. Moreover, the deliverable is destined to provide the detailed specification of each one of the modules that comprise the architecture, along with its role in the implementation of the project’s use cases. The outcomes of the deliverable will therefore include the specification of the SecureIoT architecture and the technical specification of the security platform and services that will be implemented based on this architecture. Note that the SecureIoT architecture will serve as a reference for implementer of predictive security systems for IoT platforms and smart objects, through providing proper placeholders for the integration of data-driven security intelligence, beyond the range of algorithms that will be implemented in the project, as part of WP4 of the workplan.

The production of this deliverable is very important in the scope of the project’s workplan, as it is expected to drive the project’s developments in other workpackages. In particular:

• The specification of the building blocks of the SecureIoT platform (and of related compliant systems) will give rise to their detailed design and implementation in other technical workpackages (notably WP3 and WP4).

• The specification of the interfaces between the building blocks of the architecture will drive the integration of the SecureIoT systems and services in WP5, as well as their use in the scope of the use case in WP6.

• The architecture will provide the anatomy of the SecureIoT platform and will shed light on how it should be integrated and customized in order to support the needs of the use cases.

• Finally, the building blocks of the architecture and the SecureIoT platform will provide insights regarding the security modules and results that could become part of the project’s marketplace / ecosystem platform in WP7.

For all the above reasons, the finalized and release of this deliverable signals a milestone in

SecureIoT workplan, namely milestone MS2 “SecureIoT Architecture Specified”.

Page |13




1.2 Background and Vision The vision of the SecureIoT project is to provide new insights on security monitoring and data-driven security intelligence for IoT systems, through enabling the implementation of predictive security systems that can analyse data from IoT platforms and smart objects (i.e. objects with semi-autonomous behaviour). Hence, it is envisaged that the intelligence of the SecureIoT approach will stem from the implementation and integration of data analytics algorithms that will be able to proactively identify security threats and incidents towards more timely preparedness. Nevertheless, part of the SecureIoT intelligence will also stem from the modularity and the dynamic nature of the platform, which will provide the means for dynamically binding new IoT assets (e.g., devices, modules), while at the same time protecting them based on new workflows and data driven algorithms.

The SecureIoT architecture takes into account the rich set of reference architectural models that have been introduced by standards development bodies and industry consortia regarding the structure of IoT systems. Most of these models (e.g., the Industrial Internet Security Framework and the OpenFog Reference Architecture) specify security monitoring and data analysis as one of their core security mechanisms. SecureIoT aims at substantiating these mechanisms based on concrete algorithms and security systems middleware that guarantees modularity, extensibility, configurability and scalability.

Our architecture will serve as a basis for implementing the security systems of the project’s use cases. Hence, three instances of the SecureIoT architecture will be devised and deployed for the three main contexts and application areas of the use cases, namely industrial automation, socially assisted robots and connected cars. Therefore, the project’s use cases will be used for the validation of the architecture i.e. the SecureIoT architecture will be validated against its ability to meet the main security requirements of the use cases. Furthermore, our architecture work will develop a vision about the application of this architecture in other use cases as well. In particular, the SecureIoT architecture should serve as a blueprint for the implementation of IoT security monitoring platforms, including platforms that comprise advanced data analytics. Moreover, this blueprint will be supported by a range of middleware components that will underpin the SecureIoT platform in-line with the architecture introduced in this deliverable.

Overall, the goal of this deliverable is to provide the structuring principles for building standards-based data-driven security monitoring systems for IoT infrastructures and applications, notably systems that can effectively deal with multiple diverse IoT platforms and smart objects.

Page |14




1.3 Methodology Our methodology for specifying the SecureIoT architecture, includes the following activities and

steps (Figure 1):

• Analysis/Review of the state of the art, in terms of relevant IoT projects and initiatives,

notably projects that have dealt with the implementation of data-driven intelligence and data

driven security policies. The aim of this analysis is to take into account insights from these

projects regarding the implementation of relevant IoT security mechanisms. In addition to

reviewing various state of the art initiatives, this methodological step included also a review

of reference architectures that have been introduced by industrial consortia and standards

development organizations, such as the OpenFog Reference Architecture, the Industrial

Internet Security Framework and RAMI4.0 [Schweichhart16]. The review of these reference

architectures provided insights about how to structure the architecture both logically and

physically, based on the consideration of aspects such as the collection and analysis of data

from IoT devices, as well as the specification and implementation of Policy Decision Points

(PDP) and Policy Enforcement Points (PEP).

• Synthesis and Specification of a Security Architecture for IoT systems, based on the

combination of concepts from the analysis of the previous steps, but also based on the

specification of solutions that successfully address the main functional and technical

requirements for the SecureIoT platform, including the requirements listed in earlier

deliverables D2.1 and D2.2. The specification of the SecureIoT Architecture is provided in

terms of a description of its main modules and of the interfaces between them. Emphasis is

paid on providing both logical and physical views of the architecture, while at the same time

documenting both the static and dynamic behavior of a SecureIoT system that adheres to the

architecture. To this end, multiple views of the SecureIoT architecture are provided.

• Validation of the SecureIoT architecture against the project’s scenarios and use cases,

notably the use cases that are specified and implemented in WP6 of the project. This

validation aims at ensuring the appropriateness of the architecture for the project’s use

cases, while at the same time validating that the functional characteristics of systems that

follow the principles of the architecture are sufficient to address IoT security for diverse IoT

platforms and smart objects.

Page |15




Figure 1: Main methodological steps for the SecureIoT Architecture Specification and Validation

In order to serve the objectives of the above-listed methodological steps, we will specify the

SecureIoT architecture based on multiple views, according to the “4+1” views methodology

[Kruchten95]. The latter specifies that an architecture can be described based on four

complementary views including a logical view, a process view, a development view and a physical

view. These views are complemented by a set of specified scenarios and use cases, which are

used to validate the architecture (see side figure). In the case of SecureIoT, a set of reference use

cases have been already specified as part of deliverable D2.1, while the use cases that will be

actually implemented are currently being elaborated under WP6 of the project. As outlined in

the side figure, in the 4+1 approach special emphasis is paid in the logical view, which drives the

specification of the development, and of the process view. The logical view depicts the high level

view of the architecture, including its main components and the way they are structured

together. Following the specification of the logical view, a development view can be derived and

elaborated in order to provide insight on the

implementation task of the architecture, while a

process view can be also elaborated in order to show

the dynamic behavior of the system, including

interactions and information flows between the various

components. Finally, the physical view provides insights

on the physical implementation and deployment of a

system that is based on the specified architecture. In-

line with this approach, the present deliverable has put emphasis on the presentation and

elaboration of the logical view, as the most representative and foundational view of the

Ste

p1

-R

evi

ew &

An

alys

is o

f Sta

te o

f th

e A

rt Review of Relevant Projects and Initiatives

Analysis of Reference Architectures for IoT/IIoT and IoT Security

Analysis of SecureIoT Requirements (from D2.1 & D2.2) St

ep 2

-Sy

nth

esis

an

d S

pec

ific

atio

n o

f Sec

ure

IoT

Arc

hit

ectu

re Introduction of Modules that address requirements

Structuring principles and interfaces between modules

Technical specifications of each module (including candidate implementation technologies)

Step

3 –

Valid

atio

n a

gain

st S

ecu

reIo

T U

se C

ases Instantiation of the

SecureIoT platform based on the needs of the use cases

Validation of security functionalities against security requirements of the use cases

Validation of non-functional properties of the architecture

Page |16




system. Snapshots of the other views are

also provided, yet we expect such views

(e.g., process and development views) to

be refined and elaborated as part of the

detailed design and implementation of

the technical modules that comprise the

SecureIoT architecture. Such detailed

designs will be provided in the scope of

other technical workpackages of the

project.

Apart from adherence to the 4+1 view

approach, the present deliverable has taken account prior WP2 developments (notably the

requirements and reference use cases deliverables i.e. D2.1 and D2.2) in order to develop the

SecureIoT architecture. A typical interaction between the requirements, the architecture, the

detailed design and the implementation of the SecureIoT platform has been considered for WP2

and its interaction with the technical work packages, as shown in the side figure. In particular,

the architecture of the project satisfies the functional and non-functional requirements of the

project, as the latter are specified in deliverable D2.2.

Last but not least, it’s important that the SecureIoT architecture is developed in an iterative and

evolutionary fashion based on two iterations. The present deliverable (D2.4) is devoted to the

presentation of the initial version of the architecture, which shall be improved and refined in a

subsequent version of this deliverable (D2.5). The refinement will take into account feedback

from the technical workpackages and all the different actors that engage with the project’s

developments, which provides a means for improvement.

1.4 Document Structure The structure of the deliverable is as follows:

• Section 2 following this introductory section presents briefly our analysis of the state of the art, with emphasis on the analysis of reference architectures and relevant projects. Note that the analysis emphasizes only aspects relevant to SecureIoT and hence it is by no means exhaustive. Moreover, this section introduces a reference architecture for IoT security systems, which serves as a blueprint for the implementation of the SecureIoT platforms.

• Section 3 introduces the SecureIoT platform architecture, following the main principles of the earlier introduced reference architecture. It provides a detailed description of the functionalities of each main modules of the architecture, along with a high-level description of the interfaces and interactions between them. It primarily provides logical views of the architecture yet providing insights on to physical and deployment views as well.

Page |17




• Section 4 complements the specification of the SecureIoT architecture with the specification of the security services that will be offered over it, including risk assessment, compliance auditing and developers’ support services.

• Section 5 provides some initial insights on candidate implementation technologies that can be used for the implementation of the architecture, including data collection, data analytics, data persistence and security policies management components. These implementation technologies are aimed at shedding light on possible implementation frameworks, yet there are likely to change as part of relevant fine-grained implementation decisions at the technical workpackages where individual components of the architecture will be designed and implemented.

• Section 6 validates the architecture against the three implementation scenarios of the project and the use cases that they comprise. To this end, an instantiation of the SecureIoT architecture in-line with the needs of each of three target settings/scenarios is provided. This instantiation could drive the integration of the use cases in WP6.

• Section 7 is the final and concluding section of the deliverable. It draws the main conclusions from the SecureIoT architecture specification process and provides an outlook for the subsequent version/release of this deliverable (i.e. D2.5).

Page |18




2 Analysis of State of the Art and SecureIoT

Reference Architecture 2.1 Standard Reference Architectures and Reference Architecture

Models 2.1.1 RAMI 4.0

2.1.1.1 Overview

The SecureIoT architecture is destined to support security and protection functionalities of

Industrial IoT systems, which are currently having greater market momentum than consumer IoT

systems. To this end, the development of the project’s architecture takes into account the

structure of IIoT systems as specified in the Reference Architecture Model Industry 4.0 (RAMI4.0),

which is illustrating structuring concepts and provides vocabulary for understanding Industry 4.0

systems and their deployment. RAMI describes the structure and main elements of Industry 4.0

system by means of a 3D layered model (Figure 2). The three layers of the 3D model correspond

to:

• The Architecture axis (Layers), which comprises six different layers indicating functionalities

at different granularities of the system, from the asset to the business level.

• The Process axis (Value Stream), which illustrates the stages of an asset’s lifecycle, along with

a corresponding value creation process based on IEC 62890 [IEC62980].

• The Hierarchy axis (Hierarchy levels), which presents describe the breakdown structure of

assembled components based on a taxonomy that starts from the product and goes up to the

connected smart factory. The various levels are driven by the DIN EN 62264-1 [DIN EN 62264-

1] and DIN EN 61512-1 standards [DIN EN 61512-1:2000-01].

Some more information about the three axes of the model are provided in following paragraphs.

2.1.1.2 Architecture Layers

The architecture layers of RAMI4.0 include:

• The Asset Layer, which describes physical systems and components (e.g., machines, motors,

software applications, spare parts).

• The Integration Layer, which links the physical and digital/cyber worlds based on

components like drivers and middleware.

• The Communication Layer, which deals with communications between the integration and

information layers. It employs network protocols (e.g., TCP/IP, HTTP, FTP) over LAN and WAN

networks, including wireless networks.

• The Information Layer, which provides (digital) information about sales, purchase orders,

suppliers, locations etc. along with information on materials, machines and components that

support the production.

Page |19




• The Functional Layer, which comprises production rules, actions, processing, and system

control.

• The Business Layer, which is associated with the business strategy, the business

environment, and business goals of the enterprise, including promotions, offers, pricing

models and cost analysis.

Figure 2: Reference Architecture Model Industry 4.0 (RAMI 4.0)

2.1.1.3 Process Value Streams

The Process axis deals with the lifecycle and processes of an object, which typically comprises a

product, physical entities (e.g., machines and spare parts) or even virtual entities (e.g.,

documents and project plans). Every product needs to be updated, restructured, redesigned, or

reformed for maintenance purposes.

In this context, the process layer specifies Types and Instances as it main methods. A product in

a development state is referred to as a “Type”. Once moved to production, it becomes an

“Instance”. As illustrated in the RAMI4.0 cube, a “Type” is also subject to maintenance activities.

A product returns to the “Type” state, whenever it is redesigned, or a new feature is being added

to it.

2.1.1.4 Hierarchical Levels

The hierarchy levels of the corresponding axis are as follows:

• Product, which abstracts the product that is manufactured in a factory.

Page |20




• Field device, such as sensor and electronic devices that capture and/or control data from the

field.

• Control device, which corresponds to the Operational Technology (OT) that manages input

and output. Prominent examples are PLCs (Programmable Logic Controllers) and DCSs

(Distributed Control Systems).

• Station, which enables operators to coordinate several processes and monitoring the results,

by means of automation systems such as SCADA.

• Work Center, which keeps track of manufacturing information and parameters that enable

quality management.

• Enterprise, which comprises the are core business processes (e.g., production planning,

production scheduling, marketing and sales, financial modules) that are usually managed

through an ERP system.

• Connected World, which deals with the interlinking of all stakeholders as part of their supply

chain interactions (including information sharing and exchange among them).

2.1.1.5 Security Considerations and Relationship with SecureIoT

As already outlined in RAMI related literature [Ma17], security is a cross-layer function. In

particular, it applies to all the different levels from individual assets to business processes. For

example, risk assessment functionalities are an indispensable element for individual

components, field devices, communication networks and entire business processes. Likewise,

security applies to all object’s entire life-cycle, which means that it is an orthogonal function to

the RAMI’s process value streams. Moreover, security and risk assessments need to be carried

out at all levels of the RAMI Hierarchy (i.e. from the Product to the Connected world levels).

The SecureIoT architecture will take into account RAMI4.0 concepts in order to effectively support industrial security use cases, notably manufacturing related use cases. It must therefore provide support for risk assessments associated with assets and processes at different granularities and across their entire lifecycle. However, SecureIoT is expected to have some limitations in terms of supporting all the concepts of RAMI4.0, as it is also destined to support use cases in other areas such as healthcare and transport, which are characterized by different models and taxonomies of physical and logical assets that should be monitored and protected through SecureIoT.

2.1.2 Industrial Internet Consortium Reference Architecture (IIRA)

2.1.2.1 Overview

The IIRA specifies a common architecture framework for developing interoperable IoT systems

for different vertical industries. It is an open, standards-based architecture, which has broad

applicability. The latter makes is a vehicle for interoperability, mapping and practical deployment

of IoT technologies, as well as standards development. Note that as a result of its broad

applicability, the IIRA is fairly generic, abstract and high-level. Hence, it can be used to drive the

structuring principles of an IoT system, without however specifying its low-level implementation

Page |21




details. It is also a very good vehicle for communicating concepts and facilitating stakeholders’

collaboration.

Based on the analysis of multiple use cases in different sector, the IIRA presents the structure of

IoT systems from four viewpoints, namely business, usage, functional and implementation

viewpoints. Among these four viewpoints, it’s the functional viewpoint that specifies the

functionalities of an IIoT system. To this end, the functional viewpoints specifies distinct

functionalities in the form of the so-called “functional domains”. Functional domains can be used

to decompose an IoT systems in a set of important building blocks, which are applicable across

different vertical domains and applications. As such functional domains are used to conceptualize

concrete functional architectures. The IIRA decomposes a typical IoT/IIoT system into five

functional domains, namely a control domain, an operations domain, an information domain, an

application domain and a business domain as outlined in Figure 3.

The implementation viewpoint of the IIRA is based on a three-tier architecture, which follows the

edge/cloud computing paradigm, as shown in Figure 4. It includes an edge, a platform and an

enterprise tier.

Figure 3: Functional Domains in IIRA

Page |22




Figure 4: Three Tier Architecture for IIoT Systems – Implementation Viewpoint for IIRA

2.1.2.2 Relation to SecureIoT

SecureIoT develops a general-purpose security architecture for IoT system, which emphasizes on

predictive security monitoring. The SecureIoT architecture is destined to be general and

applicable to a broad range of IoT system. To this end, the project should consider functional

domains and the implementation viewpoints specified in the IIRA. These domains and viewpoints

will provide an abstraction of many different IoT systems.

For example, SecureIoT should consider probes and data collection mechanism for accessing security information stemming for all three tiers of the IIRA i.e. the edge, platform and enterprise tiers. As another example, SecureIoT should consider the decomposition of an IoT system in different functional domains, in order to deal with the security monitoring of all the functionalities of the IoT system.

Page |23




Figure 5: Security Functionalities of the IISF

2.1.3 Industrial Internet Security Framework (IISF)

2.1.3.1 Overview

The IISF provides the security view of the IIRA viewpoints i.e. it is a security framework tight to

the IIRA. In-line with our requirements for securing the IIRA, the IISF secures all the functional

building blocks of the functional viewpoint of the IIRA end-to-end, including field, edge and cloud

end-points. This is illustrated in Figure 6, while Figure 5 illustrates the security functionalities that

have to be deployed for the various edge points according to the IISF.

Figure 6: Alignment of an IIoT System with IIRA and IISF

One of the key functionalities of the IISF in Figure 5 is “Security monitoring and analysis”, which

is destined to:

Page |24




• Capture data about the overall state of the system from the endpoints and connectivity

traffic.

• Analysing it to detect possible security violations or potential system threats.

• Initiating (upon detection of a violation or threat) of one or more actions for protection in-

line with the system’s security policy.

These steps are illustrated in more detail in Figure 7.

2.1.3.2 Relevance to SecureIoT

SecureIoT is a data-driven security system that implements the “Monitor-Analyze-Act” cycle specified in the IISF framework. It will provide the means for executing this cycle, while at the same time ensuring protection for all functional blocks and end points of an IoT system. Note that as specified in IISF the above listed cycle may complete in real-time or execute later to identify usage patterns and detect potential attack scenarios. Hence, to the extent that SecureIoT complies with IISF should support both real-time functionalities and functionalities operating in coarser timescales.

Figure 7: Breakdown of Security Monitoring and Analysis

2.1.4 OpenFog Reference Architecture

2.1.4.1 Overview

The OpenFog Consortium is a consortium of high tech industrial enterprises companies and

research/academic institutions, which are collaborating towards standardizing and promoting

the fog computing paradigm. For computing is directly associated with IoT, as it leverages fog

nodes (i.e. essentially IoT devices) in order to enable reliable, low latency IoT applications. Fog

computing alleviates the limitations and drawbacks of conventional cloud computing in various

scenarios where low-latency and processing close to the field is required. The RA of the OpenFog

Page |25




consortium illustrates the structure of fog computing systems. It presents how fog nodes can be

connected partially or fully in order to enhance the intelligence and operation of an IoT system.

Moreover, it presents solutions about growing system wide intelligence away from low-level

processing of raw data. The RA is described in terms of different views, including functional and

deployment views. Figure 8 presents an outline of the RA, which illustrates the structure of an

OpenFog compliant system and the role of some cross-cutting functionalities (i.e. functionalities

that are applied across all layers of an IoT / OpenFog system). These cross-cutting functionalities

are conveniently called “perspectives”.

Figure 8: OpenFog Reference Architecture Description including different perspectives

2.1.4.2 Security Features

Security is one of the perspectives (i.e. cross-cutting functions) of the OpenFog RA. This

perspective outlines the importance of end-to-end security as a cross-cutting function of IoT

systems. Security is integral to all IoT scenarios and should be end-to-end i.e. covering the

underlying silicon (fog/device) and all upper software layers of the fog architecture. This is

because if one of the layers is not secure, the entire solution is not secure. Hence, end-to-end

security should cover everything between the cloud and the things on the edge of the network.

According to the OpenFog RA, security starts with the individual fog node hardware. Once the

trustworthiness of fog nodes has been ensured, other secure layers (e.g., a secure fog network)

can be deployed on top of the nodes as a means of end-to-end security that provides secure

node-to-node, node-to-thing, and node-to-cloud communication.

Page |26





SecureIoT will implement the end-to-end security as specified in the OpenFog RA. Moreover, SecureIoT will be aligned to the security perspective concept of the OpenFog RA, through implementing an architecture that can be attached as a cross-cutting set of functions to any IoT system. This is in-line with the OpenFog RA security perspective concept. Beyond the alignment to security concepts of the OpenFog RA, SecureIoT will be a fog computing system itself, since it has to cover security scenarios where low-latency is required i.e. cases where cloud connectivity and cloud processing introduce significant performance overheads to the implementation of fast-response security functionalities.

2.1.5 IoT-A

2.1.5.1 Overview

The main outcome of the IoT-A FP7 project was the Architectural Reference Model (ARM). The

primary goal of the ARM concept is to solve the interoperability problem that affects to IoT based

systems: “Many IoT-enabled solutions exist with recognised benefits in terms of business and social

impact, however they form what we could call a set of Intranets of things, not an Internet of things”

[Carrez13]. As it is explained in section 3.1 of [Carrez13], the IoT-A ARM relies on five different

views of sub-models.

Figure 9: IoT-A ARM UML domain model. Section 3.3.2.2 of [Carrez13]

Dev ice

Physical Entity

Human User

Serv ice

On-Dev ice

Resource

SensorActuator

Network Resource

Resource

User

Passiv e Digital

Artefact

Activ e Digital

Artefact

Virtual Entity

Digital Artefact

Augmented Entity

Tag

Animate objects (humans, animals etc.)

Hardware

Software

Not clearly classifiable (e.g., combination)

Colour Scheme

XOR

0..*

contains

0..1

0..*

interacts with

0..*1

1

1..*

relates to 1

0..*

is associated with

0..*

0..*

contains

0..*

0..* identifies

0..10..*

is associated with

0..*

0..*

hosts

1

0..*

contains

0..1

1

1..*

0..*

contains

0..1

0..*

invokes

0..*

0..*

invokes / subscribes

1..*

0..*

has Information about / acts on

0..*

0..*

reads

0..*

0..*

monitors

0..*

0..*

acts on

0..*

0..*

is attached to0..*

0..*

exposes

0..*

Page |27




In the first case, the domain model defines a set of high-level components or actors that are

common to most IoT use-cases and which are represented in Figure 9 below. The information

model deeps into the analysis, specifying common attributes for each one of the entities of the

domain model and their semantics. For instance, it defines that a VirtualEntity may include

properties like entityType or the identifier and attributes with name, type and several values.

From the domain model, the IoT-A ARM introduces the Functionality Groups (FG) as part of the

functional model. Again, each one of these FGs is further decomposed in the functional view

diagram extracted from subsection 4.2.2.1 of [Carrez13] and showed in Figure 10, where

Functional Components (FC) are included.

Specific FC and FGs are included to handle the specific characteristics of IoT communication

flows. The Communication Model relies on these components of the architecture and on ISO OSI

Reference model [ISO 7498-1] to address interoperability at the stack or network level.

Finally, security aspects are in the scope of the Trust, Security and Privacy Model, which will be

further commented in the next subsection due to its relevance for the SecureIoT project.

Figure 10: Functional Components (FCs) for each Functionality Group (FG) of the IoT-A ARM [Carrez13]

2.1.5.2 Security Considerations

The IoT-A ARM model dedicates the complete 3.7 chapter of [Carrez13] to discuss how to

consider security issues within IoT domain. It identifies the following properties and policies as

mandatory or highly desirable:

• Trust, which must be enforced in all the layers and elements of the system. IoT-A ARM

introduces concepts like Trust-model domains, Trust-evaluation mechanisms, Behavioural

policies, Trust anchors, Federation of trust or M2M support.

• Security at three different levels:

Page |28




o Communication: it provides an abstract approach where constrained devices are

specifically targeted since they are the most challenging elements of an IoT based

system. Security for them is delegated to the corresponding Gateway, which must

implement the CDSecFeat (Constrained device security feature).

o Application: in subsection 3.7.2.2 of [Carrez13] it is stated that “System safety is

application specific”. Nevertheless, IoT-A ARM model covers the basic steps to

perform the analysis that will conduct to the identification of the design policies

and mitigation actions: description of elements to protects, categorization of risk

sources, risk assessment and proposal of design choices. A very illustrative example

of this process is included in subsections 5.2.9 and 5.2.10 of [Carrez13].

• Privacy: the central elements is the Identity Management FC, which manages the identities

of all the actors of the platform. In collaboration with the Authentication component enforces

security policies at the different endpoints and resource of the system.


We can establish a mapping between the high-level components of SecureIoT logical view and

the IoT-A ARM detailed functional model as shown in the following figure:

Figure 11: Mapping of SecureIoT main functional components to IoT-A ARM model - Figure is just an extension of the one included in section 4.2.2.1 of [Carrez13]

The generalization of IoT-A ARM model can be easily applied SecureIoT Reference Architecture. Thus, interoperability with derived and specific instantiations to address the needs and requirements of application domains shall be reachable with a limited effort.

Page |29




2.1.6 ISO/IEC 30141

2.1.6.1 Overview

ISO/IEC CD 30141 Internet of Things Reference Architecture (IoT RA) is an ongoing

standardization process. As it can be seen in [ISO/IEC CD 30141-1], the standard is from May of

2017 in Committee phase and although the working draft is not officially publicly available, the

Committee Draft can be download from the World Wide Web Consortium web page (W3C)

[ISO/IEC CD 30141-2].

ISO/IEC 30141 starts with a heuristic analysis of system characteristics that are common in most

IoT systems (e.g., auto-configuration, discoverability, scalability, etc). From them, it proposes a

Conceptual Model where typical IoT entities or actors are their relationships are described. The

CM is quite similar to IoT-A ARM domain model and includes IoT-Users, applications, services or

Virtual Entities. Finally, the five different views that describe the architecture are presented:

functional, system, communications, information and usage. The structure and main elements of

the functional view are showed in Figure 13 below.

Figure 12: Mapping of SecureIoT main functional components to ISO/IEC 30141 model - Figure is just an extension of the one included in section 4.2.2.1 of [Carrez13]


As it is showed in the functional view, the reference model takes into account security aspects

both as part of the inside-domain and cross-domain functions. In comparison with IoT-A ARM,

the analysis of each one of the functional components is not so fine-grained and this is also

applicable to the security issues. The main statements are:

Page |30




• Safety and security at Sensing and Control Domain must be enforced by edge entities.

• Security, safety, resilience, trust and privacy are functions present in all the domains

(cross-domain). Their role is to ensure data privacy protection, confidentiality, integrity,

authenticity and confirmation of exchanged information, fault-tolerance and self-healing.

Last but not least, the authentication mechanism which considers multiple levels of trust

is the proposed way of protecting data confidentiality.


The result of matching the functional view of the ISO/IEC 30141 reference architecture to

SecureIoT is presented in the following figure:

Figure 13: ISO/IEC 30141 functional view of the reference architecture. Section 4.2.2.1 of [ISO/IEC CD 30141-2]

Most of the elements of SecureIoT logical view can be wrapped within ISO/IEC 30141 functional view components.

Page |31




2.1.7 Industrial Data Space – IDS

2.1.7.1 Overview

The Industrial Data Space (IDS)1 is an initiative lead by Fraunhofer ISST in collaboration with other

companies like ATOS or T-Systems and promoted by the German Federal Ministry of Education

and Research. The main characteristic of IDS is the focus on information ownership, trying to

propose a reference distributed architecture that enables transparent and fair exchanges

between data sources and consumers.

As it is explained in [IDS-RA], IDS reference architecture is described using multiple views or

layers: business, functional, process, information and system. Transversal functionalities to all of

them are security, certification and governance.

In contrast to IoT-A ARM or ISO/IEC 30141, IDS focuses its specification of roles within the

business layer in the data flows between different domains or data spaces, defining key

participants like Data Owner, Data Provider, Data Consumer, Data User or Broker Service provider

(subsection 3.1.1 of [IDS-RA]). The complete landscape of roles, their functionalities and

relationships result in the composition of the functional architecture of Figure 15 below.

Figure 14: Functional view of IDS architecture, including the interaction between components [Hierro18]

Further details about the interactions between the different roles are provided with the process

view (section 3.3 of [IDS-RA]). This layer specifies the steps needed to provide, exchange, publish

and use data with several sequence diagrams that shall be followed to create a specific

implementation of each one of the IDS actors or roles.

Finally, the system layer (section 3.5 of [IDS-RA]) includes an internal structure strongly based

on containerization for the development of IDS connectors.

1 https://www.internationaldataspaces.org/

Page |32





IDS reference architecture includes in [IDS-RA] the entire fourth chapter to analyse the security

implications that must be studied to warrant a reliable and trusted trade of information between

independent entities. The following elements are explicitly mentioned:

• Secure communication, where the concept of Trusted Connector is introduced, as Figure

15 illustrates. To achieve data confidentiality and authenticity is the main goal of the IDS

Communication Protocol, which relies on already existing solutions like TLS.

Figure 15: IDS architecture relies on IDS Communication Protocol to enforce security in data exchanges. Section 4.1.2 of [IDS-RA]

• Identity Management to enforce identification, authentication and authorization. The use

of certificates issued by a Certificate Authority (CA) is a mandatory requirement.

• Trust Management based on Cryptographic methods like Public Key Infrastructures (PKIs)

for mutual authentication.

• Trusted Platform as a “central element of trustworthy data exchange” (page 71 of [IDS-

RA]). It defines the minimal requirement for Security Profiles that must be verifiable by

IDS connectors and the capacity to performing integrity verification of the rest of the

involved connectors.

• Data Access Control that defines authorization criteria based on the previously defined

Security Profiles.

• Data Usage Control regulates and checks that data processing complies with the intended

purposes defined by the original data owner.

Page |33





Some of SecureIoT goals are well-aligned with specific items addressed by IDS mission, i.e.,

support multiplatform interactions and decentralized architectures or enforce end to end

security. As it has been explained before, the main outcome of IDS reference architecture is not

the possibility to describe a complete IoT based system, going through all the typical components

that are needed to satisfy the requirements of the involved stakeholders. IDS core message is

that new business models and economy models are going to be boost by data and therefore the

possibility to broker information in an interoperable and trust fashion is a must. In this sense, IDS

cannot be used to derive or describe SecureIoT architecture.

Nevertheless, the security information that is at the very centre of SecureIoT concept needs to

be collected and its ingestion from probes deployed in smart objects, devices or IoT cloud

platforms’ components could be based on IDS technical concept.

Finally, it is also important to emphasize that a system derived from IDS is also a candidate to be

protected by SecureIoT. For instance, an ongoing process to reach a first IDS compliant

implementation is being done under the umbrella of FIWARE [Hierro18]. Thus, specific data

collection probes shall be developed to monitor the main IDS roles and actors, e.g., internal and

external IDS Connectors, network interfaces between IDS connectors or data space brokers.

2.2 Review of Architectures from Related R&D Projects and Initiatives 2.2.1 H2020 PaasWord

2.2.1.1 Overview

The PaaSword H2020-644814 project focuses on the development of Cloud Security technologies

and, in particular, in the implementation of an encrypted and physically distributed persistence

as a Platform-as-a-Service capability for Cloud-enabled applications and services. More

specifically, PaaSword introduces a holistic data privacy and security by design framework

enhanced by sophisticated context-aware policy access models and robust policy access,

decision, enforcement and governance mechanisms, which will enable the implementation of

secure and transparent Cloud-based applications and services that will maintain a fully

distributed and totally encrypted data persistence layer, and, thus, will foster customers' data

protection, integrity and confidentiality, even in the case wherein there is no control over the

underlying third-party Cloud resources utilized.

2.2.1.2 PaaSword Relevance to SecureIoT

The PaaSword project is focused on the cloud-based applications, however the same idea can be

used to support IoT-based applications. In the frame of SecureIoT security-oriented

functionalities will be used and extended in order to support IoT platforms, devices and smart

Page |34




objects. More specifically, code annotation libraries for security enforcement, security

monitoring and data privacy by-design features will be extended to support IoT environments.

SecureIoT will build on top of the annotation driven security and more specifically it will extend

the distributed policy engine that has been developed in PaaSword in order to be applied in an

IoT deployment. More precisely, annotations will be used to declare access policies for the

applications that are executed in IoT devices and smart objects. After the compilation of the

annotated service, the service will automatically register itself as a Policy Enforcement Point

(PEP). Therefore, each access request will be forwarded to the policy evaluation engine which

will combine all declared policies for the specific PEP in order to infer if an access request is

granted or not. The SecureIoT approach will alleviate the huge development costs of existing

solutions for preserving security and privacy, as well as their error prone nature, especially when

the complexity of security measures grows.

2.2.2 FP7 RERUM The RERUM2 project was focused on enhancing the trustworthiness of IoT technologies by

adhering to an architecture which adopts the concepts of security, privacy and reliability by

design. Both its domain model (the RERUM Domain Model) and its architecture are based on

service-oriented Architectural Reference Model proposed by the IoT-A [1], with additional

elements and concepts being incorporated, notable being the notation of Context (such as in

BUTLER3 or iCore4). In addition, RERUM has a strong focus on providing the sensors (called

RERUM Devices) with complex security, privacy and reliability-scopes, providing therefore also a

device-oriented approach, reflected by its architecture.

More specifically, within RERUM, the RERUM Devices are partially responsible for configuring

and running their own security, privacy and trust (trust being of the requirements for providing

reliability) software and hardware components on top of the underlying sensor device operating

system. This since a core expectation within RERUM is that the devices have interacting between

themselves and with the cloud-based components offering processing and storage have

heterogenous hardware configurations and owners, each one being responsible for reporting

and configuring its policies regarding how the data generated is allowed to be processed, stored,

or consumed.

RERUM also employs the concept of Virtualization, which denotes the representation of a

heterogenous, real-world hardware devices as homogenous virtualized components which

abstract the device- and model-specific mechanisms for interacting with the various sensors. It is

also providing the ability to form cooperating virtual entities, Federations, which the system then

can represent as a single specialized entity being able to solve a more complex task. This allows

2 https://ict-rerum.eu/ 3 https://cordis.europa.eu/project/rcn/101349_en.html 4 https://cordis.europa.eu/project/rcn/100873_en.html

https://cordis.europa.eu/project/rcn/101349_en.html

Page |35




rules such as “open-the-window-if-to-warm-inside” to be executed on a single virtual device

which consists of multiple federated real-world devices offering required sensors and actuators,

such as temperature sensors and window motor actuators.

2.2.2.1 RERUM Relevance to SecureIoT

RERUM defines the high-level architecture of the trust and reputation model consisting of the

four main components which are of relevance for SecureIoT as well: the trust and reputation

models, the reaction model, and of the contextual set of definitions and rules which can be used

to further extended the reliability of the overall trust and reputation component.

2.2.3 H2020 GHOST

GHOST5 is a project on IoT security, which targets the development and deployment of a highly

usable and effective security framework for smart home residents. It has already created a novel

reference architecture for user-centric cyber security in smart home environments. This

architecture emphasized collection and analysis of data from IoT devices, including network

traffic and application-level data. As such it has been taken into account in the development of

the SecureIoT architecture, yet SecureIoT has some radical differences such as its support for

different environments (rather than smart homes only) and its emphasis on smart objects with

semi-autonomous behaviour. Nevertheless, the concept of identifying abnormal behaviours and

acting upon them is certainly shared by both projects.

2.3 Architectures and Security Features of Relevant IoT Platforms 2.3.1 SIEMENS MindSphere

MindSphere represents one of the largest industrial initiatives in the area of Internet of Things

worldwide. As defined by Siemens MindSphere aim to be a full open IoT operating system,

offering full scalability at shop floor level and advanced analytics in cloud environment. Previously

based on SAP HANA, currently MindSphere rely on Amazon Web Services (AWS), Microsoft Azure,

and AliBaba cloud (for Chinese customers).

MindSphere is designed in a loosely coupled manner, micro-service oriented, allowing natural

scalability of customer needs. It is structured to provide customers both scalability at the level of

gateways towards the shop floor (managed via MindConnect ) and at the end of data analytics

users willing to extract meaningful insights, where it expose REST APIs.

5 https://www.ghost-iot.eu/

Page |36




Figure 16: MindSphere Conceptual Architecture

Technology wise MindSphere expose a set of continuously evolving services platform structured

around relevant usage scenarios for the whole platform. From a security point of view

MindSphere use for MindConnet Library a secured connection using SSL/TLS aiming to protect

customer data.

Once in the cloud instance data is kept encrypted, mostly relying on own platform mechanisms

(e.g. AWS specific).

In top of it Siemens provide own IAM framework (Identity & Access Management) where based

on each individual role able to access data and services, there is possible to provide different

types of access to segments of data stores.

MindSphere is currently a subject of commercial exposure and do not offer functions towards open community. From a design level perspective MindSphere promote serverless architectures and in the near future, due to the integration of Mendix platform fast prototyping on low-code manner. MindSphere might benefit from the SecureIoT way of thinking pairing current IAM Framework with a more analytics-oriented monitoring capability on gateways collected data performing data validation before is delivered in data store. SECaaS can be integrated as part of offer towards customer and on the evolution of the platform from cloud-based processing towards a more distributed, Fog Computing perspective. In this context, the interfacing of SecureIoT with MindSphere is considered as part of the development of the SecureIoT architecture.

Page |37




2.3.2 FIWARE6

2.3.2.1 Overview

FIWARE is an open-source initiative that aims to create a platform to leverage on the combination

of disruptive technologies like Internet of Things (IoT), Big Data or Cloud architectures. Rather

than proposing a tightly and closed solution that targets the specific requirements of a single

domain, FIWARE eases the creation of new applications in multiple verticals since its catalogue

contains a rich set of components that can be connected, combine and deploy in a flexible way.

On one hand, FIWARE concept tries to achieve to break the data and technical silos that exist in

many IoT based systems by proposing a horizontal layer to manage large-scale context

information. FIWARE NGSI specifies an information model and a RESTful interface that shall be

implemented by context data providers and consumers when interacting with the Context

Broker, a central component of FIWARE architecture. The Context Broker “enables the system to

perform updates and access to the current state of context” [FIWAREDev]. The new ETSI CIM

standard has been built on the basis of FIWARE NGSI [ETSI GS CIM 004].

On the other hand, from the management point of view, it is currently promoted by the FIWARE

foundation, an independent and open community with members like ATOS, NEC, Orange or

Telefonica. As part of its activities, it tries to foster the adoption and improvement of FIWARE

technical solution by means of the creation of a wide ecosystem where more than 100 cities and

hubs participate. FIWARE is also an active contributor and partner of some of the most relevant

standardization bodies, e.g., GSMA, ETSI, etc.

2.3.2.2 Architecture and technical specification

In addition to the Context Broker, FIWARE includes the specification of the interfaces of multiple

Generic Enablers (GE). The available implementations of FIWARE GEs can be found as part of the

Catalogue [FIWARECatalogue], which is structured in different chapters according to Figure 17

below.

6 https://www.fiware.org/

Page |38




Figure 17: FIWARE high-level architecture [FIWAREDev]

In order to simplify the interoperability with FIWARE deployment, the main GEs is decomposed

in considering the tiers used to described SecureIoT architecture: edge, cloud and application.

GEs to deal with security requirements will be specifically analysed in subsection 2.3.2.

Tier FIWARE GE Description Url

Application Wirecloud Development of user interfaces

https://catalogue-server.fiware.org/enablers/application-mashup-wirecloud

CKAN extensions

Publication of open-data

https://catalogue-server.fiware.org/enablers/fiware-ckan-extensions

Biz Framework

Data monetization

https://catalogue-server.fiware.org/enablers/business-api-ecosystem-biz-ecosystem-ri

Kurento Real-time video processing

https://catalogue-server.fiware.org/enablers/stream-oriented-kurento

Knowage Data analytics https://catalogue-server.fiware.org/enablers/data-visualization-knowage

Cloud Orion Context Broker

Mandatory. Management of context information

https://catalogue-server.fiware.org/enablers/publishsubscribe-context-broker-orion-context-broker

STH Comet Data persistence in MongoDB for time series

https://catalogue-server.fiware.org/enablers/sth-comet

Cygnus Streaming of data to databases or processing components

https://catalogue-server.fiware.org/enablers/cygnus

Cosmos Big-data analytics

https://catalogue-server.fiware.org/enablers/bigdata-analysis-cosmos

Edge IDAS Interconnection with IoT devices and networks

https://catalogue-server.fiware.org/enablers/backend-device-management-idas

Table 1: Summary of FIWARE GEs

More specifically regarding FIWARE assumptions for the connection of IoT devices or Smart

Objects, IDAS GE (also known as IoT Agents) is the functional component of the ecosystem that

Page |39




translates the corresponding IoT communication protocol (e.g. LWM2M, LoRaWAN) and data

model (e.g., IETF CBOR, JSON) to NGSI. The role of IDAS / IoT Agents is showed in Figure 18:

Figure 18: FIWARE IoT stack with IoT Agents and Context Brokers as main functional components [Calvo18]

At this moment, the following IoT Agents are ready to be used:

• Ultralight (HTTP / MQTT): https://github.com/Fiware/iot.IoTagent-UL

• JSON (HTTP / MQTT): https://github.com/Fiware/iot.IoTagent-JSON

• LWM2M (CoAP): https://github.com/Fiware/iot.IoTagent-LWM2M

• LoRaWAN: https://github.com/Fiware/iot.IoTagent-LoraWAN

Therefore, FIWARE IDAS/IoT Agent implementations enable the usage of a wide range of smart

objects that go from constrained devices based on microcontrollers to more powerful embedded

systems that are to run a complete TCP/IP stack and to apply advanced security features.

2.3.2.3 Security considerations

A. Alonso explains in [Alonso18] that FIWARE security framework is based on OAuth2.0 standard

[RFC6749], the API Gateway pattern [API-Gateway] and a central Identity Management server.

Thus, the GEs needed to protect FIWARE deployments are:

FIWARE GE Description Url

KeyRock Identity management https://catalogue-server.fiware.org/enablers/identity-management-keyrock

Wilma Policy Enforcement Point (PEP) or API Gateway / Proxy

https://catalogue-server.fiware.org/enablers/pep-proxy-wilma

AuthZForce Authorization Policy Decision Point (XACML)

https://catalogue-server.fiware.org/enablers/authorization-pdp-authzforce

Table 2: FIWARE Security GEs

The interactions between them is presented in Figure 19:

https://github.com/Fiware/iot.IoTagent-UL

https://github.com/Fiware/iot.IoTagent-JSON

https://github.com/Fiware/iot.IoTagent-LWM2M

https://github.com/Fiware/iot.IoTagent-LoraWAN

Page |40




Figure 19: Authorization based on OAuth2.0 for FIWARE components [Alonso18]

Following this approach, a PEP Proxy must be deployed together with each one of the GEs to

enforce authentication and authorization in the access to their APIs. A specific example to the

link between an IoT Agent and the Context Broker is given is Figure 20:

Figure 20: Access control for FIWARE IoT Agents and Context Broker

With respect to the edge tier or south interface using FIWARE terminology, security and access

control mechanisms must be implemented by each IoT Agent following the recommendations of

the corresponding IoT communication protocol.

Finally, there are ongoing tasks to integrate modern security mechanisms like Kong7, Apinf8 or

the User-Managed Access (UMA) profile of OAuth2.0. Most of these features shall be released

during the execution of SecureIoT.


As it is stated in the DoA, FIWARE is one of the main IoT platforms that shall be supported by SecureIoT. This implies that thanks to SecureIoT, it will be possible to deploy specific data probes that monitor the main FIWARE GEs and their interactions, collecting valuable information that will feed SecureIoT AI models and services. The data-analytic techniques shall identify and predict abnormal situations and threat patterns for FIWARE based systems, aspects that will

7 https://konghq.com/kong-community-edition/ 8 http://www.apinf.com/

Page |41




constitute the basic bricks for the implementation of the end-user functionalities as part of the SECaaS services. Thus, the result of SecureIoT will improve substantially the dynamicity and intelligence of the current FIWARE security framework, especially with respect to the interconnection of IoT devices, which is one of the weaker aspects of the ecosystem. Further details regarding the kind of data that can be collected from FIWARE GEs and the design of probes and management agents are part of deliverable D3.3 [SecureIoTD3.3]. FIWARE will be the reference IoT platform for the implemented of the Connected Car and Autonomous Driving Use Cases as it is explained in deliverable D6.1 [SecureIoTD6.1]. Therefore, it shall allow assessing SecureIoT developments for FIWARE in a relevant industrial application.

2.3.3 CloudCare2U

CloudCare2U focuses on the practical issues with regards to security and privacy, such as the

security management and the overhead and scalability of the access control by introducing novel

solutions based on concepts like CP-ABE, Single Point of Contact (SPoC), Organisation-based

Access Control (OrBAC), Privacy-aware Role Based Access Control (P-RBAC), Trust negotiation-

based access control, etc.

In CloudCare2U, the Local Data Manager (LDM) is a component that provides the trust and

privacy support of the local data being processed or kept at the Home Sensing Environment. The

LDM is built based on the following security and privacy components:

• User Identification – Responsible for recognizing a valid user's identity.

• Authentication – This component provides authentication for entitles which send inbound

data or which consume data. Authentication is the process of verifying the claimed identity

of a user.

• Authorization – Provides authorization for an entity (user or component) with specific role

for what component or data are allowed to be sent or consumed. Basically, it checks that the

given entity has the right permissions to access a certain component or data.

• Consent – It can be described as privacy management module that allows user to manage

access to user related data to other entities (users).

• Encryption - Provides encryption/decryption for both data transmission (e.g. SSL) and stored

data.

• Audit logger - Provides functions for security audits.

• Configuration – Responsible for handling all security and privacy related configuration.

CloudCare2U is iSprint’s IoT platform that will be used in SecureIoT’s socially assistive robots use case. While it provides several security features such as the ones listed above, it does not support IoT behavioural analysis functionalities, which will be integrated to it based on the Monitor→Analyze→Act functionalities of the SecureIoT platform.

Page |42




2.4 Driving Requirements Taking into account the above listed analysis of various RAs for IoT systems and their security

characteristics, along with requirements presented in deliverable D2.2 and the project’s

Description of the Action (DoA) document, we herewith summarize some of the main

requirements that drive the SecureIoT architecture:

• Cross-Cutting Functionality: As evident from various RAs, the SecureIoT architecture should

support security as a cross-cutting functionality that protects and secures all layers of an IoT

system. Likewise, SecureIoT can be seen as an overlay layer/system that protects and secures

IoT systems regardless of their structure and architecture. This is in-line with the security

concepts specified in RAMI4.0 and IIRA/IISF.

• End-to-End Security: The SecureIoT architecture should support security end-to-end i.e.

across all different layers of an IoT systems and across all the devices that it comprises. This

need is mandated in several of the IoT Reference Architectures, such as OpenFog RA.

• Tiered Approach: SecureIoT shall provide security functions of various latencies that will

operate in various timescales. Likewise, it will collect and process information both close to

IoT devices and at a cloud level. As such SecureIoT could be structured in-line with the

edge/fog systems, as for example outlined in the IIRA and the OpenFog RA. This is already

outlined in the DoA, yet verified by the analysis of the various standards-based RAs.

• Data-Driven System (Monitor→Analyse→Act): The SecureIoT architecture supports security

monitoring and behavioural analysis functionalities as specified in the IISF. In particular,

SecureIoT will support the development of data driven systems that are based on the

collection and processing of security-related data in order to assess risks, identify and

visualize threats and produce alerts, among other security services. Note that the need to

support actuation is a cornerstone to providing automation functionalities.

• Platforms and Devices Support: The SecureIoT architecture should provide the means for

protecting multiple different IoT platforms (including the platforms that will be used in the

project’s use cases) and devices. It should be therefore make provisions for supporting the

collection of data from all these devices.

• Configurability and Programmability: The SecureIoT architecture should be flexible in

accommodating different security mechanisms in a configurable and programmable fashion

i.e. without essential changes in the structure and implementation of the IoT compliant

systems. Note that as part of the configurability of the SecureIoT systems there should be a

mechanism for protecting systems from a variety of threats and vulnerabilities in a

programmable way.

These requirements are rather high-level, but generally appropriate for introducing the main

building blocks of SecureIoT systems in the form of a RA (Reference Architecture).

Page |43




2.5 The SecureIoT RA 2.5.1 Overview

Prior to introducing the architecture of the SecureIoT platform in the following section, we

present a high-level reference architecture for the SecureIoT project, which is destined to serve

the following goals:

• To become a vehicle for communications with various stakeholders within the project (e.g.,

the project partners), but also third-parties (e.g., the IoT community at large).

• To identify the main building blocks of the SecureIoT architecture, which will be detailed as

part of the SecureIoT platform specifications and the later implementation of SecureIoT use

cases and services based on it.

• To ensure some alignment with the presented driving requirements (listed in the previous

sub-section) and the earlier analyzed reference architecture for IoT platforms and their

security functionalities.

In-line with the above goals, we introduce the RA listed in Figure 21. It is structured in a number

of layers that denoted layered functionalities in the sense that functionalities in one layer make

use of functionalities in lower layers. At the same time, the RA comprises cross-cutting functions

that transcend all the different layers of the architecture. Furthermore, the RA is structured in

various tiers, including the field, edge and cloud tiers that are usually part of IoT RAs such as the

OpenFog RA and the IIRA.

Note that the RA illustrates the structure of the SecureIoT compliant security systems, not the

IoT systems to be protected. In terms of the IIC standards, it therefore matches the role of the

IISF (as a security framework), not of the IIRA (as a set of structuring principles for IoT systems

and their functionalities).

Page |44




Figure 21: SecureIoT RA (Reference Architecture)

2.5.2 Tiers

The SecureIoT RA, specifies four tiers, which are more or less compatible with concepts outlined

in the reference architectures analysed earlier in the Section:

• Field Tier: This tier comprises the physical systems and assets that must be protected and

secured. It comprises IoT devices (e.g., sensors), Smart Objects (i.e. devices with semi-

autonomous behaviour such as robots), entire IoT platforms (such as the platforms described

earlier), as well as networks and their elements. At this tier, we also positioning the data

collector functions (called “Probes”), which will be deployed in order to acquire information

about the field elements.

• Edge Tier: This tier comprises security functions that have to be executed close to the field.

These include functionalities for high performance collection of data (including streaming

data collection), high performance security data analytics (i.e. edge analytics), as well as

functions for automation and control that have to take place close to where the platforms

and devices reside. The edge tier comprises a local database of assets and probes, which

empowers the dynamic behaviour of the security functions at the edge, through enabling

them to access probes’ information dynamically, as devices join and leave the system that is

protected by SecureIoT. A “local” (i.e. close to the field) PDP (Policy Decision Point) is defined

Probes

Fiel

d T

ier

IoT Devices Smart Objects Networks

Edge

Tie

r (Local) IoT Assets Registry

Edge Data StorageData Streaming

Middleware

Edge Analytics

Clo

ud

Tie

r

Data Storage IoT Assets Registry

Distributed Analytics & Machine Learning

SEC

aaS

Tie

r

Risk Assessment Compliance

Multi-Platform Security Management

Security Automation

Programming Support

Man

agemen

t and

Co

nfigu

ration

Visu

alization

(Dash

bo

ards)

SLAManagement

IoT Security Knowledge Base

Cross-Cutting Functions

Layered Functions

Local PDP

Global PDP

Automation and Control

Ad

min

istration

Shell &

Digital Tw

ins

Template Execution

Page |45




and include at this tier, as a means of controlling the automation and control functionalities

by means of a security policy. Edge Tier functionalities have usually edge/local scope, which

means that they are likely to focus on a subset of the devices or platforms that comprise the

entire IoT system to be protected. In-line with the layered nature of the RA, edge tier

functions take advantage of Probes residing in the field tier.

• Cloud Tier: This tier includes functionalities that apply to the entire IoT system, which might

include a variety of edge-scoped devices and multiple platforms. In essence, the cloud-tier

hosts and executes “global” scope functionalities, as opposed to the edge tier that hosts

edge/local scope functionalities. It comprises building blocks such as a Global PDP that

applied security policies for the entire IoT system, distributed security data analytics (i.e.

analytics over data potentially collected from all the devices and platforms of the IoT

systems), as well as data stores for persisting and managing global security data. The cloud

tier comprises also a Security Knowledge Base, which accumulates knowledge about threats,

vulnerabilities and attacks, in order to act as a reference point for matching findings from the

analytics to security knowledge. Moreover, a registry of assets and probes is also specified in

order to allow dynamic access to information stemming from the various devices, platforms,

smart objects, network elements and other assets of the IoT system. The template execution

function that is listed in the RA is a key one for supporting the required configurability: It

suggests that security functionalities are specified in the form of a set of configurable

templates, which can be executed/enforced at the cloud tier of SecureIoT compliant systems.

In-line with the layered nature of the system, the cloud tier functionalities take advantage of

edge tier functionalities.

• SECaaS Tier: This tier comprises the cloud-based security services of the project, which as

offered based on the SECaaS paradigm. From a functional perspective, this is the tier where

the SECaaS services envisaged in the DoA of the project reside, including risk assessment,

compliance auditing and programming support functionalities. Other functions that may also

reside in this tier include security automation, management of security-related SLAs for

security interoperability and more (Figure 21). In-line with the layered natures of the system

the SECaaS tier functionalities take advantage of all services of the cloud tier of the system.

The high level description of reference functionalities included in the RA will boost the readers’

understanding of our platform specification in the next Section, where the SecureIoT platform

is introduced. The SecureIoT platform aligns to the RA, not only in terms of the definition of

tiers and cross-cutting functionalities, but also in the functionalities that will be supported and

provided by the SecureIoT platform.

2.5.3 Cross-Cutting Functions

A number of cross-cutting, cross-layer functions are also specified in the SecureIoT RA. These

include:

Page |46




• Management and Configuration: A number of management and configuration functionalities

are applicable to all layers of the system. At the field tier, the Probes need for example to be

configured in order to tune the rate of their data collection. At the edge and cloud tier the

PDPs are subject to configuration in addition to the registries of assets and probes. Likewise,

SECaaS functions can be also configured and managed in terms of the assets that they will

protect, the automation they will employ and more.

• Visualization (Dashboards): At all layers of the RA there is a possibility for visualizing security

information (e.g., in appropriate dashboards). This is for example the case with the registries

or security alerts produced at the edge or cloud tiers for different SECaaS services.

• Administration Shells and Digital Twins: Though not in the direct scope of SecureIoT, the

security information collected and/or processed at the edge, cloud and SECaaS tiers can serve

as basis for running security simulations as part the “digital twins” concept. The development

of the respective digital twins is based on the digital modelling of security aspects based on

data produced and persisted at various layers of the SecureIoT RA.

Page |47




3 SecureIoT Platform Architecture 3.1 Overview The SecureIoT architecture is destined to support a security platform that will deliver SECaaS

services to various IoT systems/platforms owners or operators, in-line with the paradigm

illustrated (at high-level) in Figure 22. In this paradigm different IoT systems provide data to the

SecureIoT services provider i.e. the entity that is deploying and operating the SecureIoT platform.

Accordingly, the SecureIoT services providers provides to IoT systems owners or operators

services such as Risk Assessments, Compliance Auditing and Developers’ Support, along with a

range of security automation (e.g., alerts) and visualization services (e.g., display of information

in dashboards). The latter services are typically provided in-line with a security policy, which is

flexible accessible and configurable by platform operators and owners.

Figure 22: SECaaS Paradigm Overview

3.2 Logical View 3.2.1 Overview

From a logical perspective, the SecureIoT platform will be structured as a multi-layered security

monitoring and enforcement system in-line with the SecureIoT RA. Figure 23 provides a high level

overview of the various layers, along with their (initial) mapping to areas of the SecureIoT

workplan. They are layering of the platform is as follows:

SecureIoT Platform

Risk Assessment Compliance Auditing

Alters Automation

IoT platform #1

Data Collection

IoT platform #N

Data CollectionCross-Platform & Cross-Vertical

SECaaS…….

Single Platform SECaaSSingle Platform SECaaS

Page |48




• IoT systems Layer: SecureIoT is about providing security services to various types of IoT

systems, such as IoT devices and IoT platforms. In this context, the term “IoT system” can be

seen as an umbrella term that can flexibly refer to IoT systems of different granularities and

levels of sophisticated. In-line with mainstream reference architectures for IoT systems (e.g.,

OpenFog RA, IIRA) an IoT system is likely to follow an edge/cloud computing architecture.

SecureIoT is destined to collect security-related information from all elements of such an

edge/cloud computing architecture, including field devices, fog nodes, field networks, edge

gateways and cloud computing infrastructures. Note that the IoT systems layer is not part of

the SecureIoT platform, but rather the layer of field systems that must be secured via the

SecureIoT platform and its architecture. In this context, it is included in this paragraph for

completeness reasons.

• Data Collection and Actuation Layer: This layer is in charge of interacting with the field for a

dual purpose: (i) Collecting security related data from various probes and from all the

different parts of IoT systems and (ii) Driving security-related automation and actuation tasks

such as the configuration of security-related properties of IoT systems. The collection of

security related data is intelligent in the sense that it is configurable and adaptable to the

security context of the monitored IoT systems. This configurability can be driven by the

automation and actuation sub-module of this layer. In terms of the project’s workplan, this

layer of the SecureIoT architecture comprises the modules and functionalities that are being

implemented in WP3 of the project.

• Security Intelligence: This layer analyses the collected data in order to identify security-

related events and indicators in the form of incidents, threats and attacks. It is characterized

as an “intelligence” layer, because it is the place where the SecureIoT reasons over the

security context in order to identify intelligent ways for securing IoT systems, through tuning

security policies, changing security configurations or simply alerting some human (security)

operator of important events. From a technical and technological perspective, the security

intelligence layer comprises a range of data analytics algorithms (including Machine Learning

(ML) and Artificial Intelligence (AI), which are used to detect security events and shape

security policies accordingly. In terms of the project’s workplan, the security intelligence layer

is implemented in the scope of WP4 of the project.

• Security Services (SECaaS): This layer comprises the three SECaaS services that will be

primarily provided by the SecureIoT platform, namely Risk Assessment (RA) services,

Compliance Auditing services and Developer Support services. These services are specified in

detail and implemented in the scope of WP5 of the project. In principle, this layer will also

implement other services that will be based on the data processing outcomes of the Security

Intelligence layer, such as alerting and visualization services (e.g., presentation of security-

related information in dashboards). Note also that all these services can be implemented and

offered on the basis of the SECaaS paradigm, which has been introduced earlier in this

section.

Page |49




• Security Use Cases: This layer leverages the security services layer in order to provide security

functionalities to specific IoT applications and use cases, such as the Industry4.0, the

connected car and the socially assistive robots’ applications of the project. At this level,

different IoT applications leverage SECaaS services (e.g., risk assessments) in order to

enhance their security and cyber-resilience.

Figure 23: High Level Logical View of the SecureIoT Architecture and Mapping to Technical Workpackages

The layered architecture of the SecureIoT platform (depicted in Figure 23) mandates that

modules in the different layers interact through properly defined API (Application Programming

Interfaces). This is a typical layered structure, where modules in upper layers take advantage of

services from lower layers (e.g., like in the popular OSI (Open Systems Interconnection) network

stack). It is also envisaged that the APIs of the SecureIoT layer will be open i.e. accessible by third-

parties rather than visible only internally to other SecureIoT platform modules. This openness is

expected to provide benefits to participants to the project’s market platform, which might be

willing to access specific modules or functionalities of the SecureIoT platform.

In following paragraphs, we describe the above layers of the SecureIoT architecture in more

detail i.e. through giving its anatomy of the main modules and functionalities involved, as well as

their interactions.

Page |50




3.2.2 The Data Collection and Actuation Layer

Figure 24 provides an anatomy of the data collection and actuation layer of the SecureIoT

platform, through illustrating the main modules that it comprises and the high-level interactions

between them. Some of these modules interact with other layers of the platform, namely the

field systems and devices layer, as well as with the security intelligence layer. A description of the

modules and their interactions follows:

• System Probes: These are probes that are deployed in the IoT systems in order to collect

system security-related from them. The latter data include for example information about

the network traffic on a host or device, its CPU (Central Processing Unit) and memory usage,

the status of each submodules and interfaces (e.g., on or off) and more. Physically the probe

can reside within the IoT system or device i.e. at the field layer, as already discussed during

the presentation of the SecureIoT reference architecture. However, from an administrative

viewpoint this is deployed and managed by the device owner in conjunction/collaboration

with the SecureIoT services provider and hence it logically belongs to the SecureIoT platform.

As this section discusses the logical view of the SecureIoT platform architecture, we depict

the system probes as a part of the data collection layer of the architecture.

• Application Level Probes: Application level probes are also deployed in the IoT system or

device in order to provide information about their application-level behaviour e.g., the

movement patterns of robot or a connected car. In many cases, application level behaviours

are very important for understanding security incidents. They are particularly important for

IoT applications that involve smart objects (i.e. objects with semi-autonomous behaviour),

since the way these objects behave may be indicative of abnormalities, especially in the case

of behaviours that deviate from their normal operation. Application level probes feature

many similarities to system level probes, since it they are collecting data from IoT system.

Nevertheless, they feature several differences from both a technical and a business

viewpoint, which is the reason we opt to present them separately in this anatomy of the data

collection layer.

• IoT Probes Registry: The probes registry is a catalogue where all the probes of the SecureIoT

system are registered. The registry serves the following main purposes: (i) First it ensures that

the SecureIoT monitoring system is dynamic i.e. probes can be dynamically discovered,

managed and activated as their become deployed and available to the SecureIoT platform;

(ii) Second it provides a means of controlling the trustworthiness of the data collection, as no

probe can contribute information to SecureIoT unless it is deployed, trustful and register to

the SecureIoT platform; (iii) Third, it provides a means of controlling access to the probes

within the SecureIoT system by keeping track of the consumers of IoT security information.

Registration can be automated (e.g., in cases where each probe announces itself in the

registry) or manual (e.g., probes registered by a security operator). As shown in the figure,

we assume the automated registration (and deregistration) as a primary scenario, which is

the reason why interactions between each probe and the registry are envisaged. These

Page |51




interactions are two-way in order to facilitate acknowledgement of the registration or

deregistration.

• Data Routing: The data routing module of the date collection layer serves the purpose of

delivering information from the probes to appropriate recipients / consumers of IoT security

information. To this end, it interacts with the registry in order to access the available probes

and the consumer processes (i.e. security applications) that are allowed to access their data.

Consumption of IoT security information from the probes can occur at the data collection

layer, but also at the security intelligence layer. Overall the data routing functions ensures

that IoT Security information is delivered to appropriate recipients. It is meant to be a high-

performance function from the latency point of view, as in several cases consumers need to

access and process information from the probes at short timescales. It is typically

implemented through a high-performance streaming middleware, as information from

security probes comes in the form of high-ingestion streams.

• Local Storage: Local storage refers to a local datastore that provides persistence for the

information that stems from the probes. It is characterized as “edge” or “local” datastore as

it is meant to store information close to the field and is distinguished from information that

is stored in the cloud level. While these are deployment decisions and as such part of the

deployment or physical view of the architecture, they are discussed at this point in order to

clarify the rationale of the local storage. In particular, local storage of security data can

facilitate security intelligence based on edge analytics and edge intelligence, as means of

detecting and mitigating events at short/fine timescales. Note that the analysis of information

at the local storage, may involve different types of analytics, but typically streaming analytics

(including high frequency machine learning).

• Security Policy Enforcement Point (SPEP): This module implements security policy

enforcement decisions that are driven by analytics at the data collection and actuation layer

or at the security intelligence layer. The latter decisions are of two main types: (i) Data

collection configuration decisions that are conveyed to the probes, which is the reason why

the SPEP module interacts with system-level and application-level probes; and (ii) Security

actuation and automation functionalities, which involves interaction with the field i.e. the

monitored IoT systems, subject to proper authentication and authorization rules. Note that

SPEP plays an instrumental role on one of key functionalities of the data collection layer of

the SecureIoT platform, namely the intelligence and adaptive nature of the data collection.

In particular, SPEP provides the means for changing the configuration and operation of the

data collection in-line with the security context.

• Management Agents: Security management agents provide the means for interacting with

field IoT systems and devices for the purpose of implementing automation and actuation

functions with security relevance. As already outlined, the latter are subject to proper

authorization and authentication of the actuating actor, in this case the SecureIoT platform.

The deployment of management agents is similar to probes, yet there are differences in their

functionality and operational characteristics, which led us to distinguish them from probes.

Page |52




• Management and Configuration Tools: This module provides the means for managing and

configuring the above-listed elements. In particular, it caters for the configuration of the

probes and their registry, the management agents and their operation, as well as of the SPEP

functionalities. A wide array of management functionalities can be implemented and

provided for each one of the components of the data collection and actuation layer. For

example, the probes can be configured in terms of their deployment properties (e.g., where

they reside) and their data delivery rates. Likewise, the IoT probes registry can be configured

in terms of the probes that are registered to it and their properties. The detailed specification

of specific management and configuration functionalities that will be provided by SecureIoT

is outside the scope of this document. Relevant specifications will be provided as part of WP3

technical deliverables that deal with the management functionalities of the data collection

and actuation layer.

• Visualization (Dashboards): The SecureIoT architecture specifies a dashboard-like

visualization component, where the status of the data collection and actuation layer will be

reflected. This component will visualize the above listed components and their status. It can

will be closely linked to the management and configuration functionalities in order to allow

security operators and the administrators of the SecureIoT infrastructure to visually manage

the various components.

Figure 24: Anatomy of the Data Collection and Actuation Layer

Page |53




As already outlined the data collection and actuation layer will interface (through Open APIs)

with the Security Intelligence Layer of the SecureIoT architecture.

The Data Collection and Actuation layer is also aligned to several concepts of the IoT RAs that have been presented in the previous chapters such as:

• The end-to-end security concept of the OpenFog RA and the IISA, based on the specification of different types of probes that cover all possible elements of an IoT system.

• The Monitor→Analyse→Act pattern of the IISF, based on the inclusion of analysis and automation functions at this layer.

• The positioning of SecureIoT as an overlay over IoT systems (as specified in RAMI4.0 security guidelines), as it interfaces at all layers and systems that comprise an IoT system.

3.2.3 The Security Intelligence Layer Figure 25 provides an anatomy of the security intelligence layer of the SecureIoT platform,

through illustrating the main modules that it comprises and the high-level interactions between

them. A description of the main modules follows:

• IoT Security Template Extraction (ISTE): This module is in charge of identifying security

knowledge based on the processes of data from the data collection layer of the architecture

i.e. from the various probes that are deployed as part of a SecureIoT system. The template

extraction process is essentially a data analytics process, which leverages on training datasets

when available and when supervised learning algorithms are used. In practical terms a

template comprises IoT security knowledge (e.g., about patterns that signal security incidents

or risks) and can be represented in various forms such as rulesets and decision trees. As a

prominent example, the IoT Security Template Extraction module can analyse data from

probes against a training dataset in order to extract rules (i.e. a ruleset) that signify abnormal

behaviour from the security viewpoint. Note that extracted templates are stored in a

database i.e. the IoT Security Templates Database.

• IoT Security Templates Database: This is a datastore that stores the data of security

templates. The latter can be provided in a document format (e.g., XML or JSON format) or

even as active components (e.g., Java or Javascript code implementing the template). The

database interfaces with the template execution engine, which takes advantage of the

existing (and active) templates in order to identify security incidents, alerts, threats etc.

• Global Storage: This is the database infrastructure where data from all the different probes

will be stored in order to enable the extraction and the execution of security templates based

on appropriate analytics algorithms (including data mining and machine learning). In principle

the Global Storage will persist data from multiple probes, that will stem from the data

collection layer of the architecture. It will also keep a global list of deployed probes in order

to facilitate the proper indexing of the data and their used for template extraction and

execution.

Page |54




• Template Execution Engine (TEE): This engine is the core of the system’s intelligence. It takes

advantage of existing security knowledge in order to identify threats, vulnerabilities, incidents

and attacks. As already outlined, existing security knowledge resides in the various security

templates, which are available in the security templates database. The Template Execution

Engine (TEE) is in charge of executing multiple templates at the same time in order to allow

the SecureIoT SECaaS services to benefit from multiple rules and pieces of security

knowledge.

• Contextualization Engine (CE): The Contextualization Engine incorporates domain and

contextual knowledge, which is important for the successful execution of security templates.

It is in charge of putting the operation of the TEE in the right context, through parameterizing

rules, thresholds and other context specific parameters for identifying, scoring, staging and

assessing security incidents, threats, risks and attacks. In general, the CE customizes the

operation of the TEE in-line with business requirements (i.e. the business domain) and

contextual knowledge (i.e. the specific environment of the deployment). As an example,

consider a threshold-based rule that is used to identify abnormal behaviour. In this case, a

template will typically define the parameters on which the threshold has to be defined, while

the CE will be able to customize the value of this threshold for use in a specific business and/or

security context.

Figure 25: Anatomy of the Security Intelligence Layer

IoT Systems (Platforms &

Devices)

FieldNetwork

FieldDevice

Edge

Cloud

App Intelligent(Context-

Aware)Data

Collection

Actuation & Automation

Open APIs

IoT Security Template Extraction (Analytics)

Template Execution

Engine(e.g., Rule

Engine)

Global Storage(Cloud)

(SecureIoT Database + Probes Registry)

IoT Security Templates Database

Templates

ContextualizationEngine

IoT Security Knowledge Base

Security Policy Enforcement Point

WP4

Open APIs

WP3Management &

Configuration ToolsVisualization (Dashboards)

Page |55




• Security Policy Enforcement Point (SPEP): Similar to the SPEP module at the data collection

layer, this module is in charge of enforcing security policies following the execution of a

specific template and the discovery of some security event that triggers security related

actions. The SPEP module is destined to boost security automation, through automating

security actions towards the field. To this end, the SPEP of the Security Intelligence Layer is

likely to interact with the SPEP at the data collection and actuation layer of the SecureIoT

architecture.

• IoT Security Knowledge Base (ISBK): This knowledge base comprises external IoT security

knowledge, including for example knowledge about known threats, attacks, incidents and

vulnerabilities. It is an expert system with inference capabilities, which can be used to deduce

whether an identified security pattern or behavior matches known attacks or other incidents.

As such it interfaces with the template execution engine in order to enable such matching

and resolution.

• Management and Configuration Tools: This module will be in charge of configuring and

managing their above-listed components of the security intelligence layer. The configuration

will concern their deployment and operational properties. A detailed specification of the

respective configuration functionalities will be provided as part of the WP4 technical

deliverables, where most of the components and modules of the Security Intelligence layer

will be specified in detail.

• Visualization (Dashboards): This module will visualize the status, deployment configuration

and operational parameters of the various components of the security intelligence layer. It

will be integrated in the management and configuration tool in order to enable visual access

to their functionalities.

As evident from the above-listed descriptions, the templates extraction mechanism is the main

vehicle for extracting data-driven security knowledge. Moreover, the contextualization engine

customizes the use of this knowledge for different business contexts. The process is illustrated in

Figure 26, which presents the process of extracting a security knowledge template based on

security data from probes. The contextualization of the template can be based on historical data

from the probes, as well as on external data associated with the security/business context.

Security Data

Pattern Detection (Machine Learning)

Knowledge Extraction (Ruleset,

Decision Tree)

Template Formulation

(Document)

Historical DataExternal Data Sets

Contextualization

Page |56




Figure 26: Example of Template Extraction and Contextualization

The results from the execution of security templates can be stored in the Global Storage or

provided through Open APIs to the SECaaS layer of the architecture. The latter layer can also take

advantage of the Open APIs in order to activate security templates, force their execution and

derive their results to be used for risk assessment, compliance auditing, alerting, production of

notifications and more.

3.2.4 The SECaaS Layer

The SECaaS Layer of the architecture implements the security functionalities that will be built-in

in the SecureIoT platform and hence directly supported by the SecureIoT architecture. These

functionalities will be provided as a service based on the SECaaS paradigm. They include risk

assessment, compliance auditing, developers’ support, alters and visualization functionalities

and are described in more detail in the following sections. All these functionalities will be able to

access data and services of the SecureIoT platform through Open APIs.

3.2.5 The Use Cases Layer

The SecureIoT architecture specifies that security integrators will be able to implement security

use cases leveraging on the risk assessment, compliance auditing and altering functionalities of

the SECaaS layer. These functionalities will be accessible through Open APIs as well. In principle,

developers and deployers of IoT security use cases could also leverage the functionalities of the

security intelligence layer directly, even though this is not foreseen as a primary option for the

SecureIoT use cases. One of the later sections of this deliverable illustrates how the use cases

integrators intend to use the SecureIoT architecture.

3.3 Development View A high-level development view of the architecture is depicted in Figure 27. It presents the

structure of the main SecureIoT modules to be developed in a layered fashion, clustering

together modules from the field (i.e. probes), edge (i.e. data routing, probes registry, policy

enforcement points), cloud (i.e. template extraction, template execution, contextualization,

global storage) and service (i.e. compliance, risk assessment, developers support) tiers.

Moreover, cross-cutting functionalities (like management, configuration and visualization) are

also depicted. The diagram explains also the dependencies between some modules through

identifying modules that use other modules. This “usage” dependency is outlined across layers

and tiers (e.g., each tier/layer uses components and services from its underlying layer), but also

with a layer (e.g., in the edge tier/layer the data routing uses the IoT probes registry).

Page |57




Figure 27: High-Level Development View of SecureIoT – Package Diagram

3.4 Process View The sequence diagrams of Figure 28 and of Figure 29 depict the dynamic behaviours of the data

collection and of the template execution processes presented as part of the logical view of the

architecture. In particular, the security data collection sequence involves the dynamic

registration of platforms and probes within an IoT probes registry (called Common

Interoperability Registry in this context) as a means of enabling the routing of information at the

edge tier and its subsequent storage both a local/edge level and at global/cloud levels.

Page |58




Figure 28: Platform and Probes Registration – Data Collection

Likewise, the template execution process is based on templates available within a database of

templates, following the process of identifying patterns and extracting templates. The execution

leverage data from the global storage. A last step in the execution process involves the matching

of identified threats/incidents to knowledge available in the SKB component.

Figure 29: Template Extraction and Execution Process

3.5 Physical View A high-level physical view of a security system that is compliant to the SecureIoT architecture is

illustrated in Figure 30. This figure is a deployment diagram, which clarifies aspects of the physical

configuration of the SecureIoT system. Multiple probes from different platforms and devices are

deployed and used in order to collect information from probes of different systems and devices,

notably in cases where these systems are characterized by geographical or administrative

Page |59




distribution. Information is routed from the edge gateways to the cloud, where it is stored in a

global datastore i.e. datastore comprising and combining information from multiple edge

gateways. The figure illustrates also some of the main components that are deployed in the cloud

tier, including the security knowledge base.

Figure 30: High-Level SecureIoT Deployment Diagam

Page |60




4 SecureIoT Security Services Specifications SecureIoT Security Services (SECaaS) will leverage on the information gathered by the Intelligent

Data Collection and the advanced models and results provided by the Monitoring & Analytics

component. Thus, the requirements of the SECaaS to the different elements and technologies to

be developed within WP3 and WP4 shall be followed to enable the realization of advanced

security functionalities that will be delivered as a service, to IoT developers, managers, security

officers and final users. In following paragraphs, we provide an initial description of the SECaaS

services of the project, given the presented SecureIoT architecture. In particular, a first effort to

explain how the various modules and information flows of the architecture will be exploited to

deliver these services. Note however, that the detailed design and description of the services is

destined to be provided in WP5 deliverables, as part of on-going work in this workpackage.

4.1 Risk Assessment and Mitigation 4.1.1 Data collection specifications

The Risk Assessment & Mitigation Services (RAM) will collect processed data from various sources

of the SecureIoT underlying infrastructure to successfully assess potential risks and propose

mitigation actions. As shown in Figure 31 below the main volume of data for risk assessment will

be driven by information produced from the Monitoring & Analytics components from WP4. The

data will be retrieved either by subscribing to the data streams or by accessing to the SecureIoT

data storage where the Analytics results are persisted. Moreover, information will be retrieved

from the Security Knowledge base where the NIST’s Common Vulnerability Scoring System will

drive the computation of a vulnerabilities’ “likelihood” factor.

4.1.2 Data Analytics Specifications

As shown in Figure 31 below and already mentioned the RAM services will collect analysed

information from the Monitoring & Analytics component. This information will be combined with

the Security Knowledge base to produce intelligent risk assessment calculations. As part of the

Risk Assessment (RA) engine different configurations and weight in the criticality of risks will be

possible and will be used in the calculations.

4.1.3 Security Policy Enforcement Points Specification

The results produced from the RA engine will be presented to end-user accompanied with

possible risk alleviation activities. These activities will include enforcement of proper security

policies based on the capabilities specified by the monitored platform and the SecureIoT PEP. As

shown in Figure 31 as soon as a mitigation action is specified the RA engine should be capable of

sending the command to the exposed interface from the PEP at the Data Collection & Actuation

Page |61




layer. Then the SecureIoT PEP will be responsible to execute the chosen action based on the

exposed capabilities of the monitored platform.

Figure 31: Risk Assessment & Mitigation Interactions

4.1.4 Cross Layer Data Exchange Specifications The RAM services as already mentioned should be capable to retrieve and push data to all the

SecureIoT layers. This is required in order to retrieve results from Analytics services, security

knowledge and additionally to be able to enforce mitigation actions from the User.

4.1.5 Cross Platform Data Exchange Specifications The RAM services would directly benefit from utilizing a cross platform data exchange

mechanism. But in the future, we could investigate the possibility of enhancing the RA procedure

with additional context by using result and weights calculated from different security platforms

and different scenarios.

Page |62




4.2 Developer Support Services 4.2.1 Data collection specifications

Data Collection Specifications may be used as a context collector to add further conditions for

access control policies such as type of device. More specifically, an HTTP request can be used to

provide such context information. During data collection, the PIP will retrieve the necessary

attributes for the policy evaluation from several smart probes and communicate with the PDP in

order to trigger for a decision.

In the Data Collection and Actuation Layer of the RA, we foresee the usage of System Probes in

order to collect system security-related data, possible the usage of Application Level Probes in

order to provide information about their application-level behavior and the Data Routing to

deliver the information from the probes to appropriate recipients of IoT security information in

our case in the PIP.

4.2.2 Data Analytics Specifications Data Analytics Specifications may be used to further analyse the collected context and add

further combined conditions for access control policies such as type of device, location and

environment information. During data analytics, the PDP collects all the necessary information,

yield the final decision and passes this decision to the PEP at the edge/cloud level.

In the Security Intelligence Layer, we foresee the usage of the ISKB (IoT Security Knowledge Base)

to identifying security knowledge based on the processes of data from the data collection layer

and extract rules to be enforced, the CE to incorporate domain and contextual knowledge for the

successful execution of security policies and the Global Storage to store data from all the different

probes.

4.2.3 Security Policy Enforcement Points Specification The Security Policy Enforcement Points Specification will receive application specific access

requests and translate them to XACML9 access control requests, then it denies or allows access

to the resource. Both data collection and analytics may be used an additional context for access

control purposes. Developer support service will provide a parametric contextual information

(e.g. location, device type, time of interaction) of an HTTP request that can be used in order to

perform policy enforcement. Based on the information collected and the on the decision taken

on the PDP, the security PEP enforces the necessary policies.

In the Security Intelligence Layer, we foresee the usage of IoT Security Templates Database to

store the data of security templates of the XACML policies and the TEE to execute the polices.

9 https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml

Page |63




The SPEP of access control will be able defined at both Data Collection and Actuation Layer and

Security Intelligence Layer to enforce the security policies.

4.2.4 Cross Layer Data Exchange Specifications Context-aware access control is extensible and is based on the context and not on a specific layer.

Open APIs between the layers will used for the cross-layer data exchange. In addition, the usage

of Management and Configuration Tools for managing and configuring the used elements and

the Visualization (Dashboards) for the status of the data collection and actuation layer will also

assist in the cross-layer data exchange.

4.2.5 Cross Platform Data Exchange Specifications The programming models used for the developer support services will comply with existing

widely used and well-established standards that are independent of the platform used. Typically

access control mechanisms rely on a centralized authority and do not consider interactions across

multiple platforms that may be based on different access control approaches. The programming

support service of SecureIoT will implemented on a cross-platform language, to support different

IoT platforms at different platforms of the IoT infrastructure such as device, edge, core, field and

smart objects. Again, we foresee the usage of Management and Configuration Tools and the

Visualization (Dashboards) to support cross platform data exchange independently of the

platform.

A high-level overview of all aforementioned SecureIoT Platform architecture components we

foresee to be used for the Developers Support Service included in Figure 32 below.

Figure 32: Developers Support Service mapping to the SecureIoT platform architecture

Page |64




4.3 Compliance Auditing 4.3.1 Data collection specifications

Compliance Auditing services rely on several data assessing compliance of an IoT system. The

data required for assessing compliance of the IoT system to be audited for adherence to a specific

rule shall be gathered using an asset list, e.g. a CMDB, and an according controls catalogue.

Moreover, data collected by this module enable the monitoring module for auditing the IoT

system.

4.3.2 Data Analytics Specifications Data Analytics may support a continuous auditing model. In this case, which WP5 will assess, the

data of the IoT system shall be analysed continuously by the Data Analytics module facilitating

detection of a breach on conformity.

4.3.3 Security Policy Enforcement Points Specification Within this module the relevant policies of the IoT system may reside. These policies and this

module will facilitate evaluation of conformity to the Security policy, which the IoT system shall

adhere to. Moreover, in a continuous mode, this module might ensure conformity based on

results of monitoring by the Data Collection module and insights gained using the Data Analytics

engine.

4.3.4 Cross Layer Data Exchange Specifications

Compliance Auditing will involve data usage across the layers of the SecureIoT solutions. Cross

Layer Data Exchange will facilitate the modularity of a solution and supports evaluation of

compliance using data from various layers.

4.3.5 Cross Platform Data Exchange Specifications In future solutions IT systems are supposed to involve micro-services of multiple platforms.

Hence, there are several ways to audit those systems. Usually, the provider of the IoT system

would rely on compliance reports of the other platform provider proving its compliance to the

rules of the IoT system provider. In a future regime of dynamic changes this kind of auditing this

may be too static. Therefore, the continuous auditing of various systems might be joined using

the Cross-Platform Data Exchange in case of continuous auditing.

Page |65




4.4 IoT Security Knowledge Base 4.4.1 Data collection specifications

In work package 5 (task 5.1), we are building an IoT Security Knowledge Base (SKB) that stores

structured information on threats including, but not limited to CPE, CWE, CVE and CAPEC

specifications. The CVE data source denotes Common Vulnerability and Exposure, publicly known

cybersecurity vulnerabilities, CWE denotes Common Weakness Enumeration, list of common

software vulnerabilities and CAPEC represents Common Attack Pattern Enumeration and

Classification, Dictionary and classification taxonomy of known attacks. We define these

information as Cyber Threat Intelligence (CTI) sources.

An overview of the components of the SKB is provided in Figure 33. The CTI collector is

responsible on collecting and storing external CTI data sources, it also provides an API endpoint

to store data provided by other components of SECaaS in the CTI database. The correlator

component is responsible on correlating the available information to generate knowledge graphs

where their vertex are either assets, vulnerabilities, weakness, or attack patterns and their edges

their relations. The graph computing base is responsible on providing a query layer for the

available graphs to extract from them security properties of available assets.

Figure 33: The different components of the IoT Security knowledge base

Below, we will describe the specifications and the interaction of this security knowledge base

according to the different components and layers of the SECaaS architecture.

The classes of CTI database are depicted in Figure 44.2. The CVE class contains the attributes of

a CVE document including its label, for example CVE-2018-13074. The CVSS attribute denotes the

cvss score of the cve. The summary is a brief summary of the cve. ExploitDBid is the id of the

exploit-db module if it exists. Nessus is list of the id of the different nessus module. Access is a

three information about the exploit of a vulnerability, authentication indicate if it needs

authentication to exploit this vulnerability, complexity is the level of complexity of the exploit of

this vulnerability, vector indicates the vector of the attack for this vulnerability. Each CVE is linked

Page |66




to one or many CWE and CAPEC and it is related to one or many CPE which identifies the

vulnerable configuration.

The CWE class contains a label which is the id of the cwe, a name, a description and the list of the

main consequences after the attack. A CWE is linked to one or many CVE and one or many CAPEC.

It is also linked to one or many CWE.

The CAPEC class contains a label which is the id of the capec, a name, a description, the list of

attack prerequisites and the required resources. A CAPEC is related to one or many CVE, and one

or many CWE. It is linked to one or many CAPEC.

The CPE class contains only a label which is the identifier of the cpe. It is only related to one or

many CVE.

Figure 34: The classes of the CTI database and their relationships

4.4.2 Data collection specifications

The SKB base relies on its internal data collection component to autonomously collect publicly

available CTI sources through, web crawling, open API or available documents in JSON or XML

format. The collected data are stored as documents in a dedicated database to be queried from

other components of the SKB. Dedicated probes are also deployed to collect information of the

Page |67




IoT system to extract and store in the SKB information about the running assets and identify or

define their CPE identifiers.

4.4.3 Data Analytics Specifications The collected and stored data in the SKB is then pre-processed, transformed and aggregated to

build graphs from them. A set of API endpoints must be specified to query the graph database

containing these graphs. Therefore, the template execution engine performing analytics can rely

on the contained information to have better profiled and accurate data analysis.

4.4.4 Security Policy Enforcement Points Specification

The data collected in SKB refers to identifiers, threats, attacks and vulnerabilities. The primary

purpose is not so to be used to directly support policy enforcement. This may happen indirectly

through the data analytics.

4.4.5 Cross Layer Data Exchange Specifications The SKB contains information about IoT assets that are collect through dedicated probes. The

SKB will provide an API for these probes to add information. The main objective is to identify and

match the assets of an IoT deployment to the CPE database, providing coherent and harmonized

naming. There is no restriction about the type of assets (application device, etc.). A standard API

should be use for accessing the SKB easily.

4.4.6 Cross Platform Data Exchange Specifications

The objective of the SKB is to construct a consolidated view of CTI data sources in view of the

current IoT deployment. These data-sources are actually public and are not so sensitive.

However, it also contains information about the different assets of the running system. It is thus

important to have an access control for the SKB.

4.5 SECaaS Services Management and Configuration The Continuous Integration (CI) and Configuration of SECaaS services will provide a methodology,

an environment, tools and automated mechanisms to warranty an agile, reliable and robust

development of the SECaaS, following modern agile and DevOps practices. Thus, it can be

considered as a horizontal task that will support all the development of WP5 (and optionally of

WP3 and WP4).

The requirements established to the different components of SecureIoT are the following:

Page |68




• Use a Source Code Management (SCM) tool during the whole development lifecycle, e.g.,

GitLab or GitHub.

o Use issues to manage the development of new features and the fix of bugs.

o Rely on the SCM for version control and code repository.

o Develop the new code in separate branches. Use Pull Request (PR) or Merge

Request (MR) mechanisms to integrate them in the master or development

branches. Commits to master or development branches are not allowed.

o Perform small commits and small pull or merge requests.

• Continuous Integration and Testing

o Include automated building using Docker.

o Include unit tests. Use of external component’s APIs should be mocked.

o Include integration tests using Docker and docker-compose.

o Integrate automation tools to execute CI tests each time a commit or PR/MR is

done.

o Integrate a code coverage tool. Percentage should be higher than 70-80%.

o Integrate a tool that detects style errors.

• Continuous Deployment

o Docker images must be published.

o Docker-compose must be used to illustrate the configuration, deployment and

interconnection of SecureIoT components.

• Documentation

o Include a README file in the repository with the following minimum content:

▪ Description

▪ How to build and install

▪ API overview and examples

▪ API reference documentation using Swagger or a similar tool.

▪ How to run tests.

• High-availability

o Documentation, docker images and docker-compose files must consider how to

deploy the component in a high-availability environment, addressing specifically

aspects like scalability or elasticity.

Page |69




5 Candidate Implementation Technologies 5.1 Overview and Purpose This section complements the development view of the SecureIoT architecture, through

illustrating some of the implementation technologies that can be used in order to develop and

integrate the various modules of the SecureIoT architecture, as part of the SecureIoT platform.

The SecureIoT architecture has been described in an implementation technology agnostic

manner. This section aims at shedding light on concrete implementation options for the

technologies that will be used to realize the SecureIoT platform, notably options that are

compatible with the SecureIoT architecture. Note however that the components of the SecureIoT

platform will be implemented in other technical workpackages. This section aims at providing

implementation insights for developers and deployers of the platform, without however

restricting their spectrum of options. It is therefore likely that the actual implementation of the

SecureIoT uses alternative technologies that deviate from the ones listed in following paragraphs.

The various technologies are presented in a way that matches the layers and the components of

the logical view of the SecureIoT architecture.

5.2 Implementation Technologies for the Data Collection and

Automation Layer 5.2.1 Probes and Data Collection Agents

The SecureIoT architecture distinguishes between system-level and application-level probes that

will provide security-related data about IoT systems, devices and applications. System-level

probes are general purpose and can be supported by a data monitoring and collection stack, such

as the Elastic stack10. In this context, we envisage system level probes to be implemented as

“Beats”, which are the single-purpose data shippers of the Elastic stack. They are lightweight

agents, which are able to send data from hundreds or thousands of machines and devices to

other components of the stack such as Logstash or Elasticsearch.

While system level probes are served from a general-purpose infrastructure, the implementation

of IoT application level probes are specific to the application at hand. We therefore expect

custom implementations for each one of the systems and devices used in the project’s use cases.

This is for example the case of the development of probes for LuxAI’s robot, in order to enable

the collection of application-level data from it.

10 Elastic.io

Page |70




5.2.2 Data Routing and Data Bus

Following the collection of data from the probes, there is a need to route these data to

appropriate consumers at the data collection and/or security intelligence layers of the SecureIoT

architecture. Given that the data including streams with high ingestion rates, high performance

routing is needed in terms of the reliable handling of large amounts of high velocity data streams,

as well as in terms of low-latency in the processing of their data. These requirements will be

served by the use of a high-performance streaming middleware framework such as Apache

Kafka11.

5.2.3 Data Persistence

In a production deployment of SecureIoT, the system shall be able to handle large volumes of

data that feature the BigData properties. In addition to a data warehouse, SecureIoT is

considering the deployment of BigData infrastructure for persistence. More information is

provided in deliverable D3.1, which is establishing the project’s data collection and analytics

infrastructure in-line with the structuring principles of SecureIoT.

5.2.4 Management, Configuration and Visualization Tools SecureIoT will develop its own management, configuration and visualization tools. To this end,

existing libraries will be used, including the libraries that enable the visualization of security

information in frameworks like Beats of the Elastic stack.

5.3 Implementation Technologies for the Security Intelligence Layer 5.3.1 Data Analytics Engines

SecureIoT should provide a framework for the execution of machine learning and deep learning

algorithms for security intelligence. Hence, popular machine learning toolkits (like the ML toolkit

of Spark) and statistical computing frameworks (e.g., like R and Python) will be considered.

Likewise, frameworks such as H2Oai and TensorFlow will be considered in order to enable the

execution of deep neural networks.

5.3.2 Security Knowledge Base

CTI data sources that are collected will be stored in a permanent manner as documents. A NoSQL

database such as MongoDB will be preferred to index each of these documents. This data is then

used when the SKB is constructed to automatically extract valuable information for the running

IoT assets. Information in the SKB could be represented as graph of knowledge. Therefore, we

11 kafka.apache.org

Page |71




rely on orientDB for graph storage and Tinkerpop computing framework to query them and

lookup available information.

5.4 Technologies for Continuous Integration and Configuration of

Services at the SECaaS Layer In terms of CI and configuration of the SECaaS services, the following tools will be considered

for various tasks:

• Project management

o Taiga (https://taiga.io/)

• Source Code Management (SCM)

o GitLab (http://gitlab.com/)

o GitHub (https://github.com/)

• Continuous Integration (CI)

o Docker (https://www.docker.com/)

o GitLab runners (https://docs.gitlab.com/ee/ci/runners/)

o Jenkins (https://jenkins.io/)

• Continuous Testing (CT)

o Travis CI (https://travis-ci.org/)

• Continuous Configuration

o Consul (https://www.consul.io/)

o Ansible (https://www.ansible.com/)

• Continuous Deployment

o Rancher (https://rancher.com/)

o Kubernetes (https://kubernetes.io/)

o Docker swarm (https://docs.docker.com/engine/swarm/).

http://gitlab.com/

https://github.com/

https://www.docker.com/

https://jenkins.io/

https://www.consul.io/

https://rancher.com/

https://kubernetes.io/

Page |72




6 SecureIoT Use Cases Architectures: Initial

Approach 6.1 Industry4.0 Security Use Cases The integrated Industry 4.0 usage scenario is comprised of three distinct usage scenarios

spanning different levels within the IoT context. The first level is the shop floor with machinery

that produces a product and machine operators who control the machines and have access to

human machine interfaces such as head mounted displays or IoT devices in general. In this case,

the machinery involved is an injection molding machine producing electrical connectors.

Figure 35: Industry 4.0 Use Case Overview

The second level consists of the IoT Platform which is hosted within the organization that owns

the shop floor. The first and second level are considered the “Local” environment. Lastly, there

can also be IoT services provided by external organizations. This third level is considered the

“Outbound” environment.

On the shop floor level, the injection molding machine is controlled by the machine operator. In

addition, it receives control instructions from the IoT Platform and send diagnostic data to it. The

machine operator uses an IoT device with a human machine interface, i.e., a head mounted

display. This device guides the machine operator and receives commands and feedback from the

operator in turn, e.g., through speech inputs. It may also collect other data, such as location data

and visual data. An exemplified data flow for diagnostics that encompasses possible placement

of probes is shown in Figure 36.

Page |73




Injection Modling Machine

GuidanceHead Mounted

DisplayMachine Operator

diagnostic data

aggregate and convert data for visualization

processed diagnostic data

Diagnostics Probe

diagnostic data

processed diagnostic data

represent

opt

abnormal machine operationadapt machine operation

Figure 36: Example Diagnostic Data Probe

To guide the machine operator, the head mounted display receives instructions from the IoT

Platform and sends the machine operator’s input to the platform for processing. Responsible for

data processing on the IoT platform are microservices, each with a specific set of responsibilities.

For example, one microservice may be responsible for speech processing, while another is

responsible for sending control commands to the machinery on the shop floor, and yet another

guides the machine operator. An exemplified data flow for guidance that encompasses possible

placement of probes is shown in Figure 37: Example HMD Data Probe.

Head Mounted Display

Machine Operator

Guidance SpeechProcessor

request guidance viaspeech control

speech data

speech data

HMD Probe

formalized speechinformation

guide

instructions

speech data

instructions

instructions

formalized speech information

Figure 37: Example HMD Data Probe

Page |74




In addition to the local IoT Platform microservices, it may be possible to integrate third party

services from partners outside of the local organization. These services may also influence the

control signals from the IoT platform to the shop floor machinery.

Configurator ExtractorInjection Molding

MachineConfiguration

Probe

ProcuctConfiguration

extract IM configuration

Configuration

Configuration

ProductConfiguration

Figure 38: Example Configuration Data Probe

One example of an outbound service is a product configurator. This configurator is used by

engineers to virtually assemble a product from supplier provided parts. The result is a product

configuration file, that can be send to a production machine to assemble it. In this case, the

product configuration file is send to an extractor, which extracts parts specifications from the

product configuration so that the injection molding machine can produce the required part. An

exemplified data flow for configuration that encompasses possible placement of probes is shown

in Figure 38: Example Configuration Data Probe.

Page |75




6.1.1 Logical View IoT Systems(Platforms &

Devices)

WP3 WP4 WP5 WP6

Intelligent(Context-Aware)

DataCollection

Actuation &Automation

Monitoring& Analytics

(SecurityIntelligence)

RiskAssessment

ComplianceAuditing

Developers’Support

Alerts &Visualization

Use Case #1 -Head-

Mounted Display

Use Case #2 -Injection Molding

Industry 4.0 IoT Platform

Industry 4.0 Virtualized

Use case

Industry 4.0 Probe Data Aggregation

Service

Injection Modlding Machine

Head Mounted Display

Use Case #3 -Configurator

Figure 39: High Level Logical View of the SecureIoT Architecture and Mapping

6.2 Healthcare and Socially Assistive Robots Use Cases The Socially Assistive Robots and IoT Applications (SAR) scenario consists of multiple edge devices

at edge and different cloud platforms.

The QTrobot itself consists of a main control board (Intel x86 multicore) running a linux operating

system. This board control communicates with each robot motor’s controller via specific serial

communication protocol to command each motor and read the sensory feedback. Other

peripheral devices such as robot 3D camera and microphone array are connected to the main

board using USB interfaces. The communication with the external world of the robot is done

using two WIFI interface; One is mostly used to connect robot to the QTrobot Tablet and the

other one connects robot to different cloud platforms via home network.

QTrobot Tablet is an android-based tabled which communicate with the QTrobot via direct WIFI

connection. The communication protocol between robot and tablet is based on Robot Operating

System (ROS). This tablet is mostly used to program and launch user’s applications using QT

graphical programming interface.

QTrobot Clould is the placeholder for robot applications, user profiles and many other contents.

QTrobot communicates with the clould platform using different web services and RESTful API.

Page |76




Home component of the CC2U system includes Ethernet, Bluetooth and Wi-Fi interfaces, multiple

USB interfaces to connect with different peripherals such as wearable sync dongles and sensor

boards. It collects data from the home sensors, processes it and sends it to the CC2U cloud.

CC2U cloud is a server-based environment that collects data from all CC2U User exposed devices,

processes it and feeds it to the user through the web-based UI or to other 3rd party platforms

through RESTful API.

Data probes will be implemented at different communication points in edge such as component

internal communication (e.g., motor commands/joint positions), QTrobot tablet (ROS messages)

and CC2U home gateway (collects data from the home sensors). Moreover, data probes will be

also implemented in cloud to, for example, monitors information (REST JSON/data) passed

through QTrobot to CC2U and QT cloud platforms. The details of data collection are explained in

SAR “Use cases specifications” SecureIoT D6.1 [SecureIoTD6.1]. These probes provide the logging

capabilities of a system to demonstrate accountability for compliance auditing services.

Figure 25 shows an overview of the different subsystems and their connections in the Socially

Assistive Robots and IoT Applications scenario. Further details about the architecture and

technologies that will be used in the “Socially Assistive Robots and IoT Applications (SAR)” Use

Cases are included in SecureIoT D6.1 [SecureIoT D6.1].

Figure 40: Overview of the different subsystems involved in the Socially Assistive Robots and IoT Applications scenarios

6.2.1 Logical View The application of SecureIoT architecture to the Socially Assistive Robots (SAR) use-cases will

imply collecting security, system and application level information from the main IoT assets

Page |77




such as QTrobot and CC2U cloud platform, QTrobot, QTrobot Table and CC2U home gateway.

Figure 41: Logical View of SAR Security System

Figure 41 presents the logical view of SecureIoT mapped to the SAR scenarios and assets. The

socially assistive robots and IoT applications are categorized in four different scenarios each

consists of multiple use cases. The scenarios have been constructed in an extensible manner to

validate different SECaaS services by involving more actors, services and covering different

security requirements.

The following table summarizes the main coverage of SECaaS services by each scenario.

Scenario

ID

Scenario

Name

Main SECAS services

(with order of coverage)

SAR1 Cognitive & physical

games

1. IoT Risk Assessment and Mitigation

2. IoT Developers Support

SAR2 Monitoring & checkups 1. IoT Compliance Auditing

2. IoT Risk Assessment and Mitigation

3. IoT Developers Support

SAR3 Daily Calendar and

System Admin

1. Legal and regulatory implications

2. IoT Compliance Auditing

SAR4 Companionship 1. IoT Developers Support

2. Legal and regulatory implications

Table 3: SECaaS Services for SAR Scenarios

The coverage of the SECaaS services are not limited to what listed in the above table. For

example, the IoT risk assessment and mitigation service can be evaluated in each scenario

Page |78




separately. This is due to the extensible nature of the designed scenarios to involve more actors

and subsystems (edge and cloud) as scenarios evolve from SAR1 to SAR4.

As we have described before, data probes will be implemented at different edge and cloud levels.

The application level data will also be monitored at different level depending on each use cases.

An interesting example of application level probe within the Cognitive & physical games scenario

is to monitor high-level commands from game application and relevant robot’s motor

commands/joint positions. The collected data can be passed to IoT Security Template Extraction

(ISTE) to create the context-based IoT security template which later will be used by Template

Execution and Contextualization Engines (TEE/CE).

6.3 Connected Car and Autonomous Driving Use Cases For the “Connected Car and Autonomous Driving” (CAD) Use Cases, the Field Device is an IoT

vehicle OBU (onboard unit), this device is embedded inside a vehicle that performs data capture

on vehicle data networks. This device also facilitates the transport of captured data from the

vehicle (acting as the Edge device) to the IoT Platform.

The IDAPT device (OBU) periodically captures vehicle performance data from the vehicle CAN

bus, movement data from the embedded GPS/IMU module and environmental data from nearby

vehicles/infrastructure from the embedded V2X module. This data is aggregated in the IDAPT

OBU and sent to the IoT platform for data processing. Additionally, the IDAPT OBU will provide

probe data to the SecureIoT platform from sources such as the vehicle CAN bus.

The FIWARE IoT platform (as mentioned in Section 2.3.2) will be used to receive, validate and

store data sent by the IDAPT OBU. A back-end application will exploit the FIWARE IoT platform

functionalities, capabilities and APIs to gain access to the vehicle data provided by the IDAPT OBU

and to apply data aggregation and logic based on the respective Use Case.

Further details about the architecture and technologies that will be used in the “Connected and

Autonomous Driving” Use Cases are included in subsection 5.2 of SecureIoT D6.1.

Data probes will be implemented in both the IDAPT OBU and in the FIWARE IoT Platform to

facilitate the validation of end to end data transmission. An example of an application level probe

would be to ensure movement data (such as a vehicle speed) is consistent from the initial data

capture (raw vehicle CAN data), IDAPT OBU application processing (application data/JSON),

IDAPT OBU network traffic (IP packets), IoT Platform reception (IP Packets) and IoT Platform

(FIWARE Cygnus/Orion Context Broker). An example of this can be found below in Figure 42.

Page |79




IDAPT CAN Interface IDAPT App CAN Vehicle Speed Probe

rxVehSpeedCANMsg

IDAPT App FIWARE Int

H/W SENSOR App - CAN App - Core App – FIWARE API

IDAPT App Core

decodeVehicleSpeedSignal()

updateCurrentVehicleSpeed()

preparePeriodicRecord()

sendPeriodicRecord()

IDAPT Network (IP)

IP Interface

sendProbeRecord()

Figure 42: Example Vehicle Speed Probe - IDAPT OBU

Application level probes such as the example above and system level probes such as CAN bus

load will be provided to the SecureIoT SECaaS services to facilitate the monitoring of irregular

messaging activity on the vehicle CAN bus for risk assessment services (see Figure 43).

Using these probes provides the logging capabilities of a system to demonstrate accountability

for compliance auditing services (see Figure 43).

6.3.1 Logical View

The application of SecureIoT architecture to the CAD use-cases will imply collecting security,

system and application level information from the main IoT assets involved: the IDAPT OBU and

the different components or Generic Enablers (GEs) or FIWARE. Figure 44 presents the logical

view of SecureIoT (Figure 23) mapped to the use-cases assets.

Page |80




Figure 43: High Level Logical View of the SecureIoT Architecture and mapping

At the same time, at the monitoring and analytics layer, specific security template shall be

developed in order to extract advanced knowledge, to detect abnormalities and threats from the

collected data or even to predict them in a running deployment. Nevertheless, CAD security

templates will be executed by SecureIoT execution engine (Figure 25: Anatomy of the Security

Intelligence Layer) and therefore additional component at this tier will not be needed.

Finally, the holistic security of the CAD use-cases will be improved, monitored and assessed

thanks to the SECaaS developed within WP5.

As it can be seen, the main adaptations needed to apply SecureIoT to WP6 CAD use-cases are

limited to the development, customization and deployment of appropriate data probes. A more

detailed view of the data collection layer is presented in Figure 44, highlighting the new

components explicitly created for the sake of the CAD scenarios.

Page |81




Figure 44: Anatomy of the Data Collection and Actuation Layer including the system and application probes to be developed and deployed for the Connected Car and Autonomous Driving use-cases.

Page |82




7 Conclusions This deliverable has introduced the SecureIoT architecture, which specifies the main building

blocks of the security systems that will be developed in the project and drives their integration.

The SecureIoT architecture specification has been driven by a number of requirements and

concepts that have been introduced by standards-based reference architectures and their

security frameworks. In particular, it has been specified in order to support end-to-end security,

based on monitor→analyse→act functionalities. Moreover, the SecureIoT architecture is

specified as a complementary, overlay and cross-cutting systems to IoT platforms.

As a first step to introducing the architecture of SecureIoT systems we have presented a high-

level reference architecture. This RA serves as communication device, by introducing the various

tiers/layers and cross-cutting functions of any SecureIoT system. Accordingly, we have presented

a more detailed technical architecture for SecureIoT systems, focusing on the presentation of the

its main modules in the form of a logical view of the architecture. Other views of the architecture

have been only briefly discussed.

Our alignment to standards-based architecture has led to the reuse of some quite well-known

concepts and building blocks in the IoT Security community. Nevertheless, some novel concepts

have been also introduced, such as a mechanism for data-driven extraction of security events

and behaviours, based on powerful analytics algorithms. This mechanism has been introduced

based on the notion of templates, which specify the behaviours that the system is destined to

capture. By supporting an arbitrary number of different templates (including their automated

extraction), the SecureIoT systems could be become flexibly and intelligently configurable to

address many different threats, vulnerabilities and attacks. Most important, templates can be

“contextualized” i.e. tailored to operate in different environments and based on different

parameters. Overall, this mechanism has reinforced the data-driven nature of the project, while

transferring a great part of the system’s security intelligent in the deployment and use of

advanced data analytics algorithms.

The architecture has also introduced other important modules that contribute to the system

intelligence. As a prominent example, the introduction of a Security Knowledge Base will allow

the system to benefit from accumulated knowledge about threats and attacks, as a means of

correlating identified behaviours with known information about security incidents that have

occurred in the past. Likewise, the specification of automation modules provides the means for

increasing the efficiency of the system, through reducing or eliminated human intervention

whenever possible.

As a first step to validating our architecture, we have presented logical architectures of the use

cases, which make use of the SecureIoT platform based on the introduced architecture. Detailed

technical architectures for each use case will be however produced as part of the use cases design

and implementation in WP6 of the project. Moreover, the detailed specification and

implementation of the security modules of the SecureIoT architecture is on-going in the scope of

Page |83




other technical workpackages of the project (i.e. WP3, WP4 and WP5). The process of designing

and implementing these modules is expected to provide invaluable feedback for extending,

refining and fine-tuning the presented architecture. We will be including these enhancements

and refinements in the second version of the architecture as part of deliverable D2.5, which can

be seen as a direct extension of the present deliverable towards the final version of the SecureIoT

architecture.

Page |84




References [Alonso18] A. Alonso, “Adding Identity Management, Access Control and API Management in

your system”, FIWARE Global Summit, 2018, https://es.slideshare.net/FI-WARE/fiware-global-

summit-adding-identity-management-access-control-and-api-management-in-your-system-

97031100

[API-Gateway] Pattern: API Gateway / Backend for Front-End,

https://microservices.io/patterns/apigateway.html

[Calvo18] D. Calvo, “Connecting FIWARE to the IoT”, FIWARE Global Summit, 2018,

https://es.slideshare.net/FI-WARE/fiware-global-summit-connecting-to-iot-97030154

[Carrez13] IoT-A. D1.5 – Final architectural reference model for the IoT v3.0. Francois Carrez.

2013.

[DIN EN 62264-1] DIN EN 62264-1:2014-07 Enterprise-control system integration - Part 1: Models

and terminology (IEC 62264-1:2013); German version EN 62264-1:2013

[DIN EN 61512-1:2000-01] Chargenorientierte Fahrweise - Teil 1: Modelle und Terminologie (IEC

61512-1:1997); Deutsche Fassung EN 61512-1:1999

[ETSI GS CIM 004] ETSI GS CIM 004, “Context Information Management (CIM) API”, Group

specification, 2018,

https://www.etsi.org/deliver/etsi_gs/CIM/001_099/004/01.01.01_60/gs_CIM004v010101p.pdf

[FIWAREDev] FIWARE developers page, https://www.fiware.org/developers/

[FIWARECatalogue] https://www.fiware.org/developers/catalogue/

[Hierro18] J. Hierro, “FIWARE implementation of IDS concepts”, FIWARE Global Summit, 2018,

https://es.slideshare.net/FI-WARE/fiware-global-summit-fiware-implementation-of-ids-

reference-architecture-concepts-97265148

[IDS-RA] IDS Reference Architecture Model, Industrial Data Space, Version 2.0,

https://www.internationaldataspaces.org/en/publications/ids-ram2-0/

[IEC62890] IEC 62890: IEC Project: Life Cycle Management for Systems and Products used in

Industrial-Process Measurement, Control, and Automation; refer to: https://webstore.iec.ch/.

[ISO/IEC CD 30141-1] ISO/IEC CD 30141 Internet of Thins Reference Architecture (IoT RA),

https://www.iso.org/standard/65695.html

[ISO/IEC CD 30141-2] ISO/IEC CD 30141 Internet of Thins Reference Architecture (IoT RA),

https://www.w3.org/WoT/IG/wiki/images/9/9a/10N0536_CD_text_of_ISO_IEC_30141.pdf

[ISO 7498-1] ISO 7498-1 – Open Systems Interconnection,

http://standards.iso.org/ittf/PubliclyAvailableStandards/s020269_ISO_IEC_7498-1_1994(E).zip

https://es.slideshare.net/FI-WARE/fiware-global-summit-adding-identity-management-access-control-and-api-management-in-your-system-97031100



https://microservices.io/patterns/apigateway.html

https://www.fiware.org/developers/

https://es.slideshare.net/FI-WARE/fiware-global-summit-fiware-implementation-of-ids-reference-architecture-concepts-97265148

https://es.slideshare.net/FI-WARE/fiware-global-summit-fiware-implementation-of-ids-reference-architecture-concepts-97265148

https://www.internationaldataspaces.org/en/publications/ids-ram2-0/

https://www.w3.org/WoT/IG/wiki/images/9/9a/10N0536_CD_text_of_ISO_IEC_30141.pdf

http://standards.iso.org/ittf/PubliclyAvailableStandards/s020269_ISO_IEC_7498-1_1994(E).zip

Page |85




[Kruchten95] Kruchten, “Architectural blueprints - The “4+ 1” view model of software

architecture,” IEEE Software, 1995.

[Ma17] Z. Ma, A. Hudic, A. Shaaban and S. Plosz, "Security Viewpoint in a Reference Architecture

Model for Cyber-Physical Production Systems," 2017 IEEE European Symposium on Security and

Privacy Workshops (EuroS&PW), Paris, 2017, pp. 153-159. doi: 10.1109/EuroSPW.2017.65

[RFC6749] RFC 6749 “The OAuth 2.0 Authorization Framework”,

https://tools.ietf.org/html/rfc6749

[Schweichhart16] Karsten Schweichhart: Reference Architectural Model Industrie 4.0 - An

Introduction, April 2016, Deutsche Telekom, online resource:

https://ec.europa.eu/futurium/en/system/files/ged/a2-schweichhart-

reference_architectural_model_industrie_4.0_rami_4.0.pdf

[SecureIoTD3.3] SecureIoT D3.3 – Intelligent data collection mechanisms and APIs, J. Soldatos

and all, 2018.

[SecureIoTD6.1] SecureIoT D6.1 – Detailed specification of usage scenarios and planning of

validation activities First version – S. Kyriazakos and all, 2018.

https://tools.ietf.org/html/rfc6749

deliverable d2.4 architecture and technical specifications · 2019. 9. 22. · john soldatos,...

Documents