
Equifax blames open-source software for its massive security breach, Really? - CrankyBear
http://www.zdnet.com/article/equifax-blames-open-source-software-for-its-record-breaking-security-breach/
======
tptacek
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.

~~~
fencepost
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.

~~~
tptacek
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.

------
mediocrejoker
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"

~~~
benmowa
wow

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

------
bhouston
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.

------
imglorp
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.

~~~
Overtonwindow
Burbclaves

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

------
BigChiefSmokem
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?

~~~
derekp7
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.

------
snowwolf
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.

------
richij
Wow. Just wow

