In order 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 an 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, 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

For two very simple examples

1. Network protection: if we know webcams of model number XXNNZZ, from manufacturer XXX Corp, only communicate to 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 end point device type it can directly notify users when new firmware's are available across a broad portfolio of installed device, thereby directly reducing security risks.

Use cases

We have broken down the use of D3 claims into a number of use cases.

• UC1: Assertion: assert the existence of a new device type, tying it to key meta data 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 (whitelists) 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 (eg. 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 is helpful in diagnosing and reporting faults
• UC14: Sharing data logs: use as a method of sharing data activity, with integrity preservation, and encryption built in

TODO

Change the examples in the D3 demo so it doesn't distract...

Types of behaviour

In the list above we distinguish between two types of behaviour

1. Static behaviour: which means the behaviour or behavioural restrictions don't change over time. Essentially this amounts to IP/Port whitelists
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

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 assertion of the claims and the workflow of the claim are designed to be as flexible as possible.

Many existing methods for declaring device information tend to assume the originating manufacture to be the ultimate authority (references). The D3 system has been designed without this underlying assumption. To examples of why this is important.

1. The manufacture may go out of business, and therefore 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

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

• Manufacturer: the originating manufacture must be able to make claims about devices
• Supplier: the retailer or service provider must be able to make claims about devices
• Intermediate: and intermediate trusted authority must be able to make claims (or support claims) about devices
• Crowd sourcing: 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