Re: Notice of Pilot Activity in CVE Auto WG

[Art Manion <amanion@cert.org>]

On 5/9/17 3:15 PM, Kurt Seifried wrote:

>     > So I assumed we'd have a publishing model where CNA's just publish to
>     > their parent until it hits MITRE.
>
>     I'd suggest a model where every CNA publishes, in at least the CVE MVP
>     format (but more is OK, such as DWF requirements).  I guess this is pull
>     not push?  Parent CNAs would be required to pull/aggregate from their
>     children.
>
> To be clear when we talk about publishing there are two very different
> aspects of this:
>
> 1) publishing the CVE publicly (e.g. in a security advisory)
> 2) publishing the CVE so that it somehow ends up in the MITRE database
>
> and I was talking about #2 only. As for #1 I don't care really (e.g.
> they may simply use the CVE # in a commit/issue tracker and not have an
> advisory per se, but as long as they publish the CVE to their parent and
> ultimately to MITRE who cares). I don't want to start dictacting
> security process/etc to anyone using CVE (e.g. can MUST they publish the
> minimum CVE format in either the CSV or JSON format? what if that data
> is in their advisory format, which is a PDF?).

I'm also only talking about #2.  My assumption is that CNAs submit or
publish a CVE entry when the vulnerability becomes public, using the
proper MVP or MVP+.  A CNA might also publish an advisory (#1), but the
CVE record (#2) is required.

>     This way, anybody can pull from any CNA, MITRE or NVD can pull from
>     all/lots of CNAs.  This allows a lot more flexibility in aggregation,
>     possibly at the cost of more effort for a central aggregator (MITRE).
>
> I think a central aggregation model is the only way to go. Or else we
> admit we're giving up on MITRE having a full view of the database. Note:
> blockchain would solve a pile of these problems... just saying =).

Why can't MITRE just pull from all of its immediately subordinate CNAs
(who in turn are required to pull from theirs)?  That'd give MITRE a
full view.

I won't claim to be a blockchain expert, but I've talked with colleagues
at CERT/CC about a model to sign assertions about vulnerabilities (e.g.,
Red Hat claims a blob of vulnerability information is correct, CERT/CC
agrees and signs, somebody else disagrees and signs...).

 - Art