Rough Drafts of CVE Counting Documents

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

Rough Drafts of CVE Counting Documents

Coffin, Chris

All,

 

Sorry for the delay, these were supposed to go out last week.

 

Attached is the latest marked up version of the Simplified Counting Rules, as well as the promised very rough version of a new CVE Vulnerability Counting for CNAs document. There is still plenty of work to be done on this new document, but the main focus so far has been to develop the decision trees. The included decision trees are meant to replace the older decision trees found at https://github.com/CVEProject/docs/blob/gh-pages/cna/application-guidance.md.

 

Current thinking is that the introduction of the “independently fixable” concept obsoletes many of the older counting decisions, but we’d be interested to hear others opinions on this. Also, the inclusion rules actually grew a bit, but these all seem to be fairly straightforward.

 

The Report Type decision is something that came up during internal discussions and is probably new to everyone. An earlier version of the doc didn’t have good coverage for how to count when independently fixable resulted in No or Not Sure. The Report Type allows for common reporting cases to be handled in a somewhat uniform way. The idea is to handle the most common reports and the recommended counting action for each. We are definitely interested in hearing others thoughts on this entire counting decision, as well as the common reports and actions that are defined.

 

Like I said before, this is a very early version so I am open to any and all feedback. Thanks in advance!

 

Chris Coffin

The CVE Team


