Skip to main content

D3 Problem Statement

To best protect IoT devices from security threats, we need to be able to make statements about device types and reason about device types. Where these security detection methods and mitigation methods are implemented on the gateway, this is particularly important as the gateway is a separate physical device to the IoT device and has no direct physical connection to or knowledge of the device in question. Every action the gateway may take is based on an assumption of which device type the device in question most closely resembles. Being able to interoperably and securely express information relating to device types is of great value to many security processes.

For a few very simple examples

  1. Network protection: if we know webcams of model number XXNNZZ, from manufacturer XXX Corp, only communicate to a restricted number of public internet addresses, the gateway can detect activity outside of this scope and lock it down if necessary
  2. Firmware updates: if the gateway can determine an IoT endpoint device type, it can directly notify users when new firmware's are available across a broad portfolio of installed devices, directly reducing security risks.
  3. Vulnerability disclosure: when any actor reports a vulnerability against a device, they do so usually against a "class" of devices, not an individual device. Being able to identify this class of device clearly and unambiguously obviously helps with the process of reporting vulnerabilities and investigation

Functional Use cases​

We have broken down the potential use of D3 claims into a number of discrete use cases (UCs).

  • UC1: Assertion: assert the existence of a new device type, tying it to key metadata such as manufacture and externally visible model number
  • UC2: Recognition: the mechanism by which an individual device instance can be recognised as a device type
  • UC3: Least privilege (static behaviour) definition from authority: define the limits on networking behaviour expected of this device (ports and IP addresses), where this description comes from an external authority
  • UC4: Least privilege (static behaviour) from inference: user intelligence at the gateway or cloud to infer a list of static behaviours (safelists) from network traffic
  • UC5: Least privilege (static behaviour) enforcement: implement constraints (at the router) limiting behaviour to the constraint defined
  • UC6: Dynamic behaviour definition from authority: create a more complex description of behaviours, where the behaviour changes over time (e.g. grammars and statistical distributions), where this description comes from an external authority
  • UC7: Dynamic behaviour from inference: complex behaviour description inferred (algorithmically) from network behaviours.
  • UC8: Dynamic behaviour enforcement: detect and restrict network activity, if dynamic behaviour descriptions are detected
  • UC9: Update method: identify the source from which updates can be reliably retrieved
  • UC10: Vulnerability disclosure: disclose a vulnerability or report an incident with maximum specificity
  • UC11: BOM/Vulnerability detection: declare the bill of materials (hardware and software), to help with vulnerability analysis
  • UC12: Hierarchy: define a type hierarchy: where one device type inherits qualities from a parent. This streamlines expressions (normalised data) and helps where the system must reason under uncertainty.
  • UC13: Failure mode and diagnostics: detailed device type information helps diagnose and report faults
  • UC14: Sharing data logs: use as a method of sharing data activity, with integrity preservation, and encryption built-in

Types of behaviour​

In the list above, we distinguish between two types of behaviour:

  1. Static behaviour: means the behaviour or behavioural restrictions don't change over time. Essentially this amounts to IP/Port safelists.
  2. Dynamic behaviour: These are behaviours that change over time. These are likely to be statistical descriptions of behaviour or grammars.

Origin of D3 claims - use cases​

The use cases listed above outline the different types of statements that can be made and how they can be used.

A key design requirement of the D3 system is the distributed nature of the claims. Specifically, both the claims' assertion and the claim's workflow are designed to be as flexible as possible.

Existing methods for declaring device information assume the originating manufacturer as the ultimate authority (references).

The D3 system has been designed without this underlying assumption. The main reasons this is important are:

  1. The manufacturer may go out of business and therefore be unable to keep the pertinent information up to date.
  2. The user of the IoT device may not trust the information provided by the manufacturer.
  3. The D3 approach must address legacy devices (devices in the field). Presuming that each originating historical manufacturer populates their statements impedes adoption
  4. Crowdsourcing: we want an approach that can harness crowdsourcing and open-source approaches to population
  5. Networking effects: any system that

Some of the specific scenarios that need to be considered when considering who can make a claim and what form of claim approvals may exist

  • Manufacturer: the originating manufacturer must be able to make claims about devices
  • Supplier: the retailer or service provider must be able to make claims about devices (the company )
  • Intermediate: an intermediate trusted authority must be able to make claims (or support claims) about devices
  • Owner: the legal and pragmatic owner of the device (or an instance of the device) in question
  • Crowdsourcing: the "man in the street" must be able to make claims (or support claims) about devices, to allow for crowd sourcing of information
  • Code: software programs, or intelligent agents, whether local applications or cloud services, must be able to make claims (or support claims) about devices

D3 claims - workflow use cases​

D3 claims are designed to evolve. No statement is ever perfect in perpetuity.

In addition, given that anyone can make D3 statements by design, the system needs to be able to provide the ability to transfer practical ownership and make statements of support, even refutations.

D3 claims - trust foundations​

The D3 system will be designed to have actor subjective trust inferencing

The D3 client (the entity making a decision based on D3 statements) can determine what credence is given to each issuer.