IoT devices typically have a finite set of remote endpoints and protocols that they communicate with. This
is the core premise around which an IETF standard called Manufacturer Usage Description (MUD) was
drafted. MUD (RFC-8520) became a proposed standard in 2019, but widespread industry adoption is still
pending.
The operating principle of MUD
The operating principle of MUD is the following: Any given IoT device manufacturer determines and
specifies all connections that their device is allowed to perform. Allowed connections are defined per
remote destination, protocol, and port number, which are structured into a device specific MUD file. This
file is distributed publicly by providing a URL, which is also embedded into the firmware of applicable
devices.
When a device gets eventually deployed and installed, it requests the MUD manager located on the local
network (typically on the gateway) to retrieve its MUD file via the given URL. The MUD manager retrieves
the file and enforces the specified connection rules as access control list entries. After the MUD file has
taken effect, normal operation may commence. From now on, any connections from a device exceeding the
boundaries defined by the manufacturer would be blocked. As an example, if a device got somehow
infected and attempted to communicate to e.g., a botnet controller host or a crypto pool, that would get
blocked because the manufacturer did not specify such connections to be allowed.
MUD is an effective and simple way of blocking and detecting anomalous communication, but its full
potential depends on device manufacturer commitment. While reputable manufacturers probably have
MUD support on their roadmap, the less reputable brands are likely among the last to adopt a technology
like MUD. This is particularly unfortunate since IoT devices from less reputable brands are typically more
prone to getting compromised and infected.
Top-down approach
As part of the research committed in SIFIS-Home, we explore the possibility to approach MUD from the
opposite direction. As an example, let’s consider a situation where we have an IoT device at hand which
does not support MUD. Lack of MUD support implies that we don’t have a MUD file for our device either.
However, what we can do is observe and monitor the network traffic of our device under inspection and
attempt to compile a MUD file ourselves. If given enough time and benign samples of traffic belonging to
the device under inspection, we can effectively transform collected data points into an access control list,
i.e., basically a reverse engineered MUD file. This file can then be used to determine if at some point in the
future our device gets compromised and starts communicating in unexpected ways.
About the author
Otto Waltari (Ph.D. 2020) is a research software engineer at F-Secure (Helsinki, Finland). His research interests in the field of networking focus on privacy and securing the not-so-secure Internet of Things.