Equifax Blames Open-Source Software For Its Record-Breaking Security Breach (zdnet.com)

A poor carpenter... by Ritz_Just_Ritz · 2017-09-11 10:04 · Score: 5, Funny

Always blames his tools.

Re:A poor carpenter... by jellomizer · 2017-09-11 10:21 · Score: 2

However there is a problem with being too aggressive.
Proper Security it tough, if you are going to be 100% secure then chances are you will not be able to perform your business. However there needs to be rules to make sure the company is putting in its best effort into security. If we find that there was a someone who tried to raise flags about security, where management declined because it was too expensive then there should be repercussion. But if there are reasonable checks in place, you shouldn't kill the company just because there was a flaw.
If your job is a Software Developer or some sort of engineer. Even if you are an ace at your job. Chances are you could had made a mistake, do you think you deserve to have your life and career killed, because of one bad day.

--
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
Re:A poor carpenter... by chispito · 2017-09-11 10:23 · Score: 1

Always blames his tools.
In that incomplete analogy, I think a web framework is more analogous to materials than tools.

--
The Daddy casts sleep on the Baby. The Baby resists!
Re:A poor carpenter... by ScienceofSpock · 2017-09-11 10:54 · Score: 5, Insightful

In the financial sector, proper security is THE most important thing. If you are offering services and you cannot secure your customer's data absolutely, then you shouldn't be offering services.
If proper security is "too expensive" for your profit margin, then you have a failed business model, and shouldn't be offering services.
Financial institutions KNOW this. This is the business they choose to be in, it has a high operating cost and they get paid VERY well to perform these services. They shouldn't be let off the hook for taking the cheap way out, and they certainly shouldn't be allowed to profit from these tactics. They only understand money. The only way to punish these institutions when they do stupid shit like this is to hit them hard in the purse.
Re:A poor carpenter... by TWX · 2017-09-11 11:14 · Score: 1

This breach is bad enough that Equifax officers should see significant jailtime.

--
Do not look into laser with remaining eye.
Re:A poor carpenter... by Desler · 2017-09-11 11:27 · Score: 2

And a good carpenter can spot when a tool is gimmicky shit or poorly made. Every tool is not a good tool.
Re:A poor carpenter... by Mad+Merlin · 2017-09-11 11:38 · Score: 2, Insightful

Proper Security it tough, if you are going to be 100% secure then chances are you will not be able to perform your business.
There's no such thing as 100% secure, and there never will be.
Even if you use a one time pad for encryption (which if implemented perfectly, is unbreakable from a ciphertext analysis perspective), it can still be broken in a multitude of other ways (flawed/predictable RNG for generating the pad, (accidental) pad reuse, a wrench, etc). Plus, the practicality of actually deploying one time pad encryption properly is so cumbersome that it's pretty much unused.
Perfectly implemented one time pads aside, if you had an infinitely fast computer, you could break every known encryption algorithm and decrypt every encrypted transmission ever sent. While we don't have infinitely fast computers (yet), the performance delta between a computer today and a computer 20 years ago is practically infinite. Similarly, the performance delta between your $300 laptop and a determined state level attacker or large botnet is rapidly approaching infinite.
There's far more to security than just encryption, but the basic tradeoff involved in encryption (how much computing power do I need to spend to make it relatively impractical for an adversary to brute force a decryption within $x timeframe) mirrors most security topics well.

--
Game! - Where the stick is mightier than the sword!
Re: A poor carpenter... by Anonymous Coward · 2017-09-11 13:36 · Score: 1

There is no such thing as an infinetfly fast computer either. anything made of matter is limited by the constraints of our universe. unless of course your suggesting were not far from making computers from something other then matter.
a themodynamically perfect computer that used a Dyson sphere surrounding our sun and used 100 percent of the sun's energy output would still be incapable of brute forcing today's encryption in any meaningful timeframe.
what I believe your overlooking is the actual scale of the number sets used in today's encryption. they are for all intents and purposes infinitely large.
let me put it into perspective. if you had this thermodynamically perfect computer and tried to count... just count.. no hashing.. no comparison... the sha256 number set for example, the sun your using to power your computer would run out long before you were even close.
of course weaknesses in rng or the algrythm itself may be flawed but attacking todays cryptography in a brute force manner is not possible.
quantum computer / classical computer. doesn't matter at all. it's just not possible !
Re:A poor carpenter... by Xest · 2017-09-11 18:58 · Score: 4, Insightful

"If you are offering services and you cannot secure your customer's data absolutely, then you shouldn't be offering services."
This is absolute drivel, there's no such thing as absolute security. The choice you're offering therefore is to simply not do business at all, or to hire people who don't understand security sufficiently to falsely believe they have absolute security rather than people who understand absolute security is non-existent and that it's simply a measure of risk.
"If proper security is "too expensive" for your profit margin, then you have a failed business model, and shouldn't be offering services."
Again, nonsense. As absolute security is a myth then you're basically saying every business model in the world ever has failed and every company should shut down. That's complete and utter nonsense, obviously.
You've not considered another possibility - that Equifax actually did the best they could and it just wasn't good enough. Given that all security can be compromised given sufficient effort this could simply be a case of them falling foul of measured risk.
That also might not be the case, it might also turn out to be absolute incompetence of course, but until we have more details we simply do not know. The summary pre-supposes they were victim to an old known exploit and not a recently publicised zero day - it's possible that the recently publicised zero day was in fact discovered precisely because of this hack for all we know - the idea that it was an old unpatched vulnerability is entirely speculation right now.
We just don't know how much blame they deserve right now. What I personally know is that it's hard to recruit good security professionals precisely because those who truly understand security often don't want to touch it precisely because they know there's always a chance someone determined could breach security. What I do know is that as a result of this most the industry is full of people parroting the myth you have of being able to implement absolute security and as a result creating a false sense of security.
Stop it. It's not helpful, it just puts you in the same basket as all those in the industry who peddle the myth and create the problem in the first place. I'd take someone who accepts that there's always a risk, but is honest about to what extent they believe they've been able to mitigate it, and then give them a waiver from blame if something happens any day over someone like you that pretends they can implement perfect security. But because people like you exist peddling the myth we instead find ourselves with an industry full of you, and we find ourselves with problems like this happening time and time again.
We need to accept that security is always imperfect, and we need to start blaming only on relative effort applied to try and make the system secure - if someone took reasonable measures and still got fucked we need to accept that that's an inevitable consequence of the fact that absolute security doesn't exist, and that therefore due to simple statistics even some of the most fortified companies will inevitably be hit.
So wait until we have the facts before assuming they did much wrong.
Re:A poor carpenter... by TheRaven64 · 2017-09-11 19:46 · Score: 3, Insightful

the performance delta between a computer today and a computer 20 years ago is practically infinite
No it isn't, it's finite and it's a predictable number that is factored into the design of crypto systems. You assume that performance doubles roughly every year (a bit faster than Moore's law, but this factors in changes like GPUs / DSPs / FPGAs becoming cheap). For a symmetric crypto algorithm, adding one bit to the key length doubles the computational cost of attacking it, so if you want your data to be secure in 20 years than you work out how long it would take to crack it today and add 20 bits. Adding 20 bits is a bit awkward, so you round up to the nearest power of two.
Occasionally you make the jump sooner. A lot of things moved from 128-bit AES to 256-bit AES, because it turns out that 256-bit AES is faster. Magical quantum computers aside, that gives an extra century or so before any of these can be cracked (ignoring weaknesses in the implementation, which are how most of these things are broken).

--
I am TheRaven on Soylent News
Re:A poor carpenter... by Cederic · 2017-09-11 20:05 · Score: 4, Insightful

Overall I agree with everything you've said, but one thing to add.

it's hard to recruit good security professionals precisely because those who truly understand security often don't want to touch it precisely because they know there's always a chance someone determined could breach security
You will suffer data loss. Assume that, plan for it, understand how to detect and mitigate it.
Given the impossibility of perfect security it would be naive to do anything else, no matter how great (and well resourced) your data security is.
Re:A poor carpenter... by Cederic · 2017-09-11 20:09 · Score: 2

If we find that there was a someone who tried to raise flags about security, where management declined because it was too expensive then there should be repercussion.
Be realistic. It's always possible to add an additional security measure, and there are rapidly diminishing returns.
Security is a risk based domain, and sometimes it's appropriate to take the risk.
Re:A poor carpenter... by Big+Hairy+Ian · 2017-09-11 23:26 · Score: 1

Was Equifax's security breached before or after the security flaws in Struts were made public?
I can understand them blaming Struts if they were hacked before they knew the tool had been compromised but if it was after then then it's their own stupid fault for not patching a known security issue.

--
Build a Man a Fire, and He'll Be Warm for a Day. Set a Man on Fire, and He'll Be Warm for the Rest of His Life.
Re:A poor carpenter... by Bengie · 2017-09-12 00:31 · Score: 1

I hate it when programmers blame the libraries they use. Never write a line of code or use a library unless you know what it's doing and how it's doing it. When I use a library, I'm hitting up github and reading their code.
Re:A poor carpenter... by TheRaven64 · 2017-09-12 00:44 · Score: 2

Only if you correctly salt them (i.e. a different salt for each one). SSNs are 9-digit numbers. That's about a 30 bit search space. It's possible to generate a rainbow table for MD5s of all possible SSNs very quickly and store it in memory on a moderately powerful system.

--
I am TheRaven on Soylent News
Re:A poor carpenter... by AmiMoJo · 2017-09-12 00:45 · Score: 3, Interesting

Equifax's service isn't based on providing reliable information or securing that information. It's based on fulfilling a legal requirement to mitigate risk when evaluating potential customers for loans.
They really don't care if they information they have is accurate, let alone secure. You are not their customer, they don't care what happens to you. All they care about is charging companies for read/write access to your file.

--
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
Re:A poor carpenter... by jbmartin6 · 2017-09-12 00:56 · Score: 1

Equifax isn't a financial company, they are a data aggregator. And their customer's data was not affected, it was possibly (still unconfirmed) the people on whom data had been collected. You and I are not Equifax customers (except for some side chiseling on various monitoring services) the lenders et al which use Equifax data are their customers.

--
This posting is provided 'AS IS' without warranty of any kind, implied or otherwise.
Re:A poor carpenter... by parkinglot777 · 2017-09-12 01:27 · Score: 1

You've not considered another possibility - that Equifax actually did the best they could and it just wasn't good enough. Given that all security can be compromised given sufficient effort this could simply be a case of them falling foul of measured risk.
I agreed that there is no perfect security and it is impossible to have absolute security especially when time goes by. However, I disagree with your opinion that their "best" is no where near up-to-par. To me, it seems that many Americans think "good enough" is what they aim for in everything. That is unacceptable to me. Especially, it should at least be "good" or "excellent" and not "good enough". If the quality is "good enough", then there will be many of this kind of situations occur over and over again.
As TFA already pointed out, the way they handled their mistake demonstrated how amateur they are -- domain name and the page content of their support look like a phishing site. Though, one non-obvious thing on the site, when you want to check if you are affected by the breach, is the digital contract you have to agree that you will give up your legal right to take them to court. It makes me wonder how competent they are in handling any thing besides protecting themselves.
I understand why you want to forgive them for what they did. However, i do believe and agreed with GP that a hash punishment needs to be put on them in order to give an example/precedence to others that they need to be more careful and ponder more on what they are doing, not how much profit margin they can increase. Even though there is no perfect security, it does not mean people should let go a mistake of others that directly impact them every time a mistake happens, especially with this kind of mistake which has a huge impact on the whole nation. Some mistakes need to be straighten out to ensure that there wouldn't be another later on (including from anyone else). I understand that too many punishments would discourage others to act; however, too much forgiveness will also spoil the ones that are forgiven. I do believe that something needs to be done to put an end of this kind of carelessness.
Re:A poor carpenter... by angel'o'sphere · 2017-09-12 01:49 · Score: 1

This is absolute drivel, there's no such thing as absolute security.
On the mere level of a web site, there most definitely is!
Making software secure is not trivial but also not impossible.
If you mean with "totally secure" that a ninja could break into the data hosting facility and steal unencrypted harddisks or install network sniffers, yes, then you have a point.
How ever as we all understand here that data breach was a simple software "problem" which could have been prevented with proper design, reviews etc.

--
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Re:A poor carpenter... by Xest · 2017-09-12 02:31 · Score: 1

