We arrive then at the problem of how to define the IoT and how to distinguish the IoT from today's internet of, well, computers. The IoT is certainly not a new term for mobile-to-mobile technology. It is far more. While many definitions of the IoT exist, we will primarily lean on the following three throughout this book.

The ITU's member-approved definition defines the IoT as follows:

The IEEE's small environment description of the IoT is as follows:

The IEEE's large environment scenario describes the IoT as follows:

Each of these definitions is complementary. They overlap and describe just about anything that can be dreamed up and can be physically or logically connected to anything else over the internet or wireless networks. Regardless of definition nuances, the services that the IoT provides to a business, government, or private citizen are the truly valuable aspects of the IoT that we must assure. As security practitioners, we must be able to understand the value of these services and ensure that they are kept available and secure.

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).

IoT security is not traditional cybersecurity, but a fusion of cybersecurity with other engineering disciplines. It addresses much more than mere data, servers, network infrastructure, and information security. Rather, it includes the direct or distributed monitoring and/or control of the state of physical systems connected over the internet. Cybersecurity, if you like that term at all, frequently does not address the physical and security aspects of the hardware device or the physical world interactions it can have. Digital control of physical processes over networks makes the IoT unique in that the security equation is limited not only to the basic information assurance principles of confidentiality, integrity, non-repudiation, and so on, but also to the physical resources and machines that originate and receive that information in the real world. In other words, the IoT has very real analog and physical elements. IoT devices are physical things, many of which are safety-related. Therefore, if such devices are compromised, it may lead to physical harm of persons and property, even death.

The subject of IoT security, then, is not the application of a single, static set of meta-security rules as they apply to networked devices and hosts. It requires a unique application for each system and system-of-systems in which IoT devices participate. Anything physical today can be connected to the internet with the appropriate electronic interfaces. The security of the IoT device is then a function of the device's use, the physical process or state impacted by or controlled by the device, and the sensitivity of the systems to which the device connects.

Cyber-physical and many IoT systems frequently invoke an intersection of safety and security engineering, two disciplines that have developed on very different evolutionary paths but which possess partially overlapping goals. We will delve more into safety aspects of IoT security engineering later in this book, but for now we point out an elegantly expressed distinction between safety and security provided by the noted academic Dr. Barry Boehm, Axelrod, W. C., Engineering Safe and Secure Software Systems, p.61, Massachusetts, Artech House, 2013. He poignantly but beautifully expressed the relationship as follows:

• Safety: The system must not harm the world
• Security: The world must not harm the system

Hence, it is clear that the IoT and IoT security are much more complex than traditional networks, hosts, and cybersecurity. Safety-conscious industries such as aerospace have evolved highly effective safety engineering approaches and standards because aircraft can harm the world and the people in it. The aircraft industry today, like the automotive industry, is now playing catch-up with regard to security because of the accelerating growth of network connectivity to their vehicles.

It is a cliché to declare how fast Moore's law is changing our technology-rich world and how connected our devices, social networks, even bodies, cars, and other objects are becoming.

A useful way to think of IoT technological progression is what happens when the network extends not to the last mile or last inch endpoint but to the last micron, where virtual and digital become physical. Whether the network extends to a motor servo controller, temperature sensor, accelerometer, light bulb, stepper motor, washing machine monitor, or pacemaker battery voltage monitor, the effect is the same: the information sources and sinks facilitate monitoring and control functions between our physical and virtual worlds. In the case of the IoT, the physical world is a direct component of the digital information, whether acting as subject or object.

