RE: The Common Vulnerabilities and Exposures taxonomy

["Scott Blake" <blake () homeport org>]

I know of at least a few Editorial Board members that are on this list,
myself included.  I have to disagree with Marcus, however.  The board was
well aware of press release activity as well as other promotional activities
undertaken by the sponsor of the Initiative, MITRE.  Overall, I have to say
that MITRE has done an outstanding job of getting the effort off the ground
and rolling.

The intent of CVE is *not* to replace human-readable descriptions with
numbers, but rather to allow a mapping of the many different human-readable
descriptions (in case you haven't noticed almost every vendor uses different
descriptions and names) into a common framework.  This allows comparisons
between tools, data sharing between tools, and consolidation of data from
multiple sources.  CVE numbers are intended to be a tag on a piece of output
data, not the output datum in its entirety.

Also, the CVE is explicitly not about taxonomies.  It is about enumeration
of vulnerabilities and exposures (and trying to have some working
understanding of what those terms mean).  Adam Shostack and I have worked up
a paper on a taxonomy of techniques for finding vulnerabilities, but as far
as I know, no one is close to a good taxonomy of the problems themselves
(someone correct me on this, as I am sure I'm wrong).

BindView's next major release of HackerShield will include CVE tags in our
descriptions of vulnerabilites, with programmatic incorporation next on the
task list.  We are not replacing anything, just adding a new field in the
output.  I know that most of the other scanner vendors are planning the same
thing and I believe that at least one IDS tool has already incorporated CVE
numbers into their output.

We're looking forward to customer demand to continue pushing us forward.

s

-----
Scott Blake
blake () bos bindview com
Security Program Manager
BindView Development Corp.


> -----Original Message-----
> From: owner-firewall-wizards () lists nfr net
> [mailto:owner-firewall-wizards () lists nfr net]On Behalf Of Marcus J.
> Ranum
> Sent: Wednesday, October 20, 1999 1:08 AM
> To: Rick Smith; firewall-wizards () nfr net
> Subject: Re: The Common Vulnerabilities and Exposures taxonomy
>
>
>
> > Has anyone else looked at this? Is anyone on this list involved with the
> > editorial board?
>
> One of the senior tech staff of NFR is involved in it, and represents
> us on the board. I don't think, honestly, that the vendors have had
> a lot of real input into the effort. :) I know I was kind of surprised
> to see us listed in a press release without anyone asking us first. :)
>
> The idea's got some merit - things will/would/can be better if
> we all use the same terms to describe the same kinds of events.
> That's just common sense. How far it'll go is still somewhat
> open to question.
>
> I, for one, don't think it was a good idea to convert human
> readable text into a non-human-intuitive numeric code. My
> experience with computing systems is that when you do that,
> usability goes into the toilet.
>
> For example:
> CVE-1999-0002 == Buffer overflow in NFS mountd gives root access
> to remote attackers, mostly in Linux systems.
>
> Does that mean my IDS should generate messages saying:
> "66.66.66.66 just tried the old CVE-1999-0002 on 10.10.10.1"?
> instead of:
> "66.66.66.66 NFS mountd buffer overrun against 10.10.10.1
> (CVE-1999-0002)"?
> I know which I'd rather read. ;) Giving it as an option, with the
> default being "human readable" is always a good idea.
>
> There's another problem - what if a vendor knows of something they
> want to look for but doesn't want to share the alert point with all
> their competition? We'd have to fall back on our own strings and
> codes, and pretty soon the taxonomy falls apart. This is just another
> instance of the "standards committees in internet time" problem -
> it's very hard to keep up with _anything_ anymore. :(
>
> I think it may be a good start. Honestly, I probably won't have
> my team invest effort in re-writing our alert outputs to use CVE
> (because we'd have to add over 500 alert points to the CVE database
> to do so) unless there's a huge demand for it. I suspect other
> vendors will also take a "wait and see" approach. For now, it's
> too basic, I feel. Obviously, we can't all agree on the significance
> of a CVE-1999-0303 (oops, excuse me, a BNU uucpd buffer overrun)
> to any given network - and the current messages are not reliably
> tagged to O/S rev, host software rev, affected files, hardware
> architecture, and configuration information. That'd be useful.
>
> mjr.
> --
> Marcus J. Ranum, CEO, Network Flight Recorder, Inc.
> work - http://www.nfr.net
> home - http://www.clark.net/pub/mjr