OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

csaf message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [csaf] Switching to use the first.org JSON schemas for CVSS scoring - issue #1


The json you provided seems reasonable and has a better structure than if you converted the XML directly. I would expect anyoneÂusing this data is more likely to want to ask "What are the CVSS vectors for these products rather than what products are associated with this CVSS vector".

Lucas Tamagna-DarrÂ| Director of Engineering - Detection Automation
Tenable Network Security

ltamagnadarr@tenable.com




On Thu, Nov 14, 2019 at 11:28 PM Eric Johnson <eric@tibco.com> wrote:
I've gone ahead and tried changing the JSON schema for CSAF to reference the first.org representations for CVSS scoring. I've uncovered four design notes for discussion. This email discusses the first issue.

Please let me know if you have thoughts.

The first issue: Flipping the relationship between scores and lists of products.

Questions I have:
  • Any problems with flipping the representation of the data model inside out? The new approach uses sets of product ids as primary, and CVSS scores secondary, rather than the current structure (which mirrors the XML approach) which puts the scores as primary, and the sets of products as secondary.
  • Any problems with the fact that this change means that round trip conversion of JSON --> XML --> JSON will, in some cases yield a different, but semantically equivalent result.
CVRF and CSAF associate product identifiers with specific scores. In the XML representation, an example instance might look like this (note that this is a bogusÂexample snippet, I don't believe the scores are correct, for example):

    <CVSSScoreSets>
      <ScoreSetV2>
        <BaseScoreV2>6.6</BaseScoreV2>
        <TemporalScoreV2>6.7</TemporalScoreV2>
        <EnvironmentalScoreV2>6.2</EnvironmentalScoreV2>
        <VectorV2>AV:N/AC:L/Au:N/C:C/I:C/A:C/E:F/RL:OF/RC:C/CDP:N/TD:N/CR:ND/IR:ND/AR:ND</VectorV2>
        <ProductID>ProductA1</ProductID>
      </ScoreSetV2>
      <ScoreSetV3>
        <BaseScoreV3>6.6</BaseScoreV3>
        <TemporalScoreV3>6.7</TemporalScoreV3>
        <EnvironmentalScoreV3>6.2</EnvironmentalScoreV3>
        <VectorV3>CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N</VectorV3>
        <ProductID>ProductB1</ProductID>
      </ScoreSetV3>
    </CVSSScoreSets>

Critical point is simply this - note how the ProductID element is adjacent to the details of the CVSS scoring. In the above example, the V2.0 score is associated with ProductA1, and the V3.0 score is associated with ProductB1.

In the initial cut of the JSON representation, we preserved this structure. However, that does not work if we adopt the CVSS schemas. Using the CVSS schemas, we can no longer put the product IDs adjacent to the CVSS scoring information, because that portion of the schema is controlled by the first.org definitions. The products associated with the specific scores need to be in "objects" that wrap the specific scores. Here's the JSON example conversion of the above XML, using the new structure:

    "scores": [
      {
        "product_ids": [
          "ProductA1"
        ],
        "cvss_v20": {
          "version": "2.0",
          "baseScore": 6.6,
          "vectorString": "AV:N/AC:L/Au:N/C:C/I:C/A:C/E:F/RL:OF/RC:C/CDP:N/TD:N/CR:ND/IR:ND/AR:ND",
          "temporalScore": 6.7,
          "environmentalScore": 6.2
        }
      },
      {
        "product_ids": [
          "ProductB1"
        ],
        "cvss_v30": {
          "version": "3.0",
          "baseScore": 6.6,
          "vectorString": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N",
          "baseSeverity": "MEDIUM",
          "temporalScore": 6.7,
          "environmentalScore": 6.2
        }
      }
    ],

In the XML, a specific score (either V2 or V3) can be associated with an arbitrary list of products. In the JSON above, an arbitrary list of products is associated with CVSS scores - each of V2.0, V3.0, and V3.1 are allowed (cvss_v20, cvss_v30, and cvss_v31 are sibling properties. This turns the model inside out a little bit.

This shouldn't be problematic, but it is worth noting that it is then possible in some cases that a round-trip JSON --> XML --> JSON will not yield the same JSON. It will yield the same meaning (specific versions of specific CVSS scores associated with specific product IDs), but not the same JSON.

Why? Because the JSON structure is such that for a set of product ids, a CVSS V2.0, and V3.0 score can be assigned (a single object in the "scores" array). In the XML representation, this necessarily converts to a ScoreSetV2 and aÂScoreSetV3 entry in the XML. When converting these back, this will result in two objects under the "scores" array.

Also note as you may have inferred, adding CVSS3.1 scores was as simple as an additional property are supported in the proposed change to the JSON format. Obviously, those will not round-trip.

This new JSON representation for CSAF seems closer to an expected use case, as the natural use is to assign both a CVSS v2 and CVSS v3 score to a single set of products, not to associate a CVSS v2 score with one set of products, and a CVSS v3 score with another, as it is with the current CVRF XML format.

Eric.




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]