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

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