Sure but that's my point - people who understand security such that they understand that data loss is always going to be a risk don't want to put themselves in that kind of role in the first place because when it happens they know they'll be in the firing line.
Hence, the people that do the job are the people naive enough to think they can implement absolute security. This is why all too many security departments are staffed by people who are themselves a risk because they do not recognise, and hence do not plan for the risk.
Re:A poor carpenter... by Xest · 2017-09-12 02:51 · Score: 1

"However, I disagree with your opinion that their "best" is no where near up-to-par. To me, it seems that many Americans think "good enough" is what they aim for in everything. That is unacceptable to me. Especially, it should at least be "good" or "excellent" and not "good enough". If the quality is "good enough", then there will be many of this kind of situations occur over and over again."
But that's really my point - you have no idea what their best is, you just know that something happened that you don't like, but the pragmatic reality of IT security is that as absolute security is a myth, something can always go wrong even if you've done everything absolutely right, and until it's clear they haven't, it's not entirely fair to assume they have.
It's possible that they were fulfilling your definition of good or excellent and still got screwed, but until we know what happened you have no frame of reference as to how good their procedures were.
It's actually in my interest that they did screw up as that harms them more as a business and I work for a competitor, however I'm trying to make a broader point here that I think we need to stop pretending that any company that got hacked was entirely to blame and could've avoided it by pouring more money in - that's not necessarily the case because as I say, the myth of absolute security in IT coupled with numbers alone means it's inherently going to be the case that sometimes organisations or individuals that get hacked simply just got unlucky - as Cederic said in response to my other post, you have to secure against it as best you can, but you also have to plan for it happening too, it looks like Equifax didn't do the latter at least based on their poor response and can rightly be criticised for that, but whether they did the former is still an unknown.
Re:A poor carpenter... by Xest · 2017-09-12 02:55 · Score: 1

You can never guarantee that someone wont find a zero day somewhere in your hardware and software stack that you simply could not prevent without full and 100% accurate auditing of the entire hardware and software stack, something, which to date, has never yet once been achieved for reasons ranging from use of proprietary non-open hardware and software, through to simple sheer complexity of modern software. Even if you use a full FOSS stack you can't guarantee that people have prevented each and every possible vulnerability, which is why Heartbleed was present for so long hiding in plain sight.
If you believe you can absolutely secure a system then you're one of the people I mentioned in my previous post who are dangerous because your understanding of security is insufficient to know why your systems are always going to have an element of risk present.
Re:A poor carpenter... by angel'o'sphere · 2017-09-12 03:14 · Score: 1

And you can not guarantee, that software always has a zero day exploit hidden.
10 PRINT "HELLO WORLD!"
20 GOTO 10
I doubt there is a zero day exploit hidden ... but well, the PRINT implantation could have a bug, but as long as you only print literal text ... what could happen?
So, you gave the solution to your claims already in your explanation: "full and 100% accurate auditing of the entire hardware and software stack", that is what you do, if you want a secure system.
Your parent is perfectly right: if you can not afford that, you have the wrong business model.
your systems are always going to have an element of risk present.
As soon as the are completely secured: no.

--
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Re:A poor carpenter... by david_thornley · 2017-09-12 04:43 · Score: 1

So, you're advocating for imprisonment on the basis that there was a breach? We don't know anything significant about the breach or Equifax security. If the security was remiss, that's one thing. If they put real work into security and were vulnerable to a flaw they had no reason to think existing, that's another.
If we imprison security people for being outsmarted, we're not going to have anybody working in computer security.

--
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
Re:A poor carpenter... by parkinglot777 · 2017-09-12 05:40 · Score: 1

It's possible that they were fulfilling your definition of good or excellent and still got screwed, but until we know what happened you have no frame of reference as to how good their procedures were.
Well, no that what they (Equifax) think that their fulfillment is good or excellent, but what they were doing was just good enough (if not worse). What you said is not determined by their clients (us) side. On the other hand, many of Americans, in general, accept the good enough work quality which is also not a really good way of dealing with security work in this case.
Re:A poor carpenter... by JackieBrown · 2017-09-12 08:54 · Score: 1

This breach is bad enough that Equifax officers should see significant jailtime.
Why not IT as well? I mean, if we are going that route, than sure you would hold the people who know the technical side most liable. If someone asks me to break the law at my job, I wouldn't do it to save said job.
Re:A poor carpenter... by JackieBrown · 2017-09-12 08:55 · Score: 1

So, you're advocating for imprisonment on the basis that there was a breach?

These are the same folks who in another threads complain about our corporate prison system and jailing non-violent criminals.
Re:A poor carpenter... by catprog · 2017-09-12 09:20 · Score: 1

Apparently 256AES quantum computing is about equal to 128AES classic computer for security.

--
My Transformation Website
Kindle Books http://www.catprog.org/rev
Interactive CYOA http://www.catprog.org/st
Re:A poor carpenter... by ilsaloving · 2017-09-12 09:32 · Score: 1

IMO, the level of security rigor a company is required to comply with should scale based on the sensitivity of the data they are retaining. Companies like Equifax should be required to build the digital equivalent of Fort Knox, because the impact of a breach is so significant.
If they are not willing to treat the very sensitive data they store with the same care as would be afforded to the CEOs first born son, then they have no business holding onto that data.
IMO, the whole executive team should be charged and thrown in jail. They know exactly what kind of data they have, and how dangerous that data can be in the wrong hands. They have no excuse.
Re:A poor carpenter... by ilsaloving · 2017-09-12 09:43 · Score: 1

You've not considered another possibility - that Equifax actually did the best they could and it just wasn't good enough.

Based on how they're handling the outrage, I'm currently leaning towards "incompetence". Blaming a 3rd party library for a catastrophic data beach tells me that they don't have the foggiest idea what they're doing.
As you yourself said, no software is perfect. It's basically impossible at this point. That's why a company needs to have a layered and multi-faceted security infrastructure to help mitigate the risks as much as possible.
Maybe they did a good job and still got breached. I don't know for sure. But I've seen MANY examples shockingly shoddy code in my time, and one thing I've noticed is that people/companies who are generally obnoxious, try to deflect blame, etc, are usually those that really weren't very good to begin with.
Re:A poor carpenter... by KingBenny · 2017-09-12 11:53 · Score: 1

ah ... leaving the gate to the company open at night might provoke uninvited guests crawling under rocks waiting for a morcel to drop from the table. I just poured boiling hot water down my pants, i will sue the electricity company for enabling hot water. The dudes should go into politics unless someone actually took a hacksaw and an axe and chopped a hole in the wall to do a brute force entry lol. Trespassing through an open door ... debatable ... i'm not even really sure if that would be considered breaking and entering even in a police state like this some lawyer might twist it . Like yahoo sueing kids who demonstrate security flaws, more dignity would show from admitting "we overlooked it" i presume. But what do i know .. its not like im a pro or anything

--
Free speech was meant to be free for all... how can anyone grow up in a nanny state ?
Re:A poor carpenter... by Xest · 2017-09-12 19:11 · Score: 1

"I doubt there is a zero day exploit hidden ... but well, the PRINT implantation could have a bug, but as long as you only print literal text ... what could happen?"
Could it overflow causing a dump of sensitive data? Could the interpreter have a vulnerability in it? Could the OS have a vulnerability in it? Could the hardware have a vulnerability in it?
You still cannot guarantee that nothing bad will come of running a machine with that software on it. There's still every possibility someone could hijack the system.
"So, you gave the solution to your claims already in your explanation: "full and 100% accurate auditing of the entire hardware and software stack", that is what you do, if you want a secure system."
Which doesn't exist, because no static or dynamic code analysis software is 100% perfect, and neither are humans. You're suggesting the impossible needs to happen, and it can't, because by definition, it's impossible. If you can't see how a machine with an example as simple as yours above may still be vulnerable then what hope in hell does anyone else have of doing that with a complex distributed multi-tier system with thousands or sometimes even millions of lines of code?
"Your parent is perfectly right: if you can not afford that, you have the wrong business model."
Thus I am also right, because as that does not exist you are effectively saying every business has the wrong business model, which of course makes absolutely zero sense - they obviously don't because they're all still in business and people prefer the services they provide to a world without them.
"As soon as the are completely secured: no."
Again, no such thing. You have a dangerous naivety towards IT security if you believe absolute security is a thing - your mindset is why more attacks are successful than necessary because you think you've provided a perfectly secure system and are naive to the fact that you're still vulnerable - when you get hit you'll end up doing exactly what Equifax has and end up with a completely hopeless response because you were unprepared due to your naivety. You can't criticise companies like Equifax when you're part of the problem.
Re:A poor carpenter... by david_thornley · 2017-09-13 03:24 · Score: 1

Both of which I'm against. There are real benefits to being soft on crime, including less money spent and fewer repeat offenders.

--
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
Re:A poor carpenter... by angel'o'sphere · 2017-09-13 06:46 · Score: 1

Could it overflow causing a dump of sensitive data? Could the interpreter have a vulnerability in it? Could the OS have a vulnerability in it? Could the hardware have a vulnerability in it?
As long as Inprint the static text 'hello world', no to all of them.
You still cannot guarantee that nothing bad will come of running a machine with that software on it. There's still every possibility someone could hijack the system.
Of course I can. The system does not sccept any input, hence you can not feed anything into it to compromise it.
Again, no such thing. You have a dangerous naivety towards IT security if you believe absolute security is a thing - your mindset is why more attacks are successful than necessary
Actually it is the opposite around.
Your idea that there is no secure system is a self fulfilling prophecy by guys who don't care about security or bugs.
Care for it, adress the issues, learn, improve and most important: stop bitching, stop being fatalistic.

--
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Re:A poor carpenter... by ScienceofSpock · 2017-09-13 08:08 · Score: 1

Forgive me for assuming everyone here was technically literate. I chose the word "absolute" when what I meant was "competent". I was referring to the current state of the art in security. Yes I know that some breaches are unavoidable. Having said that, I stand by my previous post. Here's 2 recent articles to help you rethink your position:

1. https://politics.slashdot.org/story/17/09/12/1339211/equifax-lobbied-for-easier-regulation-before-data-breach
This tells me they absolutely DO NOT CARE about customer security. They were pushing back on regulations that governed legal liability for credit reporting firms.

2. https://news.slashdot.org/story/17/09/13/1840258/equifax-had-admin-as-login-and-password-in-argentina
This was just posted today. Equifax was using admin/admin as username and password! Apathy or incompetence, take your pick.

Defend shitty companies like this all you want, but without stronger regulations and FINES THAT ACTUALLY PENALIZE, this shit will just get worse.
As for your "Give them the benefit of the doubt" plea, sorry, I've seen far too much of large corporations screwing citizens in my lifetime to have ANY doubt left to give. Call me cynical.
Re:A poor carpenter... by Xest · 2017-09-14 00:43 · Score: 1

"As long as Inprint the static text 'hello world', no to all of them."
So you know of 100% secure hardware and OS? Really? The world would love to hear about it. That's also a big if, it requires a substantial presumption on your behalf - you'd be better off admitting that actually, you're wrong, you cannot guarantee absolute security in a system rather than continuing with stupid and verifiably false arguments.
"Of course I can. The system does not sccept any input, hence you can not feed anything into it to compromise it."
If you think input into the top layer on a stack is the only way to attack a system then you're just further highlighting that you don't have the foggiest about IT security.
"Actually it is the opposite around.
Your idea that there is no secure system is a self fulfilling prophecy by guys who don't care about security or bugs.
Care for it, adress the issues, learn, improve and most important: stop bitching, stop being fatalistic."
Come back with that argument when you've told us what this magical 100% secure hardware set and OS is.
I'm waiting, we're all waiting. I suspect we will be for a while in fact.
Re:A poor carpenter... by angel'o'sphere · 2017-09-14 09:08 · Score: 1

If you think input into the top layer on a stack is the only way to attack a system then you're just further highlighting that you don't have the foggiest about IT security.

And I would say you have no clue abut software development :D
How the heck will you attack a system without input? changing its rom? Then it is no longer the same "system".
Come back with that argument when you've told us what this magical 100% secure hardware set and OS is.
That is not the question.
Your attitude that there are always bugs is the question.
We know since decades how to prevent bugs. And a security flaw is just the same, a bug in the area of security.

--
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Re:A poor carpenter... by Xest · 2017-09-18 08:04 · Score: 1

