NIST SPECIAL PUBLICATION 1800-15 PRELIMINARY DRAFT


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

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


Functional Demonstration Results Supplement to NIST Special Publication 1800-15B


Mudumbai Ranganathan

NIST


William C. Barker

Dakota Consulting


Drew Cohen

Kevin Yeich

MasterPeace Solutions


Eliot Lear

Cisco


Adnan Baykal

Global Cyber Alliance


Yemi Fashina

Parisa Grayeli

Joshua Harrington

Joshua Klosterman

Blaine Mulugeta

Susan Symington

The MITRE Corporation



November 2019


PRELIMINARY DRAFT


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


nccoenistlogos

List of Tables

Table 1‑1: Test Case Fields

Table 2‑1: MUD Use Case Functional Requirements

Table 2‑2: Test Case IoT-1-v4

Table 2‑3: Test Case IoT-2-v4

Table 2‑4: Test Case IoT-3-v4

Table 2‑5: Test Case IoT-4-v4

Table 2‑6: Test Case IoT-5-v4

Table 2‑7: Test Case IoT-6-v4

Table 2‑8: Test Case IoT-7-v4

Table 2‑9: Test Case IoT-8-v4

Table 2‑10: Test Case IoT-9-v4

Table 2‑11: Test Case IoT-10-v4

Table 2‑12: Test Case IoT-11-v4

Table 2‑13: Non-MUD-Related Functional Capabilities Demonstrated

Table 2‑14: Exercise CnMUD-13-v4

Table 3‑1: MUD Use Case Functional Requirements

Table 3‑2: Test Case IoT-1-v4

Table 3‑3: Test Case IoT-2-v4

Table 3‑4: Test Case IoT-3-v4

Table 3‑5: Test Case IoT-4-v4

Table 3‑6: Test Case IoT-5-v4

Table 3‑7: Test Case IoT-6-v4

Table 3‑8: Test Case IoT-7-v4

Table 3‑9: Test Case IoT-8-v4

Table 3‑10: Test Case IoT-9-v4

Table 3‑11: Test Case IoT-10-v4

Table 3‑12: Test Case IoT-11-v4

Table 3‑13: Non-MUD-Related Functional Capabilities Demonstrated

Table 3‑14: Exercise YnMUD-1-v4

Table 3‑15: Exercise YnMUD-2-v4

Table 3‑16: Exercise YnMUD-3-v4

Table 3‑17: Exercise YnMUD-4-v4

Table 3‑18: Exercise YnMUD-5-v4

Table 3‑19: Exercise YnMUD-6-v4

Table 5‑1: MUD Use Case Functional Requirements

Table 5‑2: Test Case IoT-1-v4

Table 5‑3: Test Case IoT-2-v4

Table 5‑4: Test Case IoT-3-v4

Table 5‑5: Test Case IoT-4-v4

Table 5‑6: Test Case IoT-5-v4

Table 5‑7: Test Case IoT-6-v4

Table 5‑8: Test Case IoT-8-v4

Table 5‑9: Test Case IoT-9-v4

Table 5‑10: Test Case IoT-11-v4

1 Introduction

The National Institute of Standards and Technology (NIST) Cybersecurity Practice Guide explains how the Manufacturer Usage Description (MUD) Specification (Internet Engineering Task Force [IETF] Request for Comments [RFC] 8520) can be used to reduce the vulnerability of Internet of Things (IoT) devices to botnets and other network-based threats as well as reduce the potential for harm from exploited IoT devices. It describes the logical architecture of a standards-based reference design for using MUD, threat signaling, and employing software updates to significantly increase the effort required by malicious actors to compromise and exploit IoT devices on a home or small-business network. It provides users with the information they need to replicate deployment of the MUD protocol to mitigate IoT-based distributed denial of service (DDoS) threats. The 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

  • NIST SP 1800-15C: How-To Guides—instructions for building the example solutions

