Recursive decisions

[laurie-tyz]

Describe how SSVC decisions can be used recursively as the situation changes. Changes outside the control of the stakeholder are included in #29. So this issue is to discuss changes to the situation based on actions by the stakeholder. There are situations where, for example, you apply new firewall rules and that will change Exposure. Such a mitigation may not be a complete fix, but if it changes the priority with which you need to act from out-of-cycle to defer, then it was still in some sense an end to the current need to attend to the vul.

Describe difference between 'fix" (remediate) and "mitigate" actions related to recursing decisions.

(formerly part of action #46 )

[ahouseholder]

Not sure if this is the best place to note it, but "fix" actions should include "decommission the vulnerable instance" in addition to "apply a patch". The rationale being that a "fix" action reduces the number of deployed vulnerable instances, whereas a mitigation action reduces the risk (i.e., via either reducing probability of exploitation or reducing impact if exploited) of deployed vulnerable instances.

[j---]

Not sure if this is the best place to note it, but "fix" actions should include "decommission the vulnerable instance" in addition to "apply a patch". The rationale being that a "fix" action reduces the number of deployed vulnerable instances, whereas a mitigation action reduces the risk (i.e., via either reducing probability of exploitation or reducing impact if exploited) of deployed vulnerable instances.

This comment is also relevant to #76

[laurie-tyz]

02:17 PM

So 74 before 79 - check

74 has 2 parts.
1: fix vs mitigate as related to recursing decisions.
2: describe how ssvc decisions can be revisited as the situation changes.

[j---]

2: describe how ssvc decisions can be revisited as the situation changes.

This part may be partly covered by #29 and what we've added to address it in #96. That's in ## Guidance on Communicating Results. That section may need to be broken up into subsections to fit some more about changing ssvc decisions for this issue, but that is OK.

[laurie-tyz]

040_stakeholders-scope.md
To further clarify terms, "Remediation occurs when the vulnerability is eliminated or removed. Mitigation occurs when the impact of the vulnerability is decreased without reducing or eliminating the vulnerability." [@dodi_8531_2020, section 3.5] Examples of remediation include: applying patches, fixes and upgrades; or removing the vulnerable software or system from operation. Mitigating actions may include software configuration changes, adding firewall ACLs, or otherwise limiting the system's exposure to reduce the risk of the impact of the vulnerability; or accepting the risk.

the End of Life/decommissioning the system is covered...

[laurie-tyz]

Emphasize "mitigations" may be temporary. (By definition, mitigations are temporary, however the remediation may never be created by the supplier.) The software may be at (or past) normal "End of Life" and the supplier refuses to issue a remediation. Additional work may be necessary by the supplier to create a fix which will eliminate or remove the vulnerability.

(If) Once the supplier completes the remediation, the deployer must make a decision regarding the need to implement a remediation for a vulnerability for which a deployer has already implemented a mitigation. One factors to consider is cost (downtime, effort for testing & installation of mitigation). From a deployer’s decision point, is the software at end of use for their company? Do they intend to replace the (mitigated) vulnerable system with an altogether different system?

Does the deployer have the option to not apply the remediation? (yes) How/should it be recorded?

@j--- Am I on the right track?

[j---]

Yes, I think this is the right stuff to discuss.

One thing we may be able to tackle is to open up the line of thinking that a successfully applied mitigation may change some of the SSVC answers. An obvious one is system exposure.
An analyst might think of applying mitigations until they can change the priority with which they need to act to "defer" in which case there may sometimes be a structured answer to your suggested question "Does the deployer have the option to not apply the remediation? (yes) How/should it be recorded?".
Not every vul can have mitigations applied until it is in defer, of course.
This can also help structure what you suggested around whether a deployer should apply a remediation for a system which has mitigations in place already.

There is a little bit of discussion about changing information in ### Information Changes Over Time in 060_. I'm not sure whether we should address this issue there or in 040; I think 040 is probably better, but you don't need to re-hash ### Information Changes Over Time, just provide a forward reference to it.

[zmanion]

I agree mitigation in practice is often temporary, in expectation of forthcoming remediation, and we can/should absolutely say that. But I'd like to keep mitigation strictly separate from a sense of temporary or permanent. IOW, it should be possible to mitigate (not remediate) and take no further action, ever, even if there is a remediation.

Perhaps it's implied, if a vulnerability is remediated, then there's no reason to perform SSVC assessments on it anymore, right?

I like the idea that

1. I assess a vulnerability and SSVC tells me to act
2. I mitigate, which changes values for maybe exposure or technical impact (or one of the contextual values like safety or mission impact)
3. I reassess, and SSVC now tells me to defer.
4. Defer it is, risk mitigated, on to the next problem.

[j---]

Perhaps it's implied, if a vulnerability is remediated, then there's no reason to perform SSVC assessments on it anymore, right?

I think it is implied, but we should make it explicit as part of resolving this issue.

But I'd like to keep mitigation strictly separate from a sense of temporary or permanent.

Agreed.

I also like making those 4 steps explicit.

[laurie-tyz]

I can't issue a new pull request until the other one is completed (060_ minor changes). So I'm putting my text here for you folks to have a look at. Let me know what you think... Worked on 040_stakeholders-scope... I included both paragraphs for context, but I only changed the first one.

Deploying Patches

Whether or not to deploy available remediation is a binary decision. However, additional defensive mitigations may be necessary sooner than patches are available and may be advisable after patches are applied. Applying mitigations will change the decision point for System Exposure and possibly Well-being and Mission Impact, shifting the priority to defer. Later, if the supplier provides a patch, the deployer may continue to defer, as the risk has been mitigated. We recognize that vulnerability management actions are different when a patch is available and when it is not available.

When remediation is available, usually the action is to apply it. When remediation is not yet available, the action space is more diverse, but it should involve mitigating the vulnerability (e.g., shutting down services or applying additional security controls) or accepting the risk of not mitigating the vulnerability. Table 3 displays the action priorities for the deployer, which are similar to the supplier case.

[j---]

Applying mitigations will change the decision point for System Exposure and possibly Well-being and Mission Impact, shifting the priority to defer.

I'd like to unpack this a bit more. It could be the following paragraph:

Applying mitigations should change the value of decision points.
For example, effective firewall and IDS rules may change System Exposure from open to controlled.
Financial well-being impact might be reduced with adequate fraud detection and insurance.
Physical well-being impact might be reduced by physical barriers that restrict a robot's ability to interact with humans.
Mission impact might be reduced by introducing back-up business flows that do not use the vulnerable component.
A mitigation that successfully changes the value of a decision point may shift the priority of further action to defer.