Upload
others
View
57
Download
0
Embed Size (px)
Citation preview
This document is part of a project that has received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement No 779899. It is the property of the SecureIoT consortium and shall not be distributed or reproduced without the formal approval of the SecureIoT Management Committee.
Project Acronym: SecureIoT
Grant Agreement number: 779899 (H2020-IoT03-2017 - RIA)
Project Full Title: Predictive Security for IoT Platforms and Networks of Smart
Objects
DELIVERABLE
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.