Re: Regarding CVE assignments on oss-sec mailing list

[Kurt Seifried <kseifried@redhat.com>]

So I think we have defined the problem from an external view (e.g. what CERT/RedHat are experiencing as symptoms), but we haven't heard anything from Mitre yet. Steven can you comment/can someone from Mitre comment on all this?

On Fri, Nov 27, 2015 at 4:29 AM, Scott Lawler <scott.lawler@lp3.com> wrote:

What do we as the board need to do in order to fully define the issue?

- Do we need to find a way to get more resources for MITRE?
- Is there a depth of research required issue as well?
- What process step are we stuck on the most often?
- Do we have any process metrics available so we can make informed inputs?

We could in parallel start thinking about potential solutions.  I do agree with Art that we need to understand the issue well before we jump to solutions.

I think MITRE really needs our help on this.   We need to solve this to help that team continue to succeed.

Scott

> On Nov 27, 2015, at 1:14 AM, Art Manion <amanion@cert.org> wrote:
>
>> On 2015-11-27 00:31, Kurt Seifried wrote:
>>
>> On Thu, Nov 26, 2015 at 10:27 PM, Art Manion <amanion@cert.org
>> <mailto:amanion@cert.org>> wrote:
>
>>    The current assignment model/process is under stress and probably needs
>>    to change for CVE to remain broadly useful and relevant.
>>
>>    Any thoughts on how to go about this?  Starting with an evaluation of
>>    current state/issues?
>
>> So I know we have something like 1000+ assigned CVE's that are public
>> and not in the database yet. So the backlog is real.
>
> So that's an item under current state/issues.
>
>> One thing I had suggested to Steve Christey ages ago was "lightweight
>> CVEs", e.g. instead of a full write up, just at least give the url for
>> the OSS-Security assignment, or the official vendor advisory/etc (for
>> cases where I had privately assigned it for a project/etc.). At least
>> this way people can track down some info on the CVE easily (you can
>> Google, but you get a lot of "reserved CVE" hits you need to filter
>> out). These lightweight entries could always be promoted to "full CVEs"
>> later on if needed.
>
> I generally like the idea (a speed/quality tradeoff), but let me suggest
> some process -- figure out where CVE is and what problems it faces
> before trying to solve them:
>
>  http://lesswrong.com/lw/ka/hold_off_on_proposing_solutions/
>
> Regards,
>
> - Art

--

--
Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Red Hat Product Security contact: secalert@redhat.com