OASIS Common Security Advisory Framework (CSAF) TC

 View Only
  • 1.  Switching to use the first.org JSON schemas for CVSS scoring - issue #1

    Posted 11-15-2019 07:21
    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.


  • 2.  Re: Switching to use the first.org JSON schemas for CVSS scoring - issue #1

    Posted 11-18-2019 21:14
    For completeness, I've created a pull request for the first.org CVSS JSON schemas. https://github.com/oasis-tcs/csaf/pull/21 ... in case people want to see the concrete details. Omar - perhaps refrain from merging the pull request until after others have had a chance to chime in on the various points I raised. Eric. Eric. On Thu, Nov 14, 2019 at 11:20 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.


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

    Posted 11-18-2019 23:26
    I really like the idea of referencing the FIRST schema the way you represented it: "cvss_v31": { "$ref": " https://www.first.org/cvss/cvss-v3.1.json " It is simple and allows for easy implementation. Regards, Omar Santos Cisco PSIRT Email: os@cisco.com Phone: 919 476 6152 PGP: https://keybase.io/santosomar On Nov 18, 2019, at 4:13 PM, Eric Johnson < eric@tibco.com > wrote: For completeness, I've created a pull request for the first.org CVSS JSON schemas. https://github.com/oasis-tcs/csaf/pull/21 ... in case people want to see the concrete details. Omar - perhaps refrain from merging the pull request until after others have had a chance to chime in on the various points I raised. Eric. Eric. On Thu, Nov 14, 2019 at 11:20 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.


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

    Posted 11-18-2019 21:21
    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.