Practical Internet of Things Security - Second Edition

Cyber-Physical Systems (CPSes) are a huge, overlapping subset of the IoT. They fuse a broad range of engineering disciplines, each with a historically well-defined scope that includes the essential theory, lore, application, and relevant subject matter needed by their respective practitioners. These topics include engineering dynamics, fluid dynamics, thermodynamics, control theory, digital design, and many others. So, what is the difference between IoT and CPS? Borrowing from the IEEE, the principal difference is that a CPS—comprising connected sensors, actuators, monitoring and control systems—does not necessarily have to be connected to the internet. A CPS can be isolated from the internet and still achieve its business objective. From a communications perspective, the IoT is comprised of things that, necessarily and by definition, are connected to the internet and, through some aggregation of applications, achieve some business objective:

It is worthwhile to think of the IoT as a super-set of CPSes, as CPSes can be enveloped into the IoT simply by connectivity to the internet. A CPS is generally a rigorously engineered system designed for safety, security, availability, and functionality. Emergent enterprise IoT deployments should take note of the lessons learned through the engineering rigor associated with CPSes. For more information on building resilient CPSes, consult the National Institute of Standards and Technology (NIST) Framework for Cyber Physical Systems (https://s3.amazonaws.com/nist-sgcps/cpspwg/files/pwgglobal/CPS_PWG_Framework_for_Cyber_Physical_Systems_Release_1_0Final.pdf) and its related efforts to the IoT-Enabled Smart Cities Framework and others (https://www.nist.gov/el/cyber-physical-systems).

Fast disappearing are the days of utility companies sending workers out in vans to read electric and gas meters mounted to the exterior of your house. Homes today include an array of Distributed Energy Resources (DER) that can communicate demand and load data with the distribution grid. Within the distribution grid, smart devices are able to collect and analyze data to identify anomalies and instabilities. These devices are then able work together to identify measures for correcting the instabilities and avoiding costly brownouts and blackouts.

Additional IoT technology insertions are modernizing business processes across energy operations. For example, after a natural disaster, operators might deploy Unmanned Aerial Systems (UAS) to survey damage to power lines. As aviation authorities begin to evolve regulations on the use of UAS platforms around the world, autonomous flight operations will begin to allow for rapid fault identification and service restoration.

As EV charging begins to strain the electrical grid, new approaches to distributed energy generation must also be considered. Clean energy solutions, such as solar, allow individual consumers to become energy generators and participate in energy transactions with their peers and the utility. Consider the concept of a microgrid. Microgrids are self-contained energy generation and distribution systems that allow owner-operators to be heavily self-sufficient. Microgrid control systems not only rely on data captured from edge devices such as solar panels and wind turbines, but also require data collected from other internet-based services. The control system may capture real-time energy pricing data from a web service, enabling the system to determine the optimal time to generate, buy, or sell back energy from the utility.

The same control system may incorporate weather forecast feeds to predict how much energy their solar panel installations will generate during a certain period of time. Maturing microgrid models are allowing innovative neighborhood microgrids to emerge such as the LO3 implemented in Brooklyn, New York. The LO3 implements a blockchain-based neighborhood microgrid (https://lo3energy.com/) that allows neighbors to sell excess solar energy directly to each other, connecting each neighbor as an IoT node in a larger IoT system.

IoT connectivity has already transformed the transportation industry and promises continued innovations. Companies such as Bosch and Continental have invested heavily in building semi-autonomous driver assistance tools while other companies such as Mercedes Benz and Audi are working on Level 4 and 5 fully autonomous vehicles. These vehicles and tools rely upon sensors that collect and feed data back to Electronic Control Units (ECUs) within the vehicle. Connected Vehicle (CV) technology is rapidly maturing through multiple CV pilots around the world, the largest being the 8,000+ vehicle New York City Connected Vehicle Pilot Deployment (note: the author, Drew Van Duren, is a security consultant to this deployment). General Motors has also fitted some vehicles with CV technology. The 2017 Cadillac CTS, for example, operates Vehicle-to-Vehicle (V2V) technology on the 5.9 GHz spectrum to share vehicle location, speed, and traffic conditions with peer vehicles on the road. V2V technology supports sharing of vehicle data including latitude, longitude, heading angle, speed, lateral and longitudinal acceleration, throttle position, brake status, steering angle, headlight status, wiper status, turn signal status, and vehicle length and width.

Intelligent Transportation Systems (ITS) promise to optimize traffic across smart cities. For example, queue warnings will let vehicles and drivers know whether a backup is forming. Vehicle navigation systems can then quickly route around the backup, easing traffic congestion. Applications such as these are aided by connected roadside equipment, known as Roadside Units (RSUs). RSUs communicate using protocols including Dedicated Short Range Communications (DSRC) to collect, proxy, and transmit data across the vehicle ecosystem, including with the local roadside (traffic signal controllers, dynamic message signs, and so on) and Traffic Management Centers (TMCs).

The term Industry 4.0 is used to describe CPSes that enable smart factories through automation and data exchange. Sensor data is fused and processed by data analytic systems, and machine learning algorithms are trained on smart manufacturing use cases such as remote monitoring and control, smart energy consumption, predictive maintenance, and human-robotic collaboration. These capabilities provide business value through the minimization of downtime or the optimization of processes and reduction of costs. For example, a Jeep Wrangler production facility in Toledo, Ohio, introduced connectivity for over 60,000 IoT endpoints and 259 robots on the assembly line (source: https://customers.microsoft.com/en-us/story/the-internet-of-things-transforms-a-jeep-factory). This implementation provides flexibility to modify manufacturing plans on demand, based on real-time data collected from sensors. The result is cost reduction and profit increase.

Industry 4.0 is also leading the way toward the adoption of robotics within manufacturing. There are many types of robotic platforms, including vision-capable robots, that can capture and analyze video streams in real time, and collaborative robots that can be guided by humans toward accomplishing a task. Robotic systems rely on many types of sensors, including motion sensors, accelerometers, temperature sensors, pressure sensors, and proximity sensors. These platforms can incorporate computer vision capabilities and make use of complex algorithms that support guidance and path planning.

According to the Smart City Tracker 2018 report by Navigant Research (https://www.navigantresearch.com/news-and-views/navigant-research-identifies-355-smart-city-projects-in-221-cities-around-the-world) over 221 cities worldwide implemented at least one smart city project in 2018. The city of Chicago, for instance, implemented the Array of Things project that resulted in the installation of over 500 multifunctional sensors on lampposts within the city. Sensors measure temperature, barometric pressure, light, vibration, carbon monoxide, nitrogen dioxide, sulfur dioxide, ozone, ambient sound intensity, pedestrian and vehicle traffic, and surface temperature (source: https://arrayofthings.github.io/faq.html). Smart cities are also now embracing the concept of open data, providing citizens with access to data collected through IoT sensors. Amsterdam, for example, provides citizens with the ability to look up all open data projects across the city.

Other examples of smart city innovations include networked LED street lights and clean and efficient buildings. The city of San Diego, for example, created the Smart City Open Urban Platform (SCOUP) to track and reduce greenhouse gas emissions across the city's real-estate portfolio (https://www.sandiego.gov/sustainability/smart-city).

Smart Cities represent a complex IoT example as they bring together systems of systems to meet numerous goals. Organizations such as Securing Smart Cities (https://securingsmartcities.org/) have sprouted up to provide guidance to city officials on how to choose and securely implement technologies.

While the majority of this book is devoted to IoT security, the aforementioned IoT use cases clearly emphasize the increasing world demand for cross-disciplined security engineers. We struggle to find it covered in academic curricula outside of a few university computer science programs, network engineering, or dedicated security programs such as SANS. Most security practitioners have strong computer science and networking skills but are less versed in the physical and safety engineering disciplines covered by core engineering curricula. So, the cyber-physical aspects of the IoT face a safety versus security clash of cultures and conundrums:

Because the IoT is concerned with connecting physically engineered and manufactured objects, this conundrum more than any other comes into play. The IoT device engineer may be well versed in safety issues, but does not fully understand the security implications of design decisions. Likewise, skilled security engineers may not understand the physical engineering nuances of a device to ascertain and characterize its physical-world interactions and fix them for security deficiencies. In other words, core engineering disciplines typically focus on functional design, creating things to do what we want them to do. Security engineering shifts the view to consider what the thing can do and how one might misuse it in ways the original designer never considered. Malicious hackers depend on this. The refrigeration system engineer never had to consider a cryptographic access control scheme in what was historically a basic thermodynamic system design. Now, designers of connected refrigerators do, because malicious hackers will look for unauthenticated data originating from the refrigerator or attempt to exploit it and pivot to additional nodes in a home network.

Security engineering is maturing as a cross-discipline, fortunately. We can argue that it is more efficient to enlighten a broad range of engineering professionals in baseline security principles than it is to train existing security engineers in all physical engineering subjects. Improving IoT security requires that security engineering tenets and principles be learned and promulgated by the core engineering disciplines (originating in their academic curricula) throughout their respective industries. If not, industries will never succeed in responding well to emergent threats. Such a response requires appropriating the right security mitigation techniques at the right time when they are the least expensive to implement (that is, the original design as well as its flexibility and accommodation of future-proofing principles). For example, a thermodynamic process and control engineer designing a power-plant will have tremendous knowledge concerning the physical processes of the control system, safety redundancies, and so on. If they understand security engineering principles, they will be in a much better position to dictate additional sensors, redundant state estimation logic, or redundant actuators, based on certain exposures to other networks. In addition, they will be in a much better position to ascertain the sensitivity of certain state variables and timing information that the network, host, application, sensor, and actuator security controls should help protect. They can better characterize the cyber attack and control system interactions that might cause gas pressure and temperature tolerances to be exceeded with a resultant explosion. The traditional network cybersecurity engineer will not have the physical engineering background on which to orchestrate these design decisions.

Medical device and biomedical companies, automotive and aircraft manufacturers, the energy industry, even video game makers and broad consumer markets are involved in the IoT. These industries, historically isolated from each other, must learn to collaborate better when it comes to securing their devices and infrastructure. Unfortunately, there are some in these industries who believe that most security mitigations need to be developed and deployed uniquely in each industry. Standards organizations frequently promote this thinking as well. This isolated, turf-protecting approach is ill-advised and short-sighted. It has the potential of stifling valuable cross-industry security collaboration, learning, and development of common countermeasures.

IoT security is an equal-opportunity threat environment; the same threats against one industry exist against the others. An attack and compromise of one device today may represent a threat to devices in almost all other industries. A smart light bulb installed in a hospital may be compromised and used to perform various privacy attacks on medical devices. In some cases, the cross-industry link is due to intersections in the supply chain or the fact that one industry's IoT implementations were adopted into another industry's systems. Real-time intelligence as well as lessons learned from attacks against industrial control systems should be leveraged by all industries and tailored to suit. The discovery, analysis, understanding, and sharing of how real-world threats are compromising ever-present vulnerabilities need to be improved for the IoT. No single industry, government organization, standards body or other entity can assume to be in control of threat intelligence and information sharing. Security is an ecosystem.

There are so many different types of things within the IoT that it becomes difficult to prescribe security recommendations for the development of any one in particular. At their core, however, IoT devices are hardware-based and contain sensing and communication capabilities. They may also support actuation, storage, and processing capabilities. 

The IoT connectivity layer is ripe with competition. There are many competing communication and messaging standards that can be used within an IoT system.

Protocols such as MQTT, the Constrained Application Protocol (CoAP), the Data Distribution Protocol (DDP), the Advanced Message Queuing Protocol (AMQP), and the Extensible Messaging and Presence Protocol (XMPP) run on top of lower-layer communication protocols and provide the ability for both clients and servers to efficiently agree on data to exchange. REST communications can also be run very effectively within many IoT systems. As of the time of writing, REST and MQTT are popular choices for IoT systems. 

MQTT

MQTT is a publish/subscribe model whereby clients subscribe to topics and maintain an always-on TCP connection to a message broker. As new messages are sent to the broker, they include the topic with the message, allowing the broker to determine which clients should receive the message. Messages are pushed to the clients through the always-on connection:

This model supports flexible communication use cases, allowing sensors to publish their data and brokers to pass that data onto subscribing systems that wish to consume or further process the sensor data. Although MQTT is primarily suited for use over TCP-based networks, the MQTT for Sensor Networks(MQTT-SN) specification provides an optimized version of MQTT for use within WSNs. 

For more information, see Stanford-Clark and Linh Truong, MQTT for Sensor Networks protocol specification, Version 1.2. International Business Machines (IBM). 2013. URL: http://mqtt.org/new/wp-content/uploads/2009/06/MQTT-SN_spec_v1.2.pdf.

MQTT-SN is optimized for use with battery-operated devices possessing limited processing and storage resources. It allows sensors and actuators to make use of the publish/subscribe model on top of ZigBee and similar RF protocol specifications.

CoAP

CoAP is another IoT messaging protocol, UDP-based and intended for use in resource-constrained internet devices such as wireless sensor nodes. CoAP uses DTLS for security services. CoAP consists of a set of messages that map easily to HTTP: GET, POST, PUT, and DELETE:

CoAP device implementations communicate to web servers using specific Uniform Resource Indicators (URIs) to process commands. Examples of CoAP-enabled implementations include smart light switches in which the switch sends a command to change the behavior (state/color) of each light in the system.

DDS

DDS is a data bus used for integrating intelligent machines. Like MQTT, it also uses a publish/subscribe model for readers to subscribe to topics of interest:

DDS allows communications to happen in an anonymous and automated fashion, since no relationship between endpoints is required. DDS also supports Quality of Service (QoS) mechanisms. DDS is designed primarily for device-to-device communication and is used in diverse deployment scenarios, including wind farms, medical imaging systems, and asset tracking systems.

Data collected from sensors may be stored as raw data at the edge and aggregated in storage within edge databases and the cloud. Data can exist in a variety of formats including text files, spreadsheets, log files, and of course in relational and NoSQL databases. Tools such as REST, WebSockets, XML, and JSON can be used for remote data acquisition. When designing the security architecture at this layer, consider how to validate the source of data, whether malicious data has been injected into data streams, and whether data has been tampered with at any point in the life cycle.

CSPs offer data services within their IoT service offerings. For example, AWS supports configuration of IoT devices to offload data to IoT-specific gateways. Data can also be ingested into AWS through platforms such as Kinesis or Kinesis Firehose. Kinesis Firehose, for example, can be used to collect and process large streams of data and forward on to other AWS infrastructure components for storage and analysis.

Once data has been collected within a CSP, logic rules can be set up to forward that data where most appropriate. Data can be sent for analysis, storage, or to be combined with other data from other devices and systems. Reasons for the analysis of IoT data run the gamut from wanting to understand trends in shopping patterns (for example, beacons) to predicting whether a machine will break down (predictive maintenance):

Software as a Service (SaaS) providers also offer analytic services for the IoT. For example, https://www.salesforce.com/in/?ir=1 has designed a tailored IoT analytic solution. Salesforce makes use of the Apache stack to connect devices to the cloud and analyze their large data streams. The Salesforce IoT cloud relies on the Apache Cassandra database, the Spark data-processing engine, Storm for data analysis, and Kafka for messaging.

An example of the immense data collection from IoT devices is the proliferation of smallUnmanned Aerial Systems (sUAS)—or drones—that provide an aerial platform for deploying data-rich airborne sensors. Today, three-dimensional terrain mapping is performed by inexpensive drones that collect high-resolution images and associated metadata (location, camera information, and so on) and transfer it to powerful backend systems for photogrammetric processing and digital model generation. The processing of these datasets is too computationally intensive to perform directly on a drone that faces unavoidable size, weight, and power constraints. It must be done in backend systems and servers. These uses will continue to grow, especially as countries around the world safely integrate unmanned aircraft into their national airspace systems.

IoT devices generate mountains of data that must be captured, aggregated, and processed by analytic systems. Preprocessing of IoT-collected data often occurs at the edge, where an initial filter is applied leaving only filtered data to be passed to a data analytic system in the fog or in the cloud.

Preprocessing also includes the classification of data objects. Classification can be done based on the types and/or sensitivities of the data. Metadata is added, which includes tags that represent the security sensitivity and other attributes of the data or the sources that collected the data. For example, any sensitive data that requires confidentiality protections should be tagged as such. At this stage, both data and metadata should be digitally signed.

Data is cleaned and de-duplicated next. The cleansing process includes corrections that must be made based on bad data. Clean data is then input into data models where it can be produced into products and visualizations.

A key consideration within the data life cycle is the need for data lineage assurance. Data lineage tracks the origin of data and the transformations and actions that were applied to that data over time. Data lineage tools can visually represent data flows and movements across a system. There are a number of data lineage tools on the market today. Apache Falcon is an open source data lineage tool that can be applied to IoT systems. You can learn more about Apache Falcon here: https://falcon.apache.org/.

Applications hosted in the cloud or data centers provide features, reporting, and analytic functions for IoT systems. Applications can be consumer-facing, business-facing, industrial, health-care or municipal. Applications can also be management focused, providing the ability to control, monitor, and configure IoT devices, as in the following examples: 

The architecture of IoT enterprise systems is relatively consistent across industries. Enterprise architects integrate solutions that include edge devices, gateways, applications, transports, cloud services, protocols, data analytics, and storage.

Indeed, some enterprises may find that they must utilize IoT capabilities typically found in other industries and served by new or unfamiliar technology providers. Consider a typical Fortune 500 company that may own both manufacturing and retail facilities. This company's business executives may consider deploying smart manufacturing systems, including sensors that track industrial equipment health status, robotics that perform various manufacturing functions, as well as sensors that provide data used to optimize the overall manufacturing process. Some of the deployed sensors may even be embedded right in their own products to add instrumentation and/or customer-engagement features. 

This same company may also consider how to leverage the IoT to offer enhanced retail experiences to their customers, such as smart billboards integrated with vehicle infotainment systems to allow customized advertisements to consumers as they pass by a retail establishment. 

That same company may require the ability to manage fleets of connected cars and shipping vehicles, drone systems that support the inspection of critical infrastructure and facilities, agricultural sensors that are embedded into the ground to provide feedback on soil quality, and even sensors embedded in concrete to provide feedback on the curing process at their construction sites. 

This complexity introduces challenges to keeping the IoT secure and ensuring that particular instances of the IoT cannot be used as a pivoting point to attack other enterprise systems and applications. For this, organizations must employ the services of enterprise security architects who can look at the IoT from the big picture perspective. Security architects will need to be critically involved early in the design process to establish security requirements that must be tracked and followed through during the development and deployment of the enterprise IoT system.

It is much too expensive to attempt to integrate security later on. Enterprise security architects will select the infrastructure and backend system components that can easily scale to support not only the massive quantities of IoT-generated data, but also have the ability to make secure, actionable sense of all of that data.

The following diagram provides a representative view of a generic enterprise IoT system of systems and showcases the IoT's dynamic and diverse nature:

In this diagram we see energy IoT deployments connected to the cloud along with connected vehicle roadside equipment, health-care equipment, and environmental monitoring sensors. This is not accidental—as previously discussed, one principal feature of IoT is that anything can be connected to everything and everything to anything. It is perfectly conceivable that a health-care biosensor both connects to a hospital's monitoring and data analytic system and simultaneously communicates power consumption data to local and remote energy monitoring equipment and systems.

The growing number of points of connectivity across diverse systems increases the attack surface of an enterprise; therefore, IoT system interconnections must be thoroughly evaluated to understand the threats and required mitigations. 

Data processing and analytic services are already gleaning valuable information from the volumes of data captured by IoT sensors. As the layer of IoT connectivity continues to expand, system designers will be able to incorporate new capabilities that better predict outcomes and failures and support machine-to-machine autonomous collaboration.

The IoT connectivity layer is starting to enable the introduction of pervasive autonomy. We are already seeing how this works in the consumer space, with integrations between vehicles and smart homes as an example. New research in both academia and industry are pushing autonomous systems and capabilities even further. Swarms of drones can work together with no human intervention. Machines can independently process and settle transactions between each other. Self-Driving Vehicles (SDVs) can form platoons that coordinate among themselves on the road. These are just a few examples of the coming age of autonomy.

Different types of autonomous vehicles (cars, drones, ships, and so on) take input from distributed sensors that might include cameras, LIDAR, RADAR, Global Positioning System (GPS), and even intertial measurements. These inputs are transmitted to fusion systems and then processed through navigation, guidance, and mission subsystems, which are integrated with propulsion and other platform sub-systems. Autonomy algorithms that might be employed in a system such as this include sense and avoid, pattern detection, object identifications, vector determination, and collision predictions. 

Machine Learning (ML) is used heavily within autonomous systems. ML algorithms learn over time by training on large datasets. A critical research area for IoT ML is associated with the use of adversarial examples that can train systems to identify malicious inputs into the algorithms. For example, research has shown that it is possible to slightly alter images to fool ML models into thinking that something is not what it really is. Injecting adversarial examples into the ML process can help prepare algorithms to identify and react to attempted abuse.

Over a decade ago, Duke University researchers demonstrated cognitive control of a robotic arm by translating neural control signals from electrodes embedded into the parietal and frontal cortex lobes of a monkey's brain. The researchers converted the brain signals into motor servo actuator input. These inputs allowed the monkey—through initial training on a joystick—to control a non-biological, robotic arm using only visual feedback to adjust its own motor-driving thoughts. So-called Brain Computer Interfaces (BCI), or Brain Machine Interfaces (BMI), continue to be advanced by Dr. Miguel Nocolelis' Duke laboratory and others. The technology promises a future in which neuroprosthetics allow debilitated individuals to regain physical function by wearing and controlling robotic systems merely by thought. Research has also demonstrated brain-to-brain functioning, allowing distributed, cognitive problem-solving through brainlets.

Digital conversion of brain-sensed (via neuro encephalography) signals allows the cognition-ready data to be conveyed over data buses, IP networks, and, yes, even the internet. In terms of the IoT, this type of cognitive research implies a future in which some types of smart devices will be smart because there is a human or other type of brain controlling or receiving signals from it across a BMI. Or the human brain is made hyperaware by providing it sensor feeds from sensors located thousands of kilometers away. Imagine a pilot flying a drone as though it were an extension of his body, but the pilot has no joystick. Using only thought signals (controls) and feedback (feeling) conveyed over a communications link, all necessary flight maneuvers and adjustments can be made. Imagine the aircraft's airspeed, as measured by its pitot tube, conveyed in digital form to the pilot's BMI interface and the pilot feeling the speed like wind blowing across his skin. That future of the IoT is not as far off as it may seem.

Now imagine what type of IoT security may be needed in such cognitive systems where the things are human brains and dynamic physical systems. How would one authenticate a human brain, for example, to a device, or authenticate the device back to the brain? What would digital integrity losses entail with the BMI? What could happen if outgoing or incoming signals were spoofed, corrupted, or manipulated in timing and availability? The overarching benefits of today's IoT, as large as they are, are small when we consider such future systems and what they mean to the human race. So too are the threats and risks.