Evaluating Security of IIoT Testbeds
The ISA/IEC 62443 defines the concept of
trust zones and conduits, 6 which have been
adopted by most testbeds to create the trust
boundaries. A trust boundary may be
enclosed within another trust boundary if
the outer trust boundary has security
policies that may override the trust
boundaries it encloses.
systems, owned by NEC and Microsoft,
respectively, within the testbed platform
tier. This section discusses the security
evaluation challenges presented by the
implementations of use cases that span
multiple trust boundaries, often owned by
different owners.
If a testbed use case spans multiple trust
boundaries, it is under the jurisdiction of
separate security policies. The trust
boundaries that are part of a use case may
be owned or operated by independent
entities that do not share the same security
policies or even the same rigor in enforcing
their security policies.
In computing platforms, the vocabulary used
by practitioners to describe a similar concept
to a trust boundary are Secure Enclave,
Security Zone, and Trusted Security Zone. In
hardware security, an isolated execution
environment with secure storage, remote
attestation, trusted path, and secure
provisioning has been termed Trusted
Execution Environment (TEE). 7 However, a
clear definition of a trust boundary,
analogous to TEE, does not exist in the
distributed hardware and software
deployment environment of IIoT testbeds.
One possible side effect of having multiple
organizations with different security policies
is that the security assumptions and
guarantees within a trust boundary may not
be documented by a testbed team or not
shared well across trust boundaries. A
simple example may involve the consistency
of encryption strength. Messages exiting a
trust boundary A and entering a trust
boundary B may have a stronger encryption
strength than the same messages exiting
trust boundary B to another trust boundary.
Multiple Owners May Obscure Trust
Boundary Properties
The IIC testbeds typically follow the three-
tier architecture for IoT systems illustrated
by the IIRA as previously shown in Figure 2.
However, the implementation of this basic
architecture approach in the testbed
systems has sometimes manifested as
multiple and separate systems owned by
different entities that interoperated within a
single tier. For example, the Retail Video
Analytics testbed included two cloud
A more complicated example may be based
on different objectives of different
organizations owning the trust boundaries.
For example, a cloud platform owner may be
more focused on the infrastructure up-time
and efficiency than on making sure the
6
International Society of Automation (ISA). ISA-62443-3-3-2013, “Security for industrial automation and control systems: System
Security Requirements and Security Levels,” (2013)
7
Sabt, Mohamed, Mohammed Achemlal, and Abdelmadjid Bouabdallah. "Trusted execution environment: What it is, and what
it is not," Trustcom/BigDataSE/ISPA, 2015 IEEE. Vol. 1. IEEE, (2015)
IIC Journal of Innovation
- 59 -