Discussion: CSG Recommender and Side Effects

[mike1813]

At present, the CSG recommender algorithm calculates the risk level in a 'baseline' system model, finds threat paths, and uses those to find control strategies that can interdict threat paths to reduce the likelihood of a target effect (or several target effects). It then performs further risk calculations to test the efficacy of enabling different combinations of control strategies to find recommendations on controls to enable at specific assets (i.e. which control sets) in order to reduce the level of risk.

It is possible that a CSG once enabled may produce side effects, which are modelled as further threats. Their effect is included in the risk calculations, so the CSG recommender algorithm correctly recommends that controls are enabled only if any side effects caused have low impact levels and hence produce low risk levels (lower than the risk level prevented by enabling the controls).

However, the CSG recommender algorithm does not consider disabling controls as a way to reduce risk levels arising from side effects. In many scenarios this should be considered. For example, we will often face the following sequence:

1. A system starts with controls in place to prevent threats, leading to a low residual risk level.
2. A runtime system scan detects the presence of a software vulnerability in a service.
3. The CSG recommender reduces TW attributes of this service to model the vulnerability, and calculates the risk, finding it to be high because exploitation of the vulnerability leads to high impact effects on (say) stored data.
4. The CSG recommender finds two options to reduce the risk level
   • perform an emergency software update, applying a software patch to remove the vulnerability, or
   • disable the vulnerable service, which leads to loss of availability for some system functions, which has lower impact than the effects of attacks that exploit the vulnerability
5. The user establishes that there is as yet no software patch available, so they implement the second recommendation, disable the service and associated system functions, leading to an intermediate but temporarily acceptable risk level
6. The software vendor publishes a patch for the vulnerability, which is applied in a routine software update.
7. The next system scan reveals that no vulnerability is present in the previously affected service.
8. The CSG recommender increases TW attributes of this service, and calculates the risk. This is still at an intermediate level, because the service is still at this point disabled, and the side effects of this are still having an impact.
9. The CSG recommender considers enabling more controls, but finds none that reduce the likelihood of the side effect.

What should happen is that since the highest risk levels come from CSG side effects, the CSG recommender should consider disabling the CSG causing the side effects. If the vulnerability has been fixed, disabling this CSG should reduce risk levels back to the original level.

Making this work would require changes to the way the CSG recommender searches the space of possible changes to the enabled CSGs and controls, allowing for the possibility that they should be disabled as well as enabled.

A reasonable first step would be to try switching off controls that create side effects, before trying other options involving enablement of controls. This should be sufficient for the above scenario, allowing the algorithm CSG to propose disabling controls it previously enabled, once they are no longer needed. It would not cover all scenarios in which risk levels arise from a combination of direct threat effects and control side effects, but it would be a lot better than nothing.

@scp93ch and @panositi should decide if/when to address this issue, and whether to address it in full (allowing the algorithm to explore arbitrary control changes) or just checking whether previously enabled controls are still needed if risk levels come only from side effects.

[mike1813]

At present, we have two options for 'enabling' a control - we can assert that the control is 'enabled', or that it is 'to be enabled'. In the latter case, an extra 'work in progress' property is added to the control set.

I guess if your highest-level risks are caused by side effects, and a recommendation says you should disable some controls, we may need a 'to be disabled' option as well. I suggest this could be handled by removing the 'isProposed' property but adding the 'work in progress' property to the control set.

[scp93ch]

At present, we have two options for 'enabling' a control - we can assert that the control is 'enabled', or that it is 'to be enabled'. In the latter case, an extra 'work in progress' property is added to the control set.

I guess if your highest-level risks are caused by side effects, and a recommendation says you should disable some controls, we may need a 'to be disabled' option as well. I suggest this could be handled by removing the 'isProposed' property but adding the 'work in progress' property to the control set.

Yes, I've been thinking about this. There are four states we'd want to track:

1. disabled (red traffic light) (false, or false assumed because no triples)
2. enabled (green light) (isProposed = true)
3. disabled, but to be enabled (amber light) (isProposed = true, isWorkInProgress = true)
4. enabled, but to be disabled

You're suggesting that for option 4 which is currently not considered, we could store the state using the remaining unused combination of the two predicates: just isWorkInProgress = true. That would work, but we'd also have to find a way to represent that in the UI.

We might have a little arrow on one side or the other of the amber light, pointing to whether the intention was to move towards red or towards green. Or we show two lights at once: always one of red or green, but with an optional amber.

[scp93ch]

| the CSG recommender algorithm correctly recommends that controls are enabled only if any side effects caused have low impact levels

Just a note that this behaviour was not the case at the time of writing and is being considered in #67.

[mike1813]

We might have a little arrow on one side or the other of the amber light, pointing to whether the intention was to move towards red or towards green. Or we show two lights at once: always one of red or green, but with an optional amber.

Or we could have red and amber meaning 'next state is green', i.e., isProposed = true, workInProgress = true (should be proposed but not yet implemented), while amber only could mean 'next state is red', i.e., isProposed = false, workInProgress = true (shouldn't be implemented but currently it is). But that might be a bit UK traffic light centric.