The Internet of Things
The “Internet of Things” (IOT) is the newest “thing” in the tech world, and broadly describes the interconnection of everyday devices through the internet. This can include anything from temperature monitors, Tesla sensor suites, and Bluetooth water bottles. Since the potential applications are so diverse, the population of IOT devices is rapidly expanding and is poised to explode over the next few years. 2016 estimates already set the number of IOT devices at 6.5 billion. By 2020, ABI expects a quarter million connected cars and 40 billion IOT devices, while Gartner predicts the emergence of a $300 billion market for IOT-based products and solutions.
However, there’s a price to such rapid growth – in the rush to connect anything and everything to the internet, dangerous compromises are being made. Build quality and actual practicality (e.g. the aforementioned Bluetooth water bottle) come to mind first, but more important are aspects of system design: networking, architecture, data management, and especially security.
Of course, the first question to come to mind is “Why should I care? What malicious use would someone have for my smart outlets, or Wi-Fi thermostat, or remote-controlled lights?” This mindset, on the part of customers and manufacturers alike, is leaving millions of everyday products vulnerable and ripe for abuse. More important, however, is the weakness of our current approach to “cybersecurity.” Traditional methods of security architecture and implementation, as well as conventional wisdom regarding threat modeling, leaves us unequipped to deal with this unique and ubiquitous attack vector.
The concept of “security”
To begin, implementing “security,” even in abstract, is difficult, since it’s a “negative goal.” If we wanted someone to be able to view or update a certain file, this is a “positive” goal – we are building the capability that would enable this, targeting a specific entity, with a definite end state (the user has access). Restricting access, on the other hand, is a “negative” goal that opens us up to a host of problems. First, there is no longer a specific “target” we are aiming to combat – there are an infinite number of adversaries and threat vectors to consider, and while the end state is defined (prevent circumvention of our restrictions), the security of our device and our system requires that this not be possible no matter what.
The issue with IOT is two-fold. First, the prevailing philosophy in tech is to design around user-friendliness and having plenty of features. However, the saturation and complexity of these features makes designing an effective security architecture without vulnerabilities impossible. IOT is particularly at risk here, as the nature of these devices is to expose themselves to as many outside actors as possible (other sensors, other devices, other users) in the name of connectivity.
For example, the UPnP protocol (Universal Plug and Play) employed by many IOT devices will automatically open a default set of ports through the user’s router, to allow the device to communicate with the wider internet. To be fair, this is required for the device to actually function– a device that can’t communicate with anything else is useless – but is done automatically and without notification. Even if permissions were switched to manual command, most users if prompted would probably just click “OK.” This interconnectivity can also be capitalized by attackers, by turning any one device into a pathway to any other. Your stuff may be secure, but your neighbor may still be using default settings. Once he’s compromised, it’s relatively simple to spoof his credentials in order to access the wider network of similar devices.
Second, attackers employ a different mindset than most IOT developers and architects. A common approach is referred to as the “patch and pray” method – a developer will focus on building functionality, and using successful attacks on your system to identify specific flaws which can be fixed post-mortem). Attackers, however, tend to take a more holistic view of a system, attacking any and all components and interfaces available. IOT provides them with exponentially more attack vectors. For a particularly relevant and recent example…
In the early hours of October 21st, 2016, the Mirai botnet (or rather, a particular botnet built on the Mirai framework) surged to life, launching a series of DDoS attacks on Dyn’s Managed DNS service, disrupting access to many of the internet’s most popular and heavily trafficked sites. On a technical level, the previous “first place” for DDoS throughput ran about 650Gbps, using a DNS reflection method, but Mirai averaged around 1.2 terabits. A post-mortem analysis revealed the unique method behind the attack: of the tens of millions of enslaved IPs, a vast majority of the DNS lookup requests came from sources like printers, security cameras, routers, and baby monitors – in other words, some of the most common IOT devices.
Mirai is so effective because it capitalizes on the economy of scale surrounding IOT devices – manufacturers often don’t assign unique access credentials to each of the many device they create (e.g. the common “admin/admin” logins on many routers), but rather rely on the end user to implement their own security measures. Mirai operates by scanning the web (mainly via Telnet and SSH) for devices using these factory-default or hard-coded credentials, by which they are accessed and co-opted into the botnet.
What can we do about it?
Though there are any number of security “solutions” that can help mitigate a wide variety of problems, a better reaction would be to change industry and user best practices surrounding information security. Broadly, architects should move away from a reactive, “post-mortem” strategy and adopt a more holistic mindset: security is a property that cannot be done well when isolated to a particular component or layer, but must be a system-wide, architectural concern (a “security-by-default” approach). Three primary keys to developing an effective security architecture are prevention, resilience, and detection and recovery. Prevention is the idea of making the job of an adversary more difficult by way of design mechanisms. If this is not or cannot be the case, a system should be designed for resilience, meaning it can still remain functional (in some form or another) despite ongoing attacks. Common methods for boosting resilience include a restricted Trusted Computing Base, encrypted computation, or specialty architecture (e.g. an “ascend” processor, a hypothetical processor architecture by which private data remains secure when accessed by arbitrary third-party programs). However, if all else fails, be prepared for detection and recovery – diagnose and repair the damage as soon as possible, and have contingencies in place for data recovery and business continuity.
The above are just some thoughts on the challenges facing the IOT sector moving forward, and hopefully inspire you to conduct some independent investigation and delve deep into what keeps you and your data safe behind the scenes.