To understand the security risks of IoT-connected devices, we have to start by examining what’s going on within the devices themselves. Take just one example: A ‘Thing’ ends up on my desk which I’ve been told connects to the Internet, but you can’t tell from looking on the outside. As with many 'Things' these days, they are built using standard parts, using a standard operating system and custom-written software.
Since they are built with standard parts, it’s also not unusual to see ports available on the board that aren’t used. In this case, the ‘Thing’ has two USB ports hidden under the plastic simply because it’s cheaper to buy a board with a USB than it is without. So the company covered the ports in plastic. However, they didn’t remove the USB drivers from the Linux operating system on the device and, in this case, the drivers had a vulnerability. The result: with a special USB key, we were able to gain root access to the device.
This is just one example which underlines the challenges we’re now facing as more devices are connected. The only difference between the Internet of Things, and everything else that has been created before it, is connectivity. The reality is that we’ve been building these things for ages, and we’ve been putting in extra stuff because it was cheaper to buy a standard board than it was to create a custom board for the product.
What has changed is the threat model and this requires a new approach in the IoT era. Threat modeling consists of identifying the entry points: how you can interact with the application; understanding the assets (what’s of interest that someone wants to steal or use) and, finally, how you can mitigate the risks of the entry points and assets.
Know the Entry Points
The first mistake in the example was not including an entry point in the threat model because it wasn’t used in the application. That’s what makes hardware unique: even if you’re not using it, you need to protect yourself from it.
Here are some common entry points for the Internet of Things:
- Cellular (GSM/CDMA/LTE)
- Zigbee/Z-Wave (in the home automation space)
- Serial ports
- LCD along with interactive buttons
- Debug ports (usually called a JTAG port)
What makes these more complex is that within each technology is a set of security controls which can protect or expose the device to risk. For example, in Bluetooth there are a set of protocols (BT 1.0, 2.0, 3.0, BTLE, etc). There are varying security controls in each protocol. Additionally, in Bluetooth there are service and device classes. This is what differentiates headphones from a watch. If you leave extra classes of service in your bluetooth stack, all of a sudden the keyboard can connect to your application when you weren’t expecting one.
It is usually the unexpected that creates risks in IoT. Just like in normal software development, where we create use cases, in this case, it also helps to create abuse cases. These are the ways that an attacker would abuse each of the entry points. Through the abuse cases, we can build protections into the system.
Know the Assets
The argument I often hear with the Internet of Things is that there are no assets in the ‘Thing’; there is no personally identifiable information; no transactions occur.
On closer inspection, this is not necessarily the case. Take the example of an IoT garden sensor I have, which reports on the temperature, sunlight, and moisture of the ground. We might assume there aren’t any assets in this ‘Thing’ however, for many devices, especially those used in the commercial space, the first asset is the ability to bridge networks. In the case of the garden sensor, it speaks both Bluetooth and wireless. When you pair the sensor, it talks to my phone via Bluetooth to get the wireless information (including my WPA password). If I could bridge the connection between the Bluetooth and wireless, I could jump on to my protected network. Now, consider the consequences in a commercial setting, for example, if that device was a sensor sitting on the manufacturing floor of a major production plant, there is a risk to the security of the enterprise’s network.
The ability to take control of a device which consumes a service also comes with financial consequences. For example, if the IoT device controls the light switch in a home automation system, and the user loses control of this, there is a direct cost generated to them.
Mitigation of Threats
Assessing all of the entry points and assets will provide a good list of threats to the device that need to be mitigated and most of this comes down to well-defined requirements and development practices. Narrowing the use and configuration of each entry point limits the risk exposure.
For each entry point, make sure only the bare-minimum functionality is enabled. Ensure that there are protections in place to prevent bridging where is shouldn’t occur. Finally, prepare for the potential outcome of something going wrong. Assume the device is compromised; what assets are available to the attacker? Has everything been encrypted? Do you have any keys or passwords that can be used to attack web services or other devices?
'Things' is nothing new; in the developed world, we interact with software every minute. What is new is that these ‘Things’ now have new ways of interaction and new backend services to collect and present the data.
Protecting against those new threats will be the difference between a secure and unsecured device.
Jay Schulman, Managing Principal, Cigital