OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

csaf message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [csaf] Proposal for CVSS future embrace


Concur with Vincent.

I believe CVSS v3 was published at last year's FIRST Conference. The intent from ICASI was to have this change on CVSS v3 take place and then move towards a new, forward thinking spec.

Pete



Regards,

Peter Allor
Senior Security Strategist, Project Manager - Disclosures



Mobile: +1-404-643-9638 | Fax: 845-491-4204
E-mail:
pallor@us.ibm.com
2160 Kensington Gates Drive NW
Kennesaw, GA 30152
United States



Inactive hide details for "Vincent Danen" ---05/15/2017 12:54:54 PM---On 04/26/2017, at 10:53 AM, Feng Cao wrote: > Hi Stefan,"Vincent Danen" ---05/15/2017 12:54:54 PM---On 04/26/2017, at 10:53 AM, Feng Cao wrote: > Hi Stefan,

From: "Vincent Danen" <vdanen@redhat.com>
To: "Feng Cao" <feng.cao@oracle.com>
Cc: csaf@lists.oasis-open.org, "Stefan Hagen" <stefan@hagen.link>
Date: 05/15/2017 12:54 PM
Subject: Re: [csaf] Proposal for CVSS future embrace
Sent by: <csaf@lists.oasis-open.org>





On 04/26/2017, at 10:53 AM, Feng Cao wrote:

> Hi Stefan,
>
> I went through the same idea of making it generic, but found out there
> were some obstacles which need to be removed by CVSS working group.
> That
> is the reason the current 1.2 proposal makes a small change instead of
> making it generic.
>
> Here are the obstacles. First, we cannot control what will be changed
> in
> the future CVSS versions, for example, the BaseScore range might be
> changed, and TemporalScore range might be changed too. In addition, we
> cannot rely on v3 schema all the times. The safe way so far is to make
> sure the version of CVSS can be consistent with the exact schema for
> that version referred inside CVRF.
>
> I did talk to my colleague in CVSS working group before, asking if
> their
> WG can always commit to [0, 10] and generate a generic data schema
> which
> can be independent of the versions. But he cannot make such a promise
> for such a ongoing effort in CVSS. So these obstacles cannot be
> removed
> for CVRF.
>
> So I think this idea can be put into CVRF 2.0. We need to keep CVRF
> 1.2
> simple and get 1.2 out ASAP

Apologies for the slow response, but I agree with Feng here.  I don't
think CVRF 1.2 is meant to be a future-looking spec, but a bridge to
make CVSSv3 (which has been out for many months now) viable to use with
CVRF and then make CSAF 2.0 the more future-looking spec.

I think keeping the changes in CVRF 1.2 as simple as possible so that we
(Red Hat, at least, is _only_ using CVSSv3 now so we are very invested
in seeing 1.2 with this support come out ASAP) can use it is to
everyone's benefit.  CSAF 2.0 should be where all the future-proofing
happens.

