Re: CNA Rules Announcement

[Kurt Seifried <kseifried@redhat.com>]

On Tue, Oct 11, 2016 at 10:30 AM, Chandan Nandakumaraiah <cbn@juniper.net> wrote:

On 10/11/16 6:46 AM, Booth, Harold (Fed) wrote:
> [HB] I assume you are referring to the submission of CVRF into OASIS, and the upcoming revision of it.

Yes.

> The CVRF revision going into OASIS is specifically focused on creating an advisory format and not a vulnerability format. Personally, I wish it were otherwise, but that was the consensus that was developed during the development of the proposal for the TC. There is still going to be a need for a vulnerability specific format of some sort for exchanging vulnerability information and hopefully the same vocabulary can be used where it is useful to do so.

The phrase 'vulnerability report' as used commonly or in the relevant
ISO standards refers to what is used by finders to describe
vulnerabilities and send it to vendors or users.

The name CVRF implied a limited scope than intended. It was corrected at
the TC submission meeting. 'Advisory' has a more compassing scope: it
can be a vulnerability report, notification about vulnerabilities with
or without fixes, about security relevant but non-vulnerability fixes.
There is nothing in the OASIS proposal that would prevent a researcher
from using CVRF to describe a vulnerability.

As a vendor or a vulnerability finder, the key information I may share
in the proposed CVE Information Format or in CVRF (or the new revision)
are essentially the same. Hence this request not to create a duplicate
format to encode the same content.

> If CVE were to use CVRF then it would be necessary to develop a CVE specific profile that everyone would need to adopt. Also, given the change in tastes and current practice, JSON is or has become the preferred data exchange syntax for many (NVD receives requests for us to implement JSON fairly often) and I think that is something that may need consideration as well, but I would agree that using a common dictionary/taxonomy/ontology to bind multiple formats is a must.

I completely agree that CVRF badly needs a revision - a simplification
rather. The key value in CVRF is providing a dictionary, structure or
mindmap. One should be able to express this in other structured formats
like JSON without sacrificing machine readability. I would personally
prefer a hand editable format similar to the HTTP protocol like syntax
suggested in Appendix B - which should make it easy to embed in email,
web pages, commit messages, change logs etc., removing a huge barrier to
entry for small or open source vendors.

What do you think of 

https://github.com/distributedweaknessfiling/DWF-Database-Artifacts/blob/master/JSON-file-format.md

Major points:

The "protocol" is versioned along with actual specific sections. Within a major release (e.g. 1.0, 1.1, 1.2, 1.3, etc.) it is guaranteed backwards compatible, for example I just updated the protocol to 1.2 because I added a SWID field to the affected area. This is because at some point we'll have thousands/tens of thousands of CVEs with version 1.x data, and I the 2.x version of the data may not be backwards compatible. And nobody wants to update that old data. 

The protocol is JSON based and can contain typical JSON types, and text, and point to other files in certain areas (e.g. the artifacts). Long term I want to find a better way to attach/embed data (such as the SWID in AFFECTS thing). 

The data has 4 main sections:

1) DWF: this is strongly controlled data, well defined, structured

2) VENDOR: this is essentially a copy of the DWF section, but vendors can submit whatever they want essentially

3) COMMUNITY: this area will have guidelines and may end up with rules, not sure yet

4)EXPERIMENTAL: exactly what you think it is, an experimental section. 

I am open to feedback/improvements as well, I'm guessing the 2.x version will look quite different (if it doesn't, then we've failed). 

Thanks,
-Chandan

--
Security Incident Response Team
Juniper Networks

--

--
Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Red Hat Product Security contact: secalert@redhat.com