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

Re: Non-public Sources of information

Let's distinguish 2 cases, relying on private or proprietary information to
create entries, and including such information in CVE entries.  

If the CVE included such information, then the information and therefore (parts
of) the CVE could be subject to licensing and the imposition of all kinds of
rules. What would happen if someone yanked their license, or sued MITRE to have
their proprietary information removed, or even worse, to "own" the CVE partly or
entirely?

Relying on that information without including it makes the CVE less
reproducible, objective, and less useful by making discussion of these entries
more difficult (due to the missing information).  You could argue that with
some extra effort that information could be rediscovered, but it could be a
significant barrier.  Certainly it would make the inclusion of CVE identifiers
more difficult in academic work inasmuch as there would be more uncertainty as
to what the entry actually refers to.  It already bugs me to see CVE entries of
the form "problem X in product Y, different from problem X in product Y in
CVE-ZZZZ-ZZZZ".  OK, what's the difference and how can I be sure I'm talking
about the correct CVE ID?  Isn't the point of CVE IDs to know what we're
talking about?  Without references that explain the issues, these entries
essentially defeat the purpose of the CVE so it's pointless to even have them. I
am convinced we'd have more of these obscure entries, without references, if
the CVE relied on non-public information without including it.  I would rather
not even have CVE IDs assigned to problems that cannot be uniquely identified
with public information, because if most entries were to become like that, the
very existence of the CVE could be questioned.

I suggest that all CNAs be required to release enough public information to
uniquely identify the CVEs they assign.  Otherwise, they effectively abuse the
CVE and threaten the very purpose of its existence.

Pascal


On Wed, 1 Apr 2015 21:19:18 +0000
"Landfield, Kent" <Kent_Landfield@McAfee.com> 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.
> 
> Thoughts?
> 
> Kent Landfield
> Director, Standards and Technology Policy
> Intel Security
> +1.817.637.8026
> 
> 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
Page Last Updated or Reviewed: April 14, 2015