[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: CNA Rules Announcement

>> 2.2.9. Publish required CVE information in a standard format and 
>> presentation, to be determined and managed by the CVE Project (CNAs, 
>> board?)

>Why is this 'TBD'? Doesn't CVRF fit the bill?
>If it doesn't meet CVE project's requirements, it is time to consider 
>those while revising CVRF instead of creating yet another CVRF.

[HB] I assume you are referring to the submission of CVRF into OASIS, 
and the upcoming revision of it. 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.

>> [CVEID]:
>> [PRODUCT]:
>> [VERSION]:
>> [PROBLEMTYPE]:
>> [REFERENCES]:
>> [DESCRIPTION]:

>It seems this is re-inventing a simplified version of CVRF.

>Why not use the same vocabulary as used in CVRF [See 1] and avoid 
>having to solve the same ambiguities already solved by CVRF?

>'VERSION' alone is ambiguous. It is ambiguous in the example given.

>Suggestion: Use any of: Fixed-Version, Known-Affected-Version, 
>Last-Affected-Version, First-Fixed-Version, see [1] for more.

>Instead of 'REFERENCES' use 'Reference' and allow repeats.

>Note that CVRF uses 'Title' or 'Note' instead of 'DESCRIPTION'.

[HB] Yes, CVRF uses 'Note' but they have an extra attribute called 
'type' with a value of the same name and semantic meaning. Since they 
were creating an advisory format and not a vulnerability format they 
used 'Description' for a different purpose at the document level 
instead of the vulnerability level. There are several examples of names 
that would have naturally been used at the vulnerability level but 
instead were included at the document level throughout the CVRF 
dictionary and alternate names/methods were employed to arrive at the 
same semantics.

>In addition to these, it may be useful to include the following 
>optional fields (or any other field from the CVRF dictionary) to make 
>the format future proof. If CVRF is lacking a particular field, that 
>should be brought up >during its revision.

[HB] I have concerns as to whether CVRF is the correct venue for a 
vulnerability format given the goals the OASIS TC has set for itself.

>InitialReleaseDate
>CurrentReleaseDate
>CVSSScore
>Acknowledgement
>Publisher
>CWE
>CPE

>While the given example works for a single vendor single product, 
>without unambiguous guidance on how to encode multiple products, 
>vendors or versions, it can become complicated (i.e we will be 
>reinventing the CVRF wheel)

[HB] I would agree that some sort of unambiguous structure/language is 
needed but I would argue that, although better than just VERSION, what 
is provided by CVRF is not expressive enough either.

[HB] Additionally, I would note that the NVD has implemented the 
ability to parse and ingest CVRF documents from the 4 vendors we have 
found that implement it (if Juniper does as well let me know), no two 
of the vendors have implemented it the same (especially around the 
product area) and we have written vendor/feed specific rules to assist 
in processing the files. 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.
Page Last Updated or Reviewed: October 12, 2016