This post was written with the invaluable assistance of Steve Watson of Intel.
On April 14, Verizon released its 2015 Data Breach Investigations Report (DBIR). Since then, McAfee Labs posted three blogs (here, here, and here) expanding on the DBIR’s Appendix D discussion of the security of the Internet of Things.
In this final blog discussing IoT security, we outline things businesses can do to prepare for the onslaught of IoT devices in their trusted networks.
Classify your networked physical environment
Are you deploying IoT devices to showcase these new technologies, optimize and automate routine tasks, or enable remote monitoring of environments? Compromising a fancy IoT device–controlled lighting display is a low-risk concern, but if the IoT device controls security lights outside a building or a large commercial refrigeration unit, then the risk is much greater.
Businesses should develop risk-based security classifications and considerations that extend beyond data and systems to networked physical environments. Everyone would agree that life-safety systems have a higher consideration than the person counter at the door of the office break room, but what about the lighting controls for the stairwell or the notification of a leak in the boiler room?
Segment (isolate) the IoT network and actively monitor that network
By isolating IoT devices onto a separate network or subnet, you can mitigate the risk of these devices in production networks. In the event of compromise, the entire IoT implementation can be managed rather than hunting for the devices among other end nodes. An important consideration regarding network isolation is that some devices will need to be multihomed across different network protocols. As noted in our second blog, an IoT device can act as a bridge between protocols, so complete isolation extends beyond the segmentation of that device on a TCP/IP network.
Evaluate IoT in light of the “cyber kill chain” principles
Lockheed Martin popularized the concept of a cyber kill chain and it has been widely used by the security community to describe the different stages of cyberattacks. The model defines seven phases of threats that can be applied to IoT devices in a network—much as the model has been applied to traditional servers and endpoints in that network.
Let’s apply the model to an evaluation of an IoT device: What level of intrusion is possible using the device? Today many IoT devices are likely limited to the Reconnaissance phase because they have not been fully dissembled to uncover vulnerabilities. We should anticipate that compromises may be imminent over the air, Internet, and physical access—moving some IoT devices into the Weaponization and Delivery phases. Once vulnerabilities are identified, attackers will seek to weaponize IoT exploits and then determine how they can be delivered.
Consider the simplicity of a backdoor attack on an IoT device running a modified Android version with limited security controls in place. Does the technical team know which operating system the IoT device is running? Will they be able to detect that a different ROM has been uploaded to the IoT device or know that it was different?
A significant unknown in the threat research community is whether compromise can occur from non-TCP/IP networks to the trusted TCP/IP networks. If an IoT device speaks to node devices via Zigbee or Thread and also has a traditional TCP/IP address, will it be possible to exploit the IoT device from the non-TCP/IP side, completely bypassing network monitoring and analysis?
We also don’t know whether an attacker could compromise multihomed IoT devices, thus accessing sensors, relays, or actuators on the other side of isolated IoT networks.
Compromise from IoT nodes to a TCP/IP network moves from right to left in the following diagram. It might be possible for an attacker to send malformed packets on the IoT node mesh network through the IoT device onto the TCP/IP network. It is easy to imagine a distributed denial of service attack on the TCP/IP network originating from a mesh network.
Compromise from a TCP/IP network to IoT nodes moves from left to right in the diagram. It is similarly easy to imagine an attacker who has gained access to the TCP/IP network triggering actuators on the IoT network, wreaking all sorts of havoc as a result.
These are new threat vectors introduced with the deployment of IoT devices with insufficient research to understand what is possible.
While businesses should be familiar with network monitoring and normalization on their networks, limited options exist for monitoring non-TCP/IP network implementations. If a network compromise occurs on the alternate wireless protocols, will it be possible to detect the attack?
IoT developers must understand where their devices fit into the network
IoT devices will not exist in a vacuum. These devices will sit alongside computing nodes on complex networks. Consequently, developers of IoT devices should understand and architect secure designs into their products. The OWASP list of attack surfaces referenced in our second blog identifies key security areas and details how IoT device developers can mitigate those security risks.
Developers should also keep a careful eye on emerging IoT security standards. Google, Intel, Qualcomm, GE, and others are working on standards, but this area is far from settled. The key thing is to embrace and support those standards as they emerge.
IoT devices are coming to a network near you, so planning and preparation are essential. Learn more about Intel’s approach to IoT devices and their security here.
The post Verizon Report Foreshadows Breaches Originating With IoT Devices, Part 4 appeared first on McAfee.