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
Crowdsourced vs. Traditional Pen Testing
Alex Haynes, Chief Information Security Officer, CDL,  3/19/2019
BEC Scammer Pleads Guilty
Dark Reading Staff 3/20/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
5 Emerging Cyber Threats to Watch for in 2019
Online attackers are constantly developing new, innovative ways to break into the enterprise. This Dark Reading Tech Digest gives an in-depth look at five emerging attack trends and exploits your security team should look out for, along with helpful recommendations on how you can prevent your organization from falling victim.
Flash Poll
The State of Cyber Security Incident Response
The State of Cyber Security Incident Response
Organizations are responding to new threats with new processes for detecting and mitigating them. Here's a look at how the discipline of incident response is evolving.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-7715
PUBLISHED: 2019-03-26
An issue was discovered in the Interpeak IPCOMShell TELNET server on Green Hills INTEGRITY RTOS 5.0.4. The main shell handler function uses the value of the environment variable ipcom.shell.greeting as the first argument to printf(). Setting this variable using the sysvar command results in a user-c...
CVE-2019-8981
PUBLISHED: 2019-03-26
tls1.c in Cameron Hamilton-Rich axTLS before 2.1.5 has a Buffer Overflow via a crafted sequence of TLS packets because the need_bytes value is mismanaged.
CVE-2019-10061
PUBLISHED: 2019-03-26
utils/find-opencv.js in node-opencv (aka OpenCV bindings for Node.js) prior to 6.1.0 is vulnerable to Command Injection. It does not validate user input allowing attackers to execute arbitrary commands.
CVE-2019-7711
PUBLISHED: 2019-03-26
An issue was discovered in the Interpeak IPCOMShell TELNET server on Green Hills INTEGRITY RTOS 5.0.4. The undocumented shell command "prompt" sets the (user controlled) shell's prompt value, which is used as a format string input to printf, resulting in an information leak of memory addre...
CVE-2019-7712
PUBLISHED: 2019-03-26
An issue was discovered in handler_ipcom_shell_pwd in the Interpeak IPCOMShell TELNET server on Green Hills INTEGRITY RTOS 5.0.4. When using the pwd command, the current working directory path is used as the first argument to printf() without a proper check. An attacker may thus forge a path contain...