mike1813
commented
3 months ago Changes as described have been made on branch 139, but some work is needed to produce an adequate test case.
@kenmeacham, @scp93ch or @samuelsenior may wish to merge changes from this branch into their current working branches to see if (a) these changes affect the risk levels (they should not), or (b) these changes simplify system modeller output (root causes or risk reports or residual risk analysis outputs).
I can't do any more today. May get some time to run up a test case over the weekend.
Threats involving exploitation of software vulnerabilities in Host or Process assets are modelled as threat paths composed of simpler steps:
For current risk calculations, the discovery threats are skipped. Instead, known (detected) vulnerabilities are modelled by reducing the CVSS-aligned TW attributes appropriately for the affected vulnerabilities.
In future risk calculations, vulnerability discovery is treated as a normal operation process, whose effects can be reduced by operational management policies such as regular, systematic application of software patches. However, this leads to two problems.
Firstly, each of the vulnerability discovery threats is specific to a CVSS metric value or combination of metric values, so discovery of a real vulnerability corresponds to a combination of those threats. When looking for root causes of a downstream effect, one finds multiple root causes, which may confuse system modeller users.
Secondly, software patching (as a normal operational policy) suppresses all vulnerability discover threats. When a risk treatment plan is extracted, the effect of software patching is represented by multiple entries, one for each CVSS-mapped TW attribute. This may also be confusing, but at minimum it means the risk treatment plan is highly repetitive. Moreover, if one then analyses the effect of a software patching policy, one finds it reduces the likelihood of multiple threats, each of which may be an upstream cause of multiple downstream effects. The calculation of residual risk levels is thus rendered a lot more complex.
Software patching reduces the likelihood of vulnerability discovery threats because it reduces the time for which the vulnerability is both known to the attacker and present in the software. Other control strategies seek to reduce the likelihood that vulnerabilities are present to be discovered, e.g., penetration testing, software certification and formal verification. Although these represent different mechanisms, they also give rise to the same problems for residual risk analysis.
To solve these problems, it is proposed that we make two changes:
The effect of these changes is to move the control mechanism upstream of the bifurcation of threat paths to cover multiple CVSS-aligned TW attributes. The goal is to reduce the size of risk treatment plans and hopefully also reduce the complexity of residual risk calculations - although to what extent can only be determined by running tests.