Design engineers might have to implement security elements into a chip, software, or platform, but they may not know how their work fits into their company’s security policies

 

 

Editor’s note: This article is part of AspenCore Media’s IIoT Cybersecurity Special Report

By Nitin
Dahad

We’ve all heard of Internet of Things (IoT) and
Industrial Internet of Things (IIoT). We know the two are different, because
IoT is commonly used for consumer usages and IIoT is used for industrial
purposes.

But
how does a professional group like the Industrial Internet Consortium (IIC)
actually define the IIoT?

The group see IIoT as a system that connects and integrates
operational technology (OT) environments, including industrial control systems
(ICS), with enterprise systems, business processes and analytics.

These IIoT systems differ from ICS and OT because they are
connected extensively to other systems and people. And they differ from IT
systems in that they use sensors and actuators that interact with the physical
world, where uncontrolled change can lead to hazardous conditions.

The benefits of IIoT are the ability of sensors or connected
devices, as part of a closed-loop system, to collect and analyze data and then
do something based on what the data reveals. The very connectivity, however,
also grows the risk of attack — and increasingly cyberattacks — by
those who may want to bring down the system.

One of the many projects under
a Department of Energy (DoE) program to reduce cyber incidents is being driven
by Intel, looking at enhanced security for the power system edge.

Since grid edge devices communicate with each other directly and
through the cloud, the research is developing security enhancements to
emphasize interoperability and provide for real-time situational
awareness. 

First this needs to be done in the form of a secure gateway for
brownfield, or legacy power system devices, then as an internal field
programmable gate array (FPGA) upgrade designed as part of greenfield, or
present day, devices.

The goal is to reduce the cyberattack surface in a way that
doesn’t impede the normal functioning of the critical energy delivery
functions.

Sven Schrecker, chief architect of IoT security solutions at
Intel and co-chair of the security working group at the IIC, said that security
should not be the sole consideration when designing and deploying devices for
IIoT systems, but developers should be thinking more broadly about five overall
key factors:

  • safety
  • reliability
  • security
  • privacy
  • resilience

While design engineers might have to implement security elements
into a chip, software, or platform, they may not necessarily be aware of how
their work fits into their company’s bigger-picture security policies.
“The security policy must be authored by both the IT team and the OT team
together, so that everyone knows what device is allowed to talk to
what,” Schrecker said.

Building a chain of trust
A common theme is to establish a security policy and chain of trust from the
outset, and then ensure it is maintained through design, development,
production and the entire lifecycle of a device. Trust must be built into the
device, the network, and the entire supply chain.

Haydn Povey, a board member of the IoT Security Foundation and
also CEO and founder of Secure Thingz, said security needs to be addressed at
four levels:

  • CxO
    level
  • security
    architect
  • development
    engineer
  • operations
    manager

The development or design engineers are the ones that need to
take the company’s security policy. They may also define factors such as how to
identify and verify that a product is theirs and how to securely provide
software and hardware updates and implement this in chips or software.

The fourth part of the chain is where OEMs are involved in
manufacturing products for IIoT networks, or in deployment of those products.
Here, the production or operations manager needs to ensure that every
electronic component has its own unique identity and can be securely
authenticated at every point in the supply chain.

In discussing the lack of a chain of trust in hardware and
software, Robert Martin, senior principal engineer at the MITRE Corporation and
a steering committee member of the IIC, said, “Connected industrial
systems have so many different tech stacks.”

In fact, he cautioned, “A small change in a microprocessor
can have an unintended impact on the software running on it. If we recompile
the software, run it on a different OS, it will work differently, but no one
will be accountable for software failures resulting from the changes.”

He added, “Compare this to the building trade, where you
would be penalized for making changes that affected safety — there’s
regulation, certification. But we just don’t have the same regime in
software-based technologies.”

Design considerations for IIoT security 
So where does one start with designing security for the IIoT, and what design
considerations must be looked at?

Various industry guidelines exist, such as the IIC’s IoT Security Framework together with its manufacturing profile providing details
for implementing the Framework in the plant, or the National
Institute of Standards and Technology Cybersecurity Framework
.

The main task for the design engineer is determining how to
translate a security policy or security framework into the design and lifecycle
management of a device that forms all, or part of, an IIoT endpoint.

The considerations range from enabling devices with unique
identities to being able to protect the device, identify an attack, recover
from it, remediate it and patch the device.

“The process is no different from safeguarding other
systems,” said Chet Bablalk vice president of solutions for IoT
devices at Arm. “We need to think about security from the ground
up.”

He explained, “The first part is the
analysis — what are the threat vectors and what are you trying to
protect?”

Arm introduced its own platform security architecture (PSA) last
year to support developers of IoT devices. Babla says the PSA is
device-agnostic, as the company is trying to encourage the industry to think
about security.

Analyze, Architect, Implement
The PSA framework comprises three stages — analyze, architect and
implement. “Analysis is the core part of what we are trying to
stress,” said Babla.

This means, for example, conducting a threat model analysis, and
Arm has introduced three analysis documents for common use cases in asset
trackers, water meters and network cameras. This analysis is essential and
echoed by others.

MITRE Corp.’s Martin commented, “We need to start talking
about what are the potential weaknesses in the hardware, and be able to emulate
attack patterns, and make test cases.”

