[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAFJuDmMn+tNjYrcJXQoLokV-sPJphBRE-1OGWn_WYjtRoDfCoA@mail.gmail.com>
Date: Sat, 5 Mar 2016 15:25:49 -0500
From: Adam Caudill <adam@...mcaudill.com>
To: "oss-security@...ts.openwall.com" <oss-security@...ts.openwall.com>
Cc: cve-editorial-board-list <cve-editorial-board-list@...ts.mitre.org>
Subject: Re: Concerns about CVE coverage shrinking - direct
impact to researchers/companies
I very much like the idea of being able to get an ID instantly - it
greatly simplifies an otherwise time consuming process. That said, I
can see some issues with OVE:
* No Lookup - For a customer, going from OVE to what it represents
could be complicated. It depends entirely on the researcher or vendor
publishing a reference for that ID.
* Invalid Entries - As noted, there's no way to see if a given ID is
considered valid, and while there is value to just having an ID, this
model makes later curation more difficult. With no information behind
the ID, there's no opportunity to later expand into a more complete
solution.
Here is what I would like to see:
* Simple ID Request - Data required should be minimal, though I think
a few basic items are needed. Perhaps vendor, product, version(s),
title, and contact information. Optionally, the requestor should be
able to provide their GPG public key, a detailed description,
reference URL(s), etc. The ID should then be instantly issued, and
given a status of assigned.
* Simple Updates - The requestor should be able to easily add / update
information as research, vendor coordination, etc. proceeds. Vendors
should have a similar mechanism to provide additional information.
Prior to publishing, a few additional items should be required, such
as the detailed description, if not included in the original request.
* Curation & Publishing - At the point that the requestor is ready to
publish the issue (may be at the time of the initial request, such as
the requests that we normally see on this list, or at a later time
after working with the vendor), they can request publication, and this
is where curation comes into play. This is the first point where
someone other than the requestor and vendor have a role to play. This
could be handled in a number of different ways - most likely review
the information listed and if there is confirmation of the issue (the
code that is vulnerable, a change log, or other vendor confirmation),
then it is published and all the information is then made public.
There are various points here where additional services could be added
as time goes on, vendors could register their contact information
which could allow them to be automatically notified when a new entry
is added for one of their products. Could offer assistance in
contacting unresponsive vendors, etc. - it is important though to
focus on automated functionality. I suspect that excessive manual work
is one of the main reasons that CVE has failed to meet the needs of
the community.
--Adam Caudill
http://adamcaudill.com
On Sat, Mar 5, 2016 at 12:20 PM, Solar Designer <solar@...nwall.com> wrote:
> On Fri, Mar 04, 2016 at 02:08:15PM -0500, Art Manion wrote:
>> I think it's been said on this list previously -- these are two separate
>> activities:
>>
>> 1. Assigning IDs
>
> Problem solved:
>
> http://www.openwall.com/ove
>
>> 2. Analysis, deconfliction, write-up
>
> Having IDs is of some use even without or before all of that.
>
> Alexander
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
