this post was submitted on 19 Jul 2024
631 points (98.5% liked)
Technology
60082 readers
3268 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related content.
- Be excellent to each another!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, to ask if your bot can be added please contact us.
- Check for duplicates before posting, duplicates may be removed
Approved Bots
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Someone never tested their DR plans, if they even have them. Generally locking your keys inside the car is not a good idea.
I remember a few career changes ago, I was a back room kid working for an MSP.
One day I get an email to build a computer for the company, cheap as hell. Basically just enough to boot Windows 7.
I was to build it, put it online long enough to get all of the drivers installed, and then set it up in the server room, as physically far away from any network ports as possible. IIRC I was even given an IO shield that physically covered the network port for after it updated.
It was our air-gapped encryption key backup.
I feel like that shitty company was somehow prepared for this better than some of these companies today. In fact, I wonder if that computer is still running somewhere and just saved someone’s ass.
The good news is! This is a shake out test and they're going to update those playbooks
Sysadmins are lucky it wasn't malware this time. Next time could be a lot worse than just a kernel driver with a crash bug.
3rd party companies really shouldn't have access to ship out kernel drivers to millions of computers like this.
I wish you were right. I really wish you were. I don't think you are. I'm not trying to be a contrarian but I don't think for a large number of organizations that this is the case.
For what it's worth I truly hope that I'm 100% incorrect and everybody learns from this bullshit but that may not be the case.
The bad news is that the next incident will be something else they haven't thought about
We also backup our bitlocker keys with our RMM solution for this very reason.
I hope that system doesn't have any dependencies on the systems it's protecting (auth, mfa).
It's outside the primary failure domain.
I get storing bitlocker keys in AD, but as a net admin and not a server admin....what do you do with the DCs keys? USB storage in a sealed envelope in a safe (or at worst, locked file cabinet drawer in the IT managers office)?
Or do people forego running bitlocker on servers since encrypting data-at-rest can be compensated by physical security in the data center?
Or DCs run on SEDs?
When I set it up at one company, the recovery keys were printed out and kept separately.
Paper print in a safe is what's usual done.
You need at least two copies in two different places - places that will not burn down/explode/flood/collapse/be locked down by the police at the same time.
An enterprise is going to be commissioning new computers or reformatting existing ones at least once per day. This means the bitlocker key list would need printouts at least every day in two places.
Given the above, it's easy to see that this process will fail from time to time, in ways like accicentally leaking a document with all these keys.
I think the idea is to store most of the keys in AD. Then you just have to worry about restoring your DCs.
I think that's a better plan than physically printing keys. I'd also want to save the keys in another format somewhere - perhaps using a small script to export them into a safe store in the cloud or a box I control somewhere
They also don't seem to have a process for testing updates like these...?
This seems like showing some really shitty testing practices at a ton of IT departments.
Apparently from what I was reading these are forced updates from Crowdstrike, you don't have a choice.
I've heard differently. But if it's true, that should have been a non-starter for the product for exactly reasons like this. This is basic stuff.
Companies use crowdstrike so they don't need internal cybersecurity. Not having automatic updates for new cyber threats sorta defeats the purpose of outsourcing cybersecurity.
Automatic updates should still have risk mitigation in place, and the outage didn't only affect small businesses with no cyber security capability. Outsourcing does not mean closing your eyes and letting the third party do whatever they want.
It shouldn't, but when the decisions are made by bean counters and not people with security knowledge things like this can easily (and frequently) happen.
Not bothering doing basic, minimal testing - and other mitigation processes - before rolling out updates is absolutely terrible policy.
Unfortunately, the pace of attack development doesn't really give much time for testing.
More time that the zero time than companies appear to have invested here.
I was just thinking about something similar. I can understand wanting to get a security update as quickly as possible, but it still seems like some kind of rolling update could have mitigated something like this. When I say rolling, I mean for example split all of your customers into 24 groups and push the update once an hour to another group. If it causes a massive fuck up it's only some or most, but not all.
Heck even 30 minutes ahead for 1% of devices wouldve had a reasonable chance of catching this