Matching Asserted or Constructed Assets

[mike1813]

At present, system modeller creates inferred assets, relationships or threats wherever the system model contains related assets that match a pattern (the 'matching pattern' associated with the asset/relationship construction pattern or threat).

The matching pattern is specified as a set of nodes, each corresponding to a role in the pattern, and specifying the class of asset that can fulfil that role (i.e., match that node). The pattern also has a set of links between roles, indicating that assets matching those roles should have the corresponding relationships.

Sometimes, it would be helpful if one could specify that a node should only be matched by an asset that is inferred or asserted.

For example, in some situations there is a construction pattern that adds an inferred asset, but only where the user hasn't specified an asserted asset. Some cases of this arise in the IoT model, where users can define an IoT device and a Data asset with a relationship to indicate that the Data is control input and/or sensor output for the device. Users can thereby use a Data subclass indicating the type of data, e.g., if it is health data. Since every IoT device has control input and/or sensor output, if the user does not include the related Data asset, one is added by a construction pattern, assigning it to a generic Data subclass.

In that situation, if the data is sensitive (e.g., health data), and the user forgets to include the Data explicitly in their system model, then the constructed data will be of the wrong type. For this reason, it is helpful to use a modelling error threat that detects where the data is an inferred asset, and flags this possibility to the user. Such a modelling error already exists in the latest domain model (v6a5-1-1).

However, the matching pattern cannot tell if an asset is asserted or inferred. To make the modelling error work, the domain modeller must assign a distinct Data subclass for inferred control inputs or sensor output data, and refer to this subclass in the modelling error threat.

Distinct Data subclasses may be needed for inferred assets anyway, in order to disambiguate such assets (see Issue #158). However, this type of workaround is undesirable because it forces domain models to include extra asset subclasses that have no real significance other than to allow distinction or disambiguation of cases.

Inferred assets in the system model already have a property that refers to the construction pattern that created them, so there shouldn't be a problem deciding whether an asset is asserted or inferred. All that is needed is an extra property on domain model Nodes to indicate if the match should be restricted to inferred (or asserted) assets, which the system modeller should use when looking for matching assets.