|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: CVE: intellectual property/branding
Stuart Staniford-Chen asked: >I'm interested in issues that would get in the way of the IETF saying >in an RFC that the n'th field in an IDEF alert is a CVE number. >what intellectual property rights does Mitre plan to assert in the >content of the CVE? The CVE will be copywritten but will allow unlimited distribution, but the copyright statement will prevent its modification. This will allow anybody to download the entire CVE, and in fact the downloads page on the web site allows just that. But the copyright will be worded to prevent someone from making changes to the CVE itself, e.g. changing CVE-1999-0003 to be their favorite vulnerability, instead of rpc.ttdbserverd. I don't know the details of the GNU public license, but it will probably be something along those lines. Full public distribution is a requirement of an acceptable common enumeration. The fact that the entire CVE can be freely downloaded, where vulnerability databases are not, could make it appear that the CVE is in "competition" with those other resources, or a replacement for them. However, as long as we make certain that there is minimal overlap between the CVE and any vulnerability database, then the CVE could not effectively "compete" with vulnerability databases; nor is it designed to. The CVE has to remain neutral in that regard, especially since it's designed to link between vulnerability databases, not to replace them. I believe that Editorial Board members understand this, but every design decision we make with respect to the CVE has to consider these implications, especially in CMEX. And the CVE often appears to be a vulnerability database to someone who's not familiar with it. The web site's FAQ and front page make this distinction clear, but it may not register with the average security analyst. I would prefer that we also provide CMEX (or a portion) due to its benefit (especially references), but that is a debate I've scheduled for sometime in August. There were some initial concerns at the SANS meeting that may not have been fully addressed yet. >More nebulously, there's the issue of branding. At the moment, it >looks to me that Mitre is definitely positioning this as "The Mitre >CVE" with the Mitre brand strongly linked to it. Since the CVE's inception, we have had a number of internal shifts in how we refer to the CVE. In the paper that Dave Mann and I presented at the CERIAS workshop, we discussed the possibility of multiple CVE's, and we would often talk about "a CVE" in a generic sense. When we started actually creating a CVE, we began referring to it as "the MITRE CVE" to distinguish MITRE's work from other possible CVE's. However, we believe that "the CVE" and "the MITRE CVE" have now become interchangeable and synonymous. So we're moving to "the CVE" both because there's only one CVE, and it re-emphasizes the fact that the CVE is the result of a community effort, not just MITRE's. Note that this most recent change in terminology was decided by the president of the company. >A possible route of evolution for the CVE would be for it to be >published periodically as an RFC. Steve and other Mitre folks are >still the authors, but it becomes a standards track document. There are a number of long-term possibilities, this being one of them. MITRE will choose the long-term strategy that best serves the public interest. I am trying to arrange for senior management to talk to the attendees at the CVE Review meeting in August. There have been a number of high-level questions that require answers from my management. Certainly I can't answer for the company in some of these areas, but the CVE does have support across the board, including MITRE's president. They will be able to address your larger concerns. - Steve
|
||||