55
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 Deliverable Number D3.6 Deliverable Name Trustworthiness Metrics and Utility Calculation Dissemination level Public Type of Document Report Contractual date of delivery 30/09/2018 Deliverable Leader FUJITSU Status & version DRAFT WP / Task responsible WP3 (AIT) / Task 3.4 (FUJITSU) Keywords: Trust, Trustworthiness, System Characteristic, Protection Objectives, Protection Levels, Metrics Abstract (few lines): Trustworthiness in the Internet of Things is defined and a model based on concepts of the Industrial Internet Consortium, Plattform Industrie 4.0 and RRI is developed. Most relevant regulations and standards driving Trustworthiness attributes are identified. An example considering the Multivendor Industry use case scenario illustrates the model. Furthermore, an approach for evaluation trustworthiness is described and mapped to the SecureIoT Reference Architecture. Next steps in the project are outlined. Deliverable Leader: Jürgen Neises, Thomas Walloschke (FUJITSU)

DELIVERABLE - SecureIoT Project D3.6... · DELIVERABLE Deliverable Number D3.6 Deliverable Name Trustworthiness ... date of delivery 30/09/2018 Deliverable Leader FUJITSU Status &

  • Upload
    others

  • View
    57

  • Download
    0

Embed Size (px)

Citation preview

Page 1: DELIVERABLE - SecureIoT Project D3.6... · DELIVERABLE Deliverable Number D3.6 Deliverable Name Trustworthiness ... date of delivery 30/09/2018 Deliverable Leader FUJITSU Status &

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

Deliverable Number D3.6 Deliverable Name Trustworthiness Metrics and Utility

Calculation Dissemination level Public

Type of Document Report

Contractual date of delivery 30/09/2018

Deliverable Leader FUJITSU

Status & version DRAFT

WP / Task responsible WP3 (AIT) / Task 3.4 (FUJITSU)

Keywords: Trust, Trustworthiness, System Characteristic, Protection Objectives,

Protection Levels, Metrics

Abstract (few lines): Trustworthiness in the Internet of Things is defined and a model

based on concepts of the Industrial Internet Consortium, Plattform

Industrie 4.0 and RRI is developed. Most relevant regulations and

standards driving Trustworthiness attributes are identified. An

example considering the Multivendor Industry use case scenario

illustrates the model.

Furthermore, an approach for evaluation trustworthiness is described

and mapped to the SecureIoT Reference Architecture. Next steps in

the project are outlined.

Deliverable Leader: Jürgen Neises, Thomas Walloschke (FUJITSU)

Page 2: DELIVERABLE - SecureIoT Project D3.6... · DELIVERABLE Deliverable Number D3.6 Deliverable Name Trustworthiness ... date of delivery 30/09/2018 Deliverable Leader FUJITSU Status &

Page | 2

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

D3.6 - Trustworthiness Metrics and Util ity Calculation,

Version: 1.00 – Final Document, Date 28/09/2018

Contributors: George Moldowan (SIEMENS), Sofianna Menesidou (UBITECH),

Daniel Groß (DWF), Arjen Lapidaire, Peter Russ (P@SSPORT)

Reviewers: Arjen Lapidaire (P@SSPORT), Thorsten Jansen (DWF)

Approved by: George Koutalieris (INTRA)

Page 3: DELIVERABLE - SecureIoT Project D3.6... · DELIVERABLE Deliverable Number D3.6 Deliverable Name Trustworthiness ... date of delivery 30/09/2018 Deliverable Leader FUJITSU Status &

Page | 3

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

D3.6 - Trustworthiness Metrics and Util ity Calculation,

Version: 1.00 – Final Document, Date 28/09/2018

Executive Summary Considering the idea of interacting things, smart objects, services and platforms in the Internet

of Things (IoT) trust is fundamental. Trustworthiness of products, solutions, and communication

is a key issue for industries and their customers. Otherwise, any communication may threaten

security of all the participants. The traditional roles must be empowered and equipped to

integrate with information technology and the cybersecurity controls to make sure the

challenges of complexity, change and cyber threats are mitigated.

In this deliverable Trustworthiness in the Internet of Things is defined and a model based on

concepts of the Industrial Internet Consortium, Plattform Industrie 4.0 and Robot Revolution

Initiative is developed.

This model is based on IoT systems characteristics and according attributes related to protection

objectives. Most relevant regulations and standards driving Trustworthiness attributes are

identified. An example considering the Multivendor Industry use case scenario illustrates the

model.

Initial discussions with partners in initiatives like the Plattform Industrie 4.0 on this approach

testify to the global value of the model presented.

Furthermore, possible approaches towards evaluation of trustworthiness based on the

stakeholders’ requirements of D2.2 are described. The architecture of a prototype evaluator is

mapped to the SecureIoT Reference Architecture.

Next steps in the project’s task T3.4 are outlined.

Page 4: DELIVERABLE - SecureIoT Project D3.6... · DELIVERABLE Deliverable Number D3.6 Deliverable Name Trustworthiness ... date of delivery 30/09/2018 Deliverable Leader FUJITSU Status &

Page | 4

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

D3.6 - Trustworthiness Metrics and Util ity Calculation,

Version: 1.00 – Final Document, Date 28/09/2018

Document History

Version Date Contributor(s) Description

0.01 01/06/2018 Jürgen Neises Table of Content

0.02 17/07/2018 George Moldovan

Jürgen Neises 1st round input

0.03 03/08/2018 George Moldovan Input on Chapter 3

0.04 10/08/2017 Jürgen Neises Merge and Drafting

0.05 04/09/2018

Arjen Lapidare,

Sofianna Menesidou,

George Moldovan,

Jürgen Neises

2nd round Input and merge of contributions

0.06 13/09/2018 Jürgen Neises Hierarchical Trustworthiness model,

Design and Implementation concept

0.07 16/09/2018 Jürgen Neises,

Thomas Walloschke

Context of Trust, Examples, Implementation

considerations

0.08 17/09/2018 Jürgen Neises,

Thomas Walloschke

Updates on Trust evaluation

Upcoming EU Regulations,

Scenario Multivendor Industry Use Case,

Mapping to SecureIoT components

0.09 23/09/2018 Jürgen Neises Adding abstract, executive summary,

conclusions

0.10 24/09/2018 Thomas Walloschke,

Jürgen Neises

Adding sections 1.3 and 2.5

Document cleansing for Peer Review

0.11 27/09/2018 Thomas Walloschke Update section 2.1, 2.5

1.00 28/09/2018 Jürgen Neises Finalization of Document

Page 5: DELIVERABLE - SecureIoT Project D3.6... · DELIVERABLE Deliverable Number D3.6 Deliverable Name Trustworthiness ... date of delivery 30/09/2018 Deliverable Leader FUJITSU Status &

Page | 5

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

D3.6 - Trustworthiness Metrics and Util ity Calculation,

Version: 1.00 – Final Document, Date 28/09/2018

Table of Contents Executive Summary ......................................................................................................................... 3

Definitions, Acronyms and Abbreviations ...................................................................................... 7

1 Introduction ............................................................................................................................. 9

1.1 Trustworthiness in IoT .................................................................................................... 9

1.2 Business Drivers of Trustworthiness in IoT ................................................................... 11

1.3 Regulatory Drivers of Trustworthiness in IoT ............................................................... 13

1.4 Document Structure ..................................................................................................... 15

2 Trustworthiness Model ......................................................................................................... 16

2.1 IIoT Trustworthiness ..................................................................................................... 16

2.2 Trustworthiness Characteristics, Attributes, Properties .............................................. 20

2.3 Relevant Regulations .................................................................................................... 28

2.4 Relevant Standards ....................................................................................................... 29

2.5 Scenario Multivendor Industry Use Case ...................................................................... 31

3 Trustworthiness Measurements and Assurance in an IoT Solution ...................................... 34

3.1 Objectives and Requirements ....................................................................................... 34

3.1.1 Design Objectives ...................................................................................................... 34

3.1.2 Stakeholders’ Requirements ..................................................................................... 35

3.1.3 Functional Requirements .......................................................................................... 36

3.1.4 Non-functional Requirements .................................................................................. 37

3.2 Trustworthiness Evaluation Components ..................................................................... 39

3.3 Evaluation Approaches ................................................................................................. 42

3.3.1 Overview ................................................................................................................... 42

3.3.2 Stochastic Models ..................................................................................................... 42

3.3.3 Technical Evaluation Approach ................................................................................. 43

3.3.4 Mapping to SecureIoT Architecture .......................................................................... 45

4 Next Steps in the Project ....................................................................................................... 50

5 Conclusion ............................................................................................................................. 51

6 References ............................................................................................................................. 52

7 Appendix ................................................................................................................................ 55

Page 6: DELIVERABLE - SecureIoT Project D3.6... · DELIVERABLE Deliverable Number D3.6 Deliverable Name Trustworthiness ... date of delivery 30/09/2018 Deliverable Leader FUJITSU Status &

Page | 6

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

D3.6 - Trustworthiness Metrics and Util ity Calculation,

Version: 1.00 – Final Document, Date 28/09/2018

Table of Figures FIGURE 1.1.1. TRUSTWORTHINESS ENVIRONMENT IN IIOT. ............................................................................................. 12 FIGURE 2.1.1. PLC WITH SENSOR AND ACTUATOR .......................................................................................................... 19 FIGURE 2.1.2. ISOLATION OF COMPONENTS IN NETWORK ZONES ...................................................................................... 19 FIGURE 2.1.3. TRUST BETWEEN COMPONENTS .............................................................................................................. 20 FIGURE 2.2.1. IOT TRUSTWORTHINESS RADAR .............................................................................................................. 23 FIGURE 2.2.2. SCHEMATIC OVERVIEW – SYSTEM CHARACTERISTICS AND PROTECTION OBJECTIVES .......................................... 26 FIGURE 3.1.1. TRUST COMPUTATION PROCESS ............................................................................................................... 38 FIGURE 3.2.1. TRUST AND REPUTATION COMPONENTS .................................................................................................... 41 FIGURE 3.3.1. FUZZY TRUST MATRIX PRESENTED IN [MANCHALA] ...................................................................................... 43 FIGURE 3.3.2. HIGH LEVEL LOGICAL VIEW OF THE SECUREIOT ARCHITECTURE AND MAPPING TO TECHNICAL WORKPACKAGES ..... 46 FIGURE 3.3.3. SECUREIOT RA (REFERENCE ARCHITECTURE) - COMPONENTS ....................................................................... 48

Page 7: DELIVERABLE - SecureIoT Project D3.6... · DELIVERABLE Deliverable Number D3.6 Deliverable Name Trustworthiness ... date of delivery 30/09/2018 Deliverable Leader FUJITSU Status &

Page | 7

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

D3.6 - Trustworthiness Metrics and Util ity Calculation,

Version: 1.00 – Final Document, Date 28/09/2018

Definitions, Acronyms and Abbreviations Acronym Title

CMDB Configuration Management Database

CO Confidential, only for members of the consortium (including Commission Services)

CR Change Request

D Demonstrator

DCS Distributed Control System

DL Deliverable Leader

DM Dissemination Manager

DMS Document Management System

DoA Description of Action

Dx Deliverable (where x defines the deliverable identification number e.g. D1.1.1)

ECA Event Condition Action

eIDAS electronic IDentification, Authentication and trust Services

EIM Exploitation Innovation Manager

ENISA European Network and Information Security Agency

EU European Union

FM Financial Manager

GDPR General Data Protection Regulation

HIPAA U.S. Health Insurance Portability and Accountability Act

ICS Industrial Control System

IEC International Electrotechnical Commission

IIC Industrial Internet Consortium

IIoT Industrial Internet of Things

IISF Industrial Internet Security Framework

IoT Internet of Things

IoT-A IoT Architecture Reference Model

ISA International Society of Automation

ISO International Organization for Standardization

IT Information Technology

KPI Key Performance Indicator

MSx project Milestone (where x defines a project milestone e.g. MS3)

MVI Multivendor Industry

Mx Month (where x defines a project month e.g. M10)

NIS Network Information Security

NIST National Institute of Standards and Technology

O Other

OT Operation Technology

P P

PC Project Coordinator

PDP Policy Decision Point

Page 8: DELIVERABLE - SecureIoT Project D3.6... · DELIVERABLE Deliverable Number D3.6 Deliverable Name Trustworthiness ... date of delivery 30/09/2018 Deliverable Leader FUJITSU Status &

Page | 8

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

D3.6 - Trustworthiness Metrics and Util ity Calculation,

Version: 1.00 – Final Document, Date 28/09/2018

PEP Policy Enforcement Point

PIP Policy Information Point

PLC Programmable Logic Controller

PM partner Project Manager

PO Protection Objective

PP Restricted to other programme participants (including the Commission Services)

PU Public

QA Quality Assurance

QAP Quality Assurance Plan

QFD Quality Function Deployment

QM Quality Manager

R Report

RAMI 4.0 Reference Architecture Model Industrie 4.0

RE Restricted to a group specified by the consortium (including Commission Services)

RRI Robot Revolution Initiative

SC System Characteristics

SCADA Supervisory Control and Data Acquisition

STM Scientific and Technical Manager

TCP/IP Transmission Control Protocol/Internet Protocol

TL Task Leader

UDP User Datagram Protocol

WP Work Package

WPL Work Package Leader

WPS Work Package Structure

Page 9: DELIVERABLE - SecureIoT Project D3.6... · DELIVERABLE Deliverable Number D3.6 Deliverable Name Trustworthiness ... date of delivery 30/09/2018 Deliverable Leader FUJITSU Status &

Page | 9

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

D3.6 - Trustworthiness Metrics and Util ity Calculation,

Version: 1.00 – Final Document, Date 28/09/2018

1 Introduction Acknowledgement: A substantial part of the deliverable has been developed in discussions with

the Industrial Internet Consortium (IIC) and the German Plattform Industrie 4.0. Major outcomes

of the discussions with the IIC will be published in a White Paper on Trustworthiness in Industrial

IoT [IIC 3]. Moreover, we refer to several publications of the IIC and the German Plattform

Industrie 4.0 especially considering Integrity as an important component of Trust in Value Chains

[I40 1].

1.1 Trustworthiness in IoT Considering the idea of interacting things, smart objects, services and platforms in the Internet

of Things (IoT) trust is fundamental. Trustworthiness of products, solutions, and communication

is a key issue for industries and their customers. Otherwise, any communication may threaten

security of all the participants. The traditional roles must be empowered and equipped to

integrate with information technology and the cybersecurity controls to make sure the

challenges of complexity, change and cyber threats are mitigated.

In practice, the terms trust and reputation, although intuitively recognized and understood, have

a broad range of definition in the information security field. A detailed overview of the various

definitions and nuances present in the reference literature is provided in [JOSANG].

Therefore, we choose to rely on a specific set of definitions, namely as defined on the notions of

trust and reputation as defined by McKnight and Chervany [KNIGHT], and by the Concise Oxford

Dictionary, respectively:

o Trust: Trust is the extent to which one party is willing to depend on something or somebody

in a given situation with a feeling of relative security, even though negative consequences are

possible. Main properties of trust are:

o 1. Trust is asymmetric. This means, that if entity A trust entity B, it does not imply that

B also trusts A.

o 2. Trust is subjective. That is, the observer might be very demanding with the expected

results/interactions, and might mark the other entities with a bias towards negative

scoring.

o 3. Trust is very context sensitive. That is, A might trust B in a certain context/scenario,

but it could mistrust B in others. E.g. a high trust that “B” forwards messages, but a

low trust in B’s own sensor readings.

Similarly, the model for the evaluation might change.

o Reputation: Reputation is what is generally said or believed - by relevant, trustworthy parties

(commented by authors) - about a person’s or thing’s character or standing. Comment by the

authors: It also depends on the degree of maturity that these reputation statements possess.

Page 10: DELIVERABLE - SecureIoT Project D3.6... · DELIVERABLE Deliverable Number D3.6 Deliverable Name Trustworthiness ... date of delivery 30/09/2018 Deliverable Leader FUJITSU Status &

Page |

10

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

D3.6 - Trustworthiness Metrics and Util ity Calculation,

Version: 1.00 – Final Document, Date 28/09/2018

Having that in mind, Trust is a continuum depending on context like policies and specific actions.

Trustworthiness then is based on a reasoning process assessing and evaluating risk and

consequences [NAZILA]. Trustworthiness may be defined as degree of Trust in a party related to

a specific environment of transactions after such a process.

To determine whether a system meets the stakeholders’ expectations for Trustworthiness, the

specific contexts deemed relevant must explicitly be stated along with the claimed trustworthy

behaviour that the stakeholders expect.

For instance, trust in socially assistive robots will rely on other criteria than trust in autonomous

vehicles or a machine in an industry 4.0 environment. Thus it is a relative attribute regarding the

intended applications and their use. Trustworthiness and trust should not be considered as a

single construct with a single effect; rather it is strongly context dependent [NAZILA].

Within this context the IIC describes [IIC 3] Trustworthiness in Industrial IoT (IIoT) means that

a satisfactory level of confidence can be established and the partner system (be that a

sensor, a machine or a factory) is what it claims to be, fulfils its tasks and not endangers

the business partners by introducing malicious components into the network.

Moreover, the Plattform Industrie 4.0 [I40 1] introduces Trustworthiness as a quality KPI:

The term ‘trustworthiness’ is used to describe the quality of existing and future

relationships between companies, people, systems, and components. A trustworthy

system ensures that all of its components behave in an expected manner.

Trustworthiness is a “Challenge for Secure Supply Chain of Connected Industries” as published

by Plattform Industrie 4.0 and Robotic Revolution & Industrial IoT Initiative (RRI) [I40 RRI]:

… Security is challenging, especially in cross-company and cross-border communication scenarios. Secure (company-wide/ cross-company) operations require trust between all parties involved…Trustworthiness is an important qualitative decision-making criterion for the entire secure value chain. Each manufacturer wants to give his customer clear, comprehensive and reliable information about the properties of the system, product and data delivered.

For identification of each partner’s trustworthiness at deliberate time, reliable information,

evaluation and assurances are fundamental within the dynamic nature of the industrial IoT. The

metrics model shall support the development of tools for utility calculation. Defining appropriate

trustworthiness metrics should reduce the complexity and effort in measuring and evaluating

trustworthiness. This way it shall facilitate trustworthy M2M interactions across IoT components

Page 11: DELIVERABLE - SecureIoT Project D3.6... · DELIVERABLE Deliverable Number D3.6 Deliverable Name Trustworthiness ... date of delivery 30/09/2018 Deliverable Leader FUJITSU Status &

Page |

11

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

D3.6 - Trustworthiness Metrics and Util ity Calculation,

Version: 1.00 – Final Document, Date 28/09/2018

(e.g., platforms, networks of smart objects), regardless of the diversity of their trust levels and

security policies. Common standards-based representations of policies and metrics are

instrumental for interoperability across different security and administrative domains.

Standardized rules and agreed procedures lay the foundation and promote methods for assessing

the trustworthiness of partners. A trustworthiness metric is an essential facilitation for

automating evaluation. Multiple state-of-the-art references explain how to evaluate and enforce

trust metrics in fields beyond IIoT (e.g. eIDAS regulation, NIST Special Publication NIST SP 800-

160 Volume 1). IEC 61508 -design, construction and operation of electrical and programmable

electronic systems

1.2 Business Drivers of Trustworthiness in IoT Business value depends on good decisions based on good information derived from validated

and sufficient data that has good quality in accordance with a high availability Thus, the whole

value chain depends on the confidence in the data, the information, and decisions. This includes

confidence that the consequences of decisions and processes are acceptable, and that business

information is handled properly [IIC 3].

This confidence is fundamentally based on the trustworthiness of the overall system. An

Industrial Internet of Things (IIoT) system can be seen as a value chain related to the use of data.

Trustworthiness is all about preserving this IIoT value chain under adverse conditions, by either

preventing a breach of confidence from occurring or by mitigating the effect of confidence abuse.

[IIC 3]

This includes an understanding and confidence in the mentioned system properties of safety,

security, privacy, reliability, and resilience as well as confidence that the appropriate trade-offs

have been made among them, based on an understanding of the system, possible interactions of

these aspects and an understanding of consequences. This shall be taken into account in the

project’s use cases.

Quantitative and qualitative metrics will help assess and manage the business impact of

trustworthiness in the entire value chain. Each partner in the value chain relies on comprehensive

and dependable information about properties of the system, product or data delivered by its

supplier. Figure 1.1.1 illustrates the Trustworthiness environment in global manufacturing value

chains.

Page 12: DELIVERABLE - SecureIoT Project D3.6... · DELIVERABLE Deliverable Number D3.6 Deliverable Name Trustworthiness ... date of delivery 30/09/2018 Deliverable Leader FUJITSU Status &

Page |

12

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

D3.6 - Trustworthiness Metrics and Util ity Calculation,

Version: 1.00 – Final Document, Date 28/09/2018

Figure 1.1.1. Trustworthiness Environment in IIoT [I40 RRI]

Considering the dependency of the whole value chain on Trustworthiness of the overall system,

trade-offs must be carefully weighed so as not to jeopardise the trustworthiness in the overall

business process and the operational process where real time delays can lead to exceed of

business losses or even life and limb.

Moreover, an IoT system may be deployed across multiple jurisdictions where the regulatory and

legal compliance requirements may be different. This needs to be supplemented by

considerations of vertical specific requirements and rules sets. The IoT system must thus have

some kind of awareness on compliance according to multiple regions and verticals.

This way within the IoT Trustworthiness must be addressed and tracked continuously throughout

the lifecycle of the system and the lifecycle of the data about the system on a risk-based approach

[I40 RRI]. The increasing complexity and integration of such systems, the risks and potentially

more severe consequences of insufficient or tampering with IoT

Trustworthiness drive the business need for a more consistent and rigorous approach towards

obtaining and maintaining IoT Trustworthiness. Hence, open, clear and transparent indicators

Page 13: DELIVERABLE - SecureIoT Project D3.6... · DELIVERABLE Deliverable Number D3.6 Deliverable Name Trustworthiness ... date of delivery 30/09/2018 Deliverable Leader FUJITSU Status &

Page |

13

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

D3.6 - Trustworthiness Metrics and Util ity Calculation,

Version: 1.00 – Final Document, Date 28/09/2018

and profiles for trustworthiness on company-, system-, and product-level are proposed by

Plattform Industrie 4.0 and Robot Revolution Initiative in [I40 RRI]. Moreover, both partners see

the necessity of further research on

o Methods for assessing the trustworthiness of supply chain key elements, and

development and standardization of common, accepted policies for a global secure

supply chain,

o Identification of trustworthiness assurance and levels for the targets, which may be

requested automatically from each participant of the supply chain;

o International standardization

1.3 Regulatory Drivers of Trustworthiness in IoT In order to build trust in digital technologies, the EU created the draft Cybersecurity Act, which

will be put to the vote in Parliament in September 2018.

It deals with (1) "Secure "intelligent" devices and networked (Internet of Things) devices for EU

consumers, (2) a stronger European Agency for Cyber Security and (3) minimising risks and

threats to information security and network systems.

To increase cyber resilience, a new certification framework for connected devices and a stronger

role for the EU Cyber Security Agency are expected.

A new EU cyber security system certifies that an ICT product, process or service has no known

vulnerabilities at the time of certification release and that it complies with international

standards and technical specifications.

At present, the framework for cyber security certification relies on voluntary certification, but

may also become mandatory if necessary and should demonstrate the following:

o confidentiality, integrity, availability and data protection of services, functions and data,

o that services, functions and data may only be accessed and used by authorized persons

and/or authorized systems and programs,

o that processes are in place to identify all known vulnerabilities and fix new ones,

o that products, processes or services are designed to be secure and equipped with up-to-

date software without known vulnerabilities,

o and that other risks associated with cyber incidents, such as life and health risks, are

minimized.

The Level of Assurance as a new paradigm will determine the certification system three risk-

based security levels:

Page 14: DELIVERABLE - SecureIoT Project D3.6... · DELIVERABLE Deliverable Number D3.6 Deliverable Name Trustworthiness ... date of delivery 30/09/2018 Deliverable Leader FUJITSU Status &

Page |

14

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

D3.6 - Trustworthiness Metrics and Util ity Calculation,

Version: 1.00 – Final Document, Date 28/09/2018

o basic, i.e. the device is protected against the known basic risks of cyber accidents,

o significant, i.e. known risks of cyber events are avoided and it is also possible to withstand

cyber-attacks with limited resources, and

o high, i.e. risks of cyber events are avoided and the device is able to withstand the most

modern cyber-attacks with considerable resources.

The stronger hand: The draft new rules will give more resources and a permanent mandate to

the existing European Network and Information Security Agency (ENISA) and will also become

the reference point for the cyber security certification system:

o Avoid fragmentation of certification systems in the European Union,

o Design EU certification schemes for certain products at the request of the European

Commission,

o Maintain all relevant information on certification schemes, including information on

withdrawn and expired certificates.

In addition, new rules exist for the protection of personal data within and outside the EU, known

as GDPR. In the meantime, this regulation has received a great deal of attention due to its

possible high penalty. In addition, newer requirements from the constantly updated Machinery

Directive apply and in our case also apply to robotics.

Surprisingly, the European data protection regulation, the ePrivacy Regulation, which is currently

being revised, has not received as much public attention. Wrongly so, as can be seen below,

because this regulation strengthens further rights of use and naturally affects trustworthiness.

These can be summarised in the following six points:

o Encryption should not only be guaranteed by the user. Providers are obliged to secure the

data in accordance with the state of the art and to protect it from unauthorised access.

In addition, providers should not be obliged to undermine the protection of users. This is

intended to prohibit the trade in backdoors.

o Spatial tracking by programmes that are not actively used should become illegal. In this

way it is prevented that unknowingly motion profiles can be created.

o Unclear data protection declarations should be a thing of the past. A detailed

