In 1978, NASA scientist Donald J. Kessler proposed a theory about what could happen when the number of objects in low earth orbit reached a certain high density. Once that threshold was reached, he posited that collisions between those objects would be inevitable. Even a chip of paint could be enough to crack the window of a space shuttle. This would trigger a cascade effect: the more collisions, the more debris; the more debris, the more collisions. The result? An atmosphere so clogged with junk that it would set back space activity by decades. Man would become trapped, unable to deploy satellites or explore space. The parallels to be drawn between Kessler’s theory and today’s IoT security challenges are all too worryingly obvious.
What if we bring this back down to Earth and replace those orbiting objects with embedded IoT devices that are connected and lacking an appropriate IoT security framework? Should we be worried that the Kessler effect threatens the future of the internet itself?
Compromised devices like security cameras, home routers and DVRs have been proven to be part of the Mirai botnet used in the two biggest distributed denial-of-service (DDoS) attacks in history. In September 2016, the world’s largest DDoS was directed against the website of cybersecurity journalist Brian Krebs. It involved more than 620 Gbps of traffic, and was the biggest DDoS ever seen at the time. Then, just a week later, a DDoS that was 40% larger than the Krebs attack took down OVH, a French web hosting provider.
Build-a-botnet at IoT scale
To create something capable of generating those levels of traffic, you’d need a huge botnet of compromised devices. In the past, botnets comprised thousands of infected PCs, but with IoT, the issue of scale changes completely; there are many millions more unattended IoT devices out there. Estimates vary, but even the lowest figure from Gartner suggests 6.4 billion connected devices right now, not including PCs and smartphones.
The difference is that most people use their PCs most days. Many users would notice something was wrong with their machines, so they’d patch, reboot or update, and those PCs would drop out of the botnet. This made it hard for attackers to build botnets that stayed big for long.
But unlike PCs and smartphones, the deployment model for most IoT devices is set-and-forget. After all, who’s paying close attention to their IP camera that’s keeping watch on a holiday home, or a cheap digital video recorder bought from a furniture store?
Many of these devices have unfettered internet access; this connectivity makes them attractive to hackers while their lack of an IoT security framework makes them easy to hijack in large numbers. Once fully armed and operational, the result is a weapon to be pointed at a target of choice, denying them usage of the internet.
Whose IoT security is it, anyway?
Here’s another difference between IoT and the PC/smartphone paradigm: low-power, embedded software devices that are field deployed, potentially for years, don’t fit the patch-monthly approach that has built up around “human interface” devices. Just as IoT sensors are seeing potentially longer lives, their manufacturers are seeing shorter lives: products, divisions or even entire companies merge, fail or change direction. This “orphans” devices that go from being rarely patched to abandoned — yet they’re still out there.
Responsible manufacturers of cellular gateways are releasing notes to say “patch this” or “upgrade this,” but plenty of others don’t. No one vendor or ISP or government can solve this problem. It’s not sufficient to mandate standards or legislate against security vulnerabilities. Every stakeholder in IoT needs to consider the risks inherent in legions of well-connected devices swamping or — as is more likely — balkanizing the internet.
One positive step to addressing this issue is at the access network. We believe IoT device connectivity needs to move from a default open state to a rule of least privilege. Instead of that embedded IP address talking to a system it isn’t supposed to, or shouldn’t, it’s only granted minimum access, like talking to three designated endpoints in order to perform its function.
Another approach is a layered defense in depth, albeit inverted from the usual defending from outsiders. Where IoT devices utilize a home gateway or router, let it be a different SSID or VLAN that can be controlled. If on cellular, make sure that custom DNS and IP ACL controls are available to ensure that access is available to only the necessary APIs or endpoints.
In the worst case, we’re looking at a classic Tragedy of the Commons. But if no one stakeholder can fix the problem of the absent IoT security framework, the very least we can do — for now — is not to make the situation worse.
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.