Content Decisions for Inclusion of Design Faults

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

Elias Levy asked:

>Are we going to start handing out CVE ids for low level design faults?
>E.g. lack of encryption at the IPv4 packet level? lack of resource
>allocation protocols? the used of DES instead of Triple DES? etc

I have defined several content decisions related to this, which is on
the agenda for the AXENT meeting.  Current candidates that are
affected by unresolved CD's will not be added to CVE until the CD's
are resolved.  (A few candidates slipped through the cracks and became
CVE entries before I added a formal "content decisions" field to CMEX.
They may be deprecated in the future.)

Some of these were discussed briefly at last August's review meetings.

With respect to Elias' question, the following CD's are slated for
*later* discussion:

CD:DESIGN-WEAK-ENCRYPTION - should we include "weak" encryption (and
how do we define "weak")?

CD:DESIGN-WEAK-AUTH - should we include "weak" authentication?

CD:DESIGN-NO-AUTH - should we include problems with "no"
authentication?

CD:DESIGN-SPOOF - do we include designs that allow spoofing, and how
"good" does the spoofing have to be?


Some other CD's of interest:

CD:EX-BETA - should we include beta code?

CD:EX-CLIENT-DOS - should we include client-side DoS (e.g. for ICQ and
the like)

CD:EX-ONLINE-SVC - should we include problems in online services,
e.g. Hotmail, where the "software" is not necessarily resident on the
client?

There are a number of others to be discussed as well, about 40 in all
at this point.

The CD's above are what I have begun referring to as *inclusion
criteria* - what's important enough to be included in the
database/list/summary/analysis/etc.?  *Abstraction criteria* include
things like the Same Codebase content decisions, that specify how to
fix the level of abstraction for an entry or entries.

- Steve