transparency and documentation obligation will be introduced for the public prosecutor's

office, so that providers can be obliged to disclose official investigations.

o Processing is no longer possible without the user's consent. What has long been valid for

telephone providers will be extended to online communication providers. Processing is

not possible without consent to storage.

Page 15: DELIVERABLE - SecureIoT Project D3.6... · DELIVERABLE Deliverable Number D3.6 Deliverable Name Trustworthiness ... date of delivery 30/09/2018 Deliverable Leader FUJITSU Status &

Page |

15

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

D3.6 - Trustworthiness Metrics and Util ity Calculation,

Version: 1.00 – Final Document, Date 28/09/2018

o In addition, effective protection against tracking should be put in place, which should

include a comprehensive setting to disable tracking.

o Finally, all settings in software and devices should be set to the more privacy-friendly

version by default. This concept is referred to by default as Privacy-by-Default.

These are the most important impulses which influence the deliverable "trustworthiness"

through regulatory drivers. Further details can be found in Section 2.3.

In Deliverable D2.6, the legal implications for the overall project are described in much greater

detail.

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

Chapter 2 describes the environment of Trustworthiness in IoT. Based on discussions by the 3

major initiatives in industrial IoT the model for Trustworthiness is developed. Furthermore, the

most relevant regulations and standards regarding the Trustworthiness attributes and protection

objectives are outlined. Finally an example illustrates the model of evaluating Trustworthiness

Chapter 3 introduces objectives and technologies considering the development of a

Trustworthiness evaluation component based in the model of chapter 2. Design objectives and

requirements are presented. Candidate technologies are listed. Finally, the architecture of a

prototype is matched with the SecureIoT Reference Architecture.

Chapter 4 outlines the next steps planned in task T3.4 of the project for the development of a

prototype evaluation component.

Chapter 5 illustrate the Conclusions based on the work of this task

Chapter 6 includes the references of the deliverable

Chapter 7 is a brief appendix including a document explaining the concept of Security Levels

based on IEC 62443

Page 16: DELIVERABLE - SecureIoT Project D3.6... · DELIVERABLE Deliverable Number D3.6 Deliverable Name Trustworthiness ... date of delivery 30/09/2018 Deliverable Leader FUJITSU Status &

Page |

16

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

D3.6 - Trustworthiness Metrics and Util ity Calculation,

Version: 1.00 – Final Document, Date 28/09/2018

2 Trustworthiness Model 2.1 IIoT Trustworthiness It is possible to rely on intuition and experience when dealing with people, but this is not

adequate for machine-to-machine communications. To speed up operations and not require

human interaction, a system, e.g. a machine, must be able to assess the trustworthiness of

connected systems while engaging and proceeding with transactions. This will require

measurements and assurance of trustworthiness, based on metrics for relevant attributes. For

instance, a common and well known way of assurance of trustworthiness is a so called trusted

3rd party assessing the level of trustworthiness of a party A and attesting it to party B. Such an

approach may be a first attempt to establish trustworthiness within a sector. A trusted 3rd party

does not have any commercial interest in the transaction itself and that is accepted by all

transaction parties. Among the examples of trusted 3rd parties there are certification and

registration authorities, clearing and notarization [VALIMÄKI].

Considering the Stakeholder’s requirements assessed in D2.2, the metrics shall be derived from

regulations like GDPR, NIS directive, and ePrivacy regulation and especially standards like ISA 99

/ IEC 62443, ISA 95, ISO27001, etc. enhanced by vertical specific enhancements as there are

Security in RAMI 4.0, ENISA and NIST requirement on security and privacy for vehicles, Safety,

Security and Privacy for robots by ISO, ENISA and others. There may be different profiles for each

vertical, based on different rules, legal definitions and standards and specifically weighted

functional requirements.

However, definition of a set of core standards across verticals is not yet resolved and is a major

objective in T3.4 and contribution of the project beyond the current State of the Art. This

facilitates a holistic approach as according trust levels based on those standards will be defined.

In the context of interacting units in IIoT, e.g. in cross-company and cross-border communication,

trustworthiness is always reflected as an estimate, since trustworthiness cannot be measured

directly or determined absolutely. In addition, a more conceivable trustworthiness level,

however it is determined and used, is "volatile" after application and can only be reused to a

limited extent for future interactions. Trustworthiness levels of any kind must be constantly

checked and re-evaluated. Technically, this is mainly reflected through the assessment of trust

and reputation. To assess trust and reputation in IoT, two other building blocks are usually

required [YAN 1]:

o Trust metrics for the computation of trust values for a given entity according to a set of

selected indicators and rules.

Page 17: DELIVERABLE - SecureIoT Project D3.6... · DELIVERABLE Deliverable Number D3.6 Deliverable Name Trustworthiness ... date of delivery 30/09/2018 Deliverable Leader FUJITSU Status &

Page |

17

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

D3.6 - Trustworthiness Metrics and Util ity Calculation,

Version: 1.00 – Final Document, Date 28/09/2018

o Observers, which acknowledge existing trust metrics and generate trust-ratings.

Five factors which influence the resulting trust metrics, and which include properties of the

trustee, trustor and their context are [YAN 2]:

o Trustee’s objective properties: Competence; ability; security (confidentiality, integrity,

availability); dependability (reliability, maintainability, usability, safety); predictability;

timeliness; (observed) behaviours; strength; privacy preservation.

o Trustee’s subjective properties: Honesty; benevolence; goodness.

o Trustor’s objective properties: Assessment; a given set of standards; trustor’s standards.

o Trustor’s subjective properties: Confidence; (subjective) expectations; subjective

probability; willingness; belief; disposition; attitude; feeling; intention; faith; hope;

trustor’s dependence and reliance.

o Context (incl. purpose): Situations entailing risk; structural risk; domain of action;

environment (time, place, involved persons), purpose of trust.

For example within ICS systems the components will need to be characterized by their intended

functionality and the intended use. This can be from safety systems all the way up to managed

services (cloud). According to IEC 62443 Security Level are defined from 1 (low) up to 4 (high),

see also the attached description in chapter 7 Appendix.

Within the IoT-A Architecture Reference Model [IOT-A] the repeatedly sequential execution of

the following five steps when creating and maintaining trust and reputation models is

recommended [RERUM]:

o Gathering information about the system’s entities: The first step in a reputation system

is responsible for collecting information on the behaviour of nodes, which will be used to

determine how “trustworthy” they are. Using established network identities, a reputation

system protocol collects information about the behaviour of a given node in previous

transactions. This information is collected individually from each node querying them or

is provided proactively by all nodes collating together their experiences. Information

sources may be for instance own personal experience, experience of pre-trusted nodes,

directly or transitively, or a global reputation system.

o Scoring and ranking entities: Once the nodes' history has been collected and properly

weighted, a reputation score is computed for each node, either by an interested agent, a

centralized entity, or by many nodes collectively.

o Entity selection: Once an agent has computed reputation ratings for the nodes it can

transact with, it must decide which, if any, to choose. This is especially true if multiple

Page 18: DELIVERABLE - SecureIoT Project D3.6... · DELIVERABLE Deliverable Number D3.6 Deliverable Name Trustworthiness ... date of delivery 30/09/2018 Deliverable Leader FUJITSU Status &

Page |

18

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

D3.6 - Trustworthiness Metrics and Util ity Calculation,

Version: 1.00 – Final Document, Date 28/09/2018

peers offer the same service, but also if the services are ranked closely, based on whether

the peer’s reputation rating is above or below a set selection threshold.

o Transaction: When a service has been chosen, out of the possible candidates, the trustor

performs the transaction with the chosen trustee.

o Rewarding and punishing entities: Reputation systems can be used to motivate peers to

positively contribute to the network and/or punish adversaries who try to disrupt the

system.

As suggested in [YAN 1], holistic trust management systems should consider a broad range of

trust-sources, such as data trust perception, identity trust, privacy preservation, data

transmission and communication trust, system security and robustness trust, privacy-preserving

data fusion and mining trust, trust of users and the trust of the consuming applications.

Trust and reputation modelling and management of cyber information is a key point e.g. in

distributed and health-related systems. The evaluation of the data resulting from processing and

reasoning over the information defines and drives physical decisions and policies. Both

malfunctioning and malicious devices and/or services can alter or report false readings, which

then propagate throughout the entire system, resulting in incorrect decisions being made on

non-authorized or falsified data. In this regard and for such manifestation into the physical

dimension, trust therefore is also closely related to the issues of overall safety and resilience. In

the case in which trust correlates to the reliability of a reporting sensor, measurements provided

by various devices, outlier detection techniques such as those presented in [STELTE] are used.

[HUYNH] proposes taking a number of information sources like trust, role-based trust, witness

reputation and certified reputation into account in order to provide a trust metric.

In the following, the trust relationships between the three industrial components Programmable

Logic Controller (PLC), a sensor and an actuator are explained. Typically, these industrial

components are also entered in a CMDB, as proposed in D2.3, for administrative purposes and

may also be represented in their individual components. Currently, it is not yet common to

display and manage the trust relationship among each other.

In fact, the three components in Figure 2.1.1 could be represented in an industrial network like

this:

Page 19: DELIVERABLE - SecureIoT Project D3.6... · DELIVERABLE Deliverable Number D3.6 Deliverable Name Trustworthiness ... date of delivery 30/09/2018 Deliverable Leader FUJITSU Status &

Page |

19

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

D3.6 - Trustworthiness Metrics and Util ity Calculation,

Version: 1.00 – Final Document, Date 28/09/2018

Figure 2.1.1. PLC with sensor and actuator

Figure 2.1.2 shows the isolation of components in network zones. This serves for grouping and

expresses indirectly and sometimes a historically different level of protection of the

components. Whether a holistic view of the trust level is taken "downwards" or from bottom to

top depends on the specific situation and policy. In any case, both directions have to be

considered separately, with their requirements and their consequences.

Figure 2.1.2. Isolation of Components in Network Zones

For instance the value TPS describes in Figure 2.1.3 the expected trust level of the sensors from

PLC‘s point of view, which, incidentally, is not symmetrical, as the sensor may typically have „no

requirements“ in terms of trust on his master or any other actor (TSP or TSA). At this point, it

should be noted that sensors in the future will very well have these capabilities to make demands

on other components in an Industrie 4.0 Ecosystem Trust.

Page 20: DELIVERABLE - SecureIoT Project D3.6... · DELIVERABLE Deliverable Number D3.6 Deliverable Name Trustworthiness ... date of delivery 30/09/2018 Deliverable Leader FUJITSU Status &

Page |

20

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

D3.6 - Trustworthiness Metrics and Util ity Calculation,

Version: 1.00 – Final Document, Date 28/09/2018

Figure 2.1.3. Trust between Components

In the Figure 2.1.3 above it is now assumed that the communication and identity of all

components require a high level of trust, because a holistic requirement of the "outside world"

reflects this by a corresponding value of Toverall .The PLC may not need to have an own trust

requirement in the opposite direction, as is may not know the „outside world“. The exact

requirements depend on the concrete policy required in each specific case.

2.2 Trustworthiness Characteristics, Attributes, Properties The assessment and evaluation of risks and consequence of interacting with another party

Trustworthiness involves a deep analysis of the underlying system. There are numerous

publications on design and description of technical systems. In this section we will use the

following terms as proposed in [AEDS]:

o A Characteristics describes structure, shape and material of a product and can be

influenced by the designer in a direct manner.

o An Attribute is a measurable feature of the product, e.g. length. In German usually the

term “Merkmal” is used.

o A property is a measured description of the product’s attribute, e.g. 1800 mm for a

product’s length.

o Moreover, [AEDS] defines Eigenschaft as the combination of a property for an attribute,

e.g. (1200mm, Length).

The IIC defines Trustworthiness in IIoT as a continuum based on a set of characteristics as follows:

Page 21: DELIVERABLE - SecureIoT Project D3.6... · DELIVERABLE Deliverable Number D3.6 Deliverable Name Trustworthiness ... date of delivery 30/09/2018 Deliverable Leader FUJITSU Status &

Page |

21

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

D3.6 - Trustworthiness Metrics and Util ity Calculation,

Version: 1.00 – Final Document, Date 28/09/2018

Trustworthiness: degree of confidence one has that the system performs as expected with

characteristics including safety, security, privacy, reliability and resilience in the face of

environmental disruptions, human errors, system faults and attacks.

This means that trustworthiness is based on the individual characteristics as well as the

interactions and trade-offs among them. Moreover, a set of characteristics – security, safety,

reliability, resilience, privacy – has been identified by the IIC [IISF] for defining the trustworthiness

of an IIoT system. The IIC and Plattform Industrie 4.0 jointly define the five characteristics as

follows:

Security: property of being protected from unintended or unauthorized access, change or

destruction ensuring availability, integrity and confidentiality [IIC]

Privacy: right of individuals to control or influence what information related to them may

be collected and stored [i.e. processed] and by whom and to whom that information may be

disclosed [ISO TS 17574:2009]

Besides the always intuitive understanding the private sphere is regulated uniformly, in the

