CVE request form is missing an important bit

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

CVE request form is missing an important bit

jericho
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/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: CVE request form is missing an important bit

Coffin, Chris
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: [hidden email] [mailto:[hidden email]] On Behalf Of jericho
Sent: Wednesday, January 04, 2017 5:39 PM
To: cve-editorial-board-list <[hidden email]>
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/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: CVE request form is missing an important bit

Landfield, Kent B
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, "[hidden email] on behalf of Coffin, Chris" <[hidden email] on behalf of [hidden email]> 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: [hidden email] [mailto:[hidden email]] On Behalf Of jericho
    Sent: Wednesday, January 04, 2017 5:39 PM
    To: cve-editorial-board-list <[hidden email]>
    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/
   

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: CVE request form is missing an important bit

Andy Balinsky (balinsky)
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 <[hidden email]> 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, "[hidden email] on behalf of Coffin, Chris" <[hidden email] on behalf of [hidden email]> 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: [hidden email] [[hidden email]] On Behalf Of jericho
   Sent: Wednesday, January 04, 2017 5:39 PM
   To: cve-editorial-board-list <[hidden email]>
   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



smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: CVE request form is missing an important bit

Levendis, Chris
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:[hidden email]

From: [hidden email] [mailto:[hidden email]] On Behalf Of Andy Balinsky (balinsky)
Sent: Thursday, January 5, 2017 10:55 AM
To: Landfield, Kent B <[hidden email]>
Cc: Coffin, Chris <[hidden email]>; jericho <[hidden email]>; cve-editorial-board-list <[hidden email]>
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:[hidden email]> 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:[hidden email] on behalf of Coffin, Chris" <mailto:[hidden email] on behalf of mailto:[hidden email]> 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:[hidden email] [mailto:[hidden email]] On Behalf Of jericho
   Sent: Wednesday, January 04, 2017 5:39 PM
   To: cve-editorial-board-list <mailto:[hidden email]>
   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:[hidden email]



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: CVE request form is missing an important bit

Landfield, Kent B
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" <[hidden email]> 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:[hidden email]
   
    From: [hidden email] [mailto:[hidden email]] On Behalf Of Andy Balinsky (balinsky)
    Sent: Thursday, January 5, 2017 10:55 AM
    To: Landfield, Kent B <[hidden email]>
    Cc: Coffin, Chris <[hidden email]>; jericho <[hidden email]>; cve-editorial-board-list <[hidden email]>
    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:[hidden email]> 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:[hidden email] on behalf of Coffin, Chris" <mailto:[hidden email] on behalf of mailto:[hidden email]> 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:[hidden email] [mailto:[hidden email]] On Behalf Of jericho
       Sent: Wednesday, January 04, 2017 5:39 PM
       To: cve-editorial-board-list <mailto:[hidden email]>
       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:[hidden email]
   
   
   
   

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: CVE request form is missing an important bit

Landfield, Kent B
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, "[hidden email] on behalf of Landfield, Kent B" <[hidden email] on behalf of [hidden email]> 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" <[hidden email]> 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:[hidden email]
       
        From: [hidden email] [mailto:[hidden email]] On Behalf Of Andy Balinsky (balinsky)
        Sent: Thursday, January 5, 2017 10:55 AM
        To: Landfield, Kent B <[hidden email]>
        Cc: Coffin, Chris <[hidden email]>; jericho <[hidden email]>; cve-editorial-board-list <[hidden email]>
        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:[hidden email]> 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:[hidden email] on behalf of Coffin, Chris" <mailto:[hidden email] on behalf of mailto:[hidden email]> 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:[hidden email] [mailto:[hidden email]] On Behalf Of jericho
           Sent: Wednesday, January 04, 2017 5:39 PM
           To: cve-editorial-board-list <mailto:[hidden email]>
           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:[hidden email]
       
       
       
       
   
   

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: CVE request form is missing an important bit

Levendis, Chris
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
[hidden email]

-----Original Message-----
From: Landfield, Kent B [mailto:[hidden email]]
Sent: Thursday, January 5, 2017 2:42 PM
To: Levendis, Chris <[hidden email]>; Andy Balinsky (balinsky) <[hidden email]>
Cc: Coffin, Chris <[hidden email]>; jericho <[hidden email]>; cve-editorial-board-list <[hidden email]>
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, "[hidden email] on behalf of Landfield, Kent B" <[hidden email] on behalf of [hidden email]> 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" <[hidden email]> 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:[hidden email]
       
        From: [hidden email] [mailto:[hidden email]] On Behalf Of Andy Balinsky (balinsky)
        Sent: Thursday, January 5, 2017 10:55 AM
        To: Landfield, Kent B <[hidden email]>
        Cc: Coffin, Chris <[hidden email]>; jericho <[hidden email]>; cve-editorial-board-list <[hidden email]>
        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:[hidden email]> 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:[hidden email] on behalf of Coffin, Chris" <mailto:[hidden email] on behalf of mailto:[hidden email]> 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:[hidden email] [mailto:[hidden email]] On Behalf Of jericho
           Sent: Wednesday, January 04, 2017 5:39 PM
           To: cve-editorial-board-list <mailto:[hidden email]>
           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:[hidden email]
       
       
       
       
   
   

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: CVE request form is missing an important bit

jericho
In reply to this post by Andy Balinsky (balinsky)
On Thu, 5 Jan 2017, Andy Balinsky (balinsky) wrote:

: 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.

"Shouldn't matter", yet every company that uses the CVE data set to
generate statistics rely on that to count by year, even if the
vulnerability was disclosed a year prior to the ID (e.g. disclosed in
2015, received a 2016 ID).

This is a simple fact, and a majority of the 'statistics' we see
surrounding vulnerabilities are impacted by this.

.b
Loading...