SSVC data/scores into CVE JSON as an Authorized Data Provider

[sei-vsarvepalli]

Today I met with @madcatter24 and @zmanion on this topic. @madcatter24 and @zmanion have been meeting CVE working group to support our work of publishing SSVC data into CVE JSON. CVE JSON 5.13 schema has some information on the "adpcontainer" - which is where we can put SSVC Computed data in JSON format.

https://github.com/CVEProject/automation-working-group/blob/d7a9b420bb7842ca5655c44506439c9ce780cf31/cve_json_schema/v5.x_discuss/cve513.schema#L477

An ADP Authorized Data Publisher (ADP) id defined as
"An organization authorized within the CVE Program to enrich a CVE Record previously published by a CNA with additional, related information (e.g., risk scores, affected product lists, and versions [i.e., references, translations]) within a defined Scope." from https://cve.mitre.org/about/terminology.html

In the engineering sense, NVD plans to have a service called ESUS that will help ADP providers push their ADPContainer data into NVD CVE. NIST could possibly make this data available to the larger community for consumption and usage.

At this time, CERT/CC would like to support a minimalist information in ADP compatible format into CVE JSON. In discussions with @zmanion , it looks like the current Computed Schema may be too much information to provide into CVE as an ADP. It is preferred that we provide only the following

1. Timestamp
2. CVE-ID
3. Partial-Tree Computed

It will be good for @j--- to decide if this should be accomplished in this phase or not? Inputs from @ahouseholder will also be crucial. I am happy to develop the said JSON plugin into CVE and do spec out engineering effort to integrate to NVD ESUS possibly from VINCE.

Vijay

[zmanion]

I think the timing for this issue is disconnected from the timing for the v2 paper (other than we'd probably implement what v2 says unless we end up with a custom tree and inputs, which I hope is unlikely).

In current SSVC schema terms, I think we want to provide a computed schema with Exploitation, Technical Impact, and Utility. Almost always Exploitation, possibly the other two (i.e., not even always all three decision points).

I was going to suggest not providing a partial tree, but I guess see no reason not to, it might help someone quickly get close to their decision.

[zmanion]

I find "computed" and "provision" non-intuitive, but I might just be new to the terms. The descriptions in the JSON are confusing also.

https://github.com/CERTCC/SSVC/tree/main/data/schema

I was about to suggest changes but think we should discuss first. I talked to @sei-vsarvepalli briefly but still don't understand the need/use for two schemas.

"$id": "https://democert.org/ssvc/SVC_Computed_v2.01.schema.json",
"title": "Computed SSVC score representing the path in the decision tree",
"description": "This schema represents the full path in the decision tree taken by an analyst with a specific role.  The representation of the full decision tree is optional",

"$id": "https://democert.org/ssvc/SSVC_Provision_v2.01.schema.json",
"title": "Decision tree schema definition for SSVC",
"description": "This provides a schema for a decision tree used to compute SSVC score for a vulnerability",

[j---]

New terms may make sense, or are worth discussion.

The reason there are two is this: one is for a fully specified decision tree, which essentially defines an organization's risk posture. The other is for communicating specific values of decision points about a specific vulnerability or work item. Communicating about a vul may be between stakeholder groups (coordinator to deployers, for example) and so does not even have to contain a decision.

"Provision" currently is the first (tree spec). "Computed" currently is the second (information about a vul / work item).

[j---]

Does "Partial-Tree Computed" mean the answers to some decision points?
The reason it's important to say "answer to some decision points" instead is that when communicating across stakeholder groups, there will certainly be different relevant trees. So while it's partial information for computing a tree, it is not a partial computation of some specific tree. Because there will be multiple relevant trees, each for a relevant stakeholder, and we don't need to know the tree in detail to provide some useful information to everyone (in the form of answers to some decision points).

[ahouseholder]

Converted to discussion from issue as there's no clear task yet.

[sei-vsarvepalli]

Related issue being tracked at CVE Project CVEProject/cve-schema#144 (comment)

[j---]

@sei-vsarvepalli , are you able to put together a task list of how the SSVC schema definition would have to change in order to be compatible with the CVE ADP requirements? Perhaps requirements is the wrong word, but how the SSVC json schema needs to change so that the CVE JSON schema / ADP expectations don't have to change? Such as the $ syntax.

From the ADP design perspective, are there objections / barriers to having each decision point (for example, Technical Impact or State of Exploitation) and the value for it as the ADP entry? I would like to avoid trying to represent whole decision trees in the ADP, as I would envision the goal to be to share what information a party knows about a vul with SSVC, not to share the decision the party took about the vul.

[sei-vsarvepalli]

Hello @j---

Currently CVE ADP is currently almost an open book, a lot to be learnt and figured out soon after we start the ADP pilot. CERTCC is going to take part in the development. We should be able to resolve this in the test environment, hopefully by July 1st week. There is very small schema tweaks needed at this time, just plan to do them all at the same time. I will come back to this as a list once the details are clear.

Thanks
Vijay

[sei-vsarvepalli]

Hello @j--- @zmanion

We successfully published an ADP container with SSVC scores in the CVE Test instance. The work of coding it into Dryad (SSVC Calculator) and cveClient is also to be done and pushed hopefully by end of the month.

For a sample of a proper SSVC record in CVE as an ADP, you can see https://cveawg-test.mitre.org/api/cve/CVE-2023-0032 as the example. Let me know if you have any questions. The sample schema we have works okay. The "metrics" is an array and you can append multiple SSVC records into this as an array. SSVC records with the identical "role" field will be inserted in sorted by time order descending.

Thanks
Vijay

[j---]

What other open projects do we need to be tracking integration with? Is there an issue tracker for CVE that we should be linking with?

[sei-vsarvepalli]

For production changes to CVE - wait for the AWG release of CVE-Services 2.1 that is being tracked at CVEProject/cve-services#1063 - notice that this ADP capability is already available and active in the Test environment of CVE Services.

As far as the schema - although there is ongoing version discussion in #289 in progress. The SSVC ADP representation can be unchanged. The recommended Computed schema https://github.com/CERTCC/SSVC/blob/main/data/schema/SSVC_Computed.schema.json can be used as is. The versioning discussion only impacts the Provisioning schema.

Currently required elements by the schema has the version which is more of the SSVC version itself. The Decision Tree, Decision Options and the Decision Values can all be represented without an issue as they will always carry unique labels/keys combination.

    "required": [
	"options",
	"timestamp",
	"role",
	"id",
	"version"
    ]