IoT dependences need overhaul

[mike1813]

The mechanism for 'surfacing' threat consequences at IoT devices is not working as it should.

The basic idea is that a Sensor is a device that acts like a source of Data, while a Controller is a device that acts like a consumer of incoming Data. In each case, if the Data is compromised, so is the IoT device. However, the Data is inferred, so SSM users won't see it on the canvas, and so probably won't specify impact levels for loss of Confidentiality, Integrity, Authenticity Availability.

To solve this, secondary threats were introduced in which each type of compromise of the Data leads to a behaviour of the IoT device. Strictly speaking, these are 'modelling artefacts', but they are processed in exactly the same way as any secondary threat, leading to propagation of effects in the Data up to the visible IoT asset. I refer to this as 'surfacing' the effects which otherwise would only be accessible via an (invisible) inferred asset.

The problem is that the secondary threats takes their causes from the Data asset. This represents the presence of data in the system rather than a copy of that data. Because stored and flowing copies are also inferred, there are 'surfacing' threats that move breaches of C, I, A or Auth on data copies up to the Data asset. But that means IoT devices are connected to any or all copies of their data, which should not be the case.

For example, if a flow of control data from a Controller becomes corrupt, this propagates via the Data asset to the Controller. But in reality the Controller would not be affected unless its onboard stored copy becomes corrupt.

The surfacing threats need some modification so they take their causes from the relevant stored or flowing data copy, or possibly from an onboard process that uses the data...

[mike1813]

Now addressed in branch 2-iot-dependences-need-overhaul.

Not yet merged into the main development branch 6a, because we need to merge this fix with others.

[mike1813]

Now merged.