We're hearing a lot about the Internet of things these days. It's the long-promised utopia where our alarm clocks and refrigerators are all Internet-enabled and working magic on our behalf. Further on down the road, anything else we can imagine will be able to talk to hosted service platforms in the cloud and send all kinds of data back and forth. How else would we update the firmware in our recliner?
(NB: I couldn't actually find a connected recliner, but I'm sure one is right around the corner with a companion smartphone app that lets you set heat and massage preferences, and potentially even take you on a little trip to the kitchen for another beer.)
Besides the wholesale connectedness, we're also seeing an odd twist on technology integration -- that is, it's happening backward. Previous to the IoT, we had technology companies adding high-tech workings to ordinary objects. That is vastly different than manufacturing companies trying to add high-tech workings to ordinary objects -- and it's how you wind up with a security and functionality nightmare.
Case in point: I recently had to deal with a home automation and management system of a significant size and pedigree. This system had grown up through the years, evolving from your basic room-based command-and-control wall panels to dedicated remote controls and eventually to smartphone and tablet control. The most recent integration was network connectivity. This was clearly required for smartphone and tablet control, as well as general Web app control over the entire system.
This should have been a very straightforward move -- toss an embedded Linux system in a control box, build an API and a Web app, and connect the thing to a LAN with a wired or wireless interface. Using an embedded Linux distro would cover nearly all the basic needs, leaving the API and app dev portions as the major hurdles to this endeavor. With Linux, you don't have to worry about a network stack, a kernel, device drivers, app servers -- none of it. Just build your app and go.
I'm still not sure what happened, but this was a clear case of extremely poor planning and execution. Somehow this manufacturer developed a system that lacked the ability to assign a static IP (or any IP information whatsoever), had not a single concept of security, and cost a bundle. Accessing the Web application required no username or password, and there were no user authorization levels. The suggested method for remote monitoring and control of the system was to open a port in the firewall to the controller's IP.
To recap, if you wanted to remotely monitor the cameras, remotely control the lights and thermostats, or remotely access any other aspects of the system, you had to expose the entire management interface to everyone on the Internet. If you open that firewall port, anyone on the planet could watch you through your own cameras and control your lights and thermostats. That's assuming the controller kept its DHCP-assigned IP address mapped through the firewall; if the system rebooted and the address changed, this would break, as would other control elements.
Sign up for Computerworld eNewsletters.