Open ahouseholder opened 11 months ago
I get this intuition. However, there is a tension I have. Security flaws are not exploited stochastically, as safety issues are modeled in IEC 61508. Intelligence analysis handles this by capability / access / intent per actor group determine whether an impact is realized, not stochastics. So this is absolutely what we are modeling. However, we have substituted out the likelihood aspect with CAI. Automatable reflects capability and access, value density reflects intent, State of exploitation reflects capability and intent, system exposure reflects access, etc.
So I don't love bringing likelihood in (which is a familiar and intuitive concept) and then ripping it back out. That may cause more confusion than benefit. But also, I do agree that the IEC table could be represented as a decision tree and we could leverage that similarity. I just want to be careful we don't bring in more harmful baggage with the metaphor than positive connection. https://discovery.ucl.ac.uk/id/eprint/10046820/1/Demjaha-2018-metaphors-considered-harmful.pdf
This is an extension to #311
While perusing the IEC 61508 wikipedia page, I noticed its hazard and risk analysis section has a very similar structure to the decision models we can create with SSVC.
Specifically, it defines two input sets (call them decision points), one outcome set (a risk class), and a policy that maps the input to the output.
Inputs
Categories of likelihood of occurrence
Consequence categories
Outcome set
Policy
This seems like it would be a good example walk-through of how one could create a custom decision function to model this mapping. It might help folks who are more accustomed to safety analysis to start reasoning about how SSVC might fit into their vulnerability response process.