"How the heck will you attack a system without input? changing its rom? Then it is no longer the same "system"."
Because there is no such thing as an inputless system - you think because you can write one simple piece of software with no input that the entire stack on which it runs must be inputless, this is patently false. An inputless computer is not a computer because by the very definition of a computer it requires some form of input to produce some form of output. That simple program you refer to IS an input, and it has to execute on something, that something else may be vulnerable. You're failing completely at comp. sci. 101 yet claiming I'm clueless about software engineering. Are you really that fucking retarded? Seriously?
"That is not the question."
Yes it is, because you're saying there's such thing as 100% secure system. There isn't.
"We know since decades how to prevent bugs. And a security flaw is just the same, a bug in the area of security."
And yet to this day we still have bugs in every single piece of meaningful software and hardware stack ever produced. So no, we haven't known for decades how to prevent bugs because no one's yet produce a 100% bug free hardware and software stack.
You literally have no idea what the fuck you are talking about, you shouldn't be doing much more than building PCs by sticking the components together like a monkey with your astounding lack of knowledge. Anything else and you're just a danger to the industry with your ignorance of computing.
Re:A poor carpenter... by angel'o'sphere · 2017-09-18 09:00 · Score: 1

Yes it is, because you're saying there's such thing as 100% secure system. There isn't.
When the systems is 100% free of bugs is is also 100% secure.
Can you prove that it has 100% no bugs? No, you can't.
Just because you don't know if it is bug free does not mean that it has bugs.
The rest of your rant clearly indicates that YOU have no clue. A bit more respect to fellow computer scientists please :D
E.g. your ranting about inputs makes no sense ... My example was a perfect counterexample, hehe. Far sketched, yes. But that was the point!

--
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Re:A poor carpenter... by Xest · 2017-09-21 22:32 · Score: 1

"Can you prove that it has 100% no bugs? No, you can't."
Oh dear, you're resorting to the god argument. "Can you prove god doesn't exist?", okay well he must then. When you resort to this, this is how I know you've lost the argument.
"The rest of your rant clearly indicates that YOU have no clue. A bit more respect to fellow computer scientists please :D"
But you're not, because you don't understand computer science. Don't even dare try and declare yourself something that you're clearly neither educated, nor qualified to declare yourself as whilst using logical fallacies to try and avoid accepting that you were wrong, and are out of your depth.
Re:A poor carpenter... by angel'o'sphere · 2017-09-22 00:24 · Score: 1

Well,
I'm a computer scientist.
Not a security specialist, though.
That is why I call your so called 'explanations' a rant, as you have not the qualification to talk about security.
Anyway, you even seem not to know what a locical fallacy is, so it would be better not to use that term.
Regarding bugs and security: you can mot proof a system had no bugs. You can only find bugs. You agree?
That doees mot imply every system has bugs. It only implies, if you have a bug free system, you can not (easily) proof it. And this is not a logical fallacy.
Hence secure and bug free software is possible. The space shutle flight controll software, some 500k lines of code, went into production with no known bugs, during the first years 4 bugs where found and fixed, henceforth they did not discover further bugs. We assume the software was bug free from that point in time.
If you want to take the efford, you can make every software bug free.
Just as a sidenote: I work in software industry now since more than 35 years, I likely made a lot of bugs, don't really know. But what I know 100% for sure: I never had a bug made by me or my team escape into production.
Well, not sure how we can cope in my current team, though :)
Anyway, attitudes like yours is the reason there is so much unsecure and buggy software in the world. "Uh oh! It is impossible to prevent security bugs, deal with it!" No, it is not impossible.

--
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Re:A poor carpenter... by Xest · 2017-09-22 06:23 · Score: 1

"Well,
I'm a computer scientist."
Then you should quit before you do any more harm to the industry.
"Not a security specialist, though."
Yes, the fact you don't have the slightest clue about computer security kind of gave that away.
"Regarding bugs and security: you can mot proof a system had no bugs. You can only find bugs. You agree?"
Theoretically you can through induction (you should know this if you're a computer scientist, but you don't, so you're not) but in practice no one ever does, there's no fully verified hardware on the market, much less operating systems, or many other key elements of a typical stack today (i.e. web servers).
"Hence secure and bug free software is possible. The space shutle flight controll software, some 500k lines of code, went into production with no known bugs, during the first years 4 bugs where found and fixed, henceforth they did not discover further bugs. We assume the software was bug free from that point in time."
What? No. We don't ever assume that. Please do not EVER let yourself get involved in any safety critical system. You'll actually kill people, I'm not joking here.
"I never had a bug made by me or my team escape into production."
Hahahaha. Good one. This is how I know you're full of shit, and not actually a computer scientist. I'd love to see your software, I'd wager I can trivially disprove this.
"Anyway, attitudes like yours is the reason there is so much unsecure and buggy software in the world."
Yes that's right, anyone who doesn't pretend they're magic is responsible for software not being magic. Fuck me you're the most stupid person on Slashdot, again, please step away from computers, I REALLY don't want you to get anyone killed with your profoundly dangerous ignorance.
Re:A poor carpenter... by angel'o'sphere · 2017-09-22 06:31 · Score: 1

And you are the most insulting person on /.
Anyway, we obviously have a mutual agreement that none of us has any clue about software development and security :)
At least I have a proven track record of software in production that has so far no bug reports, from customers or users. How about you?

--
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Re:A poor carpenter... by Xest · 2017-09-22 21:58 · Score: 1

"At least I have a proven track record of software in production that has so far no bug reports, from customers or users. How about you?"
Provide me access to the software please to verify, or stop lying. Can't have it both ways.
Re:A poor carpenter... by angel'o'sphere · 2017-09-23 05:13 · Score: 1

You only need access to my customers Jira :D
E.g. ask http://enbw.com/ or https://www.tipico.de/ or http://www.postbank.de/
I'm pretty sure they give a random idiot access to the Jira and the source code repository to browse if he can find a bug that can be attributed to angel'o'sphere or the team he is part of. Good luck.
Provide me access to the software please to verify, or stop lying. Can't have it both ways.
Ah, just because you can not verify it it is a lie?
Just because you can not find a bug in a piece of software, you know there is a bug, hidden somewhere?
Please stop showing to the internet that you are a complete idiot.

--
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Re:A poor carpenter... by Xest · 2017-09-23 10:48 · Score: 1

"I'm pretty sure they give a random idiot access to the Jira and the source code repository to browse if he can find a bug that can be attributed to angel'o'sphere or the team he is part of. Good luck."
Yes, exactly, you know they won't and probably haven't even heard of "angel'o'sphere", which is what makes it so obvious that you're lying. As I said, source code access or you're lying.
"Just because you can not find a bug in a piece of software, you know there is a bug, hidden somewhere?"
Nope, but just because you think there aren't bugs doesn't mean that there aren't, and in fact, for any moderately complex piece of software history shows that there always are. The fact you think otherwise means you're not fit to be a professional developer because it means you're not protecting against the inevitable.
"Please stop showing to the internet that you are a complete idiot."
Yep, you really might want to stop doing exactly that as I've suggested already. You're embarassing yourself with your profound ignorance of the topic, you're a joke on Slashdot for exactly this reason.
Re:A poor carpenter... by angel'o'sphere · 2017-09-24 02:00 · Score: 1

but just because you think there aren't bugs doesn't mean that there aren't
I never said that.
Go spit your vitriol elsewhere.
You're embarassing yourself with your profound ignorance of the topic
As I said before, I'm a computer scientist. You however are just a vitriol spitting idiot.
No idea what you know about computing. Except for attempts to quote me wrong you have not said much. And most certainly nothing that is remotely correct.

--
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Re:A poor carpenter... by Xest · 2017-09-24 05:16 · Score: 1

"I never said that."
Actually that's EXACTLY what you said. You said you have always written 100% bug free software, and use reported bugs as a metric. That still leaves open the possibility of their being bugs, and, given your naivety and arrogance, that's basically a certainty at this point.
"As I said before, I'm a computer scientist."
No you're not. Labelling yourself something just to make yourself feel like you matter doesn't actually make you that thing. To be a computer scientist you'd need to either practice computer science, but you're arguing that you're effectively the absolute anti-thesis of that. You do not even understand the most basic concepts of computer science, and therefore by definition, cannot be a computer science. It's like declaring yourself a astro-physicist without having the slightest clue about physics.
The very fact you even label yourself as a computer scientist is in itself laughable - you claim to write software professionally, but no one hires computer scientist to write software, computer science is quite a distinctly different practice. Computer science is research oriented and algorithmic with a strong understanding of mathematics, at best you've shown yourself to be a bottom of the pile HTML developer or something pathetic like that.
Re:A poor carpenter... by angel'o'sphere · 2017-09-24 06:02 · Score: 1

"I never said that."
Actually that's EXACTLY
Nope.
You have a reading problem. Hint: just "scroll back" and read my previous posts.
a bottom of the pile HTML developer or something
I actually have not much clue about HTML ... why do you bring that into discussion? I do software, not "documents". Aka I use C++/Java and other languages ... I actually don't even have a deep insight about TeX :D but that is chanign as my current job requires me to write docs in tech.
Funny is: I wrote my diploma thesis in HTML, with Netscape.
Now get off my lawn and find someone else to insult.

--
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Re:A poor carpenter... by Xest · 2017-09-24 06:34 · Score: 1

"You have a reading problem. Hint: just "scroll back" and read my previous posts."
Yep, I did. Perhaps you're confused about what you're saying because you're not conversing in your native language? It's pretty clear what you said:
"But what I know 100% for sure: I never had a bug made by me or my team escape into production."
I guess you probably need to learn how to converse in English better, because you're clearly saying things you don't actually mean.
Re:A poor carpenter... by angel'o'sphere · 2017-09-24 08:47 · Score: 1

What has my bug history to do with your previous post?
It is not my fault that I managed to get code into production that has no reported bugs ...
Our previous post/discussion was about bugs/errors/security flaws in "common" code ... it was not about me or my code.
Your "scrolling back abilities" must be very weak.
Scrolling back a bit: but just because you think there aren't bugs doesn't mean that there aren't any bugs
Again: I never said that. Perhaps you might scroll back further ...

--
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Re:A poor carpenter... by Xest · 2017-09-25 03:36 · Score: 1

"It is not my fault that I managed to get code into production that has no reported bugs ..."
Thank you for climbing down and finally admitting that you haven't in fact released 100% bug free software as you previously claimed, merely that you have resolved all bugs you were aware of before you released it.
You have finally backed down and admitted you were wrong, thank you. That's all it took.
Re:A poor carpenter... by angel'o'sphere · 2017-09-25 03:50 · Score: 1

Thank you for climbing down and finally admitting that you haven't in fact released 100% bug free software as you previously claimed
I have not claimed that.
merely that you have resolved all bugs you were aware of before you released it.
I wrote that already something like 5 or 10 posts back.
You have serious reading problems.

--
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.

Blame the software not the License. by jellomizer · 2017-09-11 10:06 · Score: 4, Insightful

How the product is licensed doesn't affect the quality of the software.
If the software is of significant complexity, then chances are flaws will be there, and often just like commercial licences software a flaw can be overlooked by many eyes, until the flaw is found.

--
If something is so important that you feel the need to post it on the internet... It probably isn't that important.

Re:Blame the software not the License. by HornWumpus · 2017-09-11 10:35 · Score: 1

You haven't thought that through. At all.
Don't appear to know how web servers work or security breaches happen.

--
John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
Re:Blame the software not the License. by jellomizer · 2017-09-11 10:39 · Score: 2

All sounds good in theory. But if there is 1% of the people out of the millions of transactions requesting more than 100 rows that will still be thousands of requests that need approval. The supervises will get fatigued at the request and just blanket approve them.

--
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
Re:Blame the software not the License. by Anonymous Coward · 2017-09-11 10:52 · Score: 1

It isn't because it is MS licensed, but that nobody but MS can look at it.
Re:Blame the software not the License. by SeaFox · 2017-09-11 13:35 · Score: 1

But if there is 1% of the people out of the millions of transactions requesting more than 100 rows that will still be thousands of requests that need approval. The supervises will get fatigued at the request and just blanket approve them.
Or, they could just hire an appropriate enough number to supervisors to review all these transactions without them getting fatigued.
Re:Blame the software not the License. by WaffleMonster · 2017-09-11 15:38 · Score: 1

How the product is licensed doesn't affect the quality of the software.
It certainly does influence management and priorities of the product.
Re:Blame the software not the License. by TheRaven64 · 2017-09-11 19:52 · Score: 1