CVE Counting for CNAs_v0.3_20160725.docx (82K) Download Attachment
CVE Counting - Draft for comment - 2016-07-13_no-markup.docx (111K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Rough Drafts of CVE Counting Documents

Coffin, Chris

All,

 

Attached is a new version of the CVE Counting for CNAs document. I  have made some changes to the counting decisions as well as provided some clarifications in certain decisions based on feedback from the CVE Team.

 

Chris

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Coffin, Chris
Sent: Monday, July 25, 2016 5:03 PM
To: cve-editorial-board-list <[hidden email]>
Subject: Rough Drafts of CVE Counting Documents

 

All,

 

Sorry for the delay, these were supposed to go out last week.

 

Attached is the latest marked up version of the Simplified Counting Rules, as well as the promised very rough version of a new CVE Vulnerability Counting for CNAs document. There is still plenty of work to be done on this new document, but the main focus so far has been to develop the decision trees. The included decision trees are meant to replace the older decision trees found at https://github.com/CVEProject/docs/blob/gh-pages/cna/application-guidance.md.

 

Current thinking is that the introduction of the “independently fixable” concept obsoletes many of the older counting decisions, but we’d be interested to hear others opinions on this. Also, the inclusion rules actually grew a bit, but these all seem to be fairly straightforward.

 

The Report Type decision is something that came up during internal discussions and is probably new to everyone. An earlier version of the doc didn’t have good coverage for how to count when independently fixable resulted in No or Not Sure. The Report Type allows for common reporting cases to be handled in a somewhat uniform way. The idea is to handle the most common reports and the recommended counting action for each. We are definitely interested in hearing others thoughts on this entire counting decision, as well as the common reports and actions that are defined.

 

Like I said before, this is a very early version so I am open to any and all feedback. Thanks in advance!

 

Chris Coffin

The CVE Team


CVE Counting for CNAs_v0.4.docx (83K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Rough Drafts of CVE Counting Documents

kseifried@redhat.com
Some feedback:

A vulnerability in the context of the CVE program, is code that can be exploited, resulting in a negative impact to confidentiality, integrity, and availability, and that requires a code change to mitigate or address.

Some vulns are internal to the protocol and the only code change that "fixes" it is to remove the code/functionality altogether. Could we add "typically requires" instead? I'm worried about the intersection of software/API vulns that will become increasingly common (more instances of this, and people will start looking for them). 

Can INC2 (Vendor acknowledgement) be expanded to include actual verification through a proof of concept/reproducer for example, or via source code examination?

INC3.1 "demonstrated" does this mean we need a reproducer? 

INC4: can we better define public/private? E.g. what if a medical device maker plans to use a CVE for an issue that they will then inform ever user of directly? Ditto for aerospace/SCADA/etc. 

INC5: "CVE IDs are assigned to products that are customer-controlled or customer-installable." what about on premises solutions that are locked down? I know many medical devices, high end manufacturing, etc you buy it, but you don't touch it, the company tech services it. Ditto for other regulated items like elevators (contractually most elevator maintenance involves a "if anyone but us touches it, your warranty is totally void"). 

CNT4: I'd like to better define the embedded code situation, e.g. libxml/gzip situations (bits of those are everywhere!).











On Wed, Aug 24, 2016 at 2:19 PM, Coffin, Chris <[hidden email]> wrote:

All,

 

Attached is a new version of the CVE Counting for CNAs document. I  have made some changes to the counting decisions as well as provided some clarifications in certain decisions based on feedback from the CVE Team.

 

Chris

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Coffin, Chris
Sent: Monday, July 25, 2016 5:03 PM
To: cve-editorial-board-list <[hidden email]>
Subject: Rough Drafts of CVE Counting Documents

 

All,

 

Sorry for the delay, these were supposed to go out last week.

 

Attached is the latest marked up version of the Simplified Counting Rules, as well as the promised very rough version of a new CVE Vulnerability Counting for CNAs document. There is still plenty of work to be done on this new document, but the main focus so far has been to develop the decision trees. The included decision trees are meant to replace the older decision trees found at https://github.com/CVEProject/docs/blob/gh-pages/cna/application-guidance.md.

 

Current thinking is that the introduction of the “independently fixable” concept obsoletes many of the older counting decisions, but we’d be interested to hear others opinions on this. Also, the inclusion rules actually grew a bit, but these all seem to be fairly straightforward.

 

The Report Type decision is something that came up during internal discussions and is probably new to everyone. An earlier version of the doc didn’t have good coverage for how to count when independently fixable resulted in No or Not Sure. The Report Type allows for common reporting cases to be handled in a somewhat uniform way. The idea is to handle the most common reports and the recommended counting action for each. We are definitely interested in hearing others thoughts on this entire counting decision, as well as the common reports and actions that are defined.

 

Like I said before, this is a very early version so I am open to any and all feedback. Thanks in advance!

 

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
|  
Report Content as Inappropriate

Re: Rough Drafts of CVE Counting Documents

Pascal Meunier
On 08/24/2016 04:54 PM, Kurt Seifried wrote:

> Some feedback:
>
> A vulnerability in the context of the CVE program, is code that can be
> exploited, resulting in a negative impact to confidentiality, integrity,
> and availability, and that requires a code change to mitigate or address.
>
> Some vulns are internal to the protocol and the only code change that
> "fixes" it is to remove the code/functionality altogether. Could we add
> "typically requires" instead? I'm worried about the intersection of
> software/API vulns that will become increasingly common (more instances of
> this, and people will start looking for them).

Indeed there have been CVEs issued against protocols (e.g.,
CVE-2014-3566 against SSLv3) so that's not even code per se.  However, I
think "typically" would make the definition impractical for deciding if
a particular instance is a vulnerability or not.  I suggest:

"A vulnerability in the context of the CVE program, is indicated by code
that can be exploited, resulting in a negative impact to
confidentiality, integrity, OR availability, and that requires a coding
change, specification change or specification deprecation to mitigate or
address."


> INC4: can we better define public/private? E.g. what if a medical device
> maker plans to use a CVE for an issue that they will then inform ever user
> of directly? Ditto for aerospace/SCADA/etc.

I'm not sure I understand what you would like to have happen.  Limited
diffusion?  As a customer, I'd be confused to receive a notice referring
to a CVE I couldn't lookup on a public web site, if that's what you
meant.  If you meant embargoed issues, doesn't the CVE do that already?

>
> INC5: "CVE IDs are assigned to products that are customer-controlled or
> customer-installable." what about on premises solutions that are locked
> down? I know many medical devices, high end manufacturing, etc you buy it,
> but you don't touch it, the company tech services it. Ditto for other
> regulated items like elevators (contractually most elevator maintenance
> involves a "if anyone but us touches it, your warranty is totally void").

I'm guessing the intent of INC5 is to determine if a customer can patch
or mitigate the vulnerability.  However, I would think it is equally
useful to be able to track if the provider of a managed solution has
applied the patches or mitigated the vulnerabilities, so I'd be in favor
of a wider use of CVEs.  This applies regardless of whether it's an open
source solution someone manages on your behalf or something else like
firmware or an entirely closed solution.

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

Re: Rough Drafts of CVE Counting Documents

kseifried@redhat.com


On Thu, Aug 25, 2016 at 10:02 AM, Pascal Meunier <[hidden email]> wrote:
On 08/24/2016 04:54 PM, Kurt Seifried wrote:
Some feedback:

A vulnerability in the context of the CVE program, is code that can be
exploited, resulting in a negative impact to confidentiality, integrity,
and availability, and that requires a code change to mitigate or address.

Some vulns are internal to the protocol and the only code change that
"fixes" it is to remove the code/functionality altogether. Could we add
"typically requires" instead? I'm worried about the intersection of
software/API vulns that will become increasingly common (more instances of
this, and people will start looking for them).

Indeed there have been CVEs issued against protocols (e.g., CVE-2014-3566 against SSLv3) so that's not even code per se.  However, I think "typically" would make the definition impractical for deciding if a particular instance is a vulnerability or not.  I suggest:

"A vulnerability in the context of the CVE program, is indicated by code that can be exploited, resulting in a negative impact to confidentiality, integrity, OR availability, and that requires a coding change, specification change or specification deprecation to mitigate or address."

Yours is much better!
 
INC4: can we better define public/private? E.g. what if a medical device
maker plans to use a CVE for an issue that they will then inform ever user
of directly? Ditto for aerospace/SCADA/etc.

I'm not sure I understand what you would like to have happen.  Limited diffusion?  As a customer, I'd be confused to receive a notice referring to a CVE I couldn't lookup on a public web site, if that's what you meant.  If you meant embargoed issues, doesn't the CVE do that already?


So Red Hat has 1000+ CVEs we've assigned and are not in the MITRE database. So that bridge has already been crossed. Also I'm assuming the CVE's will be available in the vendor database/website, e.g.:


We have a page with limited info (mostly because we're not affected =)


A CVE being in the MITRE or any public database is certainly nice to have, especially for high profile issues, but I wouldn't make it a requirement. 

 

INC5: "CVE IDs are assigned to products that are customer-controlled or
customer-installable." what about on premises solutions that are locked
down? I know many medical devices, high end manufacturing, etc you buy it,
but you don't touch it, the company tech services it. Ditto for other
regulated items like elevators (contractually most elevator maintenance
involves a "if anyone but us touches it, your warranty is totally void").

I'm guessing the intent of INC5 is to determine if a customer can patch or mitigate the vulnerability.  However, I would think it is equally useful to be able to track if the provider of a managed solution has applied the patches or mitigated the vulnerabilities, so I'd be in favor of a wider use of CVEs.  This applies regardless of whether it's an open source solution someone manages on your behalf or something else like firmware or an entirely closed solution.

Exactly.
 
Pascal



--

--
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
|  
Report Content as Inappropriate

RE: Rough Drafts of CVE Counting Documents

Coffin, Chris
In reply to this post by kseifried@redhat.com
Kurt,

Thanks a ton for the feedback... I very much appreciate it.

FYI... I hadn't taken into account Pascal's feedback in the comments below, but I added Pascal's definition of vulnerability as I think it works very well. Thanks Pascal!


> Could we add "typically requires" instead?

I added some text to the definition. Take a look and let me know if this works for you.

> Can INC2 (Vendor acknowledgement) be expanded to include actual verification through a proof of concept/reproducer for example, or via source code examination?

I would be concerned with putting strict verification requirements at the inclusion stage. For vendor CNAs, I think they will most likely do some or all of this, and maybe we can insert this language here that mentions it. However, there may also be other CNAs reading this decision who are not the vendor or maintainer of the product/code and assembling this data or getting it from the vendor could take time if it happens at all. My feeling is that the inclusion steps should emphasize speed in assigning CVE IDs as opposed to getting things perfect up front. If a mistake is made, it can be cleaned up after the fact. Thoughts?

> INC3.1 "demonstrated" does this mean we need a reproducer?

Similar to the above, for a vendor CNA following this it is probably not much of an issue. For a CNA who is not the vendor or maintainer, such as yourself, this becomes more important obviously. I think you have said yourself that you get lots of garbage already. In my mind, "demonstrated" means can the requester properly describe the vulnerability and explain what it's impact is. I think if we force the requester to provide a PoC we may be asking for too much at this stage. As the bolded text states, this one is about trusting the researcher in their claim to a certain extent.

> INC4: can we better define public/private? E.g. what if a medical device maker plans to use a CVE for an issue that they will then inform ever user of directly? Ditto for aerospace/SCADA/etc.

Are you saying that we should soften language now to start including room for CVEs issues that will only be released to a limited group of users? I know we have had these discussions in the recent past, but my understanding was that we would wait to make this kind of change until CVE actually brought on some of these domains where this issue will come up.

> INC5: "CVE IDs are assigned to products that are customer-controlled or customer-installable." what about on premises solutions that are locked down? I know many medical devices, high end manufacturing, etc you buy it, but you don't touch it, the company tech services it. Ditto for other regulated items like elevators (contractually most elevator maintenance involves a "if anyone but us touches it, your warranty is totally void").

This is a really great point! This is another area that I haven't really put much thought into and I don't think anyone else on the board has brought up in the recent past. Outside of the "sort of" similar idea of SaaS (and possibly other xaaS), I imagine there could be IT products (e.g., appliances and such) produced now or in the future that could fall into this category. Similar to the above comments though, should we account for this in the current rules, or should we wait until presented with this problem such as when we bring on the medical devices domain?

 > CNT4: I'd like to better define the embedded code situation, e.g. libxml/gzip situations (bits of those are everywhere!).

One thing that I noticed is that the decision language did not direct the CNA to defer the report to the appropriate CNA in the case of a shared codebase that doesn't apply to the receiving CNA (i.e., the CNA following the decisions based on the report). Are you looking for more process explanation in this case or maybe more examples? If you have anything specific please feel free to pass along.


Chris


From: Kurt Seifried [mailto:[hidden email]]
Sent: Wednesday, August 24, 2016 3:55 PM
To: Coffin, Chris <[hidden email]>
Cc: cve-editorial-board-list <[hidden email]>
Subject: Re: Rough Drafts of CVE Counting Documents

Some feedback:
A vulnerability in the context of the CVE program, is code that can be exploited, resulting in a negative impact to confidentiality, integrity, and availability, and that requires a code change to mitigate or address.
Some vulns are internal to the protocol and the only code change that "fixes" it is to remove the code/functionality altogether. Could we add "typically requires" instead? I'm worried about the intersection of software/API vulns that will become increasingly common (more instances of this, and people will start looking for them). 
Can INC2 (Vendor acknowledgement) be expanded to include actual verification through a proof of concept/reproducer for example, or via source code examination?
INC3.1 "demonstrated" does this mean we need a reproducer? 
INC4: can we better define public/private? E.g. what if a medical device maker plans to use a CVE for an issue that they will then inform ever user of directly? Ditto for aerospace/SCADA/etc. 
INC5: "CVE IDs are assigned to products that are customer-controlled or customer-installable." what about on premises solutions that are locked down? I know many medical devices, high end manufacturing, etc you buy it, but you don't touch it, the company tech services it. Ditto for other regulated items like elevators (contractually most elevator maintenance involves a "if anyone but us touches it, your warranty is totally void"). 
CNT4: I'd like to better define the embedded code situation, e.g. libxml/gzip situations (bits of those are everywhere!).










On Wed, Aug 24, 2016 at 2:19 PM, Coffin, Chris <mailto:[hidden email]> wrote:
All,
 
Attached is a new version of the CVE Counting for CNAs document. I  have made some changes to the counting decisions as well as provided some clarifications in certain decisions based on feedback from the CVE Team.
 
Chris
 
From: mailto:[hidden email] [mailto:mailto:[hidden email]] On Behalf Of Coffin, Chris
Sent: Monday, July 25, 2016 5:03 PM
To: cve-editorial-board-list <mailto:[hidden email]>
Subject: Rough Drafts of CVE Counting Documents
 
All,
 
Sorry for the delay, these were supposed to go out last week.
 
Attached is the latest marked up version of the Simplified Counting Rules, as well as the promised very rough version of a new CVE Vulnerability Counting for CNAs document. There is still plenty of work to be done on this new document, but the main focus so far has been to develop the decision trees. The included decision trees are meant to replace the older decision trees found at https://github.com/CVEProject/docs/blob/gh-pages/cna/application-guidance.md.
 
Current thinking is that the introduction of the “independently fixable” concept obsoletes many of the older counting decisions, but we’d be interested to hear others opinions on this. Also, the inclusion rules actually grew a bit, but these all seem to be fairly straightforward.
 
The Report Type decision is something that came up during internal discussions and is probably new to everyone. An earlier version of the doc didn’t have good coverage for how to count when independently fixable resulted in No or Not Sure. The Report Type allows for common reporting cases to be handled in a somewhat uniform way. The idea is to handle the most common reports and the recommended counting action for each. We are definitely interested in hearing others thoughts on this entire counting decision, as well as the common reports and actions that are defined.
 
Like I said before, this is a very early version so I am open to any and all feedback. Thanks in advance!
 
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: mailto:[hidden email]

CVE Counting for CNAs_v0.5.docx (83K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Rough Drafts of CVE Counting Documents

Pascal Meunier
In reply to this post by kseifried@redhat.com
On 08/25/2016 12:10 PM, Kurt Seifried wrote:

>
>> > INC4: can we better define public/private? E.g. what if a medical device
>>> >> maker plans to use a CVE for an issue that they will then inform ever user
>>> >> of directly? Ditto for aerospace/SCADA/etc.
>>> >>
>> >
>> > I'm not sure I understand what you would like to have happen.  Limited
>> > diffusion?  As a customer, I'd be confused to receive a notice referring to
>> > a CVE I couldn't lookup on a public web site, if that's what you meant.  If
>> > you meant embargoed issues, doesn't the CVE do that already?
>> >
>> >
> So Red Hat has 1000+ CVEs we've assigned and are not in the MITRE database.
> So that bridge has already been crossed. Also I'm assuming the CVE's will
> be available in the vendor database/website, e.g.:
>
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2002-2438
>
> We have a page with limited info (mostly because we're not affected =)
>
> https://access.redhat.com/security/cve/cve-2002-2438
>
> A CVE being in the MITRE or any public database is certainly nice to have,
> especially for high profile issues, but I wouldn't make it a requirement.
>
>
>

The example you give does have public information at
http://www.kb.cert.org/vuls/id/464113, so even though it's deplorable
that the NVD, CVE and RedHat web sites don't have any information or
even a link to that, I'm not distressed.

However, I'm disappointed by the implication, if true, that many of
these 1000+ CVEs could all be "RESERVED" with no public explanation
anywhere and with no intent to make them public at any point in the
future.  What was the point of using the CVE then?  If there was a need
for secrecy, I believe there should be some form of disclosure after
some time.  Think of it as declassification, which is of particular
interest to historians and academics.

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

Re: Rough Drafts of CVE Counting Documents

kseifried@redhat.com
In reply to this post by Coffin, Chris


On Thu, Aug 25, 2016 at 10:21 AM, Coffin, Chris <[hidden email]> wrote:
Kurt,

Thanks a ton for the feedback... I very much appreciate it.

FYI... I hadn't taken into account Pascal's feedback in the comments below, but I added Pascal's definition of vulnerability as I think it works very well. Thanks Pascal!


> Could we add "typically requires" instead?

I added some text to the definition. Take a look and let me know if this works for you.

> Can INC2 (Vendor acknowledgement) be expanded to include actual verification through a proof of concept/reproducer for example, or via source code examination?

I would be concerned with putting strict verification requirements at the inclusion stage. For vendor CNAs, I think they will most likely do some or all of this, and maybe we can insert this language here that mentions it. However, there may also be other CNAs reading this decision who are not the vendor or maintainer of the product/code and assembling this data or getting it from the vendor could take time if it happens at all. My feeling is that the inclusion steps should emphasize speed in assigning CVE IDs as opposed to getting things perfect up front. If a mistake is made, it can be cleaned up after the fact. Thoughts?

Sorry I meant that as OR, not AND, e.g. someone publishes a script that crashes a Linux machine and we have no idea why yet, I would say that should get a CVE asap. 
 

> INC3.1 "demonstrated" does this mean we need a reproducer?

Similar to the above, for a vendor CNA following this it is probably not much of an issue. For a CNA who is not the vendor or maintainer, such as yourself, this becomes more important obviously. I think you have said yourself that you get lots of garbage already. In my mind, "demonstrated" means can the requester properly describe the vulnerability and explain what it's impact is. I think if we force the requester to provide a PoC we may be asking for too much at this stage. As the bolded text states, this one is about trusting the researcher in their claim to a certain extent.

Ok, just wanted to make asure we were using the same value of "Demonstrated" =)
 

> INC4: can we better define public/private? E.g. what if a medical device maker plans to use a CVE for an issue that they will then inform ever user of directly? Ditto for aerospace/SCADA/etc.

Are you saying that we should soften language now to start including room for CVEs issues that will only be released to a limited group of users? I know we have had these discussions in the recent past, but my understanding was that we would wait to make this kind of change until CVE actually brought on some of these domains where this issue will come up.

I think we need to start looking at this and be ready to have in answer probably within the year or early next year, especially if we want to expand CVE to these industry types as I suspect they will have questions at a minimum.  
 

> INC5: "CVE IDs are assigned to products that are customer-controlled or customer-installable." what about on premises solutions that are locked down? I know many medical devices, high end manufacturing, etc you buy it, but you don't touch it, the company tech services it. Ditto for other regulated items like elevators (contractually most elevator maintenance involves a "if anyone but us touches it, your warranty is totally void").

This is a really great point! This is another area that I haven't really put much thought into and I don't think anyone else on the board has brought up in the recent past. Outside of the "sort of" similar idea of SaaS (and possibly other xaaS), I imagine there could be IT products (e.g., appliances and such) produced now or in the future that could fall into this category. Similar to the above comments though, should we account for this in the current rules, or should we wait until presented with this problem such as when we bring on the medical devices domain?

Again above, I think we should look into this and have an answer sooner rather then later.
 

 > CNT4: I'd like to better define the embedded code situation, e.g. libxml/gzip situations (bits of those are everywhere!).

One thing that I noticed is that the decision language did not direct the CNA to defer the report to the appropriate CNA in the case of a shared codebase that doesn't apply to the receiving CNA (i.e., the CNA following the decisions based on the report). Are you looking for more process explanation in this case or maybe more examples? If you have anything specific please feel free to pass along.

So for example where does code move from "Same codebase" to "different code base", e.g. mysql/various forks, embedded copies of X (gzip for example), I think one good sniff test is "does the patch work with no or minimal changes"?
 


Chris


From: Kurt Seifried [mailto:[hidden email]]
Sent: Wednesday, August 24, 2016 3:55 PM
To: Coffin, Chris <[hidden email]>
Cc: cve-editorial-board-list <[hidden email]>
Subject: Re: Rough Drafts of CVE Counting Documents

Some feedback:
A vulnerability in the context of the CVE program, is code that can be exploited, resulting in a negative impact to confidentiality, integrity, and availability, and that requires a code change to mitigate or address.
Some vulns are internal to the protocol and the only code change that "fixes" it is to remove the code/functionality altogether. Could we add "typically requires" instead? I'm worried about the intersection of software/API vulns that will become increasingly common (more instances of this, and people will start looking for them). 
Can INC2 (Vendor acknowledgement) be expanded to include actual verification through a proof of concept/reproducer for example, or via source code examination?
INC3.1 "demonstrated" does this mean we need a reproducer? 
INC4: can we better define public/private? E.g. what if a medical device maker plans to use a CVE for an issue that they will then inform ever user of directly? Ditto for aerospace/SCADA/etc. 
INC5: "CVE IDs are assigned to products that are customer-controlled or customer-installable." what about on premises solutions that are locked down? I know many medical devices, high end manufacturing, etc you buy it, but you don't touch it, the company tech services it. Ditto for other regulated items like elevators (contractually most elevator maintenance involves a "if anyone but us touches it, your warranty is totally void"). 
CNT4: I'd like to better define the embedded code situation, e.g. libxml/gzip situations (bits of those are everywhere!).










On Wed, Aug 24, 2016 at 2:19 PM, Coffin, Chris <mailto:[hidden email]> wrote:
All,
 
Attached is a new version of the CVE Counting for CNAs document. I  have made some changes to the counting decisions as well as provided some clarifications in certain decisions based on feedback from the CVE Team.
 
Chris
 
From: mailto:[hidden email] [mailto:[hidden email]:[hidden email]] On Behalf Of Coffin, Chris
Sent: Monday, July 25, 2016 5:03 PM
To: cve-editorial-board-list <mailto:[hidden email]>
Subject: Rough Drafts of CVE Counting Documents
 
All,
 
Sorry for the delay, these were supposed to go out last week.
 
Attached is the latest marked up version of the Simplified Counting Rules, as well as the promised very rough version of a new CVE Vulnerability Counting for CNAs document. There is still plenty of work to be done on this new document, but the main focus so far has been to develop the decision trees. The included decision trees are meant to replace the older decision trees found at https://github.com/CVEProject/docs/blob/gh-pages/cna/application-guidance.md.
 
Current thinking is that the introduction of the “independently fixable” concept obsoletes many of the older counting decisions, but we’d be interested to hear others opinions on this. Also, the inclusion rules actually grew a bit, but these all seem to be fairly straightforward.
 
The Report Type decision is something that came up during internal discussions and is probably new to everyone. An earlier version of the doc didn’t have good coverage for how to count when independently fixable resulted in No or Not Sure. The Report Type allows for common reporting cases to be handled in a somewhat uniform way. The idea is to handle the most common reports and the recommended counting action for each. We are definitely interested in hearing others thoughts on this entire counting decision, as well as the common reports and actions that are defined.
 
Like I said before, this is a very early version so I am open to any and all feedback. Thanks in advance!
 
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: mailto:[hidden email]



--

--
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
|  
Report Content as Inappropriate

RE: Rough Drafts of CVE Counting Documents

Coffin, Chris

All,

 

Harold Booth and I had a couple of private exchanges regarding the vulnerability definition for the CNA Counting document. The following is the current definition as proposed by Pascal, as well as two of the most current iterations from Harold and I. The difference is obviously in the second sentence which covers both Kurt’s and Pascal’s original comments. I think we are leaning more towards the second version since it stays focused on the weakness aspect of the definition. Any thoughts on this would be hugely appreciated.

 

#0.1 (current definition from Pascal)

A vulnerability in the context of the CVE program, is indicated by code that can be exploited, resulting in a negative impact to confidentiality, integrity, OR availability, and that requires a coding change, specification change or specification deprecation to mitigate or address.

 

#1

“A vulnerability in the context of the CVE program, is defined as any weakness in the computational logic (e.g., code) found in software or hardware devices, that could be exploited by a threat source, and result in a negative impact to the security of a system. Mitigation of the vulnerabilities in this context typically involve coding changes, but could also include specification changes or even specification deprecations (e.g., removal of affected protocols or functionality in their entirety).”

 

#2

“A vulnerability in the context of the CVE program, is defined as any weakness in the computational logic (e.g., code) found in software or hardware devices, that could be exploited by a threat source, and result in a negative impact to the security of a system. A non-exhaustive list of examples where a weakness in logic could be found is in the specification of a protocol, description of an algorithm, design or architecture of a product, implementation, circuit layout, or fabrication of the product.”

 

Thanks Harold!

 

Chris

 

From: Kurt Seifried [mailto:[hidden email]]
Sent: Thursday, August 25, 2016 1:15 PM
To: Coffin, Chris <[hidden email]>
Cc: cve-editorial-board-list <[hidden email]>
Subject: Re: Rough Drafts of CVE Counting Documents

 

 

 

On Thu, Aug 25, 2016 at 10:21 AM, Coffin, Chris <[hidden email]> wrote:

Kurt,

Thanks a ton for the feedback... I very much appreciate it.

FYI... I hadn't taken into account Pascal's feedback in the comments below, but I added Pascal's definition of vulnerability as I think it works very well. Thanks Pascal!


> Could we add "typically requires" instead?

I added some text to the definition. Take a look and let me know if this works for you.

> Can INC2 (Vendor acknowledgement) be expanded to include actual verification through a proof of concept/reproducer for example, or via source code examination?

I would be concerned with putting strict verification requirements at the inclusion stage. For vendor CNAs, I think they will most likely do some or all of this, and maybe we can insert this language here that mentions it. However, there may also be other CNAs reading this decision who are not the vendor or maintainer of the product/code and assembling this data or getting it from the vendor could take time if it happens at all. My feeling is that the inclusion steps should emphasize speed in assigning CVE IDs as opposed to getting things perfect up front. If a mistake is made, it can be cleaned up after the fact. Thoughts?

 

Sorry I meant that as OR, not AND, e.g. someone publishes a script that crashes a Linux machine and we have no idea why yet, I would say that should get a CVE asap. 

 


> INC3.1 "demonstrated" does this mean we need a reproducer?

Similar to the above, for a vendor CNA following this it is probably not much of an issue. For a CNA who is not the vendor or maintainer, such as yourself, this becomes more important obviously. I think you have said yourself that you get lots of garbage already. In my mind, "demonstrated" means can the requester properly describe the vulnerability and explain what it's impact is. I think if we force the requester to provide a PoC we may be asking for too much at this stage. As the bolded text states, this one is about trusting the researcher in their claim to a certain extent.

 

Ok, just wanted to make asure we were using the same value of "Demonstrated" =)

 


> INC4: can we better define public/private? E.g. what if a medical device maker plans to use a CVE for an issue that they will then inform ever user of directly? Ditto for aerospace/SCADA/etc.

Are you saying that we should soften language now to start including room for CVEs issues that will only be released to a limited group of users? I know we have had these discussions in the recent past, but my understanding was that we would wait to make this kind of change until CVE actually brought on some of these domains where this issue will come up.

 

I think we need to start looking at this and be ready to have in answer probably within the year or early next year, especially if we want to expand CVE to these industry types as I suspect they will have questions at a minimum.  

 


> INC5: "CVE IDs are assigned to products that are customer-controlled or customer-installable." what about on premises solutions that are locked down? I know many medical devices, high end manufacturing, etc you buy it, but you don't touch it, the company tech services it. Ditto for other regulated items like elevators (contractually most elevator maintenance involves a "if anyone but us touches it, your warranty is totally void").

This is a really great point! This is another area that I haven't really put much thought into and I don't think anyone else on the board has brought up in the recent past. Outside of the "sort of" similar idea of SaaS (and possibly other xaaS), I imagine there could be IT products (e.g., appliances and such) produced now or in the future that could fall into this category. Similar to the above comments though, should we account for this in the current rules, or should we wait until presented with this problem such as when we bring on the medical devices domain?

 

Again above, I think we should look into this and have an answer sooner rather then later.

 


 > CNT4: I'd like to better define the embedded code situation, e.g. libxml/gzip situations (bits of those are everywhere!).

One thing that I noticed is that the decision language did not direct the CNA to defer the report to the appropriate CNA in the case of a shared codebase that doesn't apply to the receiving CNA (i.e., the CNA following the decisions based on the report). Are you looking for more process explanation in this case or maybe more examples? If you have anything specific please feel free to pass along.

 

So for example where does code move from "Same codebase" to "different code base", e.g. mysql/various forks, embedded copies of X (gzip for example), I think one good sniff test is "does the patch work with no or minimal changes"?

 



Chris


From: Kurt Seifried [mailto:[hidden email]]
Sent: Wednesday, August 24, 2016 3:55 PM
To: Coffin, Chris <[hidden email]>
Cc: cve-editorial-board-list <[hidden email]>
Subject: Re: Rough Drafts of CVE Counting Documents

Some feedback:
A vulnerability in the context of the CVE program, is code that can be exploited, resulting in a negative impact to confidentiality, integrity, and availability, and that requires a code change to mitigate or address.
Some vulns are internal to the protocol and the only code change that "fixes" it is to remove the code/functionality altogether. Could we add "typically requires" instead? I'm worried about the intersection of software/API vulns that will become increasingly common (more instances of this, and people will start looking for them). 
Can INC2 (Vendor acknowledgement) be expanded to include actual verification through a proof of concept/reproducer for example, or via source code examination?
INC3.1 "demonstrated" does this mean we need a reproducer? 
INC4: can we better define public/private? E.g. what if a medical device maker plans to use a CVE for an issue that they will then inform ever user of directly? Ditto for aerospace/SCADA/etc. 
INC5: "CVE IDs are assigned to products that are customer-controlled or customer-installable." what about on premises solutions that are locked down? I know many medical devices, high end manufacturing, etc you buy it, but you don't touch it, the company tech services it. Ditto for other regulated items like elevators (contractually most elevator maintenance involves a "if anyone but us touches it, your warranty is totally void"). 
CNT4: I'd like to better define the embedded code situation, e.g. libxml/gzip situations (bits of those are everywhere!).










On Wed, Aug 24, 2016 at 2:19 PM, Coffin, Chris <mailto:[hidden email]> wrote:
All,
 
Attached is a new version of the CVE Counting for CNAs document. I  have made some changes to the counting decisions as well as provided some clarifications in certain decisions based on feedback from the CVE Team.
 
Chris
 
From: mailto:[hidden email] [mailto:[hidden email]:[hidden email]] On Behalf Of Coffin, Chris
Sent: Monday, July 25, 2016 5:03 PM
To: cve-editorial-board-list <mailto:[hidden email]>
Subject: Rough Drafts of CVE Counting Documents
 
All,
 
Sorry for the delay, these were supposed to go out last week.
 
Attached is the latest marked up version of the Simplified Counting Rules, as well as the promised very rough version of a new CVE Vulnerability Counting for CNAs document. There is still plenty of work to be done on this new document, but the main focus so far has been to develop the decision trees. The included decision trees are meant to replace the older decision trees found at https://github.com/CVEProject/docs/blob/gh-pages/cna/application-guidance.md.
 
Current thinking is that the introduction of the “independently fixable” concept obsoletes many of the older counting decisions, but we’d be interested to hear others opinions on this. Also, the inclusion rules actually grew a bit, but these all seem to be fairly straightforward.
 
The Report Type decision is something that came up during internal discussions and is probably new to everyone. An earlier version of the doc didn’t have good coverage for how to count when independently fixable resulted in No or Not Sure. The Report Type allows for common reporting cases to be handled in a somewhat uniform way. The idea is to handle the most common reports and the recommended counting action for each. We are definitely interested in hearing others thoughts on this entire counting decision, as well as the common reports and actions that are defined.
 
Like I said before, this is a very early version so I am open to any and all feedback. Thanks in advance!
 
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: mailto:[hidden email]



 

--

 

--
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
|  
Report Content as Inappropriate

Re: Rough Drafts of CVE Counting Documents

kseifried@redhat.com
I would make it more generic:

weakness in the computational logic (e.g., code) -> weakness in the system

e.g. intersection vulns where unexpected mixing of behaviors result in a problem. 

On Mon, Aug 29, 2016 at 12:01 PM, Coffin, Chris <[hidden email]> wrote:

All,

 

Harold Booth and I had a couple of private exchanges regarding the vulnerability definition for the CNA Counting document. The following is the current definition as proposed by Pascal, as well as two of the most current iterations from Harold and I. The difference is obviously in the second sentence which covers both Kurt’s and Pascal’s original comments. I think we are leaning more towards the second version since it stays focused on the weakness aspect of the definition. Any thoughts on this would be hugely appreciated.

 

#0.1 (current definition from Pascal)

A vulnerability in the context of the CVE program, is indicated by code that can be exploited, resulting in a negative impact to confidentiality, integrity, OR availability, and that requires a coding change, specification change or specification deprecation to mitigate or address.

 

#1

“A vulnerability in the context of the CVE program, is defined as any weakness in the computational logic (e.g., code) found in software or hardware devices, that could be exploited by a threat source, and result in a negative impact to the security of a system. Mitigation of the vulnerabilities in this context typically involve coding changes, but could also include specification changes or even specification deprecations (e.g., removal of affected protocols or functionality in their entirety).”

 

#2

“A vulnerability in the context of the CVE program, is defined as any weakness in the computational logic (e.g., code) found in software or hardware devices, that could be exploited by a threat source, and result in a negative impact to the security of a system. A non-exhaustive list of examples where a weakness in logic could be found is in the specification of a protocol, description of an algorithm, design or architecture of a product, implementation, circuit layout, or fabrication of the product.”

 

Thanks Harold!

 

Chris

 

From: Kurt Seifried [mailto:[hidden email]]
Sent: Thursday, August 25, 2016 1:15 PM


To: Coffin, Chris <[hidden email]>
Cc: cve-editorial-board-list <[hidden email]>
Subject: Re: Rough Drafts of CVE Counting Documents

 

 

 

On Thu, Aug 25, 2016 at 10:21 AM, Coffin, Chris <[hidden email]> wrote:

Kurt,

Thanks a ton for the feedback... I very much appreciate it.

FYI... I hadn't taken into account Pascal's feedback in the comments below, but I added Pascal's definition of vulnerability as I think it works very well. Thanks Pascal!


> Could we add "typically requires" instead?

I added some text to the definition. Take a look and let me know if this works for you.

> Can INC2 (Vendor acknowledgement) be expanded to include actual verification through a proof of concept/reproducer for example, or via source code examination?

I would be concerned with putting strict verification requirements at the inclusion stage. For vendor CNAs, I think they will most likely do some or all of this, and maybe we can insert this language here that mentions it. However, there may also be other CNAs reading this decision who are not the vendor or maintainer of the product/code and assembling this data or getting it from the vendor could take time if it happens at all. My feeling is that the inclusion steps should emphasize speed in assigning CVE IDs as opposed to getting things perfect up front. If a mistake is made, it can be cleaned up after the fact. Thoughts?

 

Sorry I meant that as OR, not AND, e.g. someone publishes a script that crashes a Linux machine and we have no idea why yet, I would say that should get a CVE asap. 

 


> INC3.1 "demonstrated" does this mean we need a reproducer?

Similar to the above, for a vendor CNA following this it is probably not much of an issue. For a CNA who is not the vendor or maintainer, such as yourself, this becomes more important obviously. I think you have said yourself that you get lots of garbage already. In my mind, "demonstrated" means can the requester properly describe the vulnerability and explain what it's impact is. I think if we force the requester to provide a PoC we may be asking for too much at this stage. As the bolded text states, this one is about trusting the researcher in their claim to a certain extent.

 

Ok, just wanted to make asure we were using the same value of "Demonstrated" =)

 


> INC4: can we better define public/private? E.g. what if a medical device maker plans to use a CVE for an issue that they will then inform ever user of directly? Ditto for aerospace/SCADA/etc.

Are you saying that we should soften language now to start including room for CVEs issues that will only be released to a limited group of users? I know we have had these discussions in the recent past, but my understanding was that we would wait to make this kind of change until CVE actually brought on some of these domains where this issue will come up.

 

I think we need to start looking at this and be ready to have in answer probably within the year or early next year, especially if we want to expand CVE to these industry types as I suspect they will have questions at a minimum.  

 


> INC5: "CVE IDs are assigned to products that are customer-controlled or customer-installable." what about on premises solutions that are locked down? I know many medical devices, high end manufacturing, etc you buy it, but you don't touch it, the company tech services it. Ditto for other regulated items like elevators (contractually most elevator maintenance involves a "if anyone but us touches it, your warranty is totally void").

This is a really great point! This is another area that I haven't really put much thought into and I don't think anyone else on the board has brought up in the recent past. Outside of the "sort of" similar idea of SaaS (and possibly other xaaS), I imagine there could be IT products (e.g., appliances and such) produced now or in the future that could fall into this category. Similar to the above comments though, should we account for this in the current rules, or should we wait until presented with this problem such as when we bring on the medical devices domain?

 

Again above, I think we should look into this and have an answer sooner rather then later.

 


 > CNT4: I'd like to better define the embedded code situation, e.g. libxml/gzip situations (bits of those are everywhere!).

One thing that I noticed is that the decision language did not direct the CNA to defer the report to the appropriate CNA in the case of a shared codebase that doesn't apply to the receiving CNA (i.e., the CNA following the decisions based on the report). Are you looking for more process explanation in this case or maybe more examples? If you have anything specific please feel free to pass along.

 

So for example where does code move from "Same codebase" to "different code base", e.g. mysql/various forks, embedded copies of X (gzip for example), I think one good sniff test is "does the patch work with no or minimal changes"?

 



Chris


From: Kurt Seifried [mailto:[hidden email]]
Sent: Wednesday, August 24, 2016 3:55 PM
To: Coffin, Chris <[hidden email]>
Cc: cve-editorial-board-list <[hidden email]>
Subject: Re: Rough Drafts of CVE Counting Documents

Some feedback:
A vulnerability in the context of the CVE program, is code that can be exploited, resulting in a negative impact to confidentiality, integrity, and availability, and that requires a code change to mitigate or address.
Some vulns are internal to the protocol and the only code change that "fixes" it is to remove the code/functionality altogether. Could we add "typically requires" instead? I'm worried about the intersection of software/API vulns that will become increasingly common (more instances of this, and people will start looking for them). 
Can INC2 (Vendor acknowledgement) be expanded to include actual verification through a proof of concept/reproducer for example, or via source code examination?
INC3.1 "demonstrated" does this mean we need a reproducer? 
INC4: can we better define public/private? E.g. what if a medical device maker plans to use a CVE for an issue that they will then inform ever user of directly? Ditto for aerospace/SCADA/etc. 
INC5: "CVE IDs are assigned to products that are customer-controlled or customer-installable." what about on premises solutions that are locked down? I know many medical devices, high end manufacturing, etc you buy it, but you don't touch it, the company tech services it. Ditto for other regulated items like elevators (contractually most elevator maintenance involves a "if anyone but us touches it, your warranty is totally void"). 
CNT4: I'd like to better define the embedded code situation, e.g. libxml/gzip situations (bits of those are everywhere!).










On Wed, Aug 24, 2016 at 2:19 PM, Coffin, Chris <mailto:[hidden email]> wrote:
All,
 
Attached is a new version of the CVE Counting for CNAs document. I  have made some changes to the counting decisions as well as provided some clarifications in certain decisions based on feedback from the CVE Team.
 
Chris
 
From: mailto:[hidden email] [mailto:[hidden email]:[hidden email]] On Behalf Of Coffin, Chris
Sent: Monday, July 25, 2016 5:03 PM
To: cve-editorial-board-list <mailto:[hidden email]>
Subject: Rough Drafts of CVE Counting Documents
 
All,
 
Sorry for the delay, these were supposed to go out last week.
 
Attached is the latest marked up version of the Simplified Counting Rules, as well as the promised very rough version of a new CVE Vulnerability Counting for CNAs document. There is still plenty of work to be done on this new document, but the main focus so far has been to develop the decision trees. The included decision trees are meant to replace the older decision trees found at https://github.com/CVEProject/docs/blob/gh-pages/cna/application-guidance.md.
 
Current thinking is that the introduction of the “independently fixable” concept obsoletes many of the older counting decisions, but we’d be interested to hear others opinions on this. Also, the inclusion rules actually grew a bit, but these all seem to be fairly straightforward.
 
The Report Type decision is something that came up during internal discussions and is probably new to everyone. An earlier version of the doc didn’t have good coverage for how to count when independently fixable resulted in No or Not Sure. The Report Type allows for common reporting cases to be handled in a somewhat uniform way. The idea is to handle the most common reports and the recommended counting action for each. We are definitely interested in hearing others thoughts on this entire counting decision, as well as the common reports and actions that are defined.
 
Like I said before, this is a very early version so I am open to any and all feedback. Thanks in advance!
 
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: mailto:[hidden email]



 

--

 

--
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]




--

--
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
|  
Report Content as Inappropriate

Re: Rough Drafts of CVE Counting Documents

Pascal Meunier
In reply to this post by Coffin, Chris
The change to #1 and #2, and even more with the other change suggested
by Kurt ("weakness in the system"), would greatly increase the scope for
the CVE.  CNAs will issue CVEs for any and all hardware vulnerable to
the "row hammer effect", for example, and not just for the software that
is particularly vulnerable (e.g., CVE-2015-0565).  This could create an
explosion of IDs requests, as some hardware combinations may make things
worse or better -- will we keep track of all combinations?  Next we'll
get ID requests for overclocked hardware (if overclocking is allowed),
or hardware under borderline or unusual temperatures, dirty hardware,
under brownouts and for every device that hangs, crashes or reboots
because it could indicate a vulnerability.  Will boards that have common
chips be grouped under the same CVE ID?  How different is different
enough so you'll issue 2 or 2000 different IDs?  The counting document
doesn't address hardware, I think.  It seems we just almost stumbled and
now we want to tackle a parcours du combattant.

Changing too much too quickly can be a recipe for disaster, or at least
great confusion and inadequacy.  I suggest pacing ourselves a bit (pun
intended) and waiting until the recent changes prove themselves viable
and stable before making such a change of scope.  At least, the change
in scope for the project should be something planned and directly
decided upon instead of being incidental to revising a definition.

As a very minor wording comment, of little importance compared to the
above, I think that the inclusion of "by a threat source," doesn't help
and could be removed.

Pascal



On 08/29/2016 02:01 PM, Coffin, Chris wrote:

> All,
>
> Harold Booth and I had a couple of private exchanges regarding the vulnerability definition for the CNA Counting document. The following is the current definition as proposed by Pascal, as well as two of the most current iterations from Harold and I. The difference is obviously in the second sentence which covers both Kurt’s and Pascal’s original comments. I think we are leaning more towards the second version since it stays focused on the weakness aspect of the definition. Any thoughts on this would be hugely appreciated.
>
> #0.1 (current definition from Pascal)
> “A vulnerability in the context of the CVE program, is indicated by code that can be exploited, resulting in a negative impact to confidentiality, integrity, OR availability, and that requires a coding change, specification change or specification deprecation to mitigate or address.”
>
> #1
> “A vulnerability in the context of the CVE program, is defined as any weakness in the computational logic (e.g., code) found in software or hardware devices, that could be exploited by a threat source, and result in a negative impact to the security of a system. Mitigation of the vulnerabilities in this context typically involve coding changes, but could also include specification changes or even specification deprecations (e.g., removal of affected protocols or functionality in their entirety).”
>
> #2
> “A vulnerability in the context of the CVE program, is defined as any weakness in the computational logic (e.g., code) found in software or hardware devices, that could be exploited by a threat source, and result in a negative impact to the security of a system. A non-exhaustive list of examples where a weakness in logic could be found is in the specification of a protocol, description of an algorithm, design or architecture of a product, implementation, circuit layout, or fabrication of the product.”
>
> Thanks Harold!
>
> Chris
>
> From: Kurt Seifried [mailto:[hidden email]]
> Sent: Thursday, August 25, 2016 1:15 PM
> To: Coffin, Chris <[hidden email]>
> Cc: cve-editorial-board-list <[hidden email]>
> Subject: Re: Rough Drafts of CVE Counting Documents
>
>
>
> On Thu, Aug 25, 2016 at 10:21 AM, Coffin, Chris <[hidden email]<mailto:[hidden email]>> wrote:
> Kurt,
>
> Thanks a ton for the feedback... I very much appreciate it.
>
> FYI... I hadn't taken into account Pascal's feedback in the comments below, but I added Pascal's definition of vulnerability as I think it works very well. Thanks Pascal!
>
>
>> Could we add "typically requires" instead?
>
> I added some text to the definition. Take a look and let me know if this works for you.
>
>> Can INC2 (Vendor acknowledgement) be expanded to include actual verification through a proof of concept/reproducer for example, or via source code examination?
>
> I would be concerned with putting strict verification requirements at the inclusion stage. For vendor CNAs, I think they will most likely do some or all of this, and maybe we can insert this language here that mentions it. However, there may also be other CNAs reading this decision who are not the vendor or maintainer of the product/code and assembling this data or getting it from the vendor could take time if it happens at all. My feeling is that the inclusion steps should emphasize speed in assigning CVE IDs as opposed to getting things perfect up front. If a mistake is made, it can be cleaned up after the fact. Thoughts?
>
> Sorry I meant that as OR, not AND, e.g. someone publishes a script that crashes a Linux machine and we have no idea why yet, I would say that should get a CVE asap.
>
>
>> INC3.1 "demonstrated" does this mean we need a reproducer?
>
> Similar to the above, for a vendor CNA following this it is probably not much of an issue. For a CNA who is not the vendor or maintainer, such as yourself, this becomes more important obviously. I think you have said yourself that you get lots of garbage already. In my mind, "demonstrated" means can the requester properly describe the vulnerability and explain what it's impact is. I think if we force the requester to provide a PoC we may be asking for too much at this stage. As the bolded text states, this one is about trusting the researcher in their claim to a certain extent.
>
> Ok, just wanted to make asure we were using the same value of "Demonstrated" =)
>
>
>> INC4: can we better define public/private? E.g. what if a medical device maker plans to use a CVE for an issue that they will then inform ever user of directly? Ditto for aerospace/SCADA/etc.
>
> Are you saying that we should soften language now to start including room for CVEs issues that will only be released to a limited group of users? I know we have had these discussions in the recent past, but my understanding was that we would wait to make this kind of change until CVE actually brought on some of these domains where this issue will come up.
>
> I think we need to start looking at this and be ready to have in answer probably within the year or early next year, especially if we want to expand CVE to these industry types as I suspect they will have questions at a minimum.
>
>
>> INC5: "CVE IDs are assigned to products that are customer-controlled or customer-installable." what about on premises solutions that are locked down? I know many medical devices, high end manufacturing, etc you buy it, but you don't touch it, the company tech services it. Ditto for other regulated items like elevators (contractually most elevator maintenance involves a "if anyone but us touches it, your warranty is totally void").
>
> This is a really great point! This is another area that I haven't really put much thought into and I don't think anyone else on the board has brought up in the recent past. Outside of the "sort of" similar idea of SaaS (and possibly other xaaS), I imagine there could be IT products (e.g., appliances and such) produced now or in the future that could fall into this category. Similar to the above comments though, should we account for this in the current rules, or should we wait until presented with this problem such as when we bring on the medical devices domain?
>
> Again above, I think we should look into this and have an answer sooner rather then later.
>
>
>  > CNT4: I'd like to better define the embedded code situation, e.g. libxml/gzip situations (bits of those are everywhere!).
>
> One thing that I noticed is that the decision language did not direct the CNA to defer the report to the appropriate CNA in the case of a shared codebase that doesn't apply to the receiving CNA (i.e., the CNA following the decisions based on the report). Are you looking for more process explanation in this case or maybe more examples? If you have anything specific please feel free to pass along.
>
> So for example where does code move from "Same codebase" to "different code base", e.g. mysql/various forks, embedded copies of X (gzip for example), I think one good sniff test is "does the patch work with no or minimal changes"?
>
>
>
> Chris
>
>
> From: Kurt Seifried [mailto:[hidden email]<mailto:[hidden email]>]
> Sent: Wednesday, August 24, 2016 3:55 PM
> To: Coffin, Chris <[hidden email]<mailto:[hidden email]>>
> Cc: cve-editorial-board-list <[hidden email]<mailto:[hidden email]>>
> Subject: Re: Rough Drafts of CVE Counting Documents
>
> Some feedback:
> A vulnerability in the context of the CVE program, is code that can be exploited, resulting in a negative impact to confidentiality, integrity, and availability, and that requires a code change to mitigate or address.
> Some vulns are internal to the protocol and the only code change that "fixes" it is to remove the code/functionality altogether. Could we add "typically requires" instead? I'm worried about the intersection of software/API vulns that will become increasingly common (more instances of this, and people will start looking for them).
> Can INC2 (Vendor acknowledgement) be expanded to include actual verification through a proof of concept/reproducer for example, or via source code examination?
> INC3.1 "demonstrated" does this mean we need a reproducer?
> INC4: can we better define public/private? E.g. what if a medical device maker plans to use a CVE for an issue that they will then inform ever user of directly? Ditto for aerospace/SCADA/etc.
> INC5: "CVE IDs are assigned to products that are customer-controlled or customer-installable." what about on premises solutions that are locked down? I know many medical devices, high end manufacturing, etc you buy it, but you don't touch it, the company tech services it. Ditto for other regulated items like elevators (contractually most elevator maintenance involves a "if anyone but us touches it, your warranty is totally void").
> CNT4: I'd like to better define the embedded code situation, e.g. libxml/gzip situations (bits of those are everywhere!).
>
>
>
>
>
>
>
>
>
>
> On Wed, Aug 24, 2016 at 2:19 PM, Coffin, Chris <mailto:[hidden email]<mailto:[hidden email]>> wrote:
> All,
>
> Attached is a new version of the CVE Counting for CNAs document. I  have made some changes to the counting decisions as well as provided some clarifications in certain decisions based on feedback from the CVE Team.
>
> Chris
>
> From: mailto:[hidden email]<mailto:[hidden email]> [mailto:mailto<mailto:mailto>:[hidden email]<mailto:[hidden email]>] On Behalf Of Coffin, Chris
> Sent: Monday, July 25, 2016 5:03 PM
> To: cve-editorial-board-list <mailto:[hidden email]<mailto:[hidden email]>>
> Subject: Rough Drafts of CVE Counting Documents
>
> All,
>
> Sorry for the delay, these were supposed to go out last week.
>
> Attached is the latest marked up version of the Simplified Counting Rules, as well as the promised very rough version of a new CVE Vulnerability Counting for CNAs document. There is still plenty of work to be done on this new document, but the main focus so far has been to develop the decision trees. The included decision trees are meant to replace the older decision trees found at https://github.com/CVEProject/docs/blob/gh-pages/cna/application-guidance.md.
>
> Current thinking is that the introduction of the “independently fixable” concept obsoletes many of the older counting decisions, but we’d be interested to hear others opinions on this. Also, the inclusion rules actually grew a bit, but these all seem to be fairly straightforward.
>
> The Report Type decision is something that came up during internal discussions and is probably new to everyone. An earlier version of the doc didn’t have good coverage for how to count when independently fixable resulted in No or Not Sure. The Report Type allows for common reporting cases to be handled in a somewhat uniform way. The idea is to handle the most common reports and the recommended counting action for each. We are definitely interested in hearing others thoughts on this entire counting decision, as well as the common reports and actions that are defined.
>
> Like I said before, this is a very early version so I am open to any and all feedback. Thanks in advance!
>
> 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: mailto:[hidden email]<mailto:[hidden email]>
>
>
>
> --
>
> --
> 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]<mailto:[hidden email]>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Rough Drafts of CVE Counting Documents

