There is Hope
The term ‘Internet of Things’ (IoT) makes it easy to forget that we are talking about computing devices. Just like any computer, connecting one of these devices directly to the public internet has risks. These computing devices often have operating systems such as Linux with communication ports that we have used for decades in larger computers. Protecting our desktop computers with strong authentication and keeping them behind a firewall may seem like obvious security best practices. But in the world of IoT, cost sensitivities and lack of industry know how have made risk mitigation a secondary consideration, or worse.
Recent IoT attacks: Lowest hanging fruit
The IoT device botnet that attacked popular tech writer Brian Kreb’s website was probably the largest on record. Soon after, Dyn, the DNS service provider reported that it was attacked with malicious internet traffic over 50 times above normal levels. It should be noted that this botnet took advantage of the ‘lowest hanging fruit’ available to it. From what we have recently learned, the current generation of Mirai takes advantage of IoT devices directly connected to the public internet with default or hard coded username/password credentials.
These devices can come under the control for malicious purpose for the least amount of work by the attacker. How many devices can be categorized as being ‘lowest hanging fruit’? Unfortunately, the answer is many according to Shodan, the search engine for internet connected devices.
Upcoming IoT attacks: Devices behind the firewall
IoT based DDoS attacks could become even more sophisticated, taking advantage of devices behind firewalls. For home environments, devices take advantage of UPnP technologies which open devices to the public internet, which could be used maliciously. In industrial or enterprise environments we have seen endless examples of how social engineering leads to compromised workstations connected to internal networks that could lead to any number of attacks inside the firewall. This could include sniffing for device username/passwords moving across the internal network, leading to compromise of the device. The source code for Mirai DDoS attack malware is now available publicly and will inevitably spawn variants. We have seen this before with the release of the source code for the Zeus virus which spawned a large number of sophisticated variants targeting the financial industry. Other IoT based DDoS attack systems are already in the wild, such as BASHLITE, but researchers have already noted upgrades to the publicly available Mirai source code.
We have not only seen attacks on IoT devices for the purpose of DDoS, but also against industrial systems. The lights went out in Crimea in December 2015 due to the Black Energy virus, taking advantage of workstation to device connectivity at energy plants.
A cyber attack against a German steel plant caused widespread damage.
Threats to our critical infrastructure have captured the attention of government regulators. Presidential Policy Directive 21 in 2013 was regarding “Critical Infrastructure Security and Resilience.” Government regulators are signaling that they will support fully automated vehicles, but have issued 15 points of guidance, which includes cyber security.
The recent DDoS attacks have sparked their own calls for further government regulation.
Ideally, devices should have a stronger form of authentication than username/password. Any computing device is at risk when it is using an authentication method that can be intercepted from its network or from the memory space of a compromised workstation that is interacting with the device. By protecting the digital identity of device we are able to ensure a trusted IoT ecosystem. Device authentication with cryptographically based managed identities is a world beyond the low security behind the ‘lowest hanging fruit’ used in the Mirai attacks.
Not only will devices need a way to uniquely identify each other, but we need to consider the security of device interaction with humans and applications. The sheer scale of the problem suggests that a cloud based authentication platform would be necessary to provide seamless provisioning, offset the necessary computation, span the geographic distribution, and ensure availability of services.
We should be segregating the IoT network behind IoT gateway devices. This is a good way of reducing the exposure to workstations and servers behind an enterprise or industrial firewall that are at risk of compromise. Assuming internal systems are physically safe or unconnected from the internet does not guarantee security as we saw from the Stuxtnet virus. IoT gateway devices should have their own secure digital identities, requiring strong device authentication.
Manufacturers of IoT devices are not usually experts in security. IoT devices are usually assembled from a diverse supply chain. The US CERT guidance to manufacturers to mitigate botnets such as Mirai is good, but many of the suggestions may relate to parts that are made in bulk and white labeled and therefore not in direct control of the final vendor.
Ideally, an IoT device vendor should implement security technology that is purpose built to help bring product to market quickly and securely. The results of ‘security as an afterthought’ has already played out in IT environments with endless breaches of privacy and millions of stolen dollars. What we are witnessing with IoT botnets is just the beginning of a painful parallel journey unless we make it easier for IoT device vendors to implement strong authentication, device network segmentation and secure supply chains.