This past October felt as if someone had called open season on IoT devices. One of the biggest headlines surrounded Reaper, the latest in a long line of botnet attacks designed to infect and mobilize countless connected devices by taking advantage of known vulnerabilities. Reaper was initially reported to be among the worst instances of a botnet ever seen, and while later investigation may have found those early suggestions to be a bit hyperbolic, the fact remains that Reaper still infected over 28,000 devices – spanning webcams, DVRs and security cameras – and is capable of infecting up to 2 million.
Just days earlier, KRACK was also making headlines for its scarily effective brute-force tactics in breaking Wi-Fi encryption “handshake” protocols and allowing its attackers to eavesdrop on any traffic being sent along Wi-Fi networks. Unlike Reaper, which goes after devices, KRACK took a different route in attacking the information – credit card numbers, bank account passwords, login credentials – being transmitted wirelessly between devices and across networks.
Both of these attacks illustrate two sides of the IoT security coin. Whether it’s the device or the network the devices live on, the fact remains that making our devices smarter is increasingly putting them and the information they store more at risk to thieves, hackers and criminals. And, it behooves all IoT users – from the developers to the manufacturers to the consumers – to get serious about protecting themselves on both fronts with these three common sense steps.
Step One: Assume the worst about your device’s environment
All IoT device security should start with a common baseline belief: that the environment that the device will be deployed in is inherently unsafe.
Networks can be hacked, and no amount of individual device security can circumvent that. It’s simply out of the user’s or engineer’s control. So, instead, the devices themselves need to be viewed as the first, last and best attempts at bolstering IoT security.
The operating system is critical to that approach. Leveraging a device’s OS for stronger security starts with making that OS simpler. Simplifying OS architecture means reducing the strain of CPU processing, storage and memory capacity. But, it also means reducing overall vulnerabilities. The simpler an OS is, the less it’s exposed to threats that can capitalize on overly complex designs for success.
Step Two: Streamline and prioritize updates and rollbacks
Securing IoT device operating systems also means thinking about the future; not just how secure the device is when it’s first rolled out, but how easily it can be patched in the event of future threats.
The shelf life of these devices is going to be incredibly long, running years, if not decades. Having devices that have not, or cannot, be updated to counter future attacks as they emerge, and leaving these unprotected devices out on a network, opens up more points of vulnerability for hackers to take advantage of.
A simple, centralized mechanism for releasing updates is an absolute priority. This ensures that patches are not only deployed quickly and efficiently, but can be implemented in devices whose user interfaces may not lend themselves well to easily downloading those updates.
Likewise, it also needs to be easy for these updates to be rolled back and the device restored to its last best configuration, in the event that a patch inadvertently compromises a device’s normal functioning. Otherwise, automatic updates could end up leaving devices not only unsecured, but altogether useless.
Step Three: Implement isolated app containers to limit scope of attacks
Restricting applications to self-contained sandboxes can help to mitigate the damage in the event an app is compromised in some way. Containing and isolating apps limits the scope of attack vectors if the application layer is compromised on the device. Mandatory access control is a critical part of this approach.
It’s important, however, to draw a distinction between containing apps and taking a completely ‘walled garden’ approach to device security. Minimizing the spread of infected apps shouldn’t, and doesn’t have to, override the overall open source nature of the device. Open source, after all, is the heart of the innovative spirit that has driven the IoT from its beginning, and this shouldn’t be glossed over in the pursuit of better security.
At the end of the day, there’s no foolproof method for IoT security. New vulnerabilities will always be found in the technologies used for devices, networks and security protocols. There will always be some vulnerability, somewhere, that nobody thought of until the day that it’s exposed by opportunistic cyber attackers, as we just saw with Reaper and KRACK. The most and best anyone can do to keep the IoT as safe and secure as possible is to remain constantly vigilant about new threats, and make it easy and intuitive to deploy updates and patch security holes as soon as they appear.
[su_box title=”About Mike Bell” style=”noise” box_color=”#336588″][short_info id=’104083′ desc=”true” all=”false”][/su_box]
The opinions expressed in this post belong to the individual contributors and do not necessarily reflect the views of Information Security Buzz.