5 ms·

"The social issue continues in that people want some quick and easy to understand number, because they and their company also cannot process in a short time if

"The social issue continues in that people want some quick and easy to understand number, because they and their company also cannot process in a short time if these security vulns are substantial or not. " Uh, none of this explains why they re-score the vulnerabilities themselves, ignoring the vendor scores and deciding they know best, when they seem to know ... nothing. Which if you read through the links, you'll see is one of the main complaints, and something they document here: https://nvd.nist.gov/general/FAQ-Sections/CVE-FAQs#faqLink9 https://nvd.nist.gov/general/FAQ-Sections/CVE-FAQs#faqLink9 Their take is basically "we get to do this and if it's wrong it's your problem to get us to correct us". That doesn't make any sense. As my child's kindergarten teacher once asked a student: "Do you think if everyone decided to do that, it would turn out okay?" NVD and CVE teams will simply never have the expertise or time or information necessary to actually re-score these things correctly. You'll also note that despite claiming they score things based on publicly available information, and that othres must do the same, they cite absolutely no sources to Daniel to defend their scoring. They light themselves on fire, generate smoke and noise that others have to deal with, and then complain that it's the job of others to put it out.

eugenekolo 3y ago
The gaming of the system is the reason they rescores themselves and do not take a vendors statement as fact. There's a long history of vendors underreporting and underscoring their security issues.
- DannyBee 3y ago
  So? That's a different problem to deal with a different way. People keep lying to me, so i'm going to ignore what they tell me and make it up myself doesn't seem like it's going to generate great results. Put another way - "NVD making stuff up that is not accurate" is not a solution for "other people making stuff up that is not accurate". If you want responsibility, you have to incentivize it somehow, whether carrot or stick. This doesn't achieve that. They can tell their customers whatever they want, and then blame any difference on NVD being mean.
  - _a_a_a_ 3y ago
    >> vendors underreporting and underscoring their security issues > So? So he comprehensively refuted your point by explaining why
    - tptacek 3y ago
      No, he called out the obvious reason why NVD would decide it needs to operate this way, without acknowledging that the process they've come up with doesn't work, and is sort of an industry embarassment.
- usefulcat 3y ago
  The root of the problem is that if NVD lacks the resources to adequately assess CVEs, then they can't do better (well-intentioned or not!) than what the vendor reports, and them trying to do so only adds more noise. Sure the vendors have motive to underestimate, but they're also far better equipped to accurately assess severity. Better to focus on them and hold them accountable.
  - Majromax 3y ago
    I think the implied premise is that vendors are likely to score with a low bias, downplaying security vulnerabilities. If NVD completely re-scored submitted CVEs from scratch, then they'd replace a biased dataset with a noisier but unbiased dataset. On the other hand, if NVD accepts high severities and only re-scores low severity CVEs, then the collected database might exchange a low-severity bias for a high-severity bias.
    - usefulcat 3y ago
      > I think the implied premise is that vendors are likely to score with a low bias, downplaying security vulnerabilities. Indeed. It occurs to me that there's a possible feedback loop here. To the exent that NVD increases the severity of all (or even some) CVEs, they are effectively increasing the incentive for vendors to report lower severities, since the vendors may rightly assume that NVD will inflate the severity anyway.
- kelnos 3y ago
  If vendors were responsible -- and known to be responsible -- for scoring their own security issues, then everyone would at least know that, and understand that the vendor's assessment could be biased. Instead, many people seem to believe they can blindly trust NVD, when their severity assessment is arbitrary and based on wild guessing. And individuals at NVD probably have their own biases as well!
