CVE program priorities

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

CVE program priorities

Stephen Boyle
Administrator

On Thu, Dec 17, 2015 at 11:17 AM, in the thread on “Upcoming changes for CVE,” Kurt Seifried wrote:

> Is there an ETA on any of this? Days/weeks/months?

 

It is clear at this point that CVE is not able to cover every known vulnerability. The simple fact is that the number of CVEs published every year has not kept pace with the rate or number of vulnerabilities disclosed. CVE has operated successfully for many years but fundamental changes are needed. Fifteen years ago, we could effectively focus on the U.S. IT sector and tell ourselves that we were essentially providing coverage for the world.  Given the international explosion of software development, that is no longer the case.

 

As stated on the CVE web site “CVE is sponsored by US-CERT in the office of Cybersecurity and Communications (CS&C) at the U.S. Department of Homeland Security.” DHS has identified a number of Critical Infrastructure Sectors and CS&C is the identified as the lead for the U.S. IT sector. As we consider how to increase the coverage of CVE, CVE must – as its highest priority – effectively provide full coverage of the software and devices used in the U.S. IT sector.

 

To achieve the fundamental changes required for CVE, we the Editorial Board must wrestle with a number of important topics while CVE continues to operate. We have been actively listening to and hearing the issues and concerns expressed on the Board list and on the outside. We have been working internally to understand the issues and interdependencies limiting CVE and to reflect those back to the Board for consideration.

 

To that end, we suggest the following list of tasks, in priority order:

 

0.       The operation of CVE

1.       The prioritized scope of coverage for CVE and the associated Sources and Products

2.       A re-examination and simplification of the way CVE counts vulnerabilities

3.       The required “quality” of final CVE entries

4.       Clear, redefined rules and guidelines for the operation and management of CNAs

5.       Clear, redefined and more inclusive rules for becoming a CNA

6.       Continuing revisions regarding Board membership and the process for adding members

 

We sincerely appreciate the Board’s continued efforts. You have always been a critical part of CVE, from back in the days of voting on CANs to today. We look forward to comments and discussions on this list to evolve CVE.

 

Best Regards,

Steve Boyle

Reply | Threaded
Open this post in threaded view
|

Re: CVE program priorities

Kurt Seifried
One major comment:

What is the purpose of CVE? My understanding was to provide an identifier for vulnerabilities. Essentially a serial number to make handling inventory easier. I don't care what's in most of those boxes, but I do need to be able to track them down as needed.

That we have an official database at cve.mitre.org/NVD is nice, but not needed as evidenced by the fact that something on the order of 11,000+ CVE's have been assigned and not written up and listed in the database (I know of at least 1000+ from myself personally). I even updated the Wikipedia entry to cover this because I kept getting people asking me why I had not updated the CVE database after assigning them a CVE privately/publicly. 

Personally for me the official CVE database at this point is the search engines. When I plug CVE-YEAR-FOOO in I expect to get something resembling a trusted site (e.g. bugzilla.redhat.com, bugs.debian.org, launchpad.net, upstream bug trackers, OSS-Security archives, etc.) with an entry that contains the CVE string I'm looking for. 

I think we should really split the problem into:

1) assigning CVEs

2) the CVE database

as #1 can happily exist with or without #2.


On Tue, Dec 22, 2015 at 10:55 AM, Boyle, Stephen V. <[hidden email]> wrote:

On Thu, Dec 17, 2015 at 11:17 AM, in the thread on “Upcoming changes for CVE,” Kurt Seifried wrote:

> Is there an ETA on any of this? Days/weeks/months?

 

It is clear at this point that CVE is not able to cover every known vulnerability. The simple fact is that the number of CVEs published every year has not kept pace with the rate or number of vulnerabilities disclosed. CVE has operated successfully for many years but fundamental changes are needed. Fifteen years ago, we could effectively focus on the U.S. IT sector and tell ourselves that we were essentially providing coverage for the world.  Given the international explosion of software development, that is no longer the case.

 

As stated on the CVE web site “CVE is sponsored by US-CERT in the office of Cybersecurity and Communications (CS&C) at the U.S. Department of Homeland Security.” DHS has identified a number of Critical Infrastructure Sectors and CS&C is the identified as the lead for the U.S. IT sector. As we consider how to increase the coverage of CVE, CVE must – as its highest priority – effectively provide full coverage of the software and devices used in the U.S. IT sector.

 

To achieve the fundamental changes required for CVE, we the Editorial Board must wrestle with a number of important topics while CVE continues to operate. We have been actively listening to and hearing the issues and concerns expressed on the Board list and on the outside. We have been working internally to understand the issues and interdependencies limiting CVE and to reflect those back to the Board for consideration.

 

To that end, we suggest the following list of tasks, in priority order:

 

0.       The operation of CVE

1.       The prioritized scope of coverage for CVE and the associated Sources and Products

2.       A re-examination and simplification of the way CVE counts vulnerabilities

