Without the need to even reference any research, most network administrators would agree that Security is one of the biggest inhibitors to mass adoption of IoT (Internet of Things) in enterprises. IoT Devices, unlike their IT counterparts, tend to be architected for specific uses, with security (if at all present) being relegated in importance. Furthermore, many of these devices are lightweight, both from a compute capability and power consumption standpoint, obviating strapping on any sort of protective agent or anti-virus retrospectively.
You cannot protect what you cannot see
How does one secure such devices then, you may ask. This is a great question, one that continues to boggle the minds of enterprises that manage networks with connected IoT devices. It has emerged that such networks, take for example a hospital or a university campus, have anywhere from 40-60% of devices showing up as ‘unknown’ on the network administrator’s dashboard. Considering the scale of some of these deployments, with devices running into the tens of thousands, we have a problem on our hands as you cannot protect what you cannot see/identify.
Most of the unknowns are not computers, printers or tablets (IT endpoints), but devices such as IP security cameras, smart lights, connected medical devices, smart boards, etc. Attempts to manually assign identities to these endpoints have yielded suboptimal results, especially at scale. This problem is exacerbated by the increasing variety, or types of endpoints that are finding their way onto networks.
Now admittedly there are some products in the market that fingerprint IoT Devices using their attributes, so as to make an ‘informed guess’ of the device type, and restrict their access based on generic rules for those device types. In the absence of anything else, this may be a good enough solution, but in my opinion this approach suffers from 2 major drawbacks: guesswork for identity, and guesswork again for level of access to be granted to that device.
What if IoT devices could identify themselves to the network!
What If…What If an IoT device could advertise to the network in a simple, inexpensive and scalable manner its own identity, and its recommended communication pattern? Furthermore, what if all this could happen in an automated manner. Too good to be true, you might say. Maybe. But it IS TRUE. Enter……MUD (take a bow!). MUD stands for Manufacturer Usage Description, and is a Cisco pioneered open standard that has been approved by the IETF (Internet Engineering Task Force) in June 2018. https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/
MUD specifies a standard method for manufacturers to specify both device identity and the recommended communication patterns for that device type. The 10,000 feet view of the MUD process is depicted in the diagram below:
The MUD process lets manufacturers specify both device identity
and the recommended communication patterns for that device
In a nutshell, the manufacturer of a device embeds a url into the device itself, which is picked up by a core MUD process when the device first connects to a network. The MUD process classifies the device based on this url, and fetches it’s recommended communication patterns from an internet available MUD file server that the url points to. This abstracted policy is then applied to the access point that the IoT Device is connected to.
Tools on DevNet help developers build for MUD
For its part, Cisco has hosted a portal on its DevNet platform where you can get tools and info to help developers build for MUD, including tools to author the MUD url and the MUD file, as well as capabilities to test the validity of these components if they have been authored in another environment. Other features such as hosting services for MUD files (so that manufacturers do not have to stand up a dedicated back-end server of their own), and a SandBox environment to test the MUD elements in a Cisco environment, are on the radar.
And so, just like that, Cisco’s thought leadership has solved another global problem. Please go ahead and submit the next world problem that needs to be solved in the comments space below, or simply let us know what you think of this solution. And don’t forget to point your team to the MUD DevNet portal here to learn more about this simple yet effective solution that enhances IoT endpoint security with zero clicks.
We’d love to hear what you think. Ask a question or leave a comment below.
And stay connected with Cisco DevNet on social!
Twitter @CiscoDevNet | Facebook | LinkedIn
Visit the new Developer Video Channel
Thanks for the great information on using MUD to identify IoT devices in a network!
The additional information showing that this is an IETF-approved standard in the "Awaiting missing normative reference" state provides hope that this will be a published standard soon.
Cisco's hosting of the DevNet and Sandbox environments to assist developers that are working on tools and testing are much appreciated.
Really appreciate your comments.
You are right; the document is in the IESG RFC queue, awaiting publishing.
To your second comment on the SandBoxing and DevNet hosting facility, look out for those enhancements soon. In the interim, developers can use our sample code hosted on DevNet/ GitHub for determining validity of the MUD url.
Thanks for engaging on this portal once again; feedback and comments from potential users of the technology such as yourself will help us refine our features and messaging.
Comments are closed.