IoT Is Here Whether You Like Them on Your Network or Not

Personal Internet-connected electronics, designed primarily for home use, are rapidly finding their way into the enterprise. From web-enabled streaming video cameras to connected digital picture frames to large commercial refrigerators, it feels as though everything in our lives is now connected to the Internet. Remember when “Shadow IT” wasn’t a thing and the biggest concern we had was that someone would bring in an external modem so that they could remotely connect? Those were the days.

Now we have to worry about what our users are bringing into the office that might connect to the Internet, must connect to the Internet to operate, or may be exploited for malicious data exfiltration. Welcome to the Internet of Things (IoT).

I’ll draw on an example from some research I performed back in January of this year. Shortly after Google announced that they were acquiring Nest, I started poking around to see exactly what the thermostats could communicate with. A quick Google search for nest firewall ports (which is what I commonly append to a product/application term when looking for what ports are used) provided 433,000 results. Phew, that’s a lot. After looking at several pages, the general consensus from Nest users was that port 9543/tcp needed to be allowed through their respective home routers for the product to work. One page provided the FQDN that the Nest thermostat connects to a domain in the format of: XXXX.transport.nest.com

The domain is hosted in Amazon AWS and uses an IP address associated with Amazon’s Elastic Load Balancing (ELB) service, likely to help distribute the load across multiple guest instances. It’s probably safe to assume that Nest is using Amazon’s VPC functionality given the number of devices it has claimed to have sold to date (~1 million according to a Forbes post). Unfortunately, without getting the device-to-server count directly from Nest, I doubt we’ll ever really know the final number. It’s also probably safe to assume that the IP addresses employed by Nest are load balanced (using ELB) to the servers within its VPC network.

This workflow, though somewhat time consuming, would be invaluable data to help decide if I wanted to utilize this device on my home or corporate network.

5 Things to Consider When Evaluating Internet of Things Devices

Before rushing to open unfettered access for an employee’s shiny new toy, here are some tips on how to evaluate IoT devices prior to allowing them on your corporate network:

1. Create a separate IoT network that allows for Internet access but limits (or blocks) connectivity to internal network systems. Does a digital picture frame need to be on the same network as your HR systems? Probably not. Isolate the non-enterprise devices to their own network.
2. Design a policy that evaluates new Internet of Things devices prior to allowing them on your network. If a user wants to use their shiny new Internet connected toy at work, ask them to borrow it for an afternoon to research it. The only thing they could say is “no”, at which point you can tell them the device won’t be connected to the network – or the device is relegated to the new IoT network mentioned above.
3. Read as much online documentation about the specific device as possible. This is likely going to be the most difficult aspect of this testing plan as few IoT vendors detail the ports and protocols required for proper Internet-bound communication. Most simply say “Allow https on your router to the Internet” which, in the enterprise, simply isn’t informative enough. Nor is it smart to allow unfettered access for any Internet-connected system. The ‘principle of least privilege’ must be applied.
4. As nearly all IoT devices utilize standard SSL to encapsulate their respective data streams (i.e. https) you may want to consider deploying a deep packet inspection (DPI) tool that has the ability to decrypt SSL communications. Alternatively, you may need to deploy separate SSL-decryption technology if your DPI tool lacks the ability. Decrypting SSL may not be necessary to understand how the device operates, but you may find it important if you’re concerned about hidden data leaving the network.
5. Consider dusting off that old 10/100 hub, connecting the IoT device to a test network, and running a packet capture tool against its communications to understand how the device works. Though somewhat time-consuming, this approach allows for a deep understanding of how new IoT devices will work on your network. I recommend using something as simple as tcpdump, tshark, or Wireshark for the visually inclined. Also, keep a sample of the traffic in case you need to revisit the communications requirements during an incident response or forensic exercise.

Hopefully these tips will help you think about evaluating IoT devices in the enterprise. Consumer devices are coming, whether you like them on your network or not. How you handle their deployment, however, is entirely up to you.