Re: Level of Abstraction Issue: Similar Applications, "Same" Vulnerability

[Bill Hill <bill@mitre.org>]

Dave Mann wrote:

> <SNIP>
> However, I do agree completely with Northcut who
> reminded us to keep attacks/exploits and vulnerabilities
> separate in our minds. I believe this is a fundamental
> distinction and the "same attack" language fuzzies
> this line.  Maybe "same opening" or "same chink in the
> armor" is better?

I'm open to different terminology, but I think you are changing the meaning
here.  Opening and chink seem  to me like vulnerability, and so would not
stand alone to help define vulnerability.  Perhaps "action" would replace
attack.  So, when you perform action(s) X you get outcome Y.  X and Y define
the vulnerability.  This might help make more explicit that we're talking
about what is done, not how.  So for example we don't care which program you
used to send the nasty packet, but nasty packet + blue screen = ping of death.

> <SNIP>
> Two quick quotes from recent posts...
>
> Russ Cooper writes:
> > My vote is that we work on the assumption that "Same Attack/Same
> > Results" should be the starting point for any CVE item, and, assuming
> > details are forthcoming from a vendor, the CVE item gets revised
> > according to the details as they unfold.
>
> Bill Hill writes:
> >  So even if tool A and B detect the same number of CVE
> > vulnerabilities, but tool B detects 100 more cases or instances of some
> > vulnerabilities, then in some sense tool B is more capable than A, and I
> > think people will understand that.
>
> Note that in both cases, both Russ and Bill are assuming
> or implying the need to manage vulnerability information at
> (at least) 2 levels of abstraction.  Hold onto this thought
> while I go on a minor rant...
>

I see value in different levels of abstraction, including possible other
approaches that we have not yet invented or discussed yet.  But I don't think
that _we_  have to manage that.  It should be the province of  vulnerability
databases that use other layers of abstraction to encode that type of
information.

> <SNIP>
> 5) A CAVEAT REDUX
> In suggesting that we consider a 2-tiered enumeration
> (and hence, naming scheme) I do NOT mean to suggest
> that the decision rules for each level of abstraction
> are necessarily clear.  <SNIP>

Right.  So lets only tackle one hard problem, not two.  But even more to the
point,  would it serve our primary purposes for us to add this complexity vs.
only having "same attack" be the method?

Bill
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