Securing IoT devices

From time to time, I feature guest blogs from colleagues in Mentor or elsewhere. This week I am pleased to share some very topical writing from Ayan Pahwa, who is an Embedded Software Engineer at the Mentor facility in Noida, India. Ayan is concerned about the security implications of very wide use of IoT …

I used to believe that the only possible way to secure oneself in cyber-space is to disconnect from it, which is not an option in the era of the Internet of Things. Whether it is a small embedded device continuously sending data on your activity to a cloud service, or a smart home assistant continuously listening to your voice commands to control the home appliances, IoT devices have become part of our way of life and there is no disconnect button.

AT&T’s Cybersecurity Insights Report surveyed more than 5,000 enterprises around the world, and found that 85% of them are in the process of or intend to deploy IoT devices. But less than 10% feel confident that they could really secure those devices against hackers. One reason could be that security in IoT world must be made available at every layer, from hardware to communication to cloud, web page, mobile app etc. This adds to effort and cost and increases time to market and ends up being ignored.

An average consumer has a wide choice of devices readily available off the shelf:

  • they can completely rely on smart baby monitors to watch their baby, giving them a live feed of the cradle even when at work
  • they rely on their garage door opener to welcome them as they arrive home from work
  • smart thermostats to greet them with balanced warm showers in the morning
  • blood glucose monitors are smarter and connected, to send your latest sugar levels to your doctor, as soon as you measure it, so that he can best track your diabetes

This is all very smart, is it not? But with great power comes great responsibility, and this is true for the world of consumer IoT devices. What can hackers can do with these devices if they get access to them? They can monitor your home live with those baby monitors; they can control your garage doors and get access to your house; they can also control the temperature levels of your shower. Even if the bad guys are not using all this to harm you, they can definitely use these devices to harm others and leave traces of your identity and devices at the victim’s end. Isn’t that scary?

Source: https://www.pubnub.com/blog/2015-05-04-10-challenges-securing-iot-communications-iot-security/

With IPv6 and high speed WiFi networks and gateways available almost everywhere, IoT is growing at enormous pace and it is expected that the number of such connected devices will be more than 40 billion by 2020. More connected devices means more opportunities and more attack vectors for hackers and this is where responsibility must be taken, because you do not want your new connected car to go dead in the high speed lane and your home entertainment system to play music by itself at full volume at midnight while you are asleep. End consumers are no doubt the best security care-takers, but, as an IoT device developer or enterprise, it is your duty to take security as paramount factor while designing an IoT device and provide good security features and options for consumers, so that they have confidence in your device and, thus, their privacy. When it comes to competition and time to market, the security is always ignored, as addressing it always adds to the cost and effort involved in building a product, but, in the long run, this could severely impact business and the trust of consumers may be lost for ever.

How to secure your consumer IoT device: 101

While there is no 100% guaranteed way to secure an IoT device (other than to unplug it), as a responsible enterprise focusing on consumer IoT devices, plans should be in place from the very initial design stages so that security is not a concern when it is deployed:

  1. Give up on defaults. Do you still use default admin/password to allow users log in to their new IoT devices? It is time for change! How many users actually change these default credentials to something secure? And then they wonder why their network was compromised. While these defaults can be easily found on the Internet, each device having a unique username and password is more secure. It is best to force users to change the defaults on first time usage and to only let them use strong alphanumeric credentials.
  2. Lock all doors. Often, consumer devices have hardware boards with test points, serial port connectors, etc., which can be used as a back door to enter the device and look under the hood. Removing such access ensures no voiding of security at hardware level, which could easily be published on the Internet, thus publicizing the vulnerability of such devices. Disable SSH/Telnet based logins of Linux-based IoT devices, if this facility is not required by end user.
  3. Isolate Networking. A separate guest connection, isolated from main network, ensures shared files and resources are not directly accessible in cases where devices are compromised. This provides an added layer of security.
  4. Encryption. Ask yourself: “Does someone really care about your room temperature data?” Often, such type of data is left unencrypted and, if control signals start floating from device to the Internet unencrypted, these devices can be controlled by clone signals from attackers. So always have an encrypted communication over SSL/TLS.
  5. Over-the-air software/firmware upgrades. It is nearly impossible to recall millions of devices to manually patch security vulnerabilities. Hence, there must be accommodation for over the air updates. Updates should be made ensuring authenticity of source by using certificate exchange methods or similar.
  6. High Level Interface. Cloud interface, Web app, and mobile app communication must be encrypted, patched to all known vulnerabilities and protected against attacks, like cross site scripting and SQL injections. To reduce the footprints of large volume of data stored in the cloud by IoT devices, they are commonly left logically unencrypted or non-hashed, which is inadvisable.
  7. Restrictions. Data volume restrictions can be added. For example, a connected weather station may only be allowed to send 100MBs of data in a day. This could prevent it being used as a botnet to launch massive DDoS attacks.
  8. RF security. IoT devices that communicate using non-TCP/IP based protocols, like Zigbee, BLE, LoRA etc. are found in devices like fitness bands, smart watches etc. These are often taken for granted, as they are not directly connected to Internet, but, rather, use a gateway. However, the data can be sniffed over radio frequencies using RF explorers or software defined radios, so encryption on data produced by these devices is also essential.

Keeping a watch on these basic security measures will ensure privacy of end consumers and they will build a long lasting confidence in such devices and companies, hence, ensuring secure steps ahead in the connected world of the Internet of Things.

Post Author

Posted April 24th, 2017, by

Post Tags

, , ,

Post Comments

5 Comments

About The Colin Walls Blog

This blog is a discussion of embedded software matters - news, comment, technical issues and ideas, along with other passing thoughts about anything that happens to be on my mind. The Colin Walls Blog

@colin_walls tweets

Follow colin_walls

Comments

5 comments on this post | ↓ Add Your Own

Commented on 24 April 2017 at 14:00
By cL!_N!nJ4.xx.

Nice article! Great content. Thnx for sharing.

Commented on 24 April 2017 at 17:43
By Tarab Rizvi

IOT is the new lifestyle.
Really amazed.

Commented on 24 April 2017 at 17:51
By Rajdeep

Interesting perspective! Thanks for the post

Commented on 24 April 2017 at 18:10
By Akshay

Before reading this article I didn’t know that IoT is a double edged sword. Damn.
This article is enlightening only the tip of the iceberg. And yet it’s so much that I didn’t know, and still don’t know!

Commented on 25 April 2017 at 10:12
By Ayan Pahwa

Thank you all for comments and feedback!

Add Your Comment to Akshay

Archives