Provide better summary for what is the same and what is different across organizations

[j---]

Are SSVC scores site-specific where scores for one organization may be different than another?

This question can mean different things depending on what "scores" means, but I think we need to own that in our explanations and not just be pedantic about the jargon we (I) invented. So, one SSVC question (decision point) is State of Exploitation [None, public PoC, Active]. Everyone should basically have the same answer to that question. The Mission Impact question, it's expected different orgs have different deployments and so have different answers. Those answers get combined logically by the tree into a response priority [defer, scheduled, out of cycle, immediate]. I haven't talked to any CISO or security manager who wanted different options there. So in that sense, all deployers (system owners) have the same options. And if they all use our recommended deployer tree, anyone who has the same answers (say, Mission Impact high, Exploitation PoC, etc.) will reach the same decision. But we do open the option for organizations to customize the tree to their risk appetite (whole paper section, not going to summarize). So there are a lot of things about the scores that are shared across orgs. This (hopefully) makes it easier to talk about what differences there might be and make sense of them. But I don't think this is communicated very well in a summary right now. So we need that summary in a visible place. Probably including READMEs.

[sei-vsarvepalli]

IMO the SSVC recommended action are to be used with other local database to pursue an action and have it propagate throughout the organization. As long as there is transparency about the SSVC score, I see no reason to have the SSVC score itself be customized to include "site-specific" attributes for the decision.

Given there are organization like ICS-CERT whose score will have to interpreted by the "Risk Owners" to pursue an action. This is not any different in the case of a larger organization where each site or location may have different filtering of the score to make a final decision.

Vijay

[ahouseholder]

I think this is talking about a concept of scope, and it applies to both decision points and decision trees.

Decision Point Scope

Each decision point seems to have a characteristic scope, e.g., global or local, but maybe it's 3 or 4 scopes instead of just 2?

• Globally-scoped decision points are ones that are essentially about the state of the world outside. They form the background context in which the stakeholder is making prioritization decisions. Nearly all stakeholders should agree on the assignment of specific values to these decision points. (I say "nearly" because there could be some room for local context to override a global, but it'd have to be rare and specialized knowledge of how the local decision context is exceptional. I don't have an example at the moment though.)
• Locally-scoped decision points are ones that are expected to be contextual to some decision makers. Mission Impact seems like an obvious one here.
• Intermediate-scoped decision points live between global and local ones. They might lean one way or the other (i.e., more global than local, more local than global). For example, Exposure for a DNS vul might be scoped differently for authoritative nameservers versus internal caching resolvers.

Of course, the problem with having an intermediate category is the risk that one could argue nearly everything belongs in it.

Perhaps another way of looking at it could be to just say "some decision points are global", and all the others are expected to be local, although it's of course up to the SSVC analyst to decide whether they can "borrow" someone else's "local" answer for their own local answer.

Decision Tree Scope

This one seems a bit more clear cut. All trees can be localized of course. And "localization" can occur at different levels (perhaps a sector comes up with a customized tree for its constituency, and then each organization in that constituency tweaks it a bit more for their own operational requirements)

But there might be a distinction to be made w.r.t. the "size" of a change:

1. Adjusting leaf nodes is for when you generally agree with the structure of the tree, but your risk appetite is different than the defaults provided.
2. Adding or Removing Decision Point Options is for when you need more or less fine-grained control over potential choices than the default tree permits. Obviously, because changing a decision point implies a change to the branching of the tree, there will be a need to adjust leaf nodes as well.
3. Adding or Removing Decision Points is for when the default tree simply does not address some factor that is relevant to a decision. This is basically building a new custom tree, so once again it implies the necessity to adjust leaf nodes. It could be done without modifying decision point options from the defaults though.

Possible tree modifications then take the form of: 1, 2+1, 3+1, or 3+2+1.

[ahouseholder]

Converted from issue #188 to discussion so we can resolve the threads into more specific changes and spawn those as issues as appropriate later.

[j---]

Intermediate-scoped decision points

I could imagine this being usable if it is framed as sector-group relevant decision points. Like something that makes sense for one or two ISACs, but not members of any other ISAC. Or ISAO, sector CSIRT, etc. But leaving "intermediate" unconstrained means there is no way to decide what is intermediate.

Adding or Removing Decision Point Options

I feel strongly that changing the possible answers for a decision point is the same as changing the decision point. As a readability / usability issue, there should not be decision points with the same name but different output options.

[ahouseholder]

So maybe:

Decision point scope

• keep Globally-scoped decision points as described above
• eliminate intermediate-scoped decision points entirely
• clarify that locally-scoped decision points implies a need to define the relevant scope, and that such decision points could still be inherited by subsidiary constituencies, as exemplified by
  • an ISAO defining a decision point for its sector,
  • a government department defining a decision point for use by its constituent agency CSIRTS,
  • a megacorp CSIRT defining decision points spanning its PSIRTs and CSIRTs

Decision Tree Scope

Support two customization levels:

1. risk-appetite shifts keep tree structure and only adjust leaf nodes as above
2. customizing a tree or defining a new tree implies re-evaluating the new/revised tree for decision outputs as well (i.e., 2 implies 1), but encompasses:

• incorporating an already defined decision point into an existing tree that does not already contain it
• defining a new decision point and adding it to an existing tree
  • adding or removing decision point options to an already defined decision point is treated as creating a new decision point, and it should be given a new name/identity
• defining a new tree entirely from existing or new decision points

[j---]

I think this works. Thanks!

[ahouseholder]

Closing discussion, change recommended as #239