Proposal to add CVSS/scoring to Vulnerability

[jmgnc]

Add the property: score (option): scoring-object : Describe the score for the Vulnerability

The scoring-object would have the following properties: standard (required) : scoring-standard-ov : an open vocab describing the scoring system used. Initially would contain "cvss v3.1" score (required): float : A value that is scaled from the native scoring system to [ 0, 10 ] (inclusive). If the standard score does not follow the range then it should be mapped in some way. standard_score_float (optional): float : If the standard score uses a number, this is used, and is used to represent the native score. standard_score_str (optional): string : If the standard score uses a string, this is used, and is used to represent the native score.

Additional properties may be defined based upon the standard. CVSS v3.1 has additional score parts, such as attack-vector.

[JasonKeirstead]

The Vulnerability object exists mainly in order to reference an external vulnerability (such as the CVE, which will have the score). Why clone this specific field vs all the others? Also not all vuln systems use CVSS so it would be problematic to include CVSS specific fields.

[jordan2175]

This is a new feature and probably should be done in a future version of STIX or as an extension.

[CyberDaedalus00]

During the review and prototyping of STIX Extensions, this specific use case was explored. In line with Jason's comment, we prototyped the addition of CVSS scoring by leveraging the JSON schema defined by FIRST as an extension to address this since not everyone may want the scoring data.

[allant0]

Future version. I would ask that its not just a single score but you have to identify the version of CVSS you are using too. There are common implementations out there on older versions of CVSS so you can't just add a prop. Regardless this is a material change and should be deferred to a future release.

[allant0]

I would also state that vulnerability is a useful feature without CVSS score being included and there are multiple dimensions of scoring that are not reflected in CVSS. So I would argue that if we are introducing CVSS it should be its own object that helps provide the context that goes into a CVSS score not just the score itself. And therefore maybe there should be a CVSS scoring object that contains all the meta data supporting the score and then its a relationship rather than just a property of a vulnerability. All in all I think there are enough reasons why this needs to be more considered than just adding a property.

[rpiazza]

Leaving the issue of the usefulness of CVSS aside, I wanted to make a more general comment about what properties should be included in a STIX object. The idea behind STIX is a standard language for transmit CTI over the wire. It is not an ontology or data model for cyber threat intelligence - although it shares some of the same purposes. That being said, STIX should support the most efficient exchange of information. I'm not against adding CVSS scores to the Vulnerability object, and it is probably a good addition for non-CVE vulnerabilities.

However, it makes no sense to pass around this information since it is easily available via this API: https://csrc.nist.gov/CSRC/media/Projects/National-Vulnerability-Database/documents/web%20service%20documentation/Automation%20Support%20for%20CVE%20Retrieval.pdf

In fact, the recently introduced STIX common object repository (https://github.com/oasis-open/cti-stix-common-objects) includes a vulnerability object for every published CVE, and is refreshed every night. There is no reason to ever transmit a vulnerability object based in a CVE-related vulnerability, since all consumers could be aware of the UUID for the CVE of interest. Just use the established ID.

The same can be said for ATT&CK attack patterns, etc.

Of course, people are free to do anything they want - including adding an extension to Vulnerability object...