Do we need a decision point to address "criticality"?

[zmanion]

Capturing some other potential applications of SSVC, possibly already supported, possibly requiring different inputs and trees, but likely amenable to SSVC techniques.

How critical is this component? Is this component critical? Consider NIST EO-Critical, other definition(s) of critical.

Should I escalate this vulnerability beyond my standard response practice? (This is vulnerability response prioritization and is currently supported).

[zmanion]

LF OpenSSF critical projects work: https://github.com/ossf/wg-securing-critical-projects/

[zmanion]

https://fedoraproject.org/wiki/Critical_path_package

[j---]

Just as an update, I've been attending OSSF meetings (https://github.com/ossf/wg-securing-critical-projects) to try to follow up on this.

My current thought is that once there are data sources for criticality, it should inform Mission Impact as a data source. In some cases, there may be structured data that enables support for assessments of Public Safety Impact, but mostly these efforts seem to be steering away from explicitly noting or exposing any safety related classifications.

However, mostly these criticality things are talking about something different in the risk equation. The #35 issue is the aspect most closely related to this problem. High criticality justifies spending more on mitigation. #35 would see us talk about how much doing something would cost. Criticality should inform about how much is justified to spend. Neither are what SSVC v2 focuses on.

[j---]

Above comment is my answer to #166 as well.

[ahouseholder]

Converted this to a discussion instead of an issue, as it is not clear what specific action(s) are needed to resolve this thread. Let's discuss here and spawn issues when there is something more specific to do.

[j---]

One way of thinking about this is that there might be alternative decision points that answer a similar kind of question in different ways, or that might be more or less accessible to different stakeholders. For example, maybe criticality as a concept can be used in place of mission impact for stakeholders that don't know situated mission impact (because they're a supplier, etc). Maybe criticality can proxy for or replace value density, as another example.

An alternative way to ingest this concept is to use things like criticality scores as a documented way of gathering information about value density. That would turn these disparate concepts into a way to answer some existing SSVC decision point.

I'm not sure which of these is the best option. Possible that there might be one that is better or worse depending on the stakeholder or situation. In which case, we'd need to figure out which situations fit better to which solution.

[ahouseholder]

Can you dereference "this" in "One way of thinking about this is..." All I'm getting from the conversation so far is "something something criticality" but I don't understand what it's getting at.

For example, maybe we narrow the focus to something more concrete like NIST's Critical Software - Definition & Explanatory Material, which currently says:

EO-critical software is defined as any software that has, or has direct software dependencies upon, one or more components with at least one of these attributes:

• is designed to run with elevated privilege or manage privileges;
• has direct or privileged access to networking or computing resources;
• is designed to control access to data or operational technology;
• performs a function critical to trust; or,
• operates outside of normal trust boundaries with privileged access.

Which seems to imply that "critical" is a simple Yes/No.

[j---]

@sounil may be interested in this discussion.

[ahouseholder]

I'm trying to separate out the "what is criticality?" question from the "how would criticality be used?" one. Let's assume for the sake of argument that we were to define a Criticality decision point with 2+ values. How would it be used? I.e., presumably existing trees would need to change, but which trees, and how would they incorporate this new decision point?

[j---]

I think it possibly replaces a combination of value density, public safety impact, and provides a proxy for mission impact to stakeholders in a supplier or coordinator role. I'm not yet convinced it is a better option than those decision points. But I think that would have to be the argument.
It is also plausible that different supplier stakeholders just might want different decision points, there is nothing that says there has to be only one recommended supplier tree, for example. Though then we would need to provide guidance on how to select among suggested trees, I don't think that guidance is much different than the "build your own tree" guidance.

[ahouseholder]

Without defining any new decision points, the concept that such decision points might be created is included as part of PR #242.

I do not believe that is sufficient to resolve this discussion, I'm just noting that there are some relevant words in that PR.

[j---]

Agree. I think we can leave this discussion open and if someone would like to suggest of a definition of a criticality decision point along with suggested integration into some stakeholder tree options, this is a good reference. However, I think no action at this time for us to move on this issue or trying to draft anything. The guidance on how to create new decision points added in #242 is enough for someone to do this for criticality if they wish to.

[ahouseholder]

Ack. Leaving discussion open but closing #217 to take this off the books for v2.1

[ahouseholder]

I created #319 for the Critical Software-as-decision-point item with thoughts on implementation. The main question outstanding is of an example usage.

[ahouseholder]

#319 was closed by #346 with an implemenation of a critical software decision point.