Also mis-mentioned, is that I heard nothing was "missed" but security upgrades were not possible due to the age of the stack.
Pre-0 days are one thing. But leaving systems unpatched for months, because your stack is too old, is a common, but inexcusable theme.
This is why it is vital to use libraries, frameworks, with a stable, unchanging LTS branch. Failure to do so, means a security update that needs to be applied instantly, cannot be done, without extensive app changes.
New shiny is fine. But it must never, ever override basic security concerns.
> This is why it is vital to use libraries, frameworks, with a stable, unchanging LTS branch. Failure to do so, means a security update that needs to be applied instantly, cannot be done, without extensive app changes.
It's also another reason why it's important to provide such things.
It's amazing to me how many people seriously argue it's fine to aggressively drop support for old versions and old features to focus on the newest stuff (and that it's totally fine for table-stakes of "having software" is to have engineers continuously working to keep up with changing dependencies.
The reality is the cheapest thing for society is to offer very long term support for old versions, even if it's just security patches, or well-tested backwards-compatibly features in newer versions. It's not sexy work, but it's important.
But such things do exist, you just have to vet things first.
For example, stick to a non-rolling distro, such as debia n stable. Everything there will have around 3 years support, with all the security updates done for you.
Debian backports almost all security patches, or sticks with an LTS variant of something (like php) for its lifetime.
No surprise API changes, no sudden need for code changes.
So many people use the latest shiny, and literally only because they're told to. Many need nothing from that bleeding edge version.
When it comes to frameworks, some have LTS versions, stick with those.
What's happening, is companies are doing a risk assessment, and thinking "well, it probably won't be hacked, we don't need to replace this with something that is auditable, and secure".
That needs to 100% end. There are also cases where companies think, "Well, it will take use 3 weeks to update this stack, we'll leave the old, vulnerable code online for that 3 weeks, plus testing, and plus (of course) push, so 2 months, even though this is a very easily exploitable, high profile CVE".
That too needs to end.
The only way that can end, is if fines are WELL beyond any possible savings, including being 100s of times more than those savings, so that companies will TREMBLE IN FEAR at the very idea of leaving unpatched servers online. Your stack will take 2 months + testing to upgrade?
Because you chose a stack without an easy way to upgrade instantly?
then you take your stack offline, and tough if it bankrupts you.
Because otherwise, we'll fine the company dry, and its directors, and jail the CTO, and the employees who knew.
"They routed traffic through approximately 34 servers located in nearly 20 countries to obfuscate their true location, used encrypted communication channels within Equifax’s network to blend in with normal network activity, and deleted compressed files and wiped log files on a daily basis in an effort to eliminate records of their activity."
I wonder how they managed to figure that out. Did they have to look into each of the servers?
They had months to work at it. Due to Equifax's incompetence.
It should be noted, the "official" report is what investigators have been told, not what really happened behind the scenes. Naturally Equifax and its employees tried to play the poor, innocent, helpless corp, with those dastardly hackers almost mysteriously getting in.
Thanks, might be my misunderstanding but I was trying to figure out how the investigators managed to figure out. Feels like the only sure way is from a leak from China, but theoretically they can also track all those servers.
The whole attack/investigation is super fascinating.
The initial vulnerability was in the "modern" web application that fronted the legacy mainframe application. It was completely patchable, but was missed as described in the article.
Pre-0 days are one thing. But leaving systems unpatched for months, because your stack is too old, is a common, but inexcusable theme.
This is why it is vital to use libraries, frameworks, with a stable, unchanging LTS branch. Failure to do so, means a security update that needs to be applied instantly, cannot be done, without extensive app changes.
New shiny is fine. But it must never, ever override basic security concerns.
Security comes first. Not last. Always.