Commentary

Critical Infrastructure and the IoT: A Licensing Perspective

By Phillip A. Laplante

Internet of Things (IoT) applications are increasing in diversity and number due to the falling cost of sensors, micro-electromechanical devices, routers, and the decreasing size and increased capabilities of micro-controllers and the virtual machines that run on them. These advances are fueling excitement around many emergent applications for the IoT. But we should be concerned about using IoT applications in critical infrastructure systems, particularly those involving any:

  • Telecommunications grid
  • water supply chain
  • electrical power system
  • road transportation system
  • railway transportation system
  • air transportation network
  • public safety service
  • healthcare system

In any of these applications, certain failures could lead to serious injury and death (including on a large scale).

An IoT application incorporates sensors, cameras, social media feeds and various cyberphysical devices. These inputs are transmitted over wired and wireless communications to an aggregation point, where processors apply various algorithms to make decisions, and then send control signals to actuators associated with devices in the implementation. Each one of these represents a failure point, and in critical infrastructure systems, such a failure can lead to catastrophe. Moreover, interactions (both planned and unplanned) between critical and non-critical systems in the IoT create problems for design engineers. These problems arise from differences in domain vocabulary, standards harmonization and confusion and unwanted emergent behaviors. These interacting, dynamic, cross-domain IoT ecosystems also create the potential for increased threat vectors, new vulnerabilities and tragedy.

For example, consider an application to provide seamless tracking of a container of critical medical supplies (or even transplant organs) from a large hospital to a rural hospital far away. The container starts in the large hospital, then is transferred to an ambulance, which travels the roadways to an airport. The container is then transferred to a flight, and, upon landing, to a train, then to another ambulance, and finally arrives at the rural hospital. During its travels, the container has to cross through many different IoT ecosystems, each complying with different standards (e.g. railway, highway, airport, hospital) and perform handoffs through a variety of communications links (including airborne where communication is usually forbidden). Imagine the engineering difficulties in building this application in a way that patient’s lives are not put at risk.

There is another problem in these complex, multi-domain IoT systems. Connectivity through handheld devices, smart homes, smart cars and wireless-enabled devices increases attack surface for hackers to exploit. In fact, vulnerabilities in critical infrastructure systems have already been reported. For example, there are known vulnerabilities in certain smart power meters, and in older SCADA systems that control many of the critical infrastructure systems around the world. More recently, certain traffic control sensors and network-connected smart LED light bulbs were shown to be open to hacking. These vulnerabilities can be found in any of the ecosystems in the aforementioned scenario — automotive systems, railway transportation systems, even in-flight systems. In fact, these vulnerabilities can be found just about everywhere, even in home appliances.

So imagine another tragic scenario: a hacked refrigerator’s software interacts with mom’s cellphone, interacting with an app and installing a security exploit that can be propagated to other applications with which the cell phone interacts. Mom enters her automobile and the cell phone in her purse interacts with the vehicle’s operator interface software, which downloads the new software, including the defect. Unfortunately, the software defect causes an interaction problem (e.g. a deadlock) that leads to a failure in the software-controlled safety system during a crash, leading to tragedy.

Engineering safe IoT systems for critical infrastructure involves anticipating these scenarios. It also requires a comprehensive approach involving selecting the correct engineering lifecycle model and associated processes, embracing process discipline and standards compliance, understanding complex interactions and selecting the right tools for use throughout the systems lifecycle. These activities describe the licensed Professional Engineer. In fact, we would need licensed Control Systems, Electrical, Computer and, Software Engineers to build these IoT critical infrastructure systems. And depending on the domain, other licensed engineers will need to be involved (e.g. power, nuclear, civil).

Why licensed engineers? Most importantly, we know that they have demonstrated a certain level of competence and will be aware of the kinds of complex problems that face IoT systems designers. Licensing also raises the level of professionalism and contributes to a system of accountability, which increases public trust and confidence. We should demand no less than this level of assurance when dealing with critical infrastructure systems, especially given the complexities of multi-domain IoT ecosystems.

For More Information

The author is working with the National Institute of Standards and Technology to build a database of to categorize sensor failure incidents for use by IoT researchers and systems builders. Please contact the author at plaplante@psu.edu if you would like to contribute data to the project.


Phillip Laplante, CSDP, P.E., Ph.D., is Chairman of the NCEES Software PE Exam Committee.

 

Advertisement

Guest Contributor

IEEE-USA is an organizational unit of the Institute of Electrical and Electronics Engineers, Inc. (IEEE), created in 1973 to support the career and public policy interests of IEEE’s U.S. members. IEEE-USA is primarily supported by an annual assessment paid by U.S. IEEE Members.

Related Articles

Leave a Reply

Your email address will not be published. Required fields are marked *

Back to top button