We’ve been working on a new technology at the Internet Engineering Task Force (IETF) to help Internet of Things (IoT) manufacturers and users protect themselves and others from vulnerabilities.
The basis of our work is: no matter how hard we try, IoT devices (or Things) will always have some vulnerability, which the network can provide a layer of protection against.
While it is easy to pass responsibility for protecting Things to the manufacturers — who are just learning about the Internet and security — it would also be hypocritical. After all, even we who have been doing this for decades still get it wrong from time to time.
Moreover, while we might be able to count the number of Things that are connecting, there is no easy way to count the types of Things that are connecting and, therefore, the types of policies that these Things require.
A great many Things have a set of design patterns that lend themselves to a convenient way to add network protection. Unlike general purpose computers, the designers know what sort of communication patterns these devices are likely to require — information useful for local deployments. This is the basis of a new IETF standard known as Manufacturer Usage Descriptions (MUD) (RFC 8520).
The MUD standard is open, which means that anyone can read it, implement it, and propose changes or extensions to it.
How does it work?
The good news is that MUD makes use of many mechanisms that have existed in routers and switches for decades. This includes a policy description in the form of access lists. The only trick is learning which access lists to use.
To accomplish this task, we have built upon a standard YANG ACL model to describe an abstract policy. To learn which abstract policy is appropriate for any particular Thing, the Thing will emit a URL to point to that policy.
Here is the workflow:
- A Thing informs the network of the URL in one of any number of ways, including DHCP, LLDP, or via a certificate in an IEEE 802.1X transaction. Once the device has done this, its job is done. The goal is to keep all of this as easy as possible for the manufacturer.
- Next, the URL is received from network infrastructure by a MUD manager. This component may reside in different places, depending on the nature of the network. In an enterprise, it may be called by the AAA server. In a consumer network, it may be provided by the service provider or by the customer router vendor. In a cellular network, it might be part of an operational support system (OSS).
- The MUD manager resolves the MUD URL and retrieves the abstract access control file. This file is a recommendation and not a directive to the administrator to explain what access the device is intended to have. IP addresses have been replaced with domain names or such abstractions as ‘my-controller’ or ‘same-manufacturer’ or ‘local-networks’. The idea being that a Thing may be designed to communicate with a single or small number of controllers or with similar Things, or that for some service, it should or should not have access to the local network.
- The MUD manager then translates these abstract access lists into something the local network infrastructure can consume. How that happens will vary based on network capabilities. Some networks may use ACLs and/or VLANs, while others may use OpenFlow or some other access control mechanism.
- An administrator may then approve, disapprove or edit the policy, based on deployment needs. This policy may be merged with other policies, such as who is using the device or where the device is deployed.
- Finally, the MUD manager delivers the configuration into the appropriate network infrastructure (for example, a switch, a packet gateway, or a home router). This might occur via Radius, NETCONF, or some other configuration protocol.
The result? The threat surface of the device is dramatically reduced to just the access that it was designed to have. Lights talk to switches, and heaters talk to thermostats, and neither talk to Netflix.
A recipe for success
Out of the 20 billion connected Things, a common Internet-enabled doll by a leading toy manufacturer only needs access to three domains on port 443, a UDP broadcast on the local network, and domain name and time services. A portion of its MUD file looks like this (the domain name has been changed):
{
"name": "from-ipv4-doll-5",
"matches": {
"ipv4": {
"protocol": 6,
"ietf-acldns:dst-dnsname": "storage.toy.example.com"
},
"tcp" : {
"destination-port": {
"operator": "eq",
"port": 443
},
"ietf-mud:direction-initiated": "from-device"
}
},
"actions": {
"forwarding": "accept"
}
}
There are far more complex examples. A University of New South Wales study found that enterprises often either over- or under-provision or access for such common systems as printers. Why? Because they have no idea what access those printers require.
Would you be surprised to learn, for example, that some printers make use of the XMPP (chat) protocol? MUD provides a means for manufacturers to explain all of this to customers in a standard way, even if customers do not want to automate access control mechanisms.
Who wins with MUD?
The first winners of this protection are device owners — even if a vulnerability is discovered, only a limited set of systems can attempt to exploit it.
The second winners are network administrators — they can inventory what sort of Things are connecting to the network, and what sort of policies they require. The administrator can also have at least some idea as to how many Things of a particular type with known vulnerabilities are on the network, easing risk assessment and remediation.
The third winners are manufacturers — by providing the local deployments with an explanation of what network resources are required for proper access, the administrators can take appropriate steps to see that the Thing gains that access, and no more. More importantly, MUD provides a way to limit the amount of telephone and web support calls and bad publicity that can follow when a device is compromised, providing savings on support, and limiting brand damage.
The fourth winners are the rest of us — when a device is compromised, it can be used to attack the owner or it can be used to attack someone else. This externality is the source of a great many botnet attacks. By adding this form of network-level protection, manufacturers and their customers can both protect themselves and others.
And so, it’s a win-win-win-win when MUD is used.
Do manufacturers only need to implement MUD?
Absolutely not. While MUD provides a means for device manufacturers to leverage local network capabilities to limit access to a device, manufacturers must still follow best design, coding, and operational practices. For example, there should always be an avenue to report vulnerabilities for a product, and manufacturers should always have a way to securely distribute those fixes.
Next steps
If you believe IoT security is important, and you further believe, as I do, we are currently very exposed, then here are some next steps you can take.
| Manufacturers |
|
| Network Managers |
|
| Service Providers |
|
If you want to learn more about MUD, check out the following sites:
- CIRA Labs MUD Manager
- The NIST OpenFlow MUD Manager
- Cisco VLAN-based Proof of Concept
- A MUD file generator with examples
- osMUD.org Home MUD implementation
- Fuller featured Commercial version of osMUD
And if you have any questions or comments you can join the mailing list mud@ietf.org or leave a comment below.
Eliot Lear is a Principal Engineer at Cisco Systems who focuses on IoT security, a co-creator of MUD, and a long-time Internet community member.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.