This blog post was written by Rick Simon.
Today, Verizon released its 2015 Data Breach Investigations Report (DBIR).
As Verizon noted in the Appendix D discussion of the security of the Internet of Things, most of the examples of IoT device-originated breaches have been proofs of concept—so there were few incidents and little data disclosure to report for 2014. As a result, there is no Verizon “common incident pattern” for IoT device breaches—yet.
But for those who work in incident response and information security, we know it is simply a matter of time until a large-scale IoT device-originated breach occurs with broad-based ramifications.
The IoT device security challenge
IoT devices pose a particular challenge that is not typical in new technology markets. IoT devices are by definition connected to one type of network or another, so they are windows into that network, which leads to the obvious question: Are the windows open or closed?
Further, many IoT devices sense and send information—from personal to critical infrastructure to military—that in the wrong hands poses a significant security risk.
Today and in the days ahead, we will explore why IoT devices are exposed, IoT device attack surfaces, what types of IoT device-originated breaches we expect to see in the intermediate term, and things businesses can do to prepare for the onslaught of IoT devices in their trusted networks.
What are the forces that expose IoT devices?
Emerging market that is not well-understood
Today, a person with a good idea can purchase a $20 microcontroller, download sample code into a beginner-friendly development environment, and create a working prototype of an IoT device that can be put on sale on popular crowd-funding sites. The code may never be inspected and the hardware may never be security tested, but these devices could end up on networks in early adopter homes and business.
The low cost and accessibility of these IoT device building blocks by individuals without formal software development experience have led to a proliferation of neat but unsecure devices. Further, there is little understanding of the implications of that insecurity.
IoT device cost pressure
When developing IoT devices that are meant to be purchased by the millions, cost is particularly important. Every additional bit of main memory or flash storage adds cost. Additional processing power adds cost. Software to protect the device adds cost. As a result, IoT device developers look to create devices that deliver the minimum required functionality at the lowest possible cost.
Many IoT devices have simple tasks: reading a sensor value, flipping a relay on or off to activate another circuit, or exchanging information with a gateway or application controlling the device. Because these tasks are often simple and cost is so critical, these devices are generally developed to run lightweight operating systems and applications on inexpensive 8-bit microcontrollers that are limited in capacity and processing power.
But how does a developer include SSL encryption on an 8-bit microcontroller that is simply turning lights on and off? Does it even need encryption? How can a million such devices be cost-effectively updated for security reasons when there is so little capacity on the embedded ROM that physical access to the device is required to perform the update?
Although questions like these may not concern an IoT developer trying to get a product out the door, these questions become critical if the device is used to control all of the LED streetlights in a city or used in a water treatment plant to turn pumps on and off after reading sensor values from a different IoT endpoint.
IoT device time-to-market pressure
When a budding entrepreneur or a large enterprise detects an IoT market opportunity, a basic question they must answer is “How fast can we get to market?”
In the IoT space, a rich environment of sample code, tutorials, and libraries can accelerate time to market. Although there is good guidance for securing TCP/IP networks, there is little security guidance for the proliferation of network protocols used by many new IoT devices. For example, mesh networks like ZigBee, ZWave, RF, iBeacon, and Bluetooth LE are being bridged (connected, multihomed) to current TCP/IP networks by these IoT devices directly or through a gateway, thereby opening a window to attackers.
Furthermore, the IoT developers primary focus, especially in the early market phase, is to deliver the IoT device’s basic functionality. Security of that new device is secondary. And when they do get around to addressing security issues in a meaningful way, many developers have limited understanding of secure coding practices, especially for this new industry.
Need for IoT device simplicity
There is an overwhelming need in both consumer and business environments to build IoT devices that are simple to operate and maintain and can live in perpetuity, gathering information and sending it to other systems in the network.
To reduce or eliminate maintenance, many IoT devices are designed to not allow software or firmware updates. Yet they are network-capable devices communicating on the same subnets as other sensitive information. Network-capable devices that cannot be updated but proliferate exponentially on networks eventually become open windows for the bad guys to exploit.
Focus on functionality, not security
When discussing the virtues of an IoT device, salespeople inevitably focus on its key benefits:
- “What can it control?”
- “Is it easy to set up?”
- “Can I access it when I am not at home?”
- “Does it work on my smartphone?”
- “How does it make my life simpler?”
Seldom do we hear “Is it secure?”—even when the IoT device is meant to control home security!
With the current focus of IoT devices, especially in the consumer market, on emphasizing ease of use and automation to drive demand, security questions seldom arise. Security is assumed—usually incorrectly—to be provided.
Stay tuned for a discussion of IoT device attack surfaces. Meanwhile, you can learn more here about Intel’s approach to IoT devices and their security.