IOT: “Internet of Things” or “Internet of Threats”?

Promisec-JohnLinkous-headshotby John Linkous

Back in 2012, technology giant Cisco Systems estimated that there were 8.7 billion devices connected to the Internet. At that time, the majority of those devices were servers, endpoints like desktops, laptops and smartphones, and other traditional IT technologies. Counting for the exponential growth in the use of technology, this means that today there are literally more devices connected to the Internet than there are human beings on the planet, and that differential shows no sign of decreasing; industry analyst firm Gartner backs this assertion with their recent estimate that by the year 2020, there will be 25 billion – that’s billion, with a ‘b’ – devices connected to the Internet.

What’s more interesting about Gartner’s prediction is not the number of devices that will be connected, but rather what those devices are. Today, the firm estimates that breakdown is about 60% consumer devices, with 45% of Internet-connected devices being either general business technologies (think servers, desktops and laptops) or industry-specific vertical business devices (think transportation monitoring systems, or PLCs and other SCADA equipment). Only about 5% of those Internet-connected devices today are automobiles. Fast-forward five years from now, and that model will have changed significantly. Gartner estimates over 13 billion consumer devices, which will include a huge swath of devices that have never previously known Internet connectivity, such as appliances, home automation systems, “smart” meters, and others. Perhaps as importantly, the proportion of Internet-connected automobiles is expected to increase to fully 14% of all such devices. The era of the Internet of Things (IOT) is most definitely here.

Unfortunately, the acronym “IOT” could just as easily stand for something else: “Internet of Threats”. IOT devices introduce a plethora of new security threats that simply did not exist in the traditional world of only network appliances, servers, desktops, laptops and smartphones, and many of the technologies themselves are woefully ill-prepared to defend themselves against attacks from the same Internet to which they’ve been engineered to connect.

Let’s start with the potential damage that can be done by compromising an IOT device. Traditional attacks against Internet-connected devices have focused on data breaches and manipulation of financial instruments – but always against electronic information. While those might have had ramifications against real-world assets (for example, electronically transferring funds out of a very real bank account), there’s no direct physical damage; all of the harm is tangential. This is not so with many IOT devices. The earliest significant example of this was Stuxnet. As you may recall, Stuxnet was targeted malware that was designed to cause damage to a specific type of Siemens programmable logic controller (PLC), and could affect the rotational speed of motors contained in these PLCs. The direct result of Stuxnet is that many pieces of equipment affected by the virus – including a large percentage of Iranian centrifuges, which utilize Siemens PLCs for spinning out fissionable material – were damaged or destroyed directly through the actions of the Stuxnet malware. These centrifuges were literally destroyed by a direct, physical attack on the real world caused by a piece of malware. This type of attack, defined as a kinetic attack, is one of the most significant threats introduced by the addition of so many different types of devices to the IOT. Of course, these kinetic attacks are by no means limited to PLCs and industrial equipment. In recent years, presenters at major security conferences such as Black Hat and Defcon have demonstrated real-world attacks on a broad range of Internet-connected devices, from forcing ATMs to spew out currency, to sabotaging “smart” meters to report zero usage (or alternatively, massive usage), to (perhaps most frighteningly) automobiles with advanced Internet-connected electronic systems that can be remotely controlled, managed and directed.

So what is it that is allowing this to happen with IOT devices? There are multiple factors, but one of the most significant is the fact that these technologies require functions that are not well-suited to traditional network protocols. The reasons for this are many: power requirements, bandwidth contention and a lack of independent device communication all play a part in making traditional protocols (think 802.11 WiFi) less apt for many IOT devices. And so, new protocols have been invented to manage them. One of the most glaring examples of this in the home automation industry, where new protocols like INSTEON, Z-Wave and Zigbee were developed to circumvent these problems and deliver flexibility to consumers. Unfortunately, each of these new protocols also introduces new threats that can be exploited by attackers – and some of them by attackers with relatively little knowledge and skill. Last year, an article in Forbes discussed a critical flaw within an early implementation of INSTEON, in which devices enabled with that protocol could be remotely controlled directly from the Internet. Similarly, Z-Wave has experienced its own share of discovered vulnerabilities, and this pattern is likely to continue across the ever-increasing spectrum of protocols that are being established to address the use cases of IOT-attached devices. Regardless of specific protocols, there will also be a growing need for IOT devices using different protocols to talk to each other; it’s clear that consumers will demand this, since interoperability is key value of IOT-enabled devices in the first place. This virtually ensures a rise in bridging technologies that bring together traditional 802.11 WiFi and new IOT-specific protocols like INSTEON and Z-Wave into a bridge or gateway device; as history has demonstrated with other such protocol conversation and translation devices, they will likely be rife for man-in-the-middle attacks.

