CSG Classification

[mike1813]

Domain model control strategy and threat classes have two boolean properties which specify whether they are relevant in each type of risk calculation:

• core#isFutureRisk is set to 'false' if the threat/CSG should be ignored in current risk calculations
• core#isCurrentRisk is set to 'false' if the threat/CSG should be ignored in current risk calculations

Any system model threat or CSG then inherits this property, so the risk calculator can determine whether to ignore them. If the relevant property is missing or set to 'true', the risk calculator includes it in the calculation.

In the past, CSGs that should only prevent threats in future risk calculations were encoded in a different way, by using the old and at that time unused property core#mitigates instead of core#blocks to refer to the prevented threat. This was confusing (because the word 'mitigates' implies something else), inflexible (because it only encoded one of the two cases where a CSG may need to be ignored), and incomplete (because it does not allow the CSG to be ignored as a side-effect threat trigger). The system-modeller still supports the old core#mitigates property for backward compatibility, but this also means domain models aren't being updated so it should be removed so everyone starts using the new, improved mechanism. The action on this is:

• Remove support for the deprecated use of the CSG property core#mitigates

Both risk calculations are predictions about the future, but a current risk calculation assumes no change in the system or environment from its current state, while a future risk calculation includes changes in the environment (e.g., discovery of vulnerabilities in software by attackers) and routine management processes to address them (e.g., routine application of software patches). Thus a future risk calculation takes account of the possibility there may be undiscovered vulnerabilities in software that become known to attackers over time, whereas a current risk calculation assumes the initial TW levels for software assets reflect all known vulnerabilities.

The current risk calculation can therefore be used to run 'what if' scenarios in response to changes like the discovery of a vulnerability. One can reduce the relevant TW levels to model the presence of the vulnerability, then run a current risk calculation to find out what it means. Further current risk calculations can then be used to find out if activating additional security measures is advisable.

These additional measures are modelled as control strategies, but not every control strategy can be activated at runtime. Some must be incorporated when the system is implemented, e.g., including authentication measures in software, or locks on entrances to spaces, etc. Some may be used only if the possibility has been anticipated (i.e., they represent activation of some contingency plan), or if some other dependency (not included in the system model) is fulfilled (e.g., a new software patch is available, or the payroll for this month has been completed).

This means we need a separate classification of domain model control strategy classes in current risk calculations. This should really be handled by adding further properties to the domain model classes, but at present it is encoded by a naming convention for their URIs. The classification uses the following categories:

• the CSG can be enabled at runtime, if and only if it represents activation of a contingency plan, and some dependency is satisfied. For a CSG of this type, the URI ends '-Implementation'.
• the CSG can be enabled at runtime, if and only if it represents activation of a contingency plan, with no other dependency. For a CSG of this type, the URI ends '-Implementation-Runtime'.
• the CSG can be enabled at runtime, and doesn't need to be a pre-planned contingency measure. For a CSG of this type, the URI ends '-Runtime' (without the '-Implementation' string).
• the CSG cannot be enabled at runtime. A CSG of this type has a URI that does not include the strings '-Implementation' or '-Runtime'.

For the first two cases, the CSG represents activation of a pre-planned contingency measure. The contingency plan is also represented as a CSG, whose domain model parent class URI is the same as that of the activation CSG, but without the '-Implementation' or '-Runtime' strings included. The contingency plan CSG will normally be a future risk CSG, ignored in a current risk calculation, but which must have been enabled (indicating that staff are trained to carry it out, and the system configured to allow this) before the activation CSG can be used.

This kludge should now be replaced. The actions are:

• New properties should be added to handle the classification, with any appropriate extensions or generalisations.
• New properties and if necessary validation functionality should be added to support the association between a future risk contingency plan CSG and its run-time activation CSG, with any appropriate extensions (e.g., beyoned a 1-to-1 association).

Anyone implementing a runtime CSG recommendation algorithm should be aware of this classification. If possible, they should embed the string manipulation needed to determine the current risk CSG category and (if relevant) the corresponding contingency plan CSG URI in a set of methods so these can be updated if/when the above naming conventions are replaced by core model properties.

[mike1813]

@panositi, @scp93ch : this is the issue I agreed to raise after speaking to Panos. It is based on a discussion in an IT Innovation GitLab issue from a year or so ago, but here I documented separately the classification of CSGs, and the means current used to encode this. Next action is for @panositi to amend his code under development so it uses the classification and encapsulates the encoding so that can be upgraded easily in future.

[scp93ch]

Thanks for documenting this. I think the content should go in the wiki (https://wiki.spyderisk.org/) as there's no task to do that would close the issue.

[mike1813]

I think the content should go in the wiki (https://wiki.spyderisk.org/) as there's no task to do that would close the issue.

I added three tasks, which I forgot to do when I first created the issue. Also changed the issue title since this is not about using naming conventions - it is about removing the need for them.

[mike1813]

@panositi, @scp93ch: further discussion between @mike1813 and @panositi led to a further refinement. This will require another update of the issue description and tasks (action @mike1813).

Relatively recent changes to CSG URIs mean that system model CSGs now depend on their control sets and no longer only on the threat they address. This change was needed because the same CSG often addresses multiple threats, but was being represented as multiple CSGs. This led to a very large number of CSGs, inflating the size of the system models too much.

The problem that creates is that the kludge using a naming convention in the domain model URI no longer works. The contingency plan class (in the domain model) can be found by string substitution, but not the contingency plan (in the system model).

The correct solution is to:

• include the control sets from the contingency plan as mandatory controls in each control strategy representing contingency plan implementation
• make run-time malleability a property of control sets (CS).

We can then eliminate the naming convention kludge using '-Implementation' and/or '-Runtime' in the URI of a CSG to indicate that it can be enabled at run-time. Instead, a CSG can be enabled at runtime if all mandatory CS that are not already enabled are run-time malleable. Similarly, a CSG could be deactivated if any mandatory CS is run-time malleable.

If a CSG represents activation of a contingency plan, then any mandatory contingency plan CSG control sets should be mandatory in the contingency plan activation CSG. These should not be run-time malleable (since they represent preparatory action that can't be done only when needed). The remaining mandatory CS in the contingency plan activation CSG should be run-time malleable, so it is possible to enable the activation CSG if and only if the non-malleable contingency plan controls are already enabled.