kseifried@redhat.com


On Mon, Aug 29, 2016 at 1:10 PM, Pascal Meunier <[hidden email]> wrote:

The change to #1 and #2, and even more with the other change suggested by Kurt ("weakness in the system"), would greatly increase the scope for the CVE.  CNAs will issue CVEs for any and all hardware vulnerable to the "row hammer effect", for example, and not just for the software that is particularly vulnerable (e.g., CVE-2015-0565).  This could create an explosion of IDs requests, as some hardware combinations may make things worse or better -- will we keep track of all combinations?  Next we'll get ID requests for overclocked hardware (if overclocking is allowed), or hardware under borderline or unusual temperatures, dirty hardware, under brownouts and for every device that hangs, crashes or reboots because it could indicate a vulnerability.  Will boards that have common chips be grouped under the same CVE ID?  How different is different enough so you'll issue 2 or 2000 different IDs?  The counting document doesn't address hardware, I think.  It seems we just almost stumbled and now we want to tackle a parcours du combattant.

Changing too much too quickly can be a recipe for disaster, or at least great confusion and inadequacy.  I suggest pacing ourselves a bit (pun intended) and waiting until the recent changes prove themselves viable and stable before making such a change of scope.  At least, the change in scope for the project should be something planned and directly decided upon instead of being incidental to revising a definition.

