Adding Taxonomy object

[EvansJonathan]

General taxonomy object used to map CVEs to other taxonomies, like ATT&CK. Approved by QWG on 1/21/2021.

Example JSON:
“taxonomyMappings”: [
{
“taxonomyName”: “ATT&CK”,
“taxonomyVersion”: “7”,
“taxonomyRelations”: [
{
“taxonomyId”: “T1068”,
“relationshipName”: "Parent Tactic",
“relationshipValue”: “TA0004”
},
{
“taxonomyId”: “T1068”,
“relationshipName”: “CVE-to-ATT&CK Primary Impact”,
“relationshipValue”: “CVE-2019-15976”
}
]
}
]

[mprpic]

So are these mappings supposed to be universal to all types of taxonomies, including CWE? Because that sort of conflicts with the problemTypes object that include a cweId attribute. Or is this specific to ATT&CK? In which case maybe the naming should made that more explicit?

I know this was approved in the QWG but a bit more info about this would be appreciated for those that did not partake in those discussions.

[cve-team]

The object can be used for any taxonomy. ATT&CK was the original impetus, but the QWG did not want to have to create a new object for every taxonomy a CNA might want to include in a CVE record so it was made generic. For example, you could use it to map to the OWASP Top Ten.

You can also use it to describe relationships between taxonomy items related to the CVE. For example, if you wanted describe the chain of CWEs in the vulnerability.

[mprpic]

The object can be used for any taxonomy. ATT&CK was the original impetus, but the QWG did not want to have to create a new object for every taxonomy a CNA might want to include in a CVE record so it was made generic. For example, you could use it to map to the OWASP Top Ten.

Ok, I understand the need for a general object but that doesn't answer my question about potentially duplicating CWE information between problemTypes and taxonomyMappings. The problemTypes.type even mentions OWASP:

"description": "problemtype source, text, OWASP, CWE, etc",

I can also imagine someone may start including CVSS scores in taxonomyMappings, completely circumventing the existing CVSS-related attributes.

You can also use it to describe relationships between taxonomy items related to the CVE. For example, if you wanted describe the chain of CWEs in the vulnerability.

I don't really see the upside of parsing a CWE chain into its components. In 99% of cases you will just want to display it as is. And in those 1% of research-oriented cases where you want to process the individual components for statistics purposes, parsing the chain is trivial. But I guess we'll be forced to use this mapping object since when I look at cweId, it has a restrictive pattern that would prevent specifying a chain:

"pattern": "^CWE-[0-9]+$"

[chandanbn]

I can also imagine someone may start including CVSS scores in taxonomyMappings, completely circumventing the existing CVSS-related attributes.

This was discussed and a CVSS vector string can be seen as an uniq identifier (and pointer to scores in metrics section) so it does allow use of CVSS scores, and that is OK.

[david-waltermire]

It would be good to flatten the inline definitions for taxonomyRelations items. We should also consider adding maxLength limits on the string fields. This should be done before accepting this PR.

[chandanbn]

maxLength = 128

[chandanbn]

maxLength = 128

[chandanbn]

maxLength = 2k

[chandanbn]

maxLength=128

[chandanbn]

maxLength = 2k

[chandanbn]

re-arrange description

[david-waltermire]

Please add the maxLengths.

[tcullum-rh]

@EvansJonathan @chandanbn

Where will this be referenced? In the meeting I think we discussed that this could be used for CVSS scores and CWE for example (although we already have those elsewhere as @mprpic mentioned), but we also talked about being able to provide product-specific CVSS scores. Currently, nothing maps the CVSS score in the metrics array to a product, and it's unclear how this taxonomyObject will do that either without any referenced location in the schema. The metrics object is just referenced in the CNA and ADP containers.

[chandanbn]

@EvansJonathan @chandanbn

Where will this be referenced? In the meeting I think we discussed that this could be used for CVSS scores and CWE for example (although we already have those elsewhere as @mprpic mentioned), but we also talked about being able to provide product-specific CVSS scores. Currently, nothing maps the CVSS score in the metrics array to a product, and it's unclear how this taxonomyObject will do that either without any referenced location in the schema. The metrics object is just referenced in the CNA and ADP containers.

@tcullum-rh a CVSS metric string can be seen as a unique identifier in the domain of CVSS scores, so this is an example of one way to map CVSS to CPEs:

"taxonomyMappings": [
    {
        "taxonomyName": "CVSS",
        "taxonomyVersion": "3.1",
        "taxonomyRelations": [
            {
                "taxonomyId": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H",
                "relationshipName": "applies-to-CPE",
                "relationshipValue": "cpe:2.3:a:redhat:hornetq:2.0.0:cr2:*:*:*:*:*:*"
            },
            {
                "taxonomyId": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:L",
                "relationshipName": "applies-to-CPE",
                "relationshipValue": "cpe:2.3:a:redhat:hornetq:3.0.0:cr1:*:*:*:*:*:*"
            }
        ]
    }
]

The CVSS metrics used as taxonomyId can also be seen as a pointers to the CVSS scores and scenario in the metrics object that provide more verbose context for the score.