because you end up spending a non-trivial amount of time with "soc analysts" bugging you about a bluetooth vulnerability on an os installed on a virtual machine on a server that lacks bluetooth hardware, for example
This is an unfortunate truth of a lot of security people and processes. A blind checkbox-oriented "CVE reported so must fix" approach.
I just had one where we were asked to remove a management client for an internal server that had a DOS vulnerability reported (which could not be triggered by the management client). I pointed out that removing the client does not mitigate the DOS issue - and we would be effectively causing a denial of service on ourselves! No dice. Scan shows vulnerable version, must make number of reported vulns go down. Zero thought, huge effort.
It does huge damage to security and the business to take this kind of approach, but it's depressingly common.
That may explain some of it, but I've seen it all over, including in places I know that is not the case.
Mostly I think it boils down to a combination of a CYA mentality, risk averse managers and unskilled security personnel.
Making a decision that this Critical (potential) vulnerability does not need fixing is a decision that none of the above want to make and stand by, or have to explain.
Because in many cases the CVE vulnerability report is used as a proxy for existance of a vulnerability by many: from clickbait journalism, to automated tool vendors and device procurement. It is, after all, published by a reputable source.
Then, you get a report, say, that calling X with malicious data causes reboot. DoS! But software vendor looks at it and sees that in order to call X you need so much permissions, you can do reboot directly. What now?
Also, not every report submitted to be published as CVE goes immedeately public. Where does it go? If there is CVE about RCE in popular software, who knew about it before it went public?
It's about trust that the information is going to be up to date and reliable and available. This means we need trust in the organisation that manages this.
We've had no real updates to the existing CVEs for over a year now - lots of them just pending assessment. The communication about it has been misleading or non existent. Then the recent funding issue which threatened to close it down entirely, followed by maybe 11 more months of it? Who knows.
A huge number of infosec processes and tools depend on CVEs and the NVD as the main source of them.
So the trust is gone or rapidly going. We are all looking around in the infosec community and wondering what comes next.
Some. Others are on Matrix. The type of people you're thinking of are either interested in secure development (programmers with a security interest) or cryptography. Either they choose wherever the project's chat platform is or it's discord typically.
The modern infosec scene has shockingly little in common with the old school cypherpunk / hacker scene, besides appropriating the aesthetics and lingo.
Many of the people in it are even pro-information-censorship, pro-government, pro-intelligence-agencies, pro-big tech, etc. They have zero concerns about proprietary software, they trust Microsoft, they trust Google/Alphabet, they trust their government.
In my experience talking with these types, many of the same ones hysterical about MITRE's taxpayer-funded contract ending have seemingly never ever heard of OSVDB - the idea of a community-run vulnerability database is foreign to them. They seem to believe that it's simply not possible for a non-government-funded entity to perform this kind of work without commercialization.
Offensive Security - the company behind the OSCP, OSEP (formerly OSCE), and OSEE - have their official, primary support through Discord first, their own forums second.
Discord provides the feature set people are used to. Therefore, it gets used.
Today's programmers got into it through Minecraft modding or similar. IRC, mailing lists, and forums just don't cut it for them. By contrast, the retrocomputing scene -- full of aging Xers -- often conducts its activities through Web 1.0 style forums.
The post spends too much time speculating about how CVE is mismanaged without providing anything beyond their unmet expectations. Pointing to VulnCon attendance as an act of betrayal seems pretty reductive.
Didn’t make it through the rest, it was too hyperbolic and opinionated without substance.
The author spoke of uncertainty that CVE will be around, and also said that some parties involved didn't appear forthright on some occasions. What wasn't clear to me is the "What's your threat model?" here.
I'd guess the threat model to include things like "How likely is this org to disappear from the face of the Earth?" and "How susceptible is this org going to be to outside influences that have priorities higher than the honest/accurate/timely reporting of vulnerabilities?".
I read this twice trying to figure out why it matters if we trust NVD. It's a number assigned to vulnerability reports; that's it. Who cares?
because you end up spending a non-trivial amount of time with "soc analysts" bugging you about a bluetooth vulnerability on an os installed on a virtual machine on a server that lacks bluetooth hardware, for example
This is an unfortunate truth of a lot of security people and processes. A blind checkbox-oriented "CVE reported so must fix" approach.
I just had one where we were asked to remove a management client for an internal server that had a DOS vulnerability reported (which could not be triggered by the management client). I pointed out that removing the client does not mitigate the DOS issue - and we would be effectively causing a denial of service on ourselves! No dice. Scan shows vulnerable version, must make number of reported vulns go down. Zero thought, huge effort.
It does huge damage to security and the business to take this kind of approach, but it's depressingly common.
It's because legal liability is tied up in it and therefore insurance.
That may explain some of it, but I've seen it all over, including in places I know that is not the case.
Mostly I think it boils down to a combination of a CYA mentality, risk averse managers and unskilled security personnel.
Making a decision that this Critical (potential) vulnerability does not need fixing is a decision that none of the above want to make and stand by, or have to explain.
That's how it work in our company.
This is why CVE sucks, no context.
Because in many cases the CVE vulnerability report is used as a proxy for existance of a vulnerability by many: from clickbait journalism, to automated tool vendors and device procurement. It is, after all, published by a reputable source.
Then, you get a report, say, that calling X with malicious data causes reboot. DoS! But software vendor looks at it and sees that in order to call X you need so much permissions, you can do reboot directly. What now?
Also, not every report submitted to be published as CVE goes immedeately public. Where does it go? If there is CVE about RCE in popular software, who knew about it before it went public?
It's about trust that the information is going to be up to date and reliable and available. This means we need trust in the organisation that manages this.
We've had no real updates to the existing CVEs for over a year now - lots of them just pending assessment. The communication about it has been misleading or non existent. Then the recent funding issue which threatened to close it down entirely, followed by maybe 11 more months of it? Who knows.
A huge number of infosec processes and tools depend on CVEs and the NVD as the main source of them.
So the trust is gone or rapidly going. We are all looking around in the infosec community and wondering what comes next.
> If this is a topic you’re interested in, there’s a discord chocked full of people discussing vulnerability things, feel free to join.
Are open-source-y type infosec people choosing Discord?
Some. Others are on Matrix. The type of people you're thinking of are either interested in secure development (programmers with a security interest) or cryptography. Either they choose wherever the project's chat platform is or it's discord typically.
The modern infosec scene has shockingly little in common with the old school cypherpunk / hacker scene, besides appropriating the aesthetics and lingo.
Many of the people in it are even pro-information-censorship, pro-government, pro-intelligence-agencies, pro-big tech, etc. They have zero concerns about proprietary software, they trust Microsoft, they trust Google/Alphabet, they trust their government.
In my experience talking with these types, many of the same ones hysterical about MITRE's taxpayer-funded contract ending have seemingly never ever heard of OSVDB - the idea of a community-run vulnerability database is foreign to them. They seem to believe that it's simply not possible for a non-government-funded entity to perform this kind of work without commercialization.
Offensive Security - the company behind the OSCP, OSEP (formerly OSCE), and OSEE - have their official, primary support through Discord first, their own forums second.
Discord provides the feature set people are used to. Therefore, it gets used.
Today's programmers got into it through Minecraft modding or similar. IRC, mailing lists, and forums just don't cut it for them. By contrast, the retrocomputing scene -- full of aging Xers -- often conducts its activities through Web 1.0 style forums.
The post spends too much time speculating about how CVE is mismanaged without providing anything beyond their unmet expectations. Pointing to VulnCon attendance as an act of betrayal seems pretty reductive.
Didn’t make it through the rest, it was too hyperbolic and opinionated without substance.
I'm glad I ain't the only one who understands that transparency is a dependency of trust.
The author spoke of uncertainty that CVE will be around, and also said that some parties involved didn't appear forthright on some occasions. What wasn't clear to me is the "What's your threat model?" here.
I'd guess the threat model to include things like "How likely is this org to disappear from the face of the Earth?" and "How susceptible is this org going to be to outside influences that have priorities higher than the honest/accurate/timely reporting of vulnerabilities?".