Cybersecurity and the Internet of Things
Dr. Lynne Williams, Professor, School of Business at Information Technology, Purdue University Global
The Internet of Things [IoT] is not just the next trend in technology, it is already here and it is all around us. Smart homes, smart cars, smart cities and smart things are everywhere hiding in plain sight. What makes the IoT different from the traditional technology model is connectivity. A laptop sitting on a desk connected to the office Wi-Fi cloud is a traditional connectivity model. Cybersecurity professionals understand the data conduit (Wi-Fi connection) and what needs to be done to secure that connection. The IoT employs a multitude of connectivity options including RFID, Bluetooth, Zigbee, LoRa, cellular signal, and an increasing number of other options. Smart things are designed to connect and to do so without human intervention.
Out of Sight, Out of Mind: Machine-to-Machine Connections [M2M]
Machine-to-machine communication really sets the IoT apart from traditional connection technology. Smart things don’t need humans to connect with each other. The infrastructure differs very little from a traditional local area network (LAN) or wide area network (WAN) but by using sensors to connect without human intervention, the IoT can feed data across millions of devices in a single network that lacks a defined perimeter that could be secured. Anything with sensors or some sort of control technology can connect with anything else using a growing range of connectivity options.
Manufacturers of smart devices are primarily focused on connectivity with security being mostly an afterthought. Consumers “just want the thing to work”, so they’re designed so that all you need to do is plug it in and turn it on for it to connect. Because M2M devices may not necessarily need to use traditional connectivity options to connect with each other, they can easily pass right under the enterprise cybersecurity radar because they’re not using the corporate Wi-Fi or Ethernet network. This effectively makes many M2M devices invisible and thus difficult to manage using traditional access control and network management solutions. Obviously, it’s tough to manage and secure what you can’t see.
The IoT Threat Landscape Has Expanded Over the Horizon
While the horror stories of compromised baby monitors and hacked automotive systems make for good click-bait, these incidents are not the genuinely dangerous aspect of the rapidly expanding threat landscape of the IoT. In 2016, the Mirai IoT botnet perpetrated a massive distributed denial-of-service attack [DDoS] that, at its height in September 2016, brought down several high-profile websites and services, including Dyn, which provides DNS services for many other web enterprises. Although the use of things, rather than traditional computing devices, as the attack weapon was innovative, the Mirai botnet uses a fairly traditional methodology. The Mirai code is a worm that self-propagates malicious code into vulnerable devices, and then controls the infected devices using central command and control servers. Mirai was able to spread exponentially through the IoT by simply trying a list of default login-password combinations that are commonly used by a range of IoT devices and SOHO equipment.
Since Mirai’s peak infection period in September 2016, variants have evolved to include a variety of new features. These variants have since improved infection techniques as well as hardening the code to make reverse engineering efforts more difficult. The original Mirai worm relied on a short list of common default “thing” credentials, but new sets of credentials are continually being added. Variants are also using improved methods of port scanning to find open devices. While these improvements in virulence are certainly a cause for concern, other than targeting things rather than traditional computing devices, Mirai and its variants aren’t much different than similar traditional threats, so what makes threats such as Mirai stand apart from those traditional threats?
Beyond the OSI Model
We’re all familiar with the OSI model as it relates to TCP/IP networked devices, but in 2014, the CTO for Cisco, Jim Green, proposed a new model for visualizing IoT layers. Green’s model presents a practical view of how the IoT operates. The physical layer is composed of connected things such as fitness trackers, intelligent virtual assistants, smart automotive systems and anything else with “smart” abilities. The next layer is connectivity, based on the “network of sensors” concept described by the IEEE. This connectivity layer describes the range of connectivity options available to things. The edge layer then describes how these connectivity options seek to communicate with a gateway to the internet. The data accumulation layer addresses the storage of the thing data that has been routed across the internet, then the data abstraction layer groups data into classifications. The application layer analyzes the data and is where genuine cloud computing takes place. The top layer is user-facing, where various applications draw out information from the previous layers, such as presenting fitness information gathered from fitness trackers or statistics on energy usage gathered from smart meters.
Green’s model gives a practical view of where the IoT’s vulnerabilities exist. For instance, since the physical layer is composed of physical things, the model makes it easier to examine how an attacker can use a physical attack to gain access to a thing’s interface which would then allow the attacker to extract credentials from the thing’s firmware or sniff or modify signals transmitted by the thing. In the connectivity layer, connectivity options such as Zigbee can be sniffed in order to grab encryption keys as the thing negotiates to join a Zigbee mesh.
Threats like the Mirai worm leverage the complexity and non-homogeneity of these non-traditional layers to spread and attack. Few commercially available intrusion detection systems currently monitor non-standard traffic such as Zigbee meshes or Bluetooth. Yet another non-standard connectivity option is 6LoWPAN (IPv6 over Low Power Wireless Personal Area Networks). 6LoWPAN is a competitor to Zigbee that provides gateway services between IP networks and Low-Power and Lossy Networks [LLNs]. The Routing Protocol for Low-Power and Lossy Networks [RPL] used by 6LoWPAN is vulnerable to a variety of routing attacks and is also unlikely to be monitored by traditional IDS/IPS systems.
So, is the Sky Really Falling?
Not necessarily, provided that designers and manufacturers of things come to grips with their role in building security into the things that they’re selling to the consumer. A reasonable and relatively easy step would be to use more randomized initial login credentials while also requiring the consumer to change those credentials during the first bootup of the thing. Another practical approach would be to default to an initial state of all closed ports, thus requiring the consumer to open only those ports required to allow the thing to connect. While there would be an unavoidable loss of a certain amount of convenience, by adopting the concept of least privilege, vendors could guide consumers to a more secure stance.
Developers of things should adopt an automatic update approach similar to that used for full-scale operating systems. By pushing firmware updates to things, keeping things current with patches and improvements would remove the onus on the consumer to update the thing. This would require including some form of rollback capability in case the thing fails due to the update, but automatic updates in the main would somewhat alleviate the growing problem of unpatched things. As with operating system updates, some provision would need to be made to encrypt and authenticate patching traffic.
As noted, consumers just want the thing to work, so considerable resistance to baking good security practices directly into the thing can be expected. This could be mitigated with the implementation of bug bounties by IoT vendors. Dozens of vendors such as Barracuda, Google, and Apple have had good results from bug bounty programs that reduce the burden of testing and patch development by engaging the relevant development community in finding and fixing vulnerabilities.
Given the increasingly varied set of connectivity options for things, just getting an accurate picture of what and how many things are attached to the network is almost impossible. Without an accurate inventory it is correspondingly difficult to figure out where vulnerable devices may be lurking. As with other technologies, the more that elements of a technology can standardized, the more straightforward it becomes to properly secure that technology. If thing vendors would adopt a more standardized method of providing a thing’s identity to the network, the process of auditing for things could be simplified. For example, revealing the thing’s MAC address to the media access control layer of the network would make the thing visible to traditional networking equipment.
The Elephant in the Room
All of the potential security solutions to the IoT threat landscape mentioned here are dependent on IoT developers and manufacturers. But, what actions can cybersecurity professionals take? In an enterprise setting, you’re probably already questioning whether everything connected to your workplace network really needs to be “smart”. Sometimes a coffee pot should just be a coffee pot. Another obvious step is to immediately change any default credentials used by the thing. Another action that can be borrowed from the BYOD side of the security house is to segment the network and sequester things into that segment. If you can’t keep things out of your network, you can at least try to separate them from the rest of the network. Finally, a number of vendors, such as Amazon, are beginning to develop IoT security services that stand in for those secure elements that should have been provided by the original developers and manufacturers. Depending on the size of your network and how many things are being introduced to that network, contracting with an IoT security services provider might be one of the better options until enough pressure can be applied to thing vendors to induce them to build security right into the thing.
The IoT Cybersecurity Improvement Act of 2017 is currently under review by the U.S. Congress. While the bill isn’t perfect, it’s at least an effort to induce thing makers to take security seriously. Until they do, cybersecurity professionals will simply have to do their best to cobble together an IoT security policy and implementation that works for their particular organization.
About the Author
Dr. Williams is a faculty member at Purdue University Global. She has won numerous teaching, research, and service honors, including the Outstanding Full-Time Faculty Member award for 2014. Williams’s research has been published in a variety of journals and books and she has been cited for her expertise on cybersecurity and online privacy issues in publications such as the Computer Technology Review, Techonomy, and Computer World. Most recently, Williams has been researching the legal and ethical facets of passive digital footprints with an emphasis on data gathered through the Internet of Things.
Lynne can be reached online at [email protected].
;
We are in our 11th year, and Global InfoSec Awards are incredibly well received – helping build buzz, customer awareness, sales and marketing growth opportunities, investment opportunities and so much more.