meantime e.g. within the EU (GDPR, ePrivacy, etc.) due to earlier, arbitrary interpretations in the

different legislations.

Resilience: ability of a system or component to maintain an acceptable level of service in the

face of disruption

Resilience is the property of a system that is able to avoid, absorb and manage dynamic

adversarial conditions while completing the assigned missions, and to reconstitute operational

capabilities after disruption. Often resilience is achieved by fail-safe designing the system so that

failures are compartmentalized. Fail-safe technology is a design feature that reacts to certain

failures by design in such a way that minimal or no damage is caused to people, the environment

or equipment. In contrast to the so-called inherent safety of a particular hazard, fail-safety does

not mean how erroneously it can be interpreted that a failure is not possible or likely, but that

the design of the system prevents or mitigates unsafe consequences (!) of the failure. If a single

function fails it should not cause other functions to fail, and there should be alternate ways of

performing the failed function in the design that can be invoked automatically, immediately and

reliably. This means that when a "fail-safe" system "fails", it does so in a "safe way" or no less

safe than in proper operation. Due to the multitude of failure possibilities, error probability and

influence analysis are used to investigate error situations in advance and to implement suitable

safety concepts and procedures. At this point there is an inner relation between “Resilience” and

“Availability”, which is explained in the following characteristic "Reliability".

Page 22: DELIVERABLE - SecureIoT Project D3.6... · DELIVERABLE Deliverable Number D3.6 Deliverable Name Trustworthiness ... date of delivery 30/09/2018 Deliverable Leader FUJITSU Status &

Page |

22

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

D3.6 - Trustworthiness Metrics and Util ity Calculation,

Version: 1.00 – Final Document, Date 28/09/2018

Reliability: ability of a system or component to perform its required functions under stated

conditions for a specified period of time [ISO/IEC 27040:2015]

Reliability and availability are related. Availability reflects the total fraction of time that a system

is available only interrupted by scheduled maintenance, updates, repairs and backup efforts. In

contrast, reliability reflects the fraction of actual availability in relation to scheduled availability.

Reliability reflects how much a company can count on a system working when it's scheduled and

expected to be working. In short, interruptions caused by scheduled maintenance, scheduled

updates, scheduled repairs and scheduled backup efforts reduce availability, but if properly

scheduled, they do not reduce reliability. It is possible for one system to be more reliable but less

available than the other, for example if the more reliable system required replacements of parts

after each run or after frequent upgrades leading to increased system unavailability.

Safety: the condition of the system operating without causing unacceptable risk of

physical injury or damage to the health of people, either directly, or indirectly as a result of

damage to property or to the environment [ISO/IEC Guide 55:1999, modified for consistency]

At this point it should be noted that among experts there are still fierce discussions about the

mutual interactions between Safety and Security in the area of OT and recently IoT. It is currently

not possible to explain the deterministic interaction of both characteristics in a generic model.

For example, Safety in OT is related to IEC 62443 and maybe affected by IT Security requirements

like ISO 27001. Privacy concerns are discussed widely and are subject of the GDPR in the EU.

Resilience is one of the key characteristics needed to resist (not only) cyber-attacks and is subject

to ISO and IEC standards. Finally, Reliability, which is related to NIS regulation and other legal

rules, is a quality feature in both OT and IT.

Page 23: DELIVERABLE - SecureIoT Project D3.6... · DELIVERABLE Deliverable Number D3.6 Deliverable Name Trustworthiness ... date of delivery 30/09/2018 Deliverable Leader FUJITSU Status &

Page |

23

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

D3.6 - Trustworthiness Metrics and Util ity Calculation,

Version: 1.00 – Final Document, Date 28/09/2018

Figure 2.2.1. IoT Trustworthiness Radar [IIC 2]

This concept may be illustrated in figure 2.2.1. The Trustworthiness diagram corresponds to a

sample IoT scenario:

o Current State: Actual state as it exists now

o Minimum State: Non-negotiable minimum level as mandated by legal, regulatory and

other types of requirements

o Target State: Level of Trustworthiness to achieve based on corporate vision, ROI and risk

considerations, etc.

o Maximum State: Highest level theoretically achievable

In this example, the Current State for Safety already meets/exceeds the minimum state level

required. The diagram also shows that the Current states of the other characteristics (or

dimensions) of Trustworthiness (on Security, Reliability, Resilience, Privacy) are below the

required minimum state levels, which means that work is required on them to meet the minimum

state requirements.

The importance of the different characteristics of Trustworthiness will vary according to industry

vertical and individual targets and will depend on regulations, laws and the industry itself.

Page 24: DELIVERABLE - SecureIoT Project D3.6... · DELIVERABLE Deliverable Number D3.6 Deliverable Name Trustworthiness ... date of delivery 30/09/2018 Deliverable Leader FUJITSU Status &

Page |

24

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

D3.6 - Trustworthiness Metrics and Util ity Calculation,

Version: 1.00 – Final Document, Date 28/09/2018

This view on trustworthiness is aligned with the Plattform Industrie 4.0. Within several discussion

papers trustworthiness is defined in a similar way like the IIC does. However, there is an

additional component, which should be addressed. Currently the special relevance of integrity

on its own is under discussion especially within the Plattform Industrie 4.0 [I40 1].

Reliance on correctness of internal/external data and accurate operations of systems/processes

is essential for all business processes within and outside a company. The integrity of the value

chain is necessary, so the end users can have confidence in its preservation. Although integrity is

often viewed as a technical aspect, it has a direct impact on profitability, reputation, and

regulatory responsibilities [ZVEI].

Following examples [I40 1] illustrate the importance of integrity with respect to the

trustworthiness characteristics:

o Security: In information security, integrity is an important protection target. For instance,

incorrect production parameters can lead to faulty products in a very short amount of

time. Integrity is further closely linked to the authentication of users or roles in a

production environment.

Especially within autonomous systems authenticity and integrity play an important role.

The system must authenticate the source of the data and that they have not been

manipulated.

o Privacy: Some indirect references between Privacy and Integrity exist, e.g. it is difficult to

ensure confidentiality of personal data on a compromised system, thus resulting in loss

of privacy. Furthermore, i. e. personal data must remain intact, complete and up to date

during processing.

o Resilience: For instance, erroneous transmission of required data to production control is

detected, and measures for maintaining the correct functioning of a system, such as a

request to re-transmit the required data for production control are triggered, insure

integrity of the system as well.

o Reliability: For instance, compromised integrity of transmitted process data due to

unauthorized modification can have adverse implications on reliability and availability of

the production process.

o Safety: In a production environment, photoelectric barriers are frequently used for safety

tasks. For instance, if a person enters a hazardous area in the vicinity of an industrial

robot, this is often detected by light barriers and the robot is instructed to halt

immediately. Failure to transmit values (light beam interruption/non-interruption) can

mislead safety related emergency-stop mechanisms. Also, most ICS organisations must

meet safety standards that are enforced by governments and industries.

Page 25: DELIVERABLE - SecureIoT Project D3.6... · DELIVERABLE Deliverable Number D3.6 Deliverable Name Trustworthiness ... date of delivery 30/09/2018 Deliverable Leader FUJITSU Status &

Page |

25

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

D3.6 - Trustworthiness Metrics and Util ity Calculation,

Version: 1.00 – Final Document, Date 28/09/2018

Within ICS is this mostly not done due to the fact that the field IO signals that are responsible for

monitoring, measuring or controlling the components of industrial system or processes are or

dependent of IIOT or directly control their output.

The timespan is here milliseconds and there is one way (UDP) instead of the more common

TCP/IP.

In general Trustworthiness is about controlling risks. Minimising risks means protecting

confidentiality, integrity and availability of critical systems. Thus, analogous to Integrity also

Availability and Confidentiality are well known common protection objectives, e.g. in Industrial

Control System, Cars and medical devices.

Considering operational technology, availability is an important protection target. Time

Synchronization is extremely important in highly geographically dispersed systems like SCADA for

