RE: CVE request form is missing an important bit

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

Perfect, and will do.

C

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

-----Original Message-----
From: Landfield, Kent B [mailto:kent.b.landfield@intel.com] 
Sent: Thursday, January 5, 2017 2:42 PM
To: Levendis, Chris <clevendis@mitre.org>; Andy Balinsky (balinsky) 
<balinsky@cisco.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

Sorry, a bit rushed today and the brain said to hit send before tying 
the rest of that statement.....

Call out when it is time for us to crash and bash.... ;-)

---
Kent Landfield
+1.817.637.8026

On 1/5/17, 12:58 PM, "owner-cve-editorial-board-list@lists.mitre.org on 
behalf of Landfield, Kent B" 
<owner-cve-editorial-board-list@lists.mitre.org on behalf of 
kent.b.landfield@intel.com> wrote:

    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