IoT technology is being rolled out across many industries today. In Europe, for example, the Alliance for Internet of Things Innovation (AIOTI) (see https://aioti.eu ) has designed a set of pilot projects that focus on demonstrating real-world use cases of the IoT in action. These pilots are described in the following table and show the reach and potential impact of the IoT on our daily lives. The IoT is much more than consumer toys connected to the internet. IoT systems are progressing towards making a real difference in the well-being of the population and increased productivity in the business environment:

The impact that the IoT is having on the transformation of industry capabilities is significant. It becomes clear that, as we begin to rely on these technological improvements, the impact of denying or tampering with these services becomes substantial. Each of these systems must be developed with security and resilience in mind. Next, we discuss additional IoT ecosystems that are beginning to add value to our everyday lives. 

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:

• Everyone is responsible for security
• The IoT and CPS expose huge security problems crisscrossing information computing and the physical world
• Most traditional core engineering disciplines rarely address security engineering (though some address safety)
• Many security engineers are unaware of core engineering disciplines
  (for example, mechanical, chemical, and electrical engineering), including fault-tolerant safety design

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.

The IoT world forum reference model describes seven levels of an IoT ecosystem. These levels are as follows:

• Physical devices and controllers
• Connectivity
• Edge computing
• Data accumulation
• Data abstraction
• Application
• Collaboration and processing

We will borrow these seven levels to explore and discuss the makeup of the IoT 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. 

Popular IoT development boards include Arduino, Beagle Board, Pinocchio, Raspberry Pi, and Cubieboard, among others. These development boards are used for prototyping IoT solutions. They include microcontrollers (MCUs), which serve as the brains of the device, provide memory, and a number of both digital and analog General Purpose Input/Output (GPIO) pins. These boards can be modularly stacked with other boards to provide communication capabilities, new sensors, sactuators, and so on to form a complete IoT device.

MCUs well suited for IoT development come from ARM, Intel, Broadcom, Atmel, Texas Instruments (TI), Freescale, and Microchip Technology, among others. MCUs are Integrated Circuits (ICs) that contain a processor, Read-Only Memory (ROM), and Random Access Memory (RAM). Memory resources are frequently limited in these devices. Often, manufacturers IoT-enable physical products by augmenting the MCUs with complete network stacks, interfaces, and RF/cellular transceivers. All of this horsepower is going into system-on-chip configurations and miniaturized daughter boards (single board computers).

In terms of IoT sensor types, the sky's the limit. Examples include temperature sensors, accelerometers, air quality sensors, potentiometers, proximity sensors, moisture sensors, and vibration sensors. These sensors are frequently hardwired into the MCU for local processing, responsive actuation, and/or relay to other systems.

IoT devices often employ a Real-Time Operating System (RTOS) for process and memory management, as well as utility services supporting messaging and other communications. The selection of each RTOS is based on needed performance, security, and functional requirements of the product. There are many RTOS available, including those noted here:

Many IoT device profiles are shrinking to small but powerful SoC units, capable of running a variety of secured-boot operating systems, featuring strict access controls, process isolation, trusted execution environments, kernel separation, information flow control, and tightly integrated cryptographic security architectures. Safety-critical IoT devices employ RTOS that meet industry-specific standards. Examples of these include the following:

• DO-178B: Software considerations in airborne systems and equipment certification for avionics systems
• IEC 61508: Functional safety for industrial control systems
• ISO 62304: Medical device software
• SIL3/SIL4: Safety integrity level for transportation and nuclear systems

Other critical security attributes pertain to security configuration and the storage of security sensitive parameters. Often configuration settings that are applied to an operating system are lost upon power cycle without battery-backed RAM or some other persistent storage. In many instances, a configuration file is kept within persistent memory to provide the various network and other settings necessary to allow the device to perform its functions and communicate. Of even greater interest are the handling of the root password, other account passwords, and the cryptographic keys stored on the devices when the device is power-cycled. Each of these issues has one or more security implications and requires the attention of security engineers. 

End-to-end connectivity between edge devices and web services may be provided by a series of physical and cloud gateways, each aggregating larger quantities of data. Dell, Intel, and other companies market IoT gateways. Companies such as Systech offer multi-protocol gateways that allow for many types of IoT devices to be connected together, using multiple antennas and receivers. There are also consumer-focused gateways, also called hubs, available in the commercial market, that support smart home communications. The Samsung SmartThings hub is one example of this.

Xively, ThingSpeak, and others offer flexible development solutions for integrating new IoT devices into enterprise architectures. In the domain of smart cities, platforms such as Accella and SCOPE, a smart-city cloud-based open platform and ecosystem, offer the ability to integrate a variety of IoT systems into enterprise solutions.

These platforms provide APIs that IoT device developers can use to build new features and services. Increasingly, IoT developers are incorporating these APIs and demonstrating ease-of-integration into enterprise IT environments. The ThingSpeak API, for example, can be used to integrate IoT devices via HTTP communications. This enables organizations to capture data from their sensors, analyze that data, and then take action on that data. Similarly, AllJoyn is an open source project from the AllSeen Alliance. It is focused heavily on interoperability between IoT devices, even when the devices use different transport mechanisms. As IoT matures, disparate IoT components, protocols, and APIs will continue to be glued together to build powerful enterprise-wide systems. These trends beg the question of just how secure these systems will be.

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

Both the Transport Control Protocol (TCP) and the User Datagram Protocol (UDP) have a place in an IoT system. REST, for example, is TCP-based, and MQTT was designed to work with TCP. However, the need to support temporal and bandwidth constrained networks and devices has resulted in a move away from TCP and toward the use of the UDP. For example, MQTT-SN is a tailored version of MQTT that works with UDP. Other protocols such as CoAP are also designed to work well with UDP. Given the significant reliance on UDP at this layer, protocols such as Datagram Transport Layer Security (DTLS) exist as an alternative to Transport Layer Security (TLS), used for securing TCP communications.

IPv4 and IPv6 both play a role at various points within many IoT systems. Tailored protocol stacks such as IPv6 over Low Power Wireless Personal Area Networks (6LoWPAN) support the use of IPv6 in the network-constrained environments that many IoT devices operate within. Furthermore, 6LoWPan has been designed to support wireless internet connectivity at lower data rates for devices with very limited form factor. 

In addition to this, 6LoWPAN builds upon the 802.15.4 Low Rate Wireless Personal Area Networks (LRWPAN) specification to create an adaptation layer that supports the use of IPv6. The adaptation layer provides features that include IPv6 and UDP header compression and support for fragmentation, allowing support for sensors in a variety of uses, including building automation and security. Using 6LoWPAN, designers can take advantage of the link encryption offered within IEEE 802.15.4 and can apply transport layer encryption, such as DTLS.

Radio Frequency (RF) protocols such as Bluetooth Low Energy (BLE), ZWave, and ZigBee support communication between IoT devices or with gateways that then use protocols such as LTE or Ethernet to communicate with the cloud. Tjensvold, Jan Magne, Comparison of the IEEE 802.11, 802.15.1, 802.15.4, and 802.15.6 wireless standards, September 18, 2007. URL https://janmagnet.files.wordpress.com/2008/07/comparison-ieee-802-standards.pdf.

In the energy industry, WirelessHART and Power Line Communication (PLC) technologies such as Insteon are used for device connectivity. PLCs are routed directly over existing power lines, enabling power-connected devices to be controlled and monitored—refer to http://www.eetimes.com/document.asp?doc_id=1279014. PLC is implemented in support of both home and industrial use cases.

IEEE 802.15.4 plays an important role as the physical and data link layer for other IoT protocols, including ZigBee, 6LoWPAN, WirelessHART, and Thread. Basically, 802.15.4 is designed to operate using either point-to-point or star topologies and is ideal for use in low-power or low-speed environments. Furthermore, 802.15.4 devices operate in the 915 MHz and 2.4 GHz frequency ranges, support data rates up to 250 kb/s and communication ranges of roughly 10 meters. The physical layer is responsible for managing RF network access, while the MAC layer is responsible for managing transmission and receipt of frames onto the data link.

ZWave supports the transmission of three frame types on a network—unicast, multicast, and broadcast. Unicast communications (that is, direct) are acknowledged by the receiver; however, neither multicast nor broadcast transmissions are acknowledged. ZWave networks consist of controllers and slaves. There are variants of each of these, of course. For example, there can be both primary and secondary controllers. Primary controllers are allowed to add and remove nodes form the network. ZWave operates at a frequency of 908.42 MHz (North America) and 868.42 MHz (Europe) with data rates of 100 kb/s over a range of about 30 meters.

Bluetooth/Bluetooth Smart also known as Bluetooth Low Energy (BLE) is an evolution of Bluetooth designed for enhanced battery life. Bluetooth Smart achieves its power-saving capability by defaulting to sleep mode and only waking when needed. Both operate in the 2.4 GHz frequency range. Bluetooth Smart implements high-rate frequency-hopping spread spectrum and supports AES encryption.

LTE—often referred to as 4G cellular—is a popular option for IoT connectivity. In a typical LTE network, User Equipment (UE) such as a smart phone (or an IoT device) contains a USIM that securely stores authentication information. The authentication information stored in the USIM enables authentication with the carrier's Authentication Center (AuC). A symmetric pre-shared key is provisioned to both the USIM (at manufacture time) and the AuC (at subscribe time), which then uses that symmetric key to derive an Access Security Management Entity (ASME). The ASME is used to derive additional keys that encrypt signalling and user communications.

Future 5G communications may offer additional deployment options for IoT systems, based on higher throughput and the ability to support many more connections. This may provide enhanced capabilities for direct connectivity of IoT devices to the cloud and allow for new centralized controller functions to be created that support multitudes of geographically dispersed sensors/actuators with limited infrastructure in place. More robust cellular capabilities will further enable the cloud to be the aggregation point for sensor data feeds, web service interactions, and interfaces to numerous enterprise applications.

There are many communication protocols used by IoT devices besides the ones discussed. The following is a description of some of those other protocols:

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 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 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.

XMPP is based on Extensible Markup Language (XML) and is an open technology for real-time communications. It evolved from the Jabber Instant Messaging (IM) protocol. Refer to http://www.ibm.com/developerworks/library/x-xmppintro/.

XMPP supports the transmission of XML messages over TCP transport, allowing IoT developers to efficiently implement service discovery and service advertisements.

XMPP-IoT is a tailored version of XMPP. Similar to human-to-human communication scenarios, XMPP-IoT communications begin with friend requests. For more information, see http://www.xmpp-iot.org/basics/being-friends/.

Upon confirmation of a friend request, the two IoT devices are able to communicate with each other, regardless of their domains. There also exist parent-child device relationships. Parent nodes within XMPP-IoT support configuration of trust policies that dictate what devices can connect with. Communication between IoT devices cannot proceed without a confirmed friend request between them.

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.

AMQP was designed to provide a queuing system in support of server-to-server communications. Applied to the IoT, it allows for both publish/subscribe and point-to-point based communications. AMQP IoT endpoints listen for messages on each queue. AMQP has been deployed in numerous sectors, such as transportation in which vehicle telemetry devices provide data to analytic systems for near-real-time processing.

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 small Unmanned 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: 

• Consumer-facing IoT applications include smart switches and light bulbs, connected thermostats, garage door openers, wearables, connected cars, and small unmanned aerial systems (drones).
• Business-facing IoT applications include store sensors that collect and analyze shopping behavior to make predictions, tailor marketing, and personalize consumer experiences.
• Industrial IoT applications include smart manufacturing systems, industrial robotic systems, and predictive analytics to identify likely failures before they occur and optimize maintenance actions. Industrial IoT applications can also include smart industrial control systems.
• IoT health-care applications can include connected devices such as pacemakers, smart diagnostic tools, and connected hospitals and equipment.
• Municipal IoT applications include smart transportation systems, connected park systems, and smart sensor systems that collect environmental and other information.

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.

While today's IoT innovations continue to push the envelope identifying and establishing new relationships between objects, systems, and people, our imaginations continuously dream up new capabilities to solve problems at unprecedented scale. When we apply our imaginative prowess, the promises of the IoT becomes boundless. Today, we are barely scratching the surface.

The computer-to-device and device-to-device IoT is poised for staggering growth today and over the coming years, but how will its future security depend on what we do today? Cognition and autonomy research provide us a valuable glimpse into the IoT of tomorrow.

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.

In this chapter, we saw how the world is developing and advancing towards a better future with the help of the IoT. We also looked at various uses of the IoT in today's world and then had a brief look at its concepts.

In Chapter 2, Vulnerabilities, Attacks, and Countermeasures, we will learn about threats to IoT systems and approaches we can take to avoid and overcome those threats.