Re: PROPOSAL: Cluster 20 - DESIGN (27 candidates)

[Bill Hill <bill@mitre.org>]

My .02:
The presence of finger should be an entry.  So should .forward.

- Sometimes their presence is a problem, or shall we say (even though we're
having a problem with the definition) a vulnerability.
- Some tools will report this kind of thing.  That's an important factor.  We
wanted the CVE to aid interoperability.  Need reasonably broad set of entries for
that.
- These are an appropriate level of abstraction; a reasonably atomic thing.

WRT the discussion below, sure, if we go nuts we could also list A/C power,
batteries, ethernet cables, and more as vulnerabilities.  We don't have a
sufficiently precise definition of vulnerability to absolutely dictate
decisions.   So, for now formalism may not always serve us well and we need to
apply judgment, which will of course vary.  But keeping the purposes of CVE in
mind might help.  If it appears in some tools, put it in.  If some subset of the
reviewers can give good reasons something constitutes a vulnerability, put it
in.  If there is history of exploitation, put it in.

On a related note, I do, however, think our attempts at formalism regarding
distinguishing between one/many entries, etc. are useful, and needed.

Bill


"Steven M. Christey" wrote:

> Gene Spafford said:
>
> >Okay, then if you want to list anything that *might* be considered a
> >vulnerability, I want to see an entry for each version of Windows.
> >Running it is a vulnerability that can lead to compromise.
> >
> >Then, one entry for each version of Unix, and one for each version of Linux.
> >
> >Then, one for each WWW browser capable of running applets or doing
> >downloads, and one for every MIME-capable mailer.
> >
> >If you are going to be kitchen sink repository, let's go right to the
> >source of the plumbing problems, so to speak.
>
> I will assume that the point here is that the CVE definition of
> "vulnerability" can become so diluted that anything and everything
> could be placed into it.  And certainly that is a risk, especially as
> we begin to consider these more ambiguous cases where there isn't
> necessarily agreement across all segments of the security community.
>
> With respect to the particular examples that you cite, I wouldn't
> expect them to be accepted into the CVE, as they probably are not a
> violation of any reasonable security policy that is used by a
> significant segment of the population.  Aside from operating system
> purists who (more or less) joke that the simple presence of a rival OS
> represents a security risk, I doubt that most individuals concerned
> with security would think this way.
>
> Also, these particular examples are probably at too high of a level of
> abstraction.  However, if we don't make sure that the content
> decisions for design flaws are sufficiently narrow, then it could be
> argued that such entries would need to be made.
>
> There may be some cases where we can't all agree what constitutes a
> "vulnerability."  But if we can all agree when something *doesn't*
> constitute a vulnerability, then we can keep the scope of the CVE from
> getting so broad that portions of it aren't useful to anyone.
>
> It would be very useful to get additional input from other Editorial
> Board members regarding these kinds of content decisions.  While these
> particular content decisions were used for the draft CVE, the
> Editorial Board discussions will have a direct impact on the final
> content decisions that are used for the publicly released CVE.
>
> - Steve
begin:vcard 
n:Hill;William
tel;work:703-883-6416
x-mozilla-html:TRUE
org:The MITRE Corporation
adr:;;1820 Dolley Madison Blvd;McLean;VA;22102;
version:2.1
email;internet:bill@mitre.org
title:INFOSEC Engineer
fn:Bill Hill
end:vcard