What do Boeing, an Australian shipping company, the world's largest bank, and one of the world's biggest law firms have in common? All four have suffered cybersecurity breaches, most likely at the hands of teenage hackers, after failing to patch a critical vulnerability that security experts have warned of for more than a month, according to a post published Monday.
[...] All four companies have confirmed succumbing to security incidents in recent days, and China's ICBC has reportedly paid an undisclosed ransom in exchange for encryption keys to data that has been unavailable ever since.
[...] After the CitrixBleed exploit grants initial remote access through software known as Virtual Desktop Infrastructure, LockBit escalates its access to other parts of the compromised network using tools such as Atera, which provides interactive PowerShell interfaces that don't trigger antivirus or endpoint detection alerts. This access remains even after CitrixBleed is patched unless administrators take special actions.
(Score: 5, Interesting) by Thexalon on Friday November 17 2023, @11:58PM (1 child)
Here's how I tend to look at it, which has nothing to do with "all bugs are shallow to somebody" and everything to do with "what resources can you use to address the problem".
Let's compare the situations of CTO A running the proprietary MacroHard W, and CTO B running the FLOSS X that does basically the same thing. And a serious 0-day bug is discovered for both of them at the same time that's being actively exploited in the wild.
CTO A's options:
1. Wait for MacroHard to distribute an update for W, and install it as quickly as possible.
CTO B's options:
1. Wait for literally anybody else (who may or may not be connected to the maintainers of X) to put a patch out somewhere on the Internet, and install the patch as quickly as possible.
2. Direct any in-house software developers they might have to try to create a patch themselves.
3. Direct any in-house admins they might have to try to create some kind of clever workaround for the problem, because they have access to all the components and documentation to tinker with things.
4. Hire an outside developer, e.g. somebody who has contributed to the system at some point (which conveniently is public information, just look in the git history), to develop a patch for it.
5. Hire an outside admin to create the clever workaround for the problem that the in-house admins didn't think of.
6. Organize some sort of multi-organization cooperative effort with everybody else who is facing the exact same problem.
etc etc etc.
Oh, and if your guys fix it first, you can publicize the fix and get some nice publicity from that.
So CTO A might have the advantage of being able to blame everything on MacroHard, but CTO B has lots of avenues for fixing the damn problem that CTO A doesn't. These also apply to situations like:
- The upstream abandons the software, for whatever reason.
- There's a feature that would be really useful for you to have, and isn't currently part of the software.
- There's a non-security bug that's still really friggin' annoying.
I'd rather be CTO B in all of these scenarios. But again, I approach technical problems like an engineer, not a politician, which means I want to actually fix them and not just send the blame somewhere else.
"Think of how stupid the average person is. Then realize half of 'em are stupider than that." - George Carlin
(Score: 2) by Freeman on Monday November 20 2023, @04:14PM
CTO A is why we switched from a proprietary Integrated Library System (book Library). To an open source ILS (Koha). There were a few other options, but we'd already had experience with Koha. So far, we're quite happy.
Joshua 1:9 "Be strong and of a good courage; be not afraid, neither be thou dismayed: for the Lord thy God is with thee"