[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Candidate numbering scheme

I feel very strongly about this topic but I have said my peace so many
times already that I'm afraid some of you will be peeved if I keep
interjecting. I'm very glad to see some new posters commenting on their
feelings about this, and since they appear to now be reading the
discussion, I'd like to restate my position.

I'm afraid that the CVE is being taken too technically. Not enough
attention is being paid, IMO, to the CVE's marketing aspects and
requirements. While it may make it easier to compare Vendor products as
a result of the adoption of the CVE, such easy comparisons are not going
to compel Vendors to adopt and maintain CVE references. What's in it for
them?

If, otoh, we can get all Vendors, both security products Vendors and
application/OS Vendors, to utilize the CVE in their product information
(alerts, reports, fix details, etc...), then Vendors will not only be
compelled to adopt it, but encouraged also as it will make their
customers lives much easier. Customers who are exposed to environments
where one product refers to a CVE and the CVE number allows them to find
references to it in many places (including other Vendors), will promote
the value of the CVE and other customers will, eventually, come to
demand it in all venues. Therefore;

We cannot possibly be thinking we need to "get a system out there to
try".

*The* only thing this effort is going to achieve is to get everyone to
refer to the same issue using a common unique name. Nothing more, and
nothing less.

Any "stab at it" can only be proven or disproved successful by the
adoption by as large an array of Vendors as possible. Any effort at
adoption requires a significant effort to modify current dBs and
reporting tools to refer to the CVE number. Ergo, we're unlikely to get
a Vendor to change from our first "stab at it" assuming they put the
effort in to adopt.

The Candidate question needs to be viewed in the context of what Vendors
are going to get out of the CVE number usage. Assuming we have convinced
all Vendors that its a good thing to refer to the CVE number, we need to
ensure that we do nothing to diminish its value (whatever that might
be).

Some have voiced my sentiments that any "other" numbering scheme has the
potential to diminish the real/perceived value in the CVE numbers.
Therefore, there should either be *no* Candidate numbering scheme, or,
it should be as similar as possible to the CVE numbers so as to promote
the CVE numbering rather than conflict or confuse its use.

The problem arises that currently the "official" CVE number will not be
assigned to an issue until after that issue has been thoroughly
discussed and accepted as a real and unique CVE item. So, during the
candidacy period, how do we refer to something that has not yet been
assigned a CVE number (and may never be assigned a CVE number)?

If the discussion about a CVE Candidate is closed to a small working
group, we can likely use something like "TEMP-99-01" or some other
trivial name to keep the small working group on topic.

However, if the archives of those discussions are made publicly
available...

or, if the general public is permitted to view the conversations in
real-time...

or, the candidacy of any item is discussed in any of the existing forums
(such as NTBugtraq or Bugtraq)...

and the trivial working group name is referred to...

and it is does not promote the usage of the CVE numbering convention...

then we have the, I believe, very real potential to harm the adoption or
usage of the CVE numbering system.

The issue, to me, breaks down into 3 distinct topics of discussion;

1. Who sees any of the candidacy discussions? (read: who is "the
public")

2. How do we refer to candidates without depreciating the value of the,
later assigned, CVE number?

3. How do Vendors get CVE information into their products, information
dBs, and security bulletins in a timely fashion?

IMO;

1. Candidacy discussions should be open to the world to view. I think a
real-time archive of candidacy discussions should be hosted, probably by
Mitre, via the web. The CVE-review mailing list should remain closed via
SMTP to just the accepted participants (avoiding Mitre to have to host a
mailing list with 25k+ recipients).

2a. Candidates are referred to via the Subject Line of the message that
introduced it to the CVE-Review list. IOW, we don't give it a "name", we
just ensure that all discussions uses the same subject line. This avoids
any number reference that is non-CVE.

2b. We use a Mitre assigned CVE surrogate (Candidate number). If it
becomes a CVE, Mitre alters some small portion of the Candidate number
to turn it into an accepted CVE number. This ensures that the majority
of the references to the Candidate number can easily be translated into
CVE numbers. Splits will occur (i.e. a Candidate will be split into
multiple CVE entries) as will mappings (i.e. a Candidate will be mapped
to one or more existing CVEs). All Candidate numbers should be included
in the CMEX for all relevant CVE numbers once the Candidate has been
fully discussed.

3. Vendors are very likely going to go public with information about a
CVE Candidate *prior* to Mitre's determination as to whether or not a
Candidate should become one, or more, CVEs. e.g. How does Microsoft
include a CVE number in their Security Bulletin and Knowledgebase
article about a particular issue+fix if the number has not already been
assigned? If they don't do it prior to release, how do we ensure it gets
done after the fact? If its not done, then how much value is there in
the Scanner Vendor's use of the CVE number? The value of the CVE number
is depreciated if the application/OS Vendor doesn't use it in their fix
information or information dB. e.g. Scanner reports that it has
discovered CVE #1 in a machine, and then wants to refer to a Vendor's
fix information to correct the problem. If the application/OS Vendor
doesn't refer to it as CVE #1 as well, a large part of the value in a
single defacto naming convention is lost.

So, in conclusion, its my opinion that;

1. The CVE number must be assignable at the time of discovery so all
Vendors can refer to it from day dot.

1a. The CVE numbering system must be able to denote an issue's
"accepted" or "pending" status.

1b. There must be enough unique material in the name such that its
status does not dramatically alter the name.

1c. Mitre has to, either, be responsive in assigning new CVE numbers
with a pending status upon request, or, endorse/facilitate some
automatic mechanism for number assignment.

2. All Vendors must understand and appreciate the distinction between
"accepted" and "pending" status and should refer to the CVE number in
such a fashion (so as to ensure that consumers understand the
distinction also).

2a. Vendors must attempt to keep any reference to a "pending" CVE number
up-to-date. That is, upon a CVE Candidate's acceptance, Vendor
information should be updated in a timely fashion to avoid continued use
of the Candidate number.

2b. When referencing CVE Candidates, Vendors should provide a link to a
Mitre maintained page that explains the distinction between "accepted"
and "pending".

2c. Mitre should maintain a list of all numbers, providing an
up-to-the-minute view of what is "pending" and what has been "accepted".
Items should be referable by either their Candidate or CVE number (i.e.
I should be able to search on a number that uses a "pending" status
indicator and find the official CVE if it has since been "accepted".)

To me, this means that there will be gaps in the CVE numbering system,
and that those gaps may or may not be large (it irrelevant to me). There
may be Candidates discussed widely, even in public, that do not become
"accepted", so be it, that is the purpose of the decision process after
all. It means there will need to be more entries in the CMEX than have
been discussed previously since all Candidates should be referenced in
all CVE entries.

The numbering could be as simple as;

Pending: CAN-1999-0001
Accepted: CVE-1999-0001

or

Pending: CVE-P-1999-0001
Accepted: CVE-A-1999-0001

The general public isn't going to understand, readily, the fact that
some Candidate has not been accepted as an official CVE. This sort of
distinction is probably irrelevant to anyone outside the security field.
If USA Today reports on some new vulnerability in IE, and by some
miracle refer to CVE-P-1999-0001, so be it. If its determined later that
it wasn't unique, wasn't new, and therefore is never converted to
CVE-A-1999-0001, so what.

If, otoh, Microsoft releases a Security Bulletin and describes an issue
and never mentions the CVE number at all (pending or accepted), we stand
little chance of convincing all Vendors to adopt the numbering system.

As long as the bulk of the name looks the same, it stands a chance of
being adopted and promoted. Its status, pending or accepted, is far less
relevant to our overall effort. Those who really need to understand the
difference will, its hoped, be able to find the accurate and up-to-date
information via the CVE web site.

For this working group, figuring out what should be in the CVE and what
should be "accepted" is far easier than getting the whole CVE concept
adopted and promoted.

I wouldn't be at all surprised if the IETF never imagined the impact
that RFC numbers or IANA Port Assignments have taken on. Even the fact
that an RFC is not a specification, but a work-in-progress, is largely
irrelevant to the vast majority of people who refer to them. While some
may see this lack of distinction as a bane, fact is that people
understand the language of RFC numbers and use them everyday, largely to
everyone's benefit.

I think we should pay attention to this similarity.

Cheers,
Russ - NTBugtraq Editor
Page Last Updated or Reviewed: May 22, 2007