So what’s the problem? For starters, as vendors scramble for their share of the market, they cut corners or completely ignore cybersecurity, exposing the rest of us to identity theft, internet downtime and privacy breaches. Some military cybersecurity experts believe that IoT botnets could be used as weapons, even triggering a distributed denial-of-service (DDoS) arms race.
This problem is compounded by IoT’s extreme price sensitivity. To add IoT to, say, utility meters, vending machines and smart-building sensors, the hardware must be as inexpensive as possible. That’s typically achieved by putting just enough memory and processing power into the IoT module for it to perform its tasks, with little or no resources left to support traditional cybersecurity tools such as anti-malware software. This design enables headline-grabbing attacks such as the one in September 2016, when hackers yoked together millions of surveillance cameras, DVRs and other IoT-enabled devices to launch the biggest DDoS attack in history.
This problem is further compounded by the fact that IoT frequently adds networking and other IT capabilities to devices that traditionally haven’t had them. A prime example is modern cars and trucks, which now average a million lines of code across 60 IoT devices controlling everything from emissions to infotainment. Their owners must now periodically update the firmware in those devices to patch security holes—assuming that they even know about this new responsibility, let alone take it seriously.
And that’s assuming the patches and updates even exist. IoT’s low-cost requirement means thin profit margins, which in turn mean little financial incentive for vendors to keep developing patches and updates for products that were sold years ago. Cars and utility meters are two examples of products that typically remain in use for at least a decade. How many of their IoT modules will be orphaned as their vendors stop supporting them, go out of business or are acquired?
When that happens, those modules become even more vulnerable as back doors for hackers—not only into the application that a particular module supports, but also all of the other systems it connects to. An example of the latter is an attack that uses an orphaned IoT module in a truck to access the fleet owner’s database of routes and cargo to enable hijacking of high-value shipments.
Losing the human touch
The stakes are even higher with autonomous IoT, where devices communicate directly with one another, with no humans in the loop. There are easily thousands of existing autonomous IoT applications and millions of potential ones. One example is self-driving delivery vehicles that go all day without a human behind the wheel, because they interact with sensors in smart roads to know where they’re going.
When humans aren’t monitoring those interactions, there’s increased risk of security breaches. For example, sensors could be automatically collecting information about the load in an electrical grid, but it’s up to a human to decide whether and how to act on that information. Take the human out of the loop, and it’s much easier for malware to take charge, such as to cause blackouts or surges.
Even when there are humans in the loop, unique and unexpected attack vectors exist. One example is side-channel attacks on fitness trackers worn on the wrist. If the person uses that hand to type a password or PIN on another device, a hacker could use the fitness tracker’s movements to recreate that information. This scenario also is another example of how IoT creates back doors into other, traditional IT systems.
Best practices for a new paradigm
Regardless of whether a particular IoT application is autonomous, it’s critical that everyone involved with that application—the vendors, the service providers, the end users—understand those unique considerations and develop strategies for maximizing security. The first step is to acknowledge that practices and policies that are effective with non-IoT technologies—such as installing anti-malware software on servers or laptops—often aren’t applicable to IoT.
IoT requires a different approach to security. That’s why the IEEE Internet Initiative recently published a white paper with a set of best practices that anyone can use to improve the security of IoT applications. Available as a free download from the IEEE Internet Initiative, these best practices are applicable to any IoT application, regardless of the industry or whether it’s autonomous. IEEE will host a related webinar, “IoT Security Best Practices,”on Sept. 27, with a recording available soon after.
One best practice recommendation is to limit the amount of bandwidth available to each IoT application: “Most IoT devices are made of commodity components that have vastly overpowered network capabilities for the function they are supposed to perform causing congestion on home networks and potentially contributing to huge costs for the targets of IoT-borne DDoS attacks. We recommend that device manufacturers should limit the amount of network traffic IoT devices can generate to levels reasonably needed to perform their functions. There is very little need for an internet-connected refrigerator to spew Internet Control and Management Protocol (ICMP) messages at gigabit-per-second speeds. While some refrigerators are outfitted with video screens, they more than likely do not need to have high-speed upload capabilities.”
Just as important, these best practices are described in lay terms, so they’re understandable by more than just IT security gurus. That accessibility is key because IT experts aren’t the only people who have a hands-on role with IoT applications. For instance, a building facility manager could use those best practices to ensure that IoT devices for maximizing energy efficiency don’t create security and privacy risks. If everyone—from manufacturers to end users—does their part, hackers will have far fewer opportunities to ruin the bright future that IoT enables.