This issue stems from the same underlying problem as issue #280.
The problem affects Control default settings (table CASettings.csv), Misbehaviour default settings (MADefaultSettings.csv) and Trustworthiness Attribute default settings (TWAADefaultSettings). Controls, Misbehaviours and TWA all have associated user inputs:
- Misbehaviours: need an impact level at each system asset where the Misbehaviour could occur.
- TWA: need an assumed trustworthiness level at each system asset where the associated Misbehaviour could occur.
- Controls: need a coverage level at each system asset where the Control could be enabled.
The last two are needed because Controls and TWA are exogenous variables whose likelihoods (expressed in both cases as trustworthiness levels) are inputs to the likelihood calculation phase. The impact level for each Misbehaviour is needed after that, when computing risk levels from likelihoods.
In principle, the system modeller user should set these parameters on every Misbehaviour, TWA and Control at every asset in their system model. In practice, there are too many to set manually, so defaults must be used. In most cases, the input value should be set at the minimum risk level, but in some cases this makes no sense, e.g., the default trustworthiness level for users of the Internet should be lower than for other networks, the impact level for loss of confidentiality at sensitive data should be higher than for other data, etc.
Each default setting therefore applies to a specific Asset class, and provides default inputs for a given Misbehaviour, TWA or Control type at assets of that class. Inheritance is used within the Asset class hierarchy. If you need a default setting for (say) a control of type C at an asset in class B which is a subclass of A, you look for a default setting for control type C at asset class B, and if you can't find one you then try the one for control type C at asset class A, etc.
As noted in #280, the package dependency between a control type and an asset class is weak, because either could have been defined in a lower level package, then the other added in a higher level package. The situation is worse than that, because the control location may refer only to asset class A. If A is in package P1, B is in package P2 and C is in package P3, we can get the following situation:
- A was defined first in package P1
- C was added in package P3, with a control location referring to A, which means P3 depends on P1
- the default setting D(C, A) is needed for controls of type C at assets in class A.
D(C, A) is a CASetting, which is needed if and only if both C and A are in play, i.e., if both packages P1 and P3 are enabled. This means D(C, A) should be in the dependent package (P3), because it cannot be enabled without the supporting package, so we know that D(C, A) will be needed if and only if P3 is enabled. The CASetting.csv entry refers to package P3, so it is filtered out if P3 is not enabled.
To facilitate this, the Domain Model Editor DB application includes an automatic package assignment feature that determines the correct package for 'derived' entities like default settings.
The problem arises when we develop some new ideas in the course of which
- asset class B was added in package P2, being a subclass of A, which means P2 also depends on P1
- the default setting D(C, B) is needed since controls of type C may be present at assets in class A of which class B is a subset
D(C, B) is needed if both C and B are in play, i.e., both P3 and P2 are enabled. The CASetting should refer to whichever package depends on the other. However, while P3 and P2 both depend on P1, there is no reason why one should depend on the other. In that situation, the automatic default setting package assignment algorithm assigns the CASetting to the package containing the control.
It doesn't really matter whether D(C, B) is assigned to P2 or P3. D(C, B) will not be needed if either is disabled, so it will never be missing when it is needed. However, it may be present when one of the entities referenced is not, so code that processes such a default setting may end up trying to follow an orphaned reference.
There are three possible solutions for this problem:
- in tables like CASetting.csv, both package references should be included, and used for filtering purposes
- one of the packages must be made to depend on the other, allowing the default setting to be assigned to the dependent package, or
- such a default setting should not be allowed, forcing default values to be found by using the asset inheritance hierarchy, so in this example, D(C, B) would not exist and D(C, A) would be used instead.
Changing the format of CASettings.csv and similar tables would not be ideal because other tools may need to be changed, and every row of CASettings.csv would be seen to have changed by Git. That would make it difficult to merge changes using Git from a branch where CASettings.csv has two package fields to a branch where it has only one, or vice versa.
The best solution seems to be to ban default settings that cannot be assigned to one package, which is similar to the rule used to resolve a similar problem with Control, Misbehaviour and TWA Locations.
This issue stems from the same underlying problem as issue #280.
The problem affects Control default settings (table CASettings.csv), Misbehaviour default settings (MADefaultSettings.csv) and Trustworthiness Attribute default settings (TWAADefaultSettings). Controls, Misbehaviours and TWA all have associated user inputs:
The last two are needed because Controls and TWA are exogenous variables whose likelihoods (expressed in both cases as trustworthiness levels) are inputs to the likelihood calculation phase. The impact level for each Misbehaviour is needed after that, when computing risk levels from likelihoods.
In principle, the system modeller user should set these parameters on every Misbehaviour, TWA and Control at every asset in their system model. In practice, there are too many to set manually, so defaults must be used. In most cases, the input value should be set at the minimum risk level, but in some cases this makes no sense, e.g., the default trustworthiness level for users of the Internet should be lower than for other networks, the impact level for loss of confidentiality at sensitive data should be higher than for other data, etc.
Each default setting therefore applies to a specific Asset class, and provides default inputs for a given Misbehaviour, TWA or Control type at assets of that class. Inheritance is used within the Asset class hierarchy. If you need a default setting for (say) a control of type C at an asset in class B which is a subclass of A, you look for a default setting for control type C at asset class B, and if you can't find one you then try the one for control type C at asset class A, etc.
As noted in #280, the package dependency between a control type and an asset class is weak, because either could have been defined in a lower level package, then the other added in a higher level package. The situation is worse than that, because the control location may refer only to asset class A. If A is in package P1, B is in package P2 and C is in package P3, we can get the following situation:
D(C, A) is a CASetting, which is needed if and only if both C and A are in play, i.e., if both packages P1 and P3 are enabled. This means D(C, A) should be in the dependent package (P3), because it cannot be enabled without the supporting package, so we know that D(C, A) will be needed if and only if P3 is enabled. The CASetting.csv entry refers to package P3, so it is filtered out if P3 is not enabled.
To facilitate this, the Domain Model Editor DB application includes an automatic package assignment feature that determines the correct package for 'derived' entities like default settings.
The problem arises when we develop some new ideas in the course of which
D(C, B) is needed if both C and B are in play, i.e., both P3 and P2 are enabled. The CASetting should refer to whichever package depends on the other. However, while P3 and P2 both depend on P1, there is no reason why one should depend on the other. In that situation, the automatic default setting package assignment algorithm assigns the CASetting to the package containing the control.
It doesn't really matter whether D(C, B) is assigned to P2 or P3. D(C, B) will not be needed if either is disabled, so it will never be missing when it is needed. However, it may be present when one of the entities referenced is not, so code that processes such a default setting may end up trying to follow an orphaned reference.
There are three possible solutions for this problem:
Changing the format of CASettings.csv and similar tables would not be ideal because other tools may need to be changed, and every row of CASettings.csv would be seen to have changed by Git. That would make it difficult to merge changes using Git from a branch where CASettings.csv has two package fields to a branch where it has only one, or vice versa.
The best solution seems to be to ban default settings that cannot be assigned to one package, which is similar to the rule used to resolve a similar problem with Control, Misbehaviour and TWA Locations.