One interesting feature of this outage was that "PROD" was generally fine, on account of mostly running on Linux and/or ancient proprietary software, while "CORP" was generally wrecked, on account of mostly running Windows. In other words, the bank systems responsible for moving money mostly worked, while the systems responsible for allowing humans to interact with them (to issue approvals, change configuration, or other ops things) often did not.
Yep, here in manufacturing production/OT PLCs run on Wind River VxWorks from Rockwell, Siemens, and others. The HMI (human-machine interface, basically a touchscreen used to display status and enter setpoints and other data) and SCADA/ERP systems run on Windows. Sometimes, this is an industrial fanless PC with eg. Ignition (Java+Python) software, other times it's a Rockwell Panelview which actually still run Windows CE 6.0.
This gets to be a problem when IT wants to get their hooks into OT networks. The PLC is meant to be left alone, and will happily send its Ethernet packet to that servo drive or digital IO card every 10ms for literal decades. There is no reason to update its firmware ever, just don't expose it to the Internet. But corporate wants everything on the Internet.
The PLC will reliably run its sequence when you close the contacts on the physical "Cycle Start" pushbutton. But if corporate is down, you can't know what part number you're supposed to make or how many of them, or get a serial number from and report test results to the traceability database.
On the flip side, there are a lot of physical production systems (think CNC mills or 3d printer farms) where remote observability and management would be very handy, or where you'd really like to upload gcode files directly from your workstation. However, because they've been air-gapped, you need to instead walk across the shop floor to "that one PC" that allows you to insert a USB stick, copy the files off the network drive to the USB, then walk back to the lab with the machine tools and insert the stick to feed the files over.
If you want to monitor, you need to sit in the lab and watch, or if you're lucky, leave a PC with a webcam pointed at the tool and remote into that machine from your desk or your laptop at home.
This works, but long cycle times kill productivity, and engineering twiddling their thumbs costs money. It's easy to end up spending multiple hours a week just walking back and forth doing this dumb dance. One would expect that with 40+ years of networking experience, we would have come up with a way to securely perform these tasks without simultaneously exposing our tooling to cyberattack. Perhaps some kind of segregated network that can't access the internet, but gets pull-only access to the file share? Or vice versa - a screencap feed that gets sent through a data diode so an engineer can monitor the tool from their phone or laptop without being able to affect it?
Perhaps such solutions exist and are just beyond the IT skills, budget, or complexity appetite of the sorts of production tooling shops that I'm familiar with.
Caveat tho - I don't work in this space, I'm just friends with people who do.
100% - banks were just a specific example that popped to mind immediately. If this bug had affected Linux Crowdstrike, we might have seen the opposite - people hard at work on their laptops trying to fix the production server outages. Probably nothing could have taken down the FAA systems though, on account of them being too old and bespoke to have a supported Crowdstrike module.
In the original thread there were some reports of people having their Linux systems taken down by Crowdstrike as well. At separate times, of course, and I supposed the greater heterogeneity of Linux distros prevents events of this magnitude. But that would be little consolation when it takes down your systems.
Those should be considered coincidence until proven otherwise. Crowdstrike is intended to bring down systems when it believes there was an intrusion, after all.
