NIST SPECIAL PUBLICATION 1800-15B


Securing Small-Business and Home Internet of Things (IoT) Devices

Mitigating Network-Based Attacks Using Manufacturer Usage Description (MUD)


Volume B:

Approach, Architecture, and Security Characteristics



Donna Dodson

Tim Polk

Murugiah Souppaya

NIST


William C. Barker

Dakota Consulting


Eliot Lear

Brian Weis

Cisco


Yemi Fashina

Parisa Grayeli

Joshua Klosterman

Blaine Mulugeta

Mary Raguso

Susan Symington

The MITRE Corporation


Dean Coclin

Clint Wilson

Digicert


Tim Jones

ForeScout


Jaideep Singh

Molex


Darshak Thakore

Mark Walker

CableLabs


Drew Cohen

MasterPeace



April 2019


PRELIMINARY DRAFT


This publication is available free of charge from https://www.nccoe.nist.gov/projects/building-blocks/mitigating-iot-based-ddos


nccoenistlogos




DISCLAIMER

Certain commercial entities, equipment, products, or materials may be identified in this document in order to describe an experimental procedure or concept adequately. Such identification is not intended to imply recommendation or endorsement by NIST or NCCoE, nor is it intended to imply that the entities, equipment, products, or materials are necessarily the best available for the purpose.

National Institute of Standards and Technology Special Publication 1800-15B, Natl. Inst. Stand. Technol. Spec. Publ. 1800-15B, 196 pages, (April 2019), CODEN: NSPUE2

FEEDBACK

You can improve this guide by contributing feedback. As you review and adopt this solution for your own organization, we ask you and your colleagues to share your experience and advice with us.

Comments on this publication may be submitted to: mitigating-iot-ddos-nccoe@nist.gov .

Public comment period: April 24, 2019 through June 24, 2019

All comments are subject to release under the Freedom of Information Act.

National Cybersecurity Center of Excellence
National Institute of Standards and Technology
100 Bureau Drive
Mailstop 2002
Gaithersburg, Maryland 20899
Email: nccoe@nist.gov

NATIONAL CYBERSECURITY CENTER OF EXCELLENCE

The National Cybersecurity Center of Excellence (NCCoE), a part of the National Institute of Standards and Technology (NIST), is a collaborative hub where industry organizations, government agencies, and academic institutions work together to address businesses’ most pressing cybersecurity issues. This public-private partnership enables the creation of practical cybersecurity solutions for specific industries, as well as for broad, cross-sector technology challenges. Through consortia under Cooperative Research and Development Agreements (CRADAs), including technology partners—from Fortune 50 market leaders to smaller companies specializing in information technology security—the NCCoE applies standards and best practices to develop modular, easily adaptable example cybersecurity solutions using commercially available technology. The NCCoE documents these example solutions in the NIST Special Publication 1800 series, which maps capabilities to the NIST Cybersecurity Framework and details the steps needed for another entity to re-create the example solution. The NCCoE was established in 2012 by NIST in partnership with the State of Maryland and Montgomery County, Maryland.

To learn more about the NCCoE, visit https://www.nccoe.nist.gov/. To learn more about NIST, visit https://www.nist.gov.

NIST CYBERSECURITY PRACTICE GUIDES

NIST Cybersecurity Practice Guides (Special Publication 1800 series) target specific cybersecurity challenges in the public and private sectors. They are practical, user-friendly guides that facilitate the adoption of standards-based approaches to cybersecurity. They show members of the information security community how to implement example solutions that help them align more easily with relevant standards and best practices, and provide users with the materials lists, configuration files, and other information they need to implement a similar approach.

The documents in this series describe example implementations of cybersecurity practices that businesses and other organizations may voluntarily adopt. These documents do not describe regulations or mandatory practices, nor do they carry statutory authority.

ABSTRACT

The goal of the Internet Engineering Task Force’s manufacturer usage description (MUD) architecture is for Internet of Things (IoT) devices to behave as intended by the manufacturer of the devices. This is done by providing a standard way for manufacturers to identify each device’s type and to indicate the network communications that it requires to perform its intended function. When MUD is used, the network will automatically permit the IoT device to send and receive the traffic it requires to perform as intended, and it will prohibit all other communications with the device.

The NCCoE has demonstrated for IoT product developers and implementers the ability to ensure that when an IoT device connects to a home or small-business network, MUD can be used to automatically permit the device to send and receive only the traffic it requires to perform its intended function.

A distributed denial of service (DDoS) attack can cause significant negative impact to an organization that is dependent on the internet to conduct business. A DDoS attack involves multiple computing devices in disparate locations sending repeated requests to a server with the intent to overload it and ultimately render it inaccessible. Recently, IoT devices have been exploited to launch DDoS attacks. IoT devices may have unpatched or easily discoverable software flaws, and many have minimal security, are unprotected, or are difficult to secure. A DDoS attack may result in substantial revenue losses and potential liability exposure, which can degrade a company’s reputation and erode customer trust. Victims of a DDoS attack can include

  • communications service providers who may suffer service degradation that affects their customers
  • businesses that rely on the internet who may suffer if their customers cannot reach them
  • IoT device manufacturers who may suffer reputational damage if their devices are being exploited
  • users of IoT devices who may suffer service degradation and potentially incur extra costs due to increased activity by their captured machines

Use of MUD combats these IoT-based DDoS attacks by prohibiting unauthorized traffic to and from IoT devices. Even if an IoT device becomes compromised, MUD prevents it from being used in any attack that would require the device to send traffic to an unauthorized destination. MUD provides a standard method for access control information to be available to network control devices. This NIST Cybersecurity Practice Guide shows IoT product and system providers how to integrate and use MUD to help make home and small-business networks more secure. It also shows what users should expect from IoT device manufacturers.

KEYWORDS

botnets; internet of things; IoT; manufacturer usage description; MUD; router; server; software update server; threat signaling.

DOCUMENT CONVENTIONS

The terms “shall” and “shall not” indicate requirements to be followed strictly to conform to the publication and from which no deviation is permitted.

The terms “should” and “should not” indicate that among several possibilities, one is recommended as particularly suitable, without mentioning or excluding others, or that a certain course of action is preferred but not necessarily required, or that (in the negative form) a certain possibility or course of action is discouraged but not prohibited.

The terms “may” and “need not” indicate a course of action permissible within the limits of the publication.

The terms “can” and “cannot” indicate a possibility and capability, whether material, physical, or causal.

CALL FOR PATENT CLAIMS

This public review includes a call for information on essential patent claims (claims whose use would be required for compliance with the guidance or requirements in this Information Technology Laboratory [ITL] draft publication). Such guidance and/or requirements may be directly stated in this ITL publication or by reference to another publication. This call also includes disclosure, where known, of the existence of pending U.S. or foreign patent applications relating to this ITL draft publication and of any relevant unexpired U.S. or foreign patents.

ITL may require from the patent holder, or a party authorized to make assurances on its behalf, in written or electronic form, either:

  1. assurance in the form of a general disclaimer to the effect that such party does not hold and does not currently intend holding any essential patent claim(s); or
  2. assurance that a license to such essential patent claim(s) will be made available to applicants desiring to utilize the license for the purpose of complying with the guidance or requirements in this ITL draft publication either:
    1. under reasonable terms and conditions that are demonstrably free of any unfair discrimination or
    2. without compensation and under reasonable terms and conditions that are demonstrably free of any unfair discrimination

Such assurance shall indicate that the patent holder (or third party authorized to make assurances on its behalf) will include in any documents transferring ownership of patents subject to the assurance, provisions sufficient to ensure that the commitments in the assurance are binding on the transferee, and that the transferee will similarly include appropriate provisions in the event of future transfers with the goal of binding each successor-in-interest.

The assurance shall also indicate that it is intended to be binding on successors-in-interest regardless of whether such provisions are included in the relevant transfer documents.

Such statements should be addressed to mitigating-iot-ddos-nccoe@nist.gov

ACKNOWLEDGMENTS

We are grateful to the following individuals for their generous contributions of expertise and time.

Name Organization
Allaukik Abhishek ARM
Michael Bartling ARM
Tao Wan CableLabs
Russ Gyurek Cisco
Peter Romness Cisco
Rob Cantu CTIA
Katherine Gronberg ForeScout
Adnan Baykal Global Cyber Alliance
Nate Lesser MasterPeace Solutions
Tom Martz MasterPeace Solutions
Daniel Weller MasterPeace Solutions
Kevin Yeich MasterPeace Solutions
Mo Alhroub Molex
Bill Haag NIST
Bryan Dubois Patton Electronics
Karen Scarfone Scarfone Cybersecurity
Matt Boucher Symantec
Bruce McCorkendale Symantec
Yun Shen Symantec
Pierre-Antoine Vervier Symantec
Sarah Kinling The MITRE Corporation
Mary Raguso The MITRE Corporation
Allen Tan The MITRE Corporation
Paul Watrobski University of Maryland
Russ Housley Vigilsec

The Technology Partners/Collaborators who participated in this build submitted their capabilities in response to a notice in the Federal Register. Respondents with relevant capabilities or product components were invited to sign a Cooperative Research and Development Agreement (CRADA) with NIST, allowing them to participate in a consortium to build this example solution. We worked with:

Technology Partner/Collaborator Build Involvement
Arm Subject Matter Expertise
CableLabs

Micronets Gateway

Service Provider Server

Partner and Service Provider Server

Prototype Medical Devices–Raspberry Pi

Cisco

Cisco Catalyst 3850S

MUD Manager

CTIA Subject Matter Expertise
DigiCert

Private Transport Layer Security (TLS) Certificate

Premium Certificate

ForeScout

CounterACT Appliance–VCT-R

Enterprise Manager–VCEM-05

Global Cyber Alliance Subject Matter Expertise
MasterPeace Solutions

Yikes! Router

Yikes! Cloud

Yikes! Mobile Application

Molex

Molex light emitting diode (LED) Light Bar

Molex power over ethernet (PoE) Gateway

Patton Electronics Session Border Controller—SN5301/4B/EUI
Symantec Subject Matter Expertise

List of Figures

Figure 4-1 Logical Architecture

Figure 4-2 Physical Architecture

Figure 4-3 Methods the ForeScout Platform Can Use to Discover and Classify IP-Connected Devices

Figure 4-4 Classify IoT Devices by Using the ForeScout Platform

Figure 4-5 Logical Architecture–Build 1

Figure 4-6 Physical Architecture–Build 1

Figure 4-7 Process Flow–Build 1

Figure 5-1 No MUD Protection Threat Scenario

Figure 5-2 MUD Protection from External Threats Scenario

Figure 5-3 MUD Protection from External and Internal Threats Scenario

Figure A-1 Yikes! Architecture

Figure A-2 Micronets Reference Architecture

List of Tables

Table 4-1 Products and Technologies

Table 5-1 Mapping Demonstration Platform Characteristics to NIST Interagency/Internal Report 8228 Expectations, NIST SP 800-53 Controls, and Cybersecurity Framework Subcategories

Table 5-2 Mapping Project Objectives to the Cybersecurity Framework and Informative Security Control References

Table 5-3 Summary of Functional Tests

Table D-1: Functional IoT Use Case Requirements

Table D-2: Test Case Fields

Table D-3: Test Case IoT-1-v4

Table D-4: Test Case IoT-2-v4

Table D-5: Test Case IoT-3-v4

Table D-6: Test Case IoT-4-v4

Table D-7: Test Case IoT-5-v4

Table D-8: Test Case IoT-6-v4

Table D-9: Test Case IoT-7-v4

Table D-10: Test Case IoT-8-v4

Table D-11: Test Case IoT-9-v4

Table D-12: Test Case IoT-10-v4

Table D-13: Test Case IoT-11-v4

Table D-14: Test Case IoT-12-v4

Table D-15: Test Case IoT-13-v4

Table D-16: Test Case IoT-14-v4

1. Summary

The Manufacturer Usage Description (MUD) Specification (Request for Comments [RFC] 8520) provides a means for IoT devices to signal to networks what sort of access and network functionality they require to properly function. The objective of this project is to show how IoT product and system manufacturers can use MUD to reduce the vulnerability of Internet of Things (IoT) devices to botnets and other automated distributed threats while limiting the utility of any compromised IoT devices to malicious actors. This volume describes the approach adopted for the project, the laboratory architecture demonstrated by the project, and the security characteristics demonstrated in the laboratory environment. The primary technical elements of this project include MUD-capable network gateways/routers supporting wired and wireless network access, MUD managers, MUD file servers, MUD-capable Dynamic Host Configuration Protocol (DHCP) servers, update servers, and threat signaling servers. We used personal computing devices, business computing devices, and both MUD-capable and non-MUD-capable IoT devices to demonstrate the security benefits provided by MUD. MUD will not provide perfect security, but it will significantly increase the effort required by malicious actors to compromise and exploit IoT devices on a home or small-business network. The scenarios examined by this National Cybersecurity Center of Excellence (NCCoE) project involve IoT devices being onboarded and used on home and small-business networks, where plug-and-play deployment is required. The example solution network includes MUD-capable IoT devices that interact with external systems to access secure updates and various cloud services, in addition to interacting with traditional personal computing devices, as permitted by their MUD files. The IoT devices used include smart lighting controllers, cameras, smartphones, printers, baby monitors, digital video recorders, and smart assistants.

1.1. Challenge

The term IoT is often applied to the aggregate of single-purpose, internet-connected devices, such as thermostats, security monitors, lighting control systems, and smart television sets. The IoT is experiencing what some might describe as hypergrowth. Gartner predicts there will be 20.4 billion connected IoT devices by 2020 compared with 8.4 billion in 2017, while Forbes forecasts the market to be $457 billion by 2020 (a 28.5 percent compounded annual growth rate). As connected devices become more commonplace in homes and businesses, security concerns are also increasing. Many full-featured devices such as web servers, personal or business computers, and mobile devices often have state-of-the-art security software protecting them from most known threats. Conversely, many IoT devices are challenging to secure because they are designed to be inexpensive and to perform a single function—resulting in processing, timing, memory, and power constraints. Nevertheless, the consequences of not addressing security concerns of connected devices can be catastrophic. For instance, in typical networking environments, malicious actors can detect an IoT device within minutes of it being connected and then launch an attack on that same device from any system on the internet, unbeknownst to the user. They can also commandeer a group of compromised devices, called a botnet, to launch large-scale attacks.

1.2. Solution

This project demonstrates an approach to significantly strengthen security while deploying IoT devices in home and small-business networks. This approach can help bolster the resiliency of IoT devices and prevent them from being used as platforms from which to mount DDoS attacks across the internet.

