Problem solve Get help with specific problems with your technologies, process and projects.

IoT requires a new security paradigm

For computing, security has traditionally been an endpoint game with antivirus protecting the desktop and intrusion detection on the server, monitoring for suspicious activity and alerting when it detects anything. Today, the endpoints have evolved to be a multitude of different devices connected to the internet in what we call the internet of things. They range from thermostats and security cameras to refrigerators and smartphones, and they aren’t designed to be standalone computers that can run endpoint protection software. We need a new security paradigm in the age of IoT.

For example, the Mirai botnet targeted networked devices, like IP cameras and home routers, that are running outdated versions of Linux. The malware infected the devices through security holes that result from default settings in the devices and turned thousands of them into a botnet that launched huge attacks last September and October, temporarily shutting down a number of high-profile sites like Twitter, Netflix, GitHub, Airbnb and Reddit. There are still hundreds of thousands of devices that are vulnerable to compromise and more coming on the market all the time.

Often we can’t just put antivirus or other malware-alerting software on those IoT devices though. They have scarce resources like CPU, storage and memory, and in many cases lack a typical operating system. For the end user, even if it’s running Linux, the device may not allow shell access, which would enable people to install arbitrary security software on the device. For example, with a Linux-based thermostat, you can’t just log in and set up antivirus on it and manage it. Attackers, in contrast, leverage exploits to gain shell access and install their code. When an owner does this to install their own software it’s typically called “jailbreaking” the device, and it may be an option for some scenarios. There may emerge a market wherein these jailbreaking methods are used to secure the device by their owners.

The market for IoT operating systems extends far beyond Linux, however, and includes Windows IoT, Zephyr, RIOT, Brillo, Nucleus RTOS and more — it’s truly in the explosion phase, with dominant players sure to shake out the next decade or so. Each of these operating systems presents a unique set of opportunities for security, as well as challenges. Very few of them, however, have security monitoring built in. Like anything else, IoT platform “security by obscurity” works until it doesn’t.

The consequences of failing to secure these IoT devices are great and go way beyond just botnets. With IoT, failure modes can manifest themselves in the physical world. In an enterprise we increasingly see HVAC systems connected to the internet (the compromise of a HVAC vendor is what led to the big data breach at Target four years ago). In the Target case, the attackers used the HVAC system as a conduit to get to Target’s network and customer data. Compromising an HVAC system could give attackers a way to interfere directly with an enterprise environment. Access control systems, which prompt employees to swipe a card or provide a fingerprint to get into an office, are also increasingly internet-connected. One can easily imagine malware that could lock people in or out of a building.

There are only a handful of options available today for IoT device security. In many cases you can’t run endpoint alerting tools as you can on desktop. One of the challenges is that you might get a notice that the IP address for your webcam appeared on an IP reputation list, yet you still have to track down which device it is and identify what to do next.

The challenge is we need to do security monitoring as close to the device as possible without doing it on the device. But how do we do that in this specialized IoT environment?

Evaluation and purchase

When reviewing IoT devices, their security should be a primary concern. Because of the different way they’re managed — often at the mercy of the original vendor and not the administrator — security review questions matter even more. Questions to ask include:

  • Does the vendor offer security updates? If so, how are they delivered?
  • What is the supported lifetime of an IoT device?
  • What is the track record of the vendor’s device security?
  • How will the vendor notify me of an update? How easy can I install it on a fleet of devices?
  • What kinds of security controls does the device have? Is its baseline configuration secure? Did the vendor follow any security guidelines when building the device?

With traditional IT equipment like laptops and servers, these are valuable questions but the administrator has a lot of control over the device security. For an IoT device, however, that control is often stripped; making these questions prior to purchase is significantly more important. Remember, you’re likely putting a device in the network that can lower the security of the network, treat it as you would any risk you have little control over.


When thinking about a network of high-value resources and reduced-security resources, a natural reaction is to segment those two groups. They also serve distinct business functions, further strengthening the argument to segment the traditional network and the device network. Admins should segregate business-critical IoT devices into their own network that’s not accessible from the open internet or the corporate local area network even. There is no good reason for the devices to be accessible to others. This is standard network architecture advice, but has increased relevance with IP-enabled devices.

Segmentation should be physical if possible, with a logical segmentation as a fallback option. A physically distinct network for IoT devices will ensure they can’t work unless they’re connected to the right network and prevent accidental exposure to the open internet. A logically distinct network would utilize VLANs, network addressing, routers and firewalls to isolate devices into their own network.

The goal of this segmentation is to minimize the risk to the rest of the network posed by devices with lower security guards in place. In their own network, if they’re attacked, these devices won’t enable pivoting to servers and other high value resources. This network segmentation will facilitate monitoring, as well.


Admins will still need the IoT equivalent to firewall logs. They need to track all traffic to and from the devices and look for oddities and see what traffic has been trying to talk to the devices, or worse, what servers the devices have been trying to talk to, such as a command-and-control server used for controlling botnets. As with any log monitoring effort, they also need to review the logs for oddities and follow up on those interesting hits.

There are management devices that have a very concrete set of users and use cases, but you can lock them down. These are special-purpose devices so they’re not doing random things. Utilizing the logs for IoT devices is far easier when compared to a laptop or a server because the number of devices it talks to is small, so you look for deviations. For example, the only connections to it should be from a small pool of management nodes, not the outside world. IoT devices should only initiate contact with a small handful of local systems. Similarly, the kinds of traffic it sends should fall into a narrow category, for example measurement data.

These are only stopgap measures. There is only so much admins can do, and consumers have basically no capability to secure their devices beyond changing the default settings and passwords to lock the devices down more. We need the industry to step forward to help solve this problem.

Industry efforts

The National Institute of Standards and Technology (NIST) just last winter developed a framework that tries to consolidate and develop good guidelines for IoT security. There are also a handful of specialized consortiums trying to address the IoT security issues, but those are focused on specific devices or use cases and aren’t applicable more broadly.

There is also some exciting DARPA-funded research that seeks to externally monitor IoT devices by looking at their power consumption. When there’s a spike on an IoT sensor or it’s acting abnormally, that could signal a security incident. Although this research is early stages and not likely to wind up in technology any time soon, some of these concepts have been around for a while, for example monitoring power usage or vibrations.

Eventually, we will see IoT cybersecurity solutions from vendors, such as an IoT firewall. Vendors will have a pretty good set of guidelines for a device to be secure, either based on the NIST framework or those other third-party groups such as the Cloud Security Alliance and the IoT Security Foundation. But the complexity of setting up the network will still be a huge challenge for many admins and most consumers. We can’t have default passwords or allow certain devices access to the internet. We will need a security paradigm with a combination of special user and administration policies geared just for IoT.

All IoT Agenda network contributors are responsible for the content and accuracy of their posts. Opinions are of the writers and do not necessarily convey the thoughts of IoT Agenda.