 | This is not a Wikipedia article: It is an individual user's work-in-progress page, and may be incomplete and/or unreliable. For guidance on developing this draft, see Wikipedia:So you made a userspace draft. Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
Manufacturer Usage Descriptions (MUD)
Manufacturer Usage Descriptions (MUD) refers to a standard by the Internet Engineering Task Force for describing communication patterns by IoT-based devices by their manufacturers. This provides network operators with some notion of what sort of network access these devices should be allowed.
Motivation
editThe basis of the work is that IoT-based devices will tend to have a single or small number of functions, and that the devices themselves may have vulnerabilities, leading to their compromise. If it is possible to describe the communication patterns expected from the device, then all other communications can be prevented at the network level, thus potentially limiting malicious traffic. For example, a thermostat may only need to communicate with a controller system somewhere on the Internet and not require any additional communication.
Architectural Components
editA manufacturer usage description is a standard developed by the Internet Engineering Task Force that specifies three components:
- A URL that points to a description file;
- A means by which devices may transmit that URL; and
- A file that details suggested policies about the device.[1]
The MUD URL that is expected to use HTTP over TLS ("https") to retrieve a MUD file. The standard defines three ways a device may transmit a MUD URL: LLDP, DHCP, and within an X.509 certificate through the use of EAP. The MUD file itself contains JSON that has been serialized from a YANG schema that describes policy that device manufacturers recommend be implemented by network deployments relating to that device. Among those policies are access control lists (ACLs). The MUD file for a thermostat would contain an access control list that only allows access to that specific cloud service. The purpose of MUD is, therefore, to reduce the number of systems that can attack a device. The local deployment receives these URLs and then retrieves the MUD files and acts on them as it sees fit. MUD files are not directives but rather suggestions to network administrators. How secure the mechanism itself is will largely depend on how MUD-URL is learned.[2]
MUD's focus is primarily on IoT-based devices because the assumption is that one can predict what devices it will talk to, either by class or by Internet hostname.[3] The benefit of such a declarative model is that it does not require observation of the device, nor inference by someone who did not design the device as to what is nominal versus anomalous behavior.
MUD's extension model has been contemplated for other uses, including declaration of privacy practices [4]
There are now several open source implementation of MUD managers, most notably one at osmud.org, as well as a version by Cisco.
References
edit- ^ Manufacturer Usage Descriptions, draft-ietf-opsawg-mud, 2018.
- ^ MUD: The Solution to Our Messy Enterprise IoT Security Problems?, [1], 2018.
- ^ Managing the Internet of Things – It’s All About Scaling[2],2018.
- ^ Meg Leta Jones, Ellen Kaufman, Elizabeth Edenberg, "AI and the Ethics of Automating Consent", Security & Privacy IEEE, vol. 16, no. 3, pp. 64-72, 2018.
External links
edit