Help managing the growing number of Things on our networks has arrived

Things are generally lightweight single-purpose network devices. There are a great many number of Things connected to enterprise, consumer, and industrial networks. Many can be found on the Internet through search engines such as shodan.io. Already, deployment of connected things such as printers, thermostats, heaters, dryers, coffee makers, toasters, light bulbs, curtains, door bells, and sprinkler systems are outpacing deployment of laptops and cell phones on our networks. And there are a lot of types of Things, so many that we do not even know how to properly count them, or even how to group them into common categories. Put in other terms, we probably already do not have enough network administrators on the planet to understand what these Things are doing on our networks. In enterprise terms, that means that these devices are likely either not receiving the access they need, or they have too much access. The problem is made even worse by The Department Gap, where the IT department isn't even told what Things are being connected to the network by other teams in order to meet a critical business need.

Manufacturer Usage Descriptions

MUD attempts to address this problem by capitalizing on the assumptions that, unlike the general-purpose computers we use to surf the Web, IoT devices have a single or small number of uses, and that these uses may be tied to a predictable set of communications patterns. For example, it is unlikely that your Internet-enabled toothbrush–a real world device that uses a built-in camera to capture and report on dental hygiene–is going to need access to Netflix. If that toothbrush attempts to access Netflix, something fishy is happening. Since manufacturers are the ones that designed these Things, they are in a very good position to document what sort of access they need.

Put in terms that network administrators might find useful, device manufacturers are in a very good position to provide us most of what we need in IP-based access lists for their devices. MUD provides the basic framework to enable manufacturers to provide policy that can be used to generate IP-based access lists. The astute will notice that manufacturers cannot know what IP addresses should be listed in an access list. To address that issue, MUD establishes some abstractions, such as “my-controller”, “controller {URI}”, “same-manufacturer”, “manufacturer”, and the use of domain names, with the idea being that each will map to one or more devices that the device should be allowed to access, or not. These abstractions build upon and augment the IETF’s brand new access control list (ACL) model (RFC 8519). A simple example of how to construct a “MUD file” can be found at MUD File Maker.

The MUD file itself is served up via HTTPS, just like any other file. It thus has a URL associated with it. What is left is for devices to output that URL such that deployments can retrieve it. This can be done in any number of ways, including via DHCP (RFC 2131 and RFC 8415), Link Layer Discovery Protocol (LLDP), or, my favorite, via a device certificate in an EAP-TLS or Tunnel Extensible Authentication Protocol (TEAP) transaction (RFC 7170) .

So what’s the result of all of this? At the very least, it’s knowledge the network administrator can use to establish security policies that are appropriate for each device. And that means a smaller threat surface. Even better, that process can be automated for the administrator. A number of implementations have taken that step:

• osMUD.org offers an open source version of the MUD manager that can be used in consumer deployments.

• Google has developed a device automated qualification framework (DAQ) that makes use of MUD to establish profiles for corporate building infrastructure (among other things).

• The Canadian Internet Registration Authority (CIRA) has also developed a consumer-oriented MUD manager.
  

• Cisco released support for manual configuration of devices with MUD support in their Identity Services Engine product, and has developed a proof of concept implementation that can be used to test manufacturer intent.

• Yikes!, provides automated device classification and network security for small business and consumer networks, incorporated a MUD manager into their product. 

• NIST has developed an enterprise implementation based on OpenFlow.

• A number of lighting and building companies will be delivering MUD-enabled products over the next few months.

A key point to observe is that each of these MUD managers consumes a MUD file and then produces policy in a slightly different way. One has the MUD manager reside directly on the consumer router, one is more service provide focused and delivers policy down to the consumer router, and one makes use of a FreeRadius infrastructure to deliver updated per-session ACLs. There will be other approaches over time as the technology continues to mature.

Next steps

First, check out RFC 8520. It’s a page turner.

For manufacturers

Produce a MUD file for your device and maybe even test it against an implementation or two. To create a MUD file, go to MUD File Maker. If nothing else you will have documented what access your devices need. That’s a huge win, even for deployments that don’t automate access: at least you can point administrators to what access your devices need. And then have your device output a MUD URL. Guidance for this can be found at the Cisco DevNet site.

For enterprises and consumers

Ask for products that implement MUD. Ask manufacturers for their MUD files, so that you know what sort of access devices need. Consider implementing one of the MUD manager implementations mentioned above.

A final word of caution

We think MUD is pretty cool stuff, but it’s not a panacea. It’s part of a healthy breakfast, not the whole breakfast. For that, manufacturers need to do what they can to keep their devices secure, including providing security updates to customers, as well as using secure coding practices and taking advantage of hardware trust anchors available in some of the newest IoT platforms.