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

7/30/2018
10:30 AM

Louis Creager
Louis Creager
Commentary
Connect Directly

LinkedIn
RSS
E-Mail vvv
100%
0%

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

Google Security Updates Include Titan Hardware Key

Kelly Sheridan, Staff Editor, Dark Reading,
 7/25/2018

The Double-Edged Sword of Artificial Intelligence in Security

Rodney Joffe, SVP and Senior Technologist, Neustar ,
 7/26/2018

Register for Dark Reading Newsletters

White Papers

Video

Cartoon Contest

Write a Caption, Win a Starbucks Card! Click Here

Latest Comment: “I bet you’ll wish you didn’t post that.”

Current Issue

Flash Poll

Twitter Feed
Dark Reading - Bug Report

Bug Report

Enterprise Vulnerabilities
From DHS/US-CERT’s National Vulnerability Database

CVE-2018-7957
PUBLISHED: 2018-07-31

Huawei smartphones with software Victoria-AL00 8.0.0.336a(C00) have an information leakage vulnerability. Because an interface does not verify authorization correctly, attackers can exploit an application with the authorization of phone state to obtain user location additionally.

CVE-2018-7992
PUBLISHED: 2018-07-31

Mdapt Driver of Huawei MediaPad M3 BTV-W09C128B353CUSTC128D001; Mate 9 Pro versions earlier than 8.0.0.356(C00); P10 Plus versions earlier than 8.0.0.357(C00) has a buffer overflow vulnerability. The driver does not sufficiently validate the input, an attacker could trick the user to install a malic…

CVE-2018-7993
PUBLISHED: 2018-07-31

HUAWEI Mate 10 smartphones with versions earlier than ALP-AL00 8.1.0.311 have a use after free vulnerability on mediaserver component. An attacker tricks the user install a malicious application, which make the software to reference memory after it has been freed. Successful exploit could cause exec…

CVE-2018-7994
PUBLISHED: 2018-07-31

Some Huawei products IPS Module V500R001C50; NGFW Module V500R001C50; V500R002C10; NIP6300 V500R001C50; NIP6600 V500R001C50; NIP6800 V500R001C50; Secospace USG6600 V500R001C50; USG9500 V500R001C50 have a memory leak vulnerability. The software does not release allocated memory properly when processi…

CVE-2017-17174
PUBLISHED: 2018-07-31

Some Huawei products RSE6500 V500R002C00; SoftCo V200R003C20SPCb00; VP9660 V600R006C10; eSpace U1981 V100R001C20; V200R003C20; V200R003C30; V200R003C50 have a weak algorithm vulnerability. To exploit the vulnerability, a remote, unauthenticated attacker has to capture TLS traffic between clients and…



*** This is a Security Bloggers Network syndicated blog from Trusted Computing Group authored by TCG Admin. Read the original post at: https://www.darkreading.com/endpoint/mud-the-solution-to-our-messy-enterprise-iot-security-problems/a/d-id/1332384#new_tab