Introduction
What is IoT?
The Internet of Things (IoT) is a set of ostensibly innumerable interconnected objects, services, users, and devices that can interact, exchange data and knowledge in numerous fields and applications to accomplish defined goals. There are many industries very well suited to take advantage of IoT applications, such as transport, agriculture, healthcare, electricity generation and delivery. In a series of identical and heterogeneous devices, IoT devices adopt an Identity Management technique to be defined. Similarly, the IoT area may be specified by an IP address, but each object has a specific device identifier within each region.
IoT Security Challenges
While cybersecurity is a somewhat acknowledged and established practice and industry niche within IT, many of the ‘traditional’ measures in this space aren’t apposite with IoT. Due to the unusual form-factors of many IoT devices – wireless lightbulbs, robotic vacuums, CCTV cameras, etc – there is a limited capability in terms of compute power and often power supply. This means the overhead of additional processes or daemons like security services is nearly impossible, and at best, impractical.
Compounding this limited footprint is the immaturity of the IoT industry in relation to established standards and practices. While there are some emerging efforts, as IoT is still a fairly new space, it is to be somewhat expected that standards understandably take some time to be created, tested, and ratified, let alone taking into account the lead-time for actual adoption. Further, as there’s a bit of a goldrush happening with IoT as manufacturers slap IoT capabilities on just about any imaginable device to increase interest (or at least novelty factor) and/or they rush their products to market to try and get traction. This means security measures are not considered as part of product design and development, merely addressed as a ‘To Do’ rather than with any serious consideration, and sadly, are indeed often ignored entirely.
The pitfalls of half-baked security efforts have become abundantly clear in recent years. While there are inherent limitations we can ‘forgive’ due to the limited compute power of IoT devices (it would be unrealistic to have a full-blown security solution on something the size of a coin), some of the more fundamental aspects of security like IoT password hygiene shouldn’t be too much of a stretch for IoT device security. The very ‘plug’n’play’ nature of IoT devices is necessary for user experience, particularly for home users. Often this means taking short-cuts to reduce deployment and adoption friction, and that includes authentication simplicity.
The boom & bust cycles of any goldrush sees so many organisations going out of business, or at least ending support for their solutions, and IoT manufacturers and vendors are a prime example. This has inevitably lead to ignoring security or firmware updates, even wilfully, for discovered issues in the name of cost-savings. This is compounded by the lifecycle of many IoT devices. While you may replace your phone and laptop every couple of years, it’s likely that your smarthome devices or IIoT devices have a much longer expected operational lifetime. This means more devices, and more device types deployed.
While IoT-rich greenfield projects have their own security concerns, the retro-fitting of IoT sensors to industrial machines often leads to greater complications and expenses than forecast. Such (often) unique hybrid devices sound like a compromise in the name of CAPEX, but the lack of manufacturer support can mean greater reliance on IT and Security teams that are already stretched for time and resources. Pair this with the increasing complexity of mixing IoT and standard Operational Technology (OT), and it doesn’t take long for security issues to become the proverbial leaking dike.
IoT Security
We need to see IoT as something akin to the ‘shared responsibility model’ adopted by many cloud providers. Some emerging frameworks like MUD help tackle security challenges at the technical level, but there needs to be clear demarcation of responsibilities between manufacturers and integrators/end-users. For example, the manufacturer must make concerted efforts to ensure the basics of device security are in place; authentication and encryption measures chief amongst. And the end-user needs to acknowledge that part of their due diligence during deployment is the use of secure password practices and ongoing audits and firmware updates etc.
IoT Compromises
We’ve seen some of the horror stories of IoT devices taken over by nefarious actors in the past decade. From hacking car computers, compromised baby monitors, to interfering with medical devices like pacemakers. While these all have a visceral reaction attached to them, many ‘uninteresting’ IoT compromises go unnoticed, if not by the target organisation, certainly by the media. These mundane hacks might just be the thermostat of an industrial appliance and have zero direct impact. The silent issue is, these attacks are often the first point of entry for threat actors before they pivot and further infiltrate the networks of the organisation.
An interview of our CEO, Adam de Jong with Karissa Breen touches upon many of the more challenging aspects of IoT in the real world
The compromise of SCADA-controlled critical infrastructure like we saw with the Triton attacks was a breath away from catastrophic outcomes, and the Strontium (APT28) attacks on IoT devices (VoIP phones, printers) had a peculiar parallel; they were different sides of the same coin. The Triton attacks were the terrifying outcome of a malware compromise of (essentially) IoT devices, and the IoT attacks from Strontium were the ingress attempts to gain a similar foothold within corporate networks rich with IIoT.
IoT Security – A Work In Progress
The DIGIT Act and subsequent SMART Act in the USA, the guidance from a privacy perspective of the GDPR in the EU, and of course the work being done by the IoT Alliance Australia are all putting a spotlight on IoT security and ushering in what we hope is a new expectations for manufacturers and integrators for IoT solutions across a socio-technical chasm.
As we’ve touched upon already, there have been a number of attempts to develop a standardised framework to deal with IoT security. Over the past 5-10 years we’ve seen concerted efforts from GSMA, OWASP, government initiatives like the Australian Government Department of Home Affairs and Australian Signals Directorate (ASD) security code of practice are all evolutionary steps in the right direction. We have yet to see, a truly unified framework developed, though there are a few worth covering in more detail.
The Device Identity Composition Engine (DICE) standard uses unique cryptographic keys for authentication. A hardware-based secret key is the ignition point for ostensibly a bootstrapping identity processes where the identity profile is checked and its software profile verified. DICE providers manufacturers a fairly robust, even if somewhat limited, security solution for inexpensive IoT devices by providing device authentication and validation, as well as also remote management of IoT devices, even in the event of malfunction or compromise.
The most significant we’ve seen is likely MUD – the Manufacturer Usage Description – a standard for embedded software from the Internet Engineering Task Force (IETF). Simply put, a MUD enabled IoT device has a profile ‘MUD URL’ as part of its request to network access point, enacting a transaction between the local network and (ultimately) the manufacturers server to provide verification & validation, and subsequently to set a device-appropriate policy for that device within the local network via Access Control Lists.
Both MUD and DICE are good attempts at an IoT baseline security framework. But far from perfect or complete. In both circumstances, there’s no fundamental security protections of their own. They themselves are potentially open to compromise and are forced to incrementally retrofit their flow control against existing networks.
