Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CrowdStrike will be liable for damages in France, based on the OVH precedent

thehftguy.com

Post reply on HN
Print view View original

231–240 of 285 posts

Re: CrowdStrike will be liable for damages in France, based on the OVH precedent

#231

Post by dathinab »

sjamaan wrote: post #76
lukan wrote: post #51

Earlier quoted context omitted.

"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.

It's a B2B tool, which means it's quite likely the contract/license states that all disputes are to be settled in a court appointed by them. This is not valid for consumer disputes, but businesses are free to do what they want. Perhaps this will let them off the hook? OVH is different in that it's actually a French company.

> but businesses are free to do what they want.

this is not true

just because you write into your contract that something will be settled in a specific jurisdiction doesn't mean it's legally actually the case

Re: CrowdStrike will be liable for damages in France, based on the OVH precedent

#232

Post by ungamedplayer »

amluto wrote: post #178
worthless-trash wrote: post #78

Earlier quoted context omitted.

What you've answered is a great (if not the best) way to defend against attackers, but not what was asked,They asked how to detect. I'll strongly disagree on selinux, I have seen it work in practice to defeat attackers many times, that provide features that seccomp and cgroups etc do not.

re: SELinux, I think it depends on your use case. If your system is a flight information display, then you may well have two userspace processes that do anything of significance: the display manager and the actual app. There is no persistent state. At this point, SELinux is purely overhead and extra attack surface — what would it even protect. If your payload is a container (database server, microservice, whatever),…

Absolutely depends on the use case. I'm attempting to talk in the generic case. If you limit policy to the minimum attack surface from outside the process including permissions and capabilities which are significantly more fine grained in selinux compared to normal Unix permissions, you reduce the the capability of the attacker once they gain access to the system.

Imagine if they got access to local code execution... Binding to sctp protocol would instantiate the whole protocol in kernel. Effectively opening up whole new attack vectors. I can't see any other techniques (other than selinux like AC) that enables this kind of attack space reduction as easily.

I am aware that you can blacklist modules,etc but this is just one of many examples.

Re: CrowdStrike will be liable for damages in France, based on the OVH precedent

#233

Post by null_investor »

hda111 wrote: post #121
null_investor wrote: post #95

What is hilarious to me is how the US government or courts doesn't seem to give a shit about this. Corporativism in US is a thing. Companies can brick hospital systems killing patients, drive self-driving cars and run over people but don't get sued, and if they do, they settle for very little. Just look at the recent Boeing incident where people were killed, the company clearly misled the US authorities and settled o…

I think you meant US companies. The fine for Volkswagen was $20B+.

That's why the EU needs to kick out big tech and be much more unfriendly to US companies, have its own atomic bombs and security and not be dependant on a country that every election it's foreign policy completely changes (Democrats vs. republicans)

It feels like US can hit as much as they can EU companies, but EU needs to create a whole new regulation to slap a $1B fine in a 2 trillion company from the US.

Re: CrowdStrike will be liable for damages in France, based on the OVH precedent

#234

Post by tracker1 »

xxs wrote: post #33
GJim wrote: post #20

Earlier 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.

I always prefer, default to, and advocate for yyyy-MM-dd format for dates to avoid confusion. Once you're used to them, no other format will do. Also, files with such names (backups, etc) will also be in a natural order.

Re: CrowdStrike will be liable for damages in France, based on the OVH precedent

#235

Post by tracker1 »

quantum_state wrote: post #64
Baguette5242 wrote: post #7

Holy 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…

None of them is reasonable. Open source and regulation on software safety is required. The society at large has been too lenient with poor quality software.

And the solution to that may be worse. Do you want to saddle all open-source with strict regulatory compliance on safety?

Re: CrowdStrike will be liable for damages in France, based on the OVH precedent

#236

Post by adunsulag »

prmoustache wrote: post #210
simiones wrote: post #206

Earlier quoted context omitted.

Automatic security updates are widely touted as the gold standard in IT security, at least for anything that is not a life-support system.

