CNA Rules Announcement

classic Classic list List threaded Threaded
29 messages Options
12
Reply | Threaded
Open this post in threaded view
|

CNA Rules Announcement

Coffin, Chris

Greetings,

 

On Monday, October 10th, all CNAs should be assigning CVE IDs based on the new CNA rules listed here:

 

<http://cveproject.github.io/docs/cna/CNA%20Rules%20v1.1.docx>

 

As you use these new rules, please feel free to share any feedback you might have with the rest of the CNA community and MITRE. We would like to understand what is working and what isn’t so that the rules evolve to meet the needs of the program and so that additional guidance and training can be developed based on what we collectively learn.  You can share your feedback through the cve-cna-list mailing list or directly to MITRE through the CVE Web Form.

 

<https://cveform.mitre.org/>

 

It was noted by an early reviewer that the Rules document does not provide explicit guidance on how to notify the primary or root CNA regarding publications. Appendix B provides the format but does not mention the method, and this will be corrected soon. There are currently two acceptable methods of sending requests for publication. The first would be to use the above web form and select the option “Notify CVE about a publication.” This option works well if you are publishing one or maybe a handful of CVE IDs, but may not work well if publishing a large amount of CVE IDs. The second method would be to create a file as outlined in Appendix B and to email that file to us. We prefer that you use the [hidden email] address at the moment, though this could change in the future.

 

We intend to collect and broadly share feedback over the next 3-6 months so that these rules remain effective and current.  If this time frame must be accelerated based on the conditions on the ground, then it will be based on the feedback we receive.

 

Thank you to those that offered feedback during the drafting of the document. We look forward to working with the CNAs to help get these rules implemented and to work out any kinks.

 

Please let us know if you think it isn’t time to implement these new rules.  We think it is based on the feedback to-date coupled with the board call yesterday.

 

 

Chris Coffin

The CVE Team

Reply | Threaded
Open this post in threaded view
|

Re: CNA Rules Announcement

Kurt Seifried
Regarding the 

Examples of remediation and sanctions include, but are not limited to:

  • The development of training, guidance, or implementation materials for use by the CNAs;

  • Retraining of CNA staff;

  • Additional process documentation and reporting from a CNA;

  • Reduction of the number of CVE IDs a CNA has available to assign at a time;

  • Rejection of submissions; and

  • Revocation of CNA status.


Can I for example impose monetary fines? I think this section needs a LOT more work before it is adopted officially.

On Fri, Oct 7, 2016 at 9:14 AM, Coffin, Chris <[hidden email]> wrote:

Greetings,

 

On Monday, October 10th, all CNAs should be assigning CVE IDs based on the new CNA rules listed here:

 

<http://cveproject.github.io/docs/cna/CNA%20Rules%20v1.1.docx>

 

As you use these new rules, please feel free to share any feedback you might have with the rest of the CNA community and MITRE. We would like to understand what is working and what isn’t so that the rules evolve to meet the needs of the program and so that additional guidance and training can be developed based on what we collectively learn.  You can share your feedback through the cve-cna-list mailing list or directly to MITRE through the CVE Web Form.

 

<https://cveform.mitre.org/>

 

It was noted by an early reviewer that the Rules document does not provide explicit guidance on how to notify the primary or root CNA regarding publications. Appendix B provides the format but does not mention the method, and this will be corrected soon. There are currently two acceptable methods of sending requests for publication. The first would be to use the above web form and select the option “Notify CVE about a publication.” This option works well if you are publishing one or maybe a handful of CVE IDs, but may not work well if publishing a large amount of CVE IDs. The second method would be to create a file as outlined in Appendix B and to email that file to us. We prefer that you use the [hidden email] address at the moment, though this could change in the future.

 

We intend to collect and broadly share feedback over the next 3-6 months so that these rules remain effective and current.  If this time frame must be accelerated based on the conditions on the ground, then it will be based on the feedback we receive.

 

Thank you to those that offered feedback during the drafting of the document. We look forward to working with the CNAs to help get these rules implemented and to work out any kinks.

 

Please let us know if you think it isn’t time to implement these new rules.  We think it is based on the feedback to-date coupled with the board call yesterday.

 

 

Chris Coffin

The CVE Team




--

--
Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Red Hat Product Security contact: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: CNA Rules Announcement

Landfield, Kent B

Well that’s one way to raise operational revenue… ;-) 

 

I’d think what is needed here is a little experience with the rules.  I agree there are a few places where work is needed but this seems a reasonable start.  Kurt, this is good input for MITRE. I hope we can get others to take a look at what needs to be changed and/or clarified to assure its usefulness.  I view this document as simply a stake-in-the-ground to get us started towards more consistency, while giving us a base to improve from.

 

---

Kent Landfield

+1.817.637.8026

 

From: <[hidden email]> on behalf of Kurt Seifried <[hidden email]>
Date: Friday, October 7, 2016 at 11:52 AM
To: "Coffin, Chris" <[hidden email]>
Cc: cve-editorial-board-list <[hidden email]>, cve-cna-list <[hidden email]>
Subject: Re: CNA Rules Announcement

 

Regarding the 

 

Examples of remediation and sanctions include, but are not limited to:

·         The development of training, guidance, or implementation materials for use by the CNAs;

·         Retraining of CNA staff;

·         Additional process documentation and reporting from a CNA;

·         Reduction of the number of CVE IDs a CNA has available to assign at a time;

·         Rejection of submissions; and

·         Revocation of CNA status.

 

Can I for example impose monetary fines? I think this section needs a LOT more work before it is adopted officially.

 

On Fri, Oct 7, 2016 at 9:14 AM, Coffin, Chris <[hidden email]> wrote:

Greetings,

 

On Monday, October 10th, all CNAs should be assigning CVE IDs based on the new CNA rules listed here:

 

<http://cveproject.github.io/docs/cna/CNA%20Rules%20v1.1.docx>

 

As you use these new rules, please feel free to share any feedback you might have with the rest of the CNA community and MITRE. We would like to understand what is working and what isn’t so that the rules evolve to meet the needs of the program and so that additional guidance and training can be developed based on what we collectively learn.  You can share your feedback through the cve-cna-list mailing list or directly to MITRE through the CVE Web Form.

 

<https://cveform.mitre.org/>

 