Design engineers need to think about the whole ecosystem, from
chip to cloud, in terms of implementing a system that comprises an immutable
device, or one with a non-changeable identity; enabling trusted boot; and
ensuring that over-the-air (OTA) updates and authentication can be carried out
securely. “Then you can think about mitigation in silicon, the access
points, and the cloud,” said Babla.

ARM PSA Framework

Arm’s platform security architecture (PSA) framework encourages
designers to first consider the threats, and then look at design and
implementation.(Source: Arm)

Life Cycle Management
An important consideration that some say differentiates IIoT security from
traditional IoT security concerns is the life cycle management (LCM).

Secure Thingz’s Povey said LCM has an impact on when software
updates or configuration changes are deployed to IIoT devices. In IIoT
environments, typically the connected devices, sensors and control systems will
not, or should not, be connected to the open Internet.

Therefore, some type of device LCM control layer needs to be
part of IIoT devices. This can be complex software for the reporting,
configuration and management of devices.

But security needs vary in an IIoT network depending on the
endpoints in the system, since it may comprise both an offline internal network
of non-IP-based smart controllers and some type of protection or isolation from
the external Internet; and there will also be wireless devices and sensors that
may or may not be IP-based.

All the endpoint devices need to be managed and controlled in an
industrial system as part of the LCM function.

This allows the industrial factory to control the introduction,
configuration and management of endpoint devices/products that are added to the
internal factory network.

Some high-level objectives of a security solution for IIoT are:

  •        Product
    endpoint authentication
     (device, sensor, control system) —
    is the endpoint product authentic, not a clone? Provides traceability back
    to product manufacturer, manufacturing date, and any other pertinent
    information.
  •        Product
    endpoint configuration and usage control
     — secure management and
    configuration control of the endpoint with various rights and usage models
    controlled or limited. 
  •        Secure
    control of the endpoint control state
  •        Maintenance
    of the endpoint 
    — this includes secure software updates.
  •        Secure
    communications between control systems and the endpoints, and secure
    storage of control system data.
  •        Advanced
    security protection
     — intrusion detection and security monitoring

Fundamental to enabling this endpoint product security at a
lower level are the following requirements for the endpoint device:

  •        Immutable
    device identity
     — the device has to have a
    non-changeable/protected identity, which must be verifiable by
    cryptographic means. This allows a product to identify itself and
    authenticate who made it, pertinent dates, and other information.
  •        Immutable
    root of trust (RoT) 
    — besides the device identity, there also are
    RoTs provisioned into the product. These include low-level secure boot
    loaders, certificates, and asymmetric key pairs that allow the device to
    support bilateral authentication and also enable secure software updates.
    Some parts of the RoT require that keys and other items are protected in
    some type of secure storage area so that they cannot easily be extracted
    from the product.
  •        Immutable
    secure boot loader
     — some type of low-level secure boot manager
    that verifies all firmware and configuration updates to the device/product
    before they are applied. Only the secure boot manager can install and
    apply low-level configuration updates to the endpoint device/product.
  •        LCM
    software/services
     — some type of low-level LCM control services
    that enables management of the endpoint product, including software
    updates and configuration changes.

Security enclaves
Secure Thingz’ Povey said, “Device procurement is influenced by factors
like enabling standard mechanisms to push out updates, how the update will be
stored on an edge device, and the device and memory resource impacts.”

He added, “You need to think about the security enclaves,
where to hide the secrets and the base keys, how to watermark the device.”
Engineers should consider a development environment that allows these factors
to be considered independently from silicon vendor and architecture.

The general industry consensus is that the secure elements
really need to be in hardware in order to ensure embedded trust, since
chip-level encryption can be enforced and protected.

Rich Carpenter, general manager for control and edge platforms
for GE Power, Automation and Controls, said, “We try to establish the root
of trust that starts at the hardware level. Our ‘defense-in-depth’ approach
requires that if a compromise occurs, it won’t propagate through the
system.”

He says that GE use off-the-shelf trusted platform modules
(TPMs) and are working with Intel and AMD processors.

Expectedly, Intel is focused on the hardware approach. Schrecker
said, “Having a hardware root of trust is vital. Hardware-based identity
is burned into the system and having identity at the chip level means it can be
tracked. But the key is to be able to assure the chips are genuine, to be able
to authenticate, and for updateability.”

He adds that hardware-based security doesn’t replace software
security, it just augments it.

In summary, the key considerations when designing for security
in IIoT devices are making the devices immutable, being able to provide trusted
and secure boot, and managing device security over the entire life cycle, which
includes OTA software updates and patches.

In case of an attack, there needs to be a way of accurately
identifying the device, reinstating it to a previous known good state, and
then being able to resolve the issue at the point of attack, as appropriate.
Taking these principles into account is a good start for going to the next
step — hardware implementation.

— Nitin Dahad is a European
correspondent for EE Times.

Check
out all the stories inside this IIoT Cybersecurity Special Project.

The
Day When the Industrial IoT Gets Hacked

IIoT
Meets Cyberattacks: Worst-Case Scenarios

Embedding Security
at the Edge

What
Makes IIoT So Vulnerable to Cyberattacks