Slashdot Mirror
After Equifax Breach, Major Firms Still Rely on Same Flawed Software (zdnet.com)
Last year's massive data breach at Equifax should have been a wake-up call for the entire industry. But a year after the patches were released, some of the world's wealthiest companies are still using, or have since introduced the same flawed software. From a report: Thousands of companies have downloaded vulnerable versions of Apache Struts, a popular web server software used across the Fortune 100 to provide web applications in Java. It's often used to power both front- and back-end applications -- including Equifax's public website. The bug used in the Equifax hack was fixed in March 2017, but Equifax never installed the patches. Since those patches were made available, data seen by ZDNet shows that least 10,800 companies downloaded vulnerable versions of the software. The data, provided by Sonatype, an open-source automation firm, shows that over half of the Fortune Global 100 are using vulnerable versions of the software. Although the firm wouldn't name the affected companies, a quarter of them are based in North America. The data showed that seven are tech giants, and 15 are financial services or insurance firms.
A data breach may cost money later, but changing would cost money now, which is all stock holders care about.
"Have you ever thought about just turning off the TV, sitting down with your kids, and hitting them?"
This behavior is very logical. Equifax got away with gross negligence in the area of data security. It follows that expenditures on data security can be minimized. Updates and technical expertise costs money, market-driven approach would be to keep already paid-for systems in place and outsource maintenance of these old systems to the lowest bidder.
How many Equifax executives have gone to prison?
Put them in chains, and other executives might notice.
One problem is that companies continue to run software that was built as a one-off by some consulting company, offshore vendor or similar. They either don't exist anymore, or want millions to even look at the code again.Those packages need these out-of-date frameworks and other software as dependencies, and the company doesn't have the expertise in-house to know whether a patch will break something. In my line of work, the main offender is awful Java thick client applications, and these often require a _specific_ point release of some horribly outdated JRE/JDK. But JEE web apps are even worse in this regard...and despite the hype around app-of-the-month, there are TONS of these systems from the 2000s floating around in big companies.
Consulting companies should be required to at least hand over the source code for software they produce if they're not interested in maintaining it long-term as an actual product. And if a company is relying on some system as a dependency, they shouldn't allow their vendors to walk away without fully understanding what they've left running on their systems.
(or some other ill-conceived and bloated atrocity that will never receive security updates because they cost too much money)
Was this flawed software deemed "non-complaint" by a government regulatory body of some sort after the Equifax breach?
No?
Well, then, why the hell would you expect things to change? The financial sector isn't going to do anything that costs money or time that doesn't personally benefit them unless you force them to.
faa level code audits cost way to much to do. and also why should the 1099 or H1B risk being fired / kicked out by not signing off.
All they showed was how many downloads, not how many implementations. I'm sure my company has downloaded a copy of the software too, we use local copies of various repos. We don't use Struts anywhere, we just prefer to maintain local repos.
This posting is provided 'AS IS' without warranty of any kind, implied or otherwise.
Note that a lot of these top-100 companies is chock full of outdated closed source software too.
On a recent random check of a few laptops from one of those sorts of companies, the average was about 2 years since they last received any update whatsoever from Microsoft (their update mechanism had broken and they had no reporting about it). I was working with another company and they were intentionally using a commercial product from a company that went out of business 15 years ago, because it would be too much trouble to migrate off.
Here the open/closed doesn't matter, either way they are terrible at software currency.
XML is like violence. If it doesn't solve the problem, use more.
I share the thought that those downloads do not *necessarily* mean the company deployed insecure software, but to say that 'most of these companies' are patching the security issues is way too optimistic. Sure some, but most are completely oblivious.
XML is like violence. If it doesn't solve the problem, use more.
> C level people rarely understand technology enough to properly communicate the risk and benefit of security. It just isn't typically in their wheel house.
I just left a meeting with the CEO of our security company in which we discussed how to solve this. Heck, even the technical C people, like a CIO of a major company, are busy with many different things - desktops, network, on-premise servers, cloud .... They don't have time to really understand each of the vulnerabilities that comes out every day.
They need the security experts to tell them the bottom line "how secure are we?", "What are the top five things we need to do to reduce our risk?" and "what is the value proposition, the financials?"
What it lost was money, right? And who lost it? The shareholders.
All bonuses and pay all these executives wee gorging themselves in, was not clawed back. They did not go to jail. They paid the fines and compensation using shareholder's money.
Why would they change?
Why would you expect them to change?
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
"And don't give me the usual "but the vulnerabilities were fixed before the hack happened!""
So ignore the truth, check.
Sorry, teleporters just kill you and then make a copy. A perfect, soul-less copy.
Maybe you should read up on WebSphere and figure out why these huge enterprises may be all mysteriously holding onto an ancient and buggy fork of an open source project.
Shills be shillin'