As a very minor wording comment, of little importance compared to the above, I think that the inclusion of "by a threat source," doesn't help and could be removed.


Some comments:

1) using SWID will help alleviate a lot of this identification related issues
2) we can always have "protocol" level CVEs, rowhammer seems to be a good candidate for that type of thing
3) people would have to ask for these CVEs/want to create them, we don't have to say yes, or we can simply require a very well formed request (e.g. details, SWID, etc.) so there is minimal "cost" to assign the CVE

as for the brownout stuff I'd put it into the same class as the "program opens a file and crashes", if that's the only problem (e.g. no code exec), aka "don't unplug your system/submerge it in water/cook it in an oven if you want it to behave properly", I would also say that these things are already well covered/documented in the operating conditions documented for most electronics (e.g. non condensing humidity, and what temps it'll run at). 
 

Pascal



On 08/29/2016 02:01 PM, Coffin, Chris wrote:
All,

Harold Booth and I had a couple of private exchanges regarding the vulnerability definition for the CNA Counting document. The following is the current definition as proposed by Pascal, as well as two of the most current iterations from Harold and I. The difference is obviously in the second sentence which covers both Kurt’s and Pascal’s original comments. I think we are leaning more towards the second version since it stays focused on the weakness aspect of the definition. Any thoughts on this would be hugely appreciated.

#0.1 (current definition from Pascal)
“A vulnerability in the context of the CVE program, is indicated by code that can be exploited, resulting in a negative impact to confidentiality, integrity, OR availability, and that requires a coding change, specification change or specification deprecation to mitigate or address.”

#1
“A vulnerability in the context of the CVE program, is defined as any weakness in the computational logic (e.g., code) found in software or hardware devices, that could be exploited by a threat source, and result in a negative impact to the security of a system. Mitigation of the vulnerabilities in this context typically involve coding changes, but could also include specification changes or even specification deprecations (e.g., removal of affected protocols or functionality in their entirety).”

#2
“A vulnerability in the context of the CVE program, is defined as any weakness in the computational logic (e.g., code) found in software or hardware devices, that could be exploited by a threat source, and result in a negative impact to the security of a system. A non-exhaustive list of examples where a weakness in logic could be found is in the specification of a protocol, description of an algorithm, design or architecture of a product, implementation, circuit layout, or fabrication of the product.”

Thanks Harold!

Chris

From: Kurt Seifried [mailto:[hidden email]]
Sent: Thursday, August 25, 2016 1:15 PM
To: Coffin, Chris <[hidden email]>
Cc: cve-editorial-board-list <[hidden email]>
Subject: Re: Rough Drafts of CVE Counting Documents



On Thu, Aug 25, 2016 at 10:21 AM, Coffin, Chris <[hidden email]<mailto:[hidden email]>> wrote:
Kurt,

Thanks a ton for the feedback... I very much appreciate it.

FYI... I hadn't taken into account Pascal's feedback in the comments below, but I added Pascal's definition of vulnerability as I think it works very well. Thanks Pascal!


Could we add "typically requires" instead?

I added some text to the definition. Take a look and let me know if this works for you.

Can INC2 (Vendor acknowledgement) be expanded to include actual verification through a proof of concept/reproducer for example, or via source code examination?

I would be concerned with putting strict verification requirements at the inclusion stage. For vendor CNAs, I think they will most likely do some or all of this, and maybe we can insert this language here that mentions it. However, there may also be other CNAs reading this decision who are not the vendor or maintainer of the product/code and assembling this data or getting it from the vendor could take time if it happens at all. My feeling is that the inclusion steps should emphasize speed in assigning CVE IDs as opposed to getting things perfect up front. If a mistake is made, it can be cleaned up after the fact. Thoughts?

Sorry I meant that as OR, not AND, e.g. someone publishes a script that crashes a Linux machine and we have no idea why yet, I would say that should get a CVE asap.


INC3.1 "demonstrated" does this mean we need a reproducer?

Similar to the above, for a vendor CNA following this it is probably not much of an issue. For a CNA who is not the vendor or maintainer, such as yourself, this becomes more important obviously. I think you have said yourself that you get lots of garbage already. In my mind, "demonstrated" means can the requester properly describe the vulnerability and explain what it's impact is. I think if we force the requester to provide a PoC we may be asking for too much at this stage. As the bolded text states, this one is about trusting the researcher in their claim to a certain extent.

Ok, just wanted to make asure we were using the same value of "Demonstrated" =)


INC4: can we better define public/private? E.g. what if a medical device maker plans to use a CVE for an issue that they will then inform ever user of directly? Ditto for aerospace/SCADA/etc.

Are you saying that we should soften language now to start including room for CVEs issues that will only be released to a limited group of users? I know we have had these discussions in the recent past, but my understanding was that we would wait to make this kind of change until CVE actually brought on some of these domains where this issue will come up.

I think we need to start looking at this and be ready to have in answer probably within the year or early next year, especially if we want to expand CVE to these industry types as I suspect they will have questions at a minimum.


INC5: "CVE IDs are assigned to products that are customer-controlled or customer-installable." what about on premises solutions that are locked down? I know many medical devices, high end manufacturing, etc you buy it, but you don't touch it, the company tech services it. Ditto for other regulated items like elevators (contractually most elevator maintenance involves a "if anyone but us touches it, your warranty is totally void").

This is a really great point! This is another area that I haven't really put much thought into and I don't think anyone else on the board has brought up in the recent past. Outside of the "sort of" similar idea of SaaS (and possibly other xaaS), I imagine there could be IT products (e.g., appliances and such) produced now or in the future that could fall into this category. Similar to the above comments though, should we account for this in the current rules, or should we wait until presented with this problem such as when we bring on the medical devices domain?

Again above, I think we should look into this and have an answer sooner rather then later.


 > CNT4: I'd like to better define the embedded code situation, e.g. libxml/gzip situations (bits of those are everywhere!).

One thing that I noticed is that the decision language did not direct the CNA to defer the report to the appropriate CNA in the case of a shared codebase that doesn't apply to the receiving CNA (i.e., the CNA following the decisions based on the report). Are you looking for more process explanation in this case or maybe more examples? If you have anything specific please feel free to pass along.

So for example where does code move from "Same codebase" to "different code base", e.g. mysql/various forks, embedded copies of X (gzip for example), I think one good sniff test is "does the patch work with no or minimal changes"?



Chris


From: Kurt Seifried [mailto:[hidden email]<mailto:[hidden email]>]
Sent: Wednesday, August 24, 2016 3:55 PM
To: Coffin, Chris <[hidden email]<mailto:[hidden email]>>
Cc: cve-editorial-board-list <[hidden email]<mailto:[hidden email]>>
Subject: Re: Rough Drafts of CVE Counting Documents

Some feedback:
A vulnerability in the context of the CVE program, is code that can be exploited, resulting in a negative impact to confidentiality, integrity, and availability, and that requires a code change to mitigate or address.
Some vulns are internal to the protocol and the only code change that "fixes" it is to remove the code/functionality altogether. Could we add "typically requires" instead? I'm worried about the intersection of software/API vulns that will become increasingly common (more instances of this, and people will start looking for them).
Can INC2 (Vendor acknowledgement) be expanded to include actual verification through a proof of concept/reproducer for example, or via source code examination?
INC3.1 "demonstrated" does this mean we need a reproducer?
INC4: can we better define public/private? E.g. what if a medical device maker plans to use a CVE for an issue that they will then inform ever user of directly? Ditto for aerospace/SCADA/etc.
INC5: "CVE IDs are assigned to products that are customer-controlled or customer-installable." what about on premises solutions that are locked down? I know many medical devices, high end manufacturing, etc you buy it, but you don't touch it, the company tech services it. Ditto for other regulated items like elevators (contractually most elevator maintenance involves a "if anyone but us touches it, your warranty is totally void").
CNT4: I'd like to better define the embedded code situation, e.g. libxml/gzip situations (bits of those are everywhere!).










On Wed, Aug 24, 2016 at 2:19 PM, Coffin, Chris <mailto:[hidden email]<mailto:[hidden email]>> wrote:
All,

Attached is a new version of the CVE Counting for CNAs document. I  have made some changes to the counting decisions as well as provided some clarifications in certain decisions based on feedback from the CVE Team.

Chris

From: mailto:[hidden email]<mailto:[hidden email]> [mailto:[hidden email]<mailto:[hidden email]>:[hidden email]<mailto:[hidden email]>] On Behalf Of Coffin, Chris
Sent: Monday, July 25, 2016 5:03 PM
To: cve-editorial-board-list <mailto:[hidden email]<mailto:[hidden email]>>
Subject: Rough Drafts of CVE Counting Documents

All,

Sorry for the delay, these were supposed to go out last week.

Attached is the latest marked up version of the Simplified Counting Rules, as well as the promised very rough version of a new CVE Vulnerability Counting for CNAs document. There is still plenty of work to be done on this new document, but the main focus so far has been to develop the decision trees. The included decision trees are meant to replace the older decision trees found at https://github.com/CVEProject/docs/blob/gh-pages/cna/application-guidance.md.

Current thinking is that the introduction of the “independently fixable” concept obsoletes many of the older counting decisions, but we’d be interested to hear others opinions on this. Also, the inclusion rules actually grew a bit, but these all seem to be fairly straightforward.

The Report Type decision is something that came up during internal discussions and is probably new to everyone. An earlier version of the doc didn’t have good coverage for how to count when independently fixable resulted in No or Not Sure. The Report Type allows for common reporting cases to be handled in a somewhat uniform way. The idea is to handle the most common reports and the recommended counting action for each. We are definitely interested in hearing others thoughts on this entire counting decision, as well as the common reports and actions that are defined.

Like I said before, this is a very early version so I am open to any and all feedback. Thanks in advance!

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: mailto:[hidden email]<mailto:[hidden email]>



--

--
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]<mailto:[hidden email]>




--

--
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
|  
Report Content as Inappropriate

RE: Rough Drafts of CVE Counting Documents

Coffin, Chris
In reply to this post by Pascal Meunier
Pascal,

These are great observations and I do agree with your point of view. I have spent a good part of yesterday and today thinking about the best way to address this. One way to handle it might be to leave the door open in regards to hardware, in other words, just state that "some" hardware is included. This allows us to reserve the right to refuse assignments for hardware specific issues like the ones you mentioned. I have crafted a new version of the description below that may or may not satisfy your current concerns in this regard.

Like Kurt had added, requesters will still have to ask CNAs for CVEs and the CNAs don't have to provide them in cases where it isn't applicable or doesn't make sense. Additionally, we could add an inclusion decision that could specifically exclude certain situations (e.g., environmental impacts to hardware, etc.).

#3
"A vulnerability in the context of the CVE program, is defined as a weakness in the computational logic (e.g., code) found in software and some hardware components (e.g., firmware),  and when exploited results in a negative impact to confidentiality, integrity, OR availability. Mitigation of the vulnerabilities in this context typically involve coding changes, but could also include specification changes or even specification deprecations (e.g., removal of affected protocols or functionality in their entirety).

Chris

-----Original Message-----
From: Pascal Meunier [mailto:[hidden email]]
Sent: Monday, August 29, 2016 2:10 PM
To: Coffin, Chris <[hidden email]>; Kurt Seifried <[hidden email]>; Booth, Harold (Fed) <[hidden email]>
Cc: cve-editorial-board-list <[hidden email]>
Subject: Re: Rough Drafts of CVE Counting Documents


The change to #1 and #2, and even more with the other change suggested by Kurt ("weakness in the system"), would greatly increase the scope for the CVE.  CNAs will issue CVEs for any and all hardware vulnerable to the "row hammer effect", for example, and not just for the software that is particularly vulnerable (e.g., CVE-2015-0565).  This could create an explosion of IDs requests, as some hardware combinations may make things worse or better -- will we keep track of all combinations?  Next we'll get ID requests for overclocked hardware (if overclocking is allowed), or hardware under borderline or unusual temperatures, dirty hardware, under brownouts and for every device that hangs, crashes or reboots because it could indicate a vulnerability.  Will boards that have common chips be grouped under the same CVE ID?  How different is different enough so you'll issue 2 or 2000 different IDs?  The counting document doesn't address hardware, I think.  It seems we just almost stumbled and now we want to tackle a parcours du combattant.

Changing too much too quickly can be a recipe for disaster, or at least great confusion and inadequacy.  I suggest pacing ourselves a bit (pun
intended) and waiting until the recent changes prove themselves viable and stable before making such a change of scope.  At least, the change in scope for the project should be something planned and directly decided upon instead of being incidental to revising a definition.

As a very minor wording comment, of little importance compared to the above, I think that the inclusion of "by a threat source," doesn't help and could be removed.

Pascal



On 08/29/2016 02:01 PM, Coffin, Chris wrote:

> All,
>
> Harold Booth and I had a couple of private exchanges regarding the vulnerability definition for the CNA Counting document. The following is the current definition as proposed by Pascal, as well as two of the most current iterations from Harold and I. The difference is obviously in the second sentence which covers both Kurt’s and Pascal’s original comments. I think we are leaning more towards the second version since it stays focused on the weakness aspect of the definition. Any thoughts on this would be hugely appreciated.
>
> #0.1 (current definition from Pascal)
> “A vulnerability in the context of the CVE program, is indicated by code that can be exploited, resulting in a negative impact to confidentiality, integrity, OR availability, and that requires a coding change, specification change or specification deprecation to mitigate or address.”
>
> #1
> “A vulnerability in the context of the CVE program, is defined as any weakness in the computational logic (e.g., code) found in software or hardware devices, that could be exploited by a threat source, and result in a negative impact to the security of a system. Mitigation of the vulnerabilities in this context typically involve coding changes, but could also include specification changes or even specification deprecations (e.g., removal of affected protocols or functionality in their entirety).”
>
> #2
> “A vulnerability in the context of the CVE program, is defined as any weakness in the computational logic (e.g., code) found in software or hardware devices, that could be exploited by a threat source, and result in a negative impact to the security of a system. A non-exhaustive list of examples where a weakness in logic could be found is in the specification of a protocol, description of an algorithm, design or architecture of a product, implementation, circuit layout, or fabrication of the product.”
>
> Thanks Harold!
>
> Chris
>
> From: Kurt Seifried [mailto:[hidden email]]
> Sent: Thursday, August 25, 2016 1:15 PM
> To: Coffin, Chris <[hidden email]>
> Cc: cve-editorial-board-list
> <[hidden email]>
> Subject: Re: Rough Drafts of CVE Counting Documents
>
>
>
> On Thu, Aug 25, 2016 at 10:21 AM, Coffin, Chris <[hidden email]<mailto:[hidden email]>> wrote:
> Kurt,
>
> Thanks a ton for the feedback... I very much appreciate it.
>
> FYI... I hadn't taken into account Pascal's feedback in the comments below, but I added Pascal's definition of vulnerability as I think it works very well. Thanks Pascal!
>
>
>> Could we add "typically requires" instead?
>
> I added some text to the definition. Take a look and let me know if this works for you.
>
>> Can INC2 (Vendor acknowledgement) be expanded to include actual verification through a proof of concept/reproducer for example, or via source code examination?
>
> I would be concerned with putting strict verification requirements at the inclusion stage. For vendor CNAs, I think they will most likely do some or all of this, and maybe we can insert this language here that mentions it. However, there may also be other CNAs reading this decision who are not the vendor or maintainer of the product/code and assembling this data or getting it from the vendor could take time if it happens at all. My feeling is that the inclusion steps should emphasize speed in assigning CVE IDs as opposed to getting things perfect up front. If a mistake is made, it can be cleaned up after the fact. Thoughts?
>
> Sorry I meant that as OR, not AND, e.g. someone publishes a script that crashes a Linux machine and we have no idea why yet, I would say that should get a CVE asap.
>
>
>> INC3.1 "demonstrated" does this mean we need a reproducer?
>
> Similar to the above, for a vendor CNA following this it is probably not much of an issue. For a CNA who is not the vendor or maintainer, such as yourself, this becomes more important obviously. I think you have said yourself that you get lots of garbage already. In my mind, "demonstrated" means can the requester properly describe the vulnerability and explain what it's impact is. I think if we force the requester to provide a PoC we may be asking for too much at this stage. As the bolded text states, this one is about trusting the researcher in their claim to a certain extent.
>
> Ok, just wanted to make asure we were using the same value of
> "Demonstrated" =)
>
>
>> INC4: can we better define public/private? E.g. what if a medical device maker plans to use a CVE for an issue that they will then inform ever user of directly? Ditto for aerospace/SCADA/etc.
>
> Are you saying that we should soften language now to start including room for CVEs issues that will only be released to a limited group of users? I know we have had these discussions in the recent past, but my understanding was that we would wait to make this kind of change until CVE actually brought on some of these domains where this issue will come up.
>
> I think we need to start looking at this and be ready to have in answer probably within the year or early next year, especially if we want to expand CVE to these industry types as I suspect they will have questions at a minimum.
>
>
>> INC5: "CVE IDs are assigned to products that are customer-controlled or customer-installable." what about on premises solutions that are locked down? I know many medical devices, high end manufacturing, etc you buy it, but you don't touch it, the company tech services it. Ditto for other regulated items like elevators (contractually most elevator maintenance involves a "if anyone but us touches it, your warranty is totally void").
>
> This is a really great point! This is another area that I haven't really put much thought into and I don't think anyone else on the board has brought up in the recent past. Outside of the "sort of" similar idea of SaaS (and possibly other xaaS), I imagine there could be IT products (e.g., appliances and such) produced now or in the future that could fall into this category. Similar to the above comments though, should we account for this in the current rules, or should we wait until presented with this problem such as when we bring on the medical devices domain?
>
> Again above, I think we should look into this and have an answer sooner rather then later.
>
>
>  > CNT4: I'd like to better define the embedded code situation, e.g. libxml/gzip situations (bits of those are everywhere!).
>
> One thing that I noticed is that the decision language did not direct the CNA to defer the report to the appropriate CNA in the case of a shared codebase that doesn't apply to the receiving CNA (i.e., the CNA following the decisions based on the report). Are you looking for more process explanation in this case or maybe more examples? If you have anything specific please feel free to pass along.
>
> So for example where does code move from "Same codebase" to "different code base", e.g. mysql/various forks, embedded copies of X (gzip for example), I think one good sniff test is "does the patch work with no or minimal changes"?
>
>
>
> Chris
>
>
> From: Kurt Seifried
> [mailto:[hidden email]<mailto:[hidden email]>]
> Sent: Wednesday, August 24, 2016 3:55 PM
> To: Coffin, Chris <[hidden email]<mailto:[hidden email]>>
> Cc: cve-editorial-board-list
> <[hidden email]<mailto:cve-editorial-board-l
> [hidden email]>>
> Subject: Re: Rough Drafts of CVE Counting Documents
>
> Some feedback:
> A vulnerability in the context of the CVE program, is code that can be exploited, resulting in a negative impact to confidentiality, integrity, and availability, and that requires a code change to mitigate or address.
> Some vulns are internal to the protocol and the only code change that "fixes" it is to remove the code/functionality altogether. Could we add "typically requires" instead? I'm worried about the intersection of software/API vulns that will become increasingly common (more instances of this, and people will start looking for them).
> Can INC2 (Vendor acknowledgement) be expanded to include actual verification through a proof of concept/reproducer for example, or via source code examination?
> INC3.1 "demonstrated" does this mean we need a reproducer?
> INC4: can we better define public/private? E.g. what if a medical device maker plans to use a CVE for an issue that they will then inform ever user of directly? Ditto for aerospace/SCADA/etc.
> INC5: "CVE IDs are assigned to products that are customer-controlled or customer-installable." what about on premises solutions that are locked down? I know many medical devices, high end manufacturing, etc you buy it, but you don't touch it, the company tech services it. Ditto for other regulated items like elevators (contractually most elevator maintenance involves a "if anyone but us touches it, your warranty is totally void").
> CNT4: I'd like to better define the embedded code situation, e.g. libxml/gzip situations (bits of those are everywhere!).
>
>
>
>
>
>
>
>
>
>
> On Wed, Aug 24, 2016 at 2:19 PM, Coffin, Chris <mailto:[hidden email]<mailto:[hidden email]>> wrote:
> All,
>
> Attached is a new version of the CVE Counting for CNAs document. I  have made some changes to the counting decisions as well as provided some clarifications in certain decisions based on feedback from the CVE Team.
>
> Chris
>
> From:
> mailto:[hidden email]<mailto:owner-cve
> -[hidden email]>
> [mailto:mailto<mailto:mailto>:[hidden email]
> re.org<mailto:[hidden email]>] On
> Behalf Of Coffin, Chris
> Sent: Monday, July 25, 2016 5:03 PM
> To: cve-editorial-board-list
> <mailto:[hidden email]<mailto:cve-editorial-
> [hidden email]>>
> Subject: Rough Drafts of CVE Counting Documents
>
> All,
>
> Sorry for the delay, these were supposed to go out last week.
>
> Attached is the latest marked up version of the Simplified Counting Rules, as well as the promised very rough version of a new CVE Vulnerability Counting for CNAs document. There is still plenty of work to be done on this new document, but the main focus so far has been to develop the decision trees. The included decision trees are meant to replace the older decision trees found at https://github.com/CVEProject/docs/blob/gh-pages/cna/application-guidance.md.
>
> Current thinking is that the introduction of the “independently fixable” concept obsoletes many of the older counting decisions, but we’d be interested to hear others opinions on this. Also, the inclusion rules actually grew a bit, but these all seem to be fairly straightforward.
>
> The Report Type decision is something that came up during internal discussions and is probably new to everyone. An earlier version of the doc didn’t have good coverage for how to count when independently fixable resulted in No or Not Sure. The Report Type allows for common reporting cases to be handled in a somewhat uniform way. The idea is to handle the most common reports and the recommended counting action for each. We are definitely interested in hearing others thoughts on this entire counting decision, as well as the common reports and actions that are defined.
>
> Like I said before, this is a very early version so I am open to any and all feedback. Thanks in advance!
>
> 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: mailto:[hidden email]<mailto:[hidden email]>
>
>
>
> --
>
> --
> 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]<mailto:[hidden email]>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Rough Drafts of CVE Counting Documents

Pascal Meunier
Thank you Chris.  It sounds reasonably prudent to gain experience and
provide the most needed hardware-related identifiers while leaving
enough flexibility to formally increase the scope and commit to it later
if desired.

Pascal

On 08/30/2016 02:07 PM, Coffin, Chris wrote:

> Pascal,
>
> These are great observations and I do agree with your point of view. I have spent a good part of yesterday and today thinking about the best way to address this. One way to handle it might be to leave the door open in regards to hardware, in other words, just state that "some" hardware is included. This allows us to reserve the right to refuse assignments for hardware specific issues like the ones you mentioned. I have crafted a new version of the description below that may or may not satisfy your current concerns in this regard.
>
> Like Kurt had added, requesters will still have to ask CNAs for CVEs and the CNAs don't have to provide them in cases where it isn't applicable or doesn't make sense. Additionally, we could add an inclusion decision that could specifically exclude certain situations (e.g., environmental impacts to hardware, etc.).
>
> #3
> "A vulnerability in the context of the CVE program, is defined as a weakness in the computational logic (e.g., code) found in software and some hardware components (e.g., firmware),  and when exploited results in a negative impact to confidentiality, integrity, OR availability. Mitigation of the vulnerabilities in this context typically involve coding changes, but could also include specification changes or even specification deprecations (e.g., removal of affected protocols or functionality in their entirety).
>
> Chris
>
> -----Original Message-----
> From: Pascal Meunier [mailto:[hidden email]]
> Sent: Monday, August 29, 2016 2:10 PM
> To: Coffin, Chris <[hidden email]>; Kurt Seifried <[hidden email]>; Booth, Harold (Fed) <[hidden email]>
> Cc: cve-editorial-board-list <[hidden email]>
> Subject: Re: Rough Drafts of CVE Counting Documents
>
>
> The change to #1 and #2, and even more with the other change suggested by Kurt ("weakness in the system"), would greatly increase the scope for the CVE.  CNAs will issue CVEs for any and all hardware vulnerable to the "row hammer effect", for example, and not just for the software that is particularly vulnerable (e.g., CVE-2015-0565).  This could create an explosion of IDs requests, as some hardware combinations may make things worse or better -- will we keep track of all combinations?  Next we'll get ID requests for overclocked hardware (if overclocking is allowed), or hardware under borderline or unusual temperatures, dirty hardware, under brownouts and for every device that hangs, crashes or reboots because it could indicate a vulnerability.  Will boards that have common chips be grouped under the same CVE ID?  How different is different enough so you'll issue 2 or 2000 different IDs?  The counting document doesn't address hardware, I think.  It seems we just almost stumbled and now we want to tackle a parcours du combattant.
>
> Changing too much too quickly can be a recipe for disaster, or at least great confusion and inadequacy.  I suggest pacing ourselves a bit (pun
> intended) and waiting until the recent changes prove themselves viable and stable before making such a change of scope.  At least, the change in scope for the project should be something planned and directly decided upon instead of being incidental to revising a definition.
>
> As a very minor wording comment, of little importance compared to the above, I think that the inclusion of "by a threat source," doesn't help and could be removed.
>
> Pascal
>
>
>
> On 08/29/2016 02:01 PM, Coffin, Chris wrote:
>> All,
>>
>> Harold Booth and I had a couple of private exchanges regarding the vulnerability definition for the CNA Counting document. The following is the current definition as proposed by Pascal, as well as two of the most current iterations from Harold and I. The difference is obviously in the second sentence which covers both Kurt’s and Pascal’s original comments. I think we are leaning more towards the second version since it stays focused on the weakness aspect of the definition. Any thoughts on this would be hugely appreciated.
>>
>> #0.1 (current definition from Pascal)
>> “A vulnerability in the context of the CVE program, is indicated by code that can be exploited, resulting in a negative impact to confidentiality, integrity, OR availability, and that requires a coding change, specification change or specification deprecation to mitigate or address.”
>>
>> #1
>> “A vulnerability in the context of the CVE program, is defined as any weakness in the computational logic (e.g., code) found in software or hardware devices, that could be exploited by a threat source, and result in a negative impact to the security of a system. Mitigation of the vulnerabilities in this context typically involve coding changes, but could also include specification changes or even specification deprecations (e.g., removal of affected protocols or functionality in their entirety).”
>>
>> #2
>> “A vulnerability in the context of the CVE program, is defined as any weakness in the computational logic (e.g., code) found in software or hardware devices, that could be exploited by a threat source, and result in a negative impact to the security of a system. A non-exhaustive list of examples where a weakness in logic could be found is in the specification of a protocol, description of an algorithm, design or architecture of a product, implementation, circuit layout, or fabrication of the product.”
>>
>> Thanks Harold!
>>
>> Chris
>>
>> From: Kurt Seifried [mailto:[hidden email]]
>> Sent: Thursday, August 25, 2016 1:15 PM
>> To: Coffin, Chris <[hidden email]>
>> Cc: cve-editorial-board-list
>> <[hidden email]>
>> Subject: Re: Rough Drafts of CVE Counting Documents
>>
>>
>>
>> On Thu, Aug 25, 2016 at 10:21 AM, Coffin, Chris <[hidden email]<mailto:[hidden email]>> wrote:
>> Kurt,
>>
>> Thanks a ton for the feedback... I very much appreciate it.
>>
>> FYI... I hadn't taken into account Pascal's feedback in the comments below, but I added Pascal's definition of vulnerability as I think it works very well. Thanks Pascal!
>>
>>
>>> Could we add "typically requires" instead?
>>
>> I added some text to the definition. Take a look and let me know if this works for you.
>>
>>> Can INC2 (Vendor acknowledgement) be expanded to include actual verification through a proof of concept/reproducer for example, or via source code examination?
>>
>> I would be concerned with putting strict verification requirements at the inclusion stage. For vendor CNAs, I think they will most likely do some or all of this, and maybe we can insert this language here that mentions it. However, there may also be other CNAs reading this decision who are not the vendor or maintainer of the product/code and assembling this data or getting it from the vendor could take time if it happens at all. My feeling is that the inclusion steps should emphasize speed in assigning CVE IDs as opposed to getting things perfect up front. If a mistake is made, it can be cleaned up after the fact. Thoughts?
>>
>> Sorry I meant that as OR, not AND, e.g. someone publishes a script that crashes a Linux machine and we have no idea why yet, I would say that should get a CVE asap.
>>
>>
>>> INC3.1 "demonstrated" does this mean we need a reproducer?
>>
>> Similar to the above, for a vendor CNA following this it is probably not much of an issue. For a CNA who is not the vendor or maintainer, such as yourself, this becomes more important obviously. I think you have said yourself that you get lots of garbage already. In my mind, "demonstrated" means can the requester properly describe the vulnerability and explain what it's impact is. I think if we force the requester to provide a PoC we may be asking for too much at this stage. As the bolded text states, this one is about trusting the researcher in their claim to a certain extent.
>>
>> Ok, just wanted to make asure we were using the same value of
>> "Demonstrated" =)
>>
>>
>>> INC4: can we better define public/private? E.g. what if a medical device maker plans to use a CVE for an issue that they will then inform ever user of directly? Ditto for aerospace/SCADA/etc.
>>
>> Are you saying that we should soften language now to start including room for CVEs issues that will only be released to a limited group of users? I know we have had these discussions in the recent past, but my understanding was that we would wait to make this kind of change until CVE actually brought on some of these domains where this issue will come up.
>>
>> I think we need to start looking at this and be ready to have in answer probably within the year or early next year, especially if we want to expand CVE to these industry types as I suspect they will have questions at a minimum.
>>
>>
>>> INC5: "CVE IDs are assigned to products that are customer-controlled or customer-installable." what about on premises solutions that are locked down? I know many medical devices, high end manufacturing, etc you buy it, but you don't touch it, the company tech services it. Ditto for other regulated items like elevators (contractually most elevator maintenance involves a "if anyone but us touches it, your warranty is totally void").
>>
>> This is a really great point! This is another area that I haven't really put much thought into and I don't think anyone else on the board has brought up in the recent past. Outside of the "sort of" similar idea of SaaS (and possibly other xaaS), I imagine there could be IT products (e.g., appliances and such) produced now or in the future that could fall into this category. Similar to the above comments though, should we account for this in the current rules, or should we wait until presented with this problem such as when we bring on the medical devices domain?
>>
>> Again above, I think we should look into this and have an answer sooner rather then later.
>>
>>
>>  > CNT4: I'd like to better define the embedded code situation, e.g. libxml/gzip situations (bits of those are everywhere!).
>>
>> One thing that I noticed is that the decision language did not direct the CNA to defer the report to the appropriate CNA in the case of a shared codebase that doesn't apply to the receiving CNA (i.e., the CNA following the decisions based on the report). Are you looking for more process explanation in this case or maybe more examples? If you have anything specific please feel free to pass along.
>>
>> So for example where does code move from "Same codebase" to "different code base", e.g. mysql/various forks, embedded copies of X (gzip for example), I think one good sniff test is "does the patch work with no or minimal changes"?
>>
>>
>>
>> Chris
>>
>>
>> From: Kurt Seifried
>> [mailto:[hidden email]<mailto:[hidden email]>]
>> Sent: Wednesday, August 24, 2016 3:55 PM
>> To: Coffin, Chris <[hidden email]<mailto:[hidden email]>>
>> Cc: cve-editorial-board-list
>> <[hidden email]<mailto:cve-editorial-board-l
>> [hidden email]>>
>> Subject: Re: Rough Drafts of CVE Counting Documents
>>
>> Some feedback:
>> A vulnerability in the context of the CVE program, is code that can be exploited, resulting in a negative impact to confidentiality, integrity, and availability, and that requires a code change to mitigate or address.
>> Some vulns are internal to the protocol and the only code change that "fixes" it is to remove the code/functionality altogether. Could we add "typically requires" instead? I'm worried about the intersection of software/API vulns that will become increasingly common (more instances of this, and people will start looking for them).
>> Can INC2 (Vendor acknowledgement) be expanded to include actual verification through a proof of concept/reproducer for example, or via source code examination?
>> INC3.1 "demonstrated" does this mean we need a reproducer?
>> INC4: can we better define public/private? E.g. what if a medical device maker plans to use a CVE for an issue that they will then inform ever user of directly? Ditto for aerospace/SCADA/etc.
>> INC5: "CVE IDs are assigned to products that are customer-controlled or customer-installable." what about on premises solutions that are locked down? I know many medical devices, high end manufacturing, etc you buy it, but you don't touch it, the company tech services it. Ditto for other regulated items like elevators (contractually most elevator maintenance involves a "if anyone but us touches it, your warranty is totally void").
>> CNT4: I'd like to better define the embedded code situation, e.g. libxml/gzip situations (bits of those are everywhere!).
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Wed, Aug 24, 2016 at 2:19 PM, Coffin, Chris <mailto:[hidden email]<mailto:[hidden email]>> wrote:
>> All,
>>
>> Attached is a new version of the CVE Counting for CNAs document. I  have made some changes to the counting decisions as well as provided some clarifications in certain decisions based on feedback from the CVE Team.
>>
>> Chris
>>
>> From:
>> mailto:[hidden email]<mailto:owner-cve
>> -[hidden email]>
>> [mailto:mailto<mailto:mailto>:[hidden email]
>> re.org<mailto:[hidden email]>] On
>> Behalf Of Coffin, Chris
>> Sent: Monday, July 25, 2016 5:03 PM
>> To: cve-editorial-board-list
>> <mailto:[hidden email]<mailto:cve-editorial-
>> [hidden email]>>
>> Subject: Rough Drafts of CVE Counting Documents
>>
>> All,
>>
>> Sorry for the delay, these were supposed to go out last week.
>>
>> Attached is the latest marked up version of the Simplified Counting Rules, as well as the promised very rough version of a new CVE Vulnerability Counting for CNAs document. There is still plenty of work to be done on this new document, but the main focus so far has been to develop the decision trees. The included decision trees are meant to replace the older decision trees found at https://github.com/CVEProject/docs/blob/gh-pages/cna/application-guidance.md.
>>
>> Current thinking is that the introduction of the “independently fixable” concept obsoletes many of the older counting decisions, but we’d be interested to hear others opinions on this. Also, the inclusion rules actually grew a bit, but these all seem to be fairly straightforward.
>>
>> The Report Type decision is something that came up during internal discussions and is probably new to everyone. An earlier version of the doc didn’t have good coverage for how to count when independently fixable resulted in No or Not Sure. The Report Type allows for common reporting cases to be handled in a somewhat uniform way. The idea is to handle the most common reports and the recommended counting action for each. We are definitely interested in hearing others thoughts on this entire counting decision, as well as the common reports and actions that are defined.
>>
>> Like I said before, this is a very early version so I am open to any and all feedback. Thanks in advance!
>>
>> 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: mailto:[hidden email]<mailto:[hidden email]>
>>
>>
>>
>> --
>>
>> --
>> 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]<mailto:[hidden email]>
>>
>
Loading...