The NCCoE sought existing technologies that use the MUD Specification (Request for Comments [RFC] 8520) to permit an IoT device to signal to the network what sort of access and network functionality it requires to properly operate. Constraining the communication abilities of exploited IoT devices reduces the potential for the devices to be used in attacks—both DDoS attacks that could be launched across the internet and attacks on the IoT device’s local network that could have security consequences. This practice guide explains how to effectively implement the MUD specification for MUD-capable IoT devices and envisions methods for preventing non-MUD-capable IoT devices from connecting to potentially malicious entities that use threat signaling technology.

1.3. Benefits

This project provides benefits to several different types of stakeholders:

  • Communications service providers will benefit from reduction of the set of IoT devices that can be easily used by “bad actors” to participate in DDoS attacks against their networks and thereby degrade service for their customers.
  • Organizations and others who use the internet, including businesses that rely on their customers being able to reach them over the internet, as well as critical infrastructures and other public and private sector institutions, will benefit from improved confidence in internet availability and performance due to reductions in network-based attacks.
  • IoT device manufacturers will benefit by avoiding reputational damage that they might suffer if their devices could be easily exploited to conduct DDoS attacks.
  • Users of IoT devices, including small businesses and homeowners, will benefit from improved understanding of how to find and use the set of tools available to protect their internal networks from being subverted by bad actors and of how to reduce the threats to their businesses that can result from such subversion. By protecting their networks, they also avoid suffering increased costs and bandwidth saturation that could result from having their machines captured and used to launch network-based attacks.

2. How to Use This Guide

This National Institute of Standards and Technology (NIST) Cybersecurity Practice Guide demonstrates a standards-based reference design and provides users with the information they need to replicate deployment of the MUD protocol to mitigate IoT-based DDoS threats. This reference design is modular and can be deployed in whole or in parts.

This guide contains three volumes:

  • NIST Special Publication (SP) 1800-15A: Executive Summary
  • NIST SP 1800-15B: Approach, Architecture, and Security Characteristics–what we built and why (you are here)
  • NIST SP 1800-15C: How-To Guides–instructions for building the example solution

Depending on your role in your organization, you might use this guide in different ways:

Business decision makers, including chief security and technology officers, will be interested in the Executive Summary (NIST SP 1800-15A), which describes the:

  • challenges that enterprises face in mitigating IoT-based DDoS threats
  • example solution built at the NCCoE
  • benefits of adopting the example solution

Technology or security program managers who are concerned with how to identify, understand, assess, and mitigate risk will be interested in this part of the guide, NIST SP 1800-15B, which describes what we did and why. The following sections will be of particular interest:

  • Section 3.4.3, Risk, provides a description of the risk analysis we performed.
  • Section 5.2, Security Control Map, maps the security characteristics of this example solution to cybersecurity standards and best practices.

You might share the Executive Summary, NIST SP 1800-15A, with members of your leadership team to help them understand the importance of adopting use of standards-based mitigation of network-based distributed denial of service using MUD protocols.

IT professionals who want to implement an approach like this will find the whole practice guide useful. You can use the how-to portion of the guide, NIST SP 1800-15C, to replicate all or parts of the build created in our lab. The how-to guide provides specific product installation, configuration, and integration instructions for implementing the example solution. We do not re-create the product manufacturers’ documentation, which is generally widely available. Rather, we show how we incorporated the products together in our environment to create an example solution.

This guide assumes that information technology (IT) professionals have experience implementing security products within the enterprise. While we have used a suite of commercial products to address this challenge, this guide does not endorse these particular products. Your organization can adopt this solution or one that adheres to these guidelines in whole, or you can use this guide as a starting point for tailoring and implementing parts of the MUD protocol. Your organization’s security experts should identify the products that will best integrate with your existing tools and IT system infrastructure. We hope you will seek products that are congruent with applicable standards and best practices. Section 4.3, Technologies, lists the products we used, and Section 5.2 maps them to the cybersecurity controls provided by this reference solution.

A NIST Cybersecurity Practice Guide does not describe “the” solution, but a possible solution. This is a draft guide. We seek feedback on its contents and welcome your input. Comments, suggestions, and success stories will improve subsequent versions of this guide. Please contribute your thoughts to mitigating-iot-ddos-nccoe@nist.gov.

2.1. Typographic Conventions

The following table presents typographic conventions used in this volume.

Typeface/Symbol Meaning Example
Italics filenames and pathnames, references to documents that are not hyperlinks, new terms, and placeholders For detailed definitions of terms, see the NCCoE Glossary.
Bold names of menus, options, command buttons and fields Choose File > Edit.
Monospace
command-line input, on-screen computer output, sample code examples, status codes
mkdir
Monospace Bold
command-line user input contrasted with computer output
service sshd start
blue text link to other parts of the document, a web URL, or an email address All publications from NIST’s National Cybersecurity Center of Excellence are available at https://www.nccoe.nist.gov.

3. Approach

The NCCoE invited technology providers to participate in demonstrating a proposed approach for deployment of consumer and commercial IoT devices in home and small-business networks in a manner that provides significantly higher security than is typically achieved in today’s environments. In this project, current and emerging network standards are applied to home and business networks that are composed of both IoT and fully featured devices (e.g., personal computers and mobile devices) to constrain communications-based malware exploits. Network gateway components and security-aware IoT devices leverage the MUD Specification (RFC 8520) to permit a MUD-capable IoT device to signal to the network what sort of access and network functionality it requires to properly operate. The resulting access control capability reduces the potential for exploited MUD-capable IoT devices to be used in a DDoS attack by constraining their communication abilities. In addition, network components could in the future implement network-wide access controls based on threat signaling to protect legacy IoT devices, MUD-capable IoT devices, and fully featured devices (e.g., personal computers). Automatic secure update controls are implemented on all devices used in this project, and they support secure administrative access. (Note that software update formats for IoT devices are not currently standardized. NCCoE experiences with software update strategies will be contributed to emerging standardization activities.)

The NCCoE prepared a Federal Register Notice seeking technology providers to provide products and/or expertise to compose prototypes that include MUD-capable routers or switches; MUD managers; MUD file servers; MUD-capable DHCP servers; IoT devices capable of both inserting the MUD uniform resource locator (URL) into DHCP address requests and requesting, verifying, and applying software updates; update servers; and threat signaling servers. Cooperative Research and Development Agreements (CRADAs) were established with qualified respondents, and build teams were assembled. The build teams fleshed out the initial architecture, and the collaborators’ components were composed into example implementations. The build team documented the architecture and design implementation. As the build progressed, the team documented the steps taken to install and configure each component of the demonstration environment. The team then conducted functional testing of the demonstration environment, including demonstrating software update processes and responses to attempts to perform prohibited communications. The team conducted and documented the results of a risk assessment and a security characteristics analysis, including mapping the security contributions of the demonstrated capability to the Framework for Improving Critical Infrastructure Cybersecurity (Cybersecurity Framework) and other relevant standards. Finally, the NCCoE worked with industry collaborators to suggest future considerations for mitigating IoT-based DDoS threats.

3.1. Audience

The focus of this project is on home and small-business deployments. This guide is intended for

  • IoT device manufacturers, sensor manufacturers, networking companies, and industry groups
  • internet service providers (ISPs), venture capitalists, and Smart Cities interests
  • standards development organizations such as the Internet Engineering Task Force (IETF), foreign government organizations, and state/local governments having IoT authority and standards

3.2. Scope

The objective of this project is to demonstrate a proposed approach for deployment of IoT devices in home and small-business networks in a manner that provides significantly higher security than is typically achieved in today’s IoT environments. The scope of this NCCoE project includes both home and small-business applications where plug-and-play deployment is required. The demonstration prototype network includes MUD-capable IoT devices that interact with external systems to access secure updates and various cloud services, in addition to interacting with traditional personal computing devices, as permitted by their MUD files. It employs both MUD-capable and non-MUD-capable IoT devices, such as smart lighting controllers, cameras, smartphones, printers, baby monitors, digital video recorders, and smart assistants.

3.3. Assumptions

The primary technical elements of a MUD-capable home and small-business IoT system include

  • MUD managers
  • MUD file servers
  • MUD file and corresponding signature file
  • MUD-capable DHCP servers
  • MUD-capable routers or switches supporting wired and wireless network access
  • MUD-capable IoT devices
  • non-MUD-capable (legacy) IoT devices
  • personal computing devices (personal computers, tablets, and phones)
  • business computing devices
  • update servers

Cost is a major factor affecting consumer purchasing decisions and consequent product development decisions.

MUD-capable IoT devices deployed in environments that incorporate the networking and best practice controls included in this project should be able to only send traffic to and receive traffic from preapproved devices, such as associated cloud-based services or update servers. A malicious actor would need to compromise the professionally operated cloud service or update server to detect or launch an attack, and each compromise would apply only to devices that are designed to communicate with the compromised service or update server. Best practices for administrative access and security updates would reduce the success rate for attempted compromises. Previously long-lived vulnerabilities (global administrative passwords) or short-lived vulnerabilities (known vulnerabilities subject to security updates) would be unavailable. As a result, the malicious actor would be forced to use expensive zero-day attacks or socially engineered administrative passwords, which are not scalable. If an IoT device is compromised despite these controls, virtual network segmentation can prevent lateral movement within the home/enterprise or prevent attacking systems outside the preapproved list; in this situation, control of the IoT device would be of dubious value. Obtaining value from a compromised device would demand the additional step of integrity attacks on the list of approved communicating devices. That is, attacking www.example.com with a botnet of thermostats would require modifying the product vendor’s list of approved communicating devices to indicate that thermostats should be allowed to communicate with www.example.com.

3.4. Risk Assessment

NIST SP 800-30 Revision 1, Guide for Conducting Risk Assessments, states that risk is “a measure of the extent to which an entity is threatened by a potential circumstance or event, and typically a function of: (i) the adverse impacts that would arise if the circumstance or event occurs; and (ii) the likelihood of occurrence.” The guide further defines risk assessment as “the process of identifying, estimating, and prioritizing risks to organizational operations (including mission, functions, image, reputation), organizational assets, individuals, other organizations, and the Nation, resulting from the operation of an information system. Part of risk management incorporates threat and vulnerability analyses, and considers mitigations provided by security controls planned or in place.”

The NCCoE recommends that any discussion of risk management, particularly at the enterprise level, begins with a comprehensive review of NIST SP 800-37 Revision 2, Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy, material that is available to the public. The risk management framework (RMF) guidance as a whole proved invaluable in giving us a baseline to assess risks, from which we developed the project, the security characteristics of the build, and this guide.

According to CNSSI No. 4009, Committee on National Security Systems (CNSS) Glossary, risk management is “the program and supporting processes to manage information security risk to organizational operations (including mission, functions, image, reputation), organizational assets, individuals, other organizations, and the Nation, and includes: (i) establishing the context for risk-related activities; (ii) assessing risk; (iii) responding to risk once determined; and (iv) monitoring risk over time.” Considerations for Managing Internet of Things (IoT) Cybersecurity and Privacy Risks, NIST Interagency/Internal Report (NISTIR) 8228, identified security and privacy considerations and expectations that, together with the Framework for Improving Critical Infrastructure Cybersecurity (Cybersecurity Framework) and Security and Privacy Controls for Federal Information Systems and Organizations (NIST SP 800-53), informed our risk assessment and subsequent recommendations from which we developed the security characteristics of the build, and this guide.

3.4.1. Threats

Historically, internet devices have enjoyed full connectivity at the network and transport layers. Any pair of devices with valid internet protocol (IP) addresses was, in general, able to communicate by using transmission control protocol (TCP) for connection-oriented communications or User Datagram Protocol (UDP) for connectionless protocols. Full connectivity was a practical architectural option for fully featured devices (e.g., servers and personal computers) because the identity of communicating hosts depended largely on the needs of inherently unpredictable human users. Requiring a reconfiguration of hosts to permit communications to meet the needs of system users as they evolved was not a scalable solution. However, a combination of whitelisting device capabilities and blacklisting devices or domains that are considered suspicious allowed network administrators to mitigate some threats.

With the evolution of internet hosts from multiuser systems to personal devices, this security posture became impractical, and the emergence of the IoT has made it unsustainable. In typical networking environments, a malicious actor can detect an IoT device and launch an attack on that device from any system on the internet. Once compromised, that device can be used to attack any other system on the internet. Anecdotal evidence indicates that a new device will be detected and will experience its first attack within minutes of deployment. Because the devices being deployed often have known security flaws, the success rate for the compromise of detected systems is very high. Typically, malware is designed to compromise a list of specific devices, making such attacks very scalable. Once compromised, an IoT device can be used to compromise other internet-connected devices, launch attacks on any victim device on the internet, or move laterally within the local network hosting the device.

3.4.2. Vulnerabilities

The vulnerability of IoT devices in this environment is a consequence of full connectivity, exacerbated by the large number of security vulnerabilities in today’s complex software systems. Currently accepted coding practices result in approximately one software bug for every one thousand lines of code, and many of these bugs create security vulnerabilities. Modern systems ship with millions of lines of code, creating a target-rich environment for malicious actors. Although some vendors provide patches for security vulnerabilities and an efficient means for securely updating their products, patches are often unavailable or nearly impossible to install on many other products, including many IoT devices. Poorly implemented default configuration baselines and administrative access controls, such as hard-coded or widely known default passwords, provide a large attack surface for malicious actors. Once again, IoT devices are particularly vulnerable. The Mirai malware relied heavily on hard-coded administrative access to assemble botnets consisting of more than 100,000 devices.

3.4.3. Risk

The demonstrated capability implements a set of protocols designed to permit users and product support staff to constrain access to IoT devices. Implementation for some but not all IoT components in a system mitigates only the threat based on subversion of those devices. The system as a whole remains vulnerable. A residual risk is that the implementation of the demonstrated capability may be prophylactic only. It does not necessarily permit owners to find, identify, and correct already-compromised systems without replacing or reprogramming existing system components.

For example, if a system is compromised so that it emits a new URL referencing a MUD file that permits malicious actors to send traffic to and from the IoT device, MUD may not be able to help owners detect such compromised systems and stop the communications that should be prohibited. However, if a system is compromised but it is still emitting the correct MUD URL, MUD can detect and stop any unauthorized communications that the device attempts. Such attempts would also indicate potential compromises.

If a network is set up so that it uses legacy IoT devices that do not emit MUD URLs, these devices could be associated with MUD files by connecting the devices to specific ports and associating each port with a MUD file appropriate to the device. If the device is compromised and attempts unauthorized communication, the attempt should be detected. That is, the device would still be subjected to the constraints specified in its MUD file. Under these circumstances, MUD can permit the owner to find and identify already-compromised systems. Moreover, where threat signaling is employed, a compromised system that reaches back to a known bad internet protocol (IP) address can be detected, and the connection can be refused.