example an electrical grid where components can be dispersed 100 `of kilometres away but still

need to be in sync. Hence, most ICS systems must timestamp Input and Output

For instance not being able to synchronize with a timeserver e.g. due to wrong authorization data

can do damage to the process of distribution and typically cost between $30.000 and $50.000

per hour. https://www.wipfli.com/insights/blogs/manufacturing-tomorrow-blog/170628---the-

real-cost-of-unplanned-downtime

Confidentiality, e.g. also is a protection objective in the various characteristics.

o Security: Confidentiality is one of the three most relevant protection objectives in

Security. E.g. credentials and communications must be kept confidential to protect

against attackers and identity theft. Moreover, the system must warrant that nobody can

deny that a particular data was sent or received (i.e., driving with a specific speed or

through a specific route) or that a particular action was done. Nonrepudiation /

Accountability of the systems action is a major objective of Confidentiality.

o Privacy: There is a clear case of confidentiality as a protection target related to privacy in

individualized production as production data often directly linked to persons, e.g. in

tailoring or within connected or autonomous cars (see also D2.2 Stakeholders’

Requirements) .

o Resilience: For instance, if a connection key is broken or outdated a new connection

should be established to keep confidentiality of data during transmission e.g. of

production data without stopping the production process as described above.

o Reliability: Within a PLC e.g. a certified DRM module may protect against abuse of

production data by some malicious software and keep data confidential.

Page 26: DELIVERABLE - SecureIoT Project D3.6... · DELIVERABLE Deliverable Number D3.6 Deliverable Name Trustworthiness ... date of delivery 30/09/2018 Deliverable Leader FUJITSU Status &

Page |

26

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

D3.6 - Trustworthiness Metrics and Util ity Calculation,

Version: 1.00 – Final Document, Date 28/09/2018

o Safety: Process data should be kept confidential not exposing parameter sets keeping a

machine or a process working safely.

Additional Protection Objectives may be defined related to specific application areas and

appropriate protection profiles. These profiles depend on domain, application and intended use.

Consequently sets of protection objectives appropriate for each application area shall be defined

as attributes of the 5 system characteristics. Thus the Trustworthiness metrics shall include a

modular approach facilitating adaptation of the protection objectives for various regions and

verticals.

Figure 2.2.2. Schematic Overview – System Characteristics and Protection Objectives [FUJITSU]

In a simple way the calculation of trustworthiness using this model may be considered as a

weighted combination according to the system characteristics and the attributed Protection

Objectives. This way each characteristics is a weighted combination of properties showing the

level of fulfilment of the attribute Protection Objective. The weight will be assigned according to

relevance of the attributes per system characteristics.

Overall this may be illustrated by the following set of formulas:

𝑇𝑟𝑢𝑠𝑡𝑤𝑜𝑟𝑡ℎ𝑖𝑛𝑒𝑠𝑠(𝐼𝑜𝑇_𝑆𝑦𝑠𝑡𝑒𝑚) =

Page 27: DELIVERABLE - SecureIoT Project D3.6... · DELIVERABLE Deliverable Number D3.6 Deliverable Name Trustworthiness ... date of delivery 30/09/2018 Deliverable Leader FUJITSU Status &

Page |

27

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

D3.6 - Trustworthiness Metrics and Util ity Calculation,

Version: 1.00 – Final Document, Date 28/09/2018

{

0, 𝑜𝑛𝑒 𝑜𝑟 𝑚𝑜𝑟𝑒 𝑇𝑊(𝑖)𝑖𝑠 𝑏𝑒𝑙𝑜𝑤 𝑡ℎ𝑒 𝑎𝑐𝑐𝑜𝑟𝑑𝑖𝑛𝑔 𝑚𝑎𝑛𝑑𝑎𝑡𝑜𝑟𝑦 𝑡ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑

∑ 𝑊𝑆𝐶(𝑖) ∗ 𝑇𝑊(𝑖), 𝑎𝑙𝑙 𝑚𝑎𝑛𝑑𝑎𝑡𝑜𝑟𝑦 𝑡ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑𝑠 𝑎𝑟𝑒 𝑚𝑒𝑡

𝑖∈{𝑆𝑒𝑐𝑢𝑟𝑖𝑡𝑦,𝑃𝑟𝑖𝑣𝑎𝑐𝑦,𝑅𝑒𝑠𝑖𝑙𝑖𝑒𝑛𝑐𝑒,𝑅𝑒𝑙𝑖𝑎𝑏𝑖𝑙𝑖𝑡𝑦,𝑆𝑎𝑓𝑒𝑡𝑦}

with

𝑊𝑆𝐶(𝑖), 𝑇𝑊(𝑖) ∈ [0,1], 𝑖 ∈ {𝑆𝑒𝑐𝑢𝑟𝑖𝑡𝑦, 𝑃𝑟𝑖𝑣𝑎𝑐𝑦, 𝑅𝑒𝑠𝑖𝑙𝑖𝑒𝑛𝑐𝑒, 𝑅𝑒𝑙𝑖𝑎𝑏𝑖𝑙𝑖𝑡𝑦, 𝑆𝑎𝑓𝑒𝑡𝑦},

∑ 𝑊𝑆𝐶(𝑖) = 1

𝑖∈{𝑆𝑒𝑐𝑢𝑟𝑖𝑡𝑦,𝑃𝑟𝑖𝑣𝑎𝑐𝑦,𝑅𝑒𝑠𝑖𝑙𝑖𝑒𝑛𝑐𝑒,𝑅𝑒𝑙𝑖𝑎𝑏𝑖𝑙𝑖𝑡𝑦,𝑆𝑎𝑓𝑒𝑡𝑦}

The level per system characteristic (SC) may be considered as an analogous weighted

combination of the degree of fulfilment of protection profiles:

𝑇𝑊(𝑖) =

{

0, 𝑜𝑛𝑒 𝑜𝑟 𝑚𝑜𝑟𝑒 𝑃𝑂𝑆𝐶(𝑗)𝑖𝑠 𝑏𝑒𝑙𝑜𝑤 𝑡ℎ𝑒 𝑚𝑎𝑛𝑑𝑎𝑡𝑜𝑟𝑦 𝑎𝑐𝑐𝑜𝑟𝑑𝑖𝑛𝑔 𝑡ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑

∑ 𝑊𝑆𝐶(𝑗) ∗ 𝑃𝑂𝑆𝐶(𝑗),

𝑗=1,…,𝑛𝑆𝐶

𝑎𝑙𝑙 𝑚𝑎𝑛𝑑𝑎𝑡𝑜𝑟𝑦 𝑝𝑟𝑜𝑡𝑒𝑐𝑡𝑖𝑜𝑛 𝑜𝑏𝑗𝑒𝑐𝑡𝑖𝑣𝑒𝑠 𝑎𝑟𝑒 𝑚𝑒𝑡

with

𝑊𝑆𝐶(𝑗), 𝑃𝑂𝑆𝐶(𝑗) ∈ [0,1], 𝑗 = 1, … 𝑛𝑆𝐶 , 𝑆𝐶 ∈ {𝑆𝑒𝑐𝑢𝑟𝑖𝑡𝑦, 𝑃𝑟𝑖𝑣𝑎𝑐𝑦, 𝑅𝑒𝑠𝑖𝑙𝑖𝑒𝑛𝑐𝑒, 𝑅𝑒𝑙𝑖𝑎𝑏𝑖𝑙𝑖𝑡𝑦, 𝑆𝑎𝑓𝑒𝑡𝑦},

∑ 𝑊𝑆𝐶(𝑗) = 1

𝑗=1,…,𝑛𝑆𝐶

The formulas illustrate that if a mandatory characteristics or a mandatory attribute is not fulfilled,

that this cannot be compensated.

The two vectors of weights and evaluated fulfilment characterise the IoT system and its

compliance requirements like a fingerprint. Hence this is a kind of biometric data of an IoT system

and should be protected like biometric data. E.g. in communications the least necessary

information should be transmitted.

A trusted 3rd party might assess and evaluate such a scheme and provide a signed Trust

fingerprint to a requesting party on behalf of the other transacting party. Within the global work

on the issues of Trustworthiness by the Plattform Industrie 4.0, the RRI and the IIC

standardization may be expected and evaluation results shall be provided based on Schems

following the Security Act.

Taking the Trustworthiness metrics as a quality KPI as the Plattform Industrie 4.0 does [I40 1] the

metrics can be seen as a combined maturity evaluation based on the 5 system characteristics of

Page 28: DELIVERABLE - SecureIoT Project D3.6... · DELIVERABLE Deliverable Number D3.6 Deliverable Name Trustworthiness ... date of delivery 30/09/2018 Deliverable Leader FUJITSU Status &

Page |

28

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

D3.6 - Trustworthiness Metrics and Util ity Calculation,

Version: 1.00 – Final Document, Date 28/09/2018

the IIC and the related protection objectives introduced by the Plattform Industrie 4.0. The

combined evaluation may follow an approach like Protections Levels in IEC 62443, which include

a maturity and a security view [KOBES]. However, each of the dimensions of Trustworthiness

brings its own protection objectives, maturity measurement model, stakeholder group, etc. That

makes modelling and evaluation of Trustworthiness I IoT challenging.

2.3 Relevant Regulations Regulations specify the legal framework for operating IoT systems. They form an external ruleset

imposed on an IoT system. Within different political and legislation frameworks different rulesets

need to be fulfilled. Thus, trustworthiness of an IoT system may depend heavily on localization.

As explained in Section 1.3, there are several European regulations and directives such as the

Cybersecurity Act, which is currently being newly established, the existing GDPR or Machinery

Directive and the ePrivacy Directive, which is currently being revised.

Within the assessment of stakeholder’s requirements some regulations relevant for SecureIoT

among them GDPR and the ePrivacy directive were identified. Considering the context of Critical

Information Infrastructures, e.g. in Health, Transport and some industries, the NIS directive needs

to be taken into account as well.

In general, vertical specific regulations, e.g. the Machinery Directive or other regulations on

Safety issues for vehicles or health related devices, shall be considered in the specific protection

objectives for each characteristic of the trustworthiness metrics. This type of control, however,

does not yet know any "intelligent behaviour" of machines as known from Artificial Intelligence,

which is by no means deterministic and can therefore also show predictable behaviour or derive

new behaviour from new patterns. This means that this behaviour does not have to be faulty,

because even behaviour that has not been planned can turn out to be correct behaviour. All

stakeholders are breaking new ground here.

Hence, the trust model shall provide some modularity that takes the integration of additional

rule sets into account.

Regulations do not provide (technical) rulesets per se. Any regulation solely provides a basic

framework of general rules and guidelines, which need to be assessed for each individual case

and adhered to, afterwards. Regulations do not aim at prescribing distinct rulesets. Technology

neutrality is a core principle of European law.

Hence, regulations must be understood as a set of aims that must be fulfilled. The means of

fulfilment, i.e. the (technical) rulesets, which are to be applied, can be chosen freely, as long as

they do not violate any parts of a regulation. Thus, the (technical) rulesets, which must be applied

Page 29: DELIVERABLE - SecureIoT Project D3.6... · DELIVERABLE Deliverable Number D3.6 Deliverable Name Trustworthiness ... date of delivery 30/09/2018 Deliverable Leader FUJITSU Status &

Page |

29

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

D3.6 - Trustworthiness Metrics and Util ity Calculation,

Version: 1.00 – Final Document, Date 28/09/2018

in a given case in order to fulfil the provisions of a regulation, must be established on an individual

basis.

From a legal perspective, it does not pose a problem if, upon establishment of the

aforementioned (technical) rulesets, it is found that several different technical approaches or

“rulesets” can be employed to fulfil the regulatory requirements. If two or more technical

solutions are suitable for fulfilling the legal requirements, they can be applied alternatively,

cumulatively or jointly (i.e. taking some parts from one and other parts from the other, as long

as the resulting ruleset is still fully compliant).

The evaluation of a ruleset which was developed in the above manner, may be performed by

legal experts with the help technical experts who have a deeper understanding of the applied

technology. Within the course of this projects such evaluations and reviews will be performed

within D2.7, D5.13 and D5.14.

Usually today a Policy Description Language (PDL) is used to translate manually policies created

by policy makers into technical rules. The automated transcription of rulesets into policies and

the machine based evaluation of such policies and the adherence to them is an unsolved topic of

research and is considered in several tasks of this project (e.g. T2.3, T3.4, and T5.2).

However, there are limited possibilities to machine read existing catalogues about documents

and databases about vulnerabilities that were primarily created for humans and to convert them

into neural networks that can then be understood within the framework of AI algorithms, e.g.

regarding vulnerabilities and threats (see D2.3, section 3.3.2).

The development of further procedures to compile technical transcriptions of regulations and

standards into machine processable policies might be beneficial in future. Meanwhile concepts

like Security Templates (see D2.3 section 3.3) shall provide a pragmatic approach for certain

applications and deployments.

2.4 Relevant Standards Major relevant standards have been identified in the stakeholder’s requirements developed in

T2.2. Among them there are especially ISA 99 and ISO/IEC 62443 with regard to Security in IIoT.

This covers a wide range, however within each dimension more standards need to be considered

modelling trust levels and their evaluation.

Among those standards there are

Page 30: DELIVERABLE - SecureIoT Project D3.6... · DELIVERABLE Deliverable Number D3.6 Deliverable Name Trustworthiness ... date of delivery 30/09/2018 Deliverable Leader FUJITSU Status &

Page |

30

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

D3.6 - Trustworthiness Metrics and Util ity Calculation,

Version: 1.00 – Final Document, Date 28/09/2018

Security is covered by many standards. The most prominent are the ISO 27000 series.

Furthermore the IEC 62443 illustrates approaches to industrial security using

security and protection levels.

Privacy is covered by vertical specific standards, which shall extend the regulation based

rule sets. Especially in eHealth HIPAA is well known. In the automotive sector e.g.

ISO/IEC CD 27550 describes requirements on vehicle owners’ privacy.

Resilience is a wide range topic including aspects of quality of service, risk management,

business continuity (e.g. ISO 22301). Hence, several standards may apply and

definition of Trust Levels will be challenging and trade-offs need to be considered.

Moreover, a fundamental part of evaluating resilience is a clear overview of all

available assets and their properties, e.g. in a CMDB based on an ISO 20000

process.

Reliability is closely linked to topics of risk management and availability. Again, this is often

sector related. Especially in critical infrastructure resilience has been considered

for many years since availability plays an important role in those sectors. Hence,

within this area focus should be on availability using the lessons learned, e.g. in

energy and other critical sectors.

Safety often needs to consider vertical specific standards. Therefore, the metrics needs

to facilitate modular evaluation of rule sets and trust levels. During SecureIoT most

relevant standards in the areas of the use cases scenarios, i.e. industry 4.0,

connected cars / autonomous vehicles, eHealth will be considered, e.g.

• IEC 61511- applications in safety instrumented systems

• IEC 62061 – Safety of machines

• ISO 26262– Functional safety of road vehicles

• NIST 800-82 DCS control industrial processes /control architecture • ISO 13482:2014 specifies requirements and guidelines for the inherently safe

design, protective measures, and information for use of personal care robots

Moreover, general principles like Access Control and Authentication shall be considered. NIST

performed a comparison of latest approaches in [NIST 800-178]. One important result is the

description of a functional architecture, introducing a generic concept of dedicated policy control

points. These policy control points describe, administrate, control and execute policies based on

Policy Description Language (PDL). The concept of policy control points and policies described in

Page 31: DELIVERABLE - SecureIoT Project D3.6... · DELIVERABLE Deliverable Number D3.6 Deliverable Name Trustworthiness ... date of delivery 30/09/2018 Deliverable Leader FUJITSU Status &

Page |

31

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

D3.6 - Trustworthiness Metrics and Util ity Calculation,

Version: 1.00 – Final Document, Date 28/09/2018

a PDL may be taken into account for further evaluation of Trustworthiness and compliance

regarding the five System Characteristics.

2.5 Scenario Multivendor Industry Use Case After the principles of the Trustworthiness Model have been explained, the MVI use case scenario

is used to illustrate the application of the model as an example.

At first the requirements of the components of the scenario mapped to the 5 system

characteristics are listed.

Head Mounted Display (HMD)

The aim in this part of the scenario is to avoid man-in-the-middle attacks through manipulated

third-party applications, trusted certifications are required. Thus trustworthiness in this case may

be related to security only:

Safety Security Privacy Resilience Reliability

not required

avoid information distribution manipulation

not required

not required

not required

not required

avoid information rerouting from device

not required

not required

not required

not required

avoid manipulation of ID recognition and linkage btw. device and operator

not required

not required

not required

Injection Molding Machine

Software attacks are relatively low cost to an attacker, although a highly targeted attack with

company espionage background may involve breaking a door lock to gain physical access to the

system or bypassing Wi-Fi security safeguards (e.g. firewall). This can potentially lead to

dangerous behaviour for humans (e.g. safety functions disabled) or equipment (like in the case

of Stuxnet). Therefore the aim is that the machine park operator may rely on the trustworthiness

Page 32: DELIVERABLE - SecureIoT Project D3.6... · DELIVERABLE Deliverable Number D3.6 Deliverable Name Trustworthiness ... date of delivery 30/09/2018 Deliverable Leader FUJITSU Status &

Page |

32

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

D3.6 - Trustworthiness Metrics and Util ity Calculation,

Version: 1.00 – Final Document, Date 28/09/2018

of the manufacturer of IoT components. Considering the 5 system characteristics the following

table may be taken into account.

Safety Security Privacy Resilience Reliability

Avoid unauthorized access to software implementation in IoT component and network infrastructure

Avoid unauthorized access to software implementation in IoT component and network infrastructure

N/A observe intrusion attempts and defend yourself massively and alert the next instance if possible.

comply with the required security and protection levels under all conditions

Ensure secure hardware implementation, e.g. Spectre, Meltdown…

Ensure secure hardware implementation, e.g. Spectre, Meltdown…

N/A observe intrusion attempts and defend yourself massively and alert the next instance if possible.

comply with the required security and protection levels under all conditions

Protect against careless employees, e.g. introducing malware via unsecure media

Protect against careless employees, e.g. introducing malware via unsecure media

N/A observe intrusion attempts and defend yourself massively and alert the next instance if possible.

comply with the required security and protection levels under all conditions

Configurator

Users of configurations for manufacturing need to trust in the configuration file’s confidentiality

and integrity as well as their compliance to the required protection levels.

Page 33: DELIVERABLE - SecureIoT Project D3.6... · DELIVERABLE Deliverable Number D3.6 Deliverable Name Trustworthiness ... date of delivery 30/09/2018 Deliverable Leader FUJITSU Status &

Page |

33

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

D3.6 - Trustworthiness Metrics and Util ity Calculation,

Version: 1.00 – Final Document, Date 28/09/2018

Safety Security Privacy Resilience Reliability

N/A Configuration file confidentiality and integrity

N/A N/A comply with the required security and protection levels under all conditions

Page 34: DELIVERABLE - SecureIoT Project D3.6... · DELIVERABLE Deliverable Number D3.6 Deliverable Name Trustworthiness ... date of delivery 30/09/2018 Deliverable Leader FUJITSU Status &

Page |

34

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

D3.6 - Trustworthiness Metrics and Util ity Calculation,

Version: 1.00 – Final Document, Date 28/09/2018

3 Trustworthiness Measurements and Assurance

in an IoT Solution 3.1 Objectives and Requirements

3.1.1 Design Objectives

SecureIoT will develop a trustworthiness metrics to support automated negotiation and decision

making by taking into consideration potential issues that arise from the implementation of

different security measures as well as from their distribution.

Combined Metrics / Trade-off

A trade-off analysis will be considered based on assessment of the environment’s threats and

opportunities. For example, threats like SQL injection, cross site scripting and authentication by-

passes are a big risk of consuming process and resources until an industrial IoT device crashes.

This analysis will take into account possible information disclosure, associated costs and potential

conflicts.

Such conflicts may be illustrated in the context of industrial IoT and the integration between

green field components (IIOT) and their functionality (preventive maintenance, monitoring, and

energy efficiency) and the brownfield components. In this typical industrial scenario ICS have

contradictory elements in store, but both have in common that they are not secure by design.

However, both elements have an emphasis on availability.

In general conflicts may occur since imbalanced security measures may affect the complete

environment. The effects and limitations will be analysed for potential distribution, the required

isolation levels, the exclusive uses of the infrastructure, and the hybrid cases.

Modularity / Adaptability

As discussed before in sections 2.1 and 2.2, the metrics shall be adaptive to new rules, to various

locations and to various verticals among them those applied in the SecureIoT use case scenarios.

Therefore, it needs to be open to extensions and where possible include tools for implementation

of additional rule sets.

The objective of adaptability consequently leads to a modular structure of the metrics and the

according evaluation tool.

Simplify Evaluation of Trustworthiness

Page 35: DELIVERABLE - SecureIoT Project D3.6... · DELIVERABLE Deliverable Number D3.6 Deliverable Name Trustworthiness ... date of delivery 30/09/2018 Deliverable Leader FUJITSU Status &

Page |

35

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

D3.6 - Trustworthiness Metrics and Util ity Calculation,

Version: 1.00 – Final Document, Date 28/09/2018

Trustworthiness may be evaluated with respect to different targets like: the confidentiality of

sensitive information, the integrity of valuable information, the availability of critical data, the

response time or the accuracy of outputs. This makes the evaluation of trustworthiness

challenging.

The envisioned Trustworthiness metrics shall facilitate the development of a toolset for a highly

dynamic world. It shall give guidance structuring a complex field, which usually requests a wide

range of expertise and lots of effort for static mostly annual evaluations. It shall replace

cumbersome procedures by an easy to handle tool or procedure applicable in dynamic scenarios.

The metrics shall provide a model for a dynamic evaluation of Trustworthiness this way

simplifying trusted communications and transactions in the IoT.

Usability

As users cannot be expected to understand or verify the provided protection objectives and

trustworthiness attributes themselves, it is crucial for the ability to induce trust that factors for

building trust are evaluated supporting the users need on trustworthiness.

Usability collects all those quality attributes that can be measured subjectively according to user

feedback. It refers to the ease with which a user can learn to operate, prepare input for, and

interpret the output of the service. Usually, the ease of use or usability is affected by how

accessible the system is to the users and how the interaction is designed. For example, the user

should be able to use it correctly with a minimal chance of making mistakes. This in turn usually

affects the trust towards IoT adoption [Lai2011]. Studies have revealed that a high usability of

IoT products or services increases the satisfaction level of end-users and affects the adoption

intention [Gao2014].

With the objective of simplification evaluation of Trustworthiness usability is an important issue.

Thus, the metrics shall be utilizable without very high skills. It shall provide a set of modules with

open interfaces ensuring applicability of modules in various purposes and across verticals

3.1.2 Stakeholders’ Requirements

In deliverable D2.2 three requirements regarding the development of the trustworthiness

metrics and the utility calculation have been presented:

o R3.4.1 Measurability of System Characteristics

o Rationale: Trustworthiness should be evaluated based on the measurability of the five

systems characteristics. Criteria for measurability of these characteristics should be

developed.

Page 36: DELIVERABLE - SecureIoT Project D3.6... · DELIVERABLE Deliverable Number D3.6 Deliverable Name Trustworthiness ... date of delivery 30/09/2018 Deliverable Leader FUJITSU Status &

Page |

36

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

D3.6 - Trustworthiness Metrics and Util ity Calculation,

Version: 1.00 – Final Document, Date 28/09/2018

o R3.4.2 Evaluation of the Metrics

o Rationale: Evaluation of trustworthiness should be based on a computation logic

behind the metrics. Metric rules should define the modalities, such as exceptions,

measurement methods, and practical measurement details. Parameters should allow

for variability in the definition, or in the usage of the metric.

o R3.4.3 Trustworthiness Profiles

o Rationale: The importance of the different key characteristics of trustworthiness

should vary according to industry vertical and individual targets should depend on

regulations, laws and the industry itself. Appropriate profiles should be defined for

the project’s use cases.

These stakeholder requirements shall be taken into account in the design and the

implementation of the trustworthiness calculation.

3.1.3 Functional Requirements

This section presents some of the requirements for the trust services and reputation models. We

note that these requirements are expected to change during the project’s lifetime, and that we

will present any further changes and provide a context for each one during further updates of

the deliverable.

o Service Level Trust: Services within the SecureIoT platform should be able to query

reputation ratings for specific services (e.g. sensors)

o Measurement Level Trust: Services within the SecureIoT platform should be able to query

reputation ratings for specific measurements (e.g. a temperature reading)

o Device Level Trust: Services within the SecureIoT platform should be able to query

reputation ratings for specific devices (e.g. a temperature sensor)

o Multiple Evaluation Criteria: The reputation model should be based on multiple criteria,

as defined and required by the entities processing the data (and the device-platform

interactions). This includes the requirement for being able to interactively define and

update the trust and reputation models during runtime, in order to have the platform’s

component flexible and configurable.

o Multiple Observers: The Trust and Reputation Model should support and mitigate reports

and ratings from multiple observers. This includes the ability to define new observers and

evaluation rules.

o Configurable Reaction Events: The Trust and Reputation Model should be able to

configure and dispatch reaction-based events according to the subscribers’ specification.

I.e., changes in trust and reputation ratings greater than 25% over a specific time interval.

Page 37: DELIVERABLE - SecureIoT Project D3.6... · DELIVERABLE Deliverable Number D3.6 Deliverable Name Trustworthiness ... date of delivery 30/09/2018 Deliverable Leader FUJITSU Status &

Page |

37

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

D3.6 - Trustworthiness Metrics and Util ity Calculation,

Version: 1.00 – Final Document, Date 28/09/2018

3.1.4 Non-functional Requirements

In the domain literature, there is a distinction made between two types of misbehaving entities:

(i) selfish nodes, and (ii) malicious nodes. Transitivity reflects confidence in such nodes or some

of their subcomponents in the (optional) trust or reputation ratings that may mark the date they

generate.

A selfish node is considered a node which has no intention of causing harm within a system.

Instead, the node’s misbehaviour is due to some constraints imposed by a set of rules. For

example, a usual scenario is that in which a node refuses to cooperate in forwarding messages

due to a low power operation state it chose when depleting too much of its energy reserves.

A malicious node on the other hand, is configured to cause harm to the system (regardless of the

constraint policies expected within the network or of its own – more specifically, by not being

restricted by power saving strategies such as the ones a selfish node my chose to adopt).

When considering misbehaving activities, the literature provides a complete set of literature-

specific cases and naming:

o Black and grey holes: usually relevant routing protocols (i.e. ad-hoc routing protocols) and

denoting those attacks in which a node claims to be able to provide the shortest route to

a desired destination during the route-discovery stage or updates. If or when selected,

the node then proceeds to drop the packet instead of delivering it to the destination. In

case of grey holes, the node can selectively forward the packets, making black hole

detection and mitigation mechanisms much harder.

o Bad-mouthing and false-praising: is a technique which requires a group of colluding

malicious nodes in propagating false information about one or more nodes within the

system, determining the computation of lower than deserved reputation score. Similarly,

false-praising techniques can generate positive reputation ratings for otherwise

malicious/selfish nodes.

o Worm holes: similar to the black hole attack, the worm hole attacks generate erroneous

routing information tables, by having two or more colluding malicious node advertising

false forwarding capabilities and neighbours.

o Packet manipulation (e.g. injection): denotes the injection or alteration of packets within

the network, during any of the network-relevant stages: either network setup, or

operation. During the setup, the packets might alter destination and routing information.

During the operation, the malicious nodes might change forwarding routes and message

content data.

Page 38: DELIVERABLE - SecureIoT Project D3.6... · DELIVERABLE Deliverable Number D3.6 Deliverable Name Trustworthiness ... date of delivery 30/09/2018 Deliverable Leader FUJITSU Status &

Page |

38

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

D3.6 - Trustworthiness Metrics and Util ity Calculation,

Version: 1.00 – Final Document, Date 28/09/2018

o Sybil attacks and ID spoofing: represent attacks in which a nodes masquerades as multiple

different nodes. Such a malicious node or attacks is hard to identify, due to the fact that

the malicious node is constantly changing identities.

In addition, given the legislative context in which such mechanisms are expected to operate, we

need to also consider privacy requirements and provide a guarantee that sensitive information

is persisted in a compliant way. From a technical point of view, this likely requires employing:

o Anonymization and pseudonymization, for either completely removing or replacing

sensitive ID-relevant information with pseudonyms.

Un-linking real entities from the anonymized or pseudonymized data by further processing

relevant stored information, e.g. by using anonymization techniques derived from the k-

anonymity approach (e.g. l-diversity or t-closeness). Finally, a trust and reputation computation

generally consist of the following steps:

o An information collection step;

o An information mapping step (to a trust model);

o An information dissemination step (to a reputation model);

o The computation of the trust and reputation ratings (sometimes a decision making step).

With each interaction, these steps are re-computed, which leads to regular updates to the

reputation ratings of various entities.

Figure 3.1.1. Trust computation process

Page 39: DELIVERABLE - SecureIoT Project D3.6... · DELIVERABLE Deliverable Number D3.6 Deliverable Name Trustworthiness ... date of delivery 30/09/2018 Deliverable Leader FUJITSU Status &

Page |

39

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

D3.6 - Trustworthiness Metrics and Util ity Calculation,

Version: 1.00 – Final Document, Date 28/09/2018

These three main categories of factors:

(i) Misbehaviour,

(ii) privacy preserving, and

(iii) computation cycles

are the basis for the evaluation of the various models and enhancements which are to be

considered within the project.

More specifically, these sets of metrics for evaluating results from a resilience point of view,

through

(i) their suitability and adaptability,

(ii) their performance, and

(iii) by measuring and compiling times and latencies.

3.2 Trustworthiness Evaluation Components Evaluation of Trustworthiness requires the evaluation and weighting of the systems

characteristics and their attributes, i.e. Protection Objectives. Furthermore, the degree of

adherence to the Protection Objectives shall be measured and aggregated calculating the degree

of Trustworthiness. Within this section we outline the components of a Trustworthiness

evaluation system.

There are two principal approaches evaluating Trustworthiness attributes:

o Along with the state of the art in Security and in ID management specific discrete Trust

Levels may be defined. This approach also resembles the Security Levels or Protection

Levels of the IEC 62443. For example, Abdul-Rahman and Hailes [] proposed a model in

which the trust rating is referred as Very Trustworthy, Trustworthy, Untrustworthy, and

Very Untrustworthy.

Within this approach Trust Levels shall be defined for each dimension of the metrics and

a combined evaluation shall result in an overall Trustworthiness Level

o In an alternative approach a node’s trust and reputation level is defined as a Trust

Continuum represented by a continuous real number in the range of [0, 1], where 0

represents a complete distrust, 1 a complete trust, and 0.5 ignorance. This is the case in

trust mechanisms such as HTCW or TMBBT. Others, such as GTMS compute a trust values

in the range of [0, 100] – with a similar segmentation as previously described.

A new AI based approach beyond the current scope of the project, might consider

Page 40: DELIVERABLE - SecureIoT Project D3.6... · DELIVERABLE Deliverable Number D3.6 Deliverable Name Trustworthiness ... date of delivery 30/09/2018 Deliverable Leader FUJITSU Status &

Page |

40

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

D3.6 - Trustworthiness Metrics and Util ity Calculation,

Version: 1.00 – Final Document, Date 28/09/2018

trustworthiness as a continuum. This shall result in a continuously changing

Trustworthiness score.

These approaches can be selected for each attribute individually and independently of the system

characteristics. The Trust evaluation component should be modular and adaptive regarding each

Trust attribute.

Thus, the role of the trust evaluation component is to provide both a mechanism, as well as a set

of consumed rules (or models) which allow a group or users (called observers) to compute a

numerical value representing their own trust rating reflecting their individual trust in a specific

data object or entity producing such data objects. This computed trust rating value can represent

the trustworthiness of a single data stream, of a set of data streams (i.e. consecutive

measurements of a physical value, such as temperature), of a services providing the

measurements (this also refers to the case when the entity itself providing the measurement is

composed of several sensors cooperating in a federated manner), or to one or more devices

(federated) as a whole.

When merging the set of individual trust ratings in accordance to reputation rules (or model), the

reputation rating can then be computed. This reputation rating then reflects the network-wide

trustworthiness rating of a specific data reading, service or device, and can be used by any

element within the framework in order to drive the interaction or further data processing.

The set of rules creating these two models –the trust and the reputation model – represent the

core of the trust and reputation modelling component. In addition, in previous research projects,

we have the integration of a system which allows a set of rules to specify how the system is to

react to the generated ratings.

More specifically, a third model, a reaction model, whose role is to specify what kind of event the

trust and reputation mechanisms should generate and propagate to the system. Such generated,

reactive events can include a wide range of definable actions, such as simple annotations of data,

the generation of alerts or emails, up to triggering security or changing the overall behaviour of

the system, e.g. by not consuming specific data anymore.

From an architectural perspective, depicted in Error! Reference source not found., the trust and

reputation modelling component within is composed of three distinct sub-components:

o A trust evaluation component: which reflects the individual trust rating for a specific data

object, provided service or sensor from the perspective of a single observer. Multiple

observers can function by employing different trust models, thus generating different

Page 41: DELIVERABLE - SecureIoT Project D3.6... · DELIVERABLE Deliverable Number D3.6 Deliverable Name Trustworthiness ... date of delivery 30/09/2018 Deliverable Leader FUJITSU Status &

Page |

41

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

D3.6 - Trustworthiness Metrics and Util ity Calculation,

Version: 1.00 – Final Document, Date 28/09/2018

trust evaluations for the same entity (here forth used interchangeable with the previous

set of possible interactions, at data, service or sensor level).

o A reputation evaluation component: which merges and generates a single reputation

rating for a specific entity, based on the inputs from one or multiple observers. At any

time, there is a single reputation rating available, unlike the trust evaluation which can be

very subject. In addition, the reputation evaluation reflects the rating of a specific entity

in the system and is being used by components within the system which have not

interacted directly with it.

o A reactive component: which, on certain reputation thresholds, can generate certain

events. Usually we refer to alarms, specific tags used within the system, end similar.

Reactions are also meant to drive and adjust the interactions of the SecureIoT system

with specific entities. E.g. by refusing communication with those which have negative

reputation evaluations in certain contexts, such as when a certain value cannot be verified

by corroboration.

Data Analysis Model

Incoming Data

Event

Reaction

Trust Evaluation

Model

Trust

Rating

Rules

Reputation

Model

Reputation

Rules

Reacting Model

Reputation Mode

External Reacting Rules

Trust

RatingReputation

Alert

Use

rs

Se

rvic

es

Ad

min

istr

ato

rs

Context

Entity Profile

Reputation

Sta

tus

Eve

nts

Read/

Modify

Context

Sta

tus

Eve

nts

Internal

Calculi

Figure 3.2.1. Trust and reputation components

Page 42: DELIVERABLE - SecureIoT Project D3.6... · DELIVERABLE Deliverable Number D3.6 Deliverable Name Trustworthiness ... date of delivery 30/09/2018 Deliverable Leader FUJITSU Status &

Page |

42

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

D3.6 - Trustworthiness Metrics and Util ity Calculation,

Version: 1.00 – Final Document, Date 28/09/2018

3.3 Evaluation Approaches

3.3.1 Overview

Trust and reputation systems use first hand, as well as second-hand referrals in order to compute

the respective trust and reputation ratings. In this section, we briefly present some of the

common computation principles used and presented within the relevant literature. We note that

we will focus on the stochastic models – however, other (simpler) models also exist.

For example, user-driven (or vote-based) ratings employed by interactions portals such as eBay

and Amazon, have employed simple (or variants of) summation/average rating mechanisms to

keep a score calculated as the arithmetic difference of the positive score minutes and of the

negative score minutes.

3.3.2 Stochastic Models

Fuzzy Logic Approaches

Trust and reputation can be represented as linguistically fuzzy concepts, where membership

functions describe to what degree an agent can be described as e.g. trustworthy or not

trustworthy.

Fuzzy logic approaches to trust models allow the representation of partial concepts of degrees of

the trustworthiness or un-trustworthiness of a subject. They are therefore employed in various

trust and reputation models available throughout the relevant research literature.

Even as back as 1998, [MANCHALA] details the approach of employing a fuzzy logic trust matrix

using linguistic terms or the use of fuzzy membership functions.

Page 43: DELIVERABLE - SecureIoT Project D3.6... · DELIVERABLE Deliverable Number D3.6 Deliverable Name Trustworthiness ... date of delivery 30/09/2018 Deliverable Leader FUJITSU Status &

Page |

43

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

D3.6 - Trustworthiness Metrics and Util ity Calculation,

Version: 1.00 – Final Document, Date 28/09/2018

Figure 3.3.1. Fuzzy trust matrix presented in [Manchala]

Similar approaches followed. In 2002, for example, Sabater [SABATER] proposed an extension to

their trust framework REGRET, incorporating social networks and a reputation model, based on

fuzzy rules in order to determine the reliability degree of a the information provided by a social

structure (including the computation of the neighbourhood reputation value).

Bayesian Networks

Bayesian systems take binary ratings as input (i.e. positive or negative) and are based on

computing reputation scores by statistical updating of beta probability density functions (PDF).

The a posteriori (i.e. the updated) reputation score is computed by combining the a priori (i.e.

previous) reputation score with the new rating [29, 31, 48–51, 68]. The reputation score can be

represented in the form of a probability density function parameter.

3.3.3 Technical Evaluation Approach

The basic mechanism for evaluating streams is statistics methods such as averages of streams,

jumps/deviations, density, or quantiles. These reference calculi are used in order to generate

estimators for detecting on-the-fly abnormal service behaviour.

As an initial proof of concept, based on the results of the Horizon 2020 projects RERUM and

CrowdHEALTH [CROWD] architectures, we employ the expert system CLIPS to demonstrate and

implement many of the rules mentioned.

The role of this initial proof of concept is to evaluate and demonstrate the streaming mode

processing capabilities and the (relative) simplicity of the calculations performed. Further

Page 44: DELIVERABLE - SecureIoT Project D3.6... · DELIVERABLE Deliverable Number D3.6 Deliverable Name Trustworthiness ... date of delivery 30/09/2018 Deliverable Leader FUJITSU Status &

Page |

44

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

D3.6 - Trustworthiness Metrics and Util ity Calculation,

Version: 1.00 – Final Document, Date 28/09/2018

iterations of the Trust and Reputation Model plan to employ a more efficient evaluation system,

but still similar to CLIPS.

As an example, the following rule (employed in RERUM) generates an alarm if the observed

values are outside of an interval [minA, maxA]:

;=======================

; Rule valC-mima

;=======================

(defrule valC-mima "checks valC (str val)a-priori boundary

conditions

of each observer [ 0 < valC < 40 ]"

(a-valC-mima (obsN ?obsN)(strN ?strN) (ruID ?ruID)(minA

?minA)(maxA ?maxA))

(a-str (strN ?strN)(valC ?valC) (timC ?timC))

(test (or (< ?valC ?minA) (> ?valC ?maxA)))

=>

(assert (bad ?strN ?obsN "valC-mima" ?ruID (getTime ?timC)))

;(printout t "Alert! "?obsN"'s "?strN" values are abnormal"

crlf)

)

Technical wise, the current prototype for the trust and reputation component is written as

Spring-based Java micro-services. Note-worthy is the current employment of the CLIPS (C

Language Integrated Production System) engine for performing expert system-related

operations. In the case of the trust and reputation component, the CLIPS rules are used to drive

the observer interactions with the observed entity by computing trust ratings.

The reacting system’s goal is to evaluate the Reaction Model and to trigger certain defined

events. Of special interests are the definition and execution of non-trivial rules, which are to be

expected in complex systems. A formal expression of rules for reacting systems is through the

Event Condition Action (ECA) paradigm, which is typical for event-driven architectures and active

database systems (through their support for database triggers). The ECA paradigm defines a

structure of rules, which consist of three main entities:

o An event, which defines the stimuli which triggers the rule.

o A condition, which is evaluated and of which the execution of rule depends on.

o An action, which defines the actions undertaken.

Page 45: DELIVERABLE - SecureIoT Project D3.6... · DELIVERABLE Deliverable Number D3.6 Deliverable Name Trustworthiness ... date of delivery 30/09/2018 Deliverable Leader FUJITSU Status &

Page |

45

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

D3.6 - Trustworthiness Metrics and Util ity Calculation,

Version: 1.00 – Final Document, Date 28/09/2018

ECA rules are expressed in a high-level, declarative language. It is therefore important to have

the language of choice complemented by sufficient knowledge models, so to be able to have a

system which can define events, conditions and actions of a complex high enough for the system

to efficiently perform its tasks, there are several proposed approaches, such as using XML/ XSL

for modelling constraints and entities.

[HUYNH] proposes FIRE, a multi-agent for calculating trust and reputation integrating a number

of information sources: trust, role-based trust, witness reputation and certified reputation in

order to provide a trust metric.

As part of the RERUM project [RERUM], a completely generic, flexible trust and reputation engine

was created [LOPEZ], consisting of two main parts: a trust (and corresponding reputation model),

and a reaction model, which processes and triggers defined events based on various evaluations

realized in the trust model. E.g., the reaction model can assist the authentication and

authorization components in performing their function, or the reasoning components by

providing additional annotated data. Alongside the model a tool and language for defining

custom reactions and data processing are defined, which allows extending the mechanisms to

multiple data formats and events.

3.3.4 Mapping to SecureIoT Architecture

Assessment and evaluation of Trust needs a trusted service and is done usually notarized by a

trusted 3rd party.

Within SecureIoT a prototype demonstrator of such a kind Trustworthiness assessment and

evaluation shall be developed. This demonstrator shall act as a 3rd party for the Multivendor

Industry use case scenario. Within this demonstrator we will use data based on the SecureIoT

components (see figure 3.3.2 and figure 3.3.3).

Page 46: DELIVERABLE - SecureIoT Project D3.6... · DELIVERABLE Deliverable Number D3.6 Deliverable Name Trustworthiness ... date of delivery 30/09/2018 Deliverable Leader FUJITSU Status &

Page |

46

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

D3.6 - Trustworthiness Metrics and Util ity Calculation,

Version: 1.00 – Final Document, Date 28/09/2018

Figure 3.3.2. High Level Logical View of the SecureIoT Architecture and Mapping to Technical Workpackages

The introduced model of Trustworthiness relies on Protection Objective and thus on policies.

Thus, policy managing modules as:

o Policy Information Points (PIP), which collects information from sources and are in a way

the data "snoopers" who know where the information comes from. Typically, a PIP should

know the local streaming data scanner, but also other sources: e.g. a GeoLocation

attribute PIP provides geographical location attributes, such as the location where

monitoring takes place. A Risk Calculator PIP returns RiskScore properties. An IP

Reputation PIP returns the reputation of IP address. In addition to the streaming data

sources, the environmental conditions via data probes and scanners, but also the

connection properties and contexts

o Policy Decision Points (PDP) are the sole instances, which can decide what response to

an event should be based on the relevant policies and rules that have to be applied.

o In SecureIoT Policy Enforcement Points (PEP) are the checkpoints to enforce the

corresponding response decided by the PDP, which to some extent belongs together. The

PEP is the role of a "gatekeeper" or "executor", but is not directly involved in the decision-

making process, but merely executes the PDP decision. More complex systems can

influence the PEP to some extent on the basis of different enforcement policies. But in

Page 47: DELIVERABLE - SecureIoT Project D3.6... · DELIVERABLE Deliverable Number D3.6 Deliverable Name Trustworthiness ... date of delivery 30/09/2018 Deliverable Leader FUJITSU Status &

Page |

47

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

D3.6 - Trustworthiness Metrics and Util ity Calculation,

Version: 1.00 – Final Document, Date 28/09/2018

the sense of predictable conduct, it is recommended that all policies come from one

source. This option is not considered here.

will perform important tasks. The role of the SecureIoT components is described below.

Data collection

In the Data Collection and Actuation Layer of the SecureIoT Reference Architecture, the usage of

System Probes and an asset catalogue facilitate collection of system security-related data, e.g.

on assets their configuration and vulnerabilities. Application Level Probes may provide

information on application behaviour for further analysis. As illustrated in D2.3 intelligent probes

may be introduced enabling an improved assessment of adherence to policies and resulting

trustworthiness.

The Data Routing may be used to deliver the information from the probes to appropriate

recipients of IoT security information, e.g. the PIP.

Data Analytics

Data Analytics 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.

This way Data Analytics may support a continuous Trustworthiness evaluation model. In this case,

the data of the IoT system shall be analysed continuously by the Data Analytics module facilitating

detection of a change in Trustworthiness properties.

Page 48: DELIVERABLE - SecureIoT Project D3.6... · DELIVERABLE Deliverable Number D3.6 Deliverable Name Trustworthiness ... date of delivery 30/09/2018 Deliverable Leader FUJITSU Status &

Page |

48

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

D3.6 - Trustworthiness Metrics and Util ity Calculation,

Version: 1.00 – Final Document, Date 28/09/2018

Figure 3.3.3. SecureIoT RA (Reference Architecture) - Components

Security Policy Enforcement Points

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. This module may provide information on the properties of the Trustworthiness

attributes.

Cross Layer Data Exchange

Evaluation of Trustworthiness attributes will involve data across the layers of an IoT system and

of various layers of the SecureIoT solutions. Cross Layer Data Exchange will facilitate the

modularity of a solution and supports evaluation of Trustworthiness using data from various

layers.

Cross Platform Data Exchange

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 49: DELIVERABLE - SecureIoT Project D3.6... · DELIVERABLE Deliverable Number D3.6 Deliverable Name Trustworthiness ... date of delivery 30/09/2018 Deliverable Leader FUJITSU Status &

Page |

49

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

D3.6 - Trustworthiness Metrics and Util ity Calculation,

Version: 1.00 – Final Document, Date 28/09/2018

Besides the focus on Mindsphere regarding the prototype demonstrator a Trustworthiness

module shall be capable of assessing and evaluating Trustworthiness beyond the limits of a single

platform. Hence the role and specification of using Cross Platform Data Exchange module shall

be analysed.

For validation of the concept and design the results will be used in good faith. Development of a

commercial and reliable Trust service will need more rigorous evaluation of data and assets.

Page 50: DELIVERABLE - SecureIoT Project D3.6... · DELIVERABLE Deliverable Number D3.6 Deliverable Name Trustworthiness ... date of delivery 30/09/2018 Deliverable Leader FUJITSU Status &

Page |

50

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

D3.6 - Trustworthiness Metrics and Util ity Calculation,

Version: 1.00 – Final Document, Date 28/09/2018

4 Next Steps in the Project As illustrated in section 1.1 Trustworthiness, it automated assessment and evaluation is an open

issue of global research. Within this deliverable an approach for assessment and evaluation has

been provided as starting point of the development of a prototype demonstrator.

Setting up on the Trustworthiness model defined in this deliverable a preliminary set of attributes

consisting of rules and standards will be defined taking the Multivendor Industry use case

scenario into account. This set shall be used to define assessment and evaluation schemes.

Furthermore, the technical evaluation approach will be refined to lay the ground of a

demonstrator prototype. This will include the specification of the data, which shall be used and

their sources within the SecureIoT. Additionally, the evaluation engine shall be designed.

Based on those specifications and designs the demonstration prototype will be developed and

validated in the use case scenario.

Page 51: DELIVERABLE - SecureIoT Project D3.6... · DELIVERABLE Deliverable Number D3.6 Deliverable Name Trustworthiness ... date of delivery 30/09/2018 Deliverable Leader FUJITSU Status &

Page |

51

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

D3.6 - Trustworthiness Metrics and Util ity Calculation,

Version: 1.00 – Final Document, Date 28/09/2018

5 Conclusion In this Deliverable we have classified the drivers and components of trustworthiness in the IoT.

This classification is based on the internationally agreed state of the art in the three main

initiatives Platform Industry 4.0, IIC and RRI. The current model discussion based on the 5 system

properties defined by the IIC and the Platform Industry 4.0 has been further developed beyond

the current state, in detail.

Corresponding attributes consisting of protection targets according to the respective intended

use and the regionality for the respective system characteristics were presented.

The model was related to the EU legal framework and the regulatory requirements and relevant

standards mentioned in D2.2.

The model was also illustrated using an example.

Initial discussions with partners in the above initiatives on this approach testify to the global value

of the model presented.

In addition, we defined the design objectives and implementation requirements according to the

stakeholder requirements for the development of a prototype for the evaluation of

trustworthiness. Technology candidates were identified and presented.

The architecture of the prototype was mapped to the SecureIoT reference architecture.

The next steps in Task 3.4 were defined.

This and the further development of the model lay the foundations for the development of the

prototype and enrich the international work on trustworthiness in IoT.

Page 52: DELIVERABLE - SecureIoT Project D3.6... · DELIVERABLE Deliverable Number D3.6 Deliverable Name Trustworthiness ... date of delivery 30/09/2018 Deliverable Leader FUJITSU Status &

Page |

52

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

D3.6 - Trustworthiness Metrics and Util ity Calculation,

Version: 1.00 – Final Document, Date 28/09/2018

6 References [AEDS] Birkhofer, H.; Waeldele, M.: “Properties and Characteristics and Attributes and

… - An Approach on Structuring the Description of Technical Systems”, AEDS

2008 Workshop (2008)

[CROWD] CrowdHEALTH, https://www.crowdhealth.eu/

[FUJITSU] Walloschke, T; Neises, J.: „IoT Driving Transformation – Quality in Connected

Services“, Presentation at IIC Quarterly Meeting Coronado (2016)

[GAO] Gao, L.; Bai, X.: “A unified perspective on the factors influencing consumer

acceptance of internet of things technology.”, Asia Pac. J. Mark. Logist., 26,

211–231 (2014)

[GRAND] Grandison, T.; Sloman, M.: “A Survey of Trust in Internet Applications” IEEE

Communications Surveys and Tutorials. 3. 2-16.

10.1109/COMST.2000.5340804 (2000)

[HUYNH] Huynh, T. D.; Jennings, N. R.; Shadbolt, N. R.: “FIRE: An Integrated Trust and

Reputation Model for Open Multi-Agent Systems.” in Journal of Autonomous

Agents and Multi-Agent Systems. 13. 18-22. (2004)

[IIC 1] Durand, J.; Hirsch, F.; Morrish, J.: “Using Metrics in the Industrial IoT Value

Chain to drive Trustworthiness” (to be published by IIC)

[IIC 2] Zarkout, B.: “IoT Trustworthiness is a Journey and NOT a Project” (2018)

[IIC 3] Hirsch, F.; Morrish, J.; Ginter, A.; Molina, J.; Zarkout, B., Buchheit, M., Durand,

J.; Neises, J.; Walloschke, T.: “Managing and Assessing Trustworthiness for

Industrial IoT in Practice” (to be published by IIC)

[IISF] Industrial Internet Consortium (pub.): “Industrial Internet of Things Volume G4:

Security Framework” (2016)

[IoT-A] IoT-A Architecture Reference Model,

http://open-platforms.eu/standard_protocol/iot-a-architectural-reference-

model/

[I40] Dönicke, N.; Fritsche, W.; Gamer, T.; Heer, T-; Jänicke, L-; Jochem, M.; Klasen,

W..; Lantermann, T.; Linke, L.; Mehrfeld, J.; Pfeiffer, T.; Teuscher, A.: “Discussion

Page 53: DELIVERABLE - SecureIoT Project D3.6... · DELIVERABLE Deliverable Number D3.6 Deliverable Name Trustworthiness ... date of delivery 30/09/2018 Deliverable Leader FUJITSU Status &

Page |

53

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

D3.6 - Trustworthiness Metrics and Util ity Calculation,

Version: 1.00 – Final Document, Date 28/09/2018

Paper: Integrity of Data, Systems and Processes as the Core Element of

Networking and Digitalization” (2018)

[I40 RRI] Plattform Industrie 4.0, Robot Revolution Initiative “Facilitating International

Cooperation for Secure Industrial Internet of Things/Industrie 4.0” (2018)

https://www.plattform-

i40.de/I40/Redaktion/DE/Downloads/Publikation/secure-industrial-internet-

of-things-2018.pdf?__blob=publicationFile&v=3

[JOSANG] Jøsang, A; Ismail, R.; Boyd, C.: “A Survey of Trust and Reputation Systems for

Online Service Provision. Decision Support Systems.” 43. 618-644.

10.1016/j.dss.2005.05.019 (2006)

[KNIGHT] McKnight, D.; Chervany, N., "The Meanings of Trust",

http://www.misrc.umn.edu/workingpapers/fullpapers/1996/9604_040100.pd

f (1998)

[KOBES] Kobes, Pierre: “Protection Levels, an holistic approach based on IEC 62443”,

(2017),

http://conference.vde.com/fs/2017/Vortragsfolien/Documents/Protection%2

0Levels,%20an%20holistic%20approach%20based%20on%20IEC%2062443_%

20P.%20Kobes.pdf

[LAI] Lai, I.K.W.; Tong, V.W.L.; Lai, D.C.F.: “Trust factors influencing the adoption of

internet-based interorganizational systems”. Electron. Commer. Res. Appl. 10,

85–93 (2011)

[LOPEZ] Ruiz-López, D.; Cuellar, J.; Staudemeyer, R. C.; Charalampidis, P.; Fragkiadakis,

A.; Kasinathan, P.; Pöhls, H. C.; Suppan, S.; Tragos, E.; Weber, R.: “Modelling the

trustworthiness of the IoT”, RERUM Deliverable D3.3 (2016)

[MANCHALA] Manchala, D. W.: “Trust metrics, models and protocols for electronic commerce

transactions”

http://doi.ieeecomputersociety.org/10.1109/ICDCS.1998.679731 (1998)

[NAZILA] Mohammadi, N. G.; Paulus, S.; Bishr, M.; Metzger, A.; Könnecke, H.;

Hartenstein, S.; Weyer, T.; Pohl, K.: “Trustworthiness Attributes and Metrics for

Engineering Trusted Internet-Based Software Systems” (2014)

https://pdfs.semanticscholar.org/e7ef/28ce3942dfbff919a5f0bba2c03874020

7ad.pdf

Page 54: DELIVERABLE - SecureIoT Project D3.6... · DELIVERABLE Deliverable Number D3.6 Deliverable Name Trustworthiness ... date of delivery 30/09/2018 Deliverable Leader FUJITSU Status &

Page |

54

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

D3.6 - Trustworthiness Metrics and Util ity Calculation,

Version: 1.00 – Final Document, Date 28/09/2018

[RERUM] RERUM, "RERUM | REliable, Resilient and secUre IoT for sMart

cityapplications", https://ict-rerum.eu/

[SABATER] Sabater, S.: “Reputation and Social Network Analysis in Multi-Agent Systems”

[STELTE] Stelte, B.; Rodosek, G. D.: "Assuring trustworthiness of sensor data for cyber-

physical systems” in 2013 IFIP/IEEE International Symposium on Integrated

Network Management, pp 395-402 (2013)

http://opendl.ifip-tc6.org/db/conf/im/im2013/StelteR13.pdf

[VALIMÄKI] Välimäki, M.; Martikainen, P: “Online Intermediary Liability Framework”, p113ff

in Stanford-Smith, B.; Kidd, P. T.(eds.): “E-business – Key Issues, Applications,

Technologies”, IOS Press (2000)

[YAN 1] Yan, Z.; Zhang, P.; Vasilakos, A. V.: “A Survey on Trust Management for Internet

of Things.” in: Journal of Network and Computer Applications. (2014)

[YAN 2] Yan, Z.; Prehofer, C.: “Autonomic Trust Management for a Component Based

Software System” in: IEEE TRANSACTIONS ON DEPENDABLE AND SECURE

COMPUTING.; Vol. 8, No. 6. pp. 810-823 (2011)

[ZVEI] ZVEI - Zentralverband Elektrotechnik und Elektronikindustrie e. V., Fachverband

Automation (ed.): „Orientierungsleitfaden für Hersteller zur IEC 62443“ (2017)

Page 55: DELIVERABLE - SecureIoT Project D3.6... · DELIVERABLE Deliverable Number D3.6 Deliverable Name Trustworthiness ... date of delivery 30/09/2018 Deliverable Leader FUJITSU Status &

Page |

55

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

D3.6 - Trustworthiness Metrics and Util ity Calculation,

Version: 1.00 – Final Document, Date 28/09/2018

7 Appendix Considering Protection Objectives as Trustworthiness attributes evaluation may use the concept

of Protection Levels or Security Levels. The attached document provides a brief introduction on

it.