4 ms·

> EDR/AV is basically unnecessary, No, its not and never will be. Even if it were technically unnecessary (in some hypothetical future where privilege escalat

> EDR/AV is basically unnecessary, No, its not and never will be. Even if it were technically unnecessary (in some hypothetical future where privilege escalation became impossible?), legal, compliance, and insurance requirements would still be there.

1718627440 11mo ago
The problem is that EDR is basically a rootkit, by using it you enable a huge attack surface instead of being able to have stuff e.g. immutable. That tradeoff only makes sense, when you don't trust and control the OS itself. This is more of a problem with proprietary OSes like Windows. Otherwise you would rather integrate this into the OS itself.
- mapontosevenths 11mo ago
  > That tradeoff only makes sense, when you don't trust and control the OS itself. That's totally accurate, but you're missing the fact that we fundamentally don't (and can never) trust the OS or any other part of a general purpose computer. In general purpose computing you have a version of Descartes brain in a vat problem (or maybe Plato's allegory of the cave if you want to go even further back). https://iep.utm.edu/brain-in-a-vat-argument/ https://iep.utm.edu/brain-in-a-vat-argument/ To summarize: We can't trust the inputs even if the OS is trusted, and if the OS is trusted can't trust the compiler, and even if we trust the compiler we can't trust the firmware, but even if we trust the firmware we can't trust the chips it runs on, and even if we trust those chips we can't trust the supply chain, etc. "Trust" is fundamentally unsolvable for any Turing machine, because all trust does is move the issue further down the supply chain. I know this all sounds a bit hypothetical, but it's not. I can show you a real world example of every one of those things having been compromised in the past. When there is money or lives at stake people will find a way, and both things are definitely at stake here. So what we have to do is trust, but verify, or at the very least log everything that happens and that's largely what those EDR products exist to do. Maybe we can't stop every attack, even in theory, but we take a crack at it and while we're at it we can log every attack to ensure that we can at least catch it later. There just isn't any version of this world in which general purpose computers don't require monitoring, logging, and exploit prevention.
  - 1718627440 11mo ago
    Sure, that is why you trust a blackbox software from some random company running as a rootkit, whose concrete version you do not even control, because it is remotely updated by them. If you think the hardware works against you, then you are screwed.
    - mapontosevenths 11mo ago
      > Sure, that is why you trust a blackbox software from some random company running as a rootkit, whose concrete version you do not even control, because it is remotely updated by them. It doesn't have to be "a random company". Microsoft, for example, now ships EDR as part of the operating system. Many companies prefer other vendors for their own reasons. Sometimes one concern is the exact issue you're describing. By using another vendor outside of MS they can layer the security rather than putting all their eggs in a Microsoft designed basket. We sometimes call that a "security onion" in cyber. I have no idea what the Linux version of that would even look like though. I imagine you'd just choose one of the many 3rd party EDR's from "random companies." It's another reason I asked the original question about how Sysadmins cope with Linux these days. MS has an entire suite of products designed to meet these security, regulatory, and compliance problems. Linux has... file permissions I guess?
      - 1718627440 11mo ago
        If your think of running some EDR software in kernel mode, then my point is indeed don't do that. That just sounds like less security. Use the OS and run the reporting in userspace. If you want integrity, first make everything executable immutable, the system is explicitly designed to work that way. That's why the FHS exists for. Then use something like Tripwire to monitor it. To log access use auditd (https://www.baeldung.com/linux/auditd-monitor-file-access https://www.baeldung.com/linux/auditd-monitor-file-access). What else do you need to do?
        mapontosevenths 11mo ago
        > make everything executable immutable How though? Presumably you mean we should trust the OS to do that? Edit to be clear auditd has the same issue. We're trusting it to audit itself. However, we know that we cant trust it because rootkits are a thing. So now what?... I guess we need a tool thats designed to be tamper proof to monitor it. We do that by introducing an external validation. A 2nd external system can vouch that hashes are what we expect, etc.

1718627440 11mo ago

The problem is that EDR is basically a rootkit, by using it you enable a huge attack surface instead of being able to have stuff e.g. immutable. That tradeoff only makes sense, when you don't trust and control the OS itself. This is more of a problem with proprietary OSes like Windows. Otherwise you would rather integrate this into the OS itself.

mapontosevenths 11mo ago
> That tradeoff only makes sense, when you don't trust and control the OS itself. That's totally accurate, but you're missing the fact that we fundamentally don't (and can never) trust the OS or any other part of a general purpose computer. In general purpose computing you have a version of Descartes brain in a vat problem (or maybe Plato's allegory of the cave if you want to go even further back). https://iep.utm.edu/brain-in-a-vat-argument/ https://iep.utm.edu/brain-in-a-vat-argument/ To summarize: We can't trust the inputs even if the OS is trusted, and if the OS is trusted can't trust the compiler, and even if we trust the compiler we can't trust the firmware, but even if we trust the firmware we can't trust the chips it runs on, and even if we trust those chips we can't trust the supply chain, etc. "Trust" is fundamentally unsolvable for any Turing machine, because all trust does is move the issue further down the supply chain. I know this all sounds a bit hypothetical, but it's not. I can show you a real world example of every one of those things having been compromised in the past. When there is money or lives at stake people will find a way, and both things are definitely at stake here. So what we have to do is trust, but verify, or at the very least log everything that happens and that's largely what those EDR products exist to do. Maybe we can't stop every attack, even in theory, but we take a crack at it and while we're at it we can log every attack to ensure that we can at least catch it later. There just isn't any version of this world in which general purpose computers don't require monitoring, logging, and exploit prevention.
- 1718627440 11mo ago
  Sure, that is why you trust a blackbox software from some random company running as a rootkit, whose concrete version you do not even control, because it is remotely updated by them. If you think the hardware works against you, then you are screwed.
  - mapontosevenths 11mo ago
    > Sure, that is why you trust a blackbox software from some random company running as a rootkit, whose concrete version you do not even control, because it is remotely updated by them. It doesn't have to be "a random company". Microsoft, for example, now ships EDR as part of the operating system. Many companies prefer other vendors for their own reasons. Sometimes one concern is the exact issue you're describing. By using another vendor outside of MS they can layer the security rather than putting all their eggs in a Microsoft designed basket. We sometimes call that a "security onion" in cyber. I have no idea what the Linux version of that would even look like though. I imagine you'd just choose one of the many 3rd party EDR's from "random companies." It's another reason I asked the original question about how Sysadmins cope with Linux these days. MS has an entire suite of products designed to meet these security, regulatory, and compliance problems. Linux has... file permissions I guess?
    - 1718627440 11mo ago
      If your think of running some EDR software in kernel mode, then my point is indeed don't do that. That just sounds like less security. Use the OS and run the reporting in userspace. If you want integrity, first make everything executable immutable, the system is explicitly designed to work that way. That's why the FHS exists for. Then use something like Tripwire to monitor it. To log access use auditd (https://www.baeldung.com/linux/auditd-monitor-file-access https://www.baeldung.com/linux/auditd-monitor-file-access). What else do you need to do?
      - mapontosevenths 11mo ago
        > make everything executable immutable How though? Presumably you mean we should trust the OS to do that? Edit to be clear auditd has the same issue. We're trusting it to audit itself. However, we know that we cant trust it because rootkits are a thing. So now what?... I guess we need a tool thats designed to be tamper proof to monitor it. We do that by introducing an external validation. A 2nd external system can vouch that hashes are what we expect, etc.