Re: The Common Vulnerabilities and Exposures taxonomy

[Bill_Royds () pch gc ca]

Something else I noticed about the board composition was that no  users are
involved. Yes, academics and developers should be involved, but this kind of
taxonomy also needs the sysadmins and corporate security personnel to add real
word insight to various classifications.




"Marcus J. Ranum" <mjr () nfr net> on 20/10/99 01:07:50 AM

Please respond to "Marcus J. Ranum" <mjr () nfr net>

To:   Rick Smith <rick_smith () securecomputing com>, firewall-wizards () nfr net
cc:    (bcc: Bill Royds/HullOttawa/PCH/CA)
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

Attachment: att1.eml
Description: