The Internet of Things is here – But we can’t trust the things

By: Dr. Hongwen Zhang, CEO, Wedge Networks and Co-chair of the OpenCloud Connect security working group

The Internet of Things needs secure network services through SDN and NFV – because nobody can secure the Things. Even if we try, we can’t keep the Things (better known as endpoints) secured. There are far too many mobile and wireless devices with an incredible variety of operating systems and hardware configurations. There are too many last-mile networks, from the enterprise WiFi to the coffee shop to the home to the playground. There are too many data centers, too many APIs. There are no borders. There is no trust — and there can’t be trust.

The Things cannot be secured. The best hope for preserving end-user privacy, for ensuring data integrity and for protecting devices against intrusions and corruption, is Software Defined Networking. More than that, layered on top of SDN, security implement via Network Functions Virtualization.

Let’s explore the problem, and then see why the only reasonable mass-market solution is to secure the network.

We can’t trust the Things. Smartphones, fitness bands, vending machines, thermostats, inventory control systems, weather stations, Internet cameras, WiFi routers. Who knows about the security of the device’s firmware and operating system? Think about hacked debit-card machines in retail stores. Think about Lenovo laptops with Superfish. Not good!

Many devices have no security or obsolescent encryption. Many can’t be updated, and many won’t be updated even if patches are offered. Let’s not even think about the devices where the password remains set to the factory default – a problem that’s plagued the industry for decades. Even when devices offer some sort of user authentication via software, it cannot be trusted. We have no idea who is using that device, or who might be watching its data.

We can’t trust last-mile networks. Airports, airplanes, coffee shops — we are all aware of the threat from sniffers watching for unencrypted data (such as logins and passwords). Man-in-the-middle attacks are not theoretical.

Compounding the challenge: In an IoT scenario we may not even be able to identify the networks handling the last mile or even 10 miles. We certainly can’t find that out from a cloud data center.

Packet headers from fitness bands or point-of-sale systems will reveal an IP address, but we don’t know who carried that packet, and if that carrier is trustworthy.

We can’t trust data centers and APIs. A data center is a black box. We know that data went in, and we know that data comes back out. What’s happening inside? Nobody knows. Whether the data center is in the cloud, at a host provider, or inside a corporate data center, there is no way of determining who has access to the IoT data. When we consider the range of IoT applications, from off-the-shelf health monitoring to bespoke instrumentation, it’s impossible to determine exactly which services are back-ending any particular product or service.

Today’s super-interconnected world of APIs (Application Programming Interfaces) adds to the uncertainty. Many cloud applications rely upon multiple cloud providers today, and that number is increasing. Free and paid APIs are increasingly attractive to developers. I predict that within a few years, we’ll find numerous security holes and breaches that were enabled both by cloud-to-cloud transactions and by the use of malicious (or hacked) web APIs.

We can’t protect the border when there is no border. The definition of a network has become increasingly nebulous. Long gone are the days when we could secure the intranet with a firewall appliance. The Internet of Things encompasses devices that would be inside the traditional intranet, but also outside. Homes. Customer sites. Employee smartphones that are on the enterprise WiFi one moment, and outside on WiFi or cellular data five minutes later.

This is the problem in a nutshell: We can’t trust the integrity of the end device’s security. We can’t determine exactly where the data is being processed and stored. We can’t reliably predict how the IoT device is connected to the back end, and what security looks like on those ever-changing pipes. And we can’t even define a secure perimeter to surround the Internet of Things.

The best way to secure IoT is by securing network services. Old approaches of heavy iron rigid security systems cannot be effectively used to provide enterprise grade large scale security coverage in network services due to high cost of deployment and management. SDN/NFV not also solves such high cost issue but also promises a much agile service provision process by dynamically defining the network that connects the IoT end devices to the back-end data centers or cloud services. At first, SDN may be implemented primarily in the cloud or the data center, and then expand to encompass carrier networks. At some point, it even may reach out or into the last-mile network, though that is years in the future.

Where SDN is implemented, Security-as-a-Service can be defined using NFV, providing the service provider with a measure of control and confidence that although the IoT devices can’t be secured, the network can be bound together

into a single virtual network. Forget about fiber, cable, WiFi, cellular data. Think instead of secured VPNs, implemented even where traditional VPN technology isn’t supported.

Here are three specific areas where SDN can assist with in securing the Internet of Things.

1. IoT device traffic can be scanned and secured at the network entry point, no matter where that is. While the IoT device itself cannot be protected by SDN, of course, security can be implemented at the very first SDN-enabled point on the data path. Incoming and outgoing packets can be examined and scrubbed based on deep inspections and corporate policies – not only killing bad packets at the source, but also allowing for countermeasures to deployed from the edge as well – such as knocking a malicious or compromised device (or app) off the network.
2. Policies can specific trusted pathways, and use SDN to enable or disable some type of data traffic based on the weakest part of the link. Health information from a wearable monitor might be too sensitive to transmit over a coffee shop WiFi network. The monitor isn’t smart enough to know that – but SDN-enabled networks can apply such policies.
3. Each network device is a potential security monitor. SDN can allow carriers, cloud service providers and even IoT app hosts to understand the traffic on a per-device, per-user, per-network and per-incident basis — even if the IoT device is blissfully unaware of what’s going on. By using SDN to create a virtual network that extends out to the device, operators can also be alerted to security problems sooner, and be able to respond more quickly.

An excellent slide deck on the subject is by Guofei Gu, Associate Professor at Texas A&M University, “Security as an App and Security as a Service: New Killer Applications for Software Defined Networking?” The presentation describes how the OpenFlow architecture can be used to implement security across the SDN-enabled network, and focuses on the need for Security Monitoring as a Service. The deck also introduces FRESCO, a Framework for Enabling Security Controls in OpenFlow networks, complete with a C/C++-like scripting language that can be used to implement security detectors..”

The Internet of Things is upon us – but we can’t trust the security on the “things.” It’s critical to recognize that the only way to protect users, data and devices is to protect the network. Security-as-a-Service through SDN and NFV is the best path to success.