Microsoft's products aren't insecure because they're closed source, and these days MS has pretty good security practices (they're still insecure, because they're so complex, but not more insecure than the rest of the industry). The problem for security with being closed source is that you rely on a single vendor to fix the issue. If Microsoft decides that your version of the product is not going to get security updates anymore and you need to buy the new one (then test and update all of your software to work with it) then this can cause huge delays or costs in rolling out a security update. In contrast, if it's open source and it's important to your business you can find multiple companies that will bid to back-port the security fix to your version.

--
I am TheRaven on Soylent News
Re:Blame the software not the License. by oobayly · 2017-09-12 00:08 · Score: 1

Which would take them back to 1960s data-loss rates... Plus, I'm pretty sure they could afford it. What needs to be done is to make the data loss cost more than the savings made by not securing their information properly, which rarely happens in any industry.
For example, I knew of beef farmers in Ireland that were given a custodial sentence for "dusting" cattle (using clenbuterol or angel dust). Even after the fine and the cost of hiring farm relief it still financially worthwhile.

A poor carpenter... by Anonymous Coward · 2017-09-11 10:09 · Score: 1

Keeps using a chisel with chipped blade and a loose handle.

Comment removed by account_deleted · 2017-09-11 10:10 · Score: 5, Insightful

Comment removed based on user account deletion

It is open source ... by AnthonywC · 2017-09-11 10:11 · Score: 5, Insightful

They have NO ONE to blame but themselves, it is OPEN SOURCE which means they can actually review the code and fix issue.

Re:It is open source ... by jellomizer · 2017-09-11 10:24 · Score: 1

In that case, why don't they make their own product.
Often there is just as much time and effort to review code, of a complex application, then it would take a dev team to build an app customized to the actual business need, vs using a general purpose software.

--
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
Re:It is open source ... by phantomfive · 2017-09-11 11:10 · Score: 1

In that case, why don't they make their own product
Apparently in the case of Equifax the answer is: they are too incompetent to do so. They don't seem to be competent at any aspect of building software.

--
"First they came for the slanderers and i said nothing."
Re:It is open source ... by Mr.+Shotgun · 2017-09-11 11:33 · Score: 3, Interesting

They have NO ONE to blame but themselves, it is OPEN SOURCE which means they can actually review the code and fix issue.
To be fair most organizations do not have the expertise or desire to review and fix the source code for products they are using, open source or not.
That being said I am betting dollars to pesos that they were attacked with the March Vulnerability and not taken down by the zero day from a week ago. It seems like unless a vulnerability has a fancy web page and gets featured on CNN, management could not give a flying fuck. Wait till the next patch cycle becomes wait until the next quarter becomes eh we'll get to it. And that shit has got to stop.

--
Of all tyrannies, a tyranny sincerely exercised for the (supposed) good of its victims may be the most oppressive
Re:It is open source ... by Faluzeer · 2017-09-11 20:12 · Score: 1

In that case, why don't they make their own product
Apparently in the case of Equifax the answer is: they are too incompetent to do so. They don't seem to be competent at any aspect of building software.
Alternatively, they may have some competent people, who wanted to do exactly that, or who pointed out security flaws and wanted to fix them, but were over-ruled on cost grounds by managers above them.
Re:It is open source ... by vyvepe · 2017-09-11 21:56 · Score: 1

Often there is just as much time and effort to review code, of a complex application, then it would take a dev team to build an app customized to the actual business need, vs using a general purpose software.
You are way to optimistic about how much time it takes to develop a new application. You should have written: "Often times it is cheaper to review and adjust an existing application to your particular needs."
Re:It is open source ... by jbengt · 2017-09-12 01:26 · Score: 1

You know, even if you write the code yourself, it's still going to need to be audited.
Or, in most cases, especially if you write the code yourself.
Not everybody is an expert in security.
Re:It is open source ... by david_thornley · 2017-09-12 04:51 · Score: 1

Software development is hard. Software security is much harder. You have to defend against Satan, not Murphy.
However, Equifax is responsible for the software they choose. I didn't choose their software, and neither did the guys who approved my car loan. They are responsible for running the system as they decide, and therefore bear the responsibility.

--
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes

Re:Bullshit... by jellomizer · 2017-09-11 10:11 · Score: 1

What you can't believe software that happens to be released with an Open Source license could have a security vulnerability.

Granted I expect the flaw is more then just a flaw in the software, but poor network design, excessive trust in the application and/or poor implementation.

But people who just scoff at the idea that Open Source is this just ultra secure system, will often implement it in a poor manor making it vulnerable. Because of a zealot faith in the holy license.

--
If something is so important that you feel the need to post it on the internet... It probably isn't that important.

JAVA! by TechyImmigrant · 2017-09-11 10:12 · Score: 2, Interesting

>Model-View-Controller (MVC) framework for Java
There's your problem right there.

Security demands simplicity.

--
I should use this sig to advertise my book ISBN-13 : 978-1501515132.

Re: JAVA! by javaman235 · 2017-09-11 10:19 · Score: 1

MVC for java off IBM is a top grade choice for security. This is why you use cloud though, you can blame IBM at least till the flaw is isolated. ;)

--
-The art of programming is the pursuit of absolute simplicity.
Re:JAVA! by Xest · 2017-09-11 19:01 · Score: 1

Out of interesting, what are you proposing as an alternative?
It's just after years of CGI w/C or C++, PHP, and many other things it's pretty clear that managed languages like C# and Java have suffered the least, and least serious attacks.
So I'm genuinely intrigued to know what you believe is both more simple, and more secure because I'm aware of no such thing. I still have nightmares of the full server control buffer overflow vulnerabilities from the days people were writing web apps in native code.
Re:JAVA! by Wrath0fb0b · 2017-09-12 00:09 · Score: 2

Model-View-Controller (MVC) framework for Java
There's your problem right there. Security demands simplicity.
A properly designed & implemented MVC is far simpler to understand, develop and audit than a tangle of spaghetti code that mixes everything up into a unitary blob.
Simplicity is not the lack of internal structure, it's the lack of complicated relationships between the various pieces. There are plenty of very complex pieces of software that are nevertheless simple because the complexity is well matched by modular design and clean/legible interfaces.
For a lot of design tasks, MVC is a proper choice for this. And like most things, using an off-the-shelf framework is largely preferable to rolling your own. That doesn't mean that some crap contractor never used it in the wrong place or wrote it completely pants-on-head stupidly. Or that some framework isn't shit.
Re:JAVA! by TechyImmigrant · 2017-09-12 03:26 · Score: 1

>A properly designed & implemented MVC is far simpler to understand, develop and audit than a tangle of spaghetti code that mixes everything up into a unitary blob.
Yet you have many layers of code between you and the incoming packets where problems can lurk. Indeed a problem did lurk inside the Apache struts MVC framework software, in Java, running on a JVM. with a boatload of ancillary java libraries, in some execution context on top, or within Apache. I see nothing simple whatsoever and the 'simplicity' of MVC did not prevent a bug. That's because it's not remotely simple. Easy to think about the high level abstraction isn't the same thing as simple.
The alternative isn't a unitary blob. It's to know what asset's you are securing and to know and understand all the code touches that data on the path to and from the external interface and to minimize that attack surface. You can pretty up the web app all you like, but keep the secured assets in a place where it isn't touching the eye candy web app nonsense. A sprinkling of defense in depth might help also, so individual components can fail to be secure, without undermining the security of the system.
I assume none of that happened here. They just employed a multiple huge libraries of internet facing stuff with direct access to all the information that was supposed to be secret and of course, someone took it all.

--
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
Re:JAVA! by TechyImmigrant · 2017-09-12 08:13 · Score: 1

If you mean what would I have done if I was Equifax the answer is I don't know. They are in the bizarre situation of their own making where they treat the same thing (your SS number and personal details) both the secret asset being protected and the authentication token you use to identify yourself. They also sell that information to people willing to pay. There's no fixing that mess.
If you mean more generally, I wouldn't put my protected assets in hands of a bunch of web app code on top of a framework on top of a JVM on top of another 15 layers. I would be thinking about making those things a conduit through which a simple and secure protocol can run that attached between simple and secure things at the endpoints. Assume the web server and web application is completely pwned and design a system that is still secure regardless. The hard part of getting started is identity verification in the enrollment stage. At some point there's a wet human and you're trying to uniquely identify them in order to bind to a cryptographic token.

--
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
Re:JAVA! by Xest · 2017-09-12 19:15 · Score: 1

Right, but that's not really relevant to your earlier comment - it's still hard to see what alternative technology stack would've mitigated this when Java based MVC frameworks are some of the most secure tried and tested frameworks in the world.
You're right, that doesn't protect against stupid if someone builds stupid on top of it, but that's a different problem and not a fault of using a Java based MVC framework as of and in itself. Organisations ranging from Amazon to eBay, major banks to Google have run Java based MVC systems for years and had absolutely no security breaches (which as per my other comments in this article doesn't mean they wont but that they're at least doing far better than average).
Re:JAVA! by Wrath0fb0b · 2017-09-13 03:45 · Score: 1

(1) Anyone that claims that he or she "knows and understands all the code touching the data", is either Torvalds-level-genius or, more likely, regular-smart but completely delusional about the complexity in layers that they don't understand.
Software engineering is a team sport. The network driver guy doesn't need to know about the details of the optimizing compiler, he needs only to understand the formal contract about what constitutes a well-defined program in the language. The silicon engineering team doesn't need to understand how the UI elements are drawn, the need only to understand what functionality they need to provide to the composite. This isn't silo-ing for no reason, it's the only way to build anything of scale using people of merely-above-average intelligence.
(2) This is nonsense: "secured assets in a place where it isn't touching the eye candy web app nonsense". The whole point of most applications is to take secured assets and make them available over the web or, gasp, even mutated over the web. Taken serious, you wouldn't be able to build a web interface to access my bank account or make an online payment -- IOW, you would destroy most of the functionality we are trying to secure.
Yes, these guys were incompetent. But the answer isn't in anything you wrote.

Yes Yes by American+AC+in+Paris · 2017-09-11 10:14 · Score: 5, Funny

I think that if we've learned anything from this incident, it is that Equifax is a competent, professional organization that prides itself on its honesty and transparency, and that they are tirelessly acting in the best interests of the general public.

--

Obliteracy: Words with explosions

The cost of doing business online by DogDude · 2017-09-11 10:15 · Score: 1

Doing business of any kind, online, is inherently insecure. There's a lot of risk for consumers, and a lot of expense for businesses to stay as secure as possible (which isn't very). Sucks for people who need a credit score.

--
I don't respond to AC's.

Equifax Corporate Officers by xxxJonBoyxxx · 2017-09-11 10:15 · Score: 4, Insightful

>> is it the fault of Struts developers or Equifax's developers, system admins, and their management?

None of the above. It's the officers on the corporate board, who demanded "cheaper" rather than "secure." The managers who carried out their demands (putting emphasis on cheap contractors vs. quality work and investment in patching dependencies) were just doing their jobs, the sysadmins really don't have much to do with it (if you know how Struts works) and the developers are pretty blameless because their either do what management told them or not eat.

Re:Equifax Corporate Officers by phantomfive · 2017-09-11 11:11 · Score: 1

This story is the result of a CTO who is looking to blame anything as a CYA move. He said it, the suits bought it, and made a story of it.

There is no way the CTO gets out of this with his job.

--
"First they came for the slanderers and i said nothing."
Re:Equifax Corporate Officers by Anonymous Coward · 2017-09-11 12:00 · Score: 3, Informative

My bitter, aging software engineer take: it's the endgame of chasing new features to meet next quarter's revenue target, neglecting to fund maintenance/sustaining teams for legacy apps. I don't even see maintenance/sustaining teams anymore. Maybe that was just a telecom industry (which I left 10+ years ago). In any case, if there isn't a development team that is actively updating an old unglamorous app, you're in trouble. Software will rot, not just from years of app patches, but also reliance on abandonware thirdparty libraries accumulating known exploits over time.

If you don't invest in open source by Anonymous Coward · 2017-09-11 10:21 · Score: 1

you are not allowed to place any blame on it

equifaxsecurity2017.com by Phoeniyx · 2017-09-11 10:21 · Score: 2, Informative

Yup, I went to the site and it asked for name and last 6, and I was like "GTFO"... Are you kidding me? How can these imbeciles NOT know that this looks like a classic phishing site.

Re:equifaxsecurity2017.com by antifoidulus · 2017-09-11 15:16 · Score: 1

