Make IMPACT an explicitly required component of CVE entries

[EvansJonathan]

GOAL: Better data in CVE database - IMPACT data
CHANGE: Make IMPACT an explicitly required component of the CVE unless it is truly not known. Ideally the information should be specific (e.g. "code execution") but if not a more general (AIC impact) should be provided.
OUTCOME: Less "unknown impact CVEs"

[EvansJonathan]

[Manion 2017-07-11]
no, but prefer it, and give some guidance, such as, impact can be CVSS-like direct effect of exploiting vulnerability, and doesn't have to get into more risk-like real world impact.

[kurtseifried]

Do we need a CWE like project for impact? I'm serious here, I looked around for systems ot rate impact, they basically don't exist. I consider this out of scope for CVE, but it might be something MITRE/others ned to look into.

[david-waltermire]

We have some aspects of impact defined in the NIST Vulntology. It may be useful to do some gap analysis based on what is there to figure out what should be added. IMHO, this is preferable to starting a new effort.

[dadinolfi]

First, why would we want impact to be required? Impact or a measurement of risk does not give information relevant to determining if a vulnerability exists or is unique. CVE is about naming the vulnerabilities, not interpreting their subjective effects on the world.

Assuming impact is useful for determining uniqueness, though, impact is currently part of the JSON schema, and it includes CVSS as part of it. Without a standard or common language used around impact, making the field required at this time would lead to less-than-ideal results.

I propose we put this issue on hold until a standard is identified that could be used. If the community feels this is important, we can develop that standard (or refine the relevant content in the Vulntology) and make it required during the next CNA Rules revisions cycle.

Meanwhile, if a CVE submitter wants to include impact, they can do so via JSON. Ideally, since CVSS is there and is a standard, we will see an increased use of it by CNAs at the very least, which is another good thing for the greater community.

[EvansJonathan]

Impact is used to determine if an issue is a vulnerability (CNT2.2). However, if the vendor says it is a vulnerability (CNT2.1), it is not required.

[ghost]

@EvansJonathan I think we should require it as impact is a very useful piece of information to have to help categorize how bad the CVE is.

[EvansJonathan]

@kseifriedredhat that is true. However, CVE's mission is to provide IDs to vulnerabilities, not inform people how bad the vulnerability is. That is why NIST generates the CVSS vector instead of MITRE. If we choose to make CVE the source for information like this, then we will be changing the mission of the CVE program.

[ghost]

@EvansJonathan I'm not proposing that MITRE do the CVSS, I'm proposing that a CVE request requires impact info because we have far to many "unknown impact" CVEs that aren't super useful.

http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=%22unknown+impact%22

[dadinolfi]

From Art Manion:
Make IMPACT optional, it is very dependent on context and can be optionally covered in DESCRIPTION.

[ghost]

Can we make it something like "IMPACT is required in either a separate IMPACT field or as part of the description even if it is unknown or not completely understood". I really want to minimize the number of "unknown impact entries", but I also get that there is no good standard/language taxonomy for describing this officially.