Re: PROPOSAL: Cluster 25 - IDS (5 candidates)

["Steven M. Christey" <coley@linus.mitre.org>]

Steve Northcutt said:

>I am very concerned about the direction the CVE is going from
>vulberabilities into best practice and engineering design.

This is why later clusters such as these have been labeled Medium or
High controversy :)

>It is just a matter of time till I see an candidate fly by saying palm
>pilot screens are too small allowing for the possibility of not being
>able to read attachments with email or some such.

I believe that once the Editorial Board has hammered out the
high-level content decisions for the CVE - including modifying or
clarifying the CVE vulnerability definition - then we will have a set
of principles to guide us that will hopefully avoid the sorts of
problems you describe above from ever becoming CVE vulnerabilities.  I
think that these discussions are helping to clarify that, if not in
the acceptance of the candidates, then by their rejection.

To me, there are two levels of acceptance for the various bullets in
the CVE vulnerability definition.  I believe we can all agree on the
first level, i.e. something is a vulnerability if it allows you to
escalate privileges, or access data you're not supposed to, or crash a
machine.  These are violations of a "Universal Policy" that I've
alluded to in the past.

It's the murkier waters of these more controversial candidates where
the liberal definition of the CVE vulnerability is beginning to clash
with some/many Board members' own definitions of vulnerabilities, and
that includes design problems, information gathering, etc.,
i.e. "Conditional Policies."

Spaf's rule of thumb (or an adaptation thereof) seems like a good
start to distinguish between design problems that are fundamentally
flawed and trivially compromised, e.g. XOR encryption or the rexec
service, and "best practice" design problems where there is no clear
workaround or solution.

One could argue that Smurf is a design problem, but there's a
workaround/solution.  IPv4 or TCP/IP have design problems for which
there are no real workarounds or solutions,
e.g. sniffing/spoofing/hijacking.

A good criterion for every CVE vulnerability might be "is there a
plausible and achievable solution for this?"  That prevents "best
practice" design flaws from entering the CVE, but allows fixable
design flaws to be part of it.

- Steve