RE: The Common Vulnerabilities and Exposures taxonomy

[Russ <Russ.Cooper () rc on ca>]

-----BEGIN PGP SIGNED MESSAGE-----

CVE IS NOT A TAXONOMY OR A DATABASE.

I'll just start each message about this topic with that line if you
don't mind.

> I don't think the CVE quite gets us to a common definition of what is
or is
> not a vulnerability.  Different people are concerned with different
things,
> and something not of interest to one person may be very important to
> another.

Well, its not really our intent to actually bring us to a common
definition. What is our intent is to allow "definition providers" a
way of telling everyone what it is they're defining. So, for example,
we don't talk about the level of risks associated with a given
"thing", whereas, many tool vendors will attach severity to the same
"thing". Our intent is purely to ensure that if Vendor A talks about
"thing B" and Vendor C talks about it too (loosely, identically, with
different emphasis, from a completely different perspective), Vendor C
would make us all happy if he/she referred to it (somewhere) as "thing
B"...or more correctly, CVE-1999-xxxx.

There's absolutely no attempt to say that any Vendor should, or should
not, say whatever they want to say about it. Its up to them.

Ergo, the definitions of the "thing B" by two different Vendors may be
very different (e.g. "risk" versus "feature" comes to mind).

We are, however, attempting to enumerate what is seen, cumulatively by
the Editorial Review Board, as "things" that need to be included in
the enumeration. Since the board has broad representation, its hoped
that the enumeration's will reflect that.

However, there is no stated intent to say to anyone that just because
a "thing" is not listed in the CVE, it is not a vulnerability/(use
your favorite word). We do hope, however, that it will be as complete
as possible.

> One example of where this impacts the CVE is the way the CVE
sometimes
> summarizes many issues into a single entry.  For example, one NT
entry is
> something like "Auditing permissions set incorrectly" (sorry, I can't
> remember the exact number).  This assumes that everyone will be want
to
> have the exact same settings, which likely isn't the case.  If you
really
> want to do an audit to see if someone is complying with their (local)
> security policy, you have to take this into account.

If I'm right about the "Candidates" you're referring to, then you need
to read them again. There is no CVE entry for incorrect audit
settings. There are "Candidates", or CVE entries waiting for
sufficient votes, that refer to NT events occurring which do not
produce audit entries when it is expected they should. That's a very
different animal than whether or not you should or shouldn't use a
feature.

Further, in discussions about what "exposures" should mean, there's
been the suggestion that it could be classified as an exposure that a
system, with auditing capabilities, is configured not to audit. I
certainly don't see how this represents any conflict. There's no
assumption that you want your box to be secure at all, let alone
whether or not you should have auditing enabled if its
available...however, it makes sense from an enumeration perspective to
have an entry to refer to that denotes that a particular security
feature hasn't been enabled.

Heck, if most of us ever tried to completely appease the ISS scanner
we'd have to cut all of the wires...;-] I've certainly never seen a
clean bill of health.

> From the vendor's viewpoint, a product that helps people who want to
do
> this will have to check, track, and report many different audit
settings,
> and provide the user the ability to tune the settings to fit. 
Whether
> you call this one check or many, a useful product simply has to
provide
> this.

And that level of abstraction is beyond the scope of the CVE today. It
may be that at some point we strive to achieve that level of detail,
but if we did we'd be talking about 100s of 1000s of entries (File
ACLs, User Permissions, Registry DACLs, etc...)

This is what a VdB does, not the CVE.

Cheers,
Russ - NTBugtraq Editor

-----BEGIN PGP SIGNATURE-----
Version: PGP 6.0.2

iQCVAwUBOBClMRBh2Kw/l7p5AQG+qgQApvFEfnzhjssPhyPzNnlrr7pKI8A5H3yF
k6/LSzKnSXGOy9CA0wa0x4azTp0O5OvhWHICSxg68G2TsyYR1f0xhcajW+WzqECg
l8PiagcS/mQJxXiA9yf5No2b6IhR0CRvLrLb1vvF6rLap85MNmS/TkRdYAmAruKI
gjSoX0ROP9w=
=BsOp
-----END PGP SIGNATURE-----