RE: CD PROPOSAL: HIGHCARD (Interim Decision 8/24)

["Steven M. Christey" <coley@linus.mitre.org>]

Andre Frech said:

>I would propose an ad hoc decision of the board concerning the
>treatment (inclusion, exclusion, or whatever other actions) of any of
>the 'slippery slope' class of high cardinality issues that aren't high
>now, but might most likely be large in the near future.

This makes sense to me, but hopefully we won't encounter these
situations very often.  Do you have a particular example in mind?

>> For general guidance, any "class" of more than 100 vulnerabilities may
>> be considered High Cardinality, unless that class is well-understood
>> and accepted by the community (e.g. "buffer overflow.")
>
>Would a class such as 'buffer overflow' not be addressed by the
>'Different Function, Different Vulnerability' content decision? Or is
>this an issue because the DFDV content decision is still pending in
>the voting stage?

I had provided "buffer overflow" as an example of a well-understood
category of problems, where most of us probably agree that it's
reasonable to distinguish between different buffer overflows.  In
general, other content decisions (such as DIFFUNC) may suggest further
breakdowns.

Consider default passwords, a "class" that to me seems to be at the
same level as "buffer overflow."  DIFFUNC required me to separate Unix
vs. Windows NT vs. routers vs. SNMP community strings, due to the
different functionality of the software that uses those defaults.
With this sort of breakdown, the number of default SNMP community
strings (or default router passwords, etc.) may not be high
cardinality any more.

So, maybe we should only consider High Cardinality after we've made
distinctions using other content decisions.

- Steve