This document, Functional Demonstration Results, is a supplement to NIST SP 1800-15B, Approach, Architecture, and Security Characteristics. This proof-of-concept document describes the functional demonstration results for three implementations of the reference design that were demonstrated as part of this National Cybersecurity Center of Excellence (NCCoE) project. These implementations are referred to as builds. Four builds are implemented, one of which is still under development. The functional demonstration results of three of these builds are reported in this document:

  • Build 1 uses equipment from Cisco Systems and Forescout. The Cisco MUD Manager is used to provide support for MUD, and the Forescout Virtual Appliances and Enterprise Manager are used to perform non-MUD-related device discovery on the network.


  • Build 2 uses equipment from MasterPeace Solutions Ltd., Global Cyber Alliance (GCA), and ThreatSTOP. The MasterPeace Solutions Yikes! router, cloud service, and mobile application are used to support MUD, as well as to perform device discovery on the network and to apply additional traffic rules to both MUD-capable and non-MUD-capable devices based on device manufacturer and model. The GCA Quad9 DNS Service and the ThreatSTOP Threat MUD File Server are used to support threat signaling.


  • Build 3 uses equipment from CableLabs to onboard devices and support MUD. Although limited functionality of a preliminary version of this build has been demonstrated as part of this project, elements of Build 3 are still under development. Therefore, it has not yet been subjected to functional evaluation or demonstration of the full range of its capabilities.


  • Build 4 uses software developed at the NIST Advanced Networking Technologies laboratory. This software serves as a working prototype for demonstrating the feasibility and scalability characteristics of the MUD RFC.

For a more comprehensive description of each build and a detailed explanation of each build’s architecture and technologies, refer to NIST SP 1800-15B.

1.1 Objective

This document, Functional Demonstration Results, reports the results of the functional evaluation and demonstration of Builds 1, 2, and 4. For each of these builds, we defined a list of requirements unique to that build and then developed a set of test cases to verify that the build meets those requirements. The requirements, test cases, and test results for each of these three builds are documented below.

1.2 Functional Demonstration Activities

Builds 1, 2, and 4 were tested to determine the extent to which they correctly implement basic functionality defined within the MUD RFC. Builds 1 and 2 were also subjected to additional exercises that were designed to demonstrate non-MUD-related capabilities. These additional exercises were demonstrative rather than evaluative. They did not verify the build’s behavior for conformance to a standard or specification; they were designed to demonstrate advertised capabilities of the builds related to their ability to increase device and network security in ways that are independent of the MUD RFC. These additional capabilities may provide security for both non-MUD-capable and MUD-capable devices. Examples of this type of capability include device discovery, identification and classification, and support for threat signaling.

1.3 Assumptions

The physical architecture of each build as deployed in the NCCoE laboratory environment is depicted and described in NIST SP 1800-15B. Tests for each build were run on the lab architecture documented in NIST SP 1800-15B. Prior to testing each build, all communication paths to the IoT devices on the network were open and could potentially be used to attack systems on the internet. For traffic to be sent between IoT devices, it was required to pass through the router/switch that served as the policy enforcement point (PEP) for the MUD rules.

In the lab setup for each build, the following hosts and web servers were required to be set up and available to support the tests defined below. On the local network where the IoT devices are located, hosts with the following names must exist and be reachable from an IoT device that is plugged into the local network:

  • unnamed-host (i.e., a local host that is not from the same manufacturer as the IoT device in question and whose MUD Uniform Resource Locator (URL) is not explicitly mentioned in the MUD file of the IoT device as denoting a class of devices with which the IoT device is permitted to communicate. For example, if device A’s MUD file says that it may communicate locally with devices that have MUD URLs www.zzz.com and www.xxx.com, then a local host that has a MUD file of www.qqq.com could be unnamed-host.)

  • anyhost-to (i.e., a local host to which the IoT device in question is permitted to initiate communications but not vice versa)

  • anyhost-from (i.e., a local host that is permitted to initiate communication to the IoT device but not vice versa)

  • same-manufacturer-host (i.e., a local host that is from the same manufacturer as the IoT device in question. For example, if device A’s MUD file is found at URL www.aaa.com and device B’s MUD file is also found at URL www.aaa.com, then device B could be same-manufacturer-host.)

On the internet (i.e., outside the local network), the following web servers must be set up and reachable from an IoT device that is plugged into the local network:

  • https://yes-permit-to.com (i.e., an internet location to which the IoT device in question is permitted to initiate communications but not vice versa)

  • https://yes-permit-from.com (i.e., an internet location that is permitted to initiate communications to the IoT device but not vice versa)

  • https://unnamed.com (i.e., an internet location with which the IoT device is not permitted to communicate)

We also defined several MUD files for each build (provided in each build section below) that were used to evaluate specific capabilities.

1.4 Document Conventions

For each build, a set of requirements and a corresponding set of functional test cases were defined to verify that the build meets a specific set of requirements that are unique to that build. For evaluating MUD-related capabilities, these requirements are closely aligned to the order of operations in the Manufacturer Usage Description Specification (RFC 8520). However, even for MUD-specific tests, there are tests that are applicable to some builds but not to others, depending on how any given build is implemented.

