Skip to main content
typo
Source Link
Marc Ruef
  • 1.1k
  • 5
  • 15

I am the lead architect of a very popular vulnerability database and we face similar problems. At the moment we have nearly 90'000 vulnerability entries with a CVSSv2 base and temp score. We are adding CVSSv3 scores and trying to convert most of the old data. I am going to discuss this transformation only to illustrate the basic principle of such.

The most important aspect is: Do not try to convert the scores themselves - Transform the vector into the new format and re-calculate their new scores instead.

If you take a look at the user guide of CVSSv2 and the specification of CVSv3CVSSv3 (generic link might change in the future) you can see that some of the base vectors might be transformable:

  • AV (P is new)
    • N => N
    • A => A
    • L => (L|P) (usually L)
  • Au => PR (needs manual optimization)
    • N => N
    • S => (L|H) (usually L)
    • M => (H|L) (sometimes H)
  • CI / II / AI (see comments below)
    • C => H
    • P => L
    • N => N
  • E
    • H => H
    • F => F
    • POC => POC
    • U => U
    • ND => X
  • RL
    • OF => O
    • TF => T
    • W => W
    • U => U
    • ND => X
  • RC (some deviation)
    • C => C
    • UR => R
    • UC => U
    • ND => X

But there is some additional complexity regarding other vectors:

  • AC in v2 is now somehow split into AC and UI

  • Even though CI, II and AI stay the same, v3 has added S. In most cases a CI:C/II:C/AI:C might promise a S:C sooner or later which might be derived by default.

If you follow this definition you might be able to convert approx. 97% of all issues without touching them manually. The deviation in accuracy during such a transformation is usually very small.

I am the lead architect of a very popular vulnerability database and we face similar problems. At the moment we have nearly 90'000 vulnerability entries with a CVSSv2 base and temp score. We are adding CVSSv3 scores and trying to convert most of the old data. I am going to discuss this transformation only to illustrate the basic principle of such.

The most important aspect is: Do not try to convert the scores themselves - Transform the vector into the new format and re-calculate their new scores instead.

If you take a look at the user guide of CVSSv2 and the specification of CVSv3 (generic link might change in the future) you can see that some of the base vectors might be transformable:

  • AV (P is new)
    • N => N
    • A => A
    • L => (L|P) (usually L)
  • Au => PR (needs manual optimization)
    • N => N
    • S => (L|H) (usually L)
    • M => (H|L) (sometimes H)
  • CI / II / AI (see comments below)
    • C => H
    • P => L
    • N => N
  • E
    • H => H
    • F => F
    • POC => POC
    • U => U
    • ND => X
  • RL
    • OF => O
    • TF => T
    • W => W
    • U => U
    • ND => X
  • RC (some deviation)
    • C => C
    • UR => R
    • UC => U
    • ND => X

But there is some additional complexity regarding other vectors:

  • AC in v2 is now somehow split into AC and UI

  • Even though CI, II and AI stay the same, v3 has added S. In most cases a CI:C/II:C/AI:C might promise a S:C sooner or later which might be derived by default.

If you follow this definition you might be able to convert approx. 97% of all issues without touching them manually. The deviation in accuracy during such a transformation is usually very small.

I am the lead architect of a very popular vulnerability database and we face similar problems. At the moment we have nearly 90'000 vulnerability entries with a CVSSv2 base and temp score. We are adding CVSSv3 scores and trying to convert most of the old data. I am going to discuss this transformation only to illustrate the basic principle of such.

The most important aspect is: Do not try to convert the scores themselves - Transform the vector into the new format and re-calculate their new scores instead.

If you take a look at the user guide of CVSSv2 and the specification of CVSSv3 (generic link might change in the future) you can see that some of the base vectors might be transformable:

  • AV (P is new)
    • N => N
    • A => A
    • L => (L|P) (usually L)
  • Au => PR (needs manual optimization)
    • N => N
    • S => (L|H) (usually L)
    • M => (H|L) (sometimes H)
  • CI / II / AI (see comments below)
    • C => H
    • P => L
    • N => N
  • E
    • H => H
    • F => F
    • POC => POC
    • U => U
    • ND => X
  • RL
    • OF => O
    • TF => T
    • W => W
    • U => U
    • ND => X
  • RC (some deviation)
    • C => C
    • UR => R
    • UC => U
    • ND => X

But there is some additional complexity regarding other vectors:

  • AC in v2 is now somehow split into AC and UI

  • Even though CI, II and AI stay the same, v3 has added S. In most cases a CI:C/II:C/AI:C might promise a S:C sooner or later which might be derived by default.

If you follow this definition you might be able to convert approx. 97% of all issues without touching them manually. The deviation in accuracy during such a transformation is usually very small.

Source Link
Marc Ruef
  • 1.1k
  • 5
  • 15

I am the lead architect of a very popular vulnerability database and we face similar problems. At the moment we have nearly 90'000 vulnerability entries with a CVSSv2 base and temp score. We are adding CVSSv3 scores and trying to convert most of the old data. I am going to discuss this transformation only to illustrate the basic principle of such.

The most important aspect is: Do not try to convert the scores themselves - Transform the vector into the new format and re-calculate their new scores instead.

If you take a look at the user guide of CVSSv2 and the specification of CVSv3 (generic link might change in the future) you can see that some of the base vectors might be transformable:

  • AV (P is new)
    • N => N
    • A => A
    • L => (L|P) (usually L)
  • Au => PR (needs manual optimization)
    • N => N
    • S => (L|H) (usually L)
    • M => (H|L) (sometimes H)
  • CI / II / AI (see comments below)
    • C => H
    • P => L
    • N => N
  • E
    • H => H
    • F => F
    • POC => POC
    • U => U
    • ND => X
  • RL
    • OF => O
    • TF => T
    • W => W
    • U => U
    • ND => X
  • RC (some deviation)
    • C => C
    • UR => R
    • UC => U
    • ND => X

But there is some additional complexity regarding other vectors:

  • AC in v2 is now somehow split into AC and UI

  • Even though CI, II and AI stay the same, v3 has added S. In most cases a CI:C/II:C/AI:C might promise a S:C sooner or later which might be derived by default.

If you follow this definition you might be able to convert approx. 97% of all issues without touching them manually. The deviation in accuracy during such a transformation is usually very small.