> AV was never a necessity on UNIX, whatever MS bundles in is usually enough
What prevents someone pushing a malicious package that takes my user data (that is accessible from a logged in session directly) and sends it somewhere? Especially in non-system repos, like Maven/NuGet/npm/pip/RubyGems and so on? What about the too widespread practice of piping shell scripts from the web, or applications with custom update mechanisms that might be compromised and pull in malicious code?
I'm not saying that AV software would protect against all of these, but even if users don't do stupid things (which they absolutely will anyways, sooner or later), then there are still vectors of attack against any system.
As for why *nix systems don't see that much malware, I've no idea, maybe because it's not as juicy of a target because of the lower count of desktop software installations (though the stuff that is on the systems might be more interesting to some, given the more tech savvy userbase), or maybe because a lot of the exploits focus on server software, like most CVEs.
On Windows, I guess the built in AV software is okay, maybe with occasional additional scans by something like Malwarebytes, but that's situational.
Nothing, in fact there have been many cases where python's and nodejs's package systems were exploited to achieve arbitrary code execution (because that's a feature, not a bug, to allow "complicated installation processes to just work").
AVs are the wrong way to go about security anyway, it's a reactionary strategy in a cat and mouse game by definition. For prevention, I think the BSDs are doing some promising work with the "pledge" mechanism. And as much hate as they get, I like appimages and snap et al for forcing people to consider a better segmentation model and permission system for installed software.
Crowdstrike agent is theoretically able to detect that what you just pipe-installed is now connecting to a known command and control server and can act accordingly.
Carbon Black will block any executables it pulls down though. And I think it may also block scripts as well. Executables have to be whitelisted before they can run.
Its an extremely strict approach, but it does address the situation you're talking about.
If you write a batch file on a Windows PC with Carbon Black on it, you will not be able to run it. Of course there is customisation available to tweak what is/isn't allowed.
Yes, but that's like 1% of the actual surface area for "running a script". I am not a Windows expert but on, say, Linux you can overwrite a script that someone has already run, or modify a script that is already running, or use an interpreter that your antivirus doesn't know about, or sit around and wait for a script to get run and then try to swap yourself into the authorization that gets granted for that, or…there's a whole lot of things. I assume Windows has most of the same problems. My confidence in Carbon Black stopping this is quite low.
If your malicious script starts doing things like running well known payloads or trying to move laterally or access things it really shouldn't be trying to access AV will flag/block it.
No one is suggesting it is 100% coverage but you would be suprised at the ammount of things XDR detects and prevents in a average organization with average users. Including the people who can't stop clicking YourGiftcard.pdf.exe
I am not against trying to protect against people who do that. The problem is that you pay XDR big bucks to stop a lot more than that, and this mostly doesn't work.
In a perfect world, AV software wouldn’t be necessary. We don’t live in a perfect world. So we need defense-in-depth, covering prevention, mitigation, and remediation.
> What prevents someone pushing a malicious package that takes my user data
That's not an argument in good faith. If you install unvetted packages in your airline control system, bank, or supermarket, the kind of systems that we're talking about here, you have much bigger problems to worry about.
> I'm not saying that AV software would protect against all of these,
Or indeed any of these. Highly privileged users piping shell scripts from untrusted sources is out of scope for any antivirus system, on any platform.
That doesn't mean all platforms are identical, or share the same attack vectors. It is much more accepted to install kernel mode drivers on the Windows platform, where it is not only accepted but have established quality control programs to manage it, than on Linux, where the major vendor will very literally show you the middle finger on video for everyone to see for doing so.
The Linux community is more for doing that kind of work upstream. If some type of new access control or binary integrity checking is required, that work goes upstream for everyone to use. It is not bolted on running systems with kernel mode drivers. That is because Linux is more like a shared platform, and less like a "product". That culture goes way beyond mere technical differences between the systems.
> If you install unvetted packages in your airline control system, bank, or supermarket, the kind of systems that we're talking about here, you have much bigger problems to worry about.
Surely we can agree that if it's a vector with an above 0% chance of it being exploited, then any methods for mitigating that are a good thing. Quite possibly even multiple overlaid methods for addressing the same risks. Defense in depth and all, the same reason why many run a WAF in front of their applications even though someone could just say: "Just have apps that are always up to date with no known CVEs".
> Or indeed any of these. Highly privileged users piping shell scripts from untrusted sources is out of scope for any antivirus system, on any platform.
You don't even have to be highly privileged to steam information, e.g. an "app" for running some web service could still serve to exfiltrate data. As others have mentioned, maybe this is not what AV software has been historically known for, but definitely there are pieces of software that attempt to mitigate some of the risks like this.
I'd rather have every binary or piece of executable code be scanned against a frequently updated database of bad stuff, or use heuristics to figure out what is talking with what, or have other sane defaults like preventing execution of untrusted code or to limit what can talk to what networks, not all of which is always trivial to configure in the OSes directly (even though often possible).
I won't pretend that AV software is necessarily the right place for this kind of functionality, but I also won't pretend that it couldn't be an added benefit to the security of a system, while also presenting different risks and shortcomings (threat vector in of itself or something that impacts system stability at worst, or just a hog on the resources and performance in most cases).
Use separate VMs, use secret management solutions, use separate networks, use principle of least privilege, make use of good system architecture, have good OS configuration, use WAFs, use AV software, use scanning software, use dependency management alerting software, use static code analysis, use whatever you need to mitigate the risk of waking up and realizing that there's been a breach and that your systems are no longer your own.
Even all of that might not be enough (and sometimes will actually make things worse), but you can at least try.
In that we can agree. But I would put "build on operating systems intended for the purpose" on top of that list, too. There is no excuse for building airline or bank systems on office operating systems and trying to compensate by bolting on endpoint protection systems.
The issue here is not simply scanning for known malware, "endpoint protection" systems go way beyond that. I have never, in practice, seen any of those systems be a net benefit for security. And I mean in a very serious and practical way. Depending on your needs, there are far more effective solutions that don't require backdooring your systems. There simply shouldn't be any unauthorized changes for this type of systems.
> In that we can agree. But I would put "build on operating systems intended for the purpose" on top of that list, too.
Agreed, most folks should probably use a proven *nix distro, or one of the BSD varieties. That would be a good starting point.
That said, I doubt whether the OS alone will be enough, even with a good configuration, but at some point the technical aspects have to contend with managing liability either way.
Carbon Black, running in DO NOT LET UNTRUSTED EXECUTABLES RUN mode,
would not let you run binaries that curl | sh just grabbed unless they were allow-listed.
What prevents someone pushing a malicious package that takes my user data (that is accessible from a logged in session directly) and sends it somewhere? Especially in non-system repos, like Maven/NuGet/npm/pip/RubyGems and so on? What about the too widespread practice of piping shell scripts from the web, or applications with custom update mechanisms that might be compromised and pull in malicious code?
I'm not saying that AV software would protect against all of these, but even if users don't do stupid things (which they absolutely will anyways, sooner or later), then there are still vectors of attack against any system.
As for why *nix systems don't see that much malware, I've no idea, maybe because it's not as juicy of a target because of the lower count of desktop software installations (though the stuff that is on the systems might be more interesting to some, given the more tech savvy userbase), or maybe because a lot of the exploits focus on server software, like most CVEs.
On Windows, I guess the built in AV software is okay, maybe with occasional additional scans by something like Malwarebytes, but that's situational.