61–70 of 104 posts
Earlier quoted context omitted.
Who would trust that?
your employer's IT department
It is even more likely that IT was at loggerheads with cyber, but nowadays cyber seems to be able to trump everything and everyone.
Earlier quoted context omitted.
Just a small reminder that's it's never "the guy" and always "the process", or lack thereof.
Yeah, but heads will have to roll for this one, the world will be calling for blood, so who better if not "the guy"?
One analogy is rounding - one rounding makes no difference to a transaction, but multiple systems rounding the same direction can have a large scale impact. It's not always rounding money - it can be error handling. A stops at the error, B goes on, turns out they're not in sync.
Which guy is it? The person who pressed the button? The manager who gave that person more than one task that day? The people who didn't sufficiently test the detection process? The people who wrote the specs without sufficient understanding of the full impact? The person who decided to layoff the people who knew the impact three months ago?
Earlier quoted context omitted.
the management that enabled the process. And follow the chain to the top, they are paid very well to own the risks
It’s both. If you’re an engineer and you push out shitty code that takes down 911 systems and ambulances, you f’ed up. Push back against processes that cause harm, or have the potential to cause harm. You are ultimately responsible for your actions. No one else. The excuse of “I was just following orders” has been dead and buried since WW2. Yeah, ideally management should know better. But management aren’t usually en…
This is wrong. If a company is developing that kind of software is the responsibility of the company to provide a certain level of QA before they release software. And no, it's not that "engineers are pushing out shitty code", but that the shitty company allows shitty code to be deployed in customers' machines.
Earlier quoted context omitted.
The Linux version of CS sensor defaults to being installed as a kernel module as well.
Who would trust that?
It provides the electrolytes Windows craves.
Wouldn't want to be the guy who pushed this particular commit. It's ironic that the company that is supposed to prevent this sort of thing causes the biggest worldwide outage ever. Crowdstrike is finished. Let's hope this will result in at least a small increase in desktop Linux market share.
Just a small reminder that's it's never "the guy" and always "the process", or lack thereof.
Wouldn't want to be the guy who pushed this particular commit. It's ironic that the company that is supposed to prevent this sort of thing causes the biggest worldwide outage ever. Crowdstrike is finished. Let's hope this will result in at least a small increase in desktop Linux market share.
Wouldn't want to be the guy who pushed this particular commit. It's ironic that the company that is supposed to prevent this sort of thing causes the biggest worldwide outage ever. Crowdstrike is finished. Let's hope this will result in at least a small increase in desktop Linux market share.
Why the fuck didn't MSFT just do blue/green canarying? No update should be rolled out to a billion devices at once until it's baked in a million devices for a bit, and that only after baking in 10,000 devices for a bit.
It's a crowdstrike update file with a bug in it, from what I gather. This makes your Windows machine go blue screen and stop working as it starts up. If you manage to remove it by various methods, it doesn't run and you're fine. More informed people will give you more details, but this kind of AV software often has privileged access to the OS, so it can scan your files. The same privileged access also means it can re…
The "if they want to" part is the difference, kernel drivers can easily cause BSoDs on accident, e.g. by writing to an invalid address, normal processes can't, they have to jump through hoops by choice.