Refactoring Software Vulnerability Discovery #139
Comments
|
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. |
…aviour to support threat typo checks.
|
Tested using four test cases:
The first two are taken from the tutorial last updated in 2022, modelling a simple public website that holds profiles of consumers. These were updated to V11 by replacing a deprecated control assertion (ChipAndPinVerifier no longer applies to physical spaces, having been replaced by a distinct ChipAndPinLock control type), and simplified by making all assets singletons. The last two are models used in a recent publication. In all four cases, the outcome of risk calculations is unchanged by switching to the refactored vulnerability discovery threats, other than through the inclusion of the new 'Vulnerability Discovered' behaviour. All other misbehaviour sets have the same likelihoods as before. This confirms that the refactored vulnerability discovery threat paths are working correctly. |
|
The hope was that refactoring in this way would reduce the complexity of the risk treatment plan. It turns out this is the case, as the asset behaviours corresponding to CVSS-aligned TW attributes are no longer subject to threats that have control strategies. However, these behaviours are still included in the risk treatment plan by system modeller v3.6.0-test, so at this point it doesn't lead to a reduction in the size of the risk treatment plan report. For example, in the case of 'Online Store V11s More Security', the first asset class shown in the risk treatment plan is ClientBrowser, which includes the following behaviours when validated using domain model v6a5-1-2:
Once the vulnerability discovery threat path has been refactored in the domain model, this changes to:
Evidently, the report could be made much shorter by filtering out behaviours with threats that have no control strategies. In this particular case, this should also make the system model easier for users to understand, by removing the individual CVSS-aligned behaviours and replacing them with a simpler concept. The domain model updates are now on branch 139. An issue has been created for system modeller, see Spyderisk/system-modeller#182. |
|
Branch 139 has now been merged by pull request #143, so this can now be closed. |
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.
The text was updated successfully, but these errors were encountered: