RE: [CD] CD Proposal: SF-LOC (Software flaws in different lines o f code)

[Bill Fithen <wlf@cert.org>]

On Thu, 15 Jun 2000, Pascal Meunier wrote:

> Bill Fithen <wlf@CERT.ORG> wrote:
>
> >It seems truly fundamental to me that the nature of a vulnerability is
> >independent of the mechanism(s) that can be used to correct it. There
> >may be many ways to correct a vulnerability. In fact, it seems obvious
> >to me that a "list" of such corrections of countermeasures is an
> >entirely separate undertaking on a par with CVE (perhaps CCE?).
>
> This begs the question, if we have to analyze the nature of a
> vulnerability to make a CVE entry, haven't we gone too far with
> respect to the stated goals of the CVE?

This is a good point. We should guard against creating a situation
where in-depth analysis is required just decide if a thing is one thing
or two things. Although, I expect there will occur situations where we
cannot acquire sufficient information short of true analysis to
proceed. My inclination at that point (with respect to CVE) is to punt
and just say we don't have enough information and wait till we do. If
we get it wrong, we correct it later.

> >All other things being inconclusive with respect to the split/merge
> >question, if we arrive at this rule and the vendor refuses to answer
> >the split/merge question, then it seems to me the only conservative
> >approach is to split. If we incorrectly split, the only consequence is
> >information redundancy. If we incorrectly merge, the consequence is
> >information loss. Once we split based on the lack of information, the
> >(possibly redundant) entries are marked as 'this is all we know' and
> >left that way until we know more. If at some point in the future (even
> >after they might be voted into CVE), if someone learns enough to
> >"prove" to us they should have been merged, then we merge them.
>
> I agree with this.  Moreover, why not split by default, merge when
> 'someone learns enough to "prove" to us they should have been
> merged', and save the headache?

I like this as a rule of thumb. It has the great virtue of being fast
and lightweight. I am strongly in favor of techniques that will let
entries quickly into CVE, even when they later turn out to have been
suboptimal or even wrong. Pursuing perfection too early may mean the
introduction of delays that make the eventual acceptance of an entry
less valuable merely because of the delay (I am speaking from an
organization with a lot of experience in letting perfection be the
enemy of good enough).

Bill