4. Architecture

The project architecture is intended for home and business networks that are composed of both IoT (e.g., single-purpose) and fully featured devices (e.g., personal computers and mobile devices) to constrain communications-based malware exploits. The architecture is designed to provide three forms of protection:

  • use of the MUD specification to permit a MUD-capable IoT device to signal to the network what sort of access and network functionality it requires to properly operate, thereby reducing the potential for the device to be used in a DDoS attack
  • use of network-wide access controls based on threat signaling to protect legacy (non-MUD-capable) IoT devices and fully featured devices in addition to MUD-capable devices
  • automatic secure software updates to all devices to ensure that operating system (OS) patches are installed promptly

4.1. Logical Architecture

Figure 4-1 depicts the logical architecture. A new functional component, the MUD manager, is introduced into the home or enterprise network to augment the existing networking functionality offered by the router or switch: address assignment and control of access to devices.

IoT devices insert the MUD URL into DHCP address requests that they generate when they attach to the network (e.g., when powered on). The MUD URL is passed to the MUD manager, which retrieves a MUD file from the designated website (denoted as the MUD file server) using https. The MUD file describes the communications requirements for this device; the MUD manager converts the requirements into traffic filters (e.g., access control lists—ACLs) that are installed on the router or switch to enforce access controls on the network. This enables the router or switch to deny traffic sent to or from the IoT device that is outside the device’s communications profile.

To provide further security, periodic updates are incorporated into the architecture. IoT devices periodically contact the appropriate update server to download and apply security patches. To ensure that such updates are possible, the IoT device’s MUD file must explicitly permit the IoT device to receive traffic from the update server.

The router or switch could also periodically receive threat feeds from the threat signaling server to use as a basis for restricting certain types of network traffic. For example, malicious traffic can be denied access to a device by a cloud-based or infrastructure service like domain name system (DNS), with detailed threat information, including type, severity, and mitigation available to the router or switch on demand. (Note that although threat signaling is part of the logical architecture, it is not part of the current build. Threat signaling is planned for inclusion in a later phase of the project.)

Figure 4-1 Logical Architecture

image1

Note that communications between the MUD manager and router/switch, between the threat signaling server and router/switch, and between IoT devices and the corresponding update server are not standardized.

The components of this architecture will not provide perfect security, but they will significantly increase the effort required by malicious actors to compromise and exploit IoT devices on a home or small-business network.

The components shown in the high-level architecture are described in Section 4.3 below.

4.2. Physical Architecture

Figure 4-2 depicts the high-level physical architecture of the NCCoE laboratory implementation. This implementation supports the flexibility to implement additional builds in the future. As depicted, the NCCoE laboratory network is connected to the internet via the NIST data center. Access to and from the NCCoE network is protected by a firewall. The NCCoE network includes a virtual environment that houses an update server, a MUD file server, an unapproved server (i.e., a server that is not listed as a permissible communications source or destination in any MUD file), a Message Queuing Telemetry Transport (MQTT) Broker Server, and ForeScout Enterprise Manager. (Note that although threat signaling is part of the logical architecture, there is currently no threat signaling server included in the laboratory network’s virtual environment; threat signaling is planned for inclusion in a later phase of the project.) These components are hosted at NCCoE and will be used across builds. The Transport Layer Security (TLS) certificate and Premium certificate used by the MUD file server are provided by DigiCert.

Only Build 1, as depicted in the diagram, has been implemented during this phase of the project. Build 2 and Build 3 will be part of the next phase of the project. Build 1 network components consist of a Cisco Catalyst 3850-S switch, a Cisco MUD Manager, a FreeRADIUS Server, and a virtualized ForeScout CounterACT appliance. IoT devices used in this architecture include both MUD-capable and non-MUD-capable IoT devices. The MUD-capable IoT devices for Build 1 include Raspberry Pi, Artik, u-blox, Intel UP Squared, and the Molex Light Engine controlled by Power Over Ethernet (PoE) Gateway. Non-MUD-capable devices chosen for Build 1 include a wireless access point, cameras, a printer, smartphones, lighting devices, a smart assistant device, a baby monitor, and a digital video recorder. Build 1 and the role that each of its components plays in the architecture are explained in more detail in Section 4.3 and Section 4.4.

Figure 4-2 Physical Architecture

image2

4.3. Technologies

Table 4-1 lists all the products and technologies used in this project and provides a mapping among the generic component term, the specific product used to implement that component, and the security control(s) that the product provides. Some functional Subcategories are described as being directly provided by a component. Others are described as Subcategories, the provision of which is supported by a component but not directly provided by a component. Refer to Table 5-1 for an explanation of the Cybersecurity Framework’s Subcategory codes.

Table 4-1 Products and Technologies

Component Product Function Cybersecurity Framework Subcategories
MUD manager Cisco MUD Manager (Open Source) and a FreeRADIUS Server Fetches, verifies, and processes MUD files from the MUD file server; configures router or switch with traffic filters to enforce access control based on the MUD file

Provides: PR.PT-3

Supports: ID.AM-1 ID.AM-2 ID.AM-3 PR.AC-4 PR.AC-5 PR.DS-5 DE.AE-1

