再保险:非公开的信息来源

让我们区分2例,依靠私人或专有信息来创建条目,和包括信息CVE条目。如果CVE包含这些信息,那么这些信息,因此(部分)CVE可能受到许可和实施各种各样的规则。会发生什么如果有人拽他们的许可,或者起诉横切了专有信息,或者更糟的是,“拥有”CVE的部分或全部吗?依靠这些信息没有包括它削弱了CVE可再生的,目标,那么有用,使这些条目的讨论更加困难(由于缺少信息)。你可以说一些额外的努力,信息可能会被重新发现,但它可能是一个重大障碍。当然会的CVE标识符在学术工作更加困难因为会有更多不确定性条目实际上指的是什么。它已经错误我看到CVE条目的形式“问题X在产品,不同于问题X在产品CVE-ZZZZ-ZZZZ”。好的,有什么区别,我怎么能确定我说的是正确的CVE ID吗?不是CVE id的知道我们在说什么吗?没有引用,解释问题,基本上这些条目失败CVE的目的甚至是毫无意义的。 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"  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: , "Stephen V." mailto: sboyle@mitre.org> > >日期:星期三,4月1日2015年39点>:cve-editorial-board-list > < cve-editorial-board-list@lists.mitre.org <mailto: cve-editorial-board-list@lists.mitre.org> > > Cc:“大妈,斯蒂芬·v .”mailto: sboyle@mitre.org> >主题:>非公开的信息来源> >最近,两个命名为CVE漏洞信息来源,Secunia > X-Force,实现了登录需求,限制登录>允许访问。我们认识到,这些限制是趋势的一部分>一些来源正试图平衡欲望为>公众提供有用的漏洞信息,通常>非常昂贵和资源密集型的牧师这样的信息。> >作为一直是我们记录实践,CVE >只能参考信息公开和免费供任何人使用。任何源引用的CVE >是免费实施任何形式的访问控制,如登录,只要>控制(1)并不限制人们或组织可以使用>来源,和(2)不强加任何过多的不便给用户。>如,如果任何请求者可以创造和获得登录否则>无限制的访问,如通过提供一个电子邮件地址,仍然CVE >认为源是“公共”。>>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