Another sea change is the increase in devices such as so-called “smart” meters, which are devices that are migrating from traditional electro-mechanical infrastructure to off-the-shelf components including standard ASICs and protocol stacks such as TCP/IP. While this may make life easier and more efficient for utility companies, acceptance of these standardized protocols and connectivity to the general Internet means that these devices will also need to be secured against the myriad known threats that exist for these standard hardware and software stacks. Such is the price of efficiency.

Another significant issue is attack surface area. IOT provides a challenge for a traditional “defense in depth” security strategy, because the potential attack surface area is so large. For one thing, physical access to many IOT devices is much easier than it is to data-centric devices. While your servers and storage systems may represent a tremendous value to an attacker, those assets are also likely in a data center, with multiple layers of physical security controls preventing someone from simply walking up to the device. This is not necessarily so in the world of IOT devices, where, by their very nature, many assets are in the open: from door locks, to outdoor “smart” meters, to controllers located under the hood of a car, all of these IOT devices present a much greater challenge for – and greater likelihood of – physical attack. Another big differentiator between IOT and traditional devices is the relative immaturity of the software and firmware on the devices. Certainly, many IOT devices use mature OS platforms such as Linux, which have a rich set of security controls – but that doesn’t mean the IOT device vendors are using them, nor does it mean that the underlying proprietary firmware (effectively, the BIOS of the device) is secure. Issues such as auto-updating firmware from the vendor’s website without encryption or so much as a basic checksum test are known issues with some IOT vendors and their devices. And of course, the relatively personal nature of many IOT devices – customizing “your” car personality, or “your” home automation network, or “your” A/V system – often requires personal data on these devices, ranging from names and addresses to auto-billed credit card numbers. And that’s only the data that consumers themselves enter into devices; one can only imagine how much personal data and usage history that a utility company might keep on a “smart” meter, for example.

Reading this article, you might assume that the only really secure solution to security in the IOT is to cut the wire to all of our IOT devices, bury our heads in the sand, and hope for the best. Fortunately, it doesn’t have to be that way. Defense in depth, the most effective approach to traditional information security, works just as well in the IOT at preventing both data and kinetic attacks. As for the question of who is responsible for actually implementing that security, that’s a bit tricky. Certainly, consumers can be – and should be – responsible for securing the perimeter of many of their IOT devices. Ensuring that devices are physically secured away from public access (where possible), setting up a firewall to ensure that IOT devices within the home cannot directly communicate with the Internet, and enabling a strong security configuration on IOT devices – such as separate administrative and non-privileged users, strong password policies, and enabling the logging of security-related events – are all logical steps to implementing a defense in depth security strategy. Unfortunately, however, configuring security directly on IOT assets can be a difficult if not impossible task. In many (if not most) cases, IOT device vendors intentionally block the consumer from accessing or modifying the underlying configurations, APIs and other details of the device. While this is often well-meaning, it also presents a problem for responsible consumers who want to ensure their IOT devices are reasonably secure. So, in large part, it’s incumbent on IOT product vendors to either implement reasonable defense in depth security mechanisms into their products (and enable them by default), or at a minimum, provide an interface for consumers to implement their own security mechanisms such as disabling or improving security on web-based management interfaces, implementing on-device or in-transit encryption, providing enhanced authentication, firewalling, or even enhanced physical security. If 30-plus years have taught us anything, it’s that consumers will make personal computing, well… personal. Consumer-driven mods, hacks (in the positive, not malicious, sense of the word), and outright improvements to products will occur, regardless of whether OEMs and IOT product vendors want them to; this is particularly true as we enter a “maker renaissance” of sorts across global culture. If vendors don’t engineer proper security and threat mitigation into their products and product lifecycles, rest assured that consumers will do it for them regardless of how well they try to isolate the interface to their products – and that means a loss of control for vendors. My recommendation to them: do security the right way out-of-box, and you’ll maintain a product that is easier to manage, upgrade and maintain.

John Linkous is a security strategist at Promisec.

Leave a Reply

WWPI – Covering the best in IT since 1980