Repository navigation
Mapping some CVSS vector elements to SSVC Technical Impact #195
Description
Activity
- changed the title
[-]Pull CVSS vector data into SSVC calculator as appropriate[/-][+]Mapping some CVSS 3.1 vector elements to SSVC Technical Impact[/+]on Feb 11, 2025 - changed the title
[-]Mapping some CVSS 3.1 vector elements to SSVC Technical Impact[/-][+]Mapping some CVSS vector elements to SSVC Technical Impact[/+]on Feb 11, 2025 We should adapt this for CVSS v4 at this point too.
CVSSv4 makes it easier because you can remove the Scope ELIF and just us the vulnerable system C/I/A score.
I was thinking about this, and I think we should also discuss whether we need to be careful of the CVSS guidance to score the change in access, whereas Technical Impact scores the end resulting access.
So, concretely, CVSS (v2, v3, and v4) guidance is that if there are privileges required to exploit the vul (like read access to all files, let's just say for simplicity of example), and the end result is gaining write access to all files, then the CVSS score would be C:N/I:H because confidentiality didn't change based on privs already required. This would break my simple proposed logic.
Within the CVSS vector itself, we could filter on PR:N to be able to use the simple logic. If there are privileges required and (vulnerable system) C or I or A is not High, then we don't know technical impact is not total and can't make a clear determination.
I don't think the new Attack Requirements makes a difference to us here, and I don't think User Interaction makes a difference to us here, but I could be wrong.
- added a parent issue
on Jul 7, 2025 Just a note that the new
DecisionTableobject gives us a vehicle to represent whatever mapping we eventually land on for this. #795Based on recent conversations within the team, and what we already said in Information Sources, here's where I think we stand on this.
Note
This is only for CVSS v4 vector elements, although per Information Sources it would also apply to CVSS v3 with minor tweaks when Scope is
unchangedrow Privileges Required v1.0.1 (cvss) Confidentiality Impact to the Vulnerable System v3.0.0 (cvss) Integrity Impact to the Vulnerable System v3.0.0 (cvss) CI Both highC OR I highPR: NTechnical Impact v1.0.0 0 high none none FALSE FALSE FALSE partial 1 low none none FALSE FALSE FALSE partial 2 high low none FALSE FALSE FALSE partial 3 high none low FALSE FALSE FALSE partial 4 none none none FALSE FALSE TRUE partial 5 low low none FALSE FALSE FALSE partial 6 high high none FALSE TRUE FALSE partial 7 low none low FALSE FALSE FALSE partial 8 high low low FALSE FALSE FALSE partial 9 high none high FALSE TRUE FALSE partial 10 none low none FALSE FALSE TRUE partial 11 low high none FALSE TRUE FALSE partial 12 none none low FALSE FALSE TRUE partial 13 low low low FALSE FALSE FALSE partial 14 high high low FALSE TRUE FALSE partial 15 low none high FALSE TRUE FALSE partial 16 high low high FALSE TRUE FALSE partial 17 none high none FALSE TRUE TRUE probably partial 18 none low low FALSE FALSE TRUE partial 19 low high low FALSE TRUE FALSE partial 20 none none high FALSE TRUE TRUE probably partial 21 low low high FALSE TRUE FALSE partial 22 high high high TRUE TRUE FALSE total 23 none high low FALSE TRUE TRUE probably partial 24 none low high FALSE TRUE TRUE probably partial 25 low high high TRUE TRUE FALSE total 26 none high high TRUE TRUE TRUE total The remaining question is: what information would tilt
probably partialtowardtotal? Is there any existing singular decision point (or CVSS vector element) that would do that? Would we need a second decision table to discriminate just theprobably partialrows with more information?So as it currently stands, if we flip all the
probably partials topartial, thenPrivileges Requiredis never relevant. So that means in order for us to justify keeping it in the decision table at all, at least one of the following rows must flip tototal.row Privileges Required v1.0.1 (cvss) Confidentiality Impact to the Vulnerable System v3.0.0 (cvss) Integrity Impact to the Vulnerable System v3.0.0 (cvss) CI Both highC OR I highPR: NTechnical Impact v1.0.0 17 none high none FALSE TRUE TRUE probably partial 20 none none high FALSE TRUE TRUE probably partial 23 none high low FALSE TRUE TRUE probably partial 24 none low high FALSE TRUE TRUE probably partial One obvious cut line (without adding another decision point to discriminate) would be "if one of CI is
highand the other islowand if PR isnonethen technical impact istotal, otherwisepartial. That would flip rows 23 and 26 tototaland rows 17 and 20 topartial. The resulting signal provided byPrivileges Requiredwill be fairly low because most of the information comes from C & I impacts, but at least it would contribute something to the decision table.Another possible cut line (again, not adding anything else) is "if Either C or I is
highand PR isnonethentotalotherwisepartial. This would flip all four rows tototal.The next question: What other CVSS vector elements might possibly be relevant to differentiate here?
I'll just walk through the whole vector:
CVSS Vector Element Relevant? Comment Attack Vector ❌ How the vulnerability is reached doesn't address the impact to the system once exploited. Attack Complexity ❌ Difficult or not, the impact is a post-exploitation effect Attack Requirements ❌ Basically same answer as Attack Complexity Privileges Required ⚠️ Already under consideration, and the reason we're having this conversation User Interaction ❌ UI is, again, "on the way to the impact" Confidentiality Impact ✅ See existing documentation Integrity Impact ✅ See existing documentation Availability Impact ❌ See existing documentation, denial of service is partialNone of the Threat or Environmental metrics say anything relevant to what happens on the system once exploitation occurs.
Likewise, most of the Auxiliary metrics (Automatable, Provider Urgency, Recovery, or Value Density) are also irrelevant to the question of how much control an attacker gets.
There might be room for
Safetyto factor in, but that's not clear to me at present.Similarly, there aren't any other existing [SSVC decision points](https://certcc.github.io/SSVC/reference/decision_points/ in the SSVC namespace that are relevant to Technical Impact either.
Conclusion: Outside of the "cut lines" mentioned in my earlier comment, there is no currently extant decision point to draw on to better discriminate the
probably partialintototalvspartialtechnical impact. Which leaves the question: Is there a decision point gap to fill here? What would it be?I don't think it's a decision point gap -- that would imply this is relevant to a decision outcome. I think it's a gap in gathering information guidance for how we decide between
totalandpartial. CVSS may just not perfectly map into this decision point.line 14 and 16, for example, are also probably partial. But since CVSS scores impact as a diff from what the attacker gains, rather than the final outcome, when PR:H it is sort of unclear if it is
totalorpartial.One way out could be to create a variation on Technical Impact that includes an
evaluateoption:total= as in TI 1.0.0, no changeevaluate= the decision table cannot make the call, evaluation is neededpartial= as in TI 1.0.0, no change
Then we just construct the decision table with the "probably partial" rows (plus 14 and 16 as @j--- notes) as
evaluate, and write up the accompanying instructions to provide examples that tiltevaluatetowardtotalorpartial.Summary of changes to the table previously shown:
row Privileges Required v1.0.1 (cvss) Confidentiality Impact to the Vulnerable System v3.0.0 (cvss) Integrity Impact to the Vulnerable System v3.0.0 (cvss) CI Both highC OR I highPR: NTechnical Impact v1.1.0 14 high high low FALSE TRUE FALSE evaluate 16 high low high FALSE TRUE FALSE evaluate 17 none high none FALSE TRUE TRUE evaluate 20 none none high FALSE TRUE TRUE evaluate 23 none high low FALSE TRUE TRUE evaluate 24 none low high FALSE TRUE TRUE evaluate Open Questions
If we were to take this approach, we'd need to answer a few practical questions:
- What is the name of the new value? is
evaluategood enough or is there another term we should use?- My suggestion: use
evaluate
- My suggestion: use
- Is this new decision point called
Technical Impact 1.1.0? It adds a new value but does not change semantics of existing values, so per ADR-0006 it is aminorversion bump from1.0.0.- My suggestion: use
Technical Impact 1.1.0
- My suggestion: use
- How to structure the guidance for the
evaluaterows?- My suggestion: in all discussions we've had so far, the Bayesian prior on how
evaluatefalls out is that the most likely answer ispartial. Which leads me to suggest that we say something like "Choosepartialunless one of the following criteria applies... If one or more applies, choosetotal." This framesevaluateas a catch-and-release process, where the default is to release (partial) unless the keep (total) rules are met.)
- My suggestion: in all discussions we've had so far, the Bayesian prior on how
- What, specifically, are those
keeprules?- I have no specific suggestion at present, TBD
Availability Impact | ❌ ⚠| See existing documentation, denial of service is partial
Replace X with the
⚠️ as availability is somewhat includedBecause this outcome (what's currently proposed to be called Technical Impact 1.1.0) is an outcome, and not a decision point, I think we should avoid naming it as a version of the decision point. I guess more broadly, the outcome name space and the decision point name space should probably be separate.
I might suggest this outcome space is Deciding Technical Impact v0.1 or something like that. We could make an informal pattern of using "deciding" or some other word in front of the outcome name and make the association to the Technical Impact v1.0 decision point clear. That could be a template for other mappings from things like CVSS to decision points. Thoughts?
I am good withevaluateas the term for the uncertain value, and the option to provide some further guidance on how to do the evaluation.While doing SSVC scoring and evaluating Technical Impact, we’ve found that the tricky situations tend to come from CVEs where the vendor description doesn’t provide enough detail and Confidentiality/Integrity aren’t marked as High. In those cases, PR has never helped us determine whether Technical Impact should be total or partial.
Apologies if I may have missed part of the earlier conversation, but I’m not entirely sure what prompted the idea of incorporating PR into Technical Impact. My humble opinion is that this might introduce extra complexity without giving us answers. In our experience, PR is already represented well and is essential when assessing Automatable, so keeping it separate feels both simpler and more intuitive.
For me, Technical Impact is really about what the attacker ultimately gains if successful exploitation is achieved not the preconditions needed to get there. For example, even if a code-execution vulnerability requires certain privileges to exploit, the end result is still code execution, and that’s what matters when determining Technical Impact. Maybe Tharros have a different opinion while doing SSVC and see if they think PR will help answering those instances in which TI is hard to assess based on CVSS vector and lack of proper vuln description.
The distinction between evaluate and deciding is very clear in English, German, Dutch and Scandinavian languages. However, in many non‑English languages, the distinction is blured, merged, or expressed with the same verb.
"Probably partial" indicates there's not enough evidence to select "partial". Unknown or undetermined are options if you need a third term.
Per CoPilot: CERT analysts typically use:
Unknown when the world lacks data
Undetermined when the analyst lacks dataThis is subtle but operationally important.
This is the calculator engineering aspects of #186
The document describes some equivalences or ways that CVSS vector string data can be used to inform SSVC decisions.
CVSSv3.1 is not ideal for this. See the discussion of CVSS in the md file
md_src_files/082_relatedSystems.mdor where that compiles in the PDF (# Related Vulnerability Management Systems).My suggested logic for the Impact Metrics from CVSSv3.1 is as follows:
IF Scope = Changed
do nothing
ELIF Scope = Unchanged
THEN IF Confidentiality = High AND Integrity = High
DO Technical Impact set to Total
ELSE
DO Technical Impact set to Partial
This is not a perfect mapping, but I think it is a good start.
Since it is not perfect, we will have to think about the User Experience aspect of this. How do we want to expose what the system is doing to the user? How do we give the user enough information about it that they can override the automation if they so desire?