mike1813
commented
1 year ago It may also make sense to label certain asset types as 'view enumerators', so each system model asset of that type has a related view, which contains itself and all other assets related to it.
For this to work, the specification of views would need to be included in the system model. In that case:
- the domain model would specify the rules for generating views, e.g., static views with associated asset types (as suggested above), or dynamic views based on assets of a given type (as suggested here)
- the validator would generate the views and add links from views to assets in the UI graph
- the system modeller user interface could then populate the view selector and apply filters based on their links to system model asset when a view is selected.
For example, one might specify in the domain model that 'Stakeholder' assets have their own view. Other asset types could then be included in the same view if they are related to this stakeholder. In the canvas, the dropdown to select views would include names of Stakeholder assets (including subclasses like Human and Organization). Selecting one of these would show everything operated by that stakeholder, including assets for which the relationship to the stakeholder was inferred.
The pros of using this approach (defining view generation rules rather than views in the domain model) is obviously more flexible and allows views to be based on features of a system model rather than just on the domain model classification of system assets. The only cons are that the views would not be available until the system model is validated, and changes that alter the views will not be visible until the next revalidation.
Something else to think about.
Back when some of us at the University of Southampton started working on semantic modelling applied to cyber security, what we now call 'Spyderisk' was just a knowledge base written in OWL and SWRL, and a stand-alone Java program used to display system models for demo purposes (mostly in review meetings with our funding bodies).
That old program (now lost in the mists of time) was designed to be used with that one specific knowledge base. That's a huge limitation which held back development of the knowledge base, so we replaced it with system-modeller which only depends on an upper ontology. That unlocked the door to enrichment and refinement of the knowledge base, but we did lose something - the ability to show simplified views of the system model.
Note that a 'view' is here assumed to be a presentation of the whole system model, but showing only some aspects. What is shown and how it is displayed may depend on aspects of the model that are not displayed. This is distinct from a 'report', which is a presentation of information extracted from the model for some purpose, the display being based only on what has been extracted.
The current domain-network knowledge base supports modelling of socio-cyber-physical systems (stakeholders, technology components and their physical environment). When we teach people how to create system models using this knowledge base, we usually explain that the system models can be divided into three layers:
In that old Java program, the display showed only one of these layers at a time. This provided views of the system model with far fewer assets and relationships, which were (for the most part) far easier to understand. Relationships between assets in the same layer could be added using point-and-click, as we currently do in system-modeller. Relationships between assets in different layers had to be added by selecting the visible asset, and editing a list of 'cross-layer' links. They only define physical spaces where hosts are located or networks are accessible, which hosts are running each process, and which hosts store copies of which data.
Of course, this was only possible because the old Java program code 'knew' what knowledge base would be used, and which of its asset types belonged in each layer.
We could nevertheless consider reviving this idea, by adding support for 'views'. To do this, we would need to:
The last of these is in principle already supported through the mechanism for adding relationships to an asset via its properties panel, although at present there are some problems with that (issue #44 and #45).
With this approach, system-modeller would not become locked to one specific knowledge base (or vice versa). The information on what views should exist and what is visible in each view would be inside the knowledge base. The system-modeller would only need to follow the instructions in the knowledge base used by each system model.
If we want to give this a try, the first step would be to add the concept of views to the core model (which is part of system-modeller). Then we add views to a knowledge base like domain-network. At that stage, system-modeller would just ignore all references to views, so using the domain model with an old system-modeller instance shouldn't cause a problem.
Once the necessary definitions are included in a suitable knowledge base, it would be possible to start modifying the system-modeller code, adding support for view selection and view-specific filtering, using the knowledge base definitions.
Nowadays, we have some asset types in domain-network that could be in more than one view. Whether they are displayed may depend on whether they are related to other assets in the same view. For example, if we define views correponding to the old application, network and physical layers, then humans can be in all three layers. But that doesn't mean we want all Human assets displayed all the time - it would only make sense to include them if they are related to the other elements of that view. This means Human membership of each view would be 'optional' and decided by their relationships.
Obviously, by defining views and their associated asset types in the domain model means they don't have to be based on the old concept of 'layers'. It may make sense to partition the assets in different ways, or add further views that show different subsets.