Prep Your Campus Network for Internet of Things Devices

In an ideal world, Internet of Things devices would connect to special networks, where they would be well documented and secure. On campus, it’s the real world, and IoT devices are crowding onto Wi-Fi quickly and chaotically, causing more than a few headaches along the way.

IT managers trying to support the vast array of devices that students and faculty want to connect to their networks can prepare for this onslaught — and ease the burden on users and themselves — with a few strategies designed for this unique class of network traffic.

SIGN UP: Get more news from the EdTech newsletter in your inbox every two weeks!

Segregate Devices to Maximize Utility

IoT devices rarely support advanced wireless security standards such as WPA2-Enterprise, and good luck trying to get one of these past a portal. Wi-Fi networks that use shared passwords, such as WPA2-PSK, are well supported in IoT, but most users are loathe to go back through setup dialogs to change passwords frequently. So IT managers have a choice: Either give up on enterprise-class authentication and encryption (rarely an acceptable option), or set up a second service set identifier just for IoT devices.

For most IT managers, the simplest solution is a second, poorly secured Wi-Fi SSID that’s dedicated to IoT devices. Typically, this will be protected by WPA2-PSK, with password changes no more than once a year. That’s weak security, but remember that IoT traffic should not be considered sensitive in any case. When the value of the information asset is low, there’s little benefit to installing strong controls, even if this rubs most IT managers the wrong way.

One possible bonus is that when you decrease security on an IoT SSID, you can take the opportunity to increase security to WPA2-Enterprise on the normal faculty/student Wi-Fi networks at the same time.

Another option is to use authentication based on media access control, which requires some sort of registration application as well as a Wi-Fi infrastructure that can do MAC address checks, a fairly common feature in enterprise-class products. You can also combine MAC-based authentication with WPA2-PSK and summertime password changes to provide at least a basic level of security with minimal aggravation for users.

Bring in Firewalls to Lock Down Networks

IoT devices have a different traffic pattern than user devices, and strict firewall rules for outbound traffic can help keep things secure.

Unfortunately, blocking all outbound traffic or limiting to a small number of known applications will cause nothing but frustration. Inevitably, a new IoT device will launch, requiring a new port to be opened to yet another cloud-based service. Even next-generation firewalls have not caught up to this. Depending on an NGFW to identify and control outbound IoT traffic will likely cause problems with misidentified applications.

Although most non-HTTP/HTTPS traffic can be blocked — these devices should be operating almost exclusively on ports 80 and 443 — IT managers in an education environment will probably need to establish block lists rather than whitelists of traffic. These should block obvious no-nos such as email, remote terminal, remote procedure calls, network management and VPN protocols.

Another good technique is to redirect (using destination network address translation) certain protocols such as Domain Name System and Network Time Protocol (and perhaps Simple Message Transfer Protocol) to campus servers, rather than letting that traffic out onto the internet.

Of course, inbound traffic from the internet to IoT networks should be strictly blocked. Depending on the environment, peer-to-peer traffic — traffic between systems on the same Wi-Fi network — is also a candidate for blocking. Generally, IoT devices don’t need to speak to each other. However, areas such as residence halls can upend that policy very quickly, if one IoT device acts as a hub controlling other home automation devices.

The real key to firewall success is to focus on the traffic pattern. IoT devices have very little outbound traffic and should generate new connections at a very low rate; certainly, less than one per second in a well-behaved device. Cameras are the exception, where these are not forbidden by campus privacy policies. IT managers should use the traffic and connection controls in their firewalls to keep IoT devices from becoming nuisances, strictly limiting connection rates and outbound bandwidth.

Monitor Networks to Act Proactively

IT managers who act reactively to network problems should reconsider that strategy, because IoT problems are not nearly as visible as normal end user issues.

A new area to monitor will be the Wi-Fi network itself. Traditional capacity planning based on square footage and expected user load goes out the window when every user brings three or more devices to campus. Many IoT devices are still on old 802.11b frequencies, which can exacerbate capacity problems.

Access points shouldn’t have more than 10 to 20 802.11b clients, and increasing AP density doesn’t notably scale up 802.11b performance. Even when IoT devices are on newer 5-gigahertz (802.11a) frequencies, their slow speed can cause congestion where the same number of new laptops would be perfectly fine.

All this points to a need for IT managers to keep a close eye on client counts, congestion levels and overall throughput of the network. Wi-Fi tends to work well until it fails miserably, and staying ahead of the “fail miserably” point is easy with the right monitoring tools.

IoT security is another area where monitoring can identify small issues before they become big ones. For example, if firewall logs show that an IoT device is suddenly attempting to make outbound connections at a high rate, this suggests that either the device has a bug or, worse, that it has been taken over and is trying to act as part of a botnet. IoT devices are generally consistent, so any change in the types of security alerts coming from the firewalls is a sign that either a device or a user is trying to move outside the envelope of acceptable behavior.