The recent Cisco Internet of Things (IoT) grand security challenge is a tacit recognition that the current security problems of the connected world may not be sustainable when scaled to well, to everything. Last year of course there was the well publicized security flaws of Belkin’s WeMo, and the subsequent response is a poster child for what we can expect as the Internet of Things (IoT) turbocharges the the second great crisis of computing, i.e security.
Predictably the corporate response was that ‘yes there were some problems but these have been fixed, so everything’s OK now’. Of course all this says is that the most obvious holes have been patched, but says nothing about how much trust we might put in the remaining code. And with the IoT projected to hit an installed code base of about 20 billion ‘things’ by 2020 that’s an awfully large attack surface over which you need to spread the faith.
Emerging areas will witness rapid growth of connected things. This will lead to improved safety, security and loss prevention.
Gartner Report. Forecast: The Internet of Things, Worldwide, 2013.
So what’s wrong with this picture? Well for starters the existence of a 0day XML injection exploit in the WeMo is an indication that there are underlying linguistic security issues in that case, and you can reasonably infer for the IoT in general. And while these specific weaknesses may have been patched, because of the complexity of protocols the question of whether further vulnerabilities exist remains difficult to answer. Maybe not impossible, depending on where the protocol sits on the Chomsky ladder, but definitely difficult.
Which brings us to the hidden flaw in the IoT. In essence the ‘ideal’ of the IoT is pervasive connectivity. But connectivity requires communication, which in turn requires a common language, unfortunately the more expressively powerful that language is, the greater the vulnerability. Worse yet it’s very difficult to remove such power from an interface once it’s deployed because of the need for backwards compatibility. Couple this to a natural evolutionary pressure for languages of this type to move to a state of Turing completeness, suppliers to go for ‘off the shelf’, read kitchen sink, solutions and you have a slippery slope of increasing insecurity implemented in an exponentially growing code base, and like all slippery slopes it’s very hard to stop once you start down it.
What to do about this? Well for starters not be over awed by the head spinning numbers. We need a concerted effort to revise the core protocols of the Internet via the IETF RFC process to incorporate fundamental language security principles. Next language security needs to be designed in from the beginning and a process for certifying it established. Finally we need to move software engineering from an artisan skill based discipline to one that is theory and evidence based.
And that’s my entry for the Cisco challenge.