This blog has been repurposed from the January-February 2020 edition of InTech. This article first appeared as a blog post of the Industrial Internet Consortium.
Industrial and Industrial Internet of Things (IIoT) networks almost always represent engineering risks, as well as conventional “business” risks. IIoT is the ultimate mind meld of information technology (IT) and operational technology (OT) networks. The IIoT connects edge devices in OT networks directly to the Internet to enhance operational efficiencies. What confuses security designs for IIoT deployments is differing kinds of risk.
OT practitioners and engineers plot risk on a spectrum from unacceptable physical consequences to safe, correct, continuous, and efficient physical operations. Conventional security practitioners, however, focus on protecting information, cyberresilience, incident response, data recovery, and business continuity. Conventional cyberassets are part of a sea of networks, some needing more protection than others, managed for business risk.
What then of IIoT security, which basically melds these two concepts of physical and business risk together: the ubiquity of IT networks layered on physical control and industrial networks? How do we implement a security program to simultaneously satisfy these very different needs from IT, OT, and engineering teams?
Physical and business risk
IIoT security planning starts with a cyberrisk assessment. Not all IIoT deployments pose nefarious threats to the physical world. When deploying hardware that is only physically able to monitor but not control anything, we generally face only conventional business risks. Conventional enterprise security principles apply, and direct connectivity to enterprise and even cellular and Internet networks is appropriate.
For example, consider a system of thousands of solar-powered rainwater measurement devices distributed throughout a watershed as part of a water treatment flow prediction system. If the switches are compromised, or for that matter physically kicked under a rock by passing tourists, there are no grave consequences to the water system. The system is massively redundant, and device inputs are constantly correlated with external inputs, such as official meteorological reports of rainfall in an area.
But suppose the rainfall-monitoring devices can also control switches that are connected to, say, an irrigation system to activate or deactivate irrigation in an area based on the rainfall it receives. Now there are potential physical consequences of compromise. Worst-case physical consequences might include flooding, washouts, and physical damage to irrigation canals.
If monitor-only IIoT edge devices are connected to conventional control networks, we have a different problem. For example, what if the monitor-only rainfall sensors that are deployed inside the boundaries of a large water-treatment facility were connected to the facility’s OT network? These connections exist because that water-treatment OT network is the easiest one for the IIoT sensors to access. In such an example, compromised monitor-only sensors give attackers an opportunity to pivot their attacks into the facility’s control-critical network.
Microsegmentation
When unacceptable physical consequences of compromise are possible for IIoT deployments, we need strong protections for the edge devices. In these scenarios, a good place to start is microsegment control-critical sets of equipment or networks using unidirectional gateway technology.
Unidirectional gateways are described in section 9.2.6 of the Industrial Internet Consortium Industrial Internet Security Framework (https://www.iiconsortium.org/IISF.htm). These gateways are the strongest of the network segmentation options described in the framework. Unidirectional gateways provide additional protections to edge devices when endpoint protections in those devices are not sufficient. They enable safe flows of monitoring information to enterprise and cloud systems for big data analysis and other benefits, while physically preventing any information flow back into the edge devices.
Where to deploy the gateways is the question—in complex OT networks, unidirectional gateways may be deployed close to the edge devices, close to the connection to enterprise or Internet networks, or anywhere in between. What has emerged as a best practice is perhaps obvious in hindsight—enterprise security teams need to sit down with engineering teams and work out a strategy. Both teams need to agree on where to deploy at least one layer of unidirectional protections.
