Consider a "Time Since Adversarial Activity" decision point

[ahouseholder]

Is your feature request related to a problem? Please describe.

The Exploitation decision point covers three observable states: None, Public PoC, and Active.

However, we have received feedback that time may be a desirable factor in Active. For example, "Active within the past 30 days" is a higher priority than "Active 6-12 months ago" which is a higher priority than "Active 5 years ago". This comes into play in environments where there can be a high degree of lag in the patching process.

Describe the solution you'd like

We should consider whether to add a "time since activity" decision point (that's a placeholder name) that expresses a chunky, exponential bucket sort of time scale to express recency of adversarial activity surrounding a vulnerability.

Additional context

We don't really have a mechanism for directly addressing what I would characterize as "conditional decision points", or decision points that can only be "activated" by some specific state of another decision point. We do have the notion of compound decision points that allow things to be combined into a secondary table, but it's not clear that this is the best way to address this sort of thing. In this case, it might be something like "Activity Recency" (another placeholder name for the same concept as above) can only be evaluated when Exploitation=Active. We can say that in words but it'd be nice to be able to express it in rules.

It may also be worth considering whether there could/should be a similar "age metric" for Exploitation=Public PoC. Or even for the vulnerability information itself: if you haven't patched a 10 year old vul yet, do you need to get right on that, or is the fact that it's survived without you needing to take action evidence that deferring was, and remains, the correct choice?

[j---]

I think I need a better statement of the value this would bring to the folks who have provided this feedback.
Is the implication that folks with long lag time in their patching environment want to ignore patches that were exploited 12 months ago because by the time they get to patching after 12 months they think it's not relevant any longer?

[ahouseholder]

The concept they were expressing was basically this: Given the choice between deploying fixes for two vuls without fixes already deployed, the one with more recent observed adversary activity has higher priority.

Let X be the "old" vul and Y be the "new" one. The underlying presumption is that "if we survived this long without patching X, then that is useful information about the actual threat posed by X remaining unpatched, and therefore Y should be given higher priority because it has more recently observed activity." Perhaps it's evidence that other controls aside from patching are sufficient to mitigate the risk posed by X. Some might see this as pragmatism in the face of "too many high priorities, and not enough resources to address them all".

An opportunity for perverse incentive exists in that a "slow, but lucky" organization might adopt a "wait and see" attitude toward patching. It also seems to reflect an over-reliance the idea that history is an accurate predictor of the future. And it discounts the idea that an adversary's collection of options includes all unpatched vuls present, selected based on the adversary's utility rather than on any time since last use metric.

I'm not claiming I agree with the argument in favor of this being a decision point, I'm just trying to represent the position that led to the suggestion.

However, when we encounter a group considering SSVC adoption, and their status quo is that they perceive time since last use as a relevant factor to their existing prioritization scheme, would it be preferable to argue them out of that first (and risk they walk away from SSVC and keep doing what they were already doing), or that SSVC provide them a way to model their decision in a way that is recognizable, with the potential to argue for simplification once they're using it? I don't know whether there is one right answer to that, but I could see where it could be useful have some "less preferred" decision points so we can get folks onboard then drive them toward other ones.

[j---]

My suggestion is that SSVC should remain based on evidence-based risk management.
My preference in this case is to argue that this "time since last observed exploit" is based on un-detectable evidence. If someone has exploited the vul and the org isn't instrumented to detect it, then they will go on being vulnerable to a known-exploited vul because of the fact they can't detect it. That is a potential for a negative feedback loop that I suggest we avoid making possible.
If the fact it hasn't been exploited is in fact based on some controls in place that are mitigating exploitation, etc., then the decision should just model that.
If the risk of exploitation is outweighed by other asset management risks, we already talked about that and should work on expanding this page https://certcc.github.io/SSVC/topics/asset_management/
Alternatively, is there an update to https://vuls.cert.org/SSVC/howto/bootstrap/use/#information-changes-over-time that we could use to express this practice?

I think we can find a middle ground where people can model their existing practice without making it too easy to drop in a decision point that can lead to degenerate outcomes.