What are the versioned objects in SSVC? #289
Replies: 14 comments 32 replies
-
This discussion supersedes (or at least blocks) Issue #252 about the use of SemVer in versioning. |
Beta Was this translation helpful? Give feedback.
-
On Decision Point Versioning I think individual decision point definitions might be versionable objects, for example:
At present, these are "defined" not only in the text, but also in each tree But what I'm thinking is that if we refactored the {
"label": "Automatable",
"key": "A",
"decision_type": "simple",
"options": [
{
"label": "no",
"key": "N",
"description": "Steps 1-4 of the kill chain..."
},
{
"label": "yes",
"key": "Y",
"description": "Steps 1-4..."
}
]
} We could define a decision point's identity as the tuple of the decision point label and the labels of each of its options. So if any of those changed, we'd want to call it something else i.e., those changes are identity-breaking and therefore we're not talking about a new version of X, instead we're talking about a new thing Y that might replace X in future usage. In summary:
So that also implies, I think, that we probably need to have a versioned schema for Decision Point definitions. |
Beta Was this translation helpful? Give feedback.
-
WE may need to version the schema itself, as we could think of schema making it more automation friendly as we get feedback. |
Beta Was this translation helpful? Give feedback.
-
On Tree Versioning I think a tree's identity is defined by
Notably absent is that I do not believe the order of the decision points matters. Yes, any SSVC UI has to make a choice about how to display the decision points and outcomes, and the metaphor of a tree is useful for displaying it. But different Decision Point orderings do not make for different trees, they make for different presentations of the same tree. From a data standpoint the "tree" is just a lookup function that maps each permutation of decision point labels to an outcome. Note that I'm talking about the order of the decision points themselves as in (1) above. The questions appear to include:
Following is a summary of how the example tree targeted at system owners (patch appliers, deployers) has evolved:
I have not reviewed the outcomes of Patch Applier 1.1 compared to 1.0, but let's assume for argument's sake that they stayed the same. Which means that the SSVC v1.0 Patch Applier Tree is equivalent to the SSVC v1.1 Patch Applier Tree. It seems odd to me that we'd want to change the version of an unchanged thing. On the other hand, it seems like SSVC v2.0 Deployer and SSVC v2.1 Deployer are actually significantly different, perhaps enough to bump a major version of the tree if we were to version trees separately (and depending on what versioning ruleset we eventually come to). However, if we were to posit that a future major version of SSVC (say, v3.0) were to leave both the structure and outcomes of the Deployer tree unchanged, would it warrant calling that the SSVC v3.0 Deployer tree even though nothing had changed from SSVC v2.1? I think this argues in favor of having versioning rules for trees, and that those versions are distinct from the "SSVC version", whatever that becomes. The next question is whether outcome changes (e.g., risk shift adjustments) constitute versioned events). But this essay is long enough for now, so I'll leave that for a potential follow-up post. |
Beta Was this translation helpful? Give feedback.
-
So adding to this, there is at least one other thing that might need to be versioned, and that is SSVC the system. Where the system is a collection of decision points. Documentation is separate from the system, because documentation is about how to use the system, as well as documentation of what the decision points and example trees are. |
Beta Was this translation helpful? Give feedback.
-
This comment was written prior to reading @sei-vsarvepalli's previous comment so please forgive any redunancies or contradictions I needed to make the "decision point version" idea more concrete. But we don't have a lot of examples of decision points changing over time within SSVC. So instead, I'm going to use CVSS elements as a proxy, acting as if CVSS vector elements are functionally equivalent to an SSVC decision point. I'm not trying to model all elements from all versions of CVSS, just a few that serve as good examples.
The versioning principles that emerged for me from this exercise are:
|
Beta Was this translation helpful? Give feedback.
-
This comment is addressing the "what is a tree?" and related "what do you mean by policy?" topics that weave through this discussion. This was also composed independently of the thread begun in @sei-vsarvepalli's comment above. It's lifted from an internal chat conversation at CERT earlier today I'll start with a diagram in which overlapping subsets of 5 decision points are used as input to two distinct decision functions which map policy decisions and return an outcome. graph LR
dp1[decision point 1]
dp2[decision point 2]
dp3[decision point 3]
dp4[decision point 4]
dp5[decision point 5]
subgraph df1[decision func. A]
df1i[inputs]
df1p[policy]
end
subgraph df2[decision func. B]
df2i[inputs]
df2p[policy]
end
df1o[outcome]
df2o[outcome]
dp1 --> df1
dp2 --> df1
dp3 --> df1
dp2 --> df2
dp3 --> df2
dp4 --> df2
dp5 --> df2
df1 -->|returns| df1o
df2 -->|returns| df2o
df1i -->|maps onto| df1p
df2i -->|maps onto| df2p
Say we use the usual four-option outcome set {defer, scheduled, out-of-cycle, immediate}. Also, for this exercise imagine that each decision point is a coin toss (to keep the input space small). The task is to define a mapping from the eight possible input triplets onto the four outcome options. I'm calling that mapping itself a policy. In the table below, I'll show two possible policies (the specific order of the outcome columns as aligned to the input values).
This highlights an ambiguity that I think has been impeding a lot of the conversation so far:
I am strongly in favor of (1), because it preserves the idea that if you fully specify the pinned versions of decision points as I describe in this comment we can easily have a conversation about the structure of a decision's inputs and the relevant dimensions without also having to address the policy outcomes that are inherent to (2). |
Beta Was this translation helpful? Give feedback.
-
I have a concern regarding the word policy. I believe policy is set first and then Procedures implement the policy. |
Beta Was this translation helpful? Give feedback.
-
I agree with this statement: "We define a policy as a function that maps a series of events into a set of actions. " And we should spell it out what we mean when we say "policy". |
Beta Was this translation helpful? Give feedback.
-
Was this discussion closed intentionally? It doesn't seem fully resolved to me. |
Beta Was this translation helpful? Give feedback.
-
The consensus so far leans on using version number to track individual Decision Point. For now we can
My biggest concern remains traceability of a number of items (Decision Points) with their own version numbers and no association as a set or integrated into a Decision Tree. We can always use it for sometime to see how it works out. Some questions that come at least immediately.
There is probably more questions that will come up as we try to implement this into a practical application. |
Beta Was this translation helpful? Give feedback.
-
Sample |
Beta Was this translation helpful? Give feedback.
-
The decision regarding the versioning of decision points is covered in PR #350. A separate PR for versioning of decision point groups will be forthcoming. |
Beta Was this translation helpful? Give feedback.
-
Based on
I'm marking this discussion closed. We may need to consider the question of outcome set versioning separately. I've created #454 to capture that as its own issue. |
Beta Was this translation helpful? Give feedback.
-
Extending a discussion with @j--- and @sei-vsarvepalli
What are the versioned artifacts within SSVC?
Discussion should address: (at least)
Beta Was this translation helpful? Give feedback.
All reactions