A global outage was caused when Crowdstrike pushed a bad content file. That's well-covered in many other places so I won't elaborate on that.
What I'm interested in is whether company policies to delay automatic updates would have contained the outage.
Crowdstrike has a way to set policies to limit the Falcon sensor version to n-1, n-2, or even a specific build. So you can assign a test group to get the most recent sensor version and your production groups to get a slightly earlier version.
This is a common practice used for other types of patching, such as for Windows updates. I understand that the pace is necessarily faster for information security products, but perhaps some form of vetting might have been possible.
The file that caused the problem is classified as a "content file", and so it's possible that it wouldn't have been prevented by sensor update policies.
On the other hand, Dave Plummer's Youtube video suggested that Crowdstrike was using content updates to patch the sensor code without having to go through Microsoft's driver approval process every time. And the sensor version numbers do appear to increase fairly rapidly. So it's also possible that the policies also control content updates.
So, can we say if a Crowdstrike customer had set up a procedure to test machines against sensor updates before approving them for general release within their company, that the outage could have been contained to test group(s)?
