4 ms·
As a cybersecurity person, probability is typically high since so many people release POCs and impact is almost always they steal all our IP and lock our comput
by genmud 3y ago
As a cybersecurity person, probability is typically high since so many people release POCs and impact is almost always they steal all our IP and lock our computers, grinding business to a halt. CVSS is kind of helpful for triaging stuff, but if you are even a moderately sized org, it's literally fire drills all the time or you bury your head in the sand.
Business people typically don't wanna hear that and then act all shocked pikachu face when it happens.
- NovemberWhiskey 3y agoAh, yes, this is the "start from the assumption that everything has failed" trick. "if attackers can run arbitrary code on our systems then they can exploit vulnerabilities!" or "if attackers can send arbitrary payloads to services which are turned off in the actual image and in any case not accessible without breaching a perimeter firewall and passing through a DMZ then they can exploit vulnerabilities!" OK, sure, what about "attackers kidnap the families of our AD admin team and force them to do whatever they want"? Also, "high" meaning "sometimes we just don't care". No, sorry, I do not care that (e.g.) CVE-2023-4911 has been categorized as "high", I am not in a rush to replace every single Fargate task that contains a vulnerable glibc because it's just not an interesting vulnerability in that context: let's assume you (a) bypass the payload validation on the (private!) API Gateway, (b) construct a payload that allows some kind of RCE in my JVM, (c) somehow escape from the JVM sandbox to run arbitrary native code, (d) successfully implement the attack, (e) get root in the underlying VM ... it's a Firecracker VM that doesn't have ANYTHING ELSE in it. But, no, it's a "high", I better start cutting change tickets for literally everything in the universe to conduct an incredible load of busy work in order to do a no-op. Really smart cybersecurity would be (I'm just making this up, I haven't really thought about it) "you know, if we're looking at services contained in a VM security boundary like Fargate, perhaps we don't care about Attack Vector = Local or Physical, or User Interaction = Required?" but what we actually get is "raw CVSS score tells you all you need to know and absolutely dictates urgency and triage priority".
- genmud 3y ago> Ah, yes, this is the "start from the assumption that everything has failed" trick. I am actually fairly data driven, and it's why things like SBOMs are exciting. Based on my experience, if something is exposed to the world and that thing has a vulnerability... within a period of reasonable time (say within 12 months), it will be exploited. > No, sorry, I do not care that (e.g.) CVE-2023-4911 has been categorized as "high" I wasn't actually referring to my "high" being the cvss scores. It was likelihood of exploitation(in my org), not the score. In your example, that would be a local exploit, so wouldn't be a high in my book unless you are shoveling user input to a CLI, which I would hope isn't happening. Personally unless you know there to be higher risks for certain things, if it ain't 9+ on cvss, it gets a ticket cut to deal with it like any other but at some convenient time in the future. > but what we actually get is "raw CVSS score tells you all you need to know and absolutely dictates urgency and triage priority" Your security org sucks and are doing it wrong. I'm genuinely sorry, and I'll say that not all of us are like that :(
- bawolff 3y agoThis is kind of a narrow view of security. Plenty of risks arent vulns in public software. Some are vulns in your own software. Some are just deviations from best practises or lack of system isolation. Even among public vulns with known PoC, the impact is going to depend on context. Plenty of times the impact is zero based on how software is used.
- genmud 3y agoIt was a view in response to the above post, not a generalized view I take on things. I’m actually a fan of embedding security resources into the eng teams and having those resources fix issues rather than toss shit over the wall. Knowing how software works is really hard without living inside the code base.