On April 14, Verizon released its 2015 Data Breach Investigations Report (DBIR). Also that day, McAfee Labs posted a blog expanding on the DBIR’s Appendix D discussion of the security of the Internet of Things, exploring the market conditions that have led to security weaknesses in IoT devices.
Today, we highlight the many IoT device attack surfaces. In the days ahead we will also explore the types of IoT device-originated breaches we expect to see in the intermediate term and steps businesses can take to prepare for the onslaught of IoT devices in their trusted networks.
What are the IoT device attack surfaces?
The “Open Web Application Security Project (OWASP) Internet of Things Top 10” provides a good list of IoT device attack surfaces and their specific weaknesses:
- Insecure web interface
- Insufficient authentication or authorization
- Insecure network services
- Lack of transport encryption
- Insecure cloud interface
- Insecure mobile interface
- Insufficient security configurability
- Insecure software/firmware
- Poor physical security
The list identifies obvious themes, including items that do not reach the bar of currently understood security norms (insufficient items) and those that seem to make no attempt to meet industry expectations (insecure items). The list reveals challenges incumbent to low power, small-capacity IoT devices.
The Top 10 also includes foundational areas that must be addressed not just by IoT device developers but also by device manufacturers and development environment creators. If transport layer encryption doesn’t exist in current network libraries for these devices, how can developers be expected to identify this or know how to remedy the problems?
The OWASP list highlights technical issues we would anticipate among newly networked devices. These issues include the lack of transport encryption, authentication, and authorization–as well as insecure interfaces to web, network, and mobile.
There are a few more attack surfaces that we consider significant. In the networking area, they include:
- Consequence of bridging network protocols: Many IoT devices bridge network protocols by linking wired or wireless Ethernet networks to other networks using protocols such as Bluetooth LE, ZigBee, or ZWave. If one network isn’t sufficiently secure, IOT devices could act as windows from the insecure network to the wider network infrastructure.
- Known exploits by RF-connected devices: Law enforcement agencies in multiple countries are examining remote compromises of automotive key fobs by radio frequency–connected devices. If RF is broadly integrated into IoT devices, we should anticipate continued exploit attempts against RF devices.
- NFC vulnerabilities: Near-field communication readers are easily and often integrated into IoT devices for access control and sensor activation. However, NFC card readers and writers can be purchased for just US$25 to duplicate NFC tokens, which make IoT devices with integrated NFC readers less secure.
In an effort to provide lightweight, low-power capability to these new platforms, the providers of IoT building blocks are spinning smaller operating distributions built on current operating systems. When a reduced version of Android is created to fit onto the new devices, are security features left out that could help secure them? Are older, vulnerable versions of the operating system in use for which Android exploits are readily available?
Physical device access is another important IoT device attack surface. In August 2014, McAfee demonstrated the ability to copy or wipe the Arduino platform through physical access to the device using the onboard programming ports. If an IoT device can be rebooted or reset through physical device access and leave no evidence of the action, it will be difficult or impossible for security professionals to understand what happened.
Stay tuned for our predictions of the IoT device-originated breaches we expect to see in the intermediate term. Meanwhile, you can learn more about McAfee’s approach to IoT devices and their security.
This post was written with the invaluable assistance of Steve Watson of McAfee.