Jul 25, 2014
Is your Wi-Fi enabled light bulb only using AES 128 encryption? If so, you’re in trouble already! Security research company Context IS identified a security vulnerability in the LIFX LED light bulb with just this level of protection. LIFX has since worked with Context IS to produce a firmware update to fix the security vulnerability problem. Sure, it would have been as a pretty complicated hack — really not worth the effort just to be able to switch off somebody else’s LED light — however, with access to the light bulb’s encryption key, the security firm decrypted the credentials released by the light bulb and then used those them to connect to a secured wireless network.
The take-away here is that integrating smart IoT devices (IoT = Internet of Things, where objects can exchange data with no human interaction) enabled attackers to crack the less secure devices to gain access to corporate networks. You may not have too many smart light bulbs or Internet connected fridges yet, but the IoT is expanding quickly across Europe and North America (for example, smart grid metering), presenting just such threats. Gartner predicts that there will be 30 billion connected IoT objects by 2020, each with its own IP address (IPv6 presumably), and by far the largest number will be wirelessly connected over WiFi or Bluetooth.
So how can companies manage these IoT devices securely? I mean, if AES128 encryption for IoT devices is not good enough, we seem to have a real fight on our hands. Addressing the issue adequately will certainly need efforts from both the manufacturers of IoT devices and corporate network planners, and what they will be focusing on is probably the application programming interface (API). There are currently two approaches to bridging the gap between application developers and corporate IT: build a unified API that different services all use or translate to; or push for common API standards that everyone agrees on.
However, lacking either of these options today means that retaining control of IoT devices and the data they hold requires an API gateway through which all traffic to and from the device must pass through or be blocked by. Typically the types of functions a gateway can provide include: access control (filtering traffic so only authenticated/authorized traffic gets through), and security filtering (checking the content on incoming messages for attacks), as well as analytics/metrics (tracking what’s going on in the API). An API management system for IoT devices could be used to ensure that only specific devices or IP-addresses can access the data stored in the device, and that any information requests are logged for auditing and forensics purposes. Protecting the business means granting API access only to approved and authenticated counterparts and preventing the kind of attacks and breaches that can result in brand damage, loss of revenue, legal challenges, and compliance penalties. Additionally, hanging business needs require easy integration and aggregation of new APIs no matter what interface protocols or authentication schemes they use.
This of course requires the IoT device manufacturers to publish information about their control system and APIs. Many manufacturers still prefer security by obscurity by not specifying an API, but devices with no identified API still have to have an underlying control mechanism that a gateway could interface with.
But with adaptations to in-house requirements, frequent updates and no common standards across different API categories, managing the IoT securely can become very time consuming. Preferably, installed IoT devices should come with APIs that adhere to industry standards. We do have REST/JSON, SOAP/XML, and many other protocols — but such standards have yet to merge coherently. Some things need to happen before the lights go out again all over the world!