How to prevent IoT-based Internet outages: #2 Floodgate
Recently, I started a mini-series of columns relating to creating a secure Internet of Things (IoT), or an Internet of Secure Things (IoST) as the folks at Icon Labs would say (see also How to prevent IoT-based Internet outages: #1 SynthOS).
As you may recall, this all started with the massive cyberattack on October 21, which disrupted Internet service across Europe and the US. In this attack, malware took over more than 500,000 under-secured IoT devices -- like surveillance cameras -- on the edge of the Internet and used these devices to mount a concerted distributed denial-of-service (DDoS) attack that brought down some of the most popular sites on the Internet.
I was just thinking, I wonder how much one of those surveillance camera systems would have cost before the cyberattack? I also wonder what they are selling for on eBay and Alibaba now (can the manufacturer even give them away)?
Earlier today, I was chatting with Alan Grau, the President and co-founder of Icon Labs, which is focused on creating the IoST by providing security for even the smallest IoT devices. We started by considering my previous column, in which I said:
Security must be present end-to-end throughout the Internet and must cover both hardware and software. One problem is that, although a lot of effort is going into securing the core of the infrastructure, more and more functionality is being pushed out to "the edge" of the Internet in the form of the IoT devices themselves.
Alan responded by showing me the following graphic, which depicts the way in which Icon Labs visualizes the computing landscape:
(Source: Icon Labs)
Happily, Alan and I agreed that we were saying much the same thing in different ways (it would have been a bit awkward if we'd each decided that the other was completely barking up the wrong tree). Alan then showed me another graphic that gave me pause for thought:
(Source: Icon Labs)
We start with the security on the device itself, which includes things like the ability to perform secure boot and to ensure that any instructions it is given are coming from a trusted authority. In the case of the devices used in the cyberattack mentioned above, this level security was almost non-existent -- or at least, largely irrelevant -- in that any security that was present was riddled with loopholes and backdoors.
The next step up the security chain is security management. This covers a range of activities, from the ability to remotely (and securely) upgrade any security features such as firewalls, to the ability for the devices to detect that they are under attack and to report details of such an attack to a "higher authority."
Next, we find key and certificate management, which includes the ability for the "higher authority" to push credentials down into the devices, where these keys and certificates are used by the devices to ensure that they are communicating with trusted (and uncompromised) hosts, and by the hosts to ensure that they are talking with legitimate (and uncompromised) devices.
Everything we've discussed thus far is encompassed by Icon Labs' Floodgate Security Framework, which provides a full suite of device protection, secure credentialing services, and integration with IoT cloud services. In addition to secure credentialing, the Icon Labs Floodgate Security Framework includes secure boot, secure software updates, firewall, intrusion detection, TLS, and a management agent.
(Source: Icon Labs)
The folks at Icon Labs are now turning their attention to the topic of device lifecycle management. To be honest, much of this wasn't something I'd thought much about before, but I'm certainly thinking about it now. It starts with the manufacturing of the devices to ensure that there's no possibility of them being cloned and/or introducing back doors or other security breaches into the devices before they've even left the factory.
Device lifecycle management also covers devices being deployed for the first time, followed by subsequent re-deployments as they are moved around the world, possibly being passed from one owner to another. Finally, lifecycle management covers the decommissioning of the devices, including the removal or destruction of any sensitive information stored within, such as data, encryption keys, security certificates, and so forth. (I remember hearing that the hard drives in discarded photocopiers from doctors' and lawyers' offices typically contain humongous amounts of extremely sensitive information.)
One thing I've gleaned from all of this is that implementing security into one's IoT devices is absolutely mission-critical; another thing is that it's not trivial or for the weak of heart. Fortunately, embedded systems developers don’t have to reinvent the wheel and do everything themselves -- there are robust solutions already available, such as those from Icon Labs.
How about you? What level of security are you implementing in your own embedded systems? Do you create these security systems internally, or do you use third-party vendors? And do you have any information you'd care to share regarding any security-related IP, tools, techniques, and vendors, including any disasters, close-calls, or triumphs?