Not to mention that with first and last name and last 6 finding the first 3 is often quite simple(especially if they can get your IP address as well). There are a ton of background sites where for free you can, with reasonable accuracy, piece together where a person was born and thus can figure out the first 3. SSNs are terrible for so many reasons, one of the biggest is that they aren't random. If they were completely random strings then I could share a certain # of digits without it being relatively easy for you to figure out the rest, but that isn't true with SSNs.

--
Monstar L
Re:equifaxsecurity2017.com by ichimunki · 2017-09-11 15:33 · Score: 2

I didn't know this until a couple days ago, but starting in 2011 all new SSNs are random numbers. https://www.ssa.gov/employer/r...

--
I do not have a signature
Re:equifaxsecurity2017.com by coofercat · 2017-09-12 00:22 · Score: 1

...and they don't even provide a way to verify the site (other than it's linked to from equifax.com). Even their SSL cert doesn't include their company name. It's amazing geniuses like these had security flaws in their systems!
Re:equifaxsecurity2017.com by RockDoctor · 2017-09-14 12:30 · Score: 1

How can these imbeciles NOT know that this looks like a classic phishing site.
Try this scenario for size : the people who put this site together have never seen a phishing site. After all, having been using the web since about 1995, I've never seen a phishing site. Why would I?

--
Birds are not dinosaur descendants;birds are dinosaurs, for all useful meanings of "birds", "are" and "dinosaurs"

Root cause = SJW hiring practices by Anonymous Coward · 2017-09-11 10:23 · Score: 5, Interesting

You hire a liberal arts music major as head of security to fill a gender diversity quota, and then you're surprised by this?

Re:Root cause = SJW hiring practices by i286NiNJA · 2017-09-11 10:48 · Score: 5, Interesting

I don't think it was SJWs. I think she was well connected and managed to land a bunch of compliance gigs that have nothing or little to do with technology and Equifax regards security as a good starter position for c-level executives and PHBs instead of being a terminal position for some former teen-hacker.
Let it soak for a second. If you work in IT.. even as tech takes over the world.... even as infosec mismanagement crises have been first page news for several years.
YOU ARE WORTH LESS THAN THE MANAGEMENT CASTE.
No matter how smart, no matter how educated, no matter where you work and no matter how much money you make... Unless you're born rich and connected or embed yourself into bureaucracies for access to such people .
You are of a lower caste.
Re:Root cause = SJW hiring practices by elrous0 · 2017-09-11 12:47 · Score: 3, Informative

You hire a liberal arts music major as head of security to fill a gender diversity quota, and then you're surprised by this?
Wow, I thought you were trolling until I actually looked it up. WTF were they THINKING? You're not supposed to give a token diversity hire an actual job. You're supposed to appoint them to a bullshit position where they can't do any actual damage, then put their picture in all your brochures to virtue-signal to everyone how progressive you are.

--
SJW: Someone who has run out of real oppression, and has to fake it.
Re:Root cause = SJW hiring practices by Tranzistors · 2017-09-11 18:19 · Score: 1

Obligatory XKCD
Re:Root cause = SJW hiring practices by Faluzeer · 2017-09-11 20:07 · Score: 1

Posting to remove moderation. I thought you were trolling until someone actually posted the link about her career.
Re:Root cause = SJW hiring practices by Kunta+Kinte · 2017-09-12 02:27 · Score: 1

You hire a liberal arts music major as head of security to fill a gender diversity quota, and then you're surprised by this?
This is low, even for Slashdot and you know this.

--
Based on upvotes, Ageism is the only "-ism" Slashdotters care about and think isn't SJW
Re:Root cause = SJW hiring practices by gotan · 2017-09-12 03:27 · Score: 1

Well, to the rest of the management information security probably *is* a bullshit job.

--
"By the way if anyone here is in advertising or marketing... kill yourself." -- Bill Hicks
Re:Root cause = SJW hiring practices by Tranzistors · 2017-09-12 17:59 · Score: 1

Is it sad that I knew which comic this was before even mousing over the link?
Nah. Which other comic could it possibly be?

Struts Fault? by oldgraybeard · 2017-09-11 10:31 · Score: 2

Seems to me, Equifax is! as are all the credit collection businesses. Professional Extortion artists! They collect data on everyone. Then sell access to that information to the financial industry (Credit Checks). And if you want to protect yourself you are supposed to pay them to protect (Lock) your credit history.

They do not care about spending money to protect the information they have data mined.

Open source is better, if you use it right! And put the time in to do "YOUR" due diligence! They did not! They got hacked! It took them weeks to even realize it! And weeks before they came clean.

Re:Struts Fault? by oldgraybeard · 2017-09-11 11:03 · Score: 2

Just saw it on the Fox Business Channel, the 3 execs that were caught selling 1.8M in stock before this came out.

Chief Financial Officer John Gamble made $946,374
U.S. Information Solutions President Joseph Loughran made $584,099
Consumer Information Solutions President Rodolfo Ploder made $250,458

Of course none of them knew about the data breach ;) lol Right!

I have a bridge to sell you ;)
Re:Struts Fault? by WindBourne · 2017-09-11 11:17 · Score: 1

actually, it is KNOWN that they did the sale shortly after they learned about the breach.

--
I prefer the "u" in honour as it seems to be missing these days.
Re:Struts Fault? by oldgraybeard · 2017-09-11 11:21 · Score: 1

OK, I thought they were denying it. thxs I stand corrected ;)
Re:Struts Fault? by WindBourne · 2017-09-11 11:55 · Score: 1

would not surprise me if they tried to deny it. Would not be the first time that some rich asshole lied through their teeth. :)
However, it is still known that they WERE notified prior.

--
I prefer the "u" in honour as it seems to be missing these days.
Re:Struts Fault? by l0n3s0m3phr34k · 2017-09-11 12:05 · Score: 1

Well, they ARE denying this breach is the reason. In science, "Correlation does not imply causation". However, when it comes to super-greedy C-level execs with insider info that they KNOW will cause a huge stock drop...well, I'm sure you can figure out the truth. But they will NEVER admit to cashing in stocks because of this, or any "actual verified knowledge" of the breach when they did so. Maybe if Trump proactively pardons them they will then admit to it.
Re:Struts Fault? by ClickOnThis · 2017-09-11 12:14 · Score: 1

According to this article, Equifax says the three execs did not know about the breach before they arranged the sale.
Insider trading is legal. Trading on insider information is not. Company officers like these three execs are required to announce their sales of shares well in advance. Normally, this is no big deal -- it's like cashing their paycheck. However, if they did in fact know about the breach when they arranged the sale, then they're looking at jail time.

--
If it weren't for deadlines, nothing would be late.
Re:Struts Fault? by l0n3s0m3phr34k · 2017-09-11 12:25 · Score: 1

John's original LinkedIN profile is gone, now it's just John G. His full name is John W. Gamble Jr., and he made over 2.6 million in total compensation last year. A Whitepages search doesn't find anyone in Atlanta, but does find a John W Gamble Jr. (Age 50-54) in Lockport, NY. This PR release has him at 51 in 2014. According to this he is also on the board of both CyrusOne, Inc. and CyrusOne LP, a real estate company that specializes in data centers. And his "public assets" are over 7.5 million.

He's worked "in tech" long enough to theoretically "know better" than to let this happen. What did he know about security audits, and when did he know them?
Re:Struts Fault? by WindBourne · 2017-09-11 13:55 · Score: 1

there was another article, I forget where, that showed that they DID know just in front of their sale.
BUT, I agree that the sale itself was probably arranged 2-3 weeks PRIOR.
So, the real question becomes, did they delay the announcement knowing that they had a sale, or were they doing other things?
If so, that is a whole other issue. Not insider trading, but stock manipulation.

--
I prefer the "u" in honour as it seems to be missing these days.
Re:Struts Fault? by Cederic · 2017-09-11 20:32 · Score: 1

Seems to me, Equifax is! as are all the credit collection businesses. Professional Extortion artists!

What the fuck is 'credit collection'?

They collect data on everyone. Then sell access to that information to the financial industry (Credit Checks). And if you want to protect yourself you are supposed to pay them to protect (Lock) your credit history.
It's a difficult situation. If you follow the great American dream and apply for a credit card, you expect to be extended a multi-thousand dollar credit facility. You'll also go to the company that can offer this to you in a couple of minutes and not the one that takes several days, requires personally probing interviews, demands access to all of your existing bank accounts, mortgage and other credit facilities, and then turns you down anyway for being too high a risk.
So Equifax provide a service that's actually led by consumer demand. You want them to withdraw that service, but it costs them money to do so, and you're not the customer of that service.
Here's the really fun thing though: If you don't apply for credit, then their service does not get used, and so they don't provide it. Don't apply for credit (or agree to a credit check), no service.
What you want is for them to deny the service in situations where you don't apply for credit. That doesn't make sense, in that their service is geared towards helping you access an affordable level of credit. So if you're not applying for credit, you don't need their service and they wont offer it. But you want them to withdraw it anyway.
Clearly you're worried that someone else will apply for credit using your identity. At this point person A applies for credit with company B and Equifax offer a service to help assess this. You're not even involved! The only time you're relevant is if company B believe that person A is you, and pursues you for any debts or obligations they incur, or informs Equifax that you're a poor credit risk and that subsequently impacts on your ability to access credit.
So you can be a victim, but it's company B that's at fault here for failing to correctly identify person A (and obviously person A for being a lying fraud). You can react to this situation, demanding that Equifax remove any incorrect or fraudulent entries attached to your name in their systems, sue company B and otherwise get on with your life.
Equifax offer an additional option, which is a service for you as an individual. They'll allow you to prevent person A from masquerading as you in the first place, by informing company B not to allow person A to open an account in your name. That's the service for which they're charging you, and yet you seem to think you should receive it for free?
Re:Struts Fault? by Cederic · 2017-09-11 20:34 · Score: 1

I haven't seen anything stating that the individuals involved knew of the breach ahead of selling their shares.
The timeline is that Equifax discovered the breach a couple of days before the sales, and these are people sufficiently senior that they very likely did know, but that's supposition rather than evidence.
I think they're fucked anyway. Either they knew and broke insider trading regulations or they didn't know and are incompetent at their jobs..

Re:Had this problem with a credit card company... by Anonymous Coward · 2017-09-11 10:36 · Score: 2, Funny

Hmm not sure about this story. Can you link me to a Amazon book about this scenario?

Don't store data unencrypted! by SoftwareArtist · 2017-09-11 10:37 · Score: 1, Interesting

You have to assume your servers will get hacked. It doesn't matter what software you're running. Someone will find a way in. Any competent developer starts with that assumption and designs around it. That's why you never ever EVER store sensitive data unencrypted! They're looking for someone to blame for their incompetence.

--
"I'm too busy to research this and form an educated opinion, but I do have time to tell everyone my uninformed opinion."

Re:Don't store data unencrypted! by Anonymous Coward · 2017-09-11 11:31 · Score: 1

Encryption typically protects against physical compromise of the hard drives and other media. Once someone gains access to the system/network, the encryption/decryption is transparent to the user. You are not going to pull a chuck of binary data from a database then use your local keys to decrypt them the way you would email that comes to your inbox or a thumb drive that you plug in.
Re: Don't store data unencrypted! by javaman235 · 2017-09-11 12:53 · Score: 1

How exactly does that work? In a cloud paradigm, where user login credentials can be treated as encryption key because company doesn't access data, it works. But in this paradigm, where company uses all this data for analytics and third party access, how is compromised data server kept separate from keys used to unencypt it's data all the time?

--
-The art of programming is the pursuit of absolute simplicity.
Re: Don't store data unencrypted! by modmans2ndcoming · 2017-09-11 13:31 · Score: 1

There is typically a query system involved where you request a specific data set. In such a situation they could use a private key encryption internally on the data set and then to communicate that data they could implement a perfect forward secrecy model of communication so if the keys for that one transaction message to the client were somehow captured, only that message would be decryptable, all future and past messages would not be affected. If I cared about data security for this type of data I would have had a unique encryption key for each dossier in the database so even if there was a breach of one of more keys the damage would be limited.
Re: Don't store data unencrypted! by javaman235 · 2017-09-11 15:10 · Score: 1

Thinking and reading about what you're talking about, yeah I see pretty simple ways it could be doable now. Honestly, the easiest thing for companies who hold the data on site would be a piece of hardware, a data safe. It has inside it millions of private keys the world never knows in a table, and all its network functionality is to encrypt and decrypt data for storage using these, associate them with user password hash, and to re-encrypt using temporary tokens for each different session, and log. With physical access, you could specify parts of the encrypted storage schema used for analytics, and issue temp keys for that as well. But at the network level its a black box, literally a piece of hardware not even a computer, almost nothing to hack, its so simple and separate from everything else.
The identity monitoring services are pretty ascendant though, and they have access to more of our lives in terms of purchases than anything else. The trend unfortunately will probably be toward increased monitoring not better encryption.

