Some of you no doubt noticed that Google announced their intention to buy a company known as Nest Labs for $3.2B U.S., one of their largest acquisitions ever. This blog isn’t about that acquisition, but it did get me to thinking about what such an acquisition means to our dialog on the security for the Internet of Things. It called to mind what is obvious in the way of concerns about securing a world of interconnected devices vs. what may not be obvious. I thought it would be appropriate to mention a few of the latter in the shadow of such a purchase. I realize that for many of you close to the industry, some of these concerns MAY already be obvious to you. If so, humor me so that I can point out some of them to the mainstream audience.
Concern #1 – For many devices in the IoT, programming and design is actually like a return to the ‘old’ days. While there are some similarities of IoT development to development and engineering for mobile devices (a lot in fact), many of these devices don’t have the user interface, the memory, the processing or the power you would find in a more general-purpose system like a tablet or smartphone. The devices are designed to work in harsh conditions in some cases for years with what comes from the hardware factory and the programmer. Embedded systems design figures prominently into many of these devices, and those devices are often required to communicate and interact directly with other devices, thus requiring a multi-layered understanding of machine-to-machine communications. Creating a security plan for such devices isn’t as easy as it appears. Let’s just take one example. If you are interested in installing some client code on a device of the IoT, you’ll have to make sure you talk with the designers and programmers at the beginning of the cycle to even see if they have the memory and processing to handle it. Early adopters of encryption in some systems are already finding this can be a big issue.
Concern #2 – I’ve noticed a lot of detailed attention paid fo the development of power sources for many devices in the IoT. This has led me to wonder whether or not one of the more interesting attack vectors of the future may be a “denial of power” attack, where someone conversant in the design and architecture of such systems interested in disabling them works out a way to deny those systems of power, either by getting them to do processing in an excessive way (like denial of service attacks in networking) or to otherwise impact the way power is used in the device. This is even true for those devices that might be permanently installed with “regular” attachments to power, such as a sensor for lighting systems in a city. You’ll then need to consider the physical security of the power source to ensure that you are really providing a 360 degree view of securing the device.
Concern #3 – I’ve been reading with interest the discussions about the identities of devices, and whether or not some aspects of traditional identity and access management can be used to address the IoT. While I’m certain that issues will arise regarding authenticating and authorizing access of applications running on devices of the IoT, I was thinking more about the scale of such implementations and how a device might have a relationship with another device, which has a relationship with a human, which has a— you get the idea. There are going to be some interesting designs for security management when you have to give everyone and everything a name and then work out the relationships between them to know what kind of access they should be provided.
My identifying these concerns wasn’t mean to depress you. I am also not the first one to think about them or consider them. But on the road to securing the Internet of Things, I think they bear consideration.