> On 4/25/2017 11:25 PM, Mr. Stefan Hagen wrote:
>> Dear members,
>>
>> to facilitate the business of our TC, I did many simple
>> transformations on the contributed content from v1.1 and the XSD
>> kindly provided by Feng Cao which seeded the v1.2 drafts until now.
>>
>> This night I did a first real modelling that would IMO better
>> represent the transitive task of embedding and relating CVSS
>> information of various versions.
>>
>> I hereby suggest to replace in vuln.xsd the hard wired V2/V3 mimic
>> with the following:
>>
>> A) Type for the vector (cvssVector):
>>
>> Only one type (which constrains the length to the maximum needed for
>> v2 and v3) and hopefully the future versions.
>>
>>         String representing the components needed to compute the
>>         various scores for CVSS versions 2 and 3. Note, that v3
>> scores can be longer than v2 scores
>>         (up to 138 characters). It is assumed, that future versions
>> of CVSS maintain the structure
>>         of the information break down and the required vector length.
>>
>>
>> B) Only a ScoreSet *but* with a required Version attribute
>> (xs:positiveInteger)
>>
>>       This will hold the CVSS version that the content  conforms to.
>>       Versions 2 and 3 fit the structure. It is assumed, that future
>> versions 4, 5, ... will also fit.
>>
>> C) The Container content of every [0, nifty] ScoreSet to be a
>> sequence:
>>
>>      BaseScore (cvssv3:zeroToTenDecimalType) [1, 1]
>>      TemporalScore (cvssv3:zeroToTenDecimalType) [0, 1]
>>      EnvironmentalScore (cvssv3:zeroToTenDecimalType) [0, 1]
>>      Vector (vuln:cvssVector) [0, 1]
>>      vuln:ProductID [0, infty]
>>
>>     I suggest we use the cvssv3:zeroToTenDecimalType or to be more
>> concise declare
>>     our own finite field for these 0.0, 0.1, ... 10.0 allowed values.
>>
>> D) Change the path value of the selector in the uniqueness constraint
>> UniqueScoreSetProductID into:
>>
>>     .//vuln:CVSSScoreSets/vuln:ScoreSet/vuln:ProductID
>>
>>
>> All in all this embraces the future in a reasonable way, and should
>> allow for easy migration of older documents.
>>
>> Please note, that currently the per CVSSv3 required fixed prefix for
>> vectors is not always
>> used "in the wild" (and understandably so, as our cvrf v1.1 length
>> might forbid legitimate values in CVSS v3.
>> So a Version attribute on a single ScoreSet element instance might be
>> an enhancement for existing documents
>> when being transformed (see the Oracle example, where the CVSS3.0
>> prefix would now be signalled
>> via the Version attribute value "3".
>>
>> Any feedback greatly appreciated esp. practical problems not known to
>> me in my tower of thought ;-)
>>
>>
>> Details:
>>
>> A)
>>
>>   <xs:simpleType name="cvssVector">
>>     <xs:annotation>
>>       <xs:documentation xml:lang="en">String representing the
>> components needed to compute the
>>         various scores for CVSS versions 2 and 3. Note, that v3
>> scores can be longer than v2 scores
>>         (up to 138 characters). It is assumed, that future versions
>> of CVSS maintain the structure
>>         of the information break down and the required vector
>> length.</xs:documentation>
>>     </xs:annotation>
>>     <xs:restriction base="xs:token">
>>       <xs:maxLength value="140"/>
>>     </xs:restriction>
>>   </xs:simpleType>
>>
>> B) and C)
>>
>>               <xs:element name="ScoreSet" minOccurs="0"
>> maxOccurs="unbounded">
>>                 <xs:annotation>
>>                   <xs:documentation xml:lang="en">CVSS scores for a
>> given product ID. If the
>>                     ProductID attribute is omitted, the score applies
>> to all vulnerable
>>                     products.</xs:documentation>
>>                 </xs:annotation>
>>                 <xs:complexType>
>>                   <xs:sequence>
>>                     <xs:element name="BaseScore"
>> type="cvssv3:zeroToTenDecimalType" minOccurs="1"
>>                       maxOccurs="1">
>>                       <xs:annotation>
>>                         <xs:documentation xml:lang="en">The CVSS Base
>> Score is the numeric value of
>>                           the computed CVSS Base Score which should
>> be a float from 0 ?
>>                           10.0.</xs:documentation>
>>                       </xs:annotation>
>>                     </xs:element>
>>                     <xs:element name="TemporalScore"
>> type="cvssv3:zeroToTenDecimalType"
>>                       minOccurs="0" maxOccurs="1">
>>                       <xs:annotation>
>>                         <xs:documentation xml:lang="en">The CVSS Base
>> Score is the numeric value of
>>                           the computed CVSS Temporal Score which
>> should be a float from 0 ?
>>                           10.0.</xs:documentation>
>>                       </xs:annotation>
>>                     </xs:element>
>>                     <xs:element name="EnvironmentalScore"
>> type="cvssv3:zeroToTenDecimalType"
>>                       minOccurs="0" maxOccurs="1">
>>                       <xs:annotation>
>>                         <xs:documentation xml:lang="en">The CVSS Base
>> Score is the numeric value of
>>                           the computed CVSS Environmental Score which
>> should be a float from 0 ?
>>                           10.0.</xs:documentation>
>>                       </xs:annotation>
>>                     </xs:element>
>>                     <xs:element name="Vector" type="vuln:cvssVector"
>> minOccurs="0" maxOccurs="1">
>>                       <xs:annotation>
>>                         <xs:documentation xml:lang="en">The CVSS
>> Vector string is the official
>>                           notation that contains all of the values
>> used to compute the Base,
>>                           Temporal, and Environmental
>> scores.</xs:documentation>
>>                       </xs:annotation>
>>                     </xs:element>
>>                     <xs:element ref="vuln:ProductID" minOccurs="0"
>> maxOccurs="unbounded"/>
>>                   </xs:sequence>
>>                   <xs:attribute name="Version"
>> type="xs:positiveInteger" use="required">
>>                     <xs:annotation>
>>                       <xs:documentation xml:lang="en">The CVSS
>> version that the content
>>                         conforms to. Versions 2 and 3 fit the
>> structure. It is assumed, that
>>                         future versions 4, 5, ... will also
>> fit.</xs:documentation>
>>                     </xs:annotation>
>>                   </xs:attribute>
>>                 </xs:complexType>
>>
>> D)
>>
>>     <xs:unique name="UniqueScoreSetProductID">
>>       <xs:annotation>
>>         <xs:documentation xml:lang="en">This is to ensure that each
>> CVSS score set mentions a given
>>           ProductID only one.</xs:documentation>
>>       </xs:annotation>
>>       <xs:selector
>> xpath=".//vuln:CVSSScoreSets/vuln:ScoreSet/vuln:ProductID"/>
>>       <xs:field xpath="."/>
>>     </xs:unique>
>>
>>
>>
>>
>> All the best,
>> Stefan.
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
>
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php


--
Vincent Danen / Red Hat Product Security

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 






[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]