Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Define how to handle overlapping assignments #47

Open
EvansJonathan opened this issue Jul 28, 2017 · 6 comments
Open

Define how to handle overlapping assignments #47

EvansJonathan opened this issue Jul 28, 2017 · 6 comments

Comments

@EvansJonathan
Copy link
Contributor

GOAL: Document and standardized CNA processes
CHANGE: Fill the gap in the Process to Correct Counting Issues (Appendix E) of how to handle overlapping assignments. For example when one CVE ID is assigned to cover parameter a, b, and c and another is assigned to cover parameter b, c, and d.
OUTCOME: CNAs will know how to handle these situations.

@kurtseifried
Copy link

Can you clarify this, is this a counting issue, e.g. same CNA assigned both, or a duplicate CVE assignment issue (different CNAs), or something else?

@EvansJonathan
Copy link
Contributor Author

@david-waltermire
Copy link

I believe we need to expand the scope of the outcome here, since it is likely that such a problem will be found by a downstream (e.g., NVD, end-user, tool vendor). The identifier of the problem must be able to figure out what to do, who to contact, what mechanism(s) are to be used for communication. Secondly, the assigning parties need a way to become aware of the issue. And lastly, there needs to be a way to either pick a winner (e.g., first assigner) and deprecate the other, or to create a new CVE record which will result in the original duplicates being deprecated.

@dadinolfi
Copy link
Contributor

dadinolfi commented Sep 25, 2017

As per Appendix E, the process for resolving duplicates is:


  1. PREFER THE MOST COMMONLY REFERENCED IDENTIFIER. This is roughly gauged by searching for all affected identifiers on a search engine and comparing results.
  2. If the usage numbers of identifiers are about the same, then CHOOSE THE IDENTIFIER USED BY THE MOST AUTHORITATIVE SOURCE. The "most authoritative source" is roughly prioritized as: vendor, coordinator, researcher.
  3. If the identifiers have the same level of authority, then CHOOSE THE IDENTIFIER THAT HAS BEEN PUBLIC FOR THE LONGEST PERIOD OF TIME.
  4. If the identifiers have been public for the same amount of time, then CHOOSE THE IDENTIFIER WITH THE SMALLEST NUMERIC PORTION.
    Note that the process described above is reserved for cases where the CVE IDs have clearly been assigned to the same vulnerability. If there is insufficient information to decide, the description of the CVE entries may be changed to indicate that they may be the same. For example, a NOTE sentence such as "This may be the same as " or "This may overlap " may be used.

For cases where there is overlap, we can use a similar process to determine which ID to be the winner, and then add language to explain how to reword the descriptions to clarify which covers which vulnerabilities, such as "This CVE ID may overlap...". I suggest we add this additional case to Appendix E.

The communication issue @david-waltermire-nist mentioned is something we will address separately, as we discussed in the last Strategic Planning WG meeting and Board meeting.

@ghost
Copy link

ghost commented Sep 26, 2017

What @dadinolfi said, also whoever gets it into the MITRE database first (and thus probably wins the above tests) should be used.

@dadinolfi
Copy link
Contributor

dadinolfi commented Sep 28, 2017

Suggestion: Add a section to Appendix E to cover the special case of partial duplicates (the overlap case).

There are cases where two CVE IDs overlap in what software or hardware is affected by the same vulnerabilities. An example of this would be if CVE-2017-nnnn1 references Product1 versions 1.0, 2.0, and 3.0 and CVE-2017-nnnn2 is assigned to the same vulnerability and references Product1 versions 3.0, 4.0, and 5.0. In this situation, use the following process.

  1. PREFER THE MOST COMMONLY REFERENCED IDENTIFIER. This is roughly gauged by searching for all affected identifiers on a search engine and comparing results. In our example above, CVE-2017-nnnn1 is used more often than CVE-2017-nnnn2. Therefore, CVE-2017-nnnn1 would reference versions 1.0, 2.0, and 3.0, and CVE-2017-nnnn2 would be changed to only reference versions 4.0 and 5.0. In both CVE entries, a note should be added to the effect "This CVE entry is related to [the other]."

  2. If the usage numbers of identifiers are about the same, then CHOOSE THE IDENTIFIER USED BY THE MOST AUTHORITATIVE SOURCE. The "most authoritative source" is roughly prioritized as: vendor, coordinator, researcher. Again, if CVE-2017-nnnn1 is used by the most authoritative source, CVE-2017-nnnn1 would reference versions 1.0, 2.0, and 3.0, and CVE-2017-nnnn2 would be changed to only reference versions 4.0 and 5.0. In both CVE entries, a note should be added to the effect "This CVE entry is related to [the other]."

  3. If the identifiers have the same level of authority, then CHOOSE THE IDENTIFIER THAT HAS BEEN PUBLIC FOR THE LONGEST PERIOD OF TIME. Again, if CVE-2017-nnnn1 has been public for the longest period, CVE-2017-nnnn1 would reference versions 1.0, 2.0, and 3.0, and CVE-2017-nnnn2 would be changed to only reference versions 4.0 and 5.0. In both CVE entries, a note should be added to the effect "This CVE entry is related to [the other]."

  4. If the identifiers have been public for the same amount of time, then CHOOSE THE IDENTIFIER WITH THE SMALLEST NUMERIC PORTION. Since CVE-2017-nnnn1 uses a smaller numeric portion, CVE-2017-nnnn1 would reference versions 1.0, 2.0, and 3.0, and CVE-2017-nnnn2 would be changed to only reference versions 4.0 and 5.0. In both CVE entries, a note should be added to the effect "This CVE entry is related to [the other]."

  5. If there are any disputes after this, CHOOSE THE IDENTIFIER THAT WAS POPULATED IN THE CVE LIST THE EARLIEST. Assuming CVE-2017-nnnn1 was populated earliest, CVE-2017-nnnn1 would reference versions 1.0, 2.0, and 3.0, and CVE-2017-nnnn2 would be changed to only reference versions 4.0 and 5.0. In both CVE entries, a note should be added to the effect "This CVE entry is related to [the other]."

Note that the process described above is reserved for cases where the CVE IDs have clearly been assigned to the same vulnerability. If there is insufficient information to decide, the description of the CVE entries may be changed to indicate that they may be the same. For example, a NOTE sentence such as "This may be the same as " or "This may overlap " may be used.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants