Support CVSS 4.0 in CSAF 2.x

fjscao commented 1 year ago

CVSS 4.0 official publication is scheduled for Q4, 2023. CSAF 2.x schema needs to add the new "cvss_v4": { "$ref": "https://www.first.org/cvss/cvss-v4.0.json" },

santosomar commented 1 year ago

I recently received an identical question from a member of our community. From a technical standpoint, it's entirely feasible to integrate the CVSS v4.0 standard into our current system. You can easily add the property CVSS v4 (cvss_v4) with a corresponding value that adheres to the CVSS v4.0 schema, as outlined at FIRST's CVSS v4.0 JSON schema. Here's how you can reference it in your JSON file:

"cvss_v4": {
  "$ref": "https://www.first.org/cvss/cvss-v4.0.json"
},

However, there's a caveat. Implementing this would lead to a failure in the mandatory tests as described in CSAF documentation. This raises a critical point: The landscape of cybersecurity standards like CVSS is continuously evolving. Rigidity in CSAF's requirements could make it less adaptive and potentially obsolete as these standards undergo updates or revisions.

To future-proof CSAF and encourage broader community adoption, it may be prudent to adopt a more flexible approach that can easily accommodate changes in CVSS and other related or supported standards. This way, we can ensure that CSAF remains up-to-date in the rapidly evolving field of cybersecurity.

tschmidtb51 commented 1 year ago

A future-proof standard is one that is actively maintained - and we are doing this with CSAF.

