Re: Non-public Sources of information

[Art Manion <amanion@cert.org>]

On 2015-04-01 17:19, Landfield, Kent wrote:

> While I understand the position stated, what happens if this trend
> continues and CVE is denied more and more valuable sources of
> information?  Since the intent is to identify vulnerabilities, should we
> discuss the “public” aspect a bit? 
> 
> If there were means to access those sites supplied to MITRE and NIST
> (CVE/NVD) and enough information could be gleaned to create CVE and NVD
> entries respectively, why would “public” only access be required?  I am
> not advocating any position here. I am just trying to understand and
> discuss the policy of requiring all valuable information sources to be
> public.

In terms of getting enough information to create a functional CVE entry,
access for CVE/NVD would work.

In terms of transparency and basic citation/reference practice, access
for CVE/NVD but not for others won't work.

Personally, I'm OK with the decision not to reference non-public
sources, particularly as long as other public sources remain available.
 Secunia and ISS are generally collectors/aggregators (not sure if
Secunia is producing original vulnerability reports these days.)

If we were in an environment where much vulnerability information was
behind pay/subscriber walls, and CVE was given access, and implicitly a
role in publicizing some of the otherwise non-public information, that'd
be a reason to reference non-public sources.

Referencing non-public sources potentially drives eyballs to those
sources, and those eyeballs might be inclined to register/pay to see the
secrets that CVE was talking about.  That'd put CVE in an odd position
of marketing for the non-public sources.

Also reading Pascal's email, CNAs should be required to publish
sufficient information to support an accurate CVE-ID assignment.

And the "only public references" rule (or if it's changed, then guidance
on non-public references) should be documented.  It may be, but I
couldn't find it.

  http://cve.mitre.org/data/refs/index.html

Regards,

 - Art




> From: <Boyle>, "Stephen V." <sboyle@mitre.org <mailto:sboyle@mitre.org>>
> Date: Wednesday, April 1, 2015 at 9:39 AM
> To: cve-editorial-board-list <cve-editorial-board-list@lists.mitre.org
> <mailto:cve-editorial-board-list@lists.mitre.org>>
> Cc: "Boyle, Stephen V." <sboyle@mitre.org <mailto:sboyle@mitre.org>>
> Subject: Non-public Sources of information
> 
>     Recently, two named sources of vulnerability information for CVE,
>     Secunia and
> 
>     X-Force, have implemented login requirements, and have restricted
>     which logins
> 
>     are allowed access. We recognize that such restrictions are part of
>     a trend in
> 
>     which some sources are attempting to balance their desire to provide
>     the public
> 
>     with useful vulnerability information with the fact that it is often
>     very expensive
> 
>     and resource-intensive to curate such information.
> 
>      
> 
>     As has been our documented practice, CVE can only refer to
>     information that is
> 
>     publicly accessible and free for use by anyone. Any source
>     referenced by CVE
> 
>     is free to implement any form of access control, such as a login, as
>     long as the
> 
>     control (1) does not limit which people or organizations can use the
>     source,
> 
>     and (2) does not impose any excessive inconvenience to the user.
>     E.g., if any
> 
>     requester can create and obtain a login for otherwise unrestricted
>     access, such
> 
>     as by providing an email address, CVE still considers the source to
>     be “public.”
> 
>      
> 
>     If, however, access to the information is denied by the provider for
>     any reason
> 
>     that MITRE determines is intended to limit who is allowed to access
>     it, then
> 
>     the source is not considered “public” by CVE and will be not be
>     used, even if
> 
>     CVE is allowed access while others are restricted. Similarly, any
>     public source
> 
>     referenced by CVE cannot contain any restrictions for the sharing or
>     reuse of
> 
>     its information, beyond the usual expectations that users include proper
> 
>     attribution to the source, avoid plagiarism or reposting, etc.
>     Sources that are
> 
>     inherently open without restrictions, such as Full-Disclosure or
>     Bugtraq, are
> 
>     presumed to have no access restrictions.
> 
>      
> 
>     As a result of Secunia’s and X-Force’s decisions to restrict access
>     to their
> 
>     vulnerability information, we wanted to formally notify the Board
>     that CVE
> 
>     will no longer reference Secunia or X-Force in our entries. If their
>     access policies
> 
>     change in the future such that they again become publicly
>     accessible, then we
> 
>     will again reference their vulnerability information.
> 
>      
> 
>     Please note that although OSVDB restricts access to its search
>     functionality,
> 
>     CVE still considers OSVDB as a “public” source. While CVE no longer
>     directly
> 
>     monitors OSVDB’s site, since OSVDB allows people with interactive web
> 
>     browsers to access individual OSVDB entries, CVE is free to reference
> 
>     OSVDB entries as long as they are cross-referenced in some other source
> 
>     or disclosure that is publicly available.
> 
>      
> 
>     MITRE is not considering the removal of previous entries in the CVE
>     List that
> 
>     cite Secunia, X-Force, or other sources from the past that were
>     originally public
> 
>     but then restricted, such as VUPEN.  The references were public at
>     the time
> 
>     we associated them with the CVE entries and may serve as important
>     correlating
> 
>     identifiers, or they acted as the primary or secondary source of
>     information in the
> 
>     CVE description. Any such mass removal would affect thousands of CVE
>     entries,
> 
>     which would have unexpected adverse impacts on downstream consumers who
> 
>     monitor and act on CVE changes.
> 
>      
> 
>     Best Regards,
> 
>     The MITRE CVE Team
>