Why does my log aggregation and monitoring tool need to be a kernel driver? Why can't I just use Windows Defender and a network scanner for detection, and netboot the endpoints to make bootkits useless? That would provide just as much in the way of detection, and more in the way of protection, and I still don't need to trust my endpoint, nor any third party.
From a security perspective what you're describing is a nice-to-have, and to get it you'd decuple your attack surface by adding a networked, unfirewallable, impossible to remove rootkit-shaped target for every hacker in the world to instantly own your entire network.
Banks and insurance companies already have a lot of endpoints with no kernel level EDR, those are their Android and iOS devices. It works just fine and has for a long time.
This old chestnut?
1. Exploiting endpoint agents is mildly popular on blogs and in conference talks. It could happen in the wild, but that's costly R&D for something that would be found and patched immediately. The economics are against it, so in practice it doesn't happen.
2. Exploits in general are actually pretty rare in the corporate world, and when we do see them they're mostly command injections like Log4Shell. This is a 180-degree turn from a decade ago, when Internet Explorer was the dominant browser, the web ran on Flash, people read PDFs in Acrobat, and Microsoft could barely patch the Office equation editor because they'd lost the source. That world is gone.
3. In the 2020s, almost every attack you'll have heard of was because of weak passwords or missing MFA. SolarWinds, Colonial Pipeline, Uber, Okta, Microsoft, UnitedHealth, on and on. Plenty of malware, zero exploits.
So to sum up, you have real risk from bad things that actually happen, and then you have tools that effectively manage that risk, and then you have hypothetical risk that never happens associated with those tools. And your position is that the hypothetical risk that never happens is so great that people shouldn't use these tools to stop the real risk that actually does happen.
Which, sure. That's a take.
You can't know that with anywhere near this level of confidence. For most organizations the only thing that would detect such an attack to begin with is the ERR itseld. An exploited endpoint agent in a world where endpoint agents are the cornerstone of security means that there is no guarantee it would be found immediately, especially if it's used for a targeted attack and cleaned up afterwards. Even if it was, it would be impossible to patch automatically and would require reinstalling the OS.
> 3. In the 2020s, almost every attack you'll have heard of was because of weak passwords or missing MFA. SolarWinds, Colonial Pipeline, Uber, Okta, Microsoft, UnitedHealth, on and on. Plenty of malware, zero exploits.
There were plenty of attacks that relied on exploits in the 2020s. The KEV database itself lists hundreds every year. Multiple ransomware groups relied on RCE vulnerabilities. Sometimes weak credentials are also implicated, that doesn't mean they are the only reason, and certainly doesn't mean "zero exploits".
> So to sum up, you have real risk from bad things that actually happen, and then you have tools that effectively manage that risk, and then you have hypothetical risk that never happens associated with those tools. And your position is that the hypothetical risk that never happens is so great that people shouldn't use these tools to stop the real risk that actually does happen.
The real risk that gets exploited every day is that we trust endpoints we shouldn't and don't need to. These tools do not manage this risk effectively, and in fact they make it worse because they are extremely difficult to administer when you don't integrate the endpoints in your network, and in addition to that they require you to trust one more party. The "hypothetical" risk of trusting your endpoint and integrating it in your network literally proves itself dozens of times every day.
Besides, SolarWinds and Okta showed that trusting additional security vendors is a real risk. What if instead of SolarWinds being the supply chain attack, it was CrowdStrike, and that patching the malware would require manual intervention? Supply chain attacks are hardly a hypothetical risk.
And before you say that endpoint trust and EDR is unrelated, try managing an EDR deployment without Active Directory. It's basically impossible. EDR tools assume your endpoint is trusted by default because they're too invasive to be managed otherwise.
Defender for Endpoint runs in kernel mode. If you just mean plain jane Defender, well, there's a reason Microsoft sells Defender for Endpoint.
I'm not sure what a network scanner is intended to do here but if you mean a network intrusion detection system, those still exist but the market has kind of been strangled by EDR because you get higher fidelity detections and need one fewer skillset.
> It works just fine and has for a long time.
Sort of. There are a lot of controls (MDM and sandboxing and such) that go into that. I'd guess most orgs would just slap EDR on the phones if they could. Again, same result with fewer skillsets and products if so. You need a pretty severe risk to outweigh that and I'm not sure a one-time incident and the slight risk of an actual hostile compromise of an EDR vendor get there. Maybe if there are more like this.
> Sort of. There are a lot of controls (MDM and sandboxing and such) that go into that. I'd guess most orgs would just slap EDR on the phones if they could. Again, same result with fewer skillsets and products if so. You need a pretty severe risk to outweigh that and I'm not sure a one-time incident and the slight risk of an actual hostile compromise of an EDR vendor get there. Maybe if there are more like this.
There's nothing wrong with MDM and group policy in and of itself.
If orgs could slap EDRs into their mobile devices, the mobile devices would have to become less secure to begin with. The EDR seems to be a marginal risk, but the problem is in the architecture change that's needed to accomodate such an invasive product as an EDR that is a huge risk.
If they are it'll be a fantastic litmus test of my claim.
It's not like Microsoft has spent the last few decades entirely ignoring these large scale infrastructure needs, they've just been competing with these bloatware vendors like CrowdStrike with significant marketing arms and incredible sunk cost inertia. (Given most of these companies already pay for things like Intune, it's a weirdly doubled sunk cost inertia, but still a sunk cost inertia.)
> Intune is already outdated btw.
I do know that part of Microsoft loves to change brand names every quarter for fun and the "parent" organization has changed a few times from different parts of Office and Windows Server to now "Microsoft 365", but as far as I can tell (and I don't keep up with it) Intune is still the active brand name: https://en.wikipedia.org/wiki/Microsoft_Intune
It's because of the merger into Microsoft 365 that I feel confident that most big Enterprises are already paying for Intune even if they aren't using the most up-to-date version and don't know what compliance "checkboxes" it solves versus something like CrowdStrike.
The EDR team might have more info about Windows internals than CrowdStrike does, but then again, maybe not; CrowdStrike already has to work pretty closely with Microsoft to get into the kernel in the first place, and Microsoft is (sometimes) pretty careful about 'bundling' antitrust concerns.
Red Hat says CrowdStrike themselves have sent out eBPF files that have caused all sorts of kernel panics. Any sufficiently advanced kernel scripting language is still kernel-level code. I'm not sure eBPF is exactly the savior people are hoping for, though I do still think it remains something of a general improvement if Microsoft can actually get AV vendors and others to use eBPF rather than bespoke kernel drivers.
Paying less to reduce security is a baffling business model.
Ancient IT mindset says "me need domain controller. me buy win server." but it does not need to be like this.
This is the state of modern Enterprises.
I've got two objections to this conventional wisdom:
1) Endpoint protection in particular isn't essential to good infrastructure. It's only a bandaid over bad infrastructure. Perhaps a moot point, given that bad infrastructure is prevalent, but I digress.
2) Every IT director asserting this should be challenged to prove it. Prove that you stopped credible threats equal to X dollars of damage or lost revenue compared to the Y dollars of actual lost revenue due to production outages. And I'm not talking about the inflated threat totals that such systems produce to justify their existance, but actual threats that absent CrowdStrike would have penetrated other defenses. Until this can be done, it's simply a hypothetical vs the actual damages inflicted by the outage.
It’s also quite impossible in practice.
Say that you know for a fact that CrowdStrike prevented a ransomware attack. How can you accurately assess the money saved by prevention if you don’t know what the ransom would have been set at? How can you accurately assess the value of the data loss from not paying the ransom?
You can make educated guesses in both cases, but they are still strictly in the realm of the hypothetical.
Underfunding relative to what? Another example I'd cite would be the TSA. How much do we pay it now vs how much would we lose based on what they've truly stopped?
>Say that you know for a fact that CrowdStrike prevented a ransomware attack. How can you accurately assess the money saved by prevention if you don’t know what the ransom would have been set at? How can you accurately assess the value of the data loss from not paying the ransom?
You could estimate at an order of magnitude based on the level of access of the user and a model of your infrastructure. For example, if only one machine is compromised, you could estimate order of magnitude based on the value of the data lost, the floor being set at the days of work lost * hourly rate of the user.
If you want proof that real world attack would be stopped by measure, then you will leave the system vulnerable to everything your internal people were not able to exploit.
The situation(s) that make EDR valuable, however, are not going away. Not just for prevention, but for detection and threat hunt, EDR in general and CrowdStrike in particular have pretty much eaten the market that was once shared by network detection, etc.
We live in an immensely networked world built on top of swiss cheese infrastructure (even the latest Windows is riddled with points of attack surface), unless you plan rehaul the underlying infrastructure it's simply not an option to run large scale infra without a protective layer on top.