Equifax blames open-source software for its massive security breach, Really? | Hacker News Reader

Equifax blames open-source software for its massive security breach, Really?

zdnet.com

31 pointsCrankyBear16 comments

This is clickbait. In 2017, most major breaches will trace back one way or another to open source software, simply because open source software dominates the serverside software market.

Pointing out that patient zero in a breach was a server running Struts is, obviously, not the same thing as "blaming open source". ZDNet just wants it to be, so that they can get their share of clicks for a story they've done no real reporting on.

Clickbait perhaps, but also tech press noting that if it was a Struts problem then it was either a 0-day when it happened or it happened months after a patch was made available and widely publicized.

Doesn't matter. The "zero day" thing is a red herring. If you operate a business like Equifax, technically you're responsible for infrastructure vulnerabilities whether they're known or not. You assume your app servers could get compromised by an unknown vulnerability; you design your applications to minimize attack surface to reduce your risk, and then build in layers of controls and additional defenses to mitigate the impact of such a vulnerability.

Nobody Fortune 500 company besides Google, Microsoft, Facebook and Apple really does this effectively (and even then, the track record isn't great). But that doesn't change anything about the analysis.

Did you read the story? While all the other reports were saying "Struts was the problem," this story states that this claim was highly dubious and why it was questionable.

Please don't insinuate that someone hasn't read an article. "Did you even read the article? It mentions that" can be shortened to "The article mentions that."

https://news.ycombinator.com/newsguidelines.html

I think a more accurate headline would be "NYPost claims that a non-technical source at Equifax blames open source software for its massive security breach"

wow

>According to an unsubstantiated report ... citing no evidence... The firm's source.....is believed to be Equifax.

Well, it probably was some open source software because they probably run Ubuntu/Linux, or MongoDB or MySQL etc. Probably misconfigured. But this is blaming tools rather than people and their own security team.

Many companies successfully run very secure large scale operations on open source, specifically Google.

I blame the public roads when I get robbed. I mean, without those, how would the robbers get to my house? I think everyone should have a private, security patrolled road to their house.

Burbclaves

It's time for the Equifax CTO to collect a few million $ bonus check and then leave for "new challenges".

That's an interesting turn of events. I was always told to use open source because it is safer (due to it being available publicly and all), but is it really safer to expose every bit of detail to all gov, grey, white and would-be black hats? I have been told this is true ever since the dotcom boom but the elevated state of global hacking now has had me double guessing that assumption.

But let's be honest here, the only other large-scale "trusted" enterprise vendors are Microsoft and Oracle and their developers are getting to be way more expensive than a typical "open-source developer". And do we really want to trust those who already betrayed us way back when?

So what are the probable solutions here? Most niche (and sometimes widely-used) open-source libraries are notoriously buggy, lack documentation, and usually don't have more than a few real contributors. Hybrid model perhaps? But what does that really mean?

Have there ever been exploits in closed source software, including 0-day exploits? Most definitely. So you would want to use the highest quality software you can for a given purpose, but even that isn't enough. In reality, the answer is defense in layers.

First layer -- if you are running on RedHat or CentOS, make sure to have SElinux in enforcing mode, and resolve any SElinux errors the correct way.

Second layer -- separation of concerns. The same way that many businesses accounting operations are set up, you need to have a security breach at several layers at the same time to have an issue.

This may mean that having the public facing web server talk to an app on an internal server, using a defined API, and that internal server only has firewall rules open for what is required.

That internal app server then may have access to a database server in another security zone, making requests utilizing specific API patterns. At each level, have auditing software to look if any of those patterns change unexpectedly. Also, rate-limit the amount of data that can be pulled from the DB server on a daily basis -- this would mitigate a massive data dump situation.

You could go even further, and have the web-facing side talk to an internal web server, after going through a layer that validates each request fits a given pattern. Of course this is a pain to keep updated as the app gets updated, but then again when the consequences of a security breach are high enough, this level of pain is worth it.

The closed-source model is essentially security through obscurity, which has been rightfully and thoroughly debunked as a legitimate practice. The right solution is to use the right tools for the job - which is often open source, but that doesn't mean using it blindly and not taking responsibility for it, and actively keeping up to date with exploits and patches.

I think the most likely explanations are that the hackers either exploited an unpatched application using Apache Struts or exploited a SQL injection vulnerability in an application using Apache Struts.

Wow. Just wow

Reply on news.ycombinator.com