How to mitigate IoT attacks using manufacturer usage description (MUD)
When you mention concepts like "the attack of the machines" to most people, the conversation usually goes along the lines of "Oh I loved that movie!" or leads into a heated conversation regarding the state of artificial intelligence. What a great number of people are not aware of though, is that attacks using basic appliances already happen on a daily basis, and their own toasters may be part of it.
The internet of things (IoT) has expanded the concept of connected devices to an absolutely enormous degree. Some items, such as thermostats, security cameras and smart home control systems are very easy to see and understand. Others such as refrigerators, coffee pots and even garage door openers may be significantly less visible, however.
These connected devices are built to serve a specific function, and usually on a shoestring budget. What this means is that there are enormous numbers of IoT devices out there that not only could be vulnerable to attack but very likely would never be patched, even if they are capable of doing so.
The National Institute of Standards and Technology (NIST) recently published a final draft of their recommendations on how to try to better protect and defend against IoT devices. Their publication "Securing Small-Business and Home Internet of Things (IoT) Devices: Mitigating Network-Based Attacks using Manufacturer Usage Description (MUD)," tries to establish a classification and permission system for IoT devices, which we are going to briefly break down.
Get NIST CSF training
Get NIST CSF training
As we mentioned before, IoT devices are usually cheap. Very cheap. This means that as a rule, trying to equip them with defense mechanisms against every possible threat that hasn't been thought of yet may not be feasible. The MUD, therefore, attempts to secure these devices by simply granting them the access they require and no more, keeping the heavy lifting on the network itself. In essence, we're creating a miniature DMZ zone around these devices, since logically we don't trust them and they would still be vulnerable even if we're placing them into a bubble.
MUD itself is a specification that the Internet Engineering Task Force (IETF) has helped to codify, giving incentive and reassurance to IoT device manufacturers that their devices will work as expected upon arrival. Any device that is considered to be 'MUD-Capable' broadcasts a 'MUD file,' a list of ports and protocols that the device needs to do its job- via HTTPS.
How the file is retrieved by the network can vary, from the Dynamic Host Configuration Protocol (DHCP) when the device first gets an IP address, to the Link Layer Discovery Protocol (LLDP) when the device is first attached to the network or even just as a signed certificate which can be read any number of ways. This may even not have to be on the device itself, but rather just be a feeder URL to point to a web server controlled by the manufacturer. In concept at least, this isn't all that different from how modern operating systems retrieve drivers when a new device is plugged in. In both scenarios, this is about systems learning how the devices work, but the MUD takes the added step of being able to learn best practices at the same time.
Once these files are received, they can be processed differently depending on how the network is managed. They could be manually checked by an administrator, with their access control lists (ACL) being adjusted by hand as required for instance. Other times in a much smaller environment, the MUD control software itself could live inside the router and automatically process the files themselves. This would then mean that the router would block off all non-essential traffic coming into and out of the IoT device without any required tweaks from a user. In a typical home environment, this function just on its own would radically increase defenses against outside threats to IoT devices.
We would obviously need to make sure that our networks support the standard either through hardware or software solutions. Cisco was already a part of the conceptual builds that NIST references and as such baked support for it into both its switches and its identity services engine (ISE). The workflow that Cisco showcases is what we could most likely expect from a typical implementation. the IoT device connects to our network and presents the URL that the MUD file can be retrieved from.
This is transferred up through the switch to the MUD controller. In this case ISE, or in our home example the router. The controller then accesses the MUD file server, wherever this may be, and then creates a policy based around those requirements, specifically allowing only what it requires, and then using a blanket deny for everything else. It then sends the policy wherever it needs to go, in Cisco's example back down to the switch which then updates the ACL stored there.
Even as the IETF says themselves, this is not a complete solution. This reduces the visibility of the IoT device considerably, but it doesn't change anything about the fact that the device itself may still be vulnerable. IoT manufacturers could still do a lot more to try to make it so that their devices can be easily updated when new threats arise, but again this raises costs. It also says nothing about the fact that time scales for appliances are far longer than they are for devices such as mobile phones. A support window measured in months is nothing compared to devices that may be in service for 20 years or more. So yes, MUD is absolutely something that we all can benefit from, but we've still got a long way to go.
NIST: SP 1800-15 Securing Small-Business and Home Internet of Things (IoT) Devices: Mitigating Network-Based Attacks Using Manufacturer Usage Description (MUD)
IBM Security: The weaponization of IoT devices: Rise of the thingbots
IETF News: Help managing the growing number of Things on our networks has arrived
Cisco: MUD is officially approved by IETF as an Internet Standard, and Cisco is launching MUD1.0 to protect your IoT devices
NIST Cyber Security Framework