USB Device Storage Modelling Issue

[mike1813]

If a USB Device is used to store data, there is a construction pattern that adds a data service hosted on the device. This process mediates access to the data from processes running on other devices including a paired USB Host. Subsequent patterns add the relationships between those remote processes and the mediating data service.

This pattern applies to any USB Device (one designed to plug into a USB Host), including IoT Things, Thumb Drives, Smartphones, etc. It comes after the IoT inference sequence, by which an IoT Sensor acquires an inferred Data asset and an onboard Process to send this data to recipients either proactively on on request (depending on the recipient's relationship to the Sensor).

The problem is that if the Data is created by a process on the USB Device then that process must be related to the inferred data service if it is to mediate access to the stored copy, even on its own host. If no such relationship exists, we get a modelling error of type P.E.PDO+DS-S.9.

With an IoT Sensor, the inferred structure is exactly that, except the Data is not assumed to be stored on the Sensor (since that need not be the case). Users should be able to add a Sensor-stores-Data relationship, which will be possible once we address either issue #21 (so an asserted Data asset can be used), or issue Spyderisk/system-modeller#44 (so an asserted relationship to the inferred Data asset can added). We will then have a conflict whereby the construction sequences for USB storage and IoT data generation use different assumptions and clash with modelling error P.E.PDO+DS-S.9.

This conflict must be resolved, which may or may not involve changes in the underlying assumptions for USB storage in general.

[mike1813]

This is quite urgent, because we're already working on issues #21 and Spyderisk/system-modeller#44. With the current knowledge base there is no way to make up a simple test case...

[mike1813]

It turned out that the problem is in the data lifecycle inference sequence. The patterns start from DataAccess assets which are created for every Process-handles-Data relationship. The DataAccess asset can be thought of as the volatile copy of the Data in the workspace of the Process. It is involved in threats to the Data via the Process, or to the processing of the Data by the Process, and can have controls representing the use of cryptographic keys or secure computation methods.

The DataAccess asset also fulfils a second purpose, by encoding the involvement of the Process in the lifecycle of the Data. This is encoded in the DataAccess subclass used when each DataAccess asset is created. Multiple inheritance is used so the DataAccess assets are created as a member of one or more of the following classes:

• DataInput: the process consumes the data as input, or displays it to an interactive user
• DataOutput: the process creates the data as output
• DataPool: the process controls access to the data, either a stored copy or output that is nowhere stored
• RemoteUserAccess: the process is a remote access client allowing a user to interact with data via a remote process

The data lifecycle inference then deduces the possible DataPaths (chains of communicating processes) leading to DataPool processes, and works out which of these carry flows of data such that output from each producer process can reach every consumer, and every consumer can get data from a producer or a data store.

Unfortunately there is a corner case that is not handled properly, in which a Process creates Data that is stored locally and also served by another Process on the same Host, but there is no DataPath linking the two Processes. This fails because the inference rules are based on an assumption that if a stored copy of Data is served by one Process, other Processes access that copy via the serving Process. This need not be true for Processes running on the same Host where the copy is stored.

The problem was hard to diagnose, but the fix is fairly simple: allow DataPaths to start from any DataOuput process, even if the data is served by another Process, and add a rule to detect whether the DataOutput process writes new data via the serving Process and if not, add links representing direct access to the stored copy via its Host.

This fix has now been added to branch 6a.