Industrial Internet Security Framework v 1.0 | Page 38

Security Framework

6: Permeation of Trust in the IIoT System Lifecycle

To establish the trust relationship, the receiving actor delivers requirements, so defining the
expected capabilities that will be delivered by the delivering actor below. This process may face
numerous challenges:
•
•
•
•

Requirements may be difficult to elicit and hard to describe for exceptional situations.
Requirements may change during the design phase or during the lifecycle of the system.
Background knowledge and technical terminology may be different; in international
relationships the communication language can lead to confusion.
Small mistakes in defining the requirements for subcomponents can escalate during the
permeation of trust to large problems for the whole IIoT system.

Standards, provided by organizations like ISO, IEEE, UL, IEC and government organizations
simplify the communication. Requirements and capabilities are clearly documented, so reference
to one or more well-described standards can define the system. Over time, the standards should
define the expectations on implementing trust sufficiently in the system.
There are explicit and implicit requirements. Explicit requirements define features that are
needed by the system, such as when a water pump stops due to achieving a certain water
pressure. Implicit requirements are characteristics of the system, such as quality, composability,
manageability, security, resiliency. An example for an explicit requirement is a low price; an
example of an implicit requirement is high trustworthiness. A practical example for an explicit
requirement in a modern air conditioning system is that the temperature can be controlled via
the internet; an implicit requirement is that internet access cannot be abused by hackers.
Receiving actors focus on explicit requirements and tend to neglect implicit requirements that
can lead to a compromise of trust. Most standards focus on implicit requirements; another
reason to use standards while defining the requirements.
Since the delivering actor provides the capabilities, the trust that the capabilities entirely fulfill
the requirements is based on assurance. The receiving actor should assure the trustworthiness
of the system by carefully studying the documentation describing the capabilities, and then
validate them through thorough practical tests in an environment similar to the intended
environment for actual operation. This process can be expedited by consulting an independent
third party, for example a qualified test laboratory, to verify the assurance within the design.
Unfortunately, receiving actors frequently neglect such systematic confirmation of the
capabilities because of limited time or resources. Trust is then based on the existing relationship
to the delivering actors or even the history and “good name” of the deliverer only.
Since the trustworthiness of the system depends directly on the implementation of the trust
mechanisms at each step in the process, the trustworthiness is the composition of the key system
characteristics implemented in each component and the assurance thereof.

6.2

ROLES IN THE PERMEATION OF TRUST

Permeation of trust can be structured in terms of the role a specific actor has, in one of three
different layers that are shown as rows in Figure 6-2:
IIC:PUB:G4:V1.0:PB:20160926

- 38 -