| 6lo Working Group | M. Richardson |
| Internet-Draft | Sandelman Software Works |
| Intended status: Standards Track | J. Latour |
| Expires: August 17, 2019 | CIRA Labs |
| February 13, 2019 |
A standard process to quarantine and restore IoT Devices
draft-richardson-shg-un-quarantine-00
The Manufacturer Usage Description (MUD) is a tool to describe the limited access that a single function device such as an Internet of Things device might need. The enforcement of the access control lists described protects the device from attacks from the Internet, and protects the Internets from compromised devices.
This document details the process which occurs when a device is detected to have violated the stated policy. The goal of these steps is to ensure that the device is correctly removed from operation, fixed, and if possible, restored to safe operation.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 17, 2019.
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
[I-D.ietf-opsawg-mud] describes the format of the Manufacturer Usage Description (MUD) files. MUD files provide a set of network Access Control Lists (ACL, pronounced [ak-uhl]) that describes the expected traffic from a device, such as an Internet of Things (IoT) device.
MUD files are used in a number of projects, including the CIRALabs' [SecureHomeGateway] (SHG) project. In this project a home gateway ("router") is enhanced to be able to use MUD files to describe the traffic expected from all connected devices. If a device does not have a MUD format description, then the project can provide a broad set of traffic expectations based upon categorization of the device by the home owner.
This document is about the process to be followed when a device is observed to be violating the ACLs applied to it. While this document will identify network protocols (and gaps where no protocol exists) as appropriate, the goal of this document is more about the human process. Specifically, who gets called, and in what order. Who makes each call, and how are they identified.
In addition, what kind of data needs to be shared among the parties and what are the privacy and human rights implications of sharing the required data.
Finally, in the security considerations section of this document some concerns about prevention of so-called "SWAT"ing ({swatting}), where an attempt might be made to take a location or network offline through phony reports.
This document is not a protocol specification, but rather a Best Current Practices in the area of human operations. While this is sometimes called a "Standard Operating Proceedure" (SOP), this document should not be considered the actual SOP for an organization, but rather be referrenced.
The terminology [RFC2119] the key words such as "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119. In the context of this human protocol, they do not describe network protocol interoperability requirements, but rather constraints upon how the humans need to operate in order to avoid unsafe situations.
The following terms are used in this document:
This section provides a brief overview of the states that a device may be in. The following section provides a detailed description of the state. This document is primarily about how a device transitions from one state to another, which is covered in {#transitions}.
.--------. .---------.<---------.------------.
| new |-------->| nominal | | suspicious |
| device |\ .----->| | -------->| |
'--------' \| '---------' '------------'
\ |
|\ | |
| \ | |
| \ v v
| \ .------------. .-----------.
.------------.| v| p0owned | | suspect |
| returning || | | | |
| to service | '------------' '-----------'
'------------' | |
^ | |
| v v
.------------. .------------. .-----------.
| upgrading | | quarantine | | device-of |
| |<-----| |<------| interest |
'------------' '------------' '-----------'
Figure 1: Device Connectivity States
A device is considered to be on one of the above states. The device is not considered to be aware of it's state, rather this is a characteristic that the network assigns to the device.
A device newly installed will have no initial network connectivity. It will be awaiting some kind of enrollment or onboarding process. Examples of enrollment processes include [I-D.ietf-anima-bootstrapping-keyinfra], [dpp], processes defined by The Thread Group and Apple Homekit, as well as a great number of custom and proprietary methods.
In many cases the device may provide limited network connectivity (such as by running as an Access Point), and can be reached by attackers. The owner of the device may in fact in unaware that the device is "smart", and it may be possible for a device to become compromised without ever having joined a network. This case is particularly difficult, as having never joined a network, the device will not emit signals on the owner's network that can be detected to notice that the device has been attacked. Also, having never been connected, the device is more likely to have old firmware.
The device is operating normally and is not suspected to be corrupted or under attack.
The device and/or the Internet has attempted a connection which is forbidden by the MUD file. This activity is notable, but particularly in the case where a MUD file was generated by a third party (such as by a period of observation), it may signal that the MUD file is inaccurate rather than that the device is compromised.
In the case of connections that originate from the Internet to the device which are forbidden, this may indicate that device is being scanned for, but that the security features of the router are resisting the attack.
It is unclear how a device is returned from suspicious state to nominal. A reasonable process might be that after a period of time in which no new unwanted activity occurs it is returned. A clear indication that it should return to nomimal is if a new MUD file is applied to the device.
The device is repeatedly attempting to connect to core infrastructure which it has reasonably no reason to connect to. Examples of this would include connecting to many IP addresses in a sequential or high-frequency rate, connecting to well-known ports not intended to for end devices (for instance TCP port 22, 23, 25). There might still be a reasonable explanation for this behaviour, including that the "inside" IP address has been reassigned to a different device (such as desktop computer).
A device has become interesting based upon two possible situations: an internal signal that a device has become suspected, and based upon external indications that there are active threats against the device. A device in this state SHOULD go into quarantine upon the next observed attack.
If it can be observed that there are DNS spoofing attempts against the device manufacturer's firmware repository, or it's command/control channel (for devices which have cloud connections), then it would be reasonable to become interested in the device: an attack may be coming.
A device under interest would continue to be able to perform it's normal functions. For instance, a furnace would continue to heat the house, and would continue to report it's statistics to it's manufacturer/service-entity, and would continue to respond to thermostat changes.
A device in quarantine gets no Internet or owner network access.
A device in quarantine MAY do DNS requests to the local recursive DNS resolvers for the IP address of it's firmware repository. This address would be present in the device's MUD file using the [I-D.richardson-shg-mud-quarantined-access]. Access to the firmware repository is important to permit the device to apply new firmware and/or reset itself to factory default.
A device in quarantine that performs other functions might continue to be perform those functions. For instance, a fridge would remain cold, but it would not respond to thermostat changes, or communicate with a grocery store.
A device that is disabled gets no network connectivity at all, including no local network connectivity.
A device that is directly mains powered would be disconnected by a human. A device that is powered by Power-over-Ethernet could be disconnected by administratively turning power off on that port.
A device that is battery powered or scavanges power would remain on as long as it had power.
A device that is attempting to return to service has installed some "fix" for the issue that lead it to be quarantined. It could also be the case that the device did not need to anything, and that the quarantine was a false positive, and a new MUD file is loaded with the additionally accepted patterns.
A device returning to service MAY have erased all it's network settings, and will have to go through some form of network enrollment again.
A device which is known to be controlled by a malicious entity. It may be impossible to quarantine the device if it performs some critical function and the imposition of quarantine would prevent that.
This section deals with the transitions between states. These transitions occur as a result of network and/or human signaling. The occurance of these transitions will in most cases cause a signal to be sent.
The process of enrollment is out of scope for this document.
The process of re-enrollment is out of scope for this document. This document does specify when this re-enrollment can take place, and how a human can indicate to a device and to the network infrastructure that re-enrollment can take place.
Re-enrollment can occur a number of different ways.
A device can re-enroll in a factory-default state. This means that all settings are lost and any private keys that might have been visible to malicious code/coders who may have had access to the device have are regenerated.
Devices that store private keys in Trusted Platform Modules (TPM), or in Trusted Execution Environments (see [I-D.ietf-teep-architecture]) could reasonably assume that private keys may be retained. From an 802.1AR perspective, the IDevID may be assumed to be intact, but the integrity of the LDevID may be suspect.
As the device is in a factory-default state it will have no user/owner-specific configuration, and any authorization lists will need to be re-established!
The device does not return to a factory-default state, and has existing network, owner credentials and configuration intact. A network onboarding will need to be repeated to establish new per-device network keys.
An audit of the device authorizations SHOULD be done, as an attacker may have inserted additional authorizations in order to return.
Are there states in between these two extremes?
The transition from nomimal to initial suspicion occurs when the MUD firewall detects (and blocks) network not described in the device MUD. There are a number of non-critical reasons why this could occur.
The mostly likely situation is that the MUD describes access rules using DNS names, while the firewall is implemented in terms of IP addresses. The name to IP mapping may well have changed, and the firewall has not yet caught up to the new mapping.
TBD
TBD
TBD
TBD
Here will be somes examples of a device.
TBD
TBD
TBD
No IANA objects are required.
| [I-D.ietf-opsawg-mud] | Lear, E., Droms, R. and D. Romascanu, "Manufacturer Usage Description Specification", Internet-Draft draft-ietf-opsawg-mud-25, June 2018. |
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [dpp] | "Device Provisioning Protocol Specification", n.d.. |
| [I-D.ietf-anima-bootstrapping-keyinfra] | Pritikin, M., Richardson, M., Behringer, M., Bjarnason, S. and K. Watsen, "Bootstrapping Remote Secure Key Infrastructures (BRSKI)", Internet-Draft draft-ietf-anima-bootstrapping-keyinfra-18, January 2019. |
| [I-D.ietf-teep-architecture] | Pei, M., Tschofenig, H., Wheeler, D., Atyeo, A. and D. Liu, "Trusted Execution Environment Provisioning (TEEP) Architecture", Internet-Draft draft-ietf-teep-architecture-01, October 2018. |
| [I-D.richardson-shg-mud-quarantined-access] | Richardson, M., "Manufacturer Usuage Description for quarantined access to firmware", Internet-Draft draft-richardson-shg-mud-quarantined-access-00, January 2019. |
| [looneytunes] | "List of Looney Tunes Cartoons", n.d.. |
| [SecureHomeGateway] | "CIRALabs Secure Home Gateway", n.d.. |
| [swatting] | "Cambridge English Dictionary: swatting", January 2019. |