Re: [csaf] Item: Various possible enhancements to the JSON format for representing vulnerabilities

[Eric Johnson <eric@tibco.com>]

Hi Omar,

On Tue, Aug 27, 2019 at 5:55 PM Omar Santos (osantos) <osantos@cisco.com> wrote:

Thank you, Eric! Some minor comments inline:

On Aug 27, 2019, at 8:28 PM, Eric Johnson <eric@tibco.com> wrote:

Hi CSAF-TC,

In working on the JSON format, I've observed the following possible areas of enhancement:

- Drop "ordinal" from JSON output - this field adds no value to the serialized output, that I can tell. I am planning to update the export logic of the conversion tool to automatically supply ordinals for the XML format, which made me think they should just be dropped from the JSON.

I agree that the âordinalâ provides no value and should be dropped.Â

I will implement the dropping of the ordinal.

Tracking this asÂhttps://github.com/oasis-tcs/csaf/issues/17

- use JSON schema for CVSS? Omar suggested this in an email on May 15. Seems like it might be a good ideaâ

To provide additional references to the TC. The following is the CVSS JSON schema:

https://www.first.org/cvss/data-representations

And previous GitHub issueÂhttps://github.com/oasis-tcs/csaf/issues/9

If the TC decides that we should incorporate that enhancement, I will reopen the issue and trackÂ

We should vote on this tomorrow. I believe we discussed this in a previous meeting, but I do not recall that we voted on closing it.

Based on the meeting minutes from May 29, it appears that we did not actually vote to close it, we just wanted focus on as-little-work-as-posssible to map from CVRF.

It seems like it is probably a good idea to adopt standards that exist, especially since they are available, and we haven't published yet. This leads me to reconsider my previous position. Note that the same question arises when dealing with CVSSv3.1

Â

- Change CVSSScoreSets to just "Scoring" in JSON, with children for v3.0 v3.1, etc.

We should probably at least make a reference to CVSS (e.g., CVSSScore); not to confuse it with a proprietary score. If we decide to incorporate the JSON schema from CVSS, we should at least support the minimal (version, vectorString, baseScore, baseSeverity):

The current JSON schema expects instances that look like this:

"cvss_score_sets" : {

 "score_set_v3": { ... },

 "score_set_v2": { ... }

}

I'm proposing:

"scores": {

 "cvss_v3_0": { ... },

 "cvss_v3_1": { ... },

 "cvss_v2_0": { ... },

}

In XML Schema, we're stuck with only the representations we define. With JSON schema, any additional scoring mechanisms could be simply added by a tool that supports it. For example "cvss_v3_2", or "cvss_v4_0", or for that matter "tvs_v_1" (TIBCO Vulnerability Score, if such a thing existed) or "cvi_v_2" (Cisco Vulnerabilty Information, if such a thing existed).

That's why I propose renaming it from "cvss_score_sets" to just "scores" - it allows for more natural extensibility to non-CVSS scoring.

Â

{
    "version": "3.1",
    "vectorString": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
    "baseScore": 7.8,
    "baseSeverity": "HIGH"
}

- Why does Relationship include a _list_ of products? I believe it should just be one. Anyone know differently?

They can be more than one product. In the past, we had the examples of Microsoft Office products, where MS Word can be associated to Office365, standalone, traditional Office, etcâ. Also open source components can be bundled with different distributions. For instance, libABC included in RHEL, Canonical (Ubuntu), Debian, etc.. It may be that a vulnerability in libABC may only affect Ubuntu and Debian, but does not affect RHEL (or vice versa) Âbecause they way it was implemented. This is why we had the following in CVRF 1.2 and earlier:

Default Component Of

External Component Of

Installed On

Installed With

Optional Component Of

I think I didn't ask my question explicitly enough. Example XML of a relationship definition:

    <Relationship ProductReference="ProductA2" RelationType="Installed On" RelatesToProductReference="ProductA1">
      <FullProductName ProductID="ProductA1+A2" CPE="cpe:/a:foo:bar:blah:oo:xx">Product A-1+A-2</FullProductName>
    </Relationship>

In this case "ProductA1+A2" is the thing that is ProductA2 "Installed On" ProductA1". That's fine. Except that the schema allows for multipleÂ"FullProductName" child elements (minOccurs = 1, maxOccurs = "unbounded"). However, those additional FullProductName element instances can only be just another name for "ProductA2" Installed on "ProductA1", based on how Relationship is defined. That just seems like extra complexity.

The scenarios you've outlined above would be additional Relationship elements, all with just a single FullProductName underneath them.

To restate my original question much more concretely, why is "FullProductName", as a child of the Relationship element, allowed "maxOccurs" value of "unbounded", instead of "1"?

Eric.

Thanks again!

Omar

Eric.