You are a company creating consumer-facing IoT Devices, What things should go in a IoT product/data security policy?

Initial thoughts: Privacy, Control Gates, cryptography, vulnerability/decision trees for quality planning, etc

closed as too broad by S.L. Barth, Steve, CaffeineAddiction, Xander, Matthew Feb 17 '17 at 9:21

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    This is too many questions. Can you pick one? Answering all of those would take a book. – Goose Feb 16 '17 at 15:59
  • 3
    Autoupdate facility – paj28 Feb 16 '17 at 16:02
  • 1
    @paj28 great! that is one I missed – Kamic Feb 16 '17 at 16:28
  • 1
    @goose I'd generally agree, but if you had a connected device - it would be unique top down oversight, wouldnt it? – Kamic Feb 16 '17 at 16:38
  • 1
    it would would be unique as having a top-down security approach in addition to a bottom-up for IoT devices, due to the complexity. – Kamic Feb 16 '17 at 16:43

How to build a secure IoT device

IoT devices cover a wide range of functions, from Smart Meters to Web Cams. This includes very simple devices, such as smart light bulbs, and more complex ones, like voice control hubs.

Convenience is important when setting up IoT devices. Most consumers opt for simpler setup processed like "WPS Push Button". This is probably not a big problem as attackers need physical proximity at a specific time.

Network Security

There are three main network security models for IoT devices:

  • Local automation hub
  • Connect to manufacturer
  • Provide a listening service

Local automation hub

The device makes a connection over a local network to an automation hub. Typically, a device will pair with the first hub it finds. There is a small window of vulnerability, but after that communication is encrypted. Sensitive systems may need more secure key distribution. Once connected, devices usually fully trust the hub.

Connect to manufacturer

The device makes a connection over the Internet to the manufacturer. To do this securely, there should be a certificate hardcoded on the device that validates an SSL connection. Once connected, devices usually fully trust the manufacturer.

This relies on the provider to keep their service secure and available. Some consumers dislike the requirement to trust a third party. This arrangement tends to be secure, but is only suitable for some devices, e.g. smart meters.

There needs to be a secure process to associate a user's online account with the manufacturer, with their device. Failure to do this results in vulnerabilities like this Nissan Leaf vulnerability.

Provide a listening service

The device listens on a port, typically providing a web server. The user can expose this to the Internet using port forwarding; the device may automatically expose it using UPnP.

Authentication is essential; normally this is done with a password. There are three approaches to setting the initial password:

  • Default password, same on every device. This is very risky, results in many compromises, and is not recommended.
  • Random password, unique on each device. The password can be printed on a sticker attached to the device.
  • User sets initial password during install. This leaves a small exposure before a password is set.

Many users want to change the password to something memorable. This creates many risks - users tend to pick bad passwords and re-use passwords many times. To mitigate this, there must be: a password strength policy, a lockout policy, and passwords must be stored hashed, with a salted, computationally expensive hash.

Secure development

IoT software must be coded carefully to avoid exploitable vulnerabilities, such as command injection, which have been prevalent in IoT devices. Embedded systems are a challenge as there is limited memory. Many routers run BusyBox and have Bash scripts acting as CGI scripts. This is risky as it's very easy to accidentally introduce command injection flaws. Consider using a different embedded system, such as LUA.

The device should require authentication for all requests. This greatly reduces the attack surface. For example, this Netgear vulnerability would have been much less serious if only authenticated users could exploit it. Thorough CSRF protection is also required, or external web sites can send cross-domain requests through a logged-on user's browser.

All network connections should be encrypted. Use SSL with only modern protocols and ciphers enabled. There are several good embedded SSL libraries, such as Tiny SSL. IoT devices typically have a self-signed certificate. This is acceptable, as long as the certificate is unique on each device.

Most devices use a lot of C code, which could be vulnerable to memory corruption flaws. Enable all the anti-exploitation features available (stack guard, DEP, ASLR, etc.)

You need to audit your code for bugs. This should include both static analysis (code review) and dynamic analysis (pen testing and fuzzing).

Physical security

Most IoT devices don't defend against physically local attackers. Those that do (e.g. smart meters) can take basic precautions like disabling the JTag interface to make attack much harder. More advanced anti-tamper precautions are possible.

Software Updates

Most devices should have an auto-update system that is enabled by default. The device must only accept signed updates, and there needs to be protection against downgrade attacks.


Logging poses a privacy risk, especially in devices with microphones. We need to weigh the usefulness of logs to the user against the privacy risks. In most cases IoT devices should keep limited logs. One useful log: listening services should log all connection attempts - with successful and unsuccessful authentication.

Not the answer you're looking for? Browse other questions tagged or ask your own question.