Cost of mitigation

[j---]

Section 4 of v1.1 says:

There are at least three aspects of asset management that may be important but are out of scope for SSVC. First and most obvious is the transaction cost of conducting the mitigation or fix. System administrators are paid to develop or apply any fixes or mitigations, and there may be other transactional costs such as downtime for updates. Second is the risk of the fix or mitigation introducing a new error or vulnerability. Regression testing is part of managing this type of risk. Finally, there may be an operational cost of applying a fix or mitigation, representing an ongoing change of functionality or increased overhead.

These three costs (transaction, error introduction, and operational change) are listed as out of scope in v1.1 under the assumption that these costs should not change the priority with which a vul ought to be patched. This assumption likely over-simplifies the vulnerability management decision. Version 2 should enumerate the situations in which these costs may legitimately delay the priority with which a vulnerability should be handled. If these situations are both realistic and justified (which seems likely), then how and why these considerations influence the vul handling decision should be integrated into SSVC.

This is important for #14, for example.

[j---]

One way we might handle this is to convert "mission impact" to "net mission impact" where "net" signals that we balance cost of acting with the cost of not acting. But unclear if that will be a usable solution.

[zmanion]

See 3.6 in published SSVC and 4.5(?) in v2 draft.

[j---]

See also https://www.scadafence.com/public-preview-a-comprehensive-guide-to-industrial-device-patching/

[zmanion]

After some consideration/discussion:

SSVC recommends a priority with which to act. This priority approximates the cost/risk of not acting, i.e., higher priority ~= higher cost/risk to not acting, i.e., you are more likely to be attacked and incur/cause losses. @j--- to integrate this framing appropriately throughout v2 paper (including near the front).

SSVC does not address your cost/risk of acting, that is out of (the current) scope and is a separate/next decision to be made. Armed with the SSVC priority (== cost/risk of not acting), compare that to your cost/risk of acting (possibly for different actions), and make this next decision (which action to take).

SSVC "defer" is equivalent to the cost/risk of not acting being so low that it is not necessary to consider taking any other action, not necessary to consider the (low) cost/risk of not acting to the cost/risk of acting, not acting is always lower. Other SSVC priorities imply high enough cost/risk of not acting that you need to advance to the second decision and decide an action to take. It's still possible to choose to not act at this point, but we're beyond SSVC now.

[zmanion]

About "cost/risk" terminology, this is meant to address that there are "fixed" or low-variability costs to act (e.g., direct costs of labor, downtime) and higher variability ("risk") costs such as an unexpected problem with the action/change. There are no direct costs to not acting, but there are variable costs/risk to not acting. We should pick words carefully, explain them, and be consistent.

[zmanion]

Is/to what extent cost/risk to act covered in Mission/Safety impact or any other current part of the model? Perhaps it is not? If not, actively state that it is not. E.g., financial impacts are to others, not directly to the decision maker.

[zmanion]

Likely a separate issue, @ahouseholder to describe (in future work) a generic way to approach this second decision of what action to take. E.g., if SSVC gives you a priority other than defer, prepare a list of possible actions (patching is only one, if a common action) and their rough cost/risk, compare each with SSVC priority, and choose an action (the lowest cost/risk one?) that eliminates the SSVC cost/risk of not acting.

[zmanion]

For v2, will not change model to incorporate risk/cost of change (i.e., performing a mitigation or remediation). Will point out in text that an SSVC assessor must/should consider risk/cost of change (and other organizational risk/cost considerations) before selecting a final priority/action. SSVC is effectively not the final decision but hopefully a near-to-last input in an organization's decision.

Incorporating this into the model may be future work, at the risk of stepping into a full-fledged risk assessment, which we specifically are trying not to do.

[ahouseholder]

No clear actions remain on this one. Closing.

Possible follow-ups in discussion #216