Comment

Comment on CrowdStrike Isn't the Real Problem

Rollout policies are the answer, and CrowdStrike should be made an example of if they were truly overriding policies set by the customer.

It seems more likely to me that nobody was expecting “fingerprint update” to have the potential to completely brick a device, and so none of the affected IT departments were setting staged rollout policies in the first place. Or if they were, they weren’t adequately testing.

Then - after the fact - it’s easy to claim that rollout policies were ignored when there’s no way to prove it.

If there’s some evidence that CS was indeed bypassing policies to force their updates I’ll eat the egg on my face.

source

Sort:hotnew top

originalucifer@moist.catsweat.com ⁨4⁩ ⁨months⁩ ago
from what ive read/watched thats the crux of the issue.... did they push a 'content' update, i.e. signatures or did they push a code update.

so you basically had a bunch of companies who absolutely do test all vendor code updates beings slipped a code update they werent aware of being labeled a 'content' update.

source
DesertCreosote@lemm.ee ⁨3⁩ ⁨months⁩ ago
I’m one of the admins who manage CrowdStrike at my company.

We have all automatic updates disabled, because when they were enabled (according to the CrowdStrike best practices guide they gave us), they pushed out a version with a bug that overwhelmed our domain servers. Now we test everything through multiple environments before things make it to production, with at least two weeks of testing before we move a version to the next environment.

This was a channel file update, and per our TAM and account managers in our meeting after this happened, there’s no way to stop that file from being pushed, or to delay it. Supposedly they’ll be adding that functionality in now.

source