mike1813
commented
1 year ago Some of the steps envisaged here have already been done while addressing issue #32. In particular, two new relationship types were created:
- Sensor-senses-Data: means the Data is produced as output by the Sensor
- Data-controlsThing-Thing: means the Data controls the Thing
Where the second of these is used with an IoT Sensor it affects the output of the Sensor. For an IoT Controller it affects how the Controller influences the physical world.
However, other steps have not been completed. In particular, the construction patterns create the onboard data related to each Thing, but don't exclude cases where an asserted Data asset has the relevant relationship.
In the short term, the best solution is to make the new relationships 'hidden' (i.e., non-assertible). In the longer term, we need to modify the construction patterns so the inferred Data is not added if there is already an asserted Data asset, and make these new relationships assertible once again.
In a recent tutorial exercise for new users at Southampton, it became apparent that the current IoT model may be confusing for some users.
In the current IoT model, an IoT device is either a Controller (something that interacts with its physical environment) or a Sensor (which only measures the physical environment). The environment can be a Space (indicated via the 'locatedIn' relationship) or a Human (using the 'relatesTo' relationship).
The IoT device itself is represented as a type of physical host, which is neither fixed nor mobile (mobility is inferred if the device is related To a Human). Inference rules then add a Data asset representing the data created and (in the case of a Controller) used by the Thing, and one or two Process assets handling communication of that data between the Thing and other parts of the system.
An IoT device, although nominally a type of Host, is therefore modelled as a combination of Host, Process and Data assets.
Each type of Thing can have specific types of relationships to or from external Processes (not hosted by the Thing) indicating that those Processes are at the other end of data communications with the Thing. These relationships are similar to Process-Data relationships, and inference rules convert them into relationships between the external Process and the inferred Data asset on the Thing. A Thing also has some Trustworthiness Attributes and Consequence types that are characteristic of Process or Data assets.
By the end of the inference process, each Thing becomes represented by a Host (the Thing), one or two Processes, and a Data asset. The connection of the Thing to networks is indicated by relationships between the Host and system Subnets. Data exchange with the Thing is modelled by inferred relationships between its Process and Data assets and external Processes. Cybersecurity threats that involve Host-Subnet, Process-Process or Process-Data relationships are then applied to model potential threats to the Thing.
The advantage of this is that we don't need a separate set of IoT-specific threats to capture security risks in systems containing Things. The knowledge base only needs to capture threats to Hosts, Processes and Data because these will apply in appropriate ways to Things.
The only 'IoT-specific' threats are so-called 'surfacing' threats that propagate effects on the inferred Process and Data to the Thing itself. This means users can specif impact levels for the Thing, instead of having to find the inferred assets. For example, if the Authenticity of a Sensor's Data is compromised, this acts as a cause for a surfacing threat leading to Loss of Authenticity for the Sensor. The user can set the impact level at the Sensor (which is an asserted asset and visible in the system-modeller GUI), rather than the Data (which being an inferred asset, is not visible).
One disadvantage is that because the Data is not visible, users are tempted to add it. This causes confusion because their Data is not the Data that leads to effects on the Thing. Another is the fact that the external Process that (say) reads a Sensor can't easily send the Sensor Data for processing or storage elsewhere. To do that, another process would need a relationship with the Sensor Data, and that is hard to implement when the Sensor Data is not visible.
To overcome the disadvantages while retaining the advantages, there are two options.
The first option is the subject of a separate issue in the system-modeller project https://github.com/SPYDERISK/system-modeller/issues/38. This issue proposes implementation of the second option.