For each build, the MUD-related requirements for that build are listed in a table. Each of these requirements is associated with two separate tests, one using Internet Protocol version 4 (IPv4) and one using IPv6. At the time of testing, however, IPv6 functionality was not fully supported by any of the builds and so was not evaluated. The names of the tests in which each requirement is tested are listed in the rightmost column of the requirements table for each build. Tests that end with the suffix “v4” are those in which IPv4 addressing is used; tests that end with the suffix “v6” are those in which IPv6 addressing is used. Only the IPv4 versions of each test are listed explicitly in this document. For each test that has both an IPv4 and an IPv6 version, the IPv4 version of the test, IoT-n-v4, is identical to the IPv6 version of the test, IoT-n-v6, except:

  • IoT-n-v6 devices are configured to use IPv6, whereas IoT-n-v4 devices are configured to use IPv4.

  • IoT-n-v6 devices are configured to use Dynamic Host Configuration Protocol version 6 (DHCPv6), whereas IoT-n-v4 devices are configured to use DHCPv4.

  • The IoT-n-v6 DHCPv6 message that is emitted includes the MUD URL option that uses Internet Assigned Numbers Authority (IANA) code 112, whereas the IoT-n-v4 DHCPv4 message that is emitted includes the MUD URL option that uses IANA code 161.

Each test consists of multiple fields that collectively identify the goal of the test, the specifics required to implement the test, and how to assess the results of the test. Table 1‑1 describes all test fields.

Table 1-1 Test Case Fields

Test Case Field

Description

Parent Requirement

Identifies the top-level requirement or the series of top-level requirements leading to the testable requirement

Testable Requirement

Guides the definition of the remainder of the test case fields, and specifies the capability to be evaluated

Description

Describes the objective of the test case

Associated Test Case(s)

In some instances, a test case may be based on the outcome of (an)other test case(s). For example, analysis-based test cases produce a result that is verifiable through various means (e.g., log entries, reports, and alerts).

Associated Cybersecurity Framework Subcategory(ies)

Lists the Cybersecurity Framework Subcategories addressed by the test case

IoT Device(s) Under Test

Text identifying which IoT device is being connected to the network in this test

MUD File(s) Used

Name of MUD file(s) used

Preconditions

Starting state of the test case. Preconditions indicate various starting-state items, such as a specific capability configuration required or specific protocol and content.

Procedure

Step-by-step actions required to implement the test case. A procedure may consist of a single sequence of steps or multiple sequences of steps (with delineation) to indicate variations in the test procedure.

Expected Results

Expected results for each variation in the test procedure

Actual Results

Observed results

Overall Results

Overall result of the test as pass/fail

Each test case is presented in the format described in Table 1‑1.

1.5 Document Organization

The remainder of this document describes the evaluation and demonstration activities that were performed for Builds 1, 2, and 4. Each build has a section devoted to it, with that section being divided into subsections that describe the evaluation of MUD-related capabilities and the demonstration of non-MUD-related capabilities (if applicable). The MUD files used for each build are also provided.

Acronyms used in this document can be found in the Acronyms Appendix in NIST SP 1800-15B.

1.6 Typographic Conventions

The following table presents typographic conventions used in this document.

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.

2 Build 1

Build 1 uses equipment from Cisco Systems and Forescout. The Cisco MUD Manager is used to support MUD and the Forescout Virtual Appliances, and Enterprise Manager is used to perform non-MUD-related device discovery on the network.

3 Build 2

Build 2 uses equipment from MasterPeace Solutions Ltd., GCA, and ThreatSTOP. The MasterPeace Solutions Yikes! router, cloud service, and mobile application are used to support MUD as well as to perform device discovery on the network and to apply additional traffic rules to both MUD-capable and non-MUD-capable devices based on device manufacturer and model. The GCA Quad9 DNS Service and the ThreatSTOP Threat MUD File Server are used to support threat signaling.

4 Build 3

Build 3 is still under development by CableLabs. Therefore, it has not yet been fully demonstrated. Documentation of Build 3’s functional evaluation and demonstration is planned for inclusion in the next phase of this project.

5 Build 4

Build 4 uses software developed at the NIST Advanced Networking Technologies laboratory. This software provides support for MUD and is intended to serve as a working prototype of the MUD RFC to demonstrate feasibility and scalability.