April 23, 2018
By Brian Russell

5 Initial Steps to Mitigate Security Threats in Consumer IoT Products

The major botnet variants seen over the last few years have been enabled primarily by a lack of basic security engineering practices applied to consumer IoT devices. BASHLITE, Mirai, Remaiten and Linux.Darlloz all relied at least partially on dictionary attacks that took advantage of well-known default username/password combinations to compromise devices.

The goal of cyber security is to make it more costly to compromise a system than it is worth. While there are some IoT systems for which adversaries will go to extreme measures to compromise, most IoT products will be able to deflect less-skilled attackers and botnet scripts by simply following a few good security practices. Here are five security controls to begin the process of safeguarding your devices from attack today. Implement these controls and the likelihood that your product will end up a victim of the latest botnet is greatly reduced.

1. Do not hard-code credentials into your device and require that default credentials be updated first

The dictionaries used by many of the IoT botnets mentioned above are populated with "root", "admin", "supervisor", and other well-known usernames paired with default passwords as simple as 123456 or in some cases left empty. Makers that apply a consistent default username/password combination to their devices run the risk of having their entire device family compromised quickly after connecting to the Internet. A better approach is to generate unique temporary passwords for each device and then require users to update with their own strong password upon initial configuration.

X.509 certificates can also be used to configure initial trust to IoT devices. Makers can generate a unique pair of cryptographic keys on the device and then provision a certificate bound to the device's identity. Users possessing a trusted key (through some out-of-band process) can then access and configure the device upon first use.

2. Disable unused/unneeded services such as telnet, ftp, etc.

IoT devices support remote access via various protocols such as telnet, file transfer protocol (FTP), http or other network services. Developers that enable these services on products leave open ports that can be used as attack vectors into the device. Consider limiting the device's remote access options to secure methods such as HTTPS or Secure Shell (SSH). Disable all other remote access options and require authentication for access over allowed options.

3. Encrypt sensitive communications

Allowing plaintext communications over IoT interfaces exposes products to eavesdropping. Since protocols such as MQTT do not offer native encryption support, this leaves credentials in the clear which can result in a compromise of your systems. Protocols such as MQTT and REST-based communications should be protected using Transport Layer Security (TLS) 1.2. Protocols such as the Constrained Application Protocol (CoAP) which rely upon the User Datagram Protocol (UDP) can be protected using Datagram Transport Layer Security (DTLS), as defined in IETF RFC 6347. Wireless protocols such as ZigBee, ZWave, Bluetooth and others either have native encryption options or make use of lower layer protocols such as 802.15.4 to provide confidentiality.

There are a number of cryptographic tools developers can use to integrate cryptographic capabilities into IoT devices. The use of any particular tool will depend on your IoT device's capabilities. A sampling of cryptographic libraries includes WolfCrypt, mbedTLS, Bouncy Castle, LibgCrypt and Crypto++.

4. Software Assurance

Security researchers have found a number of software vulnerabilities within consumer IoT products. Discovered vulnerabilities in IoT products or the applications and services that support them include directory traversals, buffer overflows, cross-site scripting (XSS) command Injections and even SQL injection vulnerabilities found in supporting database systems. Developers should guard against the introduction of these vulnerabilities into their products (and supporting infrastructure/services) by adopting a secure development lifecycle (SDL). A SDL defines a process for identifying and mitigating threats to IoT products. SDL activities include threat modeling, security requirements engineering, the use of secure coding standards, security code reviews, security testing, and other activities that increase the security posture of your products.

To get started, review the OWASP Embedded Application Security Project Best Practices document from Aaron Guzman and Alex Lafrenz at This in-process guide discusses approaches to protect IoT devices against buffer and stack overflows, command injection and other vulnerabilities. It also describes a set of best practices for securing sensitive information, enabling transport layer security, and auditing 3rd party software.

5. Secure your firmware update process

IoT products will eventually require updates to their firmware. If these products do not validate that firmware being loaded is legitimate and has not been tampered with, then there are opportunities for attackers to load their own firmware files. These files may include newly added functions that allow eavesdropping on your customers, or allow the attacker to exploit trust relationships to move from your product to other products in a system.

Take precautions to apply digital signatures to all firmware and require that the IoT device validate the signature prior to loading the firmware. Validation occurs when the device validates the signature on the firmware which is signed by the private key of the signer. The signer's public key should be embedded within a certificate issued by a trusted authority (e.g. a PKI), allowing the device to use its configured trust anchors to validate that the certificate is trusted, not expired and not revoked.


Follow these five steps to begin the process of securing your consumer IoT product. While these alone will not mitigate all threats to your product, they will reduce your attack surface and make it more difficult for automated scripts to gain access to your devices, if performed properly.

Share this post

You may also like