3 ms·

...Wow, gauging a "blast radius" based primarily on CVSS score sounds incredibly hamfisted and naive.

TheNewsIsHere 3y ago
I agree. I could see some value to a kind of measurement like that, but I agree that that particular method seems heavy handed. This is partly what SBOMs are meant to solve for. I’m also not sure calling Linux “aging infrastructure” that is obscured by activity in the Kernel is intellectually honest. Perhaps it’s better framed as a naive take. If the point is about shopping the rest of the OS (“all the dependencies” if you will) being a supply chain issue, I think the point would be better.
PeterisP 3y ago
It's probably close to the best thing that can be done with the available data, even if the available data is bad - the main flaw of such a metric is that while you could argue that the total impact is proportional to the number of machines affected, you can't reasonably argue that the impact is proportional to the CVSS score, the relationship is very non-linear. A vulnerability with CVSS 2.5 wouldn't have a quarter of impact of a CVSS 10 vulnerability, its impact would be insignificant.
- redserk 3y ago
  The problem is that it really depends on your stack/application. A score pretends to be an absolute frame of reference to work on, and this is hardly reliable to assess real risk and impact. A CVSS 10 on several internal services with all user input being filtered may be substantially less risky than a public facing component using a library with a CVSS 2.5 depending on your application and vulnerability. The only correct way is to assess risk is analyze how you utilize each component and determine if your application would run into the issue to begin with. This work cannot be hand-waved away with a simple number despite this practice being the hot fad in cybersecurity.
  - PeterisP 3y ago
    While individual circumstances matter a lot for impact to a single organization, for estimating the global "blast impact" of a vulnerability, we'd expect that all of that would somewhat average out between all the thousands or millions of different systems and organizations running that tool, and a library with 100 times more users can be expected (all things being equal) to have 100-ish times more situations where it's used in a publicly reachable way - but the difference in average expected impact of having a million systems with a 2.5 CVSS vulnerability (likely causing zero incidents) and a million systems with a 10.0 CVSS vulnerability (likely wormable RCE) isn't 4 times, not even close to that.

I agree. I could see some value to a kind of measurement like that, but I agree that that particular method seems heavy handed. This is partly what SBOMs are meant to solve for. I’m also not sure calling Linux “aging infrastructure” that is obscured by activity in the Kernel is intellectually honest. Perhaps it’s better framed as a naive take. If the point is about shopping the rest of the OS (“all the dependencies” if you will) being a supply chain issue, I think the point would be better.

PeterisP 3y ago

It's probably close to the best thing that can be done with the available data, even if the available data is bad - the main flaw of such a metric is that while you could argue that the total impact is proportional to the number of machines affected, you can't reasonably argue that the impact is proportional to the CVSS score, the relationship is very non-linear. A vulnerability with CVSS 2.5 wouldn't have a quarter of impact of a CVSS 10 vulnerability, its impact would be insignificant.

redserk 3y ago
The problem is that it really depends on your stack/application. A score pretends to be an absolute frame of reference to work on, and this is hardly reliable to assess real risk and impact. A CVSS 10 on several internal services with all user input being filtered may be substantially less risky than a public facing component using a library with a CVSS 2.5 depending on your application and vulnerability. The only correct way is to assess risk is analyze how you utilize each component and determine if your application would run into the issue to begin with. This work cannot be hand-waved away with a simple number despite this practice being the hot fad in cybersecurity.
- PeterisP 3y ago
  While individual circumstances matter a lot for impact to a single organization, for estimating the global "blast impact" of a vulnerability, we'd expect that all of that would somewhat average out between all the thousands or millions of different systems and organizations running that tool, and a library with 100 times more users can be expected (all things being equal) to have 100-ish times more situations where it's used in a publicly reachable way - but the difference in average expected impact of having a million systems with a 2.5 CVSS vulnerability (likely causing zero incidents) and a million systems with a 10.0 CVSS vulnerability (likely wormable RCE) isn't 4 times, not even close to that.