Add Critical Software decision point

[ahouseholder]

I'm suggesting we add one (or more) decision points to reflect software criticality.

While I don't currently have a specific decision in mind for this to be used in, it seems likely to arise in stakeholder processes.

I am currently aware of two such Critical Software definition efforts:

1. NIST definition
2. OSSF working group

Two approaches I can see to do this:

1. Treat the different definitions as a data mapping problem, and create a single, one-bit Critical Software=(yes,no) decision point. This implies documentation guidance that explains how to map NIST, OSSF, or any other such list onto the decision point.
2. Treat each definition as its own distinct decision point, e.g., NIST Critical Software=(yes,no), OSSF Critical Software=(yes,no) etc. This eliminates the need for the data mapping portion of approach 1, but it leads to having more decision points addressing a fairly narrowly defined concept.

My opinion is that approach 1 is preferable, as approach 2 might be overfitting the solution to the problem. It's certainly possible to move from approach 1 to approach 2 in the future should we have a specific need to do so. But I don't think going from approach 2 to approach 1 is as easy because our decision point definitions are likely to become entrenched in a way that the data mapping approach seems more adaptable to.

This may or may not be the same as #210 which refers to High Value Assets (HVA), but we should consider both in tandem to figure out how many decision points we actually need. The part I don't understand is how do CS and HVA designations intersect in actual operational usage.

[ahouseholder]

Note there is also prior discussion in #216 (which was converted from issue #168)

[zmanion]

I'm not sure this is a decsion-improving decision point. Is it not covered by the impact decision points? See https://github.com/CERTCC/SSVC/discussions/216#discussioncomment-5605057. I can suffer severe impact from non-critical software. libwebp seems non-critical by the NIST specification, but a browser using libwebp may be NIST-critical.

If an organization is required to perform actions or meet deadlines based on a criticality value, then it would make sense to include that in their decision trees.

[zmanion]

Generally not a fan of the NIST definition. Word or a PDF viewer don't seem to be critical, but you may want to patch them quickly. OTOH, if a lot of software is critical, the distinction loses signal.

Neither am I a fan of the OpenSSF lists. I see how the OpenSSF score works, but their lists include other projects and seem somewhat inconsistent. Alpine Linux is listed, but not Debian or Red Hat?

From an OpenSSF blog post:

The Criticality Score primarily measures activity, not necessarily criticality. Thus, a high score often indicates significant importance, but a lower score doesn’t mean a project isn’t critical.

I opened https://github.com/CERTCC/SSVC/discussions/216 but now don't think it is particularly useful unless someone is required to respond differently for NIST-critical software. I'd have to re-read the E.O., NIST, and OMB memos but I don't think anyone (USG) is required to do this.

[zmanion]

Closest I can find is

https://www.nist.gov/system/files/documents/2021/07/09/Critical%20Software%20Use%20Security%20Measures%20Guidance.pdf

that includes SM 3.2

rapidly identify, document, and mitigate known vulnerabilities (e.g., patching, updating, upgrading software to supported version) to continuously reduce the exposure time

[j---]

Two approaches I can see to do this:

1. Treat the different definitions as a data mapping problem, and create a single, one-bit `Critical Software=(yes,no)` decision point. This implies documentation guidance that explains how to map NIST, OSSF, or any other such list onto the decision point.

I agree that the way SSVC handles this should be agnostic to the different organizational definitions. Yes/no seems adequate. I don't think we need to over-work a "what if someone is using NIST and OSSF and HVA" data mapping. Rather we can probably simplify with "assuming you are using some definition of critical software yes/no, just use whatever one you want and then we're representing it with this decision point". Not sure if that's clear.

I think close #210 and include HVA in this discussion.

If an organization is required to perform actions or meet deadlines based on a criticality value, then it would make sense to include that in their decision trees.

So maybe https://www.cisa.gov/news-events/directives/bod-18-02-securing-high-value-assets as a motivating example.

[ahouseholder]

So (again showing my potential ignorance of how HVA actually works), I think that HVA and Critical Software might be different things.

