Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Endpoint

7/30/2018
10:30 AM
Louis Creager
Louis Creager
Commentary
Connect Directly
LinkedIn
RSS
E-Mail vvv
100%
0%

MUD: The Solution to Our Messy Enterprise IoT Security Problems?

The 'Manufacturer Usage Description' proposal from IETF offers a promising route for bolstering security across the industry.

While Internet of Things (IoT) devices offer plenty of impressive capabilities that improve efficiency through industrial and workplace applications, they unequivocally continue to pose major security liabilities. Many IoT devices feature little or zero built-in security measures, making them enticing targets for hackers. At the same time, many companies plan to add a large number of IoT devices to their networks, increasing the challenge of identifying which devices are actually legitimate and limiting each device to only the access it requires.

While experienced network administrators might mitigate these shortcomings with access rules tailored to each IoT device or device category, this work is painstakingly cumbersome, offers no guarantees of security, and creates more work in an area where greater efficiency is the goal. In short, enterprises could certainly benefit from fundamental IoT security improvements at the device level.

The Proposed MUD Industry Standard
The Manufacturer Usage Description (MUD) specification, proposed and described in an Internet Engineering Task Force (IETF) draft document, offers a promising route for bolstering security across the IoT industry. MUD functions by enabling IoT devices to communicate with the networks they connect with and detailing the specific access and network functionality they require.

The MUD workflow is as follows. First, when the IoT device joins a network, it sends a MUD URL to the router. The router then functions as a MUD manager and visits the specified URL to retrieve a MUD file. The MUD manager then uses the information within the MUD file to put access rules in place that are recommended by the device's manufacturer.

In this way, enterprises can simply connect their IoT devices and the access and capabilities of those devices will be automatically limited to what is appropriate. Hackers may succeed in hijacking those devices but will be unable to corrupt the MUD file accessed online from the manufacturer. If an attacker attempts to direct a device to participate in a distributed denial-of-service attack, wreak havoc in an industrial environment, or collect and transfer sensitive information to an unfamiliar destination, MUD will not allow that activity to happen. Manufacturers still will need to address vulnerabilities and update firmware going forward, but MUD drastically reduces the harm that a compromised IoT device can actually inflict.

Can the MUD URL to which the Device Points Be Corrupted?
Hackers who understand this workflow could attempt to change the MUD URL to target their own false MUD file, one that allows the access needed to perform malicious activities. As drafted, MUD offers three choices for sending the MUD URL (and allows for others to be added in the future): the DHCP option, the X.509 extension, and the LLDP extension. Of these, the DHCP option and LLDP extension potentially could allow the MUD URL to be corrupted in scenarios where the IoT device becomes compromised. The X.509 extension distinguishes itself as more secure because the MUD URL is added to an identity certificate, either by the manufacturers when the device's IDevID is created or by another party in the supply chain with the creation of the LDevID.

How the 802.1AR Standard and DICE Support MUD Security
The IEEE 802.1AR standard specifies secure device identifiers, IDevIDs or LDevIDs, that are unique and cryptographically bound to individual devices. It also provides the capability to authenticate the identity of these devices. Devices utilizing this standard most often include a Trusted Platform Module (TPM) that stores cryptographic keys. Because the X.509 extension is added to the certificate for the IDevID or LDevID and stored on the TPM, the correct MUD URL is safeguarded through this verification. The IDevID can't be changed, and so neither can the MUD URL.

However, the size, cost, and power requirements of TPMs create severe limitations, making it impossible to rely on this method for securing all IoT devices. Thankfully, the Device Identifier Composition Engine (DICE) Architecture, offered by Trusted Computing Group, is up to the task of providing security to devices with these resource limits. Using DICE, even smaller IoT devices can store cryptographic keys and use the 802.1AR standard without the need for a TPM. Thus, they can use the X.509 extension and ensure the MUD URL is secure.

Looking forward, the promising MUD standard must be finalized as a draft document, and manufacturers of IoT devices and routers must then embrace the standard. If that happens, though issues will always remain, enterprises will have all the advantages of an IoT that is significantly safer and more secure.

Related Content:

Learn from the industry's most knowledgeable CISOs and IT security experts in a setting that is conducive to interaction and conversation. Register before July 27 and save $700! Click for more info

Louis Creager is an IoT security analyst at  * zvelo* , a provider of cybersecurity solutions for web content, network traffic, and connected/IoT devices. Prior to joining zvelo, Louis held security analyst and engineering roles at Trustwave, an information security ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Stop Defending Everything
Kevin Kurzawa, Senior Information Security Auditor,  2/12/2020
Small Business Security: 5 Tips on How and Where to Start
Mike Puglia, Chief Strategy Officer at Kaseya,  2/13/2020
5 Common Errors That Allow Attackers to Go Undetected
Matt Middleton-Leal, General Manager and Chief Security Strategist, Netwrix,  2/12/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
6 Emerging Cyber Threats That Enterprises Face in 2020
This Tech Digest gives an in-depth look at six emerging cyber threats that enterprises could face in 2020. Download your copy today!
Flash Poll
How Enterprises Are Developing and Maintaining Secure Applications
How Enterprises Are Developing and Maintaining Secure Applications
The concept of application security is well known, but application security testing and remediation processes remain unbalanced. Most organizations are confident in their approach to AppSec, although others seem to have no approach at all. Read this report to find out more.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-20477
PUBLISHED: 2020-02-19
PyYAML 5.1 through 5.1.2 has insufficient restrictions on the load and load_all functions because of a class deserialization issue, e.g., Popen is a class in the subprocess module. NOTE: this issue exists because of an incomplete fix for CVE-2017-18342.
CVE-2019-20478
PUBLISHED: 2020-02-19
In ruamel.yaml through 0.16.7, the load method allows remote code execution if the application calls this method with an untrusted argument. In other words, this issue affects developers who are unaware of the need to use methods such as safe_load in these use cases.
CVE-2011-2054
PUBLISHED: 2020-02-19
A vulnerability in the Cisco ASA that could allow a remote attacker to successfully authenticate using the Cisco AnyConnect VPN client if the Secondary Authentication type is LDAP and the password is left blank, providing the primary credentials are correct. The vulnerabilities is due to improper in...
CVE-2015-0749
PUBLISHED: 2020-02-19
A vulnerability in Cisco Unified Communications Manager could allow an unauthenticated, remote attacker to conduct a cross-site scripting (XSS) attack on the affected software. The vulnerabilities is due to improper input validation of certain parameters passed to the affected software. An attacker ...
CVE-2015-9543
PUBLISHED: 2020-02-19
An issue was discovered in OpenStack Nova before 18.2.4, 19.x before 19.1.0, and 20.x before 20.1.0. It can leak consoleauth tokens into log files. An attacker with read access to the service's logs may obtain tokens used for console access. All Nova setups using novncproxy are affected. This is rel...