Add "refinement" step to bootstrapping process?

[ahouseholder]

The bootstrapping process as described right now does not include any feedback from the operational use of SSVC to refine any of

• the decision model (including both the decision points used and the outcomes)
• the policy (decision points → outcomes)
• the data mapping (collected data → decision point values)

Yet we already know that model and policy tuning are part of the operational conversation once you're using SSVC:

1. You use your existing SSVC model to make a decision
2. "Why did you do that?"
3. "Because when we discussed our model and policy, that's what we agreed to."
4. "But we should have done <something else> in this case"
5. "Ok, what should we change in our decision model to address this concern?"
6. Adjust decision points, outcomes, policy, or data mapping to improve the behavior/expectation match next time around

So we should reflect this somewhere. Maybe it goes into the bootstrapping docs directly, or maybe it's a separate page about "maintaining SSVC's operational fit" in the howto section, but regardless it seems like this kind of process monitoring and improvement ought to be explicitly described, however briefly.

[ahouseholder]

It might be convenient to pick up

• 481

• 381

if they're not already resolved when this one gets a PR.

This issue seems independent of #480 though.

[ahouseholder]

See Figure 3 of https://insights.sei.cmu.edu/documents/737/2004_005_001_14405.pdf for a possibly relevant diagram

[ahouseholder]

The PR I submitted

• 488

takes a fairly minimalist approach to this. I just added a section to the prepare step, which I think is sufficient to bring attention to the fact that maintaining an SSVC Decision Model is something you need to prepare for too.

Instead of connecting it back to CMU/SEI-2004-TR-015 Defining Incident Management Processes for CSIRTs: A Work in Progress though, I tied it into the Vulnerability Analysis and Resolution process area of CERT RMM, which seemed a bit more formalized. The diagram in the 2004 report was helpful in thinking about how the Governance bit tied into the big diagram though, given the limitations of Mermaid diagrams.