Smart and secure: choosing IoT devices which shouldn’t compromise your home 4

In the first article in this series, I laid out some questions which you need to ask when selecting a smart device to put onto your network. The second tackled operating systems and their updating, and the third how the device communicates, both within its local network and with the Internet.

Because of the major security issues with allowing incoming connections to your local network, as might be needed to check temperature or control a smart device, the most popular solution is for smart devices to connect outgoing to remote servers, which then act as intermediaries.

If the device is a thermostat, say, this enables you to change its setting whilst you are still at work. Your iPhone, running the vendor’s support app, connects to the support server. Periodically the smart device checks in with that server (using an outgoing connection from your home network, which is secure), which enables it to learn of the changed setting, and warm your home up before you get back in the evening.

As I pointed out in the first article, individual home networks are of low interest to potential intruders, unless the intrusion has another purpose, such as hijacking your network to provide Internet access when driving by, building a botnet, or as part of a planned burglary. A remote server, home to millions of smart devices, is far more attractive to those with malicious intent, as it could yield sensitive information on all those accounts and devices.

How secure is the remote server?

Breaches of commercial servers are commonplace, may pass undetected for some time, and are unlikely to stop for the foreseeable future. If your personal data have not yet been compromised in such an attack, then it is only a matter of time before they are. It is probably wisest to expect that to happen, than to hope vainly that you will be lucky enough not to be so affected.

So the best strategy is to ensure that, should such a breach occur, the damage which you will suffer is minimised: and that depends on what you trust servers with, both in terms of the data which they hold about you and your systems, and how much control an intruder on the server would have over your smart devices.

This may sound excessively pessimistic, but Rapid7’s survey of baby monitors found that 3 of the 6 servers supporting the smart devices which they assessed had vulnerabilities which could be exploited by attackers to gain access to user accounts or devices. Although a small sample of the consumer IoT market, this suggests that there is a good probability that the server which your smart device connects to is vulnerable to attack.

So it is essential that those supporting smart devices provide very clear statements as to what information they do obtain and retain, in their privacy policy. In this respect, Nest’s privacy policy may be long and complex, but appears to contain clear and explicit detail. If the vendor of your smart device falls short, then you should be extremely cautious about putting any trust in them.

You should then think carefully through the likely consequences to you of the unintended disclosure – for example, following a major intrusion – of that information. Most servers will store your complete address, details of the devices installed including their locations within your home – information which could be invaluable to a physical intruder. However the greatest risk following data breach is from remote use of data, rather than physical intrusion. That may change as more people use smart devices to control physical security, though.

One major factor which you do control is the individual security of your server account(s). It is absolutely vital that all accounts for smart devices on remote servers are properly secured using unique and unguessable passwords of sufficient length. Where services provide options for improved security, such as sending email notifications, you should enable them.

How secure are the apps provided to enable you to access the smart device remotely?

It is common practice for the support servers for smart devices to interface with iOS and other apps using a RESTful interface, such as those discussed here. This should make it easy to develop client apps, and to ensure their proper authentication.

However you should satisfy yourself that this is the case, and ponder the consequences if your mobile phone were to be lost or stolen. Would that allow someone to break into your smart devices without having to enter an unguessable password? Could they disable security cameras and unlock your house? If your home is only as secure as your phone, you could be courting disaster.

What vulnerabilities have been discovered and how has the vendor responded?

Most vendors of high technology systems are puzzlingly reticent about informing us about how well they respond to vulnerability reports. That suggests that some, perhaps all, recognise that they need to improve. For example, Apple normally only informs us of known vulnerabilities when they are fixed in a security or other update.

Information about open or fixed vulnerabilities is hard to obtain from most vendors. Nest again does quite well here, with a very clear and informative statement about the Heartbleed vulnerability in OpenSSL.

But this is unusual. Rapid7’s report contains the following chilling comments:
“During the course of the vulnerability disclosure process, we saw vendors exhibit the entire range of possible responses. One vendor was impossible to contact, having no domain or any other obvious Internet presence beyond an Amazon store listing. Some vendors did not respond to the reported findings at all. Others responded with concerns about the motives behind the research, and were wondering why they should be alerted or why they should respond at all.”

The reality is that almost every smart device has had at least one significant vulnerability. If its vendor is not prepared to trust you with knowing how that has been addressed, then you should not trust that vendor either.

In the next (and hopefully last) article in this series, I will give some final tips on choice and use, then look at how some vendors and products perform against these criteria.