Elaborate the concept of a "acuity ramp" using SSVC trees.

[ahouseholder]

Adapted from a comment originally posted by @j--- in #303 (reply in thread)

Let's say we want to give a system deployer a maturity ramp for trees that might fit their current information consumption and asset management maturity levels.

Maturity Level	Tree
1	[IN_KEV]
2	[EXPLOITATION_1]
3	[EXPLOITATION_1, SYSTEM_EXPOSURE_1_0_1]
4	[EXPLOITATION_1, SYSTEM_EXPOSURE_1_0_1, AUTOMATABLE_1]
5	[EXPLOITATION_1, SYSTEM_EXPOSURE_1_0_1, AUTOMATABLE_1, MISSION_IMPACT_2]
6	[EXPLOITATION_1, SYSTEM_EXPOSURE_1_0_1, AUTOMATABLE_1, MISSION_IMPACT_2, SAFETY_IMPACT_1]

How do we name and version this series of trees in a way that helps people onboard into progressively more mature vulnerability management?
Given that people might actually want to add mission impact before automatable (even though there are reasons for picking automatable as easier to gather information for than mission impact, people should be able to express that).

[ahouseholder]

Given our new approach applying the Diátaxis framework to documentation, this seems to me to be appropriate material for either a how to or tutorial document. What I mean by this is that this seems to describe a way to use an SSVC example tree such as the Deployer tree (which we describe in the docs in its level 6) form.

In such a doc, we could describe how (following the adoption process outlined in pull request #308) a deployer stakeholder might be limited in the data they are able to collect or work with, and therefore they begin with a simplified version of the tree that still captures the data they have available.

I don't believe we need to enumerate and version each derivative tree, since there are $2^n-2$ non-empty strict subsets of the main tree (So 30 in this specific example). And especially in the smaller subsets, they will start to overlap with other trees, so their identity is somewhat indeterminate. For example, the tree containing only EXPLOITATION_1 could as easily be a coordinator triage, a supplier, or a deployer derived tree.

But generally I think this is a great idea as it helps show how a stakeholder could "grow into" their desired decision function as their data collection and analysis capabilities improve.

[ahouseholder]

One nit we need to consider when we start writing this up:

Is it always the case that the derivative trees are strict subsets of the parent tree? In @j---'s example for level 1, we find an IN_KEV decision point. (Which we'd need to create, btw. Not a big deal, just noting it's non-existence at the time of this writing.) And conceptually, assuming that IN_KEV provides values (yes, no), then we can probably reasonably define a mapping from IN_KEV == yes to EXPLOITED_1 == Active. But we can't say anything about IN_KEV == no.

It's not necessarily a big deal if we're not worrying about naming/versioning these derivatives, but it's worth pointing out that some decision points might even track along some dimension of maturity, or maybe acuity is a better term at the decision point level? Maturity carries a sort of moral bias in the sense that it has an implied "good" direction from "immature" to "mature", whereas "acuity" as a dimension is more akin to resolution in the imagery/photography sense. There are many good reasons that decisionmakers might be fine with a low-resolution-but-readily-available signal over a high-resolution-but-hard-to-acquire signal. We shouldn't burden the language with an implication of deficiency if you build a decision process using IN_KEV over EXPLOITATION_1, assuming that IN_KEV provides an appropriate resolution for the decision in question.

[j---]

Is it always the case that the derivative trees are strict subsets of the parent tree? In @j---'s example for level 1, we find an IN_KEV decision point. (Which we'd need to create, btw. Not a big deal, just noting it's non-existence at the time of this writing.) And conceptually, assuming that IN_KEV provides values (yes, no), then we can probably reasonably define a mapping from IN_KEV == yes to EXPLOITED_1 == Active. But we can't say anything about IN_KEV == no.

Also for example, maybe we say VALUE_DENSITY is a lower-maturity version of MISSION_IMPACT at least for some folks because VALUE_DENSITY is less effort to collect data for than MISSION_IMPACT. But the lower maturity one would eventually be swapped out for the higher maturity one. The reason to replace, rather than add, is that we don't want trees to get visually too big because then it interfere's with leadership's ability to quickly reason about the risk tolerance represented by the huge number of combinatorics (this is what I think has happened with CVSS to some extent). If we think that this is plausible, then that would mean supporting the maturity ramp not being strictly subsets.

[j---]

Also @jeroenh you're interested in this.

[jeroenh]

thanks for pinging me @j--- I was busy, lost track of the many github notifications.
However, this did allow me to let this issue simmer in my thoughts.

I recognise the struggle with the term "maturity". This comes up in many different topics when you're discussing this kind of development roadmap. It also touches upon the issue that in general we've not come to terms with the idea that cybersecurity processes need to adapt to context.

Would it be possible though to give some indication on how hard it is to gather information about certain decision points?

[ahouseholder]

Based on #315 (comment) I changed the name of this issue to acuity ramp as I think it better reflects that we're talking about increasing the resolution with which a process perceives the world.

In response to:

Would it be possible though to give some indication on how hard it is to gather information about certain decision points?

I think so. Now that we've opened up the concept of data mapping in our documentation, we might want to reframe many of the "Gathering information about..." sections to be more focused on that data mapping process. And something akin to degree of difficulty would seem relevant in that context.

[j---]

I can imagine a first pass on the "how hard is it" options as:

• Someone posts it publicly
• You can buy it
• You have to set up a system to collect and manage it yourself

I'm sure there can be many layers of difficulty within each of these. Structured data in a public database are easier than scraping images out of a PDF that have to be OCR'd. But I propose these three as the broad salient categories.