-----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-----
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 13:44:46 PDT