It was noted by an early reviewer that the Rules document does not provide explicit guidance on how to notify the primary or root CNA regarding publications. Appendix B provides the format but does not mention the method, and this will be corrected soon. There are currently two acceptable methods of sending requests for publication. The first would be to use the above web form and select the option “Notify CVE about a publication.” This option works well if you are publishing one or maybe a handful of CVE IDs, but may not work well if publishing a large amount of CVE IDs. The second method would be to create a file as outlined in Appendix B and to email that file to us. We prefer that you use the [hidden email] address at the moment, though this could change in the future.

 

We intend to collect and broadly share feedback over the next 3-6 months so that these rules remain effective and current.  If this time frame must be accelerated based on the conditions on the ground, then it will be based on the feedback we receive.

 

Thank you to those that offered feedback during the drafting of the document. We look forward to working with the CNAs to help get these rules implemented and to work out any kinks.

 

Please let us know if you think it isn’t time to implement these new rules.  We think it is based on the feedback to-date coupled with the board call yesterday.

 

 

Chris Coffin

The CVE Team



 

--

 

--
Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Red Hat Product Security contact: 
[hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: CNA Rules Announcement

Levendis, Chris

Correct.  The rules will be improved as they are implemented and we learn how to do better.  Specifically about sanctions, as we conceive of new and reasonable sanctions, we can add them to the representative list.  Reasonability should be a collective determination as much as that’s possible.  Our view is that the stake in the ground is the important first step, and then we build from there based on everyone’s experience with dealing with the rules.

 

We’ll keep a working copy of the rules coupled with feedback received and tweak them through discussions on the CNA list and with the board.  GitHub seems like a good place to keep this copy.

 

C

 

___________________
Chris Levendis

MITRE

Homeland Security Systems Engineering and

Development Institute (HS SEDI)

(MITRE) 703-983-2801

(Cell)    703-298-8593

[hidden email]

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Landfield, Kent B
Sent: Friday, October 07, 2016 1:13 PM
To: Kurt Seifried <[hidden email]>; Coffin, Chris <[hidden email]>
Cc: cve-editorial-board-list <[hidden email]>; cve-cna-list <[hidden email]>
Subject: Re: CNA Rules Announcement

 

Well that’s one way to raise operational revenue… ;-) 

 

I’d think what is needed here is a little experience with the rules.  I agree there are a few places where work is needed but this seems a reasonable start.  Kurt, this is good input for MITRE. I hope we can get others to take a look at what needs to be changed and/or clarified to assure its usefulness.  I view this document as simply a stake-in-the-ground to get us started towards more consistency, while giving us a base to improve from.

 

---

Kent Landfield

+1.817.637.8026

 

From: <[hidden email]> on behalf of Kurt Seifried <[hidden email]>
Date: Friday, October 7, 2016 at 11:52 AM
To: "Coffin, Chris" <[hidden email]>
Cc: cve-editorial-board-list <[hidden email]>, cve-cna-list <[hidden email]>
Subject: Re: CNA Rules Announcement

 

Regarding the 

 

Examples of remediation and sanctions include, but are not limited to:

·        The development of training, guidance, or implementation materials for use by the CNAs;

·        Retraining of CNA staff;

·        Additional process documentation and reporting from a CNA;

·        Reduction of the number of CVE IDs a CNA has available to assign at a time;

·        Rejection of submissions; and

·        Revocation of CNA status.

 

Can I for example impose monetary fines? I think this section needs a LOT more work before it is adopted officially.

 

On Fri, Oct 7, 2016 at 9:14 AM, Coffin, Chris <[hidden email]> wrote:

Greetings,

 

On Monday, October 10th, all CNAs should be assigning CVE IDs based on the new CNA rules listed here:

 

<http://cveproject.github.io/docs/cna/CNA%20Rules%20v1.1.docx>

 

As you use these new rules, please feel free to share any feedback you might have with the rest of the CNA community and MITRE. We would like to understand what is working and what isn’t so that the rules evolve to meet the needs of the program and so that additional guidance and training can be developed based on what we collectively learn.  You can share your feedback through the cve-cna-list mailing list or directly to MITRE through the CVE Web Form.

 

<https://cveform.mitre.org/>

 

It was noted by an early reviewer that the Rules document does not provide explicit guidance on how to notify the primary or root CNA regarding publications. Appendix B provides the format but does not mention the method, and this will be corrected soon. There are currently two acceptable methods of sending requests for publication. The first would be to use the above web form and select the option “Notify CVE about a publication.” This option works well if you are publishing one or maybe a handful of CVE IDs, but may not work well if publishing a large amount of CVE IDs. The second method would be to create a file as outlined in Appendix B and to email that file to us. We prefer that you use the [hidden email] address at the moment, though this could change in the future.

 

We intend to collect and broadly share feedback over the next 3-6 months so that these rules remain effective and current.  If this time frame must be accelerated based on the conditions on the ground, then it will be based on the feedback we receive.

 

Thank you to those that offered feedback during the drafting of the document. We look forward to working with the CNAs to help get these rules implemented and to work out any kinks.

 

Please let us know if you think it isn’t time to implement these new rules.  We think it is based on the feedback to-date coupled with the board call yesterday.

 

 

Chris Coffin

The CVE Team



 

--

 

--
Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Red Hat Product Security contact: 
[hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: CNA Rules Announcement

Coffin, Chris
In reply to this post by Coffin, Chris
Larry,

Thanks for the note.

> I'm not releasing details of vulnerabilities publicly giving the vendor time to fix it.  Would having the above details in the web form assist you all in this process? or you don't require details until the disclosure goes public?

One thing that should probably be pointed out here. The “Notify CVE about a publication” form should really only be used when you the CVE ID(s) in question are public and ready to be populated in the CVE repository. It would seem that you could put tomorrow's date into that form and expect that the CVE repository entry would wait until tomorrow, but keep in mind that this process is not yet automated. Also, what happens if something changes on your side and you need to wait on publication. Currently there would be no easy way to change this date. For now, it would be best if you only use the form in question once the CVE ID has been published on your side. I am definitely open to comments and suggestions on this as well.

As for the fields themselves, we are definitely aware of the fact that the current “Notify CVE about a publication” form does not follow Appendix B exactly. This is mostly a side effect of us creating the CNA rules *after* we created the web forms. We will need to either update the Notify of publication form, or just create a new form specific to CAN notification of publication.

In the meantime, I think it makes sense to just include the data in the Additional information field. The field should be large enough to hold a reasonably sized set of fields from Appendix B. The form already has specific fields for the CVE ID and advisory reference. I believe the reference field will allow multiple references separated by a new line, but if not then this could also be included in the additional information.

As I had stated previously, this works ok if you have one or a couple CVE IDs to publish. If you have a number of IDs to publish all at once, the best option currently would be through email.

If anyone else on the list has any additional suggestions or thoughts on the topic, please don't hesitate to share them. We will most definitely be thinking about methods for automation around this process as we move forward.

Thanks for the feedback!

Chris

-----Original Message-----
From: Larry W. Cashdollar [mailto:[hidden email]]
Sent: Friday, October 07, 2016 11:13 AM
To: Coffin, Chris <[hidden email]>
Cc: cve-editorial-board-list <[hidden email]>; cve-cna-list <[hidden email]>
Subject: Re: CNA Rules Announcement

Hi,

Upon filling out the form for publishing a CVE I thought you might have the same fields as required in the rules document:

[CVEID]:
[PRODUCT]:
[VERSION]:
[PROBLEMTYPE]:
[REFERENCES]:
[DESCRIPTION]:

I'm not releasing details of vulnerabilities publicly giving the vendor time to fix it.  Would having the above details in the web form assist you all in this process? or you don't require details until the disclosure goes public?

Thanks!
Larry

(so far this has been a very smooth process, I'm happy)


> On Oct 7, 2016, at 11:14 AM, Coffin, Chris <[hidden email]> wrote:
>
> Greetings,
>  
> On Monday, October 10th, all CNAs should be assigning CVE IDs based on the new CNA rules listed here:
>  
> <http://cveproject.github.io/docs/cna/CNA%20Rules%20v1.1.docx>
>  
> As you use these new rules, please feel free to share any feedback you might have with the rest of the CNA community and MITRE. We would like to understand what is working and what isn’t so that the rules evolve to meet the needs of the program and so that additional guidance and training can be developed based on what we collectively learn.  You can share your feedback through the cve-cna-list mailing list or directly to MITRE through the CVE Web Form.
>  
> <https://cveform.mitre.org/>
>  
> It was noted by an early reviewer that the Rules document does not provide explicit guidance on how to notify the primary or root CNA regarding publications. Appendix B provides the format but does not mention the method, and this will be corrected soon. There are currently two acceptable methods of sending requests for publication. The first would be to use the above web form and select the option “Notify CVE about a publication.” This option works well if you are publishing one or maybe a handful of CVE IDs, but may not work well if publishing a large amount of CVE IDs. The second method would be to create a file as outlined in Appendix B and to email that file to us. We prefer that you use the [hidden email] address at the moment, though this could change in the future.
>  
> We intend to collect and broadly share feedback over the next 3-6 months so that these rules remain effective and current.  If this time frame must be accelerated based on the conditions on the ground, then it will be based on the feedback we receive.
>  
> Thank you to those that offered feedback during the drafting of the document. We look forward to working with the CNAs to help get these rules implemented and to work out any kinks.
>  
> Please let us know if you think it isn’t time to implement these new rules.  We think it is based on the feedback to-date coupled with the board call yesterday.
>  
>  
> Chris Coffin
> The CVE Team

Reply | Threaded
Open this post in threaded view
|

Re: CNA Rules Announcement

jericho
In reply to this post by Coffin, Chris
Chris,

On Fri, 7 Oct 2016, Coffin, Chris wrote:

: On Monday, October 10th, all CNAs should be assigning CVE IDs based on the new CNA rules listed here:
:
: <http://cveproject.github.io/docs/cna/CNA%20Rules%20v1.1.docx>

Just to be clear, does this mean MITRE has reached out to all of the
current CNAs and informed them of the new rules?

: As you use these new rules, please feel free to share any feedback you
: might have with the rest of the CNA community and MITRE. We would like
: to understand what is working and what isn't so that the rules evolve to
: meet the needs of the program and so that additional guidance and
: training can be developed based on what we collectively learn.  You can
: share your feedback through the cve-cna-list mailing list or directly to
: MITRE through the CVE Web Form.

How should we approach CNAs that are violating these rules, via a
long-term string of violations regarding an assignment. For example, IBM
has been using CVE-2014-8730 for their products despite the early change
in the entry from MITRE specifically designating it for F5 products only.
I have contacted IBM half a dozen times over the last year or more
pointing out examples of this. Their most recent mis-use of this CVE was
on Sep 19 (http://www-01.ibm.com/support/docview.wss?uid=swg21390112).
Moving forward, if they continue to mis-use 2014-8730, what is the best
course of action since contacting them doesn't seem to help?

Thanks,

Brian
Reply | Threaded
Open this post in threaded view
|

RE: CNA Rules Announcement

Coffin, Chris
Brian,

> Just to be clear, does this mean MITRE has reached out to all of the current CNAs and informed them of the new rules?

Yes... The rules have been sent through all appropriate channels, and they are also included in this email thread via the cve-cna-list.

> How should we approach CNAs that are violating these rules, via a long-term string of violations regarding an assignment.

We are trying to create a set of rules and a structure for them that works within the overall federated model. The idea is that the Primary CAN would be the ultimate authority, and could impose sanctions on any lower level CNAs. Similarly, root CNAs could impose sanctions on any sub-CNAs underneath them. This structure is discussed in section 1.3 of the current document.

> what is the best course of action since contacting them doesn't seem to help?

The rules are obviously brand new and there will likely be some growing pains, but we will work these through the CNA channels as they are defined in the new rules. If there is failure to communicate regarding the new rules going forward, then the CNA(s) within those channels will need to decide how to proceed.

As for the specific issue you mention, we discussed this one recently and I believe that there are changes in the works (i.e., it shouldn't be an issue much longer).

Chris

-----Original Message-----
From: jericho [mailto:[hidden email]]
Sent: Friday, October 07, 2016 1:54 PM
To: Coffin, Chris <[hidden email]>
Cc: cve-editorial-board-list <[hidden email]>; cve-cna-list <[hidden email]>
Subject: Re: CNA Rules Announcement
Importance: High


Chris,

On Fri, 7 Oct 2016, Coffin, Chris wrote:

: On Monday, October 10th, all CNAs should be assigning CVE IDs based on the new CNA rules listed here:
:
: <http://cveproject.github.io/docs/cna/CNA%20Rules%20v1.1.docx>

Just to be clear, does this mean MITRE has reached out to all of the current CNAs and informed them of the new rules?

: As you use these new rules, please feel free to share any feedback you
: might have with the rest of the CNA community and MITRE. We would like
: to understand what is working and what isn't so that the rules evolve to
: meet the needs of the program and so that additional guidance and
: training can be developed based on what we collectively learn.  You can
: share your feedback through the cve-cna-list mailing list or directly to
: MITRE through the CVE Web Form.

How should we approach CNAs that are violating these rules, via a long-term string of violations regarding an assignment. For example, IBM has been using CVE-2014-8730 for their products despite the early change in the entry from MITRE specifically designating it for F5 products only.
I have contacted IBM half a dozen times over the last year or more pointing out examples of this. Their most recent mis-use of this CVE was on Sep 19 (http://www-01.ibm.com/support/docview.wss?uid=swg21390112).
Moving forward, if they continue to mis-use 2014-8730, what is the best course of action since contacting them doesn't seem to help?

Thanks,

Brian
Reply | Threaded
Open this post in threaded view
|

Re: CNA Rules Announcement

jericho
In reply to this post by jericho
On Fri, 7 Oct 2016, Chandan Nandakumaraiah wrote:

: > For example, IBM
: > has been using CVE-2014-8730 for their products despite the early change
: > in the entry from MITRE specifically designating it for F5 products only.
:
: As per the new rules (CNT3), a common vulnerability in a 'protocol
: implementation' should get a single CVE. Since this is the "same
: specific common mistake" in the TLS protocol implementation though there
: is no problem in the protocol specification. It seems like an
: appropriate use of the new rules to refer this vulnerability with a
: single CVE id.

Moving forward sure, but retroactively trying to enforce that for an issue
that is already abstracted to some degree does not work. The current
abstraction and assignments that have been in place for over a year need
to be followed.

: The new rule is more in line with how consumers use CVEs to refer to
: common vulnerabilities. When our customers ask us about "POODLE for TLS"
: they use CVE-2014-8730 to refer to this vulnerability. When
: vulnerability scanners scan, they may find an instance of CVE-2014-8730.
: Telling customers that MITRE says that CVE-2014-8730 is limited to F5
: products only would be confusing and may lead to wrong interpretations.

Not sure every scanner does that. There is a lot of value in having a
per-vendor finding in that case, else that single finding will come with a
list of 250+ advisories that are not easily distinguished from each other,
that carry the solution. A per-vendor plugin/scan basis would allow for
much more friendly reporting when it comes to the solution.

Many people aren't aware of this because they haven't seen a VDB actually
track affected products to that degree. I can assure you that the 'mega
entries' of VulnDB where it is a single entry for a protocol vulnerability
are unwieldy and not as user friendly as the abstracted implementation
issues. We have entries with over 500 advisory links and well over 1,000
products impacted. That is what many companies have been demanding for
vulnerability management, yet most VDBs have never bothered with it.

Brian
Reply | Threaded
Open this post in threaded view
|

RE: CNA Rules Announcement

Williams, Ken
Solution:  Assign a master/primary/original CVE for the
"POODLE for TLS" vulnerability, and then assign CVEs as needed
for all affected products-vendors.  Each of these "secondary"
POODLE CVEs should reference/"hashtag" the primary POODLE CVE
in their description.

Regards,
Ken Williams
Vulnerability Response Director, Product Vulnerability Response Team
CA Technologies | 520 Madison Avenue, 22nd Floor, New York NY 10022


> -----Original Message-----
> From: [hidden email] [mailto:owner-cve-cna-
> [hidden email]] On Behalf Of Chandan Nandakumaraiah
> Sent: Saturday, October 08, 2016 12:16 AM
> To: cve-cna-list <[hidden email]>
> Cc: cve-editorial-board-list <[hidden email]>
> Subject: Re: CNA Rules Announcement
>
> > Moving forward sure, but retroactively trying to enforce that for an
> issue
> > that is already abstracted to some degree does not work.
>
> Agreed. We need a statement or rule on the interaction between new
> assignments and assignments based on previous rules.
>
> If we discover a new product with "POODLE for TLS" vulnerability:
>  (a) do we assign a new CVE id with its use limited to that product
> alone (old rule)?
>  (b) use CVE-2014-8730 (based on INC5 and Appendix E rules)?
>  (c) assign a new CVE entirely for the "POODLE for TLS" vulnerability?
>
> > Not sure every scanner does that. There is a lot of value in having a
> > per-vendor finding in that case, else that single finding will come with
> a
> > list of 250+ advisories that are not easily distinguished from each
> other,
> > that carry the solution.
>
> We can not solve that problem by assigning 250+ different CVEs for a
> common vulnerability. That would be like going back to pre-CVE era,
> isn't it?
>
> What if the product-vendor being scanned had never produced an advisory
> or fix for the 'POODLE for TLS' issue? Which of the many CVEs should the
> scanner use to reference that unique issue?
>
> Thanks,
> -Chandan
> --
> Security Incident Response Team
> Juniper Networks
Reply | Threaded
Open this post in threaded view
|

Re: CNA Rules Announcement

Pascal Meunier
In reply to this post by jericho
I think that problem belongs to scanner vendors or the NVD, who should
worry about which vendors exactly are affected, which software versions,
and which advisories apply to which, and which to report in the scanner
findings.  It reminds me of Steve's mantra, "the CVE is not a
vulnerability database".  Based on that mantra and your argumentation
being based on what a full-service vulnerability database can or should
do ideally, I believe the CVE should not be distorted for it.  Besides,
I bet most scanners would report *all* such CVEs if they could not
determine the vendor, and count them as individual findings against the
target (even if Kens suggestion of a "master" CVE was retained, which
would make the CVE hierarchical like the CWE).

I imagine this report:  "You have 247823 vulnerabilities on your network!"

I am in favor of the single CVE, and avoiding anything making it
hierarchical.

Brian thanks for copying again the cve-editorial-board-list, I never saw
Chandan's message.

Pascal

On 10/07/2016 08:26 PM, jericho wrote:

> On Fri, 7 Oct 2016, Chandan Nandakumaraiah wrote:
>
> : > For example, IBM
> : > has been using CVE-2014-8730 for their products despite the early change
> : > in the entry from MITRE specifically designating it for F5 products only.
> :
> : As per the new rules (CNT3), a common vulnerability in a 'protocol
> : implementation' should get a single CVE. Since this is the "same
> : specific common mistake" in the TLS protocol implementation though there
> : is no problem in the protocol specification. It seems like an
> : appropriate use of the new rules to refer this vulnerability with a
> : single CVE id.
>
> Moving forward sure, but retroactively trying to enforce that for an issue
> that is already abstracted to some degree does not work. The current
> abstraction and assignments that have been in place for over a year need
> to be followed.
>
> : The new rule is more in line with how consumers use CVEs to refer to
> : common vulnerabilities. When our customers ask us about "POODLE for TLS"
> : they use CVE-2014-8730 to refer to this vulnerability. When
> : vulnerability scanners scan, they may find an instance of CVE-2014-8730.
> : Telling customers that MITRE says that CVE-2014-8730 is limited to F5
> : products only would be confusing and may lead to wrong interpretations.
>
> Not sure every scanner does that. There is a lot of value in having a
> per-vendor finding in that case, else that single finding will come with a
> list of 250+ advisories that are not easily distinguished from each other,
> that carry the solution. A per-vendor plugin/scan basis would allow for
> much more friendly reporting when it comes to the solution.
>
> Many people aren't aware of this because they haven't seen a VDB actually
> track affected products to that degree. I can assure you that the 'mega
> entries' of VulnDB where it is a single entry for a protocol vulnerability
> are unwieldy and not as user friendly as the abstracted implementation
> issues. We have entries with over 500 advisory links and well over 1,000
> products impacted. That is what many companies have been demanding for
> vulnerability management, yet most VDBs have never bothered with it.
>
> Brian
>
Reply | Threaded
Open this post in threaded view
|

Re: CNA Rules Announcement

Pascal Meunier
I got a reply "Rejected posting to [hidden email]".  I
imagine Chandan got his message rejected by the
cve-editorial-board-list?  This is awkward.

Pascal

On 10/08/2016 04:26 PM, Pascal Meunier wrote:

> I think that problem belongs to scanner vendors or the NVD, who should
> worry about which vendors exactly are affected, which software versions,
> and which advisories apply to which, and which to report in the scanner
> findings.  It reminds me of Steve's mantra, "the CVE is not a
> vulnerability database".  Based on that mantra and your argumentation
> being based on what a full-service vulnerability database can or should
> do ideally, I believe the CVE should not be distorted for it.  Besides,
> I bet most scanners would report *all* such CVEs if they could not
> determine the vendor, and count them as individual findings against the
> target (even if Kens suggestion of a "master" CVE was retained, which
> would make the CVE hierarchical like the CWE).
>
> I imagine this report:  "You have 247823 vulnerabilities on your network!"
>
> I am in favor of the single CVE, and avoiding anything making it
> hierarchical.
>
> Brian thanks for copying again the cve-editorial-board-list, I never saw
> Chandan's message.
>
> Pascal
>
> On 10/07/2016 08:26 PM, jericho wrote:
>> On Fri, 7 Oct 2016, Chandan Nandakumaraiah wrote:
>>
>> : > For example, IBM
>> : > has been using CVE-2014-8730 for their products despite the early
>> change
>> : > in the entry from MITRE specifically designating it for F5
>> products only.
>> :
>> : As per the new rules (CNT3), a common vulnerability in a 'protocol
>> : implementation' should get a single CVE. Since this is the "same
>> : specific common mistake" in the TLS protocol implementation though
>> there
>> : is no problem in the protocol specification. It seems like an
>> : appropriate use of the new rules to refer this vulnerability with a
>> : single CVE id.
>>
>> Moving forward sure, but retroactively trying to enforce that for an
>> issue
>> that is already abstracted to some degree does not work. The current
>> abstraction and assignments that have been in place for over a year need
>> to be followed.
>>
>> : The new rule is more in line with how consumers use CVEs to refer to
>> : common vulnerabilities. When our customers ask us about "POODLE for
>> TLS"
>> : they use CVE-2014-8730 to refer to this vulnerability. When
>> : vulnerability scanners scan, they may find an instance of
>> CVE-2014-8730.
>> : Telling customers that MITRE says that CVE-2014-8730 is limited to F5
>> : products only would be confusing and may lead to wrong interpretations.
>>
>> Not sure every scanner does that. There is a lot of value in having a
>> per-vendor finding in that case, else that single finding will come
>> with a
>> list of 250+ advisories that are not easily distinguished from each
>> other,
>> that carry the solution. A per-vendor plugin/scan basis would allow for
>> much more friendly reporting when it comes to the solution.
>>
>> Many people aren't aware of this because they haven't seen a VDB actually
>> track affected products to that degree. I can assure you that the 'mega
>> entries' of VulnDB where it is a single entry for a protocol
>> vulnerability
>> are unwieldy and not as user friendly as the abstracted implementation
>> issues. We have entries with over 500 advisory links and well over 1,000
>> products impacted. That is what many companies have been demanding for
>> vulnerability management, yet most VDBs have never bothered with it.
>>
>> Brian
>>
Reply | Threaded
Open this post in threaded view
|

Re: CNA Rules Announcement

jericho
In reply to this post by jericho
On Fri, 7 Oct 2016, Chandan Nandakumaraiah wrote:

: > Moving forward sure, but retroactively trying to enforce that for an issue
: > that is already abstracted to some degree does not work.
:
: Agreed. We need a statement or rule on the interaction between new
: assignments and assignments based on previous rules.

Also need to be careful if we unilaterally change the abstraction rules
for CVE if it breaks from a 16 year history.

: > Not sure every scanner does that. There is a lot of value in having a
: > per-vendor finding in that case, else that single finding will come with a
: > list of 250+ advisories that are not easily distinguished from each other,
: > that carry the solution.
:
: We can not solve that problem by assigning 250+ different CVEs for a
: common vulnerability. That would be like going back to pre-CVE era,
: isn't it?

No. Pre-CVE there was BID (for 6 months) and X-Force (for 2 years),
neither of which really faces these kind of protocol vulns. There are
merits of each abstraction method and we should weigh the pros and cons
looking forward, not back.

: What if the product-vendor being scanned had never produced an advisory
: or fix for the 'POODLE for TLS' issue? Which of the many CVEs should the
: scanner use to reference that unique issue?

If they do it right, they don't reference a CVE in that case. That is
perhaps the most critically dangerous notion the board, or anyone in
security, could have; that you *must* have a CVE for it to be a valid
security issue or that an issue without a CVE is some kind of weird thing,
when it absolutely is not. In fact, that is the norm [1] for many
companies.

Brian

[1] http://www.csoonline.com/article/3122460/techology-business/over-6000-vulnerabilities-went-unassigned-by-mitres-cve-project-in-2015.html
Reply | Threaded
Open this post in threaded view
|

Re: CNA Rules Announcement

jericho
In reply to this post by Pascal Meunier
On Sat, 8 Oct 2016, Pascal Meunier wrote:

: I think that problem belongs to scanner vendors or the NVD, who should
: worry about which vendors exactly are affected, which software versions,

That is why the industry is in horrible shape. NVD doesn't even try to
keep up with vendors impacted to that degree. I'm sure if they tried, they
would ask for a lot more money to do so.

: and which advisories apply to which, and which to report in the scanner
: findings.  It reminds me of Steve's mantra, "the CVE is not a
: vulnerability database". Based on that mantra and your argumentation
: being based on what a full-service vulnerability database can or should
: do ideally, I believe the CVE should not be distorted for it.  Besides,

I had long debates with Christey over his mantra for many years, which I
think is absurd personally. While we appreciate each other's arguments,
the fact is almost every major security vendor that relies on
vulnerability information uses CVE, and treats it like a VDB. More
telling, is that every commercial VDB out there shares a common "#1
competition", and it isn't each other at all. CVE/NVD are the reason
companies opt not to pay for better vulnerability intelligence. So use
whatever term you want, it is completely irrelevant as far as the
practical use as seen in the wild today.

: I bet most scanners would report *all* such CVEs if they could not
: determine the vendor, and count them as individual findings against the

Nessus certainly wouldn't.

Brian
Reply | Threaded
Open this post in threaded view
|

Re: CNA Rules Announcement

Scott Lawler
In reply to this post by Williams, Ken

This level of abstraction is…well…abstract.   How do we determine what should be abstracted and to what level?

 

This is a slippery slope to start down.  

 

While I concur that some level of abstraction is good.   I think that we need to carefully define for the community what level of abstraction is appropriate.    

 

Honestly, I’m not quite sure how to do that.   I hate to say case-by-base but…

 

Ideas on how to quantify and define the right level of abstraction?

 

Thank you,  

Scott

703-509-9330

 

 

From: <[hidden email]> on behalf of "Williams, Ken" <[hidden email]>
Date: Saturday, October 8, 2016 at 11:31 AM
To: Chandan Nandakumaraiah <[hidden email]>, cve-cna-list <[hidden email]>
Cc: cve-editorial-board-list <[hidden email]>
Subject: RE: CNA Rules Announcement

 

Solution:  Assign a master/primary/original CVE for the

"POODLE for TLS" vulnerability, and then assign CVEs as needed

for all affected products-vendors.  Each of these "secondary"

POODLE CVEs should reference/"hashtag" the primary POODLE CVE

in their description.

 

Regards,

Ken Williams

Vulnerability Response Director, Product Vulnerability Response Team

CA Technologies | 520 Madison Avenue, 22nd Floor, New York NY 10022

 

 

-----Original Message-----

[hidden email]] On Behalf Of Chandan Nandakumaraiah

Sent: Saturday, October 08, 2016 12:16 AM

To: cve-cna-list <[hidden email]>

Cc: cve-editorial-board-list <[hidden email]>

Subject: Re: CNA Rules Announcement

> Moving forward sure, but retroactively trying to enforce that for an

issue

> that is already abstracted to some degree does not work.

Agreed. We need a statement or rule on the interaction between new

assignments and assignments based on previous rules.

If we discover a new product with "POODLE for TLS" vulnerability:

  (a) do we assign a new CVE id with its use limited to that product

alone (old rule)?

  (b) use CVE-2014-8730 (based on INC5 and Appendix E rules)?

  (c) assign a new CVE entirely for the "POODLE for TLS" vulnerability?

> Not sure every scanner does that. There is a lot of value in having a

> per-vendor finding in that case, else that single finding will come with

a

> list of 250+ advisories that are not easily distinguished from each

other,

> that carry the solution.

We can not solve that problem by assigning 250+ different CVEs for a

common vulnerability. That would be like going back to pre-CVE era,

isn't it?

What if the product-vendor being scanned had never produced an advisory

or fix for the 'POODLE for TLS' issue? Which of the many CVEs should the

scanner use to reference that unique issue?

Thanks,

-Chandan

--

Security Incident Response Team

Juniper Networks

 

Reply | Threaded
Open this post in threaded view
|

Re: CNA Rules Announcement

Kurt Seifried
I would prefer less abstraction, it's easier to have more CVE's and cross reference them (this is related to the following CVEs: Z/X/Y) then it is to have less CVEs and try to ... explain what is in them (this CVE involved multiple vendors and blah de blah blah). 

I would also point out we can tell people "CVE is not a vuln DB" till we're blue in the face, but the  reality is a large portion of the community treats it as such, so we can try to push the sea back, or we can accept reality and work with it (so things like improving CVRF or some alternative so the CVE database has better data, or the data can be more easily discovered in an automated fashion). 

On Sun, Oct 9, 2016 at 7:29 AM, Scott Lawler <[hidden email]> wrote:

This level of abstraction is…well…abstract.   How do we determine what should be abstracted and to what level?

 

This is a slippery slope to start down.  

 

While I concur that some level of abstraction is good.   I think that we need to carefully define for the community what level of abstraction is appropriate.    

 

Honestly, I’m not quite sure how to do that.   I hate to say case-by-base but…

 

Ideas on how to quantify and define the right level of abstraction?

 

Thank you,  

Scott

<a href="tel:703-509-9330" value="+17035099330" target="_blank">703-509-9330

 

 

From: <[hidden email]> on behalf of "Williams, Ken" <[hidden email]>
Date: Saturday, October 8, 2016 at 11:31 AM
To: Chandan Nandakumaraiah <[hidden email]>, cve-cna-list <[hidden email]>
Cc: cve-editorial-board-list <[hidden email]>
Subject: RE: CNA Rules Announcement

 

Solution:  Assign a master/primary/original CVE for the

"POODLE for TLS" vulnerability, and then assign CVEs as needed

for all affected products-vendors.  Each of these "secondary"

POODLE CVEs should reference/"hashtag" the primary POODLE CVE

in their description.

 

Regards,

Ken Williams

Vulnerability Response Director, Product Vulnerability Response Team

CA Technologies | 520 Madison Avenue, 22nd Floor, New York NY 10022

 

 

-----Original Message-----

[hidden email]] On Behalf Of Chandan Nandakumaraiah

Sent: Saturday, October 08, 2016 12:16 AM

To: cve-cna-list <[hidden email]>

Cc: cve-editorial-board-list <[hidden email]>

Subject: Re: CNA Rules Announcement

> Moving forward sure, but retroactively trying to enforce that for an

issue

> that is already abstracted to some degree does not work.

Agreed. We need a statement or rule on the interaction between new

assignments and assignments based on previous rules.

If we discover a new product with "POODLE for TLS" vulnerability:

  (a) do we assign a new CVE id with its use limited to that product

alone (old rule)?

  (b) use CVE-2014-8730 (based on INC5 and Appendix E rules)?

  (c) assign a new CVE entirely for the "POODLE for TLS" vulnerability?

> Not sure every scanner does that. There is a lot of value in having a

> per-vendor finding in that case, else that single finding will come with

a

> list of 250+ advisories that are not easily distinguished from each

other,

> that carry the solution.

We can not solve that problem by assigning 250+ different CVEs for a

common vulnerability. That would be like going back to pre-CVE era,

isn't it?

What if the product-vendor being scanned had never produced an advisory

or fix for the 'POODLE for TLS' issue? Which of the many CVEs should the

scanner use to reference that unique issue?

Thanks,

-Chandan

--

Security Incident Response Team

Juniper Networks

 




--

--
Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Red Hat Product Security contact: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: CNA Rules Announcement

jericho
In reply to this post by Scott Lawler
On Sun, 9 Oct 2016, Scott Lawler wrote:

: This level of abstraction is?well?abstract.  How do we determine what
: should be abstracted and to what level?
:
: This is a slippery slope to start down.
:
: While I concur that some level of abstraction is good.  I think that we
: need to carefully define for the community what level of abstraction is
: appropriate.
:
: Honestly, I?m not quite sure how to do that.  I hate to say case-by-base
: but?
:
: Ideas on how to quantify and define the right level of abstraction?

I think the best way to start is to pick out ~ 10 vulns from the past
that fit the bill. "Protocol" vulns that were NOT due to a flaw in the
design specs, rather the implementation (where almost every vendor got it
wrong), and see how it worked out.

While many may immediately say "we don't need 100 IDs for that, it's
confusing!" I disagree to at a certain point. When it comes to per-vendor
fixes where you are applying 20 different patches, upgrades, or
workarounds in your organization "for the same vulnerability", that is
confusing. That one ID is no longer talking about the same vulnerability
in the full scope of it (flaw, impact, and remediation).

So examining some of the past ones that were abstracted, and some that
were not... then look at how security vendors handled it. Did they create
different rules for IDS/IPS? Did vuln scanners create different
IDs/plugins? That would also be a good one to get community feedback on.

Brian
Reply | Threaded
Open this post in threaded view
|

Re: CNA Rules Announcement

jericho
On Sun, 9 Oct 2016, Chandan Nandakumaraiah wrote:

: On 10/9/16 1:08 PM, jericho wrote:
: > While many may immediately say "we don't need 100 IDs for that, it's
: > confusing!" I disagree to at a certain point. When it comes to per-vendor
: > fixes where you are applying 20 different patches, upgrades, or
: > workarounds in your organization "for the same vulnerability", that is
: > confusing. That one ID is no longer talking about the same vulnerability
: > in the full scope of it (flaw, impact, and remediation).
:
: CVE's core value is in the ability to name vulnerabilities - not fixes,
: patches, upgrades or workarounds.
:
: This is similar to how we name hurricanes or medical conditions: we
: don't name the same medical condition differently based on medicines
: used to treat it, or people it affects. If we have to send 20 rescue
: missions to respond to hurricane Matthew, naming the hurricane
: differently for each response mission isn't going to help.
:
: If there is a need to name (i.e assign unique id to) each patch or
: upgrade then that should not be mixed up with 'Common Vulnerability
: Enumeration'. We will need something named liked a 'Vulnerability
: Remediation Enumeration'.

You are right, but jump back in the thread. If the vulnerability is in the
protocol specs, it deserves one ID. That is *one* base vulnerability that
is inherited by any product implementing the protocol based on the specs.

If you want to then turnaround and issue one ID for implementation flaws,
when the protocol spec is correct, you aren't being consistent. At that
point having different IDs speaks to the different patches, but it wasn't
abstracted *because* of the different patches. Subtle, but important
difference.

I honestly don't much care which way it goes. One ID, abstract by vendor,
whatever. The important part is to stay consistent in the handling of such
issues. MITRE has largely been consistent on this, with a few outliers
(all understandable as best I recall). If MITRE and the Board decide to
change that, it should be a unified decision that is clearly stated moving
forward.

Again, I see the benefit of each method and unfortunately, the benefits of
each way help different types of InfoSec professionals. If we go one way,
we please academics, (some) VDBs, and (some) auditors. If we go the other
way, we please system admins, (some) VDBs, and (some) auditors.

Brian
Reply | Threaded
Open this post in threaded view
|

Re: CNA Rules Announcement

Pascal Meunier
I apologize for having missed the point (even stated in the text of
CVE-2014-8730!), that this is not a flaw in the specification of the
protocol.

I agree with Brian, it makes sense to have one ID for a flaw in the
specification of a protocol, and multiple IDs for vendor implementations
with different code bases, even if they happen to have made similar
mistakes.  I think Kurt's suggestion to cross-reference them "(this is
related to the following CVEs: Z/X/Y)" would be helpful although not
necessary.

I am sorry for having added confusion.

Pascal

On 10/09/2016 10:13 PM, jericho wrote:

> On Sun, 9 Oct 2016, Chandan Nandakumaraiah wrote:
>
> : On 10/9/16 1:08 PM, jericho wrote:
> : > While many may immediately say "we don't need 100 IDs for that, it's
> : > confusing!" I disagree to at a certain point. When it comes to per-vendor
> : > fixes where you are applying 20 different patches, upgrades, or
> : > workarounds in your organization "for the same vulnerability", that is
> : > confusing. That one ID is no longer talking about the same vulnerability
> : > in the full scope of it (flaw, impact, and remediation).
> :
> : CVE's core value is in the ability to name vulnerabilities - not fixes,
> : patches, upgrades or workarounds.
> :
> : This is similar to how we name hurricanes or medical conditions: we
> : don't name the same medical condition differently based on medicines
> : used to treat it, or people it affects. If we have to send 20 rescue
> : missions to respond to hurricane Matthew, naming the hurricane
> : differently for each response mission isn't going to help.
> :
> : If there is a need to name (i.e assign unique id to) each patch or
> : upgrade then that should not be mixed up with 'Common Vulnerability
> : Enumeration'. We will need something named liked a 'Vulnerability
> : Remediation Enumeration'.
>
> You are right, but jump back in the thread. If the vulnerability is in the
> protocol specs, it deserves one ID. That is *one* base vulnerability that
> is inherited by any product implementing the protocol based on the specs.
>
> If you want to then turnaround and issue one ID for implementation flaws,
> when the protocol spec is correct, you aren't being consistent. At that
> point having different IDs speaks to the different patches, but it wasn't
> abstracted *because* of the different patches. Subtle, but important
> difference.
>
> I honestly don't much care which way it goes. One ID, abstract by vendor,
> whatever. The important part is to stay consistent in the handling of such
> issues. MITRE has largely been consistent on this, with a few outliers
> (all understandable as best I recall). If MITRE and the Board decide to
> change that, it should be a unified decision that is clearly stated moving
> forward.
>
> Again, I see the benefit of each method and unfortunately, the benefits of
> each way help different types of InfoSec professionals. If we go one way,
> we please academics, (some) VDBs, and (some) auditors. If we go the other
> way, we please system admins, (some) VDBs, and (some) auditors.
>
> Brian
>
Reply | Threaded
Open this post in threaded view
|

Re: CNA Rules Announcement

Art Manion
On 2016-10-10 05:32, Pascal Meunier wrote:

> I agree with Brian, it makes sense to have one ID for a flaw in the
> specification of a protocol, and multiple IDs for vendor implementations
> with different code bases, even if they happen to have made similar
> mistakes.  I think Kurt's suggestion to cross-reference them "(this is
> related to the following CVEs: Z/X/Y)" would be helpful although not
> necessary.

Noting the disagreement about level of abstraction, I suspect that
beyond individual opinion, different vulnerability analysis/management
use cases prefer different abstractions.  VRDX-SIG at FIRST has a
proposed answer for this, which is basically a protocol (working title:
vxref) for relationships between vulnerability IDs.

https://www.first.org/resources/papers/conf2015/first_2015_-_manion-_uchiyama-_terada_-_vrdx-sig_20150619.pdf

So one could say CVE-X is a subset of CVE-Y.  Or similar to.  If VDBs
were to use the protocol, a user could construct a graph of IDs.  vxref
isn't limited to CVE IDs.

In a world of, at the very minimum, 14K publicly disclosed
vulnerabilities per year, a way to deal with different abstractions
within or across VDBs is more than helpful, it's essential, unless one
VDB is going to cover the entire world's uses.

In my view, the role of CVE is to identify/name vulnerabilities, and
nothing further.  Other downstream users, like NVD, can build on CVE.
Of course CVE needs to make abstraction decisions and contain enough
information to de-duplicate entries.

 - Art
Reply | Threaded
Open this post in threaded view
|

Re: CNA Rules Announcement

Landfield, Kent B
Art,

You wrote:
    In my view, the role of CVE is to identify/name vulnerabilities, and
    nothing further.  Other downstream users, like NVD, can build on CVE.
    Of course CVE needs to make abstraction decisions and contain enough
    information to de-duplicate entries.
   
I could not agree more.  The power of CVE is that it is simply a means for naming vulnerabilities. Others should build on it as their use cases require.
---
Kent Landfield
+1.817.637.8026

On 10/10/16, 9:28 AM, "[hidden email] on behalf of Art Manion" <[hidden email] on behalf of [hidden email]> wrote:

    On 2016-10-10 05:32, Pascal Meunier wrote:
   
    > I agree with Brian, it makes sense to have one ID for a flaw in the
    > specification of a protocol, and multiple IDs for vendor implementations
    > with different code bases, even if they happen to have made similar
    > mistakes.  I think Kurt's suggestion to cross-reference them "(this is
    > related to the following CVEs: Z/X/Y)" would be helpful although not
    > necessary.
   
    Noting the disagreement about level of abstraction, I suspect that
    beyond individual opinion, different vulnerability analysis/management
    use cases prefer different abstractions.  VRDX-SIG at FIRST has a
    proposed answer for this, which is basically a protocol (working title:
    vxref) for relationships between vulnerability IDs.
   
    https://www.first.org/resources/papers/conf2015/first_2015_-_manion-_uchiyama-_terada_-_vrdx-sig_20150619.pdf
   
    So one could say CVE-X is a subset of CVE-Y.  Or similar to.  If VDBs
    were to use the protocol, a user could construct a graph of IDs.  vxref
    isn't limited to CVE IDs.
   
    In a world of, at the very minimum, 14K publicly disclosed
    vulnerabilities per year, a way to deal with different abstractions
    within or across VDBs is more than helpful, it's essential, unless one
    VDB is going to cover the entire world's uses.
   
    In my view, the role of CVE is to identify/name vulnerabilities, and
    nothing further.  Other downstream users, like NVD, can build on CVE.
    Of course CVE needs to make abstraction decisions and contain enough
    information to de-duplicate entries.
   
     - Art
   
   

12