--
-The art of programming is the pursuit of absolute simplicity.
Re: Don't store data unencrypted! by Ash-Fox · 2017-09-20 22:03 · Score: 1

But in this paradigm, where company uses all this data for analytics and third party access, how is compromised data server kept separate from keys used to unencypt it's data all the time?
Homomorphic encryption.

--
Change is certain; progress is not obligatory.

Re:Struts Fault? CORRECTION by oldgraybeard · 2017-09-11 10:45 · Score: 1

I said
credit collection businesses

I should have said
credit reporting businesses

Well they're entitled by Hognoxious · 2017-09-11 10:49 · Score: 2

Well they're entitled to ask for a full refund of whatever they paid for it.

--
Confucius say, "Find worm in apple - bad. Find half a worm - worse."

Not confirmed by campuscodi · 2017-09-11 10:51 · Score: 1

This is only hear-say. It was never confirmed by Equifax or FireEye.

Re:Not confirmed by ClickOnThis · 2017-09-11 12:20 · Score: 1

This is only hear-say. It was never confirmed by Equifax or FireEye.
How long have you been here? Netcraft has to confirm it, or it never happend.

--
If it weren't for deadlines, nothing would be late.

They are missing the point of open source. by Gravis+Zero · 2017-09-11 10:52 · Score: 1

The point of open source isn't, "free software you don't have to pay anyone to develop!" but rather, it's software that you can audit and don't have to take anyone's word that it does what they claim. Honestly, when your data is both highly valuable and sensitive you should at the very least hire another company to review the source code.

--
Anons need not reply. Questions end with a question mark.

Re:Bullshit... by chipschap · 2017-09-11 10:55 · Score: 2

No complex software is without bugs, no complex software is completely secure. I'm a big open source fan but this is reality. Open or closed, there will be bugs and exploits. Subjectively, it seems open source may get fixed more quickly, but that doesn't change the bottom line, which is that the onus is on the company.

Equifax stores tons of sensitive information and it's up to them to protect it properly. No excuses, no finger pointing, no passing the blame. They are responsible, period.

Re:They can blame whoever they want by chipschap · 2017-09-11 10:57 · Score: 1

Maybe it was global warming. Or Trump.

Sure, Struts from 2003 by Just+Some+Guy · 2017-09-11 11:05 · Score: 1

Why would you assume that they're using software written this decade? I think it's equally plausible that a good chunk of their components are from the mid 2000s and utterly riddled with security holes, but no PM will let the devs update anything because "if it works, leave it alone". Never mind that it doesn't actually work - that's someone else's problem, obviously.

It is apparent that Equifax couldn't give a flying fuck about security. I think it's ludicrous to debate whether the problem is with a bug revealed in March or September, when I think it's equally likely to be older than my kids.

--
Dewey, what part of this looks like authorities should be involved?

Re:Sure, Struts from 2003 by Cederic · 2017-09-11 20:41 · Score: 1

It is apparent that Equifax couldn't give a flying fuck about security
While I'm personally greatly enjoying seeing Equifax get a kicking, and looking forward to meeting up with a friend that works there to taunt him about it, I think it's very apparent that Equifax do a fucking excellent job on data security.
Otherwise this breach would have occurred a decade ago, and monthly since. It's almost a surprise that it's taken this long, and that is itself testament to the extent to which they do indeed give a fuck about security.
US consumers though.. no, they don't give a fuck about them.
Re:Sure, Struts from 2003 by coofercat · 2017-09-12 00:26 · Score: 1

I would love to know what versions their software stack is on right now - would make very interesting reading, I'm sure.
Re:Sure, Struts from 2003 by jbmartin6 · 2017-09-12 00:45 · Score: 1

Maybe if the updates didn't have a high cost in breaking things and pointless interface and API changes they would be more interested. Unfortunately, keeping a wide array of software tools up to date isn't as simple as "giving a shit"

--
This posting is provided 'AS IS' without warranty of any kind, implied or otherwise.
Re:Sure, Struts from 2003 by Hognoxious · 2017-09-12 02:22 · Score: 1

Otherwise this breach would have occurred a decade ago, and monthly since.

Perhaps it did.

--
Confucius say, "Find worm in apple - bad. Find half a worm - worse."

I would like to know where it was coded? by WindBourne · 2017-09-11 11:14 · Score: 1

Seriously, I am guessing that we will find out that it was done in India, not in America.

--
I prefer the "u" in honour as it seems to be missing these days.

"open source" as in "Java"? by doctorvo · 2017-09-11 11:18 · Score: 1

Apache Struts is a popular open-source software programming Model-View-Controller (MVC) framework for Java.

The problem there being Java.

Analogy by istartedi · 2017-09-11 11:37 · Score: 1

This is like me blaming a lock manufacturer for a theft that involved a bunch of Russian guys driving a truck up to my front door, picking the lock, and carrying off all my stuff over the course of 8 hours while I sat there getting drunk.

--
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?

Re:Analogy by ClickOnThis · 2017-09-11 12:30 · Score: 1

This is like me blaming a lock manufacturer for a theft that involved a bunch of Russian guys driving a truck up to my front door, picking the lock, and carrying off all my stuff over the course of 8 hours while I sat there getting drunk.
It's more like you blamed the lock manufacturer because they published patents showing how their lock works. Not that patents would make any difference to a lockpicker. They could find weaknesses in the design whether it was published or not.
Similarly, crackers can find exploits in software, whether the source is open or closed.
But really, we need a car analogy. This is slashdot after all.

--
If it weren't for deadlines, nothing would be late.
Re:Analogy by Anne+Thwacks · 2017-09-11 19:26 · Score: 1

OK, Its like this:
Our job is to transport the data equivalent of highly enriched Uranium. To save money, instead of getting specialists to construct secure containment vessels, we will send it by public transport. Then when people find out that the NORKs are getting on the buses, and building missiles on the back seats, we can blame the Greyhound bus company.

--
Sent from my ASR33 using ASCII

Morons running Equifax by MoarSauce123 · 2017-09-11 11:43 · Score: 1

Struts or not, the sole blame is with the greedy morons running Equifax with apparently the same take on security as they had in the year of their inception. Why do they even collect and store that much information and hold on to it for that long? I know, it is to generate a credit history, but I am sure there are equally good ways to determine if I pay my bills or not.

Re:Morons running Equifax by DidgetMaster · 2017-09-11 14:31 · Score: 1

Hopefully, the penalty in this case will be severe enough that next time this is how the typical conversation will go:

You: "We can do it cheap, or we can do it right!"

Boss: "Do it cheap."

You: "Oh, you mean like Equifax did?"

Boss: "On second thought..."
Re:Morons running Equifax by Cederic · 2017-09-11 20:44 · Score: 1

I am sure there are equally good ways to determine if I pay my bills or not.
Devise them, commercialise them, get retirement level rich.
Even if you can't be arsed running a business, just sell it to Equifax, or Experian, or Call Credit. If you can provide reliable risk indicators without needing a fuckton of data then they'll start a bidding war for you.

Look in the mirror for blame by s1d3track3D · 2017-09-11 11:48 · Score: 1

Equifax Blames Open-Source Software For Its Record-Breaking Security Breach

7. Disclaimer of Warranty. Unless required by applicable law or agreed to in writing, Licensor provides the Work (and each Contributor provides its Contributions) on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND... - Apache License

Not all financial institutions... by Roger+W+Moore · 2017-09-11 12:14 · Score: 3, Insightful

Financial institutions KNOW this.

Correction: competent financial institutions know this. Incompetent ones clearly do not and, as recent events show, it is not always easy to tell the competent from the incompetent.

Re:Not all financial institutions... by ScienceofSpock · 2017-09-11 12:30 · Score: 1

I think what you are referring to as "incompetent" financial institutions are actually just apathetic. They simply don't care about good security because it is more cost effective for them to do as little as possible because the fines don't affect their bottom line as much as providing actual security would.
We have regulations in place to try to make sure these financial institutions are NOT incompetent. They choose to not worry about the regulations because the fines don't affect them enough. We need stronger regulations.
Re:Not all financial institutions... by Hylandr · 2017-09-11 13:24 · Score: 1

It's high time that the other agencies be scrutinized. Even though the cat's out of the bag as it were.

--
~ People that think they are better than anyone else for any reason are the cause of all the strife in the world.
Re:Not all financial institutions... by Roger+W+Moore · 2017-09-12 11:47 · Score: 1

I'm not so sure apathy covers it. Their response - creating an extremely dodgy website which many people are convinced does not work - goes way past apathy and puts them firmly in the incompetent pile, at least in my opinion.

Re:class-action lawsuit? by ClickOnThis · 2017-09-11 12:19 · Score: 1

I'm just wanting to know if a lawsuit against these criminals is possible?

A class-action lawsuit is already in the works. You can find references to this in any one of many news stories.

--
If it weren't for deadlines, nothing would be late.

Security is a process by mr_shifty · 2017-09-11 12:20 · Score: 1

... not a product.

--
And the circle of life continues to spin, occasionally wobbling on its axis thanks to the weighty presence of dumb.

Confusing, not by Anonymous Coward · 2017-09-11 12:25 · Score: 1

The problem with their claim is that
Open source == inspectable so you can see the consequences of your actions.

To claim that (OS==helpless user) as a defense for your (in)actions is pretty lame.

On the surface, the facts seems to be more like

Our business model requires holding information which if made public could hurt people.
It is expensive and hard to secure this data, so let's don't.
Suprise! the data got stolen.
No problem, let offer a revenue stream ^H^H^H^H^H 'service' to help.
Oops, we got caught doing that, need new plan.
Hmmm who can we blame for our in actions?
I know, the open source community.

Hopefully, the next step will be a Congressional inquiry figuring out that the world would be better off if these folks went bankrupt.

And for sure, an understanding that a bank opening an account with this silly ID information is indefensible.

Need More Info by SwashbucklingCowboy · 2017-09-11 12:30 · Score: 1

We need more info to come to any conclusions. I've seen it claimed that Equifax wasn't using the latest version of Struts and some have thought that meant that they didn't patch to deal with the RCE from earlier this year. BUT, is it possible that what really happened is that Equifax was using Struts 1, not Struts 2? Struts 1 is EOL by the way. That wouldn't surprise me in the least.

Lick the boot too hard and you'll scuff the shine by Anonymous Coward · 2017-09-11 12:53 · Score: 1

Equifax punishes people for coincidences all the time.

Blames Struts? I blame Java.... by modmans2ndcoming · 2017-09-11 13:16 · Score: 1, Offtopic

I blame Java, not Struts......because its Java and its a pile of garbage.

Data diodes? by ka9dgx · 2017-09-11 13:20 · Score: 2

Equifax obviously has never heard of data diodes, which let data in, but not back out. Such a system could have let them accumulate data without risk of exposing all of it. They probably never heard of capability based security either, nor the principle of least privilege. They probably also use Operating Systems that rely on ambient authority to get everything done, such operating systems are wildly popular, but can't be made secure.

There's a lot of bad design decisions behind this... not just the use of Apache Struts.

Re:Data diodes? by Cederic · 2017-09-11 20:47 · Score: 1

Equifax obviously has never heard of data diodes, which let data in, but not back out
It's rather hard to offer data based services without ever letting data out.

They probably never heard of capability based security either, nor the principle of least privilege. They probably also use Operating Systems that rely on ambient authority to get everything done, such operating systems are wildly popular, but can't be made secure.
Are you an academic? Just that it doesn't sound like you have any experience at all in protecting complex real world business systems.
Re:Data diodes? by ka9dgx · 2017-09-11 22:00 · Score: 1

