Upload
others
View
1
Download
0
Embed Size (px)
Citation preview
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
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
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
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
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
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
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
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
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
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
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.2.1 Data collection specifications ................................................................................... 62
4.2.2 Data Analytics Specifications .................................................................................... 62
4.2.3 Security Policy Enforcement Points Specification .................................................... 62
4.2.4 Cross Layer Data Exchange Specifications ................................................................ 63
4.2.5 Cross Platform Data Exchange Specifications ........................................................... 63
4.3 Compliance Auditing ..................................................................................................... 64
4.3.1 Data collection specifications ................................................................................... 64
4.3.2 Data Analytics Specifications .................................................................................... 64
4.3.3 Security Policy Enforcement Points Specification .................................................... 64
4.3.4 Cross Layer Data Exchange Specifications ................................................................ 64
4.3.5 Cross Platform Data Exchange Specifications ........................................................... 64
4.4 IoT Security Knowledge Base ........................................................................................ 65
4.4.1 Data collection specifications ................................................................................... 65
Page |8
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
4.4.2 Data collection specifications ................................................................................... 66
4.4.3 Data Analytics Specifications .................................................................................... 67
4.4.4 Security Policy Enforcement Points Specification .................................................... 67
4.4.5 Cross Layer Data Exchange Specifications ................................................................ 67
4.4.6 Cross Platform Data Exchange Specifications ........................................................... 67
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
• 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
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
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
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
• 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
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
• 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
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
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
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
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
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
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
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
• 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
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
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
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
2.1.4.3 Relevance to SecureIoT
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
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
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
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
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.
2.1.5.3 Relevance to SecureIoT
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
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
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]
2.1.6.2 Security Considerations
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
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
• 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.
2.1.6.3 Relevance to SecureIoT
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
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
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
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
2.1.7.2 Security Considerations
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
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
2.1.7.3 Relevance to SecureIoT
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
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
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
Page |35
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
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
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
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
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
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
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
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
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
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:
Page |40
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
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.
2.3.2.4 Relevance to 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
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
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
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
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
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
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
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
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
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
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
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
• 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
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
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
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
• 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
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
• 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
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
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
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
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
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
• 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
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
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
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
• 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
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
• 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
• 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
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
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
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
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
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
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/).
Page |72
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Page |85
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
[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.