IoT devices today are getting more complex. Some devices may simply consist of an image containing the RTOS, third-party libraries, and custom code. More modern IoT devices will often consist of an operating system, a runtime environment, as well as containers that are used to segregate cloud services, analytics services, third-party code, and custom applications. These devices must be configured to operate on the network securely. First and foremost, follow the manufacturer's documentation for configuring their devices securely. In the absence of manufacturer guidance, seek out best practices for the specific types of devices deployed in your network.
At a minimum, disable unused and frequently compromised services. Malicious code is constantly scanning the internet looking for vulnerable FTP, telnet, and other services that may have weak or well-known passwords guarding them.
Review the passwords that allow entry into the device, including any passwords used for custom IoT services as well as accounts stored in the /etc/passwd file. Disable/delete accounts that are not authorized and require role-based authentication for access to device functions and administration.
The management of passwords for IoT devices is non-trivial. Adopt tools that allow you to configure all IoT devices with unique passwords; do not share passwords across multiple devices. Also, rotate passwords on a regular basis as defined by your security policy. There are security products that can assist with these efforts. For example, Device Authority has a product known as KeyScaler that can perform automated password management for IoT devices. Administrators can manage local passwords of devices and rotate passwords on a predefined basis.
Review best-practice documentation for IoT protocols and lock down your implementations accordingly. For example, there are guidance documents available that describe secure configurations for Bluetooth communications:
- National Security Agency (NSA) Information Assurance Directorate (IAD) guide to Bluetooth security (https://www.nsa.gov/ia/_files/factsheets/i732-016r-07.pdf)
- NIST SP 800-121 NIST Guide to Bluetooth security (http://csrc.nist.gov/publications/nistpubs/800-121-rev1/sp800-121_rev1.pdf)
For devices that make use of ZigBee for communications, don't rely on default configurations. Tobias Zillner and Sebastian Strobl provided a useful briefing on the need to change the default keys. The researchers noted that the default Trust Center link keys for both the ZigBee Light Link (ZLL) profile and the ZigBee Home Automation Public Application Profile (HAPAP) are both based on the passphrase ZigBeeAlliance09. Implementing any IoT system that doesn't enforce modification of default keys can render many communication security controls useless within an enterprise. These keys should always be updated prior to bringing a ZigBee-based IoT network online (https://www.blackhat.com/docs/us-15/materials/us-15-Zillner-ZigBee-Exploited-The-Good-The-Bad-And-The-Ugly.pdf).
The security of the hardware configurations is equally important. Work with your manufacturers to review their security posture. Review documentation or ask your manufacturer's representative if the devices have locked-down test interfaces (for example, JTAG) to combat the ability of an attacker to gain access to devices that are stolen or left exposed. In conjunction with designers, also make use of any physical security features that may be included in the hardware. Such features may include active tamper detection and response (for example, automated wiping of sensitive data upon tamper), coverage and blocking of critical interfaces, and so on.