Re: My background/motivation:
Nope, I make gears for a living. I used to be a system administrator. The facts are that there are no fundamentally secure operating system choices in the consumer / commercial space worth considering. Windows, Linux, MacOS, none of them can be made secure, it's all just a single zero-day exploit (or old NSA toolbox) away from being owned.
The reason is that they all fail to implement the principle of least privilege, instead using ambient authority as a universal lubricant to make everything work. If the APIs didn't keep changing every year or two, it would be possible to come up with a Windows clone that implemented capabilities, and pretty much work identically as far as the user is concerned, substituting a PowerBox for dialog boxes, and giving capabilities to applications, instead of just a filename and all of the users authority. But that time has passed, the powers that be have no interest in actually securing general purpose computing.
Most of the technical community seems completely unaware of the implications of the hole in the design of their systems, and is more than ready to go along with approaches that paper over it in the short run. They deploy virus scanners, "secure" programming languages, patch Tuesdays, and/or apt-update as means to deflect problems. They blame the users, the programmers, the internet, the software vendors, hackers, hardware, spy agencies.
All of this effort at patching things, or the emotional work of blaming others is misplaced. I've got a boatload of analogies, but none of them seem to be able to break through the mindset that things will be ok if we just make this one little tweak. NOPE, won't work..
If we want to SOLVE computer security, we have to implement capability based security in our operating systems, and then modify every single program to support the new APIs that it provides. We can build things such that the users won't really notice much different, and the administration overhead actually goes down a bit. It can be done, but it's not trivial, it's an Apollo moonshot worth of effort required.
The open source community could pull off a secure OS, if it had an interest in doing so. I hope that one day, one of my many comments here on the subject sparks that discussion and interest. I think we're still 10 years out... people haven't suffered enough yet.
As for the original question:
Data diodes can, in hardware, allow for physically secure data ingress. Equifax could use one to allow reporting into their systems, which is the bulk of the information flow. They could then use another to allow requests inbound for customer queries, and then another one for the outbound results of those queries. All of the outbound results would be in one easy to monitor flow. No other egress would be possible. Thus they could then know the type and flow rates that are normal... and cut it off if the rates get exceeded, possibly even in an automated manner.
Data diodes aren't cheap, because they are specialized devices, but it should be possible to craft one out of a few Raspberry Pi computers for about $200, if you don't have a large flow of data to secure. They are definitely within the reach of the open source community to pull off.
Re:Data diodes? by Ash-Fox · 2017-09-11 23:16 · Score: 1

The facts are that there are no fundamentally secure operating system choices in the consumer / commercial space worth considering. Windows, Linux, MacOS, none of them can be made secure, it's all just a single zero-day exploit (or old NSA toolbox) away from being owned.
I agree that making a secure system is very difficult.

The reason is that they all fail to implement the principle of least privilege, instead using ambient authority as a universal lubricant to make everything work.
But Ubuntu went through the process of applying that by making sure all default and core daemons run under their own user instead of 'root', along with building app armor to ensure these principles were applied across the board with apparmor profiles for core packages.

If we want to SOLVE computer security, we have to implement capability based security in our operating systems, and then modify every single program to support the new APIs that it provides.
This is AppArmor again and has been in Ubuntu for many years now.

--
Change is certain; progress is not obligatory.
Re:Data diodes? by ka9dgx · 2017-09-11 23:33 · Score: 1

AppArmor is a step in the right direction, but it's not Capability Based Security. With Capabilities, you hand a capability (much like a file handle) to a program, instead of giving it all the users permissions. This eliminates the need for an administrator to set up a bunch of rules on top of a system, and just lets the user handle it in a more transparent manner.
AppArmor is good, but it puts a lot of load on administrators to make up for a design flaw in Linux.
Re:Data diodes? by Cederic · 2017-09-12 00:25 · Score: 1

The reason is that they all fail to implement the principle of least privilege
The application required data access rights. Its least privilege included access to data. Once it was compromised, so was the data.
Could things be more secure? Of course. Switch the fucking thing off, it's more secure. There's a risk/cost equation and right now the risks don't (in business terms) justify the extra cost of excessive security.

Data diodes can, in hardware, allow for physically secure data ingress. Equifax could use one to allow reporting into their systems, which is the bulk of the information flow. They could then use another to allow requests inbound for customer queries, and then another one for the outbound results of those queries. All of the outbound results would be in one easy to monitor flow. No other egress would be possible. Thus they could then know the type and flow rates that are normal... and cut it off if the rates get exceeded, possibly even in an automated manner.
We don't know which part of the data flow was compromised. It could be any of those three, or others, and a data diode wouldn't have prevented the compromise.
Rate and flow monitoring were hopefully in place but a sensible attacker will draw data incrementally to avoid triggering alerts - Equifax have said the hack was in place for several weeks, so that's a relatively low number of records/hour, given their likely normal traffic.
Without further detail it's hard to pinpoint the measures that would've saved them. It may have been a passive intercept, capturing data traversing a link or system interaction, then passing the captured data back via a side channel. If you've got access at the application layer then you have a large number of options available to you on how to achieve that, some of which would be almost impossible to detect through standard tooling.
Re:Data diodes? by Ash-Fox · 2017-09-12 01:08 · Score: 1

With Capabilities, you hand a capability (much like a file handle) to a program, instead of giving it all the users permissions.
You can litterally do that with AppArmor profiles though?

This eliminates the need for an administrator to set up a bunch of rules on top of a system
These rules are provided for AppArmor by default through installation of related packages (ie: tomcat).

and just lets the user handle it in a more transparent manner.
Security based on prompting the user is not useful on a server, which is what is being discussed here when it comes to for "data based services" as described by Cederic.

--
Change is certain; progress is not obligatory.
Re:Data diodes? by ka9dgx · 2017-09-12 13:53 · Score: 1

True enough, prompting a user isn't going to help much on a server. Capabilities offer a way to make sure a process only accesses the appropriate files and folders, and nothing else, without having to have an administrator set the permissions on everything to make that happen. Having a default of no access is far, far easier to secure, making it easy to limit the possible side effects (and side channels of data exfiltration) for any given task.

Heh... by XSportSeeker · 2017-09-11 13:22 · Score: 1

Data was leaked, management enjoyed a great round of insider trading, they botched up the page for verifying if your information was leaked, and now the most obvious next step: scapegoating.

What can we expect next? Shut up settlements after a long protracted court battle meant to make people forget about it, slap on the wrist from government/justice, just for the next rounds of leak to prove that they have learned nothing.

Equifax hack is the end of privacy even for those who are careful about it. You can be as paranoid as you want to, once your personal sensitive data is being taken and stored by companies that are this careless about it, it's over.

Oooh, but an open source software had an exploit in it. That's what they have to say? Motherfuckers, ALL software potentially has exploits in them. It's why for sensitive data competent companies employ several layers of security so that even if parts of it fail, attackers still won't have access to it. You are not a fucking backyard business or some kid's lemonade stand. If you are going to claim this level of ignorance for leaking all that data out, the rational decision would be closing doors down, getting out of the fucking market, and leave it to grown ups to handle since you are clearly too incompetent to do so.

Blame by Archon · 2017-09-11 13:39 · Score: 1

So they get a Commodore-64 and some big floppy drives and put our SSNs on that, because *reasons*.
Then when it's breached they point to the C64 and say, "well, look what we had to work with."

Doesn't work that way, but we're not their customers. So fuck us.

Who put it on the 'net? by guruevi · 2017-09-11 13:41 · Score: 1

Regardless of the system you use, setting up a system like this directly on the Internet is what's to blame. Obviously it's a little more expensive to develop a proper web application and checks and balances on what it can do but no part that is not the "View" should be online.

--
Custom electronics and digital signage for your business: www.evcircuits.com

Never trust odd version numbers. by fahrbot-bot · 2017-09-11 13:50 · Score: 1

Adding insult to injury, the credit agency's advice and support site looks, at first glance, to be a bogus, phishing-type site: "equifaxsecurity2017.com."

We should wait for the "equifaxsecurity2018.com" release.

--
It must have been something you assimilated. . . .

Re:Never trust odd version numbers. by coofercat · 2017-09-12 00:30 · Score: 1

Looks like that domain's been taken already. equifaxsecuritysucks.com is still free though ;-)

Open source software blamed for the breach huh? by UltraZelda64 · 2017-09-11 17:22 · Score: 1

I wonder what they used for their horribly broken website https://www.equifaxsecurity201..., which can't even seem to reliably tell you if you were affected by the incident. But I'm not surprised that a company with such shitty security to allow practically all adult Americans' identities to be exposed can't even get their check to find out if you have been exposed right. But, based on the numbers, and subtract everyone who does not have a credit history (age 17 and under), it's safe to assume that *every* U.S. citizen with a credit history has to watch their asses from here on, for the rest of their life. Is Equifax going to blame open source software for that piece of shit site/impact checker too? Equifax... what a fucking joke.

Re:Open source software blamed for the breach huh? by Ash-Fox · 2017-09-11 23:11 · Score: 1

which can't even seem to reliably tell you if you were affected by the incident.
It seemed to work for me?

Thank You
Based on the information provided, we believe that your personal information was not impacted by this incident.
Click the button below to continue your enrollment in TrustedID Premier.

--
Change is certain; progress is not obligatory.
Re:Open source software blamed for the breach huh? by david_thornley · 2017-09-12 05:04 · Score: 1

Good for you. The web page just hung for me.

--
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
Re:Open source software blamed for the breach huh? by UltraZelda64 · 2017-09-12 16:16 · Score: 1

It does not give a reliable answer. It has been found to give seemingly-random answers. Don't rely on it.
Based on the U.S. population, minus people without a credit history (including everyone under 18), and number of people Equifax has announced to have had their data stolen (officially over 143 million), it is best that if you have any credit history at all... then you should probably consider yourself f***ed. Don't trust their little "tool." It's about as big of a joke as their security itself.

It's cheap for us to inspect the tools daily by raymorris · 2017-09-11 17:36 · Score: 4, Interesting

For a thousand bucks or so, Equifax could have had our company inspecting their tools daily, scanning for any accessible systems with security issues, including the issues in the Struts plugins.

We would have also provided them with detection systems that would have caught the attempt to load the massive amount of data via the vulnerability, and systems to detect the attempt to exfiltrate the data, again at a very reasonable cost. These include 24/7 monitoring by our SOC. So if they had been even competent enough to simply sign up with a decent security provider, they would have been protected three times over.

ALL software beyond "hello world" has bugs.* A competent CIO, or even a competent programmer or network engineer, knows that and plans accordingly. Any CIO or CSO whose security planning pretends that there server software is perfect is incompetent. A software bug didn't cause this - plenty of other organizations used the same software, but didn't get breached because they had scanning and alerting set up, so they mitigated the flaw immediately after it became known.

*. All software has flaws, and well known proprietary software such as Windows, MS Office, Flash, and Oracle Java are an order of magnitude worse than well known open source software such as Linux, Libre office, Apache httpd, etc. My database I manage at work has almost every known vulnerability cataloged and rated for several measurements of severity. There's no comparison - there simply is not pride of workmanship in code nobody is allowed to see. Open source programmers know they are being judged personally for the code they put on display and it makes a HUGE difference in code quality.

Re:It's cheap for us to inspect the tools daily by conquistadorst · 2017-09-12 01:17 · Score: 1

For a thousand bucks or so, Equifax could have had our company inspecting their tools daily, scanning for any accessible systems with security issues, including the issues in the Struts plugins.
I mean that's nice to get a report of vulnerabilities but what about actually patching them up. My company uses services like yours, and yet we have servers staying unpatched for more than a decade. Sure, there are mitigating protocols put into place but there's just so much "technical debt" with old software, servers, processes. Companies don't want to pony up the costs and resources to fix this crap. Good intentions are failing to keep companies secure, perhaps it's time to talk beyond costs and penalties and bring some real punishments into the picture?
Re:It's cheap for us to inspect the tools daily by RobTowne · 2017-09-12 04:30 · Score: 1

The company I worked for had yearly pen tests and security audits done. Every year they found a vulnerability that the boss would not fix since the cost was new hardware due to a program that was written that required upgrade. Poor Code left the door open on the network, luckily it was never exploited that we know of. Essentially it was a Ruby Gem that was outdated and the whole program would need to be recoded to fix the vulnerability. From the Network perspective the Routers, Firewalls and Hypervisors were patched regularly but the software that had access through them had a huge hole.... Leaving anyone that used the software a potential target to get through.
Re:It's cheap for us to inspect the tools daily by sydbarrett74 · 2017-09-12 21:50 · Score: 1

Another consideration is that FOSS projects aren't driven by marketing droids to the degree that proprietary products are. When the marketing department sets the deadlines, quality suffers drastically. Marketeers make useful servants but dreadful masters.

--
'He who has to break a thing to find out what it is, has left the path of wisdom.' -- Gandalf to Saruman

You all get it wrong by jarle.aase · 2017-09-11 17:46 · Score: 1

They just wanted to get in the guinness book of records...

Re:Lick the boot too hard and you'll scuff the shi by Anne+Thwacks · 2017-09-11 18:53 · Score: 1