worthless-trash 3y ago
Disclaimer: I had worked for Red Hat prodsec for 6 years doing the kernel work. It is common that I regularly resubmit rescores requests to CVSSv3 to NVD, they seem to be pretty good about it when it is clearly explained. NVD will sometimes consider flaws scoring it the 'general' use case not in the specific use case which can make scoring libraries environment and usage specific.
- lars_francke 3y ago
  Can you - by any chance - talk about the tooling you used in that work (as in: the tech behind https://access.redhat.com/security/cve/cve-2023-34416 https://access.redhat.com/security/cve/cve-2023-34416 ). I assume it's all custom but we're looking for something just like it: https://news.ycombinator.com/item?id=36311682 https://news.ycombinator.com/item?id=36311682 If you're willing to you can find my contact details in my profile. Thanks!
- DannyBee 3y ago
  I am sure there are somewhat reasonable people on the other side. But it doesn't make it a sane process :) Making your own stuff up is not a solution for other people making stuff up or underselling things.
  - worthless-trash 3y ago
    I have to agree, publishing your own scoring is not ideal however it is sometimes specific to the use case. This is one of the reasons why people are uncomfortable with CVSS, some scorers consider the general case, some scorers consider the actual used case.

eugenekolo 3y ago

The gaming of the system is the reason they rescores themselves and do not take a vendors statement as fact. There's a long history of vendors underreporting and underscoring their security issues.

DannyBee 3y ago
So? That's a different problem to deal with a different way. People keep lying to me, so i'm going to ignore what they tell me and make it up myself doesn't seem like it's going to generate great results. Put another way - "NVD making stuff up that is not accurate" is not a solution for "other people making stuff up that is not accurate". If you want responsibility, you have to incentivize it somehow, whether carrot or stick. This doesn't achieve that. They can tell their customers whatever they want, and then blame any difference on NVD being mean.
- _a_a_a_ 3y ago
  >> vendors underreporting and underscoring their security issues > So? So he comprehensively refuted your point by explaining why
  - tptacek 3y ago
    No, he called out the obvious reason why NVD would decide it needs to operate this way, without acknowledging that the process they've come up with doesn't work, and is sort of an industry embarassment.
usefulcat 3y ago
The root of the problem is that if NVD lacks the resources to adequately assess CVEs, then they can't do better (well-intentioned or not!) than what the vendor reports, and them trying to do so only adds more noise. Sure the vendors have motive to underestimate, but they're also far better equipped to accurately assess severity. Better to focus on them and hold them accountable.
- Majromax 3y ago
  I think the implied premise is that vendors are likely to score with a low bias, downplaying security vulnerabilities. If NVD completely re-scored submitted CVEs from scratch, then they'd replace a biased dataset with a noisier but unbiased dataset. On the other hand, if NVD accepts high severities and only re-scores low severity CVEs, then the collected database might exchange a low-severity bias for a high-severity bias.
  - usefulcat 3y ago
    > I think the implied premise is that vendors are likely to score with a low bias, downplaying security vulnerabilities. Indeed. It occurs to me that there's a possible feedback loop here. To the exent that NVD increases the severity of all (or even some) CVEs, they are effectively increasing the incentive for vendors to report lower severities, since the vendors may rightly assume that NVD will inflate the severity anyway.
kelnos 3y ago
If vendors were responsible -- and known to be responsible -- for scoring their own security issues, then everyone would at least know that, and understand that the vendor's assessment could be biased. Instead, many people seem to believe they can blindly trust NVD, when their severity assessment is arbitrary and based on wild guessing. And individuals at NVD probably have their own biases as well!

worthless-trash 3y ago

Disclaimer: I had worked for Red Hat prodsec for 6 years doing the kernel work. It is common that I regularly resubmit rescores requests to CVSSv3 to NVD, they seem to be pretty good about it when it is clearly explained. NVD will sometimes consider flaws scoring it the 'general' use case not in the specific use case which can make scoring libraries environment and usage specific.

lars_francke 3y ago
Can you - by any chance - talk about the tooling you used in that work (as in: the tech behind https://access.redhat.com/security/cve/cve-2023-34416 https://access.redhat.com/security/cve/cve-2023-34416 ). I assume it's all custom but we're looking for something just like it: https://news.ycombinator.com/item?id=36311682 https://news.ycombinator.com/item?id=36311682 If you're willing to you can find my contact details in my profile. Thanks!
DannyBee 3y ago
I am sure there are somewhat reasonable people on the other side. But it doesn't make it a sane process :) Making your own stuff up is not a solution for other people making stuff up or underselling things.
- worthless-trash 3y ago
  I have to agree, publishing your own scoring is not ideal however it is sometimes specific to the use case. This is one of the reasons why people are uncomfortable with CVSS, some scorers consider the general case, some scorers consider the actual used case.