Seeing past the fear, uncertainty and doubt surrounding IoT security

September 29, 2016 Facebook Twitter LinkedIn Google+ Uncategorized



Kevin Holbrook

Momenta Partners’ Kevin Holbrook discusses tried-and-tested strategies for mitigating novel IoT security threats.

There’s currently a significant amount of Fear, Uncertainty and Doubt floating around the Connected Industry and IoT universe. Much of that ‘FUD’ centers around recent well-publicized exploits, including the BMW Wi-Fi exploit in Europe and the revelation that NEST was sending zip codes in plain text. But, as with most FUD, it’s largely a lack of understand that has nurtured the seeds of doubt.

To help us understand the real state of IoT Security, let’s explore the attack surfaces (the combination of different attack vectors or routes by which a hacker might attempt to access a computer or network) that IoT might introduce and ways to mitigate these unique risks.

IoT attack surfaces

Due to their “connected” nature, all IoT solutions expose a variety of attack surfaces: at the edge (where devices generate data), in transport (the communication channel used to move that data) and in the cloud (where servers receive that data and allow remote users to interact with the devices at the edge). Each of these attack surfaces provides a possible avenue for exploitation and needs to be evaluated so appropriate remediation strategies can be applied.

When companies expand their traditional environments to include IoT technology, they need to be aware of these new attack surfaces before they’re introduced as part of the IoT solution. After all, planning for exploits as the solution is being implemented will go a long way toward keeping that implementation out of the news.

In the next sections, we explore security at the edge, along the networks that transport data from there to the cloud, where those networks meet the cloud and deep inside the cloud, at the cloud platform.

Securing the edge

Local physical data connections and local wireless connections such as Wi-Fi and Bluetooth are two key attack vectors found at the edge. By connecting IoT hardware (such as an IoT gateway) to a sensitive installation, a potential avenue is created for an intruder to gain unauthorized access to data or communications, or even to interfere with equipment within that installation.

The best way to mitigate this risk is to limit the capabilities and access given to the connected hardware to the bare minimum it needs to function. Building up from that limited, locked-down capability set, Identity Management and communications hold the key to securing the edge.

smart home summit banner

The identity of any edge device also needs to be confirmed to ensure data is not coming from a malicious imposter device. This identity should be obtained from the hardware directly whenever possible, rather than from an easily replicated configuration file.

Unfortunately, if the device does not have a known and stable IP address, it’s not always possible to ‘reach out’ to the device to validate its identity. Common strategies for identifying a device with an unknown or short-lived IP address include:

  • Reading the device Identity from within its message request
  • Using client certificates obtained either from the hardware itself, or installed on the device

While device identity is one key component of Edge Security, making sure the communications path is secure is also crucial, as we saw with the BMW Wi-Fi exploit. It’s vital that the communications from these devices is encrypted (both the payload and the transport independently) to ensure the traffic can’t be sniffed or spoofed.

Securing the cloud surface

Where the edge first meets the cloud, the flood of traffic flowing in from the fleet of IoT devices looks and feels very much like an attempted Denial of Service (DoS) security exploit. Proactive steps are needed to ensure the cloud’s infrastructure can differentiate valid connections and data from possible intruders so it doesn’t interrupt communications unnecessarily. Firewall configurations can be tweaked to ensure only valid connections from IoT devices are allowed in.

Sometimes real-world devices can go ‘rogue’, generating data constantly because of a misconfiguration, an unexpected condition that has triggered a loop or even a malicious attack on the device. Ensuring these devices are ‘muted’ promptly to prevent a flooding of the edge is crucial. While protecting against these, it’s also important to note that many connected devices experience message drops and retransmissions resulting from unpredictable communication channels.

Related articles

The cloud front-end must account for all of these possibilities.

Security cloud platforms

One set of attack surfaces at the cloud layer emerges when a new IoT device first introduces itself to the cloud platform. This process is generally referred to as ‘registration’ and sees the cloud platform create a virtual representation of the device in response to some external action. The most secure registration and provisioning processes incorporate the identity of the new device into the cloud platform before any traffic from that device ever reaches the IoT environment. It’s important that the following processes are properly defined and secured:

  • Provisioning: the configuration of the device with its identity, the cloud endpoint it will communicate to, etc.
  • Registration: the flow of events that take place when a device first communicates with the cloud platform
  • De-commissioning: the flow of events when a device is no longer in use and needs to be reclaimed or destroyed

In addition, many IoT installations don’t give sufficient care to ensure user groups and roles have appropriate levels of privileges. By default, many users are able to see and do too many things. This is particularly true with API based consumers. The ideal solution gives users the minimum privileges they require and adapts these based on the status of the IoT environment. Engineers, for example, may only be able to monitor healthy systems, but would have their access expanded so they can intervene if a system develops a fault.

The access privileges of external APIs and web services need to be managed carefully too as they could be exploited to, for example, create a denial of service scenario by requesting large volumes of data and reading that data slowly from the cloud’s memory. The trick here is to limit the volume of data and number of parallel requests allowed from a given external source.


I hope I have helped you appreciate at least some of the attack vectors and attack surfaces that IoT might introduce and that there are solutions available to every problem that arises in IoT. After all, your business may find itself lagging behind your competitors if you allow the fear of new risks limit your adoption of this game-changing technology.

Hear Kevin Holbrook talk more about the facts surrounding IoT’s unique security challenges and the proven strategies for mitigating them.

Attend Momenta Partners’ ‘Taking Control: Beyond the IoT Security Hype’ webinar on October 13, 2016, co-hosted with Rob Black, Sr. Director of Product Management at PTC/ThingWorx. 

IoT Security Summit 2016

We’ve secured a generous 20% discount to attend IoT Security Summit in Boston for all IoT World News readers! Just use code IoTWN20 when you register to secure your discounted place.

Register now >>