CVRF Adoption -- success and challenges

["Omar Santos (osantos)" <osantos@cisco.com>]

Hi folks,
 
As Eric Johnson suggested, I am starting a discussion here about the background of CVRF, how it has been adopted, and why it has not been adopted by everyone. This will help to provide some background to new TC members and for us to think about the successes and challenges of the current standards and how it can be improved.
 
CVRF Background:
------------------------
CVRF was originally created by the Industry Consortium for Advancement of Security on the Internet (ICASI):
http://www.icasi.org/the-common-vulnerability-reporting-framework-cvrf-v1-1/ 
 
Since ICASI is not a standards body, it was decided to move it to where it belongs and the best home for the standard is OASIS.
 
Adoption (Success and Challenges):
------------------------------------------------
Prior to creation of the CSAF TC, the CVRF standard has been adopted by several technology vendors (mostly ICASI member companies, RedHat, etc.) and MITRE. And a number of organizations are consuming information produced in the CVRF format. For example, in the case of Cisco, several major customers are using them every time that we disclose security vulnerabilities. Partners (like vulnerability scanner vendors) are also using it to consume our vulnerability information.
 
On the other hand, there is a significant opportunity to build upon the existing CVRF standard, and enable a more universal adoption of this process that saves customers time and increases the security of their networks in a more real-time manner. Our TC can offer immediate value and quickly support future development to improve the interoperability and utility of the framework in support of providing structured machine-readable security advisories.
 
The following are a few examples of current challenges that have hinder the ability for further adoption:
-       Not extensible even if XML stands for EXtensible Markup Language? ;-) The current specification is XML based and can be improved by making it independent of XML, JSON, etc. Similarly to what we have done with STIX and TAXII in the CTI TC.
-       Lack of tools: there are not a lot of tools that have been maintained to create or consume CVRF content.
-       Stale documentation: we can do a better job making the CVRF (now CSAF) documentation easier for both consumers and content creators.
-       Lack of support for newer standards like SWID and others – and extensions to support similar standards like STIX.
 
We have already captured these in our JIRA issues at:
https://issues.oasis-open.org/browse/CSAF-30?jql=project%20%3D%20CSAF 
 
I would love for other TC members to also provide their perspective, as Eric suggested in today’s call.
 


Regards,

Omar Santos
PSIRT, Security Research and Operations
Cisco Systems, Inc.
Email: os@cisco.com
Phone: +1 919 392 8635
PGP Key: 0x3AF27EDC