I am talking about control, I am not talking about disabling automatisation of updates. You can have automatic security updates with delay between non prod and prod environments so that you can detect failures or possibly intrusions.

My understanding is that customers believed they had control as Crowdstrike gave them configuration options to delay updates / stagger them. Apparently many of them were surprised that Crowdstrike had the ability to bypass all these configuration options and force the update. I think that is where Crowdstrike's liability skyrockets through the roof.

Re: CrowdStrike will be liable for damages in France, based on the OVH precedent

#237

Post by tsimionescu »

prmoustache wrote: post #199
tsimionescu wrote: post #55

Earlier quoted context omitted.

Only your third point makes any sense. For the other two, obviously the answer is yes, that's entirely reasonable. Businesses and government organizations use plenty of commercial tools that they have no way of designing or understanding on their own. Software is no different from hardware from this point of view. A hospital doesn't have, and couldn't use even if it did, the blueprints for an MRI machine or an old-fa…

But do we really need "trade secrets" as a society?

Even if companies were forced to publish every detail of their devices (which is the only way to not have trade secrets), any decently complex products products would still be black boxes to every company who is not specialized in creating them.

Even something like a fountain pen is used as a black box, I'm not even talking of anything truly complex. Even the buildings we work in are black boxes that we get from third parties, not to mention all the systems powering and heating or cooling them.

Re: CrowdStrike will be liable for damages in France, based on the OVH precedent

#238

Post by tsimionescu »

lynx23 wrote: post #112
tsimionescu wrote: post #69

Earlier quoted context omitted.

If your system was processing any valuable information owned by the company (code, PII, etc) than the company is likely much safer today than it was when you had exclusive control over that system, even if they introduced several vulnerabilities. Previously, if you decided/were coerced to do something against the company's interests, you could do whatever you wanted from that system and they never would have even kno…

Well, now we're getting somewhere. If my company distrusts me so much that it needs to put a black box in place to prevent me from fucking it over, it shouldn't hire me as an admin for tons and tons of infrastructure. Distrust goes both ways. Increase the pressure, and maybe, maybe, your employee will just leave for another company that doesn't behave that way (yet). The timing is great, because some employees still…

Any company that fully trusts all of its employees to handle my secrets is a company I don't want to do business with. I would bet you don't want, say, every hospital janitor to have access to your personal medical records either. So, you probably also want the hospital not to trust its employees and to keep certain data under lock and key. Same with a bank and your money.

It's no different with software.

Re: CrowdStrike will be liable for damages in France, based on the OVH precedent

#239

Post by ongy »

amluto wrote: post #70
commandersaki wrote: post #35

Earlier quoted context omitted.

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.

> How do you actively detect a malware agent running in user space using stealth or a kernel. 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…

> Only authorized images will boo

How do you do this on modern commodity hardware without secure boot?

Or do you assume something in the category of embedded systems that allow to blow some efuses to get similar trusted boot?

Re: CrowdStrike will be liable for damages in France, based on the OVH precedent

#240

Post by ongy »

ungamedplayer wrote: post #232
amluto wrote: post #178

Earlier quoted context omitted.

re: SELinux, I think it depends on your use case. If your system is a flight information display, then you may well have two userspace processes that do anything of significance: the display manager and the actual app. There is no persistent state. At this point, SELinux is purely overhead and extra attack surface — what would it even protect. If your payload is a container (database server, microservice, whatever),…

Absolutely depends on the use case. I'm attempting to talk in the generic case. If you limit policy to the minimum attack surface from outside the process including permissions and capabilities which are significantly more fine grained in selinux compared to normal Unix permissions, you reduce the the capability of the attacker once they gain access to the system. Imagine if they got access to local code execution...…

You can use SEccomp for some of it as well. But for SEccomp something in the hierarchy needs to do this actively

While SELinux can be set up somewhat orthogonal to the running system. OTOH systemd should make it easy to confirm every service process

Post reply on HN