Equifux punishes people because of their own blunders and corrupt database contents all the time.

In other news, Granny said "don't put all your eggs in one basket".

Why was their data not compartmentalised? Its not that hard to do, and ought to be compulsory for data on this scale.

Public floggings are totally inadequate for scum like this. These people are a clear and present danger to civilisation as we know it, even in the absence of data loss like this. Now is the time to make this obvious to everyone.

--
Sent from my ASR33 using ASCII

Re: No, no, the root issue... by Anne+Thwacks · 2017-09-11 19:02 · Score: 1

There is a difference between profits and conspiracy to defraud, even if Trump supporters don't know..

--
Sent from my ASR33 using ASCII

Re:Lick the boot too hard and you'll scuff the shi by Cederic · 2017-09-11 20:12 · Score: 1

Really? How? What punishments does Equifax dole out?

Clearly their US business differs from the one in the UK.

Governance failure is root cause by Martin+S. · 2017-09-11 22:04 · Score: 1

The exploit is not the root cause, the exploit only became possible in a live environment because they failed to properly follow governance processes during development.

Re:Governance failure is root cause by david_thornley · 2017-09-12 05:05 · Score: 1

That sounds an awful lot like MBA talk. Smile when you say that, pardner!

--
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes

Re:Lick the boot too hard and you'll scuff the shi by oobayly · 2017-09-11 23:46 · Score: 2

You could argue that by giving somebody a [false] bad credit rating (by carelessly using a different John Smith's records, or simply because they haven't borrowed enough money in the past) they are punishing that person. It's something that happens regularly and costs those people money, yet credit agencies are rarely taken to task over their conduct.

The Problem Is Probability by ytene · 2017-09-12 00:05 · Score: 1

Lots of excellent discussion here, but perhaps there is another aspect of this to consider...

Think about all the really big issues that have happened with financial institutions over the last 10-15 years, such as:-

1. Nick Leeson at Barings [lost his employer an estimated $1.4 Billion in 1995]
2. Jerome Kervial at Societe Generale [lost his employer $7 Billion in 2007]
3. Bruno Iksil at JPMorgan [lost his employer an estimate $7 Billion in 2012]

In fact, if you're interested, there is a complete ranking at Wikipedia:-

https://en.wikipedia.org/wiki/...

What this shows us is that all of the biggest losses [and at this point I will concede that the Wikipedia article lists only trading losses, but these are by far the largest, financially-impacting losses we observe] come not from data security issues, or software vulnerabilities, but from an absolute lack of fundamental operational controls on the financial side of the institutions that have experienced these losses.

Yes, it is true to say that "because: Cyber" seems to have created a bit more interest in boardrooms around the world, but the cold, hard fact remains that the vast majority of losses [whether numerically or by value] originate from operational control failures, not IT Security. This being the case, when an institution comes to look at safeguards, IT and Cyber Security controls are almost always going to play "second fiddle" to the operational risks the institution carries.

Having worked for both blue chip companies and financial institutions for the last ~ 30 years, my own personal experience is that IT Controls are generally seen as a poor relation to Operational Controls - and attract budgets and resources accordingly. As an IT professional with many years working in IT Security, IT Risk Management and Cyber Security, I would like to see cyber risk treated more seriously by large corporations. Unfortunately, in the absence of actual, head-line grabbing real-world examples of multi-billion-dollar losses from cyber events, the institutions carrying these risks will consider them to be "black swan" events - undeniably high risk, but so rare as to be irrelevant... until they are themselves hit.

The only way to ensure that the information of private citizens is adequately protected by the corporations that hold and process it is to follow up incidents such as this with hard-hitting fines, along with jail time for relevant executives [CEO, CIO, CTO]. Unless we see that happen [and just consider for a moment the likely lobbying effort against this] then there will be no safety and no recourse for individually impacted citizens.

Some may be thinking that perhaps legislation like the Sarbanes-Oxley Act [and clause 404 of that bill] might be sufficient to address the gap. The sad fact is that, in the 15 years since it was introduced, SOX has become a "paper exercise". There is no evidence to suggest that anything equivalent but addressing data breaches would be any more useful 15 years from now.

Unless something fundamentally changes, the balance of probability will condemn this particular topic to irrelevance.

in depth by jbmartin6 · 2017-09-12 00:48 · Score: 1

Defense in depth is an applicable concept here. A single point is going to have weaknesses. While a Struts vulnerability may have been involved, there is a whole iceberg of failures below that on the Equifax side for the breach to reach this scale. It is hard to say what level of failure though without any details. "May have been impacted" is not the same as 100 million people victimized by identity theft.

--
This posting is provided 'AS IS' without warranty of any kind, implied or otherwise.

Security Joke by sdinfoserv · 2017-09-12 00:55 · Score: 1

Red the Equifax annual report on their website - it's all about revenue growth (18%), new markets and reducing expenses... Looking at the people, the CIO has a Bachelors degree in Russian and Masters degree in Business Administration. The other "techie", President of Information Solutions, is a Harvard lawyer.
http://www.equifax.com/about-e...
Now it has come out that top management unloaded stock post breach, but before public announcement.
We have a corporation dealing with personal information with zero security core competency at the top, and devoid of moral principal AND willingness to commit crimes for personal gain.
THIS is the exact type of corporation and players that needs to be crushed and go away, like Arthur Anderson, or Daryl McBride.

Re:Security Joke by ytene · 2017-09-12 01:42 · Score: 1

*Darl* McBride, but yes, agreed...
Re:Security Joke by david_thornley · 2017-09-12 05:12 · Score: 1

The annual report is intended to be read by investors, not geeks.
In an organization, management doesn't have to have all the expertise of the people doing the work. When you get to the C level, it can be reasonable to have an executive who doesn't really understand what's going on. The executive had better know that he or she doesn't understand what he or she is in charge of, and get good people and trust them. (I've seen that work nicely.) Somebody has to argue about the budget and present business value and such. A section of the company might be better run by a good business person who trusts subordinates.

--
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes

Pretty limp excuse... by Timothy2.0 · 2017-09-12 01:13 · Score: 1

If you adopt open-source software as an underlying framework for your system which stores highly sensitive information, then you take all the time you need to audit the code to ensure that your highly-sensitive information is secure before you go live.

It's *the firm's* responsibility to ensure their infrastructure is secure, not anyone else, and if they decide to use infrastructure X on a production server, the outcomes are on *their* ass.

Re:Pretty limp excuse... by david_thornley · 2017-09-12 05:14 · Score: 1

I don't care whether the software was Free or proprietary. Equifax decided what software to use out of numerous alternatives, so from my point of view it's their software system. It's easier to audit open source, but a company can make arrangements to audit a potential vendor's software, or negotiate some sort of trust.

--
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes

Naturally. by Christinagirl1 · 2017-09-12 02:42 · Score: 1

They chose to use it! So naturally, it's someone else's fault. I am so sick of this shit! They are all parasites. And the US government never did anything about it because they too, want all of your data so they can bypass the intention of the US constitution. I'll add that this breach should discredit everything the credit bureau's have collected. It proves they have no control over their data and that most of it can be manipulated and controlled on behalf of big corporations. Congress, what the hell are you doing? If anything.

About costs, what works for fire safety is by raymorris · 2017-09-12 03:09 · Score: 5, Insightful

> Companies don't want to pony up the costs and resources to fix this crap. Good intentions are failing to keep companies secure

Fire safety was a similar issue a hundred years ago. The insurance companies created Underwriters Laboratories (UL Listed) and the National Fire Protection Association, which writes the fire code. Companies buy insurance against fire, and their insurance company, in order to reduce their own cost of claims, insists that the companies meet fire codes and otherwise operate safely to minimize the risk of fire. That has worked well.

The costs are a very real and legitimate issue. A magazine publisher should NOT spend $50 million to protect from the names of their subscribers being leaked. The cost would be too high relative to the risk. Spending too much on security is a mistake just as spending too little is. Spending on security increases costs, it makes products and services cost more for the consumer. It's all about calculating the *right* amount of spending to mitigate the risk by the right amount.

As it happens, insurance companies are experts at calculating risks and costs. I expect over time they'll get involved in cyber security in a similar way as they are involved in greatly reducing fire risk.

Re:About costs, what works for fire safety is by gaudior · 2017-09-12 04:50 · Score: 1

It's a real shame you are not getting modded up. This is the best course of action I can see for fixing these kinds of problems, especially when people's lives are at stake. Screwing up a person's finances can be more damaging than a faulty toaster.
Re:About costs, what works for fire safety is by conquistadorst · 2017-09-13 00:57 · Score: 2

>
As it happens, insurance companies are experts at calculating risks and costs. I expect over time they'll get involved in cyber security in a similar way as they are involved in greatly reducing fire risk.
That's quite an imperfect analogy. You're comparing products they sell and underwrite vs their own personal best practices, but let's ignore that for now because regardless the cyber experience is just not there at insurance companies right now. Insurance companies, even those like mine offering cyber coverage, don't have boots on the ground like they did for fire & allied lines. When it comes to fire, insurance companies employ (and still have) claims adjusters who had physical experience from looking at properties damaged in fires and investigating their causes. They do outsource sometimes too but a majority of the time they don't. Should they be hiring claims adjusters that are experienced in cyber forensics? Yes, I'm surprised they're not. Maybe they will *someday* but they don't right now. At my company they rely on outsourcing *all of it* it. The elephant in the room we're all being forced to see here is cyber attacks carry a far steeper and more dynamic sophistication than fires. Don't get me wrong, fires are sophisticated but it's a completely different playing field. I don't think we have to go through the laundry list of why they're so different but we can.
In fact, I'm actually going to take your example and use it to beat you to death with it. Let me point out terribly unfortunate flaws. Insurance companies first started covering fire in the early 1700's. The UL wasn't founded until 1896 and the NFPA wasn't founded until 1896. Yes, that's almost 200 years later. YIKES. So those organizations make awfully terrible examples of "prowess" by insurance companies. As an insider I can tell you when it comes to technology insurance companies lag the rest of the world, not the other way around. But you are right they will figure it out, eventually.

Modularity and microservices by raymorris · 2017-09-12 07:10 · Score: 1

> the cost was new hardware due to a program that was written ... Essentially it was a Ruby Gem that was outdated and the whole program would need to be recoded to fix the vulnerability.

And this was why we write software as modules, even microservices, rather than a huge monolithic pile of code. With proper abstraction and encapsulation, a bad problem means that specific 12-line function, or at worst the entire 350-line module, needs to be redone.

Some good points, some misunderstandings by raymorris · 2017-09-13 07:34 · Score: 1

> You're comparing products they sell and underwrite vs their own personal best practices

No, I'm comparing internal operating standards with internal operating standards. At my office, we had a fire inspector come through once every two years and look for extension cords being used improperly and that sort of thing. Passing the fire safety inspection lowered the insurance costs that the company paid. Management took care that we did well on the inspection, so that they would get the lower insurance rate.

We ALSO had a cyber security inspection / audit. The results of that inspection did not, however, affect our insurance costs. Therefore the security inspection was less important.

You are of course correct that fire insurance existed long before UL and NFPA, though not so long in the US. The point is that when they did take proactive measures such as UL and NFPA, it worked well - and they know that. They know that if they are going to insure a major office building, they are going to insist on fire safety. Knowing that, having that experience, they can use the results of cyber security inspections in setting rates.

Whether the inspection is outsourced or done by W-2 employees of the insurance company isn't the point. The point is they are starting to expect a passing security audit. Companies are beginning to pay attention to security in order to reduce costs, and hopefully we'll see that trend expand.

Flaw in front-facing shouldn't allow this by illtud · 2017-09-15 09:59 · Score: 1

[OK, I'm late to this, but haven't seen this point made]

Even if it was a vulnerability in the front-end (in a DMZ, I hope), a totally compromised front-end shouldn't have allowed anybody to exfiltrate that much data. The backend should be locked down with methods that allow the front-end to access only one per call, and access patterns monitored to disallow harvesting. The actual data should be at least another step away, and encrypted in case anybody steals a the whole as a blob. There's bad architecture here, regardless of any owning of a public-facing website. This might have been a long-drawn out slow exfiltration, but it doesn't sound like it. The whole infrastructure may have been owned, but again, that can't be blamed solely (or even mostly) on any vulnerability in the top layer.

Slashdot Mirror

Equifax Blames Open-Source Software For Its Record-Breaking Security Breach (zdnet.com)

190 of 283 comments (clear)