RE: CVE request form is missing an important bit

["Levendis, Chris" <clevendis@mitre.org>]

To the broader point of revising the form, we’ve been gathering 
requirements since the form was implemented as the basis for 
improvement.  The year issue is one of many legitimate issues.  I 
propose that Mitre clean these up as the basis for further discussion 
with the board.  Ideally, we work with DWF to develop the same form (I 
think this is plausible) and then take that shared understanding (or 
areas of disagreement which I don’t anticipate) to the board for review 
and comment.  The form works well but it can certainly be more 
effective in terms of collecting more information and explaining how to 
provide information, and board inputs are welcome and desired. There is 
likely a limit to what we try to collect but I don't think we've 
reached that limit yet.

Once we have a good version 2 developed, perhaps interested members of 
the board can try and break it:-)

C

___________________
Chris Levendis
MITRE
Homeland Security Systems Engineering and 
Development Institute (HS SEDI)
(MITRE) 703-983-2801
(Cell)    703-298-8593
mailto:clevendis@mitre.org 

From: owner-cve-editorial-board-list@lists.mitre.org 
[mailto:owner-cve-editorial-board-list@lists.mitre.org] On Behalf Of 
Andy Balinsky (balinsky)
Sent: Thursday, January 5, 2017 10:55 AM
To: Landfield, Kent B <kent.b.landfield@intel.com>
Cc: Coffin, Chris <ccoffin@mitre.org>; jericho <jericho@attrition.org>; 
cve-editorial-board-list <cve-editorial-board-list@lists.mitre.org>
Subject: Re: CVE request form is missing an important bit

From the early days, the rationale behind CVE was that it was never 
meant to be a database, just an index. Thus, for example, the list of 
references for a CVE, or the description was never meant to be the 
canon or the most comprehensive description of the vulnerability. It 
was not meant to be the repository for all info related to the 
vulnerable. However, the state of the vulnerability info space meant 
that CVE was the best centralized source of info, so people started 
using it as a database for all sorts of purposes including statistical. 
There are better DBs out now, such as NVD that add additional 
info.Thus, I think the year was really meant just as a convenience, so 
you didn't just start at 1 and go to infinity. You could reset the 
counter to zero each January. 

My point is that the year of the CVE shouldn't be a major data item, 
and it shouldn't matter much if the year is 2016 or 2017 for a December 
vuln. 

But that said, I don't really care if steps are taken to let the 
requester request the year either. As I said, I don't think it is very 
important.

That's my opinion.

Andy

On Jan 5, 2017, at 9:21 AM, Landfield, Kent B 
<mailto:kent.b.landfield@intel.com> wrote:

Hi Chris,

What would your response have been if Brian had said the vulnerability 
was ‘public’ in December 2016?  I get your justification/education in 
this specific case but he has a valid point that the form needs to be 
enhanced.  There is nothing that says you cannot add the explanation as 
to how to appropriately use the ‘year’, but it is clear the form needs 
to be able to support this type of issue.  The idea was we would send 
in suggestion to enhance the submission form via real world experiences 
and this seems to fit that case. ;-)  Granted, we should normally only 
see this type of issue shortly after the 1st of any year but ...

FWIW.

---
Kent Landfield
+1.817.637.8026

On 1/5/17, 9:01 AM, 
"mailto:owner-cve-editorial-board-list@lists.mitre.org on behalf of 
Coffin, Chris" <mailto:owner-cve-editorial-board-list@lists.mitre.org 
on behalf of mailto:ccoffin@mitre.org> wrote:

   The year portion of the ID is not meant to indicate when the 
vulnerability was discovered. In general, the year portion translates 
to either the request year, or the public disclosure year. 

   We had explained the thought behind our process in an oss-security 
post (quoted below) a couple of years ago [1]. The following is the 
main take away from that post.

   "The year portion of a CVE ID typically reflects when the CVE was 
requested for non-public issues; or for already-public issues, the year 
portion typically reflects the year of disclosure. The disclosure date 
itself can be a subject of interpretation, such as when an issue is 
disclosed at a publicly-accessible URL but only likely to be noticed by 
a limited audience ("technically public") versus when the issue becomes 
"widely public" to the infosec industry."

   We could ask for this data in an optional field, but it might not be 
used if the requester is unclear on how the year is currently used in 
CVE. Would this be a problem on your side, i.e., you ask for a specific 
year but it's assigned something different? Also, What would the 
specific benefits be to allowing the requester to specify the year?

   If anyone else has any thoughts or opinions that would differ from 
this, please let us know. 

   [1] http://seclists.org/oss-sec/2015/q1/46

   Chris Coffin
   The CVE Team

   -----Original Message-----
   From: mailto:owner-cve-editorial-board-list@lists.mitre.org 
[mailto:owner-cve-editorial-board-list@lists.mitre.org] On Behalf Of 
jericho
   Sent: Wednesday, January 04, 2017 5:39 PM
   To: cve-editorial-board-list 
<mailto:cve-editorial-board-list@lists.mitre.org>
   Subject: CVE request form is missing an important bit
   Importance: High

   MITRE,

   The current form for requesting a CVE ID [1] only has one box that 
could be used for this, "Additional information", but does not prompt 
the question at all. The significant thing missing is that when 
requesting an ID, you should be asked what year the ID is for.

   e.g. I requested an ID for my day job yesterday and it even slipped 
my mind that it technically should have been a 2016 ID since the issue 
was discovered in December. As the form does not include anything to 
ask such a question, it didn't occur to me either.

   I believe the form needs to add a box or drop-down and request this 
information, likely with a one-liner about how the year-based 
assignments work (i.e. year it was discovered and/or disclosed to 
vendor, not publicly), to better track vulnerabilities by year.

   .b

   [1] https://cveform.mitre.org/


Andy Balinsky
mailto:balinsky@cisco.com