44 validation cannot handle asserted relations with inferred assets

[mike1813]

There is now an update to the domain-network KB addressing issue Spyderisk/domain-network#23, which is tagged as v6a3-1-2-beta1 in the Spyderisk domain-network repository.

With this in place, it is possible to run a simple test of the system-modeller fix on branch 44 using the attached system model, which contains a single IoT Sensor. The test sequence is as follows:

• deploy the system-modeller
• deploy domain-network KB v6a3-1-2-beta1
• import the test case
• validate: this will create an onboard SensorProcess and a Data asset representing the sensor output
• select the Sensor and use the properties panel to create a new outbound relationship 'stores' from the Sensor to the inferred Data asset
• revalidate: this should add a stored DataCopy of the Data on the Sensor, and a DataService enabling access to it, plus relationships indicating that the SensorProcess now writes its output to the stored copy

Before the fix, the first validation failed to insert the correct relationship between the Process and Data, due to issue #52. The revalidation would then crash due to issue #44 (a separate problem not due to issue #52).

The fix consists of changes to the implementation of caching and especially cache synchronisation which were the cause of issue #52, and changes to the method for retrieving assets from the triple store which caused issue #44.

Closes #52, #44.
Issue 44 Test - Asserted - Before.nq.gz

[kenmeacham]

The code changes seem reasonable, although I'm struggling to understand much of it.

I did some testing. Firstly just to say I couldn't find v6a3-1-2-beta1, although I did get hold of v6a3-1-2. Not sure if this is a problem?

Using this, I tested first on dev and did get an Exception where expected. I then tried this branch, which gave no errors. As far as I can tell, it produces inferred assets that you mentioned, although was I supposed to see those listed in #52? I don't see OutputPool for example.

If the above can be clarified, then I could approve the merge I think, as long as you are pretty sure that it behaves as you expect. I'll also run the unit tests manually, to be sure.

[mike1813]

@kenmeacham : thanks for taking a look. Here are some clarifications on the test case.

The version number on the domain model should be OK. The last domain model fix is not yet merged, so I tried to give it the tag 'v6a3-1-2-beta1', but I think I screwed that up and ended up making it 'v6a3-1-2'.

The list of assets from issue #52 is what you should see before the Sensor-stores-[Data:Sensor] link was added. The issue there was that some of the links were not stored properly. So the point at which that should be checked is before you add the asserted link.

Once the asserted link has been added, we should get a total of 11 assets:

• Sensor: the asserted asset
• [World] is the global inferred public space where the Sensor is assumed to be (given that it has no other location
• [Data:Sensor] is the sensed data
• [DataCopy:{Data:Sensor]-Sensor]: is the serialized copy of this data stored on the Sensor device
• [SensorProcess:Sensor] is the onboard process that communicates this data to other processes
• [DataService:Sensor] is a data service added by the USB storage submodel, the sensor being assumed to be a USB device which is now storing a copy of its data
• [DataOutput:[Data:Sensor]-[SensorProcess:Sensor]] represents the data in the workspace of the SensorProcess:Sensor projects that created it. This used to be an OutputPool because it was the only source of this data, but now the data is accessible via the DataService so the creation is represented as a simple DataOutput asset
• [StoredDataPool:[Data:Sensor]-[DataService:Sensor]] represents the data in the workspace of the DataService:Sensor process
• [HostContext:Sensor-[World]] is the context for access rights on Sensor when in [World]
• [ProcessContext:Sensor-[SensorProcess:Sensor]-[World]] is the context for access rights of [SensorProcess:Sensor] on Sensor when in [World]
• [ProcessContext:Sensor-[DataService:Sensor]-[World]] is the context for access rights of [DataService:Sensor] on Sensor when in [World]

The relationships are obviously a little different as well. Before issue #52 was addressed, only outgoing relationships from the Sensor device would have been stored. Now we should get 23 inferred relationship plus the 1 asserted relationship we added.

[kenmeacham]

@kenmeacham : thanks for taking a look. Here are some clarifications on the test case.

The version number on the domain model should be OK. The last domain model fix is not yet merged, so I tried to give it the tag 'v6a3-1-2-beta1', but I think I screwed that up and ended up making it 'v6a3-1-2'.

The list of assets from issue #52 is what you should see before the Sensor-stores-[Data:Sensor] link was added. The issue there was that some of the links were not stored properly. So the point at which that should be checked is before you add the asserted link.

Once the asserted link has been added, we should get a total of 11 assets:

* Sensor: the asserted asset

* [World] is the global inferred public space where the Sensor is assumed to be (given that it has no other location

* [Data:Sensor] is the sensed data

* [DataCopy:{Data:Sensor]-Sensor]: is the serialized copy of this data stored on the Sensor device

* [SensorProcess:Sensor] is the onboard process that communicates this data to other processes

* [DataService:Sensor] is a data service added by the USB storage submodel, the sensor being assumed to be a USB device which is now storing a copy of its data

* [DataOutput:[Data:Sensor]-[SensorProcess:Sensor]] represents the data in the workspace of the SensorProcess:Sensor projects that created it. This used to be an OutputPool because it was the only source of this data, but now the data is accessible via the DataService so the creation is represented as a simple DataOutput asset

* [StoredDataPool:[Data:Sensor]-[DataService:Sensor]] represents the data in the workspace of the DataService:Sensor process

* [HostContext:Sensor-[World]] is the context for access rights on Sensor when in [World]

* [ProcessContext:Sensor-[SensorProcess:Sensor]-[World]] is the context for access rights of [SensorProcess:Sensor] on Sensor when in [World]

* [ProcessContext:Sensor-[DataService:Sensor]-[World]] is the context for access rights of [DataService:Sensor] on Sensor when in [World]

The relationships are obviously a little different as well. Before issue #52 was addressed, only outgoing relationships from the Sensor device would have been stored. Now we should get 23 inferred relationship plus the 1 asserted relationship we added.

Thanks for the clarification. I see the assets that you described, after initial validation, then adding the relation, etc.

What doesn't yet match is the relations. This is what I currently see to/from the Sensor:

[mike1813]

@kenmeacham : there was a slight glitch in my previous comment. The number of assets is indeed 11, but I was using domain-network v6a3-1-1 which gets the inferred relationships slightly wrong. With v6a3-1-2, we should get 27 not 23 inferred relationships.

I have now checked the validated model as downloaded from your test system. You are getting the expected results: 11 assets, 28 relationships, 117 threats (plus 4 modelling error threats), 53 active control types related to the 11 assets, and 45 visible consequences, etc.

[kenmeacham]

@kenmeacham : there was a slight glitch in my previous comment. The number of assets is indeed 11, but I was using domain-network v6a3-1-1 which gets the inferred relationships slightly wrong. With v6a3-1-2, we should get 27 not 23 inferred relationships.

I have now checked the validated model as downloaded from your test system. You are getting the expected results: 11 assets, 28 relationships, 117 threats (plus 4 modelling error threats), 53 active control types related to the 11 assets, and 45 visible consequences, etc.

Great. On that basis it seems that the fix is working, so I'll OK the pull request :)

[kenmeacham]

Looks good to merge, based on the latest tests and validation of results, etc.