Closed YanWittmann closed 9 months ago
Hi! As far as I understand there is only one CVSS v4.0 score. If you do not fill in any optional metrics you will get a worst case. If you fill more optional information, the score can get lower. It is even expected that software providers and consumers will fill different metrics during their analysis.
@ViperGeek can probably give you more complete explanation or point you to better place to have more thorough discussion.
I see, thank you for the clarification. That already helped point me in the correct direction.
If you don't mind, I have two more questions regarding this implementation (which has been very useful to understanding CVSS 4.0, so thank you) and the spec:
The spec has the following section on the EQ6:
Table 30: EQ6 - MacroVectors
Levels | Constraints | Highest Severity Vector(s) |
---|---|---|
0 | AV:N and PR:N and UI:N | AV:N/PR:N/UI:N |
1 | (CR:H and VC:H) or (IR:H and VI:H) or (AR:H and VA:H) | VC:H/VI:H/VA:H/CR:M/IR:M/AR:M or VC:H/VI:H/VA:L/CR:M/IR:M/AR:H or VC:H/VI:L/VA:H/CR:M/IR:H/AR:M or VC:H/VI:L/VA:L/CR:M/IR:H/AR:H or VC:L/VI:H/VA:H/CR:H/IR:M/AR:M or VC:L/VI:H/VA:L/CR:H/IR:M/AR:H or VC:L/VI:L/VA:H/CR:H/IR:H/AR:M or VC:L/VI:L/VA:L/CR:H/IR:H/AR:H |
But your code seems to use a different formula:
// EQ6: 0-(CR:H and VC:H) or (IR:H and VI:H) or (AR:H and VA:H)
// 1-not[(CR:H and VC:H) or (IR:H and VI:H) or (AR:H and VA:H)]
Is this intentional? Yours makes more sense to me.
Regarding the specification, there is also a reference to a Table 32:
... the MacroVector from Table 32.
But this table does not exist anywhere on the page or in the PDF version. Do you have any details on what this table contains? Did it exist previously and was removed or renamed without refreshing the numbering?
Again, thank you for helping me in this.
I am sorry that I cannot answer your questions in detail. I was not involved with CVSS v4.0 recently so I am not familiar with all the most recent changes to both documentation and code. However, I bet @ViperGeek , @giorgioditizio , or @bjedwards could help and possibly use this feedback or direct you to a better place for this discussion?
Hello @YanWittmann. Thank you very much for taking the time to submit these questions. As you may know, CVSS v4.0 is currently reviewing all public comment received over the last two months. The response has been both helpful and overwhelming.
I'm glad @skontar's reply was able to help explain the newly refined concepts of CVSS-BTE scoring. In a nutshell, all CVSS v4.0 scores consider Base, Threat, and Environmental metric values. In the absence of any optional (Threat and/or Environmental) metric, the default Not Defined (X) value is used in the calculation. In most cases, X is equivalent to the worst-case value for that metric.
Regarding the typos in our Specification Document, Table 30 is being reviewed and updated as you read this. References to Table 32 have already been resolved, but have not yet been pushed into production.
Thanks again for your comments and questions!
Ah, I see. The reduction from the 6 scores to 1 surprised me at first, I will have to adjust quite some logic and visualizations in my system.
Sorry for the late answer and for persisting with my questions, but I have some more.
For anyone reading this, feel free to skip any questions you don't know the answer to or don't want to read through all of this. I'm grateful for every answer I can get.
Q1:
In this table of the EQ4 Macro Vectors on https://www.first.org/cvss/v4.0/specification-document, the values SI
and SA
are both set to S
, which is not one of the valid values of these attributes:
Table 28: EQ4 - MacroVectors
Levels | Constraints | Highest Severity Vector(s) |
---|---|---|
0 | MSI:S or MSA:S | SC:H/ SI:S/SA:S |
1 | not (MSI:S and MSA:S) and (SC:H or SI:H or SA:H) | SC:H/SI:H/SA:H |
2 | not (MSI:S and MSA:S) and not (SC:H or SI:H or SA:H) | SC:L/SI:L/SA:L |
Valid values include:
Subsequent System Integrity Impact (SI): [H,L,N]
Or should I assume the values of the modified attributes for this?
Modified Subsequent System Integrity (MSI): [X,N,L,H,S]
In this implementation here, the scoring function seems to assume the modified values:
const SC_levels = {'H': 0.1, 'L': 0.2, 'N': 0.3}
const SI_levels = {'S': 0.0, 'H': 0.1, 'L': 0.2, 'N': 0.3}
const SA_levels = {'S': 0.0, 'H': 0.1, 'L': 0.2, 'N': 0.3}
If I run the calculations (manually, by hand to help me understand) using these values, I get the correct score.
Q2.1:
On the user guide, it says:
Use metric groups to gather the 15 million *CVE-BTE* vectors into 271 equivalence sets
But in the table above that and everywhere else, CVSS-BTE
is used:
Is this a typo or something different?
Q2.2:
In the same sentence, it says that there are 271 EQs, whilst here https://www.first.org/cvss/v4.0/specification-document there are only 270:
Use metric groups to gather the 15 million CVE-BTE vectors into 270 equivalence sets
The 270 make more sense to me, as there are 270 keys in the lookup table https://github.com/FIRSTdotorg/cvss-v4-calculator/blob/main/cvss_lookup.js
Q3: When it says that EQ3 and EQ6 are not independent from each other and must be considered together, is the reason for that simply that EQ6 considers attributes that EQ3 already contains (VC/VI/VA
)?
Q4: Could you provide and example as to how you calculated the max hamming distance (vector depth?) in this table?
https://github.com/RedHatProductSecurity/cvss-v4-calculator/blob/main/max_hamming.js
When I calculate them myself, I get different values.
Again, I'm just trying to understand the new standard, thank you for your help, it has been invaluable.
@ViperGeek I am not sure if all questions here were/should be answered. Can you please have a look?
Ah, I almost forgot asking these questions here. I figured some of it out in the meantime myself.
I can accept Q1 as just being like this for the calculations, it doesn't have to make more around that.
Q2 is just another issue I found with the documentation being inconsistent, might already be fixed in your internal versions, but that's all right.
Q3 might be interesting, but isn't critical.
Q4 is the question that I would really be interested however. I still don't fully understand how these values come to be.
Another thing related to these hamming values I found whilst performing the calculations myself and writing my own little formulas, is that the step = 0.1
variable doesn't really do anything:
The final equation for each of the EQ adjustment values looks something like this: (current_hamming_distance_eq1)/maxHamming_eq1
This means, both the current_hamming_distance_eq1
and maxHamming_eq1
need to be in the same decimal place system (either both integers or both step size). In your calculations, this is the step size (0.1
), as seen in:
AV_levels={"N": 0.0, "A": 0.1, "L": 0.2, "P": 0.3}
are given using decimal.
This means that also the values from the lookup table must use that step size, which they are not, so they must be multiplied with the step size: maxHamming_eq1 = this.maxHammingData['eq1'][String(eq1_val)]*step
, where they are then used to calucate the hamming distance for that EQ: current_hamming_distance_eq1 = hamming_distance_AV + hamming_distance_PR + hamming_distance_UI
This seems... unnecessary? When I calculate this myself, I can easily leave away the step size multiplication and use full integer steps for the AV_levels={"N": 0, "A": 1, "L": 2, "P": 3}
, since this is the only place these values are used and only the ratio between these matters. I don't know, that confused me a little at first, why you had to multiply with the step size first there, when you really did not. But that's just a thing with the implementation, so if it works, it's all fine.
You don't really need to answer my questions if you don't have the time or knowledge, but I would really be interested in the answerto Q4.
Thank you!
Hi @YanWittmann, I may try to provide a few answers to your questions:
Q1:
This has been clarified in the upcoming CVSS v4.0 specification, but some code cleaning may be needed to match it properly. It has been clarified that SI/SA can't have the value S, so during computation you have to rely on MSI/MSA to compute the MacroVector.
The S value is explained in the "Modified Base Metrics and Safety" paragraphs if needed (in the public draft).
Q2.1:
CVSS-BTE defines the CVSS v4.0 vectors that combines the Base, Threat and Environmental metrics groups. This notation is involved to explain how the score was computed. As the Supplemental metric groups is not involved in the computation, CVSS-BTES is a nonsense. I'm not sure if this provides an answer to your question as I can't understand what you saw as a problem :x
Q3:
Yep !
Q4:
The "Hamming distance" is a relica from a previous work on the CVSS v4.0 scoring system. This has been removed in favor of "severity distance" defined in the specification (even in the draft, it stays the current definition as it does not match a "Hamming distance" computation). I did not re-computed it by hand, but can you provide an example of what you did to get a different value ?
I hope to have time to clean up the scoring system implementation as it is full of technical dept due to recent decisions through the public questions and comments period. In the same time, I hope to clarify the algorithm in the specification such that it is more dev-friendly.
Thank you for your time, and I'll try to explain my questions a little better.
Q1:
Ah, all right, that's what I thought, nice.
Q2.1:
My issue here was that one time it is called CVE-BTE and one time CVSS-BTE, but again, that's most likely a typo.
Q4:
I may just have understood the calculation, but just to make sure, for example for the EQ1 level 1 with a value of 4, would this be a valid way to calculate the vector depth?
Table 25: EQ1 - MacroVectors
Levels | Constraints | Highest Severity Vector(s) |
---|---|---|
1 | (AV:N or PR:N or UI:N) and not (AV:N and PR:N and UI:N) and not AV:P | AV:A/PR:N/UI:N or AV:N/PR:L/UI:N or AV:N/PR:N:/UI:P |
Let's take AV:A/PR:N/UI:N
as our highest vector. I then try to modify it in a way that does not change the EQ level, but aims to be the lowest score possible:
and with these three changes we get: AV:L/PR:H/UI:N
If we now add 1, we get our distance of 4.
Did I get this right? I mean, there are obviously better ways to calculate these values automatically, but just for my understanding I did it by hand.
But it would be nice to understand where the +1
comes from, why do we have to add 1 to the distance?
Again, thank you for your time and I'm exited for the release of 4.0!
@ViperGeek @pandatix I am not sure if all questions have been answered and if we can close this. However, I also think that GitHub issues are not the best for questions. Maybe we could add a description on the main page explaining where to send your questions? Thanks!
Yes I think the best place to discuss the spec is elsewhere out of this repository's issue tracker, to avoid having multiple communication media :)
I've been able to clarify most of my questions by now on my own and through your pointers. Thanks for helping me out and providing this implementation, it's helped a lot!
I've originally started this issue because I didn't really find other places to ask for help, so yes, it might be a good idea to provide some resources regarding that on the readme.
Hello,
I apologize if this isn't the appropriate place for my question, but I'm trying to understand the scoring system in CVSS v4.0 more clearly.
From the documentation and resources I've seen so far, it appears that CVSS v4.0 produces a single score, with different nomenclatures like CVSS-BE, CVSS-BT, etc., depending on which metrics are used.
Could you clarify how these nomenclatures relate to the types of scores we had in CVSS 3.x?
In CVSS 3.x, we had multiple types of scores:
But in CVSS v4.0, it seems like there's only one score, the meaning of which changes based on which parts of the vector are filled out. Could you please clarify this?
Or, some more detailed questions:
Thank you for your time and assistance.