Having reviewed several methodologies to develop Digital Twins for the purpose of supporting cyber security monitoring and investigation i decided that the AWS IOT Things Graph Data Model (TDM) domain constructs was a way to help define and organise the Device Digital Twin structure within a Protege OWL ontology.
The TDM offers a way to align the constructs to security use cases which i researching as part of this proof of concept. The table below shows the construct and supporting use case.
| AWS IOT Things Graph Data Model (TDM) domain constructs | AWS Description | Security Control and Monitoring Use Case |
|---|---|---|
| State | The State construct is a set of properties that represent the inner state of a device at a point in time. | Determine the normal or abnormal state of operations |
| Mapping | The Mapping construct bridges differences across multiple representations of the same concept. It converts semantically equivalent data from one representation to another. A Mapping creates a single semantic view of data that originates from multiple sources. | Version control of configuration |
| Event | The Event construct describes a notification from a device that some action has been taken on it including: – The event name – A unique identifier of the source device of the event – A payload containing information that supports handling of the event | Monitor Events in relation to the result of device actions and outcomes |
| Action | The Action construct is an abstract representation of a device performing an instance of its capability. An Action takes properties as its parameters and returns properties as its output. | Monitor Action outputs in relation to an expected outcome |
| Capability | The Capability construct describes a piece of functionality that is implemented by an IoT device. A Capability can extend one or more pre-existing Capabilities. It’s a package containing a State and a set of Actions and Events. A Capability definition consists of the following: – A unique identifier – At most, one State – A set of Actions – A set of Events | Define the properties required to fulfil the Capability as per the expected Actions. Monitor Capability over a time period to determine normal or abnormal patterns |
| Device Model | The DeviceModel construct describes an abstraction of an IoT device or a stateful service. A DeviceModel must implement one Capability. It represents a conceptual device and isn’t tied to any specific manufacturer. A DeviceModel consists of the following: A TDM URN that identifies the device model A TDM URN that identifies the device model’s Capability | The parent class or master digital twin of the concept. Incorporates the Capabilities and subsequent requirements. This should construct the generalised monitoring requirements. |
| Device | The Device construct describes a specific IoT device that implements the Capability of a DeviceModel. This is not a concrete device, but an abstract definition of a device. After a device is defined in TDM, concrete devices can be mapped to the device definition. A Device definition includes the following: – An implementation of the parent device model’s State – An implementation of the parent device model’s Actions and Events in the context of a specific communication protocol, such as MQTT or Modbus | A sub-class or variant of the Device Model forming a digital twin of the specification and configuration of the Device for the purpose of association with the Asset Management of the physical device. |
| Service | The Service construct describes either an AWS Lambda or a RESTful web service that can be called from a Workflow. Conceptually a Service is analogous to a Device, because it can be called inside a workflow step. The structure of a Service is also similar to that of a Device. The primary difference is that the Action of a Service is a call to the web service or an invocation of a Lambda function. The Service structure contains the input and output parameters of the web service or Lambda call. | A Service associated with working with the IOT Device may exist as an End Point (Tablet or Mobile) App or Cloud application. Requires a digital twin of the service / architecture within its service boundaries and its service model. Requires a complimentary monitoring strategy. |
Workflow | The Workflow construct (also called flow) describes an automated process that consists of multiple devices and stateful services. Workflow takes a set of parameters and consists of an array of steps that are connected to events. Input events can trigger a step, and a step can generate an output event. Each step can represent a Lambda function, a device action, or a web application method. | Monitoring of triggers and actions |
| System | The System construct describes a collection of devices, services, and workflows that interact with each other in an IoT system. For example, a security system can consist of entry sensors, cameras, light bulbs, and a door monitoring workflow. A System can be composed of other systems to create arbitrarily complex systems of systems. | Considered as part of situation awareness and broader monitoring of risk and threat intelligence. |
| Trigger | The Trigger construct defines the conditions that start a workflow. Triggers have two components: a condition and a set of one or more actions. The condition specifies whether to trigger a new workflow, and an action specifies what the workflow does if the condition is true. | Triggers should be classified by the severity of their actions and outcomes so critical triggers are monitored for normal or abnormal behaviours. |
| Deployment | The Deployment construct associates a physical location with specific devices and the triggers that start the workflows in which they are used. | Considered as part of situation awareness and broader monitoring of risk and threat intelligence. |
Smart City Cyber Security 