3.       The required “quality” of final CVE entries

4.       Clear, redefined rules and guidelines for the operation and management of CNAs

5.       Clear, redefined and more inclusive rules for becoming a CNA

6.       Continuing revisions regarding Board membership and the process for adding members

 

We sincerely appreciate the Board’s continued efforts. You have always been a critical part of CVE, from back in the days of voting on CANs to today. We look forward to comments and discussions on this list to evolve CVE.

 

Best Regards,

Steve Boyle




--

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

Re: CVE program priorities

Eugene H. Spafford
In reply to this post by Stephen Boyle
Simply an observation on this statement:

The simple fact is that the number of CVEs published every year has not kept pace with the rate or number of vulnerabilities disclosed. 

This is an indirect measure — and a depressing one — of the state of software quality, vendor commitment, and consumer pressure.

Every year that I have worked in the field (about 31 now) I have been heartened by the wonderful people who are concerned with the problems, yet on balance, more depressed about the future.   This year is no different.

In 1985 there were 2 PC viruses “in the wild.”  In 1986, there were 7 (2+5).  In 1987, 12.  In 1988, 24.  Now, there are millions of families of malware and no one is able to keep an accurate count.  The rate of increase is still exponential.  

The “cyber” world largely continues to operate on a “ship crap, fix it later” model.  Whatever we do with the CVE infrastructure is not going to change the causality, and eventually any response will break under the load, the same as the malware repository/naming model has.

I won’t close with “Bah, humbug” because someone would feel compelled to generate a CVE for that bug, too.

My best (but someone curmudgeonly) wishes to you all for happy, safe holidays, and a wonderful new year.
—spaf


smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: CVE program priorities

Stephen Boyle
Administrator
In reply to this post by Kurt Seifried

Hi Kurt,

 

Kurt wrote:

> What is the purpose of CVE?

 

Excellent question.

 

The short answer is that having a comprehensive official list of all assigned CVEs is a “must-have,” otherwise security product vendors and other “CVE integrators” wouldn’t be able to effectively find all assigned CVEs, much less integrate them into their products.

 

The longer answer is that we should collectively review the CVE use cases.  To that end, I’ve updated the list of issues and topics for us to discuss in more detail.  I recommend we dig into this further immediately after we get through a review of the priority products and sources needed to give effective full coverage of the U.S. IT sector.

 

Updated list discussion topics & tasks

0.       The operation of CVE

1.       The prioritized scope of coverage for CVE and the associated Sources and Products

2.       A review of CVE’s major use cases (added)

3.       A re-examination and simplification of the way CVE counts vulnerabilities

4.       The required “quality” of final CVE entries

5.       Clear, redefined rules and guidelines for the operation and management of CNAs

6.       Clear, redefined and more inclusive rules for becoming a CNA

7.       Continuing revisions regarding Board membership and the process for adding members

 

Best Regards,

Steve

 

From: Kurt Seifried [mailto:[hidden email]]
Sent: Tuesday, December 22, 2015 2:29 PM
To: Boyle, Stephen V. <[hidden email]>
Cc: cve-editorial-board-list <[hidden email]>
Subject: Re: CVE program priorities

 

One major comment:

 

What is the purpose of CVE? My understanding was to provide an identifier for vulnerabilities. Essentially a serial number to make handling inventory easier. I don't care what's in most of those boxes, but I do need to be able to track them down as needed.

 

That we have an official database at cve.mitre.org/NVD is nice, but not needed as evidenced by the fact that something on the order of 11,000+ CVE's have been assigned and not written up and listed in the database (I know of at least 1000+ from myself personally). I even updated the Wikipedia entry to cover this because I kept getting people asking me why I had not updated the CVE database after assigning them a CVE privately/publicly. 

 

Personally for me the official CVE database at this point is the search engines. When I plug CVE-YEAR-FOOO in I expect to get something resembling a trusted site (e.g. bugzilla.redhat.com, bugs.debian.org, launchpad.net, upstream bug trackers, OSS-Security archives, etc.) with an entry that contains the CVE string I'm looking for. 

 

I think we should really split the problem into:

 

1) assigning CVEs

 

2) the CVE database

 

as #1 can happily exist with or without #2.

 

 

On Tue, Dec 22, 2015 at 10:55 AM, Boyle, Stephen V. <[hidden email]> wrote:

On Thu, Dec 17, 2015 at 11:17 AM, in the thread on “Upcoming changes for CVE,” Kurt Seifried wrote:

> Is there an ETA on any of this? Days/weeks/months?

 

It is clear at this point that CVE is not able to cover every known vulnerability. The simple fact is that the number of CVEs published every year has not kept pace with the rate or number of vulnerabilities disclosed. CVE has operated successfully for many years but fundamental changes are needed. Fifteen years ago, we could effectively focus on the U.S. IT sector and tell ourselves that we were essentially providing coverage for the world.  Given the international explosion of software development, that is no longer the case.

 

As stated on the CVE web site “CVE is sponsored by US-CERT in the office of Cybersecurity and Communications (CS&C) at the U.S. Department of Homeland Security.” DHS has identified a number of Critical Infrastructure Sectors and CS&C is the identified as the lead for the U.S. IT sector. As we consider how to increase the coverage of CVE, CVE must – as its highest priority – effectively provide full coverage of the software and devices used in the U.S. IT sector.

 

To achieve the fundamental changes required for CVE, we the Editorial Board must wrestle with a number of important topics while CVE continues to operate. We have been actively listening to and hearing the issues and concerns expressed on the Board list and on the outside. We have been working internally to understand the issues and interdependencies limiting CVE and to reflect those back to the Board for consideration.

 

To that end, we suggest the following list of tasks, in priority order:

 

0.       The operation of CVE

1.       The prioritized scope of coverage for CVE and the associated Sources and Products

2.       A re-examination and simplification of the way CVE counts vulnerabilities

3.       The required “quality” of final CVE entries

4.       Clear, redefined rules and guidelines for the operation and management of CNAs

5.       Clear, redefined and more inclusive rules for becoming a CNA

6.       Continuing revisions regarding Board membership and the process for adding members

 

We sincerely appreciate the Board’s continued efforts. You have always been a critical part of CVE, from back in the days of voting on CANs to today. We look forward to comments and discussions on this list to evolve CVE.

 

Best Regards,

Steve Boyle



 

--

 

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

Reply | Threaded
Open this post in threaded view
|

Re: CVE program priorities

Pascal Meunier
In reply to this post by Stephen Boyle
On 12/22/2015 12:55 PM, Boyle, Stephen V. wrote:
> coverage of the software and devices used in the U.S. IT sector.

What is "the U.S. IT sector"?  Is "U.S. IT sector" intended to include
devices used in our homes or micro-businesses with firmware developed
abroad, especially if they are connected to the internet, or does this
only cover software and devices used in U.S. enterprises?  Also, would
US-based firms using foreign software when they do business abroad be
covered;  is that "used in the U.S. IT sector" or not?  Whose
responsibility is it (or should it be) to generate identifiers for
software and devices "not used in the U.S. IT sector", but used in or
for U.S. supply chains and used by important partners we collaborate
with, trust and rely upon?  Inasmuch as MITRE and its CNAs shoulder the
responsibility of managing identifiers for "the U.S. IT sector", who
should be responsible for international IT sectors?

I'm wondering how much software and how many devices exist that won't be
used somewhere in the U.S. at some point.  Does trying to exclude "never
used in the U.S." software and devices really provide a significant
workload relief, worth the effort of sorting and the risk of error?  I
ask because it seems a given that manufacturers and software vendors
will try to target everything they have at the U.S. market, due to
economies of scale.  The criterion "used in the U.S. IT sector" is
indistinct, and I doubt its usefulness and practicality.  Instead,
"products developed by firms or organizations based in the U.S." would
be more clearcut, and so would be the responsibility.  Coverage would be
significantly reduced and more manageable, but consequently it would be
narrow to the point of making the CVE less useful.

Given the conflicting desire to restrict the workload but usefulness of
prompt and broad coverage, perhaps it's time to ask other countries or
regions (I mean to include the European Union in this) to be responsible
for their share of produced software and to peer with MITRE using
"Olympic swim lanes" (eh, Olympic as in "a time for laying aside
political and religious differences") that would avoid duplication of
effort and redundant identifiers?  Besides directly contacting foreign
organizations, I would think this is worthy of the United Nations'
attention, given its goal of promoting international co-operation, and
given the ubiquitous distribution of software.  This sounds idealistic
but the very idea is important.  I believe this needs to be stated and
recognized as something desirable, and even needs to be attempted so
that perhaps we'll obtain through compromise an intermediate solution
that works well enough.

Other related "can of worms" thoughts: Can CNAs be foreign nations, or
could foreign nations have the power to designate CNAs, or would it be
preferable that they have their own identifiers?  Would it be useful if
they used different letters than 'CVE' but kept the format similar and
recognizable (a Universally Unique Vulnerability ID, UUVID)?  Can they
be trusted enough, and what mechanisms could detect misbehavior, and
then work around it or even repair it?

Pascal
Reply | Threaded
Open this post in threaded view
|

Re: CVE program priorities

Kurt Seifried
In reply to this post by Stephen Boyle


On Tue, Dec 22, 2015 at 1:46 PM, Boyle, Stephen V. <[hidden email]> wrote:

Hi Kurt,

 

Kurt wrote:

> What is the purpose of CVE?

 

Excellent question.

 

The short answer is that having a comprehensive official list of all assigned CVEs is a “must-have,” otherwise security product vendors and other “CVE integrators” wouldn’t be able to effectively find all assigned CVEs, much less integrate them into their products.


So two comments:

1) when and how do you plan to address the backlog of 11,000+ CVE's currently not in the database? You say this is a "MUST-HAVE" and yet we've lived without it for 10+ years. 

2) When do you plan to make the database properly index-able by search engines, it's 2015, usually if you want to share something publicly you let the search engines index it.


 

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

Re: CVE program priorities

Eugene H. Spafford
In reply to this post by Stephen Boyle
Simply an observation on this statement:

The simple fact is that the number of CVEs published every year has not kept pace with the rate or number of vulnerabilities disclosed. 

This is an indirect measure — and a depressing one — of the state of software quality, vendor commitment, and consumer pressure.

Every year that I have worked in the field (about 31 now) I have been heartened by the wonderful people who are concerned with the problems, yet on balance, more depressed about the future.   This year is no different.

In 1985 there were 2 PC viruses “in the wild.”  In 1986, there were 7 (2+5).  In 1987, 12.  In 1988, 24.  Now, there are millions of families of malware and no one is able to keep an accurate count.  The rate of increase is still exponential.  

The “cyber” world largely continues to operate on a “ship crap, fix it later” model.  Whatever we do with the CVE infrastructure is not going to change the causality, and eventually any response will break under the load, the same as the malware repository/naming model has.

I won’t close with “Bah, humbug” because someone would feel compelled to generate a CVE for that bug, too.

My best (but someone curmudgeonly) wishes to you all for happy, safe holidays, and a wonderful new year.
—spaf


smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: CVE program priorities

Pascal Meunier
In reply to this post by Stephen Boyle
Here are a couple of silly questions that keep me up at night (literally):

1. Why would the U.S. keep a military presence in foreign countries but
not a CVE presence?

2. If the source of funding is what restricts the CVE mission, perhaps
the CVE program should get funding from the United Nations?

Pascal


On 12/22/2015 12:55 PM, Boyle, Stephen V. wrote:

> On Thu, Dec 17, 2015 at 11:17 AM, in the thread on "Upcoming changes for CVE," Kurt Seifried wrote:
>> Is there an ETA on any of this? Days/weeks/months?
>
> It is clear at this point that CVE is not able to cover every known vulnerability. The simple fact is that the number of CVEs published every year has not kept pace with the rate or number of vulnerabilities disclosed. CVE has operated successfully for many years but fundamental changes are needed. Fifteen years ago, we could effectively focus on the U.S. IT sector and tell ourselves that we were essentially providing coverage for the world.  Given the international explosion of software development, that is no longer the case.
>
> As stated on the CVE web site "CVE is sponsored by US-CERT in the office of Cybersecurity and Communications (CS&C) at the U.S. Department of Homeland Security." DHS has identified a number of Critical Infrastructure Sectors and CS&C is the identified as the lead for the U.S. IT sector. As we consider how to increase the coverage of CVE, CVE must - as its highest priority - effectively provide full coverage of the software and devices used in the U.S. IT sector.
>
> To achieve the fundamental changes required for CVE, we the Editorial Board must wrestle with a number of important topics while CVE continues to operate. We have been actively listening to and hearing the issues and concerns expressed on the Board list and on the outside. We have been working internally to understand the issues and interdependencies limiting CVE and to reflect those back to the Board for consideration.
>
> To that end, we suggest the following list of tasks, in priority order:
>
>
> 0.       The operation of CVE
>
> 1.       The prioritized scope of coverage for CVE and the associated Sources and Products
>
> 2.       A re-examination and simplification of the way CVE counts vulnerabilities
>
> 3.       The required "quality" of final CVE entries
>
> 4.       Clear, redefined rules and guidelines for the operation and management of CNAs
>
> 5.       Clear, redefined and more inclusive rules for becoming a CNA
>
> 6.       Continuing revisions regarding Board membership and the process for adding members
>
>
>
> We sincerely appreciate the Board's continued efforts. You have always been a critical part of CVE, from back in the days of voting on CANs to today. We look forward to comments and discussions on this list to evolve CVE.
>
> Best Regards,
> Steve Boyle
>
Reply | Threaded
Open this post in threaded view
|

Re: CVE program priorities

Pascal Meunier
In reply to this post by Kurt Seifried
On 12/22/2015 02:28 PM, Kurt Seifried wrote:
> What is the purpose of CVE?

The ultimate purpose of the CVE is to facilitate communications and
understanding.  I'm afraid that the difficulty in obtaining CVE
identifiers (slow or no responses, opaque processes, identifying an
appropriate and willing CNA) will be increased by the uncertainty and
burden of justifying how an issue passes selection criteria extrinsic to
the subject matter, while simultaneously lowering the usefulness and
mindshare of the CVE by limiting its ubiquity and scope.  When the CVE
becomes a net barrier to communications, it will have outlived its
usefulness.  If that happens, the consequences will be anti-academic.
Vulnerability communications will be (more) balkanized by multiple
competing and redundant identifiers, or no identifiers at all, assigned
at different levels of abstraction, in different languages,
inconsistently;  some will be proprietary, some private, or semi-private
("clubs"), and will require the creation of maps, and the mappings could
require paid subscriptions.  It will be a step back towards private
libraries, the hoarding and trading of knowledge, encouraging less
precise and detailed vulnerability announcements.  Fewer, less open,
less useful security communications will encourage putrescence and a
decay of software security.

So, it costs money.  However the nature of an enumeration is, either you
do it all or it's not: "An enumeration is a complete, ordered listing of
all...".  If MITRE wants to do a partial enumeration, let's change the
name to PVE...  The benefits of the CVE are international and cannot
easily be segmented by country or geopolitical alliances, especially in
the face of open software.  If the costs are too much for the U.S.
budget, get money internationally or get credit for the effort
internationally, that is, trade it as a debt other countries owe the
U.S. for its contributions to software and cyber security, or go home
because "partial enumeration" is an oxymoron.

Pascal
Reply | Threaded
Open this post in threaded view
|

Re: CVE program priorities

Kurt Seifried
So my hope was always that Mitre would realize that the best way to handle this is to become a coordinating body primarily and secondarily an assigning/researching/writing up body, rather than being primarily and assigning/researching/writing up CVE body (with no real coordination I can see, heck at this point I'm not even sure what the purpose of the board is). 


The only viable way to scale out CVE to cover things, or heck, to even continue covering what we have in past (e.g. major US based commercial vendors, most major Open Source, etc.) is to adopt an Open Source style model. We need to reduce the cost (both in monetary terms and effort/time) of getting CVE's, the best way to do this is to create more CNAs so CVE's can simply be assigned at the source of discovery, quickly and promptly. 

We need to admit that the official CVE database is now google.com (or whatever search engine you use), not cve.mitre.org

We need to admit what makes a CVE real is not Mitre's blessing, but the fact that a trustworthy source (Vendor security team, trusted researcher, etc.) says the CVE is valid. This is actually already true, the number of assigned CVE's in public use but not in the official Mitre database is considerable (Red Hat alone has over 1000 we have assigned but not seen in the Mitre database yet). 

We need to admit we need more CNAs and the CNA process needs to be simpler. Mitre hasn't even replied to Mark Cox, a board member and well known security industry luminary, I mean he runs Red Hat's Security Response, and sits on Apache's and OpenSSL security teams, and he wants Apache and OpenSSL respectively to be CNAs (currently he simply piggy backs on the CVE blocks assigned to Red Hat's, so he's been acting as a CNA for quite some time now, just unofficially. But Mitre won't make Apache/OpenSSL a CNA (or even reply with a reason as to why this hasn't been done). 

We have been promised change by Mitre, both publicly, and I have been privately emailed over a period of 6 months or so, but as far as I know/can see there has been no change. 

I am rapidly losing confidence in Mitre's ability to manage the CVE database, CNA process and so on. 

I have grave concerns about the viability of CVE if it is left primarily under Mitre's control. 


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

RE: CVE program priorities

Stephen Boyle
Administrator
In reply to this post by Pascal Meunier
Hi Pascal et al,

Pascal wrote:
> What is "the U.S. IT sector"?  

As one would expect, there are many and varying definitions of what constitutes the "U.S. IT Sector." In this case, we picked the "U.S. IT Sector" as a starting point for further discussion because that has historically been one way to describe what CVE covers.  Essentially, we are asking the Board to decide on a definition of priorities that will serve the needs of the community that uses CVE. That definition may or may not turn out to be what some would consider the "U.S. IT Sector."

We share your questions about what would be included or excluded in such a  statement of priorities-we can reasonably expect it to engender at least as many questions as it might answer. However, If we collectively acknowledge that today's CVE cannot cover all publicly known vulnerabilities, then we need to have a shared understanding of the priorities it is to operate against. As you noted later in your comments, we need to balance what is manageable against narrowing coverage to the point of being inconsequential.

With regard to your comments about CVE operations and CNAs, we believe that the CNA pool not only should be, but needs to be opened up more broadly. How that is defined and bounded is subject to further discussion with the Board. We will note that, based on our experience, we believe there should be qualifications to become a CNA, ongoing measures of effectiveness, and a framework for adding and removing CNAs. In addition, each of those should be clear and publicly documented.

You also touched on many of the topics and concepts we have been mulling over, such as global identifier schemes and other ways to support and govern the operation of cooperating or federated CVE-like enumerations. We will more fully address your and other's related questions and comments in another, combined response email.

Best Regards,
The MITRE CVE Team
Reply | Threaded
Open this post in threaded view
|

Re: CVE program priorities

Kurt Seifried
On Mon, Dec 28, 2015 at 4:16 PM, Boyle, Stephen V. <[hidden email]> wrote:
Hi Pascal et al,

Pascal wrote:
> What is "the U.S. IT sector"?

As one would expect, there are many and varying definitions of what constitutes the "U.S. IT Sector." In this case, we picked the "U.S. IT Sector" as a starting point for further discussion because that has historically been one way to describe what CVE covers.  Essentially, we are asking the Board to decide on a definition of priorities that will serve the needs of the community that uses CVE. That definition may or may not turn out to be what some would consider the "U.S. IT Sector."

We share your questions about what would be included or excluded in such a  statement of priorities-we can reasonably expect it to engender at least as many questions as it might answer. However, If we collectively acknowledge that today's CVE cannot cover all publicly known vulnerabilities, then we need to have a shared understanding of the priorities it is to operate against. As you noted later in your comments, we need to balance what is manageable against narrowing coverage to the point of being inconsequential.

With regard to your comments about CVE operations and CNAs, we believe that the CNA pool not only should be, but needs to be opened up more broadly. How that is defined and bounded is subject to further discussion with the Board.

Will Mitre be leading this discussion? If so can you post your suggested framework for this ASAP?
 
We will note that, based on our experience, we believe there should be qualifications to become a CNA, ongoing measures of effectiveness, and a framework for adding and removing CNAs. In addition, each of those should be clear and publicly documented.

Do we have an ETA for doing this and a structure for this? Or is this stuff waiting on the new docs/process/etc being written by Mitre as mentioned in past?
 

You also touched on many of the topics and concepts we have been mulling over, such as global identifier schemes and other ways to support and govern the operation of cooperating or federated CVE-like enumerations. We will more fully address your and other's related questions and comments in another, combined response email.

Best Regards,
The MITRE CVE Team



--

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

Re: CVE program priorities

Art Manion
In reply to this post by Eugene H. Spafford
A few collected responses...

On 2015-12-22 15:22, Eugene H. Spafford wrote:
>
> The “cyber” world largely continues to operate on a “ship crap, fix it
> later” model.  Whatever we do with the CVE infrastructure is not going
> to change the causality, and eventually any response will break under
> the load, the same as the malware repository/naming model has.

My view of CVE is that is isn't directly intended to change the
causality, but to provide services and/or data (e.g., vulnerability
identification) that supports other work like vulnerability management.
 We know some current use cases for CVE, but we don't have to know all
of them.  Being able to even name/identify something is infrastructural.

Now, to the scale problem, it may be possible to scale CVE sufficiently
to meet the identification goal.  Or it may not, or it may not be
necessary even?  Anti-malware work somehow continues without centralized
identification?  We're easily above 10K/year public vulnerability
disclosures.

On 2015-12-22 14:28, Kurt Seifried wrote:
> I think we should really split the problem into:
>
> 1) assigning CVEs
>
> 2) the CVE database
>
> as #1 can happily exist with or without #2.

This is an important point.  #1 is identification, this thing is called
CVE-X.  Some amount of information (#2) is needed to perform #1 --
uniqueness determination at least.  That amount could be reduced at the
cost of more duplicates or overall less short-term quality for #2.

On 2015-12-22 15:46, Boyle, Stephen V. wrote:
> Updated list discussion topics & tasks
>
> 0. The operation of CVE
>
> 1. The prioritized scope of coverage for CVE and the associated
> Sources and Products
>
> 2. A review of CVE’s major use cases (added)
...

I'd like to suggest a step back (or possibly up) and ask if the Board
(and other interested parties?) would be willing to focus first on
problems/issues with CVE before getting into solutions.

  "Do not propose solutions until the problem has been discussed as
thoroughly as possible without suggesting any."

  http://lesswrong.com/lw/ka/hold_off_on_proposing_solutions/

I'm not particularly against any of the discussion topics (well, maybe
#1), and I don't think of it solely as a list of solutions, but the
process idea here is to really work on the describing the problem space
first.

Regards,

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

Re: CVE program priorities

Scott Lawler
If like to hear from the MITRE Team about how they would like the board to help us collectively move forward with CVE.  

I'd also like to second Art's insightful comment about carefully defining the problem.  

Similarly, where do we want CVE to be in 5 years?   What steps do we take to get there?  

Scott

> On Dec 29, 2015, at 12:57 PM, Art Manion <[hidden email]> wrote:
>
> A few collected responses...
>
> On 2015-12-22 15:22, Eugene H. Spafford wrote:
>>
>> The “cyber” world largely continues to operate on a “ship crap, fix it
>> later” model.  Whatever we do with the CVE infrastructure is not going
>> to change the causality, and eventually any response will break under
>> the load, the same as the malware repository/naming model has.
>
> My view of CVE is that is isn't directly intended to change the
> causality, but to provide services and/or data (e.g., vulnerability
> identification) that supports other work like vulnerability management.
> We know some current use cases for CVE, but we don't have to know all
> of them.  Being able to even name/identify something is infrastructural.
>
> Now, to the scale problem, it may be possible to scale CVE sufficiently
> to meet the identification goal.  Or it may not, or it may not be
> necessary even?  Anti-malware work somehow continues without centralized
> identification?  We're easily above 10K/year public vulnerability
> disclosures.
>
>> On 2015-12-22 14:28, Kurt Seifried wrote:
>> I think we should really split the problem into:
>>
>> 1) assigning CVEs
>>
>> 2) the CVE database
>>
>> as #1 can happily exist with or without #2.
>
> This is an important point.  #1 is identification, this thing is called
> CVE-X.  Some amount of information (#2) is needed to perform #1 --
> uniqueness determination at least.  That amount could be reduced at the
> cost of more duplicates or overall less short-term quality for #2.
>
>> On 2015-12-22 15:46, Boyle, Stephen V. wrote:
>> Updated list discussion topics & tasks
>>
>> 0. The operation of CVE
>>
>> 1. The prioritized scope of coverage for CVE and the associated
>> Sources and Products
>>
>> 2. A review of CVE’s major use cases (added)
> ...
>
> I'd like to suggest a step back (or possibly up) and ask if the Board
> (and other interested parties?) would be willing to focus first on
> problems/issues with CVE before getting into solutions.
>
>  "Do not propose solutions until the problem has been discussed as
> thoroughly as possible without suggesting any."
>
>  http://lesswrong.com/lw/ka/hold_off_on_proposing_solutions/
>
> I'm not particularly against any of the discussion topics (well, maybe
> #1), and I don't think of it solely as a list of solutions, but the
> process idea here is to really work on the describing the problem space
> first.
>
> Regards,
>
> - Art
Reply | Threaded
Open this post in threaded view
|

Re: CVE program priorities

Kurt Seifried
In reply to this post by Art Manion
On Tue, Dec 29, 2015 at 12:56 PM, Art Manion <[hidden email]> wrote:
A few collected responses...

On 2015-12-22 15:22, Eugene H. Spafford wrote:


On 2015-12-22 14:28, Kurt Seifried wrote:
> I think we should really split the problem into:
>
> 1) assigning CVEs
>
> 2) the CVE database
>
> as #1 can happily exist with or without #2.

This is an important point.  #1 is identification, this thing is called
CVE-X.  Some amount of information (#2) is needed to perform #1 --
uniqueness determination at least.  That amount could be reduced at the
cost of more duplicates or overall less short-term quality for #2. 

So one note: most Open Source security issues have a CVE associated with either the code commit the created the vuln, the code commit that fixed the vuln, or a security report that typically at least identifies the vulnerable function and describes what happened (usually with a code snippet example). So at least from the Open Source side mostly what we care about is "what is the vulnerable code" because then anyone can check if they are vulnerable or not with relative ease and a high degree of certainty. 

A perfect example of this being some vulns in giflib's giffix utility, we (Red Hat) ship a product which includes PhantomJS which in turn embeds giflib, so I crack the source rpm open to see what version of giffix is included in our PhantomJS and good news is, it doesn't include giffix, just the giflib library bits. 

The current state of http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-7555 is the "reserved" statement.

Now obviously the closed people are in a bit more of a difficult position, without a security report that lists reliable version affected/not affected information, or a reproducer to test it they are largely in the dark. But this problem currently exists because I doubt Mitre is actively verifying/testing/writing reproducers for closed source reports (if they are I'd love to know) but is instead consuming security reports from vendors/etc. like the rest of the world.

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

Re: CVE program priorities

Art Manion
In reply to this post by Art Manion
On 2015-12-29 14:56, Art Manion wrote:
> I'd like to suggest a step back (or possibly up) and ask if the Board
> (and other interested parties?) would be willing to focus first on
> problems/issues with CVE before getting into solutions.
>
>   "Do not propose solutions until the problem has been discussed as
> thoroughly as possible without suggesting any."
>
>   http://lesswrong.com/lw/ka/hold_off_on_proposing_solutions/

Having given it some more thought, and with some hope that we'll convene
an in-person meeting, I'd like to step back even further to what I'll
call use cases.

What is CVE used for, by whom, and how?

There is more than one answer, there is probably a "when" aspect too
(use cases change over time), and we may not know all the use cases or
be able to predict future ones.  Nonetheless, having some idea (and
agreement) on what CVE is for makes the discussion about problems
actually meaningful.  To have a problem, there is a (possibly assumed)
use that isn't being met.

So use cases, problems, solutions is the order I'm proposing, and this
should frame our in-person meeting, and even work leading up to the meeting.

Regards,

 - Art

PS, if you think I'm a process nut, I'm really not.  But I've seen
enough complicated, multi-party discussions to know that without some
process/framing, we're all spinning our wheels.
Reply | Threaded
Open this post in threaded view
|

Re: CVE program priorities

Pascal Meunier
Art,
        I understand the point about how the premature discussion of solutions
- with an intent to implement - can preclude or obscure a
better-inspired perspective.  However, I find that a comment in the link
you provided, by " Comment author: Eddieosh " about TRIZ resonates with
me.  I believe it would be productive and useful to "write the solutions
down (rather than be diverted by them or try to bat them away), use them
to help examine the problem a bit more and then carry on until you have
enough information to make useful judgments about all the solutions
you've generated".

I also want to suggest that more than one iteration of "use cases,
problems, solutions" may be necessary.  The CVE seems like it is needed
for many different processes that different people are trying to get
done, however in somewhat different ways and with different
requirements.  Those are your use cases.  How can we know if all use
cases have been captured, and captured correctly?  In effect we're
trying to build a conceptual model of systems of processes.  Comparing
that model to reality is a crucial step.  I submit that the activity of
discussing and criticizing potential solutions contributes to building
conceptual models and validating them. This can create corrections to
use cases or the identification of new ones, or a change in the
perception of problems.  Certainly the order you are proposing, "use
cases, problems, solutions", is logical and should determine the final
justification for actions.  However, in arriving to the correct and
complete (to the best of our abilities) list of use cases, problems, and
solutions, I believe that an iterative process or loops may be beneficial.

I'm glad you mentioned "work leading up to the meeting".  I think there
hasn't been enough for a meeting to produce a list of actionable
recommendations or resolutions.  Deciding on a date and duration seems
premature when so little of this work has been done, unless having a
deadline is a necessary motivating factor.

Pascal

On 01/29/2016 04:46 PM, Art Manion wrote:

> On 2015-12-29 14:56, Art Manion wrote:
>> I'd like to suggest a step back (or possibly up) and ask if the Board
>> (and other interested parties?) would be willing to focus first on
>> problems/issues with CVE before getting into solutions.
>>
>>    "Do not propose solutions until the problem has been discussed as
>> thoroughly as possible without suggesting any."
>>
>>    http://lesswrong.com/lw/ka/hold_off_on_proposing_solutions/
>
> Having given it some more thought, and with some hope that we'll convene
> an in-person meeting, I'd like to step back even further to what I'll
> call use cases.
>
> What is CVE used for, by whom, and how?
>
> There is more than one answer, there is probably a "when" aspect too
> (use cases change over time), and we may not know all the use cases or
> be able to predict future ones.  Nonetheless, having some idea (and
> agreement) on what CVE is for makes the discussion about problems
> actually meaningful.  To have a problem, there is a (possibly assumed)
> use that isn't being met.
>
> So use cases, problems, solutions is the order I'm proposing, and this
> should frame our in-person meeting, and even work leading up to the meeting.
>
> Regards,
>
>   - Art
>
> PS, if you think I'm a process nut, I'm really not.  But I've seen
> enough complicated, multi-party discussions to know that without some
> process/framing, we're all spinning our wheels.
>
Reply | Threaded
Open this post in threaded view
|

Re: CVE program priorities

Art Manion
On 2016-01-30 11:02, Pascal Meunier wrote:

> Art,
> I understand the point about how the premature discussion of solutions
> - with an intent to implement - can preclude or obscure a
> better-inspired perspective.  However, I find that a comment in the link
> you provided, by " Comment author: Eddieosh " about TRIZ resonates with
> me.  I believe it would be productive and useful to "write the solutions
> down (rather than be diverted by them or try to bat them away), use them
> to help examine the problem a bit more and then carry on until you have
> enough information to make useful judgments about all the solutions
> you've generated".

Had not heard of TRIZ (remember, I'm not really a process person :), thanks.

And I'm not claiming my suggestion should be the one and only way, but
given what we're trying to deal with, I want some sort of process to
follow, at least 80%, and also to avoid "distracted by solutions"
syndrome.  Keeping track of solutions and backing into what they say
about the problem sounds reasonable, but it might take some discipline.

> I also want to suggest that more than one iteration of "use cases,
> problems, solutions" may be necessary.  The CVE seems like it is needed
> for many different processes that different people are trying to get
> done, however in somewhat different ways and with different
> requirements.  Those are your use cases.  How can we know if all use
> cases have been captured, and captured correctly?

There are certainly more than one use case for CVE, and I'm not even
sure we (the board) can describe all of them.  Survey?

> I'm glad you mentioned "work leading up to the meeting".  I think there
> hasn't been enough for a meeting to produce a list of actionable
> recommendations or resolutions.  Deciding on a date and duration seems
> premature when so little of this work has been done, unless having a
> deadline is a necessary motivating factor.

The deadline motivator might be needed?  But I'd still want some
process/agenda sorted out in advance and some input (Kent started a list
of issues).  Ideally goals/output, but I'm not sure what those should be.

Regards,

 - Art


> On 01/29/2016 04:46 PM, Art Manion wrote:

>>>    "Do not propose solutions until the problem has been discussed as
>>> thoroughly as possible without suggesting any."
>>>
>>>    http://lesswrong.com/lw/ka/hold_off_on_proposing_solutions/
>>