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] CVSS v2/v3 use in CVRF 1.2

On 13/04/17 16:32, Patrick Maroney wrote:
> Re: "Before voting can we have an opportunity to discuss? I am not sure
> everyone is aware of the consequences of the various options."
> I think Harold raises a good point.  It's important those voting on a
> formal ballot understand the ramifications of their decision.

I hope this is what is happening here currently between our monthly meetings ;-)

> I'm not familiar enough with all of the practical implementation
> details, but want to pose the following question:
> In the CTI TC community we've faced similar issues with backwards
> compatibility (and about to face a major challenge in the XML => JSON
> MTI transition).  MITRE was engaged to develop conversion/validation
> scripts.  This provided a "clean" method to convert legacy STIX
> documents to the current version.  If you still have "old" operational
> tooling (or legacy data files) you can add an automated process to
> upgrade your content.  It only works in one direction of course and you
> may have to manually deal with outliers/special cases.
> Would this be a viable approach here as well?

I do not think so because of the to my knowledge non-existent algorithmic transform of CVSS v2 to v3. I even read in this mail thread, that some prefer the env or temp scores from v2 !

Last time I tried, I had to reconsider some aspects (separate in v2) to evaluate the impact in v3.

In the CVSS v3 spec as a sample:
"""2.3. Attack Complexity

Access Complexity (from v2.0) conflated two issues: any software, hardware, or networking condition beyond the attacker's control that must exist or occur in order for the vulnerability to be successfully exploited (for example a software race condition, or application configuration), and the requirement for human interaction (for example, requiring a user execute a malicious executable). Therefore, Access Complexity has been separated into two metrics, Attack Complexity (which addresses the former condition), and User Interaction (which addresses the latter condition).
# end of citation

So I guess besides the already suggested formal "name level" remapping described in the appendix, these CVSS vx worlds will not transition into each other, but instead will be stored side by side - with the controversial issue of enforcing an CVSS v3 addition or not (when storing something in the new format).

All the best,

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