What remediation information should be included in a CVE Record?

[ccoffin]

The CVE Survey respondents signaled that remediation information was very important in CVE Records. What kinds of remediation information should be included within a CVE Record?

[ElectricNroff]

The CNA Published container and the ADP container could be extended to have a new remediation-related property, with a few properties under this where information could (for example) be entered as an array of string values from an enum.

An alternative approach is that the producer would simply add a "patch" tag to the reference URL that is associated with the patch. Or maybe it's the reference URL that is associated with the vendor advisory. For example, https://cnascorecard.org/scoring.html says "including direct links to official patches or vendor advisories, rather than generic references or third-party discussions." However, for a large set of Supplier CNAs, consumers already know how to do updates. A customer relationship in which the method for updating has to be re-explained (through a link) for each instance of a required patch seems burdensome and antiquated. In many situations, that knowledge is best captured elsewhere, e.g., there is a uniform method of updating across an entire software ecosystem, or the update steps for each specific customer are automatically generated on an individualized basis within a customer portal.

For this proposed approach, here is a very preliminary list of possible string values that would be allowed (keep in mind that the actual enum strings would almost certainly not be these long sentences). Also, it is likely that not all data would be enum strings; for example, there could be a number associated with the amount of downtime while an update is deployed.

Remediation familiarity:
enum of:

• "It is sufficient to perform an update in the manner that is typical for this software ecosystem"
• "Consumers are expected to know how to navigate a customer portal to determine the appropriate options for updating"
• "This is an unusual situation in which a consumer must also manually uninstall older versions"
• "This is an unusual situation in which a consumer must also perform manual restarts after updating"
• "This is an unusual situation in which a consumer must also perform manual cleanup of artifacts left behind by older versions"
• "There is novel update guidance, and consumers must read the Supplier's content in the References section"

Remediation viability:
enum of:

• "The Supplier expressed an intention, through version numbering or other means, that updating keeps compatibility with previously working use cases"
• "The only available updated version contains various other fixes that may, in unusual situations, disrupt some use cases of the Product"
• "Little is known about whether the available update will resolve more problems than it adds"
• "Many enterprise customers will need to bring in consultants to advise on how to implement the updated version in their environment"
• "This is an unusual situation in which a library Product must be updated but all callers must also be updated"
• "This is an unusual situation in which a server Product must be updated but all clients must also be updated"

Remediation complications:
enum of:

• "Most enterprise customers will need to schedule an application outage window before updating"
• "Most enterprise customers will need to plan for User Acceptance Testing before deploying the update to production"
• "This is an unusual situation in which the update cannot be rolled back in any supported manner"
• "Many customers will be unable to install the updated version without also doing version updates of dependencies"
• "Although one could update to a fixed version, this realistically opens up the dependency graph to malicious packages, so many customers will just skip it"
• "Many customers will not be able to install and run the updated version because it has not been certified by a regulatory authority"
• "Although an update can be installed if already downloaded, the Supplier has chosen to withdraw it because of adverse customer experiences"

Remediation alternatives:
enum of:

• "Many customers perceive that the workaround, stated in the CVE Record, is preferable to the update, and they are correct"
• "Many customers perceive that the workaround, stated in the CVE Record, is preferable to the update, but they are sadly mistaken"
• "In a typical environment, the update will be installed automatically, but it is straightforward to block that"
• "In a typical environment, the update will be installed automatically, and blocking that requires reverse engineering expertise"
• "The update has licensing or payment implications that may warrant investigating alternative Products"

[darakian]

Can you express what this might look like in json? Also, mitigation advice is probably better left for a mitigation specific area.

[ElectricNroff]

Can you express what this might look like in json? Also, mitigation advice is probably better left for a mitigation specific area.

Currently, an array of enum strings is used for tags, e.g., /containers/cna/tags can be

"tags": [
        "unsupported-when-assigned",
        "exclusively-hosted-service"
      ]

This could be similar except that there would perhaps be at least four, e.g.,

"newRemediationProperty": {
           "familiarity": ["manuallyUninstall", "manuallyRestart"],
           "viability": ["updateNotCompatible"],
           "complications": ["userAcceptanceTesting"],
           "alternatives": ["workaroundSufficient"]
}

and a mitigation specific area is a good option as well.

[darakian]

Gotcha. I think it would be good to have some paved paths for the things we think are common and not implicit from the rest of the record (eg. move off a known bad version). Using your style I think that might be something like a

"configChange": url-that-provides-instructions-and-or-a-diff
"envChange": url-that-provides-instructions-and-or-a-diff

These could also be reference tags as well which might be a simpler approach. Not sure.

[darakian]

Remediation advice/guidance should be product specific right? If so would this be an extension to the affected array?

[ElectricNroff]

Remediation advice/guidance should be product specific right? If so would this be an extension to the affected array?

Possibly, although - because it's uncommon for a CVE Record to cover multiple products that have disparate update stories - it could live outside of affected and the disparate case would force the "There is novel update guidance, and consumers must read the Supplier's content in the References section" value, e.g.,

"newRemediationProperty": {
           "familiarity": ["itsComplicated"],
            ...

[darakian]

Ok, from the QWG meeting today; yes advice is product specific but also we have the solutions array which is likely the best place to make these changes in the short term. So, no this isn't an extension to the affected array, but we should have a way to indicate what product a given solution/remediation applies to.

cve-schema/schema/CVE_Record_Format.json

Lines 1074 to 1082 in ce5f5c8

	"solutions": {
	"type": "array",
	"description": "Information about solutions or remediations available for this vulnerability.",
	"minItems": 1,
	"uniqueItems": true,
	"items": {
	"$ref": "#/definitions/description"
	}
	},

[boblord]

We might want to see how to define some terms, and how to group them together. One possible way to group the ideas:

Tier 1 (Eliminate) ──► Patch / Replace
Tier 2 (Contain) ──► Disable Feature / Config Change / Enable Control
Tier 3 (Defend) ──► Network Restriction / Workaround / Compensating Control
Tier 4 (Acknowledge) ──► Rollback / No Fix

I wonder if defenders would benefit from information like this to inform their remediation efforts. For some, Defend might be the most cost effective mitigation, while others can apply security updates (Eliminate) more easily.

[darakian]

Questions that arose from today's QWG; if we take as an assumption that just do a dang update is implicit, tooling can inform a user if their version is in a known vulnerable range and we don't want to repeat ourselves by having a just do a dang update remediation tag/array item/whatever then what is a remediation? Is it meaningful to differentiate remediations from workarounds? It might be a semantic argument to say a config change is one or the other and ultimately fruitless to come to a conclusion there. One path which would simplify the schema and cve processing could be to merge the solutions and workarounds arrays to be something like routes to address the vuln which are not doing a dang update.

Hard questions for the group

1. Do we consider just do a dang update an implicit remediation?
2. Does the idea of merging the solutions and workarounds arrays seem like a workable schema simplification?