3 ms·

"It really doesn’t make sense for cybersecurity to have its own special snowflake process for things. It does not make sense operationally, philosophically, or

"It really doesn’t make sense for cybersecurity to have its own special snowflake process for things. It does not make sense operationally, philosophically, or socially." In general, I believe it does - cybersecurity is unique in the sense that you're dealing with intelligent adversaries that are actively trying to break your code. It's not like SRE work or normal software engineering. But there's also a lot of snake oil in the industry and most "cybersecurity" professionals don't actually know how to find vulnerabilities. "Attackers accessing our systems without our consent is one type of failure, but not the only kind. Reliability failures are arguably both more frequent and more damaging when they occur". This will completely depend on your product, but I've seen this sentiment across industries. "Risk = probability * impact" doesn't work when you throw security into the mix. The author sounds like a very common type of software developer who takes security issues in their code like a personal attack.

surge 3y ago
I agree with this, finding vulnerabilities is really hard, and there's people coming out of college with no experience anywhere else in the field trying to get high paying jobs looking for vulns in technology they don't understand or have never worked with. One of the best vulns I've ever remediated was one discovered by an application developer in their own authentication that was prescribed by our platform. He knew it was a problem and knew it needed to be fixed, but knew he needed us to report it before a fire got lit under the appropriate people's butts to make it get fixed.
bb88 3y ago
> The author sounds like a very common type of software developer who takes security issues in their code like a personal attack. She herself is a cyber security expert, so congratulations on attacking the messenger I guess?
- pizzalife 3y ago
  Oh word? Because the only CVE I find when I google the author's name is this: https://www.fastly.com/blog/cve-2023-30534-insecure-deserialization-in-cacti-prior-to-1-2-25 https://www.fastly.com/blog/cve-2023-30534-insecure-deserial... An unexploitable PHP bug that five people decided to share the credit on.
  - NovemberWhiskey 3y ago
    I mean, of all the perverse metrics.
  - bb88 3y ago
    Bro, Way to prove her point!
NovemberWhiskey 3y ago
>"Risk = probability * impact" doesn't work when you throw security into the mix. In my experience, that's primarily because cybersecurity people know neither the probability nor the impact of the things which they are calling risks, which moreover means they don't know how to order them from a prioritization perspective.
- 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 ago
    Ah, 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".
lizard 3y ago
> cybersecurity is unique in the sense that you're dealing with intelligent adversaries I disagree with this on the grounds that normal software engineering is dealing with intelligent adversaries as well. They may not be "adversarial" in the sense they are maliciously trying to _break_ the code, but if it is successful in performing _some_ work they will attempt to use it to perform other work as well, whether it was intended to or not. But, what the author seems to be saying here is that a "vulnerability" is just a fancy word for a bug that is not inherently more significant than a crash or outage (where the vulnerability may not be available to exploit anyways). The suggest that cybersecurity teams may be more successful by integrating with the pipelines developers and SREs already have for dealing with issues (including critical ones) than interrupting their work and trying to assert how much more important cybersecurity is.

surge 3y ago

I agree with this, finding vulnerabilities is really hard, and there's people coming out of college with no experience anywhere else in the field trying to get high paying jobs looking for vulns in technology they don't understand or have never worked with. One of the best vulns I've ever remediated was one discovered by an application developer in their own authentication that was prescribed by our platform. He knew it was a problem and knew it needed to be fixed, but knew he needed us to report it before a fire got lit under the appropriate people's butts to make it get fixed.

bb88 3y ago

> The author sounds like a very common type of software developer who takes security issues in their code like a personal attack. She herself is a cyber security expert, so congratulations on attacking the messenger I guess?

pizzalife 3y ago
Oh word? Because the only CVE I find when I google the author's name is this: https://www.fastly.com/blog/cve-2023-30534-insecure-deserialization-in-cacti-prior-to-1-2-25 https://www.fastly.com/blog/cve-2023-30534-insecure-deserial... An unexploitable PHP bug that five people decided to share the credit on.
- NovemberWhiskey 3y ago
  I mean, of all the perverse metrics.
- bb88 3y ago
  Bro, Way to prove her point!

NovemberWhiskey 3y ago

>"Risk = probability * impact" doesn't work when you throw security into the mix. In my experience, that's primarily because cybersecurity people know neither the probability nor the impact of the things which they are calling risks, which moreover means they don't know how to order them from a prioritization perspective.

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 ago
  Ah, 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".

lizard 3y ago

> cybersecurity is unique in the sense that you're dealing with intelligent adversaries I disagree with this on the grounds that normal software engineering is dealing with intelligent adversaries as well. They may not be "adversarial" in the sense they are maliciously trying to _break_ the code, but if it is successful in performing _some_ work they will attempt to use it to perform other work as well, whether it was intended to or not. But, what the author seems to be saying here is that a "vulnerability" is just a fancy word for a bug that is not inherently more significant than a crash or outage (where the vulnerability may not be available to exploit anyways). The suggest that cybersecurity teams may be more successful by integrating with the pipelines developers and SREs already have for dealing with issues (including critical ones) than interrupting their work and trying to assert how much more important cybersecurity is.