In the last year or so, the topic of Internet of Things (IoT) received a lot of attention. Both the concept of the topic and scope of what should be included in IoT changed dramatically in that time. The first commercialization of IoT were wearables such as GoogleGlass. Shortly thereafter came the next wave, with devices such as smart watches. The first security concerns were focused on personal safety due to user distractions, similar to those voiced when smartphones became popular, and then came the invasion of privacy concerns. However, shortly after the first hackers got hold of them and identified attacks to gather data from them. At that point, the view on IoT expanded to recognize that the concept of IoT was actually much broader and had more significant impacts than privacy.
The integration of sensors and interactive programs into many formerly unconnected devices took place and expanded right under the general public’s nose. This integration began much earlier in the mid-1990s, when companies using connected infrastructure management systems like Supervisory Control and Data Acquisition (SCADA) systems and Remote Power Distribution Units/Switches (PDU/RPS) began connecting them to the Internet to save money and reduce on-site personnel needs. In 1999, the United States Food and Drug Administration (FDA) allocated the first radio spectra for short range communication between body implants and nearby controllers.1 After that, actual devices using these specifications began cropping up in the early 2000s, such as the first FDA-approved wireless insulin pump in 2003.2 By the time the term “Internet of Things” was coined, the world was actually well into connected devices, many with serious consequences for abuse or misuse.
Exabytes to zetabytes of data are generated globally from over 5 billion devices.3 Most of these devices are perceived as benign, merely sensing data with no causal interaction capability. However, this is not true for all of them and even the ones that have only sensing capability may be a threat vector.
Though not true for all devices classified as IoT, as a general rule, the devices are identified by a lightweight and dedicated operating system with low memory, CPU, and power overhead requirements. IoT devices are generally created to be very small and, when possible, provide wireless connectivity as well. These specifications make for a very dangerous package. The memory, CPU, and power requirements often mean that security has not been a priority. The low power requirements mean they can often run without commercial power hookup for extended periods. The small size means IoT capability can be embedded in other previously unconnected devices. Wireless capability means they can connect to enterprise Wi-Fi networks to begin their work. The low CPU and memory, combined with the embedded nature of the devices, also means that in many cases the manufacturers have no plan for upgrading or otherwise patching these devices if vulnerabilities are identified. It also means that the devices are not meant to be actively managed and there is no feasible way to put any sort of management or defensive agent, like anti-malware, on them.
That means that we now have devices within our networks that have previously been standalone or network inert brought in and connected with no means of monitoring, managing, patching, or upgrading them, but having a real possibility that they can be attacked, compromised, and then used against the enterprise.
This is not hype, conjecture, or FUD! It is happening. Last year, a colleague told me that his security team had identified problematic traffic originating on their network that resembled command and control and data exfiltration. After some work tracking it down, they found the culprit. It was an Internet-enabled coffee maker that was purchased by office staff and placed in a break room. The purpose of the connection was to remotely monitor the usage of the machine, identify how much coffee was in it, how old the coffee was, and remotely manage power on the system. No one thought that this would be an issue but somehow, a threat actor compromised it and began using it as a beachhead for malicious activity. The device was in the office for nearly a year and by the end of the investigation, it had been showing signs of compromise for over six months.
Devices bring far more than privacy issues with them and as they continue to expand their presence in corporate networks, they present a great opportunity for threat actors. Their common design limitations and their potential invasiveness make improving our visibility of the devices (as they are connected to our networks) imperative. The example I related also demonstrated that we require a means of isolating and otherwise protecting these devices from malicious threat actors and protecting the rest of the network from them if they are compromised.
