The CVE List cannot be the first point of publication for any information. #26
Comments
|
What is the "CVE List"? I assume CVE database? All CVE's already require a working reference URL, so by definition this is already covered, or? |
|
Just because there is a URL does not mean that all of the information in the CVE entry is also in the URL. For example, the entry for CVE-2016-10392 was published with a URL, but the URL says nothing about CVE-2016-10392. CVE-2016-10392 is the most extreme example. We have had other instances where the URL does talk about the vulnerability, but the description submitted to MITRE has additional details, e.g. affected component. All of these are technically valid under the current CNA rules. |
|
While we can set a guideline to be transparent in this way, I don't see a reasonable way to enforce a requirement for all information in a CVE entry is covered by the resource pointed to by a URL. If we cannot enforce a requirement without significant human resource costs, we may not want to have it as a requirement. This is even more difficult when we deal with 3rd party information in the CVE. Does this information also need to follow this rule? If so, how is that requirement enforced? At what cost? Instead, we may want to express this concept as part of a set of goals for a CVE entry and allow the community and market to drive behavior if these goals are valued. |
|
Proactive enforcement of the rule would certainly slow down the submission process and make automation impossible. However, making this a rule allows us to require a CNA to update their entry with a useful reference when someone points out that the reference does not match the entry. Guidelines don't give you that level of authority. |
|
True, although in a voluntary system, you can ONLY make a volunteering party do something they actually WANT to do. The same cannot be said for something the volunteer DOESN”T want to do.
My point is we should focus on rules that add value, are automatically enforceable, and that align with positive incentives. I don’t like punitive requirements, because we cannot make a volunteer do something they don’t want to do in the first place. We can point out a mistake or oversight, but the issue will only get fixed if they want to fix it. From this perspective a guideline or set of best practices are just as good if they align with positive incentives that the volunteer CNA cares about.
From: Jonathan Evans [mailto:[email protected]]
Sent: Tuesday, August 29, 2017 3:35 PM
To: CVEProject/docs <[email protected]>
Cc: Waltermire, David A. (Fed) <[email protected]>; Comment <[email protected]>
Subject: Re: [CVEProject/docs] The CVE List cannot be the first point of publication for any information. (#26)
Making this a rule allows us to require a CNA to update their entry with a useful reference when someone points out that the reference does not match the entry. Guidelines don't give you that level of authority.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub<#26 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AJaiaIcdJ4xbXHLDtO1WVQPzSMuA3Lijks5sdGf2gaJpZM4OkDF6>.
|
|
I am not sure what such a rule would look like. As far as I can tell, none of our current rules do, include the rule not to assign multiple CVE IDs to the same vulnerability. Could you provide an example rule that meets your criteria? |
|
Including provenance (an external point of reference for the vuln info/disclosure) has been a cornerstone of CVE for 90% of its time. Changing to allow CVE to become the point of disclosure may be an option, but if so, should have some flag or indication that is the case. Further, this is potentially problematic because external provenance typically gives people a way to contact the researcher in case there are questions or disputes on the disclosure. This change means that MITRE would be receiving those mails and having to mediate or do virtual introductions, provided they are willing to give up the reporting party contact information. |
|
@attritionorg this is one reason I require a working (at least long enough to agree to the CVE ToU) email associated with DWF assignments. |
|
@kseifriedredhat good in theory, but when they don't answer those emails? that has happened with a few DWF requesters I have contacted for clarity and provenance already. |
|
Generally speaking, one thing I don't think most of the Board is aware of is the recent shift in how CVEs are perceived among many 'researchers'. The number of cases where people are using them on their LinkedIn profiles and resumes is growing; more specifically, they are using reserved CVE IDs. It doesn't matter what the vuln is or if it is open, it comes across as them finding legitimate vulns. Hiring managers see the CVE IDs and assume the same thing. There is now a false equivalency between having a CVE ID and it also meaning that it a valid vulnerability approved by the CVE entity. In one case I tried to track down, the reservations were from 2014 and the researcher had not published details despite saying the vendor fixed the issues, and little interest in publishing after I contacted him. |
|
That's not a false equivalency, that's how it used to be (CAN -> CVE), then that went but CVE's were still verified to some degree, now we have a claims based system, but I've not meet a single person that knew about it yet. The one thing we have is publishing in the official database, which is clearly a concern for many resume padders (based on some of the emails I get), but like I said before, if it incentivizes people to find good flaws and publish the details then I'm ok with that. |
|
My point is that the current system is being used (I won't go so far as to say it incentivizes) as resume fodder where we don't know if they are good flaws, because they aren't published. Hell, we don't know if they are flaws at all. |
|
@attritionorg yup so I would argue it's kind of our job to educate people that the good flaws are 1) published with good reports/details and 2) also included in reputable websites (e.g. https://access.redhat.com/security/security-updates/#/cve or https://cve.mitre.org/) |
|
Through the various mechanisms to request one (MITRE form, DWF email, etc), having some language that encourages them to actually publish their findings and not sit on the RESERVED CVE for five years might help. |
|
We will be updating the CVE Form to include language strongly encouraging requesters to update us with references ASAP. Even if the rules about first publication change, this language will be relevant at least until the end of the calendar year under the current rules. |
|
Add to Appendix B: [REFERENCES] should be URLs pointing to a world-wide-web-based resource. For CSV and flat-file formats, they should be separated by a space. References should point to content that is relevant to the vulnerability and include at least all the details included in the CVE entry. Ideally, references should include the CVE ID itself whenever possible. |
|
For the last sentence, are you suggesting that the URL should contain the CVE ID or that the content the URL points to contains the CVE ID? |
|
Should be the latter, of course. Fixing to clarify: Ideally, references should point to content that includes the CVE ID itself whenever possible. |
|
Do you want to add anything regarding 'publicly available'? e.g. does not require authentication. |
|
In section 2.1.1, we have: Note: for a vulnerability to be considered "public", the following conditions must be met: We can add a "See section 2.2.1" line to link these in both directions. Does that work? |
|
That would be great, thanks! |
GOAL: Transparency
CHANGE: The CVE List cannot be the first point of publication for any information, i.e. anything said in a CVE entry must be backed up by a reference.
OUTCOME: Document current policy
The text was updated successfully, but these errors were encountered: