RE: Initial Guidance on Linux Issues

["Mann, Dave" <damann@mitre.org>]

>Mark J Cox wrote:
>> Our (Red Hat) processes and procedures require that every vulnerability is
>> given a CVE name.  We use CVE as our primary key in a number of situations
>> including our bug database and CVE database as well as for internal
>> tracking of issues, instead of using any other unique identifier.


Mark, parroting this back to you to confirm what I think you are saying, I take this to mean that you believe full coverage of the Red Hat source is required (and, as the Red Hat CAN, you are willing to ensure this).  Is that correct?


Art Manion wrote:
>If CVE is not to be funded/staffed to cover Linux packages (much less
>small PHP web apps and Chinese software), somebody else (CNAs?) has to
>do more assignment/tracking.

Several things here...

FUNDING IS NOT THE ISSUE - I really, really, really want to keep funding levels out of this discussion as much as possible and keep this focused on prioritization and relevance. We've asked if it is required to give full coverage for all vulnerabilities disclosed in the following 4 Linux distros: Debian, Red Hat, Attachmate: SUSE and Ubuntu (Linux).  Mark has argued that for Red Hat, the answer is yes.  What about the other three?  Is it important that they have complete coverage or does complete coverage create unwanted noise?  If the answer is yes, the other 3 Linuxes need to be completely covered, then please don't assume that funding, staffing and processes will prevent us from accomplishing this.  They may.  They may not.  First we need to know if these are sources that need complete coverage.

FOREIGN LANGUAGE DISCLOSURES - At this point in time, we are excluding all non-English sources from consideration.  This isn't a funding issue.  Partially, it's a language barrier issue.  It also relates to the fact that different markets have very different disclosure practices.  Our working assumption is that CVE will be one of many world wide ID structures and that no amount of funding will change that.


>I'd suggest we look at some form of more distributed CVE assignment,
>with more authority (for lack of a better word) given to CNAs, and maybe
>adding CNAs.  Maybe if CVE's role was to "accredit" or monitor CNAs,
>maintain the master list, and handle disagreements, then CNAs would do
>the bulk of the assignment.  I don't know exactly how far this direction
>to move, or what it would mean for CVE's efforts to disambiguate and to
>write the dense CVE text that goes with an entry.

To a large extent, we already do this.

The issue isn't the oversight of CNAs in their ID assignments.  The issue is in capturing well formed CVE descriptions (the definition of that is changeable).  Authoring descriptions is costly business and, as I noted in another email, if CCE is an example, making well formed descriptions a requirement for id assignment is proving to be a very large dis-incentive.

Again, let's try to postpone the brainstorm on "how to" as much as possible.

Let's focus first on what needs to be covered.

>Maybe the board could come up with a definition of "sufficient coverage,
>quality, and speed," then look for ways (including effort/funding) to
>meet that definition.  Then the exercise is requirement building, not
>budgeting what is possible with current effort.

This discussion is coming.  Again, let's first focus on what to cover and then we can discuss how to cover it.  Quality of descriptions, process, speed...  All those discussions are teed up.


-Dave
==================================================================
David Mann | Principal Infosec Scientist | The MITRE Corporation
------------------------------------------------------------------
e-mail:damann@mitre.org | cell:781.424.6003
==================================================================