5 Recommendations for IoT Manufacturers

As devices get more connected, they potentially get smarter and provide richer functionality. The internet of things (IoT) describes a world where just about anything can be connected, from routers, smart thermostats, smart light bulbs, and door locks to intelligent fridges, or even cars.

In recent events, devices with less than desirable security states were taken over by massive botnets consisting of hundreds of thousands of devices that were able to launch an impressive DDoS attack that crippled several online services.

Security should be a top priority in the strategy of manufacturers and not an afterthought. Consumers are in need of solutions built with security in mind and which protect their homes, their lives and their private information. There is a need for better regulations due to a lack of product certifications or labels to help consumers in differentiating brands and products with respect to their security state.

For this reason, I would like to propose five best practices that any IoT manufacturer should consider:

1) Invest in a common operating platform built with security in mind.

It is worth thinking about this and making the right choices upfront as to make sure all your future devices support the operating environment. A single OS provides a consistent user experience across your devices and you will profit from scaling updates, changes, and improvements on all your devices, limiting the duplication and porting efforts of security updates and new features. Linux and BusyBox, although in the eye of the storm of all things bad surrounding IoT, can be a good choice for embedded devices, as is Windows 10, Android, or any other fitting platform. It isn’t the base OS as such that will provide the security, but it is how you go about it and how you harden the platform and maintain its most up to date version. Some pointers:

• Unnecessary services should be disabled by default, especially SSH, Telnet, SMB, FTP: Un-savvy users will never use these services and the ones that actually might need them for advanced operations will be able to find and understand the ‘enable SSH’ flag in the ‘advanced options’ tab. Do not worry, even if you bury the option in the most illogical place, the people who want it will find it.

• Do not run your management GUI from a web server that runs in root context – if you have an RCE vulnerability, you are pretty much completely exposed. Run the web server in chroot environment and with a user that has limited rights. Most modern web servers by default are configured for running with limited rights, however we have seen manufacturers changing this to have the web server run as root because it was more convenient for them to read/write protected files. There are better ways of doing this, it might take a bit more effort to get this designed into your software but it is well worth the effort. Do consider the fact that whatever shortcut you take to make your life easier, you are also making the life of the potential hacker easier! Whatever you can read/write from your software, a hacker can potentially do so as well. This will add an important layer of security and severely limit the impact of inadvertent programming mistakes – no software is perfect and completely free of vulnerabilities, keep this in mind!

• Use up-to-date versions of OS kernel and services such as Telnetd/SSHD, web server, php or any other GUI supporting framework. Even the most securely-written software will be vulnerable when it runs on a vulnerable framework or service.

• Do not keep hidden backdoors or try to stash secret passcodes – some manufacturers have been found keeping backdoors for remote tech support. It is just a matter of time before your secret is exposed and abused. Do know that just by unpacking and inspecting publicly downloadable microcode updates, most of the backdoors and secret passes can easily be discovered – a hacker does not even need access to a device to uncover such information.

• UPNP on the local network for discovery is fine and will enhance the user experience, but avoid the use of UPNP-IGD (Internet Gateway Device protocol). The UPNP-IGD protocol allows you to punch holes in the security policy of the owners’ internet gateways, most of the time without them being aware of that, to make your device directly reachable from the internet. If you must have internet reachability, be aware of the consequences you are exposing your device to and whatever measure has been taken to secure it should at least be doubled – you are now open and exposed. Also, let the user open a port or create a port forwarding rule by himself, at least they are aware of the security risk and hole in their internet gateway. Better would be however to try to find other ways to avoid the need for internet exposure. It is of course possible that in the end, opening a port is the only way, in that case assume the responsibility!

[You might also like: Nine Questions to Ask to Determine IoT Device Safety]

2) Enforce strong passwords but do not require them to be extremely difficult to prevent users from having to write down their passwords.

Those who want to use extreme passwords can do so and some might do it through password management tools, so allow them but do not enforce them. Use common password checks based on publicly available password dictionaries to prevent users from exposing themselves to brute-force attacks.

Do not store the passwords in reversible format using symmetric encryption, use cryptographic hash to store passwords. Choose modern, secure hashing methods and avoid MD5 or SHA-1. Even the most secure password is useless if you are using weak hashing.

Alternatively, you could work around the whole password issue by integrating with the most common enterprise centralized authentication services such as LDAP, Radius or TACACS and leverage the enterprises’ established password policies.

3) Invest time in a robust and user-friendly OTA (over-the-air) update procedure.

Ideally updates should be seamless and automatic. Alternatively, give the user the ability to download and update his/her device through a simple click on a button in the admin GUI. Do not require users to download a package, burn it to a flash card and have them press impossible key-sequences or CLI commands to start the update procedure of the device. Make it convenient and accessible.

Provide notifications to owners, e.g. by email, when there is a new update available so they can take timely and appropriate action.

Sign your update packages and verify them at install time to ensure they are not tampered with by bad actors.

4) Create a vulnerability disclosure and handling program and provide clear instructions and points of contact for security researchers.

Consider a bounty program to attract security researchers. Take every reported vulnerability seriously and follow up closely with the researcher. Give the researcher credit and let them publish their findings after you fixed the vulnerability. No device or software is free of vulnerabilities, everyone can appreciate that, so there is no bad publicity in the fact that a researcher publishes a vulnerability that you already addressed and you have an update for – it will only build you a stronger reputation and security researchers and consumers will see you as a serious, trusted manufacturer.

5) Try to limit the personal data that needs to be stored on the devices themselves – the more information gets stored, the more can be stolen.

Same for the cloud service that might be related to your devices. Remember that starting May 2018, any provider storing personal information from a EU citizen will be held responsible for protecting that data as part of the GDPR (General Data Protection Regulation) and can face fines of up to 20,000,000 euro for not adhering to the regulation. If you need profile information, store them encrypted and clearly inform the user of the risk.

One more piece of advice before concluding: Ask for help!
The security challenge is enormous because there is currently no standard and, worse, no consensus on how to implement security when it comes to IoT on devices. But like all providers, you have to assume responsibility. Don’t wait for regulations to start considering the security of your products. Instill security in your enterprise culture, and accept that it has an impact on your organizational structure. Security should be a foundational pillar in IoT, not an afterthought.