Re: CONTENT DECISION: Content Decisions for "Password Selection" problems
On Fri, Jul 16, 1999 at 01:21:41PM -0400, Steven M. Christey wrote:
> Aleph One said:
> >If we follow the logic we did during our meeting at Black Hats then
> >each distinct non-announced account/password should be a separate CVE
> >entry. If I am using a scanner I want to know whether it knows about
> >the specific 3com backdoor, not whether its knowns about backdoors in
> >some general sense. Ditto for default passwords.
> While there was agreement between you and Adam, I need to keep my
> promise not to be overly swayed by what was discussed at that meeting,
> including this particular issue.
> Let's separate non-announced accounts/passwords from "announced"
> default passwords.
> Assuming that announced default passwords are a high cardinality
> issue, is "default password" at the same "class" level as, say,
> "buffer overflow" or "race condition"? If so, then that's an argument
> for having separate entries for announced default passwords. I agree
> that from a scanner perspective, you want to know what specific
> default passwords it tests for. However, as Adam has indicated in the
> past, it's also reasonable for a scanner to announce that it checks
> for "X *instances* of CVE vulnerability V," where the instances are at
> a lower level of abstraction of the CVE.
Lets take another look at this argument against high cardinality.
Why are we so set against it? What is the problem with having
100 entries for default passwords? By all accounts the CVE will
have more than a thousand entries in the near future with or without
the high cardinality entries. So what is the point of trying to
stop high cardinality entries for entering the CVE? Either way
how many default passwords are there? 100? 200? Is that high cardinality?
Not sure we would all agree.
> - Steve
Aleph One / firstname.lastname@example.org
Fingerprint EE C9 E8 AA CB AF 09 61 8C 39 EA 47 A8 6A B8 01