Asset hierarchy rationalisation

[mike1813]

Until recently, the top level subclasses of core#Asset were used by system modeller as categories into which assertible assets should be grouped in the palette displayed in the system modeller U/I. This imposed restrictions on the asset classification hierarchy, as those top-level subclasses had to provide a sensible set of categories to users.

Issue Spyderisk/system-modeller#101 described this issue and called for a change in system modeller so that the categories used to classify assets in the asset palette would be controlled by subclasses of an overlay parent class core#PaletteType. This allows the domain model to control how assets are grouped in the U/I independently of their classification in terms of properties and relationships.

It is therefore now possible to introduce asset classes at a high level to describe aspects like the domain and range of asset relationships, or the assets having specific misbehaviour, control or TWA properties. This can be used to improve modularity between domain submodel packages, and reduce the conflicts with RDF operational semantics where a relationship domain or range is specified as a list of disjoint asset subclasses.

For example, at present in package#Users we have asset classes representing stakeholders including Organisations and Humans (strictly, the system model assets represent fulfilment of system roles by these entities). Humans acting in specific system roles are capable of entering spaces, and able to interact with devices in those spaces, and with data via software processes running on those devices. There are also situations whereby a Human in a system role may make mistakes and interact incorrectly with software, or be unable to access devices and processes.

In an ideal world, package#Users would include the relationships, asset properties and threats needed to describe these Human capabilities and ways in which they may go wrong. The current domain model does include these elements, e.g.

• relationship canAccess between a Human (user role) and a Space signifies that a Human can enter the Space to fulfil that role
• relationship interactsWith between a Human and a Host or software Process signifies that the Human
• misbehaviour LossOfAvailability represents the inability of a Human to carry out their role, caused by threats such as being inadvertently locked out of a space
• misbehaviour LossOfReliability represents errors in their interaction with software processes, caused by threats such as a lack of training

However, the relationships cannot be in package#Users because their ranges are specified using asset types from other packages (package#Physical and package#Network, respectively). This in turn means threats causing the two misbehaviours cannot be included in package#Users.

A simple solution could be to introduce abstract (non-assertible) base classes in package'Users:

• an asset class called something like domain#Enterable representing anything that can be physically entered by a Human
• an asset class called something like domain#Usable representing anything that a Human can interact with in order to use

This could not be done, because these high-level classes would have been direct subclasses of core#Asset, and would have become palette categories. In the case of the prospective domain#Enterable class this may have been OK, although it should arguably include Jurisdictions as well as Spaces which may have caused some confusion (since Jurisdictions represent legal systems, not the regions in which they apply). However, domain#Usable would be a huge palette category containing every type of Host and Process and other assets classes.

Now that issue Spyderisk/system-modeller#101 has been addressed in system modeller, we can introduce these higher level classifiers into the asset class hierarchy.

[mike1813]

A short term solution is to alter the current package hierarchy to address the most glaring anomalies.

At present (in v6a7) the bottom of the package dependency tree is package#Core <- package#Users <- package#Physical <- package#Network, where each depends on its predecessor. This is why relationships like canAccess and interactsWith are not in package#Users.

A better option might be to change the hierarchy to package#Core <- package#Physical <- package#Network<- package#Users. This would mean those relationships could be part of package#Users. It would mean other relationships pertaining to user interactivity will also move to package#Users, leading to further changes in the package assignment of some construction patterns and threats.

Nothing should be done about this issue until these alternatives can be analysed.