Earlier quoted context omitted.
Windows does have Defender, which does some amount of tracking signatures and heuristics of various types of malware. It has not, however, proved enough to fend off different real world problems like ransomware. Hence, the market for 3rd party solutions that are more aggressive. And to keep up with real world threats, they have to update often. And have to run at high privilege levels. So now you have the situation w…
But randsomware is mostly targeted to servers, many of the devices affected were clients
CrowdStrike will be liable for damages in France, based on the OVH precedent
61–70 of 285 posts
Re: CrowdStrike will be liable for damages in France, based on the OVH precedent
#62Earlier quoted context omitted.
It's not unusual in the US to assume the US are the only planet in the universe.
Special mention of the expression “the west” which Americans like to use to mean the USA and some amorphous blob I don’t really want to think about but I’m going to pretend is exactly the same as the USA.
Re: CrowdStrike will be liable for damages in France, based on the OVH precedent
#63Earlier quoted context omitted.
The number of US tech businesses that are surprised they need, or think they can ignore the need, to obey employment and data protection laws when working in other jurisdictions is simply bonkers.
Well, it'd be a lot easier if most US entities understood that M/d/yy(yy) format is rare, or that default to Frankenstein degrees is pretty much the same/awkward (even Microsoft reset their weather widget to F on regular basis). The root of issue, not understanding local laws/culture, is very similar - surrounded by a vast market/culture (US +Canada) dulls your senses for the rest of the globe.
US companies don't think about Canada as anything but an afterthought, and struggle with the same issues here that you just mentioned.
Canada is metric, uses different spellings (closer to UK English.. colour, not color [Chrome just marked my spelling as wrong despite me having Canadian English as my setting]) and is officially bilingual with localization laws requiring companies to provide French versions for certain kinds of services. US companies either don't bother, or usually get this entirely wrong.
e.g. It's been how many years? And navigation on Android / Google Maps can't pronounce French names for streets/places while driving around in bilingual places in Canada. Just completely butchers them, their system can't "understand" the concept that you could have your language set to English but still need to hear French place names, or vice versa.
Re: CrowdStrike will be liable for damages in France, based on the OVH precedent
#64Holy shit (hits the fan). For sure CrowdStrike will be held accountable in several countries, but I believe that some conclusions need to be drawn also from a customer/user perspective. - Is it reasonable to grant such privilege access to a piece of software that ultimately is a black box ? - Is it reasonable to put a Microsoft / Commercial / Closed source OS in critical infrastructure ? If not considered as critical…
Re: CrowdStrike will be liable for damages in France, based on the OVH precedent
#65Can someone explain to me why the protections that Falcon provides, are not provided by the OS itself? I am not completely naive, I've secured quite a few critical Linux servers, but with Windows it seems that there do not exist the same clear roles of security. Contrast with Red Hat or even Canonical, where is feels like I'm (correctly) fighting the security of the systems to get them into a state where my users can…
E.g. downloading a file and running the contents as code, or uploading/encrypting all files you have access to.
Crowdstrike and Defender handle those possible but suspicious actions.
Re: CrowdStrike will be liable for damages in France, based on the OVH precedent
#66Re: CrowdStrike will be liable for damages in France, based on the OVH precedent
#67Surely, there must be a gigantic number of claimants already taking to their lawyers about how to get compensation? Not just in France but across the planet? I wonder how this kind of thing is organised, since there's all these jurisdictions.
"I wonder how this kind of thing is organised, since there's all these jurisdictions." In theory simple. Crowdstrike is doing buisness in state X, so compensation claims will be settled in court in state X. So lots of courts and lawers all around the world, will be quite busy for some time with the case.
If that doesn't work, judgements can be registered in other courts for collection purposes.
Re: CrowdStrike will be liable for damages in France, based on the OVH precedent
#68Can someone explain to me why the protections that Falcon provides, are not provided by the OS itself? I am not completely naive, I've secured quite a few critical Linux servers, but with Windows it seems that there do not exist the same clear roles of security. Contrast with Red Hat or even Canonical, where is feels like I'm (correctly) fighting the security of the systems to get them into a state where my users can…
As to why windows is not more locked down- that's on the shoulders of the admins. But out of the box, you are right, it is to permissive. But apparently users and management like it that way.
Re: CrowdStrike will be liable for damages in France, based on the OVH precedent
#69Holy shit (hits the fan). For sure CrowdStrike will be held accountable in several countries, but I believe that some conclusions need to be drawn also from a customer/user perspective. - Is it reasonable to grant such privilege access to a piece of software that ultimately is a black box ? - Is it reasonable to put a Microsoft / Commercial / Closed source OS in critical infrastructure ? If not considered as critical…
EDRs are the devil's spyware. Especially since corporate "security" people are now pushing for EDRs to run on Linux. Argument is that the cloud nature of the thing makes it necessary that it runs everywhere. Fact is, since my company forced me to install this black box, my system is definitely less secure. Before that, I didnt have a single incoming port enabled. Now, my system talks to all sorts of external things w…
Security is a complicated topic, and employees are also potential attack vectors. A system that is in the complete control of a malicious employee is a security problem for the company just as much as a system that was corrupted by an external cracker.
Re: CrowdStrike will be liable for damages in France, based on the OVH precedent
#70Can someone explain to me why the protections that Falcon provides, are not provided by the OS itself? I am not completely naive, I've secured quite a few critical Linux servers, but with Windows it seems that there do not exist the same clear roles of security. Contrast with Red Hat or even Canonical, where is feels like I'm (correctly) fighting the security of the systems to get them into a state where my users can…
How do you actively detect a malware agent running in user space using stealth or a kernel. Authors of such are fully aware of Linux hardening like SELinux / AppArmor and work around it.
You start with correct design.
The system has a root of trust (ideally you skip the insane level of complexity that is Secure Boot + TPM and use something simple, testable, and verifiable — this isn’t actually that hard). Only authorized images will boot, and, more importantly, nothing else on the network trusts the machine until it proves it’s running the right image.
Then you make the image immutable. Want to edit a system file? You can’t. Maybe in developer mode you can edit an overlay.
All configuration is stored in a designated place, and that configuration is minimized. A stock image from the distro vendor has zero configuration, so there is no incomprehensible soup in /etc to audit. Configuration is also attested.
Persistent data is separate from configuration. All persistent data is considered suspect. Any bug that allows malicious persistent data to compromise anything is a blocker, including corrupt filesystem metadata.
A root-of-trust attestation has limited lifetime. The system forcibly re-verifies periodically. This either means rebooting or doing a runtime “dynamic root of trust” attenuation. The latter is complex.
Complicated messes like kernel “lockdown” and the stock Secure Boot signatures have no place. Usermode root and the kernel are approximately equally trusted. SELinux is barely necessary, if at all, unless the actual user code wants it to control access to persistent data. But there are simpler, better schemes that are easier to reason about.
Sadly the industry doesn’t think this way. I’m regularly surprised that Apple hasn’t gone in this direction more aggressively than they are with their MacOS products.