RE: Publication of CVE in CVRF Format

["Mann, Dave" <damann@mitre.org>]

TK,

 

Somebody once wrote an interesting word on my white board that changed my thinking.  The word was:

 

                Ontogenesis.

 

How do come to know what we know?

 

I can’t speak for any of the other structuring efforts that have used the term “enumeration”, but have spent a good deal of time thinking about both CVE and CCE.  It strikes me that these 2 efforts are different both at the data and meta-data level.

 

CVE’s use descriptions but descriptions don’t seem to work in CCE.  They are among the most problematic fields in CCE.   Both CVE and CCE need to be documented in terms of specific system artifacts but they tend to be very different system artifacts and in both cases, the information at CVE or CCE definition time may be incomplete but incomplete in different ways.  CVE and CCE both have reference but they work better in CVE and are very different animals.  CCE needs to point to pdf documents and things like man pages while CVE references point to urls.

 

At the meta-data level things are different too.  Vulnerabilities are discovered and disclosed while configuration controls are “documented”.  The who, when and how of this documentation process is very different from the process of disclosing vulnerabilities. 

 

I’ve seen nothing that comes close to CVRF in the configuration space. Perhaps the CCE publication XML but that is not at all as well adopted or agreed upon.  In fact, there is good reason to believe that CCE’s value proposition has either shifted or entirely disappeared.

 

I would suggest allowing the vulnerability space to mature along its own while allowing the other sub-disciplines to do the same.

 

 

 

-Dave

==================================================================

David Mann | Principal Infosec Scientist | The MITRE Corporation

------------------------------------------------------------------

e-mail:damann@mitre.org | cell:781.424.6003

==================================================================

 

From: owner-cve-editorial-board-list@lists.mitre.org [mailto:owner-cve-editorial-board-list@lists.mitre.org] On Behalf Of Tim Keanini
Sent: Friday, November 02, 2012 11:40 AM
To: Christey, Steven M.; cve-editorial-board-list
Subject: RE: Publication of CVE in CVRF Format

 

 

While I applaud and support CVRF and machine readability in general, I would also like to complain a little about the narrowness of this effort; we lack opportunity to speak to the Commonness of scoring and machine readability across all the Enumerations.  The only reason I am taking a minute to complain here is because it is a board level topic even if we are just representing Vulnerabilities.

 

What bugs me is that we have all of these Common Enumerations we use as Identifiers but no common way to represent them in XML.  I can say the same about the Common Scoring Systems having similar problems.  If is not fatal that they are different but having common vocabularies that create cross Enumeration predicates would really benefit everyone.

 

The problem is that there is no one taking into account all the CxE and CxSS so everyone just develops without much consideration across the E’s or SS’s. 

 

Again, not fatal because as long as they are all XML, you could create an middle to upper Ontology that would stitch them together.    At some point we all get to the conversation of standard set of predicates that take us to the next level of modeling.  I’m getting tired of making these points but will continue to complain until we all get there.  Until then, good luck with modeling compensating controls, or anything that relates two or more different Enumerations. 

 

If we consider historical events a map to the future, then CVE is where it all begins (Scoring started here, and now Reporting Framework).  It may be that this higher level modeling must also begin here even if the effort is focused at a meta level.

 

Sorry to be Negative Nelly this Friday.  I really do like the CVRF effort and you can’t hear me but I am clapping.  Have a great weekend.

--tk

 

--

Tim "TK" Keanini, Chief Research Officer    …    nCircle Inc.   …   mbl (415) 328-2722  …

Blog: patterns.ncircle.com   Twitter: @tkeanini

 

From: owner-cve-editorial-board-list@LISTS.MITRE.ORG [mailto:owner-cve-editorial-board-list@LISTS.MITRE.ORG] On Behalf Of Christey, Steven M.
Sent: Thursday, November 01, 2012 6:53 PM
To: cve-editorial-board-list
Subject: Publication of CVE in CVRF Format

 

All,

 

The Common Vulnerability Reporting Framework (CVRF, www.icasi.org/cvrf) version 1.1 was released back in May 2012, with significant improvements compared to the previous version.  We have been requested to publish CVE in CVRF format, and we have finished 90% of the implementation to do this (mostly during “down time” in long meetings where heavy-thinking CVE content production was not feasible ;-)

 

Over the past 10 years or so, there have been several attempts to provide a common, machine-parseable advisory format, but none of the proposals were widely adopted.  However, CVRF is supported by some major vendors, including Red Hat, Cisco, Oracle, and Microsoft.  And this isn't just lip service or “plans” to adopt in the future – most or all of these vendors publish their advisories in CVRF format today.

 

For CVE content production, we scrape many web pages for advisory information, and these web changes can change, forcing us to make frequent code changes to our parsers.  Encouraging the use of CVRF will ultimately help CVE (and many other vulnerability information consumers) to reduce the effort needed to support the wide variety of advisory formats that are currently in use.  For example, at SOURCE Boston a couple years ago, I heard a person from a major Internet company complain about all the time that was lost trying to collate advisories from diverse sources.

 

In addition, various features of CVRF indirectly encourage an advisory structure that can simplify CVE analysis.  For example, many custom-built advisories do not clearly delineate multiple vulnerabilities, or they do not clearly specify which CVE goes with which vulnerability, which can contribute to errors or omissions due to poor formatting.  Thus, more widespread adoption of CVRF could further improve the actual quality of some advisories, benefiting the general public and not just CVE.

 

And while we don't know where the upcoming GVR discussions will head in the coming years, it seems likely that if truly global vulnerability information sharing takes place, there will be a greater need for a common format to facilitate sharing.

 

So, we believe that the time has come for CVE to support CVRF - to make it easier for CVE consumers to access CVE content instead of having to learn our custom format, to ultimately make our own analytical work easier and more efficient, and to further encourage others in the security community to pursue machine-readable vulnerability information sharing.

 

We still have some work to do, such as updating the web site and preparing an announcement, but the underlying technical implementation is nearly ready, and all of our CVE output validates properly (with enough memory, good ol’ XML ;-))  We plan to roll out the CVRF format and make a formal public announcement soon, maybe in late November.  We will still support the current formats and may consider additional formats in the future.

 

If anybody who speaks CVRF wants to help beta-test our CVE outputs, please let me know.

 

Thanks,

Steve