Re: CVE request form is missing an important bit

["Landfield, Kent B" <kent.b.landfield@intel.com>]

Asking me to break things? Cool!  I have fun doing that. ;-)  Call

---
Kent Landfield
+1.817.637.8026

On 1/5/17, 12:45 PM, "Levendis, Chris" <clevendis@mitre.org> wrote:

    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