The buzz about the Internet of Things (IoT) in the past few years has been accompanied by growing concerns about security. Researchers at Proofpoint have discovered that hackers used over 25,000 home appliances, like refrigerators, to send spam emails. A Frost & Sullivan report on M2M communications in manufacturing suggests that adoption of the IoT may be slow due to security concerns. James Clapper, the director of national intelligence, recently testified before the Senate Select Committee about securing the IoT.
A couple of months ago, Hewlett-Packard issued an Internet of Things Security Study, which listed personal privacy, insufficient authentication and/or authorization, a lack of transport encryption, and insecure web interfaces, hardware, or software as among the top categories of potential security breaches. The majority of devices covered in the report exhibited one or more of these problems. Proponents of the IoT for embedded systems need to address these issues if the IoT is to continue to gain traction among the general public.
As we see it, one of the fundamental and significant exposures of embedded devices on the IoT stems from a pre-Internet approach to data connectivity and networking. The typical communication scenario is client-server, in which a device (like your refrigerator) is the server that holds the data, and client applications (like a smartphone app) make requests for data. One job of security is to ensure that only authorized clients can ask for the data. However, this approach carries the ever-present risk of allowing inbound requests from the Internet. If anyone can knock on the door, that door can easily become a target for undesirables.
Wouldnít it be better to completely eliminate the possibility of any inbound requests at all? A more secure approach is to have the device make only outbound connections to a specific location on the cloud. This way all firewalls remain closed, and there’s effectively no door to knock on. There’s just a closed tunnel connecting the device to a single address on a server in the cloud. For example, your refrigerator would initiate the conversation and establish a secure connection to the cloud. Then it would pass its data over that secure connection. At the other end, a smartphone app would make a similar secure, outbound connection to the cloud, and request the data from your refrigerator. In this way, both data sources and data users are fully protected.
This approach to the IoT can work between devices in M2M scenarios, as well as between devices and people in M2H systems. Of course, all other security precautions, such as encrypted data protocols and cloud system access control, must also be implemented. Yet, with absolutely no inbound connection possible, a device on the IoT that implements this approach to connectivity stands much less chance of being hacked. With no exposed attack surface, that device provides the kind of security that people are looking for in the IoT.