Consumer IoT manufacturing – what could possibly go wrong?
By Ken Munro, Director Pen Test Partners
In terms of innovation, companies that make IoT devices are leaders, almost by default. They speed their products to market to fix problems that many of us didn’t know we even had. They give consumers the ability to feel that they are in some way “at home” whilst being far from it, and they tell compelling stories about the benefits of having a connected lifestyle.
Like so many manufacturers they deal with issues of complex design, have scalable production and marketing processes, and are often involved with and dependent upon multiple partners. In common with legacy physical products, the IoT production process can be a long and painful one, from securing funding to hitting targets to achieve time-to-market: the manufacturer needs to meet shipping deadlines, shareholder expectations, and peak sales periods, all while keeping down costs.
App development, marketing and hosting will often be carried out by third parties. IoT start ups are fast moving, so large in-house teams are rare. Outsourced developers may not have the same understanding of security that the vendor might expect. That’s if the vendor even thought to ask a question about secure coding standards. Speed to market and lowest cost do not lend themselves to high quality, secure mobile apps! An insecure mobile application used to control an IoT device is a common source of compromise.
The very thing that makes them innovative is also a potential Achilles heel. Once a device is controllable over a network it can become so much more than it was created for. Take the humble Wi-Fi kettle for example. As well as boiling remotely it can also be subverted to give up the owners physical location and Wi-Fi network credentials, and you can guarantee that particular functionality was not an intended feature.
If we go back to the production process it’s clear that many manufacturers simply aren’t geared to build-in the ability to make post-hack security changes to devices. They either don’t know about the risks that IoT devices present, or they disregard them. If a device can be compromised there’s the problem of product updates or recalls. The sheer scale of numbers involved and the implications for their stockists make can coming clean a daunting prospect.
Think about it; a researcher approaches an IoT manufacturer and informs them of a critical security issue. Do they stop production, fix it, re-release after a delay, then miss Black Friday, the Xmas season and implode through lack of sales? Far more likely that they have to carry on shipping, either hoping the problem will go away or can be resolved later.
Where Over The Air updates can be made this is far less of an issue, all it takes is for the update to be pushed out OTA and the issue is remedied. But when that is not an option how do you explain to an established retailer, with their own brand to protect, that their gamble on your IoT device could cost them dear because consumers could soon start bringing back the product in their droves?
OTA updating brings its own challenges though. Does it encourage complacency with security? ‘It’s OK, we can fix bugs later’ rather than ‘get it right first time’ although it’s tough for any developer to write code that defends against all current and future security issues.
So if neither the device manufacturer nor the associated third parties are looking at security, who is? What is really needed is some form of standardisation such as a variation of CERT perhaps with specialisation for key sectors (e.g. domestic, automotive, medical etc.) or some hardware-specific adaptation of the well-established OWASP guidance.
And until then, security researchers and hackers will have a field day, uncovering security bugs in IoT devices.