MUD file server NCCoE-hosted Apache server Hosts MUD files; serves MUD files to the MUD Manager by using https ID.AM-1 ID.AM-2 ID.AM-3 PR.AC-4 PR.AC-5 PR.DS-5 PR.PT-3 DE.AE-1
MUD file maker MUD File Maker (https://www.mudmaker.org/) YANG script GUI used to create MUD files ID.AM-1
MUD file A YANG model instance that has been serialized in javascript object notation (JSON) [RFC7951]. The manufacturer of a MUD-capable device creates that device’s MUD file. MUD file maker (see previous row) can be used to create MUD files. Each MUD file is also associated with a separate MUD signature file. Specifies the communications that are permitted to and from a given device

Provides: PR.PT-3

Supports: ID.AM-1 ID.AM-2 ID.AM-3

DHCP server Cisco IOS (Catalyst 3850-S) Dynamically assigns IP addresses; recognizes MUD URL in DHCP DISCOVER; should notify MUD manager if the device’s IP address lease expires or has been released ID.AM-3 PR.AC-4 PR.AC-5 PR.DS-5 PR.PT-3 DE.AE-1
Link Layer Discovery Protocol (LLDP) Cisco IOS (Catalyst 3850-S) Supports capability for devices to advertise their identity and capabilities to neighbors on a local area network (LAN) segment; provides capability to receive MUD URL in IoT device LLDP Type Length Value (TLV) frame as an extension ID.AM-1
Router or switch Cisco Catalyst 3850-S (IOS XE software version 16.09.02) Provides MUD URL to MUD manager; gets configured by the MUD manager to enforce the IoT device’s communication profile; performs per-device access control ID.AM-3 PR.AC-4 PR.AC-5 PR.DS-5 PR.PT-3 DE.AE-1
Certificates DigiCert Certificates (TLS and Premium) Authenticates MUD file server and secures TLS connection between MUD manager and MUD file server; used to sign MUD files and generate corresponding signature file PR.AC-1 PR.AC-3 PR.AC-5 PR.AC-7
MUD-capable IoT device

Raspberry Pi Model 3B (Devkit)

u-blox C027-G35 (Devkit)

Samsung ARTIK 520 (Devkit)

Intel UP Squared Grove (Devkit)

Molex PoE Gateway and Light Engine

Emits a MUD URL as part of its DHCP DISCOVER; requests and applies software updates ID.AM-1
Non-MUD-capable IoT device

Cameras

Smartphones

Smart lighting devices

Smart assistant

Printer

Baby monitor

Wireless access point

Digital video recorder

Acts as typical IoT devices on a network; creates network connections to cloud services ID.AM-1
Update server NCCoE-hosted Apache server Molex Update Agent Provides patches and other software updates PR.IP-1 PR.IP-3
Unapproved server NCCoE-hosted Apache server Acts as an internet host that has not been explicitly approved in a MUD file DE.DP-3 DE.AM-1
MQTT Broker Server NCCoE-hosted MQTT server Receives and publishes messages to/from clients ID.AM-3 DE.AE-3
IoT Device Discovery ForeScout CounterACT Virtual Appliances and Enterprise Manager Discovers IoT devices on network ID.AM-1 PR.IP-1 DE.AM-1

Each of these components is described more fully in the following sections.

4.3.1. MUD Manager

The MUD manager is a key component of the architecture. It fetches, verifies, and processes MUD files from the MUD file server. It then configures the router or switch with an access list to control communications based on the contents of the MUD files.

4.3.1.1. Cisco MUD Manager

The Cisco MUD Manager is an open-source implementation. For this project, the Cisco MUD Manager was used to support IoT devices that emit their MUD URLs via DHCP messages and other IoT devices that emit their MUD URLs via the IEEE 802.1AB LLDP. The Cisco MUD Manager is supported by an open-source implementation of an authentication, authorization, and accounting (AAA) server that communicates by using the remote authentication dial-in user service (RADIUS) protocol (i.e., a RADIUS server) called FreeRADIUS. When the MUD URL is emitted via DHCP or LLDP, it is extracted from the corresponding message, and the switch thereafter provides these MUD URLs to the MUD manager via RADIUS messages. The MUD manager then retrieves MUD files associated with those URLs and configures the Catalyst 3850-S switch to enforce the IoT devices’ communication profiles based on these MUD files. The switch implements an IP access control list -based policy for src-dnsname, dst-dnsname, my-controller, and controller constructs that are specified in the MUD file, and it uses virtual local area network (VLANs) to enforce same-manufacturer, manufacturer, and local-networks constructs that are specified in the MUD file. The system supports both lateral “east–west” protection and appropriate access to internet sites (“north–south” protection).

When supporting MUD URL emission by LLDP TLV, LLDP TLV must be enabled on both the Cisco switch and the IoT device. A policy-map configuration and a corresponding template are used to cause MAC Authentication Bypass (MAB) to happen. This will trigger an access-session attribute that will cause LLDP TLVs (including the MUD URL) to be forwarded in an accounting message to the RADIUS server.

Some manual preconfiguration of VLANs on the switch is required. The Cisco MUD Manager supports a default policy for IPv4. It implements a static mapping between domain names and IP addresses inside a configuration file.

The version of the Cisco MUD Manager used in this project is a proof-of-concept implementation that is intended to introduce advanced users and engineers to the MUD concept. It is not a fully automated MUD manager implementation, and some protocol features are not present. These are described in Section 6.1, Findings.

4.3.2. MUD File Server

In the absence of a commercial MUD manager for use in this project, the NCCoE implemented its own MUD file server by using an Apache web server. This file server signs and stores the MUD files along with their corresponding signature files for the IoT devices used in the project. Upon receiving a “GET” request for the MUD files and signatures, it serves the request to the MUD manager by using https.

4.3.3. MUD File

Using the MUD file maker component referenced above in Table 4-1, it is possible to create a MUD file with the following contents:

  • Internet communication class–access to cloud services and other specific internet hosts:

    • Host: updateserver (hosted internally at the NCCoE)

      • Protocol: TCP
      • Direction-initiated: from IoT device
      • Source port: any
      • Destination port: 80
  • Controller class–access to classes of devices that are known to be controllers (could describe well-known services such as DNS or Network Time Protocol—NTP):

    • Host: mqttbroker (hosted internally at the NCCoE)

      • Protocol: TCP
      • Direction-initiated: from IoT device
      • Source port: any
      • Destination port: 1883
  • Local-networks class–access to/from any local host for specific services (e.g., http or https):

    • Host: any

      • Protocol: TCP
      • Direction-initiated: from IoT device
      • Source port: any
      • Destination port: 80
  • My-controller class–access to controllers specific to this device:

    • Controllers: null (to be filled in by the network administrator)

      • Protocol: TCP
      • Direction-initiated: from IoT device
      • Source port: any
      • Destination port: 80
  • Same-manufacturer class–access to devices of the same manufacturer:

    • Same-manufacturer: null (to be filled in by the MUD manager]

      • Protocol: TCP
      • Direction-initiated: from IoT device
      • Source port: any
      • Destination port: 80
  • Manufacturer class–access to devices of a specific manufacturer (identified by MUD URL):

    • Manufacturer: devicetype (URL decided by the device manufacturer)

      • Protocol: TCP
      • Direction-initiated: from IoT device
      • Source port: any
      • Destination port: 80
4.3.3.1. Signature file

According to the IETF MUD specification, “a MUD file MUST be signed using CMS as an opaque binary object.” The MUD file (ciscopi2.json) was signed with the OpenSSL tool by using the command described in the specification (this will be detailed in Volume C of this publication). A Premium certificate, requested from DigiCert, was leveraged to generate the signature file (ciscopi2.p7s). Once created, the signature file is stored on the MUD file server.

4.3.4. DHCP Server

The DHCP server in the architecture is MUD-capable. In addition to dynamically assigning IP addresses, it recognizes the DHCP option (161) and extracts the MUD URL from the IoT device’s DHCP message. The MUD URL is provided to the MUD manager. The DHCP server is typically embedded in a router/switch. This project uses the DHCP server that is embedded in the Cisco Catalyst 3850-S.

4.3.4.1. Cisco DHCP Server

Cisco IOS provides a basic DHCP server that is useful in small-/medium-business and home network environments, where centralized address management is not required. As described in the previous section, the DHCP server in this case is configured to allocate addresses for the test network, provide a default router, and configure a domain name server. It is not used to deliver MUD URLs to the MUD manager.

4.3.5. Router/Switch

This project uses the Cisco Catalyst 3850-S switch.

4.3.5.1. Cisco Catalyst 3850-S

The Cisco Catalyst 3850-S is an enterprise-class layer 3 switch capable of Universal PoE for digital building solutions. The optional PoE feature means it can be configured to supply power to capable devices over Ethernet through its ports. In addition to providing DHCP services, the switch also acts as a broker for connected IoT devices for AAA through the FreeRADIUS server. The LLDP is enabled on ports that MUD-capable devices are plugged into to help facilitate recognition of connected IoT device features, capabilities, and neighbor relationships at layer 2. Additionally, an access session policy is configured on the switch to enable port control for multihost authentication and port monitoring. The combined effect of these switch configurations is a dynamic access list, which has been generated by the MUD manager, being active on the switch to permit or deny access to and from MUD-capable IoT devices. The version of the Cisco Catalyst switch used in this project is a proof-of-concept implementation that is intended to introduce advanced users and engineers to the MUD concept. Some protocol features are not present. These are described in Section 6.1, Findings.

4.3.6. Certificates

DigiCert’s CertCentral™ web-based platform allows for provisioning and managing publicly trusted X.509 certificates for TLS and code signing as well as a variety of other purposes. After establishing an account, clients can log in, request, renew, and revoke certificates using only a browser. Multiple roles can be assigned within an account, and a discovery tool can be used to inventory all certificates within the enterprise. In addition to certificate-specific features, the platform also offers baseline enterprise software as a service (SaaS) capabilities, including role-based access control (RBAC), security assertion markup language (SAML), single sign-on (SSO), and security policy management and enforcement. All account features come with full parity between the web portal and a publicly available application programming interface (API). For this implementation, two certificates were provisioned: a private TLS certificate for the MUD file server to support the https connection from the MUD manager to the MUD file server, and a Premium certificate for signing the MUD files.

4.3.7. IoT Devices

This section describes the IoT devices used in the laboratory implementation. There are two distinct categories of devices: devices that are capable of emitting a MUD URL in compliance with the MUD specification, i.e., MUD-capable IoT devices; and devices that are not capable of emitting a MUD URL in compliance with the MUD specification, i.e., non-MUD-capable IoT devices.

4.3.7.1. MUD-Capable IoT Devices

The project used several MUD-capable IoT devices: NCCoE Raspberry Pi (Devkit), u-blox C027-G35 (Devkit), Samsung ARTIK 520 (Devkit), Intel UP Squared Grove (Devkit), Molex PoE Gateway, and Molex Light Engine. The devkits were modified by the NCCoE to simulate IoT devices. All of the MUD-capable IoT devices demonstrate the ability to emit a MUD URL as part of a DHCP transaction or LLDP message and to request and apply software updates.

4.3.7.1.1. Molex PoE Gateway and Light Engine

This set of IoT devices was developed by Molex. The PoE Gateway acts as a network end point and manages lights, sensors, and other devices. One of the devices managed by the PoE Gateway is a light engine that was provided by Molex.

4.3.7.1.2. NCCoE Raspberry Pi (Devkit)

The Raspberry Pi devkit runs the Raspbian 9 operating system. It is configured to include a MUD URL that it emits during a typical DHCP transaction. The NCCoE developed a Python script that allowed the Raspberry Pi to receive and process on and off commands by using the MQTT protocol, which were sent to the light-emitting diode (LED) bulb connected to the Raspberry Pi.

4.3.7.1.3. NCCoE u-blox C027-G35 (Devkit)

The u-blox C027-G35 devkit runs the ARM Mbed operating system. The NCCoE modified several of the Mbed-OS libraries to configure the devkit to include a MUD URL that it emits during a typical DHCP transaction. The u-blox devkit is also configured to initiate network connections to test network traffic throughout the MUD process.

4.3.7.1.4. NCCoE Samsung ARTIK 520 (Devkit)

The Samsung ARTIK 520 devkit runs the Fedora 24 operating system. It is configured to include a MUD URL that it emits during a typical DHCP transaction. The same Python script mentioned earlier was used to simulate a smart lock. This Python script allowed the ARTIK devkit to receive on and off commands by using the MQTT protocol.

4.3.7.1.5. NCCoE Intel UP Squared Grove (Devkit)

The Intel UP Squared Grove devkit runs the Ubuntu 16.04 LTS operating system. It is configured to include a MUD URL that it emits during a typical DHCP transaction. The same Python script mentioned earlier was used to simulate a smart lighting device. This allowed the UP Squared Grove devkit to receive on and off commands by using the MQTT protocol.

4.3.7.2. Non-MUD-Capable IoT Devices

The laboratory implementation also includes a variety of legacy, non-MUD-capable IoT devices that are not capable of emitting a MUD URL. These include cameras, smartphones, lighting, a smart assistant, a printer, a baby monitor, a wireless access point, and a digital video recorder (DVR).

4.3.7.2.1. Cameras

The three cameras utilized in the laboratory implementation are produced by two different manufacturers. They stream video and audio either to another device on the network or to a cloud service. These cameras are controlled and managed by a smartphone.

4.3.7.2.2. Smartphones

Two types of smartphones are used for setting up, interacting with, and controlling IoT devices.

4.3.7.2.3. Lighting

Two types of smart lighting devices are used in the laboratory implementation. These smart lighting components are controlled and managed by a smartphone.

4.3.7.2.4. Smart Assistant

A smart assistant is utilized in the laboratory implementation. The device is used to demonstrate and test the wide range of network traffic generated by a smart assistant.

4.3.7.2.5. Printer

A smart printer is connected to the laboratory network wirelessly to demonstrate smart printer usage.

4.3.7.2.6. Baby Monitor

A baby monitor with remote control plus video and audio capabilities is connected wirelessly to the laboratory network. This baby monitor is controlled and managed by a smartphone.

4.3.7.2.7. Wireless Access Point

A smart wireless access point is used in the laboratory implementation to demonstrate the network activity and functionality of this type of device.

4.3.7.2.8. Digital Video Recorder

A smart DVR is also connected to the laboratory implementation network. This is also controlled and managed by a smartphone.

4.3.8. Update Server

The update server provides patches and other software updates to the IoT devices. This project used an NCCoE-hosted update server.

4.3.8.1. NCCoE Update Server

The NCCoE implemented its own update server by using an Apache web server. This file server hosts software update files to be served as software updates to the IoT device devkits. When the server receives an http request, it sends the corresponding update file.

4.3.8.2. Molex Update Agent

The process for updating the firmware on a Molex PoE Gateway is currently a manual process, with the firmware update taking place over the CoAP, UDP, and trivial file transfer protocol (TFTP) protocols. The update process is initiated by an update agent on the local network connecting to the PoE Gateway and sending the firmware update information.

4.3.9. Unapproved Server

The NCCoE implemented its own unapproved server by using an Apache web server. This web server acts as an unapproved internet host, i.e., an internet host that is not explicitly approved in the MUD File. This was created to test the communication between a MUD-enabled IoT device and an internet host that is not included in the MUD file and should thus be denied. To verify that the traffic filters were applied as expected, communication to and from the unapproved server and the MUD-enabled IoT device was tested.

4.3.10. MQTT Broker Server

The NCCoE implemented an MQTT Broker Server by using the open-source tool Mosquitto. The server communicates messages among multiple clients. For this project, it provides the ability for mobile devices set up with the appropriate application to communicate with the MQTT-enabled IoT devices in the build. The messages exchanged by the devices are on and off messages, which allow the mobile device to control the LED light on the IoT device.

4.3.11. IoT Device Discovery

This project uses ForeScout CounterACT appliance and Enterprise Manager to provide an IoT device discovery service for the demonstration network. CounterACT is able to discover, inventory, profile, and classify all attached devices to validate that the access that is being granted to each device is consistent with that device’s type. ForeScout can also continuously monitor the actions of these assets as they join and leave the network. While ForeScout CounterACT provides a wide range of data collection capabilities, items this project focuses on include

  • Device Information

    • Device Type

    • Manufacturer

    • Connection Type

    • Hardware Information

    • MAC and IP Addresses

    • Operating System

      • Network Services
  • Network Configuration

    • Wired or Wireless

CounterACT detects IoT devices in real time as they connect to the network. It uses both passive monitoring and integration with the network infrastructure. As a device connects to the network, CounterACT may learn about that device via a variety of different techniques to discover and classify it without requiring agents, as shown in Figure 4-3. The methods demonstrated in this project included the following: CounterACT passive discovery of devices using switch polling, importation of MAC classification data, and TCP fingerprinting. Due to the passive nature of the device discovery, neither performance nor reliability of the IoT devices is impacted.

Figure 4-3 Methods the ForeScout Platform Can Use to Discover and Classify IP-Connected Devices

image3

ForeScout CounterACT is deployed as virtual appliances on the NCCoE laboratory network and managed by a single Enterprise Manager. After discovering IoT devices and collecting relevant information, classification is the next step.

To automatically classify discovered devices, the ForeScout platform includes ForeScout Device Cloud. Device Cloud allows users to benefit from crowdsourced device insight to auto-classify their devices, as shown in Figure 4-4. It also auto-classifies the devices by their type and function, operating system and version, and manufacturer and model. Users can leverage new and updated auto-classification profiles published by ForeScout. In addition, they can create custom classification policies to auto-classify devices unique to their environments. At the time of this writing, the ForeScout CounterACT appliance did not have the ability to identify whether an IoT device on the network was MUD-enabled.

Figure 4-4 Classify IoT Devices by Using the ForeScout Platform

image4

4.4. Build Demonstration

The MUD manager used in the capability demonstration was provided by Cisco. Cisco is a provider of enterprise, telecommunications, and industrial networking solutions. The work in this project is being undertaken within Cisco’s Enterprise Central Software Group, with an eye toward improving the product offering over time. Cisco has provided a proof-of-concept MUD manager as well as a Catalyst 3850-S switch with Power-over-Ethernet.

Figure 4-5 describes the logical architecture of the first build. The example implementation is designed with a single device serving as the MUD manager and FreeRADIUS server that interfaces with the Catalyst 3850-S switch over TCP/IP. The Catalyst 3850-S switch contains a DHCP server that is configured to extract MUD URLs from IPv4 DHCP transactions. Upon connecting a MUD-enabled device, the MUD URL will be emitted in some approved method (LLDP, X.509, or DHCP)–for this example implementation, DHCP and LLDP were leveraged (step 1). The Catalyst 3850-S switch will send the MUD URL to the FreeRADIUS server (step 2a); this is passed from the FreeRADIUS server to the MUD manager (step 2b). Once the MUD URL is received, the MUD manager will fetch the MUD file by using the MUD URL provided in the previous step (step 3a); if successful, the MUD file server at the specified location will serve the MUD file (step 3b). Next, the MUD manager will request the signature file associated with the MUD file (step 4a) and upon receipt (step 4b) will verify the MUD file with the respective signature file. Once the MUD file has been verified successfully, the MUD manager passes the device’s traffic filters to the FreeRADIUS server (step 5a), which in turn sends the device’s traffic filters to the router or switch, where they are applied (step 5b). The device is finally assigned an IP address (step 6).

Figure 4-5 Logical Architecture–Build 1

image5

Figure 4-6 describes the physical architecture of laboratory build 1. The Catalyst 3850-S switch is configured to host four VLANs. The first VLAN, VLAN 1 hosts a large number of IoT devices. Three separate instances of DHCP servers are configured for VLANs 1, 3, and 4 to dynamically assign IPv4 addresses to each IoT device that connects to the switch on each of these VLANs. VLAN 2 is configured on the catalyst switch to host the Cisco MUD Manager, the FreeRADIUS server, and the ForeScout CounterACT appliance. VLAN 3 and VLAN 4 are configured to host IoT devices from the same manufacturer. Specifically, VLAN 3 hosts two Raspberry Pi devices, while VLAN 4 hosts two u-blox devices. The network infrastructure as configured utilizes the IPv4 protocol for communication both internally and to the internet.

Figure 4-6 Physical Architecture–Build 1

image6

A full description of Cisco’s proof of concept can be found at https://github.com/CiscoDevNet/MUD-Manager. The Cisco MUD Manager is built as a callout from FreeRADIUS and uses MongoDB to store policy information. The MUD manager is configured from a JSON file that will vary slightly based on the installation. This configuration file provides a number of static bindings and directives as to whether both egress and ingress ACLs should be applied, and it identifies the definition of the “local network” class on the network.

Figure 4-7 shows the process flow of onboarding a MUD-enabled IoT device that emits a MUD URL via DHCPv4.

Figure 4-7 Process Flow–Build 1

figure-4-7

As shown in Figure 4-7, the process flow is as follows:

  • A MUD-enabled IoT device is connected to the network.
  • The MUD-enabled IoT device begins a DHCPv4 transaction in which DHCP option 161, the internet assigned numbers authority (IANA)-assigned value for MUD, is transmitted as part of a DHCP request. It is possible to transmit the option in both DISCOVERY and REQUEST messages.
  • The DHCP server on the Cisco switch recognizes that option and extracts the MUD URL from the DHCP message, which is sent from the switch to the FreeRADIUS server in the associated accounting request. From this point, the FreeRADIUS server sends the MAC address and MUD URL for the newly onboarded device to the MUD manager.
  • Next, the MUD manager does a query for the MAC address in its database, searching for any cached MUD files associated with the MAC address and MUD URL. If an entry does not exist, as depicted in the figure, the MUD manager fetches the MUD file and signature file from the MUD file server.
  • The MUD manager verifies the MUD file with the corresponding signature file and translates the contents into ACLs, which are passed through the FreeRADIUS server to the Cisco switch where they are applied.
  • The MUD-enabled IoT device is assigned an IP address and is ready to be used on the network.
  • Finally, when the MUD-enabled IoT device is in use, access of all traffic to and from the IoT device is controlled by the Cisco switch.

Communications that are allowed by the MUD file include egress north/south and east/west traffic. At the time of publication, ingress access control was not yet supported. Specifics can be found in Section 6.1, Findings. The version of the Cisco MUD Manager implemented in this build leverages a JSON configuration file that is responsible for translating many of the abstractions that are defined by the MUD file. East/west constructs as described in the MUD specification are

  • Controller–class of devices known to be controllers (could describe well-known services such as DNS or NTP)
  • My-controller–class of devices that the local network administrator admits to the particular class
  • Local-networks –class of IP addresses that are scoped within some local administrative boundary
  • Same-manufacturer–class of devices from the same manufacturer as the IoT device in question
  • Manufacturer–class of devices made by a particular manufacturer as identified by the authority component of its MUD URL

In addition to the components required for the MUD solution to function as defined, the example implementation also includes the CounterACT appliance. This appliance was leveraged in order to discover IoT devices on network.

5. Security Characteristic Analysis

The purpose of the security characteristic analysis is to understand the extent to which the project meets its objective of demonstrating the ability to identify IoT components to MUD managers and manage access to those components in a manner that maintains component functionality while limiting unauthorized access to and from the components. In addition, it seeks to understand the security benefits and drawbacks of the example solution.

5.1. Assumptions and Limitations

The security characteristic analysis has the following limitations:

  • It is not a comprehensive test of all security components, nor is it a red team exercise.
  • It cannot identify all weaknesses.
  • It does not include the lab infrastructure. It is assumed that devices are hardened. Testing these devices would reveal only weaknesses in implementation that would not be relevant to those adopting this reference architecture.

5.2. Security Control Map

One aspect of the security characteristic analysis involved assessing how well the reference design addresses the security characteristics that it was intended to support. The NIST Cybersecurity Framework Subcategories were used to provide structure to the security assessment. We consulted the specific sections of each standard that are cited in reference to a Subcategory. The cited sections provide validation points that the example implementation would be expected to exhibit. Using the Cybersecurity Framework Subcategories as a basis for organizing our analysis allowed us to systematically consider how well the reference design supports the intended security characteristics.

The characteristics analysis was conducted in the context of home network and small-business usage scenarios. Use in large enterprise environments may be included in future project extensions but is not considered in this analysis.

The capabilities demonstrated by the architectural elements described in Section 4 and used in the home networks and small-business environments are primarily intended to address requirements, best practices, and capabilities described in the following NIST documents: Framework for Improving Critical Infrastructure Cybersecurity (Cybersecurity Framework), Security and Privacy Controls for Federal Information Systems and Organizations (NIST SP 800-53), and Considerations for Managing Internet of Things (IoT) Cybersecurity and Privacy Risks (NIST Interagency/Internal Report 8228). NIST Interagency/Internal Report 8228 identifies a set of 25 security and privacy expectations for IoT devices and subsystems. These include expectations regarding meeting device protection, data protection, and privacy protection goals. As described in the Mitigating IoT-Based Distributed Denial of Service (DDoS) project description, the example implementation directly addresses the PR.AC-1, PR.AC-2, PR.AC-7, and PR.PT-3 Cybersecurity Framework Subcategories and supports activities addressing the ID.AM-1, ID.AM-2, ID-AM-3, ID.RA-2, ID.RA-3, PR.AC-5, PR.AC-4, PR.DS-5, PR.DS-6, PR-IP-1, PR.IP-3, and DE.CM-8 Subcategories. Also, the security platform directly addresses NIST SP 800-53 controls AC-3, AC-18, CM-7, SC-5, SC-7, SC-28, and SI-2, and it supports activities addressing NIST SP 800-53 controls AC-4, AC-6, AC-24, CM-8, IA-2, IA-5, IA-8, PA-4, PM-5, RA-5, SC-8, and SI-5. In addition, seven of the NIST Interagency/Internal Report 8228 expectations are addressed by the example implementation. Table 5-1 describes how example implementation characteristics address NIST Interagency/Internal Report 8228 expectations, NIST SP 800-53 controls, and Cybersecurity Framework Subcategories.

Table 5-1 Mapping Demonstration Platform Characteristics to NIST Interagency/Internal Report 8228 Expectations, NIST SP 800-53 Controls, and Cybersecurity Framework Subcategories

Applicable Project Description Element That Addresses the Expectation Applicable NISTIR 8228 Expectations Draft NIST SP 800-53 Rev 5 Controls Supported Cybersecurity Framework Subcategories Supported
1 IoT devices insert the MUD extension into DHCP address requests when they attach to the network (e.g., power on). Device has a built-in identifier.

Supports:

CM-8

System Component Inventory

PM-5

System Inventory

Supports:

ID.AM-1

Physical devices and systems within the organization are inventoried.

2 The contents of the MUD extension are passed to the MUD manager, which retrieves a MUD file from the designated website (denoted as the MUD file server) by using https. The MUD file describes the communications requirements for this device. The MUD manager converts the requirements into access control information for enforcement by the router or switch. Device can interface with enterprise asset management systems.

Provides:

AC-3

Access Enforcement

AC-18

Wireless Access

CM-7

Least Functionality

SC-5

Denial of Service Protection

SC-7

Boundary Protection

Supports:

AC-4

Information Flow Enforcement

AC-6

Least Privilege

AC-24

Access Control Decisions

CM-8

System Component Inventory

PM-5

System Inventory

Provides:

PR.PT-3

The principle of least functionality is incorporated by configuring systems to provide only essential capabilities.

Supports:

ID.AM-1

Physical devices and systems within the organization are inventoried.

ID.AM-2

Software platforms and applications within the organization are inventoried.

ID.AM-3

Organizational communication and data flows are mapped.

PR.AC-4

Access permissions and authorizations are managed, incorporating the principles of least privilege and separation of duties.

PR.AC-5

Network integrity is protected (e.g., network segregation, network segmentation).

PR.DS-5

Protections against data leaks are implemented.

DE.AE-1

A baseline of network operations and expected data flows for users and systems is established and managed.

5 IoT devices periodically contact the appropriate update server to download and apply security patches. The manufacturer will provide patches or upgrades for all software and firmware throughout each device’s life span.

Provides:

SI-2

Flaw Remediation

Supports:

PR.IP-1

A baseline configuration of information technology/industrial control systems is created and maintained, incorporating security principles (e.g., concept of least functionality).

PR.IP-3

Configuration change control processes are in place.

7 The router or switch periodically receives threat feeds from the threat signaling server to use as a basis for restricting certain types of network traffic. (Note that although threat signaling is included as part of the reference architecture, it has not yet been implemented in the build.) The device either supports the use of vulnerability scanners or provides built-in vulnerability identification and reporting capabilities.

Supports:

AC-24

Access Control Decisions

RA-5

Vulnerability Scanning

SI-5

Security Alerts, Advisories, and Directives

Supports:

ID.RA-2

Cyber threat intelligence is received from information-sharing forums and sources.

ID.RA-3

Threats, both internal and external, are identified and documented.

DE.CM-8

Vulnerability scans are performed.

11 The contents of the MUD extension are passed to the MUD manager, which retrieves a MUD file from the designated website (denoted as the MUD file server) by using https. The MUD file server must have a valid TLS certificate, and the MUD file itself must have a valid signature. The MUD file describes the communications requirements for this device. The MUD manager converts the requirements into access control information for enforcement by the router or switch. The device can use existing enterprise authenticators and authentication mechanisms.

Supports:

IA-2

Identification and Authentication (Organizational Users)

IA-5

Authenticator Management

IA-8

Identification and Authentication (Non- Organizational Users)

Provides:

PR.AC-1

Identities and credentials are issued, managed, verified, revoked, and audited for authorized devices, users and processes.

PR.AC-3

Remote access is managed.

PR.AC-7

Users, devices, and other assets are authenticated commensurate with the risk of the transaction.

21 IoT devices insert the MUD extension into DHCP address requests when they attach to the network (e.g., power on). The contents of the MUD extension are passed to the MUD manager, which retrieves a MUD file from the designated website (denoted as the MUD file server) by using https. The MUD file describes the communications requirements for this device. The MUD manager converts the requirements into access control information for enforcement by the router or switch. Device can prevent unauthorized access to all sensitive data transmitted from it over networks.

Provides:

SC-23

Session Authenticity

Supports:

AC-18

Wireless Access

SC-8 Transmission Confidentiality and Integrity

Provides:

PR.PT-3

The principle of least functionality is incorporated by configuring systems to provide only essential capabilities.

Supports:

PR.DS-5

Protections against data leaks are implemented.

PR.DS-6

Integrity-checking mechanisms are used to verify software, firmware, and information integrity.

24 IoT devices insert the MUD extension into DHCP address requests when they attach to the network (e.g., power on). The contents of the MUD extension are passed to the MUD manager, which retrieves a MUD file from the designated website (denoted as the MUD file server) by using https. The MUD file describes the communications requirements for this device. The MUD manager converts the requirements into access control information for enforcement by the router or switch. The router or switch periodically receives threat feeds from the threat signaling server to use as a basis for restricting certain types of network traffic. (As mentioned earlier, although a part of the logical architecture, threat signaling has not yet been implemented in the build.) There is sufficient centralized control to apply policy or regulatory requirements to personally identifiable information.

Supports:

PA-4

Information Sharing with External Parties

None

Table 5-2 details Cybersecurity Framework Identify, Protect, and Detect Categories and Subcategories that the example implementation directly addresses or for which the example implementation may serve a supporting role. Those Subcategories that are directly addressed are highlighted in green. While some of the references provide general guidance that informs implementation of referenced Cybersecurity Framework core functions, the NIST SP and Federal Information Processing Standard (FIPS) references provide specific recommendations that should be considered when composing and configuring security platforms. (Note that not all of the informative references apply to this example implementation.)

Table 5-2 Mapping Project Objectives to the Cybersecurity Framework and Informative Security Control References

Cybersecurity Framework Category Cybersecurity Framework Subcategory Informative References
Asset Management (ID.AM): The data, personnel, devices, systems, and facilities that enable the organization to achieve business purposes are identified and managed consistent with their relative importance to business objectives and the organization’s risk strategy. ID.AM-1: Physical devices and systems within the organization are inventoried.

CIS CSC 1

COBIT 5 BAI09.01, BAI09.02

ISA 62443-2-1:2009 4.2.3.4

ISA 62443-3-3:2013 SR 7.8

ISO/IEC 27001:2013 A.8.1.1, A.8.1.2

NIST SP 800-53 Rev. 4 CM-8, PM-5

ID.AM-2: Software platforms and applications within the organization are inventoried.

CIS CSC 2

COBIT 5 BAI09.01, BAI09.02, BAI09.05

ISA 62443-2-1:2009 4.2.3.4

ISA 62443-3-3:2013 SR 7.8

ISO/IEC 27001:2013 A.8.1.1, A.8.1.2, A.12.5.1

NIST SP 800-53 Rev. 4 CM-8, PM-5

ID.AM-3: Organizational communication and data flows are mapped.

CIS CSC 12

COBIT 5 DSS05.02

ISA 62443-2-1:2009 4.2.3.4

SA 62443-3-3:2013 SR 7.8 ISO/IEC 27001:2013 A.8.1.1, A.8.1.2, A.12.5.1

NIST SP 800-53 Rev. 4 AC-4, CA-3, CA-9, PL-8

Risk Assessment (ID.RA): The organization understands the cybersecurity risk to organizational operations (including mission, functions, image, or reputation), organizational assets, and individuals. ID.RA-2: Cyber threat intelligence is received from information-sharing forums and sources.

CIS CSC 4

COBIT 5 BAI08.01

ISA 62443-2-1:2009 4.2.3, 4.2.3.9, 4.2.3.12

ISO/IEC 27001:2013 A.6.1.4

NIST SP 800-53 Rev. 4 SI-5, PM-15, PM-16

ID.RA-3: Threats, both internal and external, are identified and documented.

CIS CSC 4

COBIT 5 APO12.01, APO12.02, APO12.03, APO12.04

ISA 62443-2-1:2009 4.2.3, 4.2.3.9, 4.2.3.12

ISO/IEC 27001:2013 Clause 6.1.2

NIST SP 800-53 Rev. 4 RA-3, SI-5, PM-12, PM-16

Identity Management, Authentication, and Access Control (PR.AC): Access to physical and logical assets and associated facilities is limited to authorized users, processes, and devices and is managed consistent with the assessed risk of unauthorized access to authorized activities and transactions. PR.AC-1: Identities and credentials are issued, managed, verified, revoked, and audited for authorized devices, users, and processes.

COBIT 5 DSS05.04, DSS06.03

ISA 62443-2-1:2009 4.3.3.5.1

ISA 62443-3-3:2013 SR 1.1, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9

ISO/IEC 27001:2013 A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3

NIST SP 800-53 Rev. 4 AC-1, AC-2, IA-1, IA-2, IA-3, IA-4, IA-5, IA-6, IA-7, IA-8, IA-9, IA-10, IA-11

CIS CSC 1, 5, 15, 16

PR.AC-3: Remote access is managed.

CIS CSC 12 COBIT 5 APO13.01, DSS01.04, DSS05.03 ISA 62443-2-1:2009 4.3.3.6.6

ISA 62443-3-3:2013 SR 1.13, SR 2.6 ISO/IEC 27001:2013 A.6.2.1, A.6.2.2, A.11.2.6, A.13.1.1, A.13.2.1

NIST SP 800-53 Rev. 4 AC-1, AC-17, AC-19, AC-20, SC-15

PR.AC-4: Access permissions and authorizations are managed, incorporating the principles of least privilege and separation of duties.

CIS CSC 3, 5, 12, 14, 15, 16, 18

COBIT 5 DSS05.04

ISA 62443-2-1:2009 4.3.3.7.3

ISA 62443-3-3:2013 SR 2.1 ISO/IEC 27001:2013 A.6.1.2, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5

NIST SP 800-53 Rev. 4 AC-1, AC-2, AC-3, AC-5, AC-6, AC-14, AC-16, AC-24

PR.AC-5: Network integrity is protected, incorporating network segregation where appropriate.

CIS CSC 9, 14, 15, 18

COBIT 5 DSS01.05, DSS05.02

ISA 62443-2-1:2009 4.3.3.4

ISA 62443-3-3:2013 SR 3.1, SR 3.8 ISO/IEC 27001:2013 A.13.1.1, A.13.1.3, A.13.2.1, A.14.1.2, A.14.1.3

NIST SP 800-53 Rev. 4 AC-4, AC-10, SC-7

PR.AC-7: Users, devices, and other assets are authenticated (e.g., single-factor, multifactor) commensurate with the risk of the transaction (e.g., individuals’ security and privacy risks and other organizational risks).

CIS CSC 1, 12, 15, 16

COBIT 5 DSS05.04, DSS05.10, DSS06.10 ISA 62443-2-1:2009 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9

ISA 62443-3-3:2013 SR 1.1, SR 1.2, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 1.10 ISO/IEC 27001:2013 A.9.2.1, A.9.2.4, A.9.3.1, A.9.4.2, A.9.4.3, A.18.1.4

NIST SP 800-53 Rev. 4 AC-7, AC-8, AC-9, AC-11, AC-12, AC-14, IA-1, IA-2, IA-3, IA-4, IA-5, IA-8, IA-9, IA-10, IA-11

E.g., Data Security (PR.DS): Information and records (data) are managed consistent with the organizationʼs risk strategy to protect the confidentiality, integrity, and availability of information.

page75image15040

PR.DS-5: Protections against data leaks are implemented.

CIS CSC 13

COBIT 5 APO01.06, DSS05.04, DSS05.07, DSS06.02

ISA 62443-3-3:2013 SR 5.2 ISO/IEC 27001:2013 A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5, A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3

NIST SP 800-53 Rev. 4 AC-4, AC-5, AC-6, PE-19, PS-3, PS-6, SC-7, SC-8, SC-13, SC-31, SI-4

PR.DS‐6: Integrity checking mechanisms are used to verify software, firmware, and information integrity
ISA 62443-3-3:2013 SR 3.1, SR 3.3, SR 3.4, SR 3.8
ISO/IEC 27001:2013 A.12.2.1, A.12.5.1, A.14.1.2, A.14.1.3
FIPS 140‐2 Sec. 4
NIST SP 800‐45 Ver. 2 2.4.2, 3, 4.2.3, 4.3, 5.1, 6.1, 7.2.2, 8.2, 9.2
NIST SP 800‐49 2.2.1, 2.3.2, 3.4
NIST SP 800‐52 Rev. 1 3, 4, D1.4
NIST SP 800‐53 Rev. 4 SI‐7
NIST SP 800‐57 Part 1 Rev. 4 5.5, 6.1, 8.1.5.1, B.3.2, B.5
NIST SP 800-57 Part 2 1, 3.1.2.1.2, 4.1, 4.2, 4.3, A.2.2, A.3.2, C.2.2 NIST SP 800-81-2 All
NIST SP 800-130 2.2, 4.3, 6.2.1, 6.3, 6.4, 6.5, 6.6.1
NIST SP 800-152 6.1.3, 6.2.1, 8.2.1, 8.2.4, 9.4

NIST SP 800-177 2.2, 4.1, 4.4, 4.5, 4.7, 5.2, 5.3

Information Protection Processes and Procedures (PR.IP): Security policies (that address purpose, scope, roles, responsibilities, management commitment, and coordination among organizational entities), processes, and procedures are maintained and used to manage protection of information systems and assets. PR.IP-1: A baseline configuration of information technology/industrial control systems is created and maintained, incorporating security principles (e.g., concept of least functionality).

CIS CSC 1

COBIT 5 BAI10.01, BAI10.02, BAI10.03, BAI10.05

ISA 62443-2-1:2009 4.3.4.3.2, 4.3.4.3.3

ISA 62443-3-3:2013 SR 7.6

ISO/IEC 27001:2013 A.12.1.2, A.12.5.1, A.12.6.2, A.14.2.2, A.14.2.3, A.14.2.4

NIST SP 800-53 Rev. 4 CM-2, CM-3, CM-4, CM-5, CM-6, CM-7, CM-9, SA-10

PR.IP-3: Configuration change control processes are in place.

CIS CSC 3, 11

COBIT 5 BAI01.06, BAI06.01

ISA 62443-2-1:2009 4.3.4.3.2, 4.3.4.3.3

ISA 62443-3-3:2013 SR 7.6

ISO/IEC 27001:2013 A.12.1.2, A.12.5.1, A.12.6.2, A.14.2.2, A.14.2.3, A.14.2.4

NIST SP 800-53 Rev. 4 CM-3, CM-4, SA-10

Protective Technology (PR.PT): Technical security solutions are managed to ensure the security and resilience of systems and assets, consistent with related policies, procedures, and agreements. PR.PT-3: The principle of least functionality is incorporated by configuring systems to provide only essential capabilities.

CIS CSC 3, 11, 14

COBIT 5 DSS05.02, DSS05.05, DSS06.06 ISA 62443-2-1:2009 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4

ISA 62443-3-3:2013 SR 1.1, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7 ISO/IEC 27001:2013 A.9.1.2

NIST SP 800-53 Rev. 4 AC-3, CM-7

Security Continuous Monitoring (DE.CM): The information system and assets are monitored to identify cybersecurity events and verify the effectiveness of protective measures. DE.CM-8: Vulnerability scans are performed.

CIS CSC 4, 20

COBIT 5 BAI03.10, DSS05.01

ISA 62443-2-1:2009 4.2.3.1, 4.2.3.7

ISO/IEC 27001:2013 A.12.6.1

NIST SP 800-53 Rev. 4 RA-5

Additional resources and references required to develop this solution are identified in Appendix E. The core standards, secure update standards, industry best practices for software quality, and best practices for identification and authentication are generally stable, well understood, and available in the commercial off-the-shelf market. Standards associated with the MUD protocol are in an advanced level of development in the Internet Engineering Task Force.

5.3. Scenarios

This section presents three threat scenarios for home and small-business networks involving increasing levels of security. In the first scenario, MUD is not deployed on the network, so IoT devices are vulnerable to being port scanned and are not restricted from exchanging traffic with either external sites or other devices on the local network. IoT devices in this first scenario are highly vulnerable to attack.

In the second scenario, MUD is deployed on the network, but the MUD files being used only restrict traffic from being sent between the IoT devices and some external internet domains (i.e., north-south traffic); IoT devices are still able to send and receive traffic from all other devices on the local network (i.e., east-west traffic). In the third scenario, the MUD file protections provided in scenario 2 are enhanced to also restrict traffic between IoT devices and some other devices on the local network, ensuring that the IoT devices are permitted to exchange traffic with only external domains and internal devices that are explicitly specified in their MUD file.

5.3.1. Scenario 1: No MUD Protection

In the No MUD Protection scenario, as shown in Figure 5-1, the home/small-business network (depicted by the blue cloud) does not have MUD deployed to provide security for its IoT devices.

Figure 5-1 No MUD Protection Threat Scenario

image8

All IoT devices on the network can be port scanned (and perhaps hijacked) from anywhere. IoT devices are permitted access to and from intended services as desired. However, the IoT devices are also reachable by compromised mobile devices that are on their local network and by malicious external devices, making them vulnerable to attacks from these compromised and malicious devices. In addition, if an IoT device becomes compromised, there are no protections in place to stop it from launching an attack on outside devices, creating additional potential victims.

5.3.2. Scenario 2: MUD Protection from External Threats

In the MUD Protection from External Threats scenario, as shown in Figure 5-2, the home/small-business network (depicted by the blue cloud) has MUD deployed (the components of the MUD deployment are not depicted). The MUD file for the IoT device lists the domains of all external services with which the device is permitted to exchange traffic. All domains that are not explicitly permitted in the MUD file are denied. Therefore, the IoT device on the network can freely communicate with its intended external services, but all other attempted communications between the IoT device and external devices are blocked. The IoT device cannot be port scanned or receive traffic from external malicious actors, even if those actors are not known to be malicious. Furthermore, even if the IoT device is compromised in some way after being onboarded, it will not be permitted to send traffic to any external devices to attack those devices. One of the external devices with which the IoT device is permitted to communicate is an update server, from which the device receives regular software updates to ensure that it installs the most recent security patches as needed.

Unfortunately, the MUD file for the IoT device in this scenario also includes a construct that permits the IoT device to exchange traffic with all devices that are on the local network. If a device on the local network becomes compromised, that device will be able to attack the IoT device.

Figure 5-2 MUD Protection from External Threats Scenario

image9

5.3.3. Scenario 3: MUD Protection from External and Internal Threats

In the MUD Protection from External and Internal Threats scenario, as shown in Figure 5-3, the home/small-business network (depicted by the blue cloud) has MUD deployed (the components of the MUD deployment are not depicted). As in the MUD Protection from External Threats scenario, the MUD file for the IoT device lists the domains of all external services with which the device is permitted to exchange traffic, thereby protecting the IoT devices from being attacked by external entities and protecting external entities from being attacked by the IoT device. In addition, unlike the previous scenario, the MUD file in this scenario does not include a construct that permits the IoT device to exchange traffic with all other devices that are on the local network. Instead, the MUD file specifies specific devices with which the IoT device is permitted to communicate based on, for example, the manufacturer of those other devices. If a local device is not from the specified manufacturer, it will not be permitted to communicate with the IoT device. So, if a device on the local network becomes compromised and that device’s manufacturer or model is not one that has been explicitly permitted in the MUD file, that device will not be permitted to send traffic to attack the IoT device.

Figure 5-3 MUD Protection from External and Internal Threats Scenario

image10

5.4. Build Evaluation

A functional evaluation of the IoT example implementation was conducted to verify that it meets the requirements. Table 5-3 summarizes the tests that were performed, their expected and observed outcomes, and the applicable Cybersecurity Framework Subcategories and NIST SP 800-53 controls for which each test is designed to verify support. The tests that are listed in the table are described in a functional evaluation plan that is provided in Appendix D. Not all tests defined in the functional evaluation plan are listed in Table 5-3 because not all those tests were applicable to this build of the IoT example implementation. Boldface text is used in the Test Summary and Expected Outcome columns to highlight the gist of the information that is being conveyed.

Table 5-3 Summary of Functional Tests

Test Applicable Cybersecurity Framework Subcategories & NIST SP 800-53 Controls Test Summary Expected Outcome Observed Outcome
IoT-1

ID.AM-1: Physical devices and systems within the organization are inventoried.

NIST SP 800-53 Rev. 4 CM-8, PM-5

ID.AM-2: Software platforms and applications within the organization are inventoried.

NIST SP 800-53 Rev. 4 CM-8, PM-5

ID.AM-3: Organizational communication and data flows are mapped.

NIST SP 800-53 Rev. 4 AC-4, CA-3, CA-9, PL-8

PR.DS-5: Protections against data leaks are implemented.

NIST SP 800-53 Rev. 4 AC-4, AC-5, AC-6, PE-19, PS-3, PS-6, SC-7, SC-8, SC-13, SC-31, SI-4

DE.AE-1: A baseline of network operations and expected data flows for users and systems is established and managed.

PR.AC-4: Access permissions and authorizations are managed, incorporating the principles of least privilege and separation of duties.

NIST SP 800-53 Rev. 4 AC-1, AC-2, AC-3, AC-5, AC-6, AC-14, AC-16, AC-24

PR.AC-5: Network integrity is protected, incorporating network segregation where appropriate.

NIST SP 800-53 Rev. 4 AC-4, AC-10, SC-7

PR.IP-1: A baseline configuration of information technology/industrial control systems is created and maintained, incorporating security principles (e.g., concept of least functionality).

NIST SP 800-53 Rev. 4 CM-2, CM-3, CM-4, CM-5, CM-6, CM-7, CM-9, SA-10

PR.IP-3: Configuration change control processes are in place.

NIST SP 800-53 Rev. 4 CM-3, CM-4, SA-10

PR.PT-3: The principle of least functionality is incorporated by configuring systems to provide only essential capabilities.

NIST SP 800-53 Rev. 4 AC-3, CM-7

PR.DS-2: Data in transit is protected.

A MUD-enabled IoT device is configured to emit a MUD URL. The DHCP server extracts the MUD URL, which is sent to the MUD manager. The MUD manager requests the MUD file and signature from the MUD file server, and the MUD file server serves the MUD file to the MUD manager. The MUD file explicitly permits traffic to/from some internet services and hosts and implicitly denies traffic to/from all other internet services. The MUD manager translates the MUD file information into local network configurations that it installs on the router or switch that is serving as the MUD PEP for the IoT device. Upon connection to the network, the MUD-enabled IoT device has its MUD policy enforcement point (PEP) router/switch automatically configured according to the MUD file’s route filtering policies. Pass
IoT-2

PR.AC-7: Users, devices, and other assets are authenticated (e.g., single-factor, multifactor) commensurate with the risk of the transaction (e.g., individuals’ security and privacy risks and other organizational risks).

NIST SP 800-53 Rev. 4 AC-7, AC-8, AC-9, AC-11, AC-12, AC-14, IA-1, IA-2, IA-3, IA-4, IA-5, IA-8, IA-9, IA-10, IA-11

A MUD-enabled IoT device is configured to emit a URL for a MUD file, but the MUD file server that is hosting that file does not have a valid TLS certificate. Local policy has been configured to ensure that if the MUD file for an IoT device is located on a server with an invalid certificate, the router/switch will be configured to deny all communication to/from the device. When the MUD-enabled IoT device is connected to the network, the MUD manager sends locally defined policy to the router/switch that handles whether to allow or block traffic to the MUD-enabled IoT device. Therefore, the MUD PEP router/switch will be configured to block all traffic to and from the IoT device. Pass
IoT-3

PR.DS‐6: Integrity-checking mechanisms are used to verify software, firmware, and information integrity.

NIST SP 800‐53 Rev. 4 SI‐7

A MUD-enabled IoT device is configured to emit a URL for a MUD file, but the certificate that was used to sign the MUD file had already expired at the time of signing. Local policy has been configured to ensure that if the MUD file for a device has a signature that was signed by a certificate that had already expired at the time of signature, the device’s MUD PEP router/switch will be configured to deny all communication to/from the device. When the MUD-enabled IoT device is connected to the network and the MUD file and signature are fetched, the MUD manager will detect that the MUD file’s signature was created by using a certificate that had already expired at the time of signing. According to local policy, the MUD PEP will be configured to block all traffic to/from the device. Pass
IoT-4

PR.DS‐6: Integrity-checking mechanisms are used to verify software, firmware, and information integrity.

NIST SP 800‐53 Rev. 4 SI‐7

A MUD-enabled IoT device is configured to emit a URL for a MUD file, but the signature of the MUD file is invalid. Local policy has been configured to ensure that if the MUD file for a device is invalid, the router/switch will be configured to deny all communication to/from the IoT device. When the MUD-enabled IoT device is connected to the network, the MUD manager sends locally defined policy to the router/switch that handles whether to allow or block traffic to the MUD-enabled IoT device. Therefore, the MUD PEP router/switch will be configured to block all traffic to and from IoT device. Pass
IoT-5

ID.AM-3: Organizational communication and data flows are mapped.

NIST SP 800-53 Rev. 4 AC-4, CA-3, CA-9, PL-8

PR.DS-5: Protections against data leaks are implemented.

NIST SP 800-53 Rev. 4 AC-4, AC-5, AC-6, PE-19, PS-3, PS-6, SC-7, SC-8, SC-13, SC-31, SI-4

PR.IP-1: A baseline configuration of information technology/industrial control systems is created and maintained, incorporating security principles (e.g., concept of least functionality).

NIST SP 800-53 Rev. 4 CM-2, CM-3, CM-4, CM-5, CM-6, CM-7, CM-9, SA-10

PR.PT-3: The principle of least functionality is incorporated by configuring systems to provide only essential capabilities.

NIST SP 800-53 Rev. 4 AC-3, CM-7

Test IoT-1 has run successfully, meaning that the MUD PEP router/switch has been configured based on a MUD file that permits traffic to/from some internet locations and implicitly denies traffic to/from all other internet locations. When the MUD-enabled IoT device is connected to the network, its MUD PEP router/switch will be configured to enforce the route filtering that is described in the device’s MUD file with respect to traffic being permitted to/from some internet locations; and traffic being implicitly blocked to/from all remaining internet locations. Pass (for testable procedure –ingress cannot be tested)
IoT-6

ID.AM-3: Organizational communication and data flows are mapped.

NIST SP 800-53 Rev. 4 AC-4, CA-3, CA-9, PL-8

PR.DS-5: Protections against data leaks are implemented.

NIST SP 800-53 Rev. 4 AC-4, AC-5, AC-6, PE-19, PS-3, PS-6, SC-7, SC-8, SC-13, SC-31, SI-4

PR.AC-5: Network integrity is protected, incorporating network segregation where appropriate.

NIST SP 800-53 Rev. 4 AC-4, AC-10, SC-7

PR.IP-1: A baseline configuration of information technology/industrial control systems is created and maintained, incorporating security principles (e.g., concept of least functionality).

NIST SP 800-53 Rev. 4 CM-2, CM-3, CM-4, CM-5, CM-6, CM-7, CM-9, SA-10

PR.PT-3: The principle of least functionality is incorporated by configuring systems to provide only essential capabilities.

NIST SP 800-53 Rev. 4 AC-3, CM-7

Test IoT-1 has run successfully, meaning that the MUD PEP router/switch has been configured based on a MUD file that permits traffic to/from some lateral hosts and implicitly denies traffic to/from all other lateral hosts. (The MUD file does not explicitly identify the hosts as lateral hosts; it identifies classes of hosts to/from which traffic should be denied, where one or more hosts of this class happen to be lateral hosts.) When the MUD-enabled IoT device is connected to the network, its MUD PEP router/switch will be configured to enforce the access control information that is described in the device’s MUD file with respect to traffic being permitted to/from some lateral hosts; and traffic being implicitly blocked to/from all remaining lateral hosts. Pass (for testable procedure –ingress cannot be tested)
IoT-7

PR.IP-3: Configuration change control processes are in place.

NIST SP 800-53 Rev. 4 CM-3, CM-4, SA-10

PR.DS-3: Assets are formally managed throughout removal, transfers, and disposition.

Test IoT-1 has run successfully, meaning that the MUD PEP router/switch has been configured based on the MUD file for a specific MUD-enabled device in question. Next, have the IoT device change DHCP state by explicitly releasing its IP address lease, causing the device’s policy configuration to be removed from the MUD PEP router/switch. When the MUD-enabled IoT device explicitly releases its IP address lease, the MUD-related configuration for that IoT device will be removed from its MUD PEP router/switch. Pass
IoT-8

PR.IP-3: Configuration change control processes are in place.

NIST SP 800-53 Rev. 4 CM-3, CM-4, SA-10

PR.DS-3: Assets are formally managed throughout removal, transfers, and disposition.

Test IoT-1 has run successfully, meaning that the MUD PEP router/switch has been configured based on the MUD file for a specific MUD-enabled device in question. Next, have the IoT device change DHCP state by waiting until the IoT device’s address lease expires, causing the device’s policy configuration to be removed from the MUD PEP router/switch. When the MUD-enabled IoT device’s IP address lease expires, the MUD-related configuration for that IoT device will be removed from its MUD PEP router/switch. Failed (not supported)
IoT-12

ID.AM-1: Physical devices and systems within the organization are inventoried.

NIST SP 800-53 Rev. 4 CM-8, PM-5

ID.AM-2: Software platforms and applications within the organization are inventoried.

NIST SP 800-53 Rev. 4 CM-8, PM-5

ID.AM-3: Organizational communication and data flows are mapped.

NIST SP 800-53 Rev. 4 AC-4, CA-3, CA-9, PL-8

PR.DS-5: Protections against data leaks are implemented.

NIST SP 800-53 Rev. 4 AC-4, AC-5, AC-6, PE-19, PS-3, PS-6, SC-7, SC-8, SC-13, SC-31, SI-4

DE.AE-1: A baseline of network operations and expected data flows for users and systems is established and managed.

PR.AC-4: Access permissions and authorizations are managed, incorporating the principles of least privilege and separation of duties.

NIST SP 800-53 Rev. 4 AC-1, AC-2, AC-3, AC-5, AC-6, AC-14, AC-16, AC-24

PR.AC-5: Network integrity is protected, incorporating network segregation where appropriate.

NIST SP 800-53 Rev. 4 AC-4, AC-10, SC-7

PR.IP-1: A baseline configuration of information technology/industrial control systems is created and maintained, incorporating security principles (e.g., concept of least functionality).

NIST SP 800-53 Rev. 4 CM-2, CM-3, CM-4, CM-5, CM-6, CM-7, CM-9, SA-10

PR.IP-3: Configuration change control processes are in place.

NIST SP 800-53 Rev. 4 CM-3, CM-4, SA-10

PR.PT-3: The principle of least functionality is incorporated by configuring systems to provide only essential capabilities.

NIST SP 800-53 Rev. 4 AC-3, CM-7

PR.DS-2: Data in transit is protected.

A MUD-enabled IoT device is configured to emit a MUD URL. Upon being connected to the network, its MUD file is retrieved, and the PEP is configured to enforce the policies specified in that MUD URL for that device. Within 24 hours (i.e., within the cache-validity period for that MUD file), a second IoT device that has been configured to emit the same MUD URL is connected to the network. Upon connection of the second IoT device to the network, the MUD manager does not contact the MUD file server. Instead, it uses the cached MUD file. It translates this MUD file’s contents into appropriate route-filtering rules and installs these rules onto the PEP for the second IoT device. Pass
IoT-13

ID.AM-1: Physical devices and systems within the organization are inventoried.

NIST SP 800-53 Rev. 4 CM-8, PM-5

ID.AM-2: Software platforms and applications within the organization are inventoried.

NIST SP 800-53 Rev. 4 CM-8, PM-5

ID.AM-3: Organizational communication and data flows are mapped.

NIST SP 800-53 Rev. 4 AC-4, CA-3, CA-9, PL-8

DE.AE-1: A baseline of network operations and expected data flows for users and systems is established and managed.

NIST SP 800-53 Rev. 4 AC-4, CA-3, CM-2, SI-4

DE.CM-1: The network is monitored to detect potential cybersecurity events.

NIST SP 800-53 Rev. 4 AC-2, AU-12, CA-7, CM-3, SC-5, SC-7, SI-4

A visibility/monitoring component is connected to the local IoT network. It is configured to detect all devices connected to the network, discover attributes of these devices, categorize the devices, and monitor the devices for any change of status. Upon being connected to the network, the visibility/monitoring component detects all connected devices, identifies their attributes (e.g., type, IP address, OS), and categorizes them. When an additional device is powered on, it is also detected, and its attributes identified. When a device is powered off, its change of status is detected. Pass
IoT-14 ID.AM-1: Physical devices and systems within the organization are inventoried. A MUD-enabled IoT device is capable of emitting a MUD URL. The device should leverage one of the specified manners for emitting a MUD URL.

Upon initialization, the MUD-enabled IoT device broadcasts a DHCP message on the network, including at most one MUD URL, in https scheme, within the DHCP transaction.

OR

Upon initialization, the MUD-enabled IoT device emits a MUD URL as an LLDP extension.

Pass

6. Findings and Recommendations

This section introduces findings based on the build implementation and demonstration, as well as recommendations.

6.1. Findings

  • It is possible to provide significantly higher security than is typically achieved in today’s (non-MUD-capable) home and small-business networks by deploying and using MUD on those networks.

  • The NCCoE example solution demonstrates that by using MUD-capable IoT devices on networks where support for MUD has been deployed, it is possible to manage access to MUD-capable IoT devices in a manner that maintains device functionality while

    • preventing access to the MUD-capable IoT device from other components on the internal network that are not from authorized manufacturers or authorized device classes
    • preventing the MUD-capable IoT device from being used to access unauthorized external domains
    • preventing the MUD-capable IoT device from being used to access other components on the internal network that are not from authorized manufacturers or that are not authorized device types
  • MUD can help prevent MUD-capable IoT devices from being used to launch DDoS and other attacks that are typically possible by commandeering non-MUD-capable IoT devices on today’s home and small-business networks. To enable MUD to provide this protection, it must be deployed correctly, networks must use MUD-capable IoT devices, and MUD files must be written and available for these devices so that the files authorize only the outgoing communications that each MUD-capable IoT device needs to maintain its intended functionality.

  • There are commercially available network visibility/monitoring technologies that are able to detect connected devices and identify certain device attributes (e.g., type, IP address, OS) throughout the duration of a device’s connection to the network. These technologies are also able to detect when the devices leave the network or are powered off and to note their change of status accordingly.

  • Setup and configuration of the components needed to deploy MUD on a network (MUD-capable router/switch and MUD manager) should ideally be able to be performed easily, right out of the box, to enable typical home or small-business users to deploy MUD successfully. It is not clear that the current suite of available products is sufficiently user-friendly to enable the typical, nontechnical user to easily and seamlessly deploy MUD on their home and small-business networks. However, improvements in the usability of MUD components are expected as more manufacturers implement support for MUD and as current manufacturers that support MUD refine the design of their MUD components to target the home and small-business user.

  • MUD has the potential to help with the security of even those IoT devices that have been deprecated and are no longer receiving regular updates. Eventually, most IoT devices will reach a point at which they will no longer be updated by their manufacturer. This is a dangerous point in any device’s life cycle because it means that any of its security vulnerabilities that become known after this point will not be protected against, leaving the device open to attack. For MUD-capable devices that reach this end-of-life stage, however, the use of MUD provides additional protection that is not available to non-MUD-capable devices. Even if a MUD-capable device can no longer be updated, its MUD file will still limit the other devices with which that MUD-capable device is able to communicate, thereby limiting what other devices could be used to attack it and what other devices it could be used to attack. In the future, there are expected to be many IoT devices that are no longer being updated by their manufacturers, yet that will continue to be used. The ability to leverage MUD to limit the communications profiles of such unsupported devices will be important for protecting these highly vulnerable devices from attack by unauthorized end points and for protecting the internet from attack by these vulnerable devices.

  • Even when using components that are fully conformant to the MUD specification, there are still some behaviors that will be determined by local policy. If the default policy that is provided by a specific product out of the box is not sufficient, user action will be required to configure the device according to a different and desired policy. User-friendly interfaces will be needed to enable the typical, nontechnical user of a home or small-business network to interact with the MUD components to modify their default settings when needed. For example, the MUD specification does not dictate what action to take (e.g., block or permit traffic to the IoT device) if the MUD manager is not able to validate the device’s MUD file server’s TLS certificate or if the MUD manager is not able to validate the device’s MUD file’s certificate. In either of these cases, if the default behavior that the device is configured to perform is not acceptable, the user would need to configure the device to perform the desired behavior. Ideally the device would provide a user-friendly interface through which to do so.

  • There is a dearth of MUD-capable IoT devices. Users wanting to deploy MUD do not yet have the option to do so because of a lack of availability of MUD-capable IoT devices. More vendor buy in is required to encourage IoT device manufacturers to implement support for MUD in their devices.

  • Communications between the MUD manager and the router/switch, between the threat signaling server and the MUD manager/router, and between the IoT devices and their corresponding update servers are not standardized. This lack of standardization has the potential to inhibit interoperability of components that are obtained from different manufacturers, thereby limiting the choice that consumers have to mix architectural components from different vendors in their MUD deployments.

  • Specifically, for Build 1 we observed the following limitations that are informing improvements to the current proof-of-concept implementation:

    • MUD Manager (version 1.0):

      • DNS resolution of internet host names in the MUD file is performed manually and remains static. The MUD manager does not invoke a DNS resolution service to automatically resolve the fully qualified domain names (FQDNs) that are referenced in MUD files dynamically at the time that it reads those MUD files. Instead, DNS resolution of FQDNs referenced in MUD files is performed manually by a human operator before beginning execution of the MUD manager service. The operator inserts this address resolution information into the MUD manager’s .JSON configuration file, where it remains static for the duration of the operation of the MUD manager service. The MUD manager consults this configuration file, which is passed to it at the time the MUD manager service is started, to obtain this static DNS resolution information.

        Use of the .JSON configuration file as the mechanism to provide the MUD manager with DNS resolution information means that every FQDN that will be referenced in any MUD file must be resolved and inserted into the MUD manager’s configuration file manually before beginning execution of the MUD manager service. So, for example, if a MUD file that will be used on the network permits traffic to be sent to domains www.example.com and www.company.com, the MUD manager’s .JSON configuration file must be provided with lines that indicate that the FQDN www.example.com resolves to IP address 128.56.54.3 and the FQDN www.company.com resolves to IP address 128.54.35.2.

        Use of the .JSON configuration file as the mechanism to provide the MUD manager with DNS resolution information also means that the operator who is configuring the .JSON file must have prior knowledge of all FQDNs that will be referenced in all MUD files that will used by devices on the network. If a MUD file references an FQDN that has not been listed and associated with a corresponding IP address in the MUD manager’s .JSON configuration file, the MUD manager will not be able to configure an ACL to enforce controls related to that FQDN.

        In addition, because the DNS resolution information is passed to the MUD manager at execution time, this address resolution information remains static for as long as the MUD manager service continues to operate. To add new FQDN address resolutions or change existing ones, the MUD manager’s .JSON file would have to be edited and the MUD manager process killed and restarted by using the new .JSON configuration file.

        Dynamic resolution of FQDNs is expected to be supported in the future.

      • Translation and implementation of the “model” construct from the MUD file was not supported at the time of testing. However, this should be addressed in newer versions.

  • Catalyst 3850-S Switch (IOS version 16.09.02):

    • The MUD URL cannot be extracted when emitted via DHCPv6. Hence, the switch is only capable of supporting MUD-capable IoT devices that use DHCPv4 and IPv4. This version of the switch does not yet support MUD-capable IoT devices when they are configured to use IPv6. IPv6 functionality is expected to be supported in the future.
    • The DHCP server does not notify the MUD manager of changes in DHCP state for MUD-enabled IoT devices on the network. According to the MUD specification, the DHCP server should notify the MUD manager if the MUD-enabled IoT device’s IP address lease expires or has been released. However, this version of the DHCP server does not do so at the time of testing. This is expected to be addressed in the future.
    • Ingress Dynamic ACLs (DACLs) (i.e., DACLs that pertain to traffic that is received from sources external to the network and directed to local IoT devices) are not supported with this version. Consequently, even if a MUD-capable IoT device’s MUD file indicates that the IoT device is not authorized to receive traffic from a particular external domain, the DACL that is needed to prohibit that ingress traffic will not be configured on the switch. As a result, unless there is some other layer of security in place, such as a firewall that is configured to block this incoming traffic, the IoT device will still be able to receive incoming packets from that unauthorized external domain, which means it will still be vulnerable to attacks originating from that domain, despite the fact that the device’s MUD file makes it clear that the device is not authorized to receive traffic from that domain. Because egress DACLs (i.e., DACLs that pertain to traffic that is sent from IoT devices to an external domain) are supported, however, even though packets that are sent from an outside domain are not stopped from being received at the IoT device, return traffic from the device to the external domain will be stopped. This means, for example, that if an attacker is able to get packets to an IoT device from an outside domain, it will not be possible for the attacker to establish a TCP connection with the device from that outside domain, thereby limiting the range of attacks that can be launched against the IoT device. This is expected to be addressed in the future.
  • In working with project collaborators, the NCCoE determined that MUD is only one of several foundational elements that are important to IoT security. First and foremost, it is imperative that IoT device manufacturers follow best practices for security when designing, building, and supporting their devices. Manufacturers should, for example, understand and manage the security and privacy risks posed by their devices as discussed in NISTIR 8228 (Considerations for Managing Internet of Things (IoT) Cybersecurity and Privacy Risks) as well as the more general guidelines for identifying, assessing, and managing security risks that are discussed in the Framework for Improving Critical Infrastructure Cybersecurity (Cybersecurity Framework). In addition, they should continue to support their devices throughout their full life cycle, from initial availability through eventual decommissioning, with regular patches and updates. Cisco has proposed the following four elements as necessary for IoT security:

    • device security by design: Certifiable device capabilities
    • device intent: MUD
    • device network onboarding: Secure, scalable, automated–bootstrapping remote secure key infrastructure/autonomic networking integrated model approach
    • life-cycle management: behavior, software patches/updates

    The NCCoE recommends additional work with IoT security that builds on the broader set of security controls.

6.2. Security Considerations

Use of MUD, when implemented correctly, allows manufacturers to constrain communications to and from IoT devices to only those sources and destinations intended by the device’s manufacturer. By restricting an IoT device’s communications to only those that it needs to fulfill its intended function, MUD reduces both the communications vectors that can be used to attack a vulnerable IoT device and the communications vectors that a compromised IoT device can use to attack other devices. MUD does not, however, provide any inherent security protections to IoT devices themselves. If a device’s MUD file permits an IoT device to receive communications from a malicious domain, traffic from that domain can be used to attack the IoT device. Similarly, if the MUD file permits an IoT device to send communications to other domains, and if the IoT device is compromised, it can be used to attack those other domains. Users implementing MUD are advised to keep the following security considerations in mind.

  • It is important to ensure that the MUD implementation itself is secure and not vulnerable to attack. If the MUD implementation itself were to be compromised, the compromised MUD infrastructure would serve as a venue for attack. As stated in the Security Considerations section of the MUD Specification (RFC 8520), “the basic purpose of MUD is to configure access, and so by its very nature can be disruptive if used by unauthorized parties.” Protecting the MUD infrastructure includes ensuring the security of the IoT device MUD URL emission, the MUD manager, the DHCP server, the MUD file server, the router, and the private key used to sign the MUD file. If the MUD implementation itself is compromised—e.g., if an IoT device emits an incorrect MUD file URL; if a different MUD file URL is sent to the MUD manager than that provided by the IoT device; if a well-formed, signed MUD file is malicious; if a bad actor creates a compromised MUD manager; or if a router is compromised so that it does not enforce its ACL rules—then MUD can be used to enable rather than prevent potentially damaging communications between affected IoT devices and other domains.

  • If a bad actor is able to create a well-formed, signed, malicious MUD file, the undesirable communications that will be permitted by that MUD file will be readily visible by reading the MUD file. Therefore, for added protection, users implementing MUD should review the MUD file for their IoT devices to ensure it specifies communications that are appropriate for the device. Unfortunately, on home and small-business networks, where users are not likely to have the technical expertise to enable themselves to understand how to read MUD files, users will be required to trust that the MUD files specify communications appropriate for the device or rely on a third party to perform this review for them.

  • To protect all IoT devices on a network, both MUD-capable and non-MUD-capable, users may want to consider investigating mechanisms for supplying MUD files for legacy (non-MUD-capable) devices.

  • By emitting a MUD URL, a device reveals information about itself, thereby potentially providing an attacker with guidance on what vulnerabilities it might have and how it might be attacked.

  • An attacker could spy on the MUD manager to determine what devices are connected to the network and then use this information to plan an attack.

  • If an attacker can gain access to the local network, they may be able to use the MUD manager in a reflected DoS attack by emitting a large amount of MUD URLs (e.g., from spoofed MAC addresses) and forcing the MUD manager to make connection attempts to retrieve files from those MUD URLs. Safeguards to counter this, such as throttling connection attempts of the MUD manager, should be considered.

  • MUD users should understand that the main benefit of MUD is its ability to limit an IoT device’s communications profile; it does not necessarily permit owners to find, identify, and correct already-compromised IoT devices.

  • If a system is compromised but it is still emitting the correct MUD URL, MUD can detect and stop any unauthorized communications that the device attempts. Such attempts may also indicate potential compromises.

  • On the other hand, a system could be compromised so that it emits a new URL referencing a MUD file that a malicious actor has created to enable the compromised device to engage in communications that should be prohibited. In this case, whether the compromised system will be detected depends on how the MUD manager is configured to react to such a change in MUD URL. According to the MUD specification, if a MUD manager determines that an IoT device is sending a different MUD URL, the MUD manager should not use this new URL without some additional validation, such as a review by a network administrator.

    • If the MUD manager requires an administrator to accept the new URL but the administrator does not accept it, MUD would help owners detect the compromised system and limit the ability of the compromised system to be used in an attack.
    • However, if the MUD manager does not require an administrator to accept the new URL or if it requires an administrator to accept the new URL and the administrator does accept the new URL, MUD would not help owners detect the compromised system, nor would it limit the ability of the compromised system to be used in an attack.
    • As a third possibility, a compromised system could be subjected to a more sophisticated attack that enables it to dynamically change its identity (e.g., its MAC address) along with emitting a new URL. In this case, the compromised system would not be detected unless the MUD manager were configured to require the administrator to explicitly add each new identity to the network.
  • The following security considerations are specific to the MUD deployment and configuration process:

    • When an IoT device emits its MUD URL by using DHCP or LLDP rather than using an X.509 certificate that can be used to provide strong authentication of the device, the device may be able to lie about its identity and thereby gain network access it should not have. If a network includes IoT devices that emit their MUD URL by using one of these insecure mechanisms, as does the MUD build implemented in this project, network administrators should take additional precautions to try to improve security. For example, the MUD implementation should be configured to:

      • prevent devices that have not been authenticated from being in the same class as devices that have been strongly authenticated to prevent the nonauthenticated devices from getting possibly elevated permissions that are granted to the authenticated devices
      • prevent devices that have not been authenticated from being able to use the same MUD URL as devices that have been strongly authenticated
      • whenever possible, bind communications to the authentication that has been used, e.g., IEEE 802.1X, 802.1AE (MACsec), 802.11i (WPA2), or future authentication types
      • remove state if an unauthenticated method of MUD URL emission is being used and any form of break in that session is detected
      • not include unauthenticated devices into the manufacturer grouping of any specific manufacturer without additional validation
      • use additional discovery and classification components that may be on the network to try to fingerprint devices that have not been authenticated to try to verify that they are of the type they are asserting to be by their MUD URLs
      • To protect against rogue Certificate Authorities, the MUD implementation should be configured to raise an alert and require administrator approval if the MUD manager detects that the signer of a MUD file has changed.
      • To protect compromised IoT devices that seek to be associated with malevolent MUD files, the MUD implementation should be configured to raise an alert and require administrator approval if the MUD manager detects that a device’s MUD file has changed.
      • To protect against domain name ownership changes that would permit a bad actor to provide MUD files for a device, MUD managers should be configured to cache certificates used by the MUD file server. If a new certificate is retrieved, the MUD manager should check to see if ownership of the domain has changed and, if so, it should raise an alert and require administrator approval.

The above bullets provide only a summary of the security considerations discussed in the MUD Specification (RFC 8520). Users deploying a MUD implementation are encouraged to consult that document directly for more detailed discussion.

Additionally, please refer to NISTIR 8228 (Considerations for Managing Internet of Things (IoT) Cybersecurity and Privacy Risks) for more details related to IoT cybersecurity and privacy considerations.

6.3. Recommendations

The following are recommendations for using MUD:

  • Home and small-business network owners should enable MUD on their networks by deploying a MUD-capable infrastructure.
  • Home and small-business network owners should select and use MUD-capable IoT devices on their networks.
  • ISPs should consider providing and supporting MUD-capable home routers for their customers.
  • IoT device manufacturers should configure their devices to emit a MUD URL by default.
  • IoT device manufacturers should write MUD files for their devices. By doing so, they will be able to provide network administrators the confidence to know what sort of access their device needs (and what sort of access it does not need), and they will do so in a way that someone trained to operate and install the device does not need to understand network administration.
  • IoT device manufacturers should ensure that the MUD files for their devices remain continuously available by hosting these MUD files at their specified MUD URLs throughout the devices’ life cycles.
  • IoT device manufacturers should update each of their MUD files over the course of their devices’ life cycles, as needed, in the event that the communications profiles for their devices evolve.
  • Even after an IoT device manufacturer deprecates an IoT device so that it will no longer be supported, the manufacturer should continue to make the device’s MUD file available so the device’s communications profile can continue to be enforced. This will be especially important for deprecated IoT devices that have unpatched vulnerabilities.
  • IoT device manufacturers should provide regular updates to patch security vulnerabilities and other bugs that are discovered throughout the life cycle of their devices, and they should make these updates available at a designated URL that is explicitly named in the device’s MUD file as being a permissible end point with which the device may communicate.
  • Manufacturers of MUD managers, MUD-capable DHCP servers, and MUD-capable routers that are targeted for use on home and small-business networks should strive to make deployment and configuration of these devices as easy to understand and as user-friendly as possible to increase the probability that they will be deployed and configured correctly and securely, even when the person performing the deployment has limited understanding of network administration.
  • Home and small-business network owners should have visibility into every device on their network. Any device is a potential attack or reconnaissance point that must be discovered and secured. In particular, non-MUD-capable devices are inviting targets.
  • Home and small-business network owners should segment their networks where possible. In small-business and home environments it may not be possible to apply good segmentation policies. But at a minimum, where there are IoT devices that are known to have security risks, e.g., non-MUD-capable devices, keep these on a separate network segment from the everyday computing devices that are afforded with a higher level of cybersecurity protection via regular updates and security software. This is an important step to contain any threats that may emerge from the IoT devices.
  • Home and small-business network owners should use the information presented in the Security Considerations section of the MUD Specification (RFC 8520) to enhance protection of MUD deployments.
  • Home and small-business network owners should consider their deployment of MUD to be only one pillar in the overall security of their network and IoT devices. Deployment of MUD is not a substitute for performing best practices to ensure overall, comprehensive security for their network as a whole.
  • Standards development organizations should standardize communications between the MUD manager and the router, between the threat signaling server and the MUD manager/router, and between the IoT devices and their corresponding update servers.
  • Manufacturers of MUD-capable network components and MUD-capable IoT devices should consider MUD to be only one pillar in helping users secure their networks and IoT devices. Manufacturers should, for example, understand the security and privacy risks posed by their devices as discussed in NISTIR 8228 (Considerations for Managing Internet of Things (IoT) Cybersecurity and Privacy Risks) as well as the guidelines for identifying, assessing, and managing security risks that are discussed in the Framework for Improving Critical Infrastructure Cybersecurity (Cybersecurity Framework). They should use this information as they make decisions regarding both how they design their MUD-capable components and the default configurations with which they provide these components, being mindful of the fact that home and small-business network users of their components may have only a limited understanding of network administration and security.

The following recommendations are suggestions for continuing activity with the collaboration team:

  • Continue work with collaborators to enhance MUD capabilities in their commercial products (see Section 6.1).

  • Perform additional work that builds on the broader set of security controls identified in Section 5.2.

  • Work with collaborators to demonstrate MUD deployments that are configured to address the security considerations that are raised in the MUD specification, such as

    • configuring IoT devices to emit their MUD URLs in a secure fashion by providing the IoT devices with credentials and binding the device’s MUD URLs with their identities
    • restricting the access control permissions of IoT devices that do not emit their MUD URLs in a secure fashion, so they are not elevated beyond those of devices that do not present a MUD policy
    • configuring the MUD manager to raise an exception and seek administrator approval if the signer of a MUD file or the MUD file itself changes
    • for IoT devices that do not emit their MUD URLs in a secure fashion, if their MUD files include rules based on the “manufacturer” construct, performing additional validation measures before admitting the devices to that manufacturer class. For example, look up each device’s MAC address and verify that the manufacturer associated with that MAC address is the same as the manufacturer specified in the “manufacturer” construct in that device’s MUD file.
  • Explore the possibility of using crowdsourcing and analytics to perform traffic flow analysis and thereby adapt and evolve traffic profiles of MUD-capable devices over the course of their use. Instead of simply dropping traffic that is received at the router if that traffic is not within the IoT device’s profile, this traffic could be quarantined, recorded, and analyzed for further study. An analytics application that receives such traffic from many sources would be able to analyze the traffic and determine whether there may be valid reasons to expand the device’s communications profile.

  • Work with collaborators to define a blueprint to guide IoT device manufacturers as they build MUD support into their devices, from initial device availability to eventual decommissioning. Provide guidance on required and recommended manufacturer activities and considerations.

7. Future Build Considerations

As the MUD build proceeded, some emerging components were not included in our initial demonstration platform. The physical architecture described in Section 4.2 and the technologies identified in Section 4.3 describe those components that were demonstrated in the course of developing this preliminary practice guide. The team is working on additional builds that include additional components that have become available. Findings from the demonstration of components, including those described in Appendix A, will appear in a subsequent version of this draft practice guide.

The number of components that can employ the MUD protocol continues to grow rapidly. It is recommended that this project be further extended to demonstrate the capabilities of the maturing offerings of technology providers and to integrate additional related capabilities such as threat signaling. In addition, IPv6, for which MUD-capable products were unavailable for the initial demonstration sequences, adds a new dimension to using MUD to help mitigate IoT-based DDoS threats. As discussed in Section 7.2 below, inclusion of IPv6-capability should be considered for future builds.

7.1. Extension to Demonstrate the Growing Set of Available Components

ARM, CableLabs, Cisco, CTIA, DigiCert, ForeScout, Global Cyber Alliance, MasterPeace Solutions, Molex, Patton Electronics, and Symantec have signed CRADAs and are collaborating in the project. There is also strong interest from additional industry collaborators to participate in future builds, particularly if we expand the project scope to include the enterprise use case. Several of these new potential collaborators may submit letters of interest leading to CRADAs for participation in tackling the challenge of integrating MUD and other security features into enterprise or industrial IoT use cases. Appendix A describes components scheduled for demonstration in the second phase of this project.