The most important point to me is, that people can develop their tools to a fixed version of the standard and know what they can expect. Custom extensions and adding special fields makes it harder to validate files (you can't tell anymore whether it is a misspelling or a custom extension) and to write tools that process files as you have to implement all different extensions.

Therefore, I'm much more in favor of writing a new version of the standard to avoid the complications...

fjscao commented 1 year ago

There are pros and cons for each approach. Someone can provide the list of pros and then the list of cons. I'm busy in this week and next week. Will provide the draft about pros and cons soon, if no one else works on it.

I support Tomas for writing a new version of CSAF (based on the pros and cons in my mind now).

fjscao commented 12 months ago

First, CVSSv3.0 was released in June 2015, CVSSv3.1 in June 2019. The frequency for CVSS new versions isn't a concern, assuming CSAF also has new versons.

Second, there are pros and cons for a future proof standard. The pros include the stabilities of schema, parsers, and test scripts. The cons include the actual work for parsing and testing the new versions from others like CVSS has to be pushed down to the customers. As Thomas pointed out, this can easily create widespread problems among the unsophisticated customers.

So writing a new version of CSAF is a more efficient way to validate the inclusion and notify all the customers of the incoming changes needed.

tschmidtb51 commented 12 months ago

In my perception, CVSS 4.0 is set for CSAF 2.1 - but let's double check with the TC...

tschmidtb51 commented 10 months ago

Here is a list of things to do:

[x] Add CVSSv4 to the Schema
[x] Add CVSSv4 to Informative References
[x] Add CVSSv4 to Construction Principles
[x] Add CVSSv4 to Vulnerabilities Property - Scores
[x] Add additional test file for 6.1.7
- [x] valid
- [x] invalid
[x] Add CVSSv4 to 6.1.8
[x] Add additional test file for 6.1.8
- [x] valid
- [x] invalid
[x] Add CVSSv4 to 6.1.9
[x] Add additional test files for 6.1.9
- [x] valid
- [x] invalid
[x] Add CVSSv4 to 6.1.10
[x] Add additional test files for 6.1.10
- [x] valid
- [x] invalid
[x] Add additional test file for 6.2.19
- [x] valid
- [x] invalid
[x] Update Test 6.3.1
[x] Add new test 6.3.X
[x] Add additional test files for 6.3.X
- [x] valid
- [x] invalid
[x] CVRF-CSAF conversion rules
[x] Add CVSSv4 to C.3
[x] Add CVSSv4 to C.5
[x] Add CVSSv4 to referencedSchemas
[x] Generate Strict schema
[x] Adopt test scripts that mention CVSS
- [x] Aggregator
- [x] PMD
- [x] CSAF
- [x] validator

For the schema:

"cvss_v4": {
                  "$ref": "https://www.first.org/cvss/cvss-v4.0.json"
                },

Add CVSSv4 to Informative References

###### [CVSS40]
_Common Vulnerability Scoring System v4.0: Specification Document_, FIRST.Org, Inc., 09 November 2023, https://www.first.org/cvss/v4-0/cvss-v40-specification.pdf.

Add CVSSv4 to Construction Principles

  * Common Vulnerability Scoring System (CVSS) Version 4.0 [CVSS40]
    * JSON Schema Reference https://www.first.org/cvss/cvss-v4.0.json

Add CVSSv4 to Vulnerabilities Property - Scores

Value type of every such Score item is `object` with the mandatory property `products` and the optional properties `cvss_v2`, `cvss_v3` and `cvss_v4` specifies information about (at least one) score of the vulnerability and for which products the given value applies. Each Score item has at least 2 properties.

        "properties": {
          "cvss_v2": {
            // ...
          },
          "cvss_v3": {
            "oneOf": [
              // ...
            ]
          },
          "cvss_v4": {
            // ...
          },
          "products": {
            // ...
          }
        }

The property CVSS v4 (`cvss_v4`) holding a CVSS v4.0 value abiding by the schema at [https://www.first.org/cvss/cvss-v4.0.json](https://www.first.org/cvss/cvss-v4.0.json).

Add CVSSv4 to 6.1.8

  /vulnerabilities[]/scores[]/cvss_v4

Add CVSSv4 to 6.1.9

  /vulnerabilities[]/scores[]/cvss_v4/baseScore
  /vulnerabilities[]/scores[]/cvss_v4/baseSeverity
  /vulnerabilities[]/scores[]/cvss_v3/threatScore
  /vulnerabilities[]/scores[]/cvss_v3/threatSeverity
  /vulnerabilities[]/scores[]/cvss_v4/environmentalScore
  /vulnerabilities[]/scores[]/cvss_v4/environmentalSeverity

Add CVSSv4 to 6.1.10

/vulnerabilities[]/scores[]/cvss_v4

Update test 6.3.1

It is recommended to (also) use the CVSS v4.0.

Add new test 6.3.X

6.3.X Missing CVSSv4 => TBD

For each item in the list of scores which does not contains the cvss_v4 object it MUST be tested that a CVSS v4 is present.

The relevant paths for this test are:

  /vulnerabilities[]/scores[]
  /vulnerabilities[]/scores[]

Example 1 (which fails the test):

  "cvss_v3": {
    "version": "3.1",
    "vectorString": "CVSS:3.1/AV:L/AC:L/PR:H/UI:R/S:U/C:H/I:H/A:H",
    "baseScore": 6.5,
    "baseSeverity": "MEDIUM"
  }
TBD

Just CVSS v3.1 is used.

CVRF-CSAF conversion rule

  *  For any CVSS v4 element, the CVRF CSAF converter MUST compute the `baseSeverity` from the `baseScore` according to the rules of the applicable CVSS standard. (CSAF CVRF v1.2 predates CVSS v4.0.) 
  * TBD: Check rules for CVSS v2 => also computation?

Add CVSSv4 to C.3

/vulnerabilities[]/scores[]/cvss_v4/vectorString

Add CVSSv4 to C.5

TBD

tschmidtb51 commented 10 months ago

[ ] Todo: Backport test 6.1.7: 02, 03, 13, 14 to CSAF 2.0 => #341
[ ] Todo: Backport test 6.1.8: 02, 03, 12, 13 to CSAF 2.0 => #341
[ ] Todo: Backport test 6.1.9: 02, 03, 12, 13 to CSAF 2.0 => #341

[x] Add example with vector to trigger multipleOf issue: (=> tba which test that belongs to)

      "cvss_v4": {
         "version": "4.0",
         "vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N",
         "baseScore": 5.3,
         "baseSeverity": "MEDIUM"
       }

tschmidtb51 commented 9 months ago

Todo:

[x] Update CVSS schema (strict and normal)
[x] Correct test files to reflect change
[ ] Check computation of threatScore
[ ] Check computation of environmentalScore

fjscao commented 9 months ago

CVSSv4.0 doesn't define threatScore and environmentalScore. This issue had been discussed in CVSS SIG, and there is no conclusion yet. One workaround discussed in CVSS SIG is to list CVSS-B, CVSS-BT, CVSS-BE, CVSS-BTE in v4.0 calculator before the scores. CVSS-BT is similar to threatScore, and CVSS-BE is similar to environmentalScore.

Another possibility is CSAF 2.1 should make it clear that CVSSv4.0 doesn't define threatScore and environmentalScore, and the test cases are about CVSS-B, CVSS-BT, CVSS-BE, and CVSS-BTE

fjscao commented 9 months ago

CVSS 3.1: https://www.first.org/cvss/cvss-v3.1.json

    "exploitCodeMaturityType": {
        "type": "string",
        "enum": [ "UNPROVEN", "PROOF_OF_CONCEPT", "FUNCTIONAL", "HIGH", "NOT_DEFINED" ]
    },

CVSS 4.0:

  "exploitMaturityType": {
      "type": "string",
      "enum": [ "UNREPORTED", "PROOF_OF_CONCEPT", "ATTACKED", "NOT_DEFINED" ],
      "default": "NOT_DEFINED"
  },

3.2.3.14

"exploit_status" in CSAF: " this section can be a mirror image of "Exploitability" metric in CVSS v2.x, "exploitCodeMaturityType" in CVSS v3.x, and "exploitMaturityType" in CVSS v4.0.

fjscao commented 9 months ago

Add CVSSv4 to 6.1.9

fjscao commented 9 months ago

The tyop of "_v3" should be replaced by "_v4" /vulnerabilities[]/scores[]/cvss_v4/threatScore /vulnerabilities[]/scores[]/cvss_v4/threatSeverity

fjscao commented 9 months ago

"6.3.2 Use of CVSS v3.0" -> "6.3.x Use of CVSS v3.1"

tschmidtb51 commented 9 months ago

CVSSv4.0 doesn't define threatScore and environmentalScore. This issue had been discussed in CVSS SIG, and there is no conclusion yet. One workaround discussed in CVSS SIG is to list CVSS-B, CVSS-BT, CVSS-BE, CVSS-BTE in v4.0 calculator before the scores. CVSS-BT is similar to threatScore, and CVSS-BE is similar to environmentalScore.

There might be an inconsistency here. I just had a look at the schema and it says:

  "$id": "https://www.first.org/cvss/cvss-v4.0.json?20240216",
// ...
      {
          "anyOf": [{
              "properties": {
                "threatScore" : {
                  "$ref": "#/definitions/noneScoreType"
                },
                "threatSeverity" : {
                  "$ref": "#/definitions/noneSeverityType"
                }
              }
            },
            {
              "properties": {
                "threatScore" : {
                  "$ref": "#/definitions/lowScoreType"
                },
                "threatSeverity" : {
                  "$ref": "#/definitions/lowSeverityType"
                }
              }
            },
            {
              "properties": {
                "threatScore" : {
                  "$ref": "#/definitions/mediumScoreType"
                },
                "threatSeverity" : {
                  "$ref": "#/definitions/mediumSeverityType"
                }
              }
            },
            {
              "properties": {
                "threatScore" : {
                  "$ref": "#/definitions/highScoreType"
                },
                "threatSeverity" : {
                  "$ref": "#/definitions/highSeverityType"
                }
              }
            },
            {
              "properties": {
                "threatScore" : {
                  "$ref": "#/definitions/criticalScoreType"
                },
                "threatSeverity" : {
                  "$ref": "#/definitions/criticalSeverityType"
                }
              }
            }
          ]
      },
      {
          "anyOf": [
              {
              "properties": {
                "environmentalScore" : {
                  "$ref": "#/definitions/noneScoreType"
                },
                "environmentalSeverity" : {
                  "$ref": "#/definitions/noneSeverityType"
                }
              }
            },
            {
              "properties": {
                "environmentalScore" : {
                  "$ref": "#/definitions/lowScoreType"
                },
                "environmentalSeverity" : {
                  "$ref": "#/definitions/lowSeverityType"
                }
              }
            },
            {
              "properties": {
                "environmentalScore" : {
                  "$ref": "#/definitions/mediumScoreType"
                },
                "environmentalSeverity" : {
                  "$ref": "#/definitions/mediumSeverityType"
                }
              }
            },
            {
              "properties": {
                "environmentalScore" : {
                  "$ref": "#/definitions/highScoreType"
                },
                "environmentalSeverity" : {
                  "$ref": "#/definitions/highSeverityType"
                }
              }
            },
            {
              "properties": {
                "environmentalScore" : {
                  "$ref": "#/definitions/criticalScoreType"
                },
                "environmentalSeverity" : {
                  "$ref": "#/definitions/criticalSeverityType"
                }
              }
            }
          ]
      }

If it's defined in the schema, there should be a way to compute them...

Another possibility is CSAF 2.1 should make it clear that CVSSv4.0 doesn't define threatScore and environmentalScore, and the test cases are about CVSS-B, CVSS-BT, CVSS-BE, and CVSS-BTE

I'm not sure whether I fully got that - maybe, we should have a call to discuss the topic.

fjscao commented 9 months ago

threatScore and environmentalScore are not defined in CVSSv4.0 spec. CVSSv4.0 schema inherits them from CVSSv3.1 schema, but they are not defined in v4.0. CVSSv4.0 SIG realizes this issue, but this issue is still under discussion and there is no conclusion yet.

tschmidtb51 commented 9 months ago

Add CVSSv4 to 6.1.9

and

The tyop of "_v3" should be replaced by "_v4" /vulnerabilities[]/scores[]/cvss_v4/threatScore /vulnerabilities[]/scores[]/cvss_v4/threatSeverity

I don't understand these comments. Could you please make them through a review in the current editor revision at: https://github.com/oasis-tcs/csaf/pull/699/files so that I know the right place? Thanks!

tschmidtb51 commented 9 months ago

threatScore and environmentalScore are not defined in CVSSv4.0 spec. CVSSv4.0 schema inherits them from CVSSv3.1 schema, but they are not defined in v4.0. CVSSv4.0 SIG realizes this issue, but this issue is still under discussion and there is no conclusion yet.

From a CVSS user perspective, I would love to have them. As they are currently defined in the schema, we need to keep them. Please keep us posted about the updates so that we can update CSAF accordingly

tschmidtb51 commented 9 months ago

"6.3.2 Use of CVSS v3.0" -> "6.3.x Use of CVSS v3.1"

I don't agree here. Yes, we want people to use the latest version - therefore, test 6.3.12 was added. However, I still think that we want to encourage people and tools to explicitly NOT use CVSS 3.0 - especially as you can only offer either v3.0 or v3.1. Also, the quick fix is easy to implement and an automatic upgrade is easily possible. (Changing a CVSS major version is not as easy - and most of us won't do that for old advisories.)

tschmidtb51 commented 9 months ago

"exploit_status" in CSAF: " this section can be a mirror image of "Exploitability" metric in CVSS v2.x, "exploitCodeMaturityType" in CVSS v3.x, and "exploitMaturityType" in CVSS v4.0.

@fjscao This has been addressed in #707

fjscao commented 2 months ago

The latest plan in First CVSS SIG is to keep the current v4.0 schema and make some changes in v4.1. There is no timeline for v4.1 yet.

oasis-tcs / csaf