For example, CISA says:

A High Value Asset (HVA) is information or an information system that is so critical to an organization that the loss or corruption of this information or loss of access to the system would have serious impact to the organization’s ability to perform its mission or conduct business. These assets, systems, and datasets may contain sensitive controls, instructions or data used in critical operations, or they may house unique collections of data.

So to me the HVA designation sounds broader than Critical Software because it includes data and possibly other things like configurations or documentation. (I'm not attempting to engage in a "data is software and software is data" argument here because we're talking about reflecting extant policies that treat them as distinct categories of things.)

I could imagine that an org designates say SAP or PeopleSoft as Critical Software, but the data stored within them could be designated as HVA. Maybe a lot of folks have a consistent logic for "Any software that stores, manipulates, or controls access to high value assets is considered critical software." But to encode that assumption into making CS and HVA be the same decision point seems like it's us presuming a policy that we don't necessarily have a basis for.

My recommendation is that we retain #210 and just make it a simple 1 bit thing as well.

For what it's worth, I already have these represented in:

https://github.com/ahouseholder/SSVC/blob/68b78d7b23628b9c53991998a794b6276ecbda44/src/ssvc/decision_points/critical_software.py#L9-L31

and

https://github.com/ahouseholder/SSVC/blob/68b78d7b23628b9c53991998a794b6276ecbda44/src/ssvc/decision_points/high_value_asset.py#L7-L29

which would be merged by #328 once approved

[laurie-tyz]

High Value Assets:

HVAs are those assets, Federal information systems, information, and data for which an unauthorized access, use, disclosure, disruption, modification or destruction could cause significant impact to the United States’ nations security interests, foreign relations, economy, or to the public confidence, civil liberties, or public health and safety of the American people. https://www.cio.gov/handbook/policies-initiatives/high-value-assets/

[laurie-tyz]

NIST defines critical software: (NIST uses the word "critical" to define a "High Value Asset")

What is the difference between High Value Asset (HVA) systems and EO Critical Software usage?

A High Value Asset (HVA) is information or an information system that is so critical to an organization that the loss or corruption of this information or loss of access to the system would have serious impact to the organization's ability to perform its mission or conduct business. The HVA program focuses on the overarching system and the value it provides to the agency. EO Critical Software security measures are intended to protect the use of deployed EO-critical software in agencies' operational environments on-premises or in the cloud. The EO-Critical Software pinpoints the software that may feed into the HVA systems.

Some additional background on HVA:

An agency may designate Federal information or a Federal information system as an HVA when it relates to one or more of the following categories:

Informational Value - The information or information system that processes, stores, or transmits the information is of high value to the Government or its adversaries.
Mission Essential - The agency that owns the information or information system cannot accomplish its Primary Mission Essential Functions (PMEF), as approved in accordance with Presidential Policy Directive 40 (PPD-40) National Continuity Policy, within expected timelines without the information or information system.
Federal Civilian Enterprise Essential (FCEE) - The information or information system serves a critical function in maintaining the security and resilience of the Federal civilian enterprise.

https://www.nist.gov/itl/executive-order-improving-nations-cybersecurity/critical-software-definition-faqs

[j---]

My recommendation is that we retain #210 and just make it a simple 1 bit thing as well.

For what it's worth, I already have these represented in:

https://github.com/ahouseholder/SSVC/blob/68b78d7b23628b9c53991998a794b6276ecbda44/src/ssvc/decision_points/critical_software.py#L9-L31

and

https://github.com/ahouseholder/SSVC/blob/68b78d7b23628b9c53991998a794b6276ecbda44/src/ssvc/decision_points/high_value_asset.py#L7-L29

which would be merged by #328 once approved

Keeping them separate is fine. I think they're closely related in the sense that I don't think we should make any example tree that has both in it. Any example tree we propose should just have one or the other. And in that vein, probably should be mutually exclusive with Mission Impact in our examples as well?

Thanks for the context Laurie, that will help inform which one we might want to include in examples for different stakeholder groups.