9 ways to improve IoT device security
New devices are being plugged into the Internet of Things (IoT) at a rapid pace. While IoT is expected to offer many benefits, adding insecure devices to an enterprise network can have serious consequences. The good news is that security policies and procedures can protect enterprise infrastructure, harden IoT configurations, and make the network smarter and more defensible.
Research indicates that most systems are not compromised through sophisticated or device-specific vulnerabilities, but rather because of a lack of basic security controls. While at-risk devices have some things in common—they use TCP/IP protocols and Internet-based software—they cover a wide spectrum of price, application, and purpose. The category includes typical IT gear such as smartphones, tablets, sensor equipment, and control systems, as well as video cameras, network printers, industrial controls, and medical equipment.
Just how big of a problem is it? According to a recent poll by 451 Research, security is the No. 1 impediment of IoT—and for good reason. Weak links in an enterprise’s security posture from insecure devices are broad-ranging and difficult to pin down. For example, supply chains have many vulnerabilities and attack surfaces. There are also many protocols and standards to support, minimal over-the-network software security, complex security architectures, malware-riddled devices, and few incentive for vendors to develop and deploy device updates after the initial sale. Not to mention, just finding and cataloging every device is nearly impossible.
If IoT is to reach its full potential—and if enterprises are to benefit—devices must be more secure. The recommendations below are from various sources, including the Broadband Internet Technical Advisory Group (BITAG) and the Cloud Security Alliance. Some of the advice can be implemented today, but other recommendations will take time, especially around product design improvement.
1. Secure and centralize the access logs of IoT devices
Preventing devices from connecting to the network without IT’s knowledge is one of the first lines of defense. IT managers maintain centralized access logs of networks under their control. They know what’s attached to the network and who logs in to what, when, and for how long. Unfortunately, the process hasn’t scaled to address the volume of IoT devices coming online, which has enabled hackers to turn insecure devices into botnets to launch distributed denial-of-service (DDoS) attacks. The consequences can be considerable. Thousands of vulnerable routers, IP cameras, and digital video recorders became infected with the Mirai malware and were then used to take down major websites. Mirai spreads to vulnerable devices by continuously scanning the Internet for IoT systems that are protected by factory default or hard-coded usernames and passwords. Experts suggest that the malware can be wiped by rebooting the device, but constant scanning for vulnerable systems almost ensures devices are re-infected. Only changing the default password protects them from rapid re-infection. And in this instance, because few enterprises kept centralized access logs of vulnerable devices, IT security managers didn’t know they were compromised.
Bottom line: Centralize access logs, and train security teams to recognize attack and alert patterns that use IoT endpoints. DDoS attacks sourced from vulnerable IoT devices are expected to increase, meaning endpoint protection systems that can recognize such threats should become standard.
2. Use encrypted protocols to secure communications
Encryption practices of IoT devices are inferior and insecure. Few devices use encrypted communications as part of their initial configuration. Rather, most use ordinary web protocols that communicate across the Internet in plain text, which makes them easy targets for hackers observing network traffic to identify weaknesses. At the very least, all web traffic should be using HTTPS, transport layer security (TLS), Secure File Transfer Protocol (SFTP), DNS security extensions, and other secure protocols for communications with management stations and across the Internet. In addition, devices that connect to mobile apps or other remote gateways should use encrypted protocols as well as encrypt data stored on flash drives. One reason to encrypt data is to ensure that malware hasn’t infected the device.
Bottom line: Choose devices that employ encryption, and use it.
3. Create more effective and secure password policies
Most network infrastructure requires the administrator’s default password to be changed when first accessed. However, most devices, such as home routers, network printers, and sensors, lack strong authentication and access methods. The Mirai botnet was able to be constructed because the default settings of many digital video recorders and IP cameras were never changed. Moreover, the concept of using multifactor authentication—using a variety of mechanisms to log in besides a simple password, such as with an SMS code sent to a cell phone—is a rarity in the IoT world. In fact, some IoT devices don’t require any authentication. A user can navigate with a web browser to a particular IP address and control the device’s configuration and operation.
To demonstrate the possible insecurities, software engineer Leo Linsky wrote what he called an “anti-worm” worm that hacks into IoT devices using default credentials and then changes the passwords to something stronger. While this is just an academic proof of concept published on GitHub, it is worth reviewing.
Bottom line: Change default passwords to strong, unique ones, and use single sign-on tools to manage and limit access. Educate end users on best practices for home network routers and modems, especially if laptops and tablets move from home to office networks.
4. Implement restrictive network communications policies, and set up virtual LANs
It's important to understand the difference between restrictive network communications and permissive network communications. For example, there is a difference between a PC that shares all of its hard drive with everyone and a web server that restricts only a few authorized users to view its content. Unlike most restricted web servers, the assumption with IoT devices—such as temperature sensors—is that they are permissive. They can and should communicate with just about anyone and any device by default. This permissive communication is part of their design. Vendors want them to participate on networks and share their data with a variety of tools and software programs. Unfortunately, permissiveness is what makes these devices inherently insecure and vulnerable to all sorts of exploits. Instead, restrictive network communications, such as built-in firewall rules or more careful user or application authentication, should be implemented. Devices should not be reachable by standard TCP/IP ports such as Telnet or FTP, and users should not assume they operate behind enterprise firewalls that will prevent communications across the network or out to the Internet.
Bottom line: One way to provide better security is to isolate sensors and other permissive devices on a separate virtual LAN. This setup prevents a hacker from observing the totality of network traffic if one sensor is compromised, or using it to launch attacks across the entire enterprise.
5. Understand that device firmware can be insecure
Identifying how firmware on connected devices is updated is a priority. For example, look at the network-attached printers still running original factory-installed firmware versions. Unlike Windows or Mac endpoints, sensors and printers don’t have the ability to enable automatic updates, and device manufacturers aren’t forthcoming when it comes to updates.
Some firmware is easily compromised because updates can be applied without any user authentication. Firmware can also be riddled with vulnerabilities. A case in point: Security researchers at the Carnegie Mellon University Cylab downloaded close to 2,000 home router products’ firmware images and tested them. Some 43 percent were vulnerable to simple attacks, and many had back doors to make hacking easier. One bright spot in this area is Factom, a security software vendor that proposes to authenticate IoT devices to prevent spoofing and ensure data integrity by leveraging block chain technology. Others should follow its lead.
Bottom line: Purchase devices that have secure firmware update policies when possible. In addition, educate users on how to secure home routers.
6. Improve failover design
Devices should function when Internet connectivity is lost or disrupted. However, few IoT devices are designed to cope with failures such as Internet continuity or data disconnections. Failover design is especially important for IoT devices that involve user safety, such as door lock mechanisms, video monitoring, and environmental monitors and alarms. These devices should have manual overrides or special functions for disconnected operations.
Bottom line: IT should include failover design as part of the decision process. Vendors must step up and address the problem.
7. Design explicitly for privacy and security
Few IoT device vendors consider security a feature or incorporate it into the design lifecycle. As a result, most devices fail to offer privacy policies or incorporate privacy-by-design principles. (This is also true of many standard computer hardware and software vendors.) In addition, distinguishing between the roles of supplier, OEM, customer, and partner is getting harder, making enforcement of security best practices difficult. As a result, some devices might have inserted malware, outdated software, bugs, or other vulnerabilities due to lack of proper testing or quality controls.
Bottom line: Security and user privacy of the entire IoT supply chain need improvement. Vendors must design explicitly for privacy and security, especially when a device is sold with an accompanying online service contract that locks customers in for extended periods of time. Vendors should also provide obvious links to privacy policies from websites.
8. Create an industry-backed program for “Secure IoT Device” labeling
There is currently no industry standards program for IoT security. BITAG’s "Internet of Things (IoT) Security and Privacy Recommendations" report suggests, “An industry-backed set of best practices seems to be the most pragmatic means of balancing the innovation in IoT against the security challenges associated with the fluid nature of cybersecurity, and avoiding the checklist mentality that can occur with certification processes.” It goes on to list a collection of industry groups, such as the W3C, the U.S. Federal Trade Commission, and the Online Trust Alliance, that have stakes in the IoT industry. Unfortunately, none of these organizations focus primarily on IoT.
Bottom line: The IoT device industry should consider the creation of an industry-backed program under which a "Secure IoT Device" logo or notation could appear on IoT retail packaging, similar to how the Wi-Fi Alliance operates.
9. Create bug bounty programs and vulnerability reporting systems
Vendor support for IoT devices is limited, especially when flaws are discovered. IoT devices are often missing features such as power reset buttons or even on/off switches found in typical IT products. Manufacturers may skip these features to simplify the product and reduce cost, but doing so can make products vulnerable to remote control exploits. Unfortunately, companies have few places to turn to. Few IoT vendors have implemented the support programs that the enterprise world takes for granted, such as customer alerts when a device is no longer sold, links to prior versions, and contact information.
Bottom line: Vendors must create ways for companies and users to get answers, including bug bounty programs, vulnerability reporting systems, support contacts, and escalation procedures.
- Internet of Things (IoT) Security and Privacy Recommendations (Source: Broadband Internet Technical Advisory Group)
- Future-proofing the Connected World: 13 Steps to Developing Secure IoT Products (Source: Cloud Security Alliance)
This article/content was written by the individual writer identified and does not necessarily reflect the view of Hewlett Packard Enterprise Company.