Early morning on our annual Thanksgiving pilgrimage I noticed a nontrivial number of cameras along our route on Interstate 95 as we were leaving Northern Virginia. Left to entertain myself by my sleeping passengers, I began to contemplate their meaning.
Back in “the day” a surveillance camera was part of a closed-circuit system. The links between the cameras and the collection point were proprietary and required specialty cabling to each camera location. This approach was neither simple nor cost effective.
Devices are now easily connected through the Internet using mobile connections or other wireless protocols. A camera that communicates via the Internet through some form of wireless communication can now be placed virtually anywhere. Factor in that cameras have become incredibly cheap and suddenly the interstate looks like a science fiction movie with “eyes in the sky” watching over the scene.
Alas, there are two sides to the sword. Internet connectivity greatly extends the portability and usability of medical devices that previously required proprietary protocols and connections within the physical boundaries of the medical facility. But the proprietary nature of the connections created a form of security. Connecting the device to the Internet now makes it accessible to anyone, anywhere.
Obviously, there are layers to the security issue. The first layer to consider is the common IoT connection points. Connectivity for IoT is created using Ethernet, Bluetooth, WiFi, Cellular (GSM/CDMA/LTW), Zigbee/Z-Wave (in the home automation space), USB, Serial, LCD along with interactive buttons, and Debug ports (usually called a JTAG port). Each of these connection points has security protocols that need to be properly deployed to protect the device.
Bluetooth provides a great example, as the different Bluetooth protocols (BT 1.0, 2.0, 3.0, BTLE, etc.) offer varying security controls. Bluetooth also has multiple designations for class of device and class of service (COD) that can create unexpected risk. For example, leaving an extra class of service in your Bluetooth stack may create the potential for unexpected connections with other devices.
The second layer is exploitation of the software associated with the IoT devices. Two interesting recent cases illustrate the point:
• SecurityWeek reported on November 25 that millions of devices share cryptographic keys, making them vulnerable to attack. The sharing of keys and certificates enables a variety of attack vectors.
• SecurityWeek reported on November 30 that an Android-based app used to remotely control billboard lights was vulnerable to compromise. Attackers could bypass the application’s authentication processes and control the lights in the system.
Neither of these examples are as riveting as hacking the braking system of a car, but they’re illustrative of exploiting the applications that interact with the IoT devices. The same security disciplines applied to building web-based and mobile applications for banking or commerce must be applied when building the applications that monitor and manage IoT devices.
The breach of a billboard lighting system may bring a shrug, but there is a third layer to explore. The price of ubiquity is that the IoT creates access points exploitable by those with bad intentions. Billboard lights may not contain any data of value, but the network on which it resides may have lots of other places that do.
Consider the standard IoT example of smart streetlights. A breach of the connections or systems associated with these lights may only be a nuisance. That is unless I could use the access as a way to jump to a protected network that controls traffic signals. Now we have moved from nuisance to mayhem.
Finally, there is a layer that addresses the point where ostensibly innocuous data becomes meaningful. Many “smart” devices use microphones to accept direct commands or collect other data. For example, smart thermostats use the microphone to track when a house is empty to prompt temperature adjustments. The cumulative data creates a picture of personal patterns that could provide those with malicious intent knowledge of when a home is likely to be empty and therefore a target for a break-in.
Security must be built into IoT devices and systems just like any other application. Security practices must be followed. Entry points must be carefully configured with bare minimum functionality enabled. Threat points must be identified and then mitigated. Authentication must be sound.
In the end, we know how to build security in. We need to not let the push to connect things quickly and cheaply dissuade us from doing what is necessary to make connecting “things” secure.