Let's break down your response:
You've completely left out the part where the local machine would need security prior to even connecting to the network as is dictated by many IT Security admins and which I very clearly mentioned in the post you're responding to.
You mean 802.1x. Likely Delta didn't even have that. If you have properly designed your system, you can still do things like PXE boot and updates, which we allow our users a few more things basically fixing things if the certificate expired or got corrupted or logins don't work, it is limited what you can access, but you can do it. If you lock out every person because they can't authenticate to your 802.1X without MANUAL INTERVENTION, then YOU are making poor design decisions.
Please do better next time, I would suggest looking at the Open Source solution PacketFence. Please do think through your proposed security solution next time.
This is only true if those systems were first configured to do so.
That is entirely my point, do you have a mass malware recovery option? If you manage 150k+ devices on your network, you don't want to walk around fixing shit, if you don't have a recovery time objective for a black swan event like this, you are doing things wrong. Malware will cause the same damage, do you not have a playbook? Where will you hire 5,000 IT folk within 24 hours to meet that RTO?
As PXE boot is vulnerable to a MItM attack, especially in a more open network like an airport.
First you claim they have 802.1X now you claim they are vulnerable to MITM. Let me tell you, terminals in the airport are not connected to public WiFi (or they shouldn't). Please do better next time. That is also why we have things like BitLocker, so in case a public terminal gets compromised by a wandering trader with a USB drive. According to Delta, they do not have the recovery keys for. Again, that is something I said we have an option for - once booted into PXE boot with a trusted (that is what TPM is for) boot chain, then you just run a script based on trusted information. And again, Apple does this for ALL their devices, Dell can do it, Intel AMT works globally with the right configurations, you can be on a public WiFi and your company can re-deploy or destruct the hard drive remotely, that is TRUE security, not "if it's not on my trusted network and runs this AV software, only then", no, I need a guarantee and have at least 3 ways to destroy a machine, even if it is intentionally being tampered with.
This is assuming it was approved by IT Security. As those same features allowing remote access can be used to gain the same access by bad guys, it would tend more towards not being enabled.
Please read up on Intel AMT to discover why that is not the case. You need physical access to enable it and you need to enroll encryption keys to pair with it. IT's not just a switch. Again, do better.
Now multiply that time by several thousand
I did, we recovered 150,000 devices in a matter of days
add in the travel necessary because
Unnecessary as we have a mass malware playbook
IT Security would not have allowed either remote access to those machines by any of the above methods or for those machines to remotely access a workstation without security software installed
Again, BS, it is not security, people will find ways around said security and you will have no security as a result. You clearly have never designed in collaboration with true IT security folks.
they still would have needed to obtain the bitlocker keys in order to decrypt each machine just so they could do the fix in the first place since none of them were able to fully boot and likely were now encrypted and waiting for those keys.
That is what MBAM, SCCM, AD is for (or its Azure equivalents) - which most of it is either an LDAP or SQL database, more or less integrated. When a system is booted you can literally recover its recovery key from PowerShell. Ours is stored in AD and in the Snipe-IT inventory management SQL databases so it is a query away.
I'm assuming, at this point, that you're just throwing out random information hoping something sticks.
802.1x is a networking standard. Yes it has some security built in, no that's not enough to secure a machine or, quite frankly, a network. This is why it's only part of a security solution and not the entire thing.
As you've brought up 802.1x several times, this must mean you think it's a magic bullet to secure all systems.
Second, you're giving a what-if scenario instead of what actually happened and is happening. That isn't where we're at with this. It's the equivalent of saying you would've gotten somewhere sooner had you been driving rather than the person who actually is driving. It helps no-one and annoys everyone. That's not what this conversation is now or ever has been about. If you think that's what it should be, post your comment as such, not as a response.
Next, good for you, you hypothetically recovered 150,000 devices in a matter of days. That means you didn't actually have to type in the bitlocker keys, visit the locations as these techs had to do, boot up each machine to the point of inputting that bitlocker key prior to being able remove the file or whatever fix they ended up going with. That's not what happened here or how these machines were configured to work. "My own company does not use Crowdstrike so those 150,000 devices of yours that need to be back up and running was a waste of time because you could have done it better" - see how that argument works?
Your next argument "people will find ways around said security". This is the same argument given every single time IT Security proposes a change and is, effectively, a non-argument. Security isn't meant to completely block every access, it's to mitigate the issues as much as possible. It's the equivalent of not locking your door because a thief will just break in anyway.
MBAM, SCCM and AD are useful but, if a machine is bitlocker encrypted and is asking for the key, you still need to type it in manually. This isn't a resolution but an alternate place to store those keys. Again, a non-argument of "my way is better".
