Equifax Blames Open-Source Software For Its Record-Breaking Security Breach (zdnet.com) 283
The blame for the record-breaking cybersecurity breach that affects at least 143 million people falls on the open-source server framework, Apache Struts, according to an unsubstantiated report by equity research firm Baird. The firm's source, per one report, is believed to be Equifax. ZDNet reports: Apache Struts is a popular open-source software programming Model-View-Controller (MVC) framework for Java. It is not, as some headlines have had it, a vendor software program. It's also not proven that Struts was the source of the hole the hackers drove through. In fact, several headlines -- some of which have since been retracted -- all source a single quote by a non-technical analyst from an Equifax source. Not only is that troubling journalistically, it's problematic from a technical point of view. In case you haven't noticed, Equifax appears to be utterly and completely clueless about their own technology. Equifax's own data breach detector isn't just useless: it's untrustworthy. 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." That domain name screams fake. And what does it ask for if you go there? The last six figures of your social security number and last name. In other words, exactly the kind of information a hacker might ask for. Equifax's technical expertise, it has been shown, is less than acceptable. Could the root cause of the hack be a Struts security hole? Two days before the Equifax breach was reported, ZDNet reported a new and significant Struts security problem. While many jumped on this as the security hole, Equifax admitted hackers had broken in between mid-May through July, long before the most recent Struts flaw was revealed. "It's possible that the hackers found the hole on their own, but zero-day exploits aren't that common," reports ZDNet. "It's far more likely that -- if the problem was indeed with Struts -- it was with a separate but equally serious security problem in Struts, first patched in March." The question then becomes: is it the fault of Struts developers or Equifax's developers, system admins, and their management? "The people who ran the code with a known 'total compromise of system integrity' should get the blame," reports ZDNet.
A poor carpenter... (Score:5, Funny)
Always blames his tools.
Comment removed (Score:5, Insightful)
Re: (Score:3)
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 kil
Re:A poor carpenter... (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.
Not all financial institutions... (Score:4, 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: (Score:2)
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 stron
Re: (Score:2)
It's high time that the other agencies be scrutinized. Even though the cat's out of the bag as it were.
Re:A poor carpenter... (Score:5, 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... (Score:5, 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... (Score:4, 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.
Re: (Score:3, Insightful)
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 [xkcd.com], etc). Plus, the practicality of actually deploying one ti
Re:A poor carpenter... (Score:4, 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).
Re: (Score:3)
Re: (Score:3)
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: (Score:2)
This breach is bad enough that Equifax officers should see significant jailtime.
Re: (Score:2)
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.
Re: (Score:2)
Really? How? What punishments does Equifax dole out?
Clearly their US business differs from the one in the UK.
Re: (Score:3)
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.
Re: (Score:2)
Always blames his tools.
In that incomplete analogy, I think a web framework is more analogous to materials than tools.
Re: (Score:2)
And a good carpenter can spot when a tool is gimmicky shit or poorly made. Every tool is not a good tool.
It's cheap for us to inspect the tools daily (Score:5, 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.
About costs, what works for fire safety is (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: (Score:3)
>
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 looki
Blame the software not the License. (Score:5, 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.
Re: (Score:2)
How the product is licensed doesn't affect the quality of the software.
It certainly does influence management and priorities of the product.
Re: (Score:2)
You haven't thought that through. At all.
Don't appear to know how web servers work or security breaches happen.
Re: (Score:3)
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.
Re: (Score:2)
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: (Score:2)
It is open source ... (Score:5, Insightful)
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
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: (Score:2)
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 ... (Score:4, 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.
JAVA! (Score:3, Interesting)
>Model-View-Controller (MVC) framework for Java
There's your problem right there.
Security demands simplicity.
Re: JAVA! (Score:2)
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. ;)
Re: (Score:2)
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: (Score:3)
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 thi
Yes Yes (Score:5, Funny)
The cost of doing business online (Score:2)
Equifax Corporate Officers (Score:5, Insightful)
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: (Score:2)
There is no way the CTO gets out of this with his job.
Re: (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 abandonwar
Re: (Score:2)
equifaxsecurity2017.com (Score:2, Informative)
Re: (Score:2)
Re: (Score:3)
Root cause = SJW hiring practices (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 (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 (Score:4, 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 [ihypocrite.net]. 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.
Re: (Score:2)
Re: (Score:2)
Posting to remove moderation. I thought you were trolling until someone actually posted the link about her career.
Struts Fault? (Score:3)
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? CORRECTION (Score:2)
credit collection businesses
I should have said
credit reporting businesses
Re: (Score:3)
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
I have a bridge to sell you
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
However, it is still known that they WERE notified prior.
Re: (Score:2)
Re: (Score:2)
According to this article, [bloomberg.com] 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.
Re: (Score:2)
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.
Re: (Score:2)
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: (Score:2)
He's work
Re: (Score:2)
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
Don't store data unencrypted! (Score:2, 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.
Re: Don't store data unencrypted! (Score:2)
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?
Re: (Score:2)
Re: (Score:2)
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 phys
Well they're entitled (Score:3)
Well they're entitled to ask for a full refund of whatever they paid for it.
Not confirmed (Score:2)
Re: (Score:2)
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.
They are missing the point of open source. (Score:2)
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.
Sure, Struts from 2003 (Score:2)
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 r
Re: (Score:2)
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 abou
I would like to know where it was coded? (Score:2)
"open source" as in "Java"? (Score:2)
The problem there being Java.
Analogy (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
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.
Morons running Equifax (Score:2)
Re: (Score:2)
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: (Score:2)
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 (Score:2)
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
Security is a process (Score:2)
... not a product.
Need More Info (Score:2)
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.
Blames Struts? I blame Java.... (Score:2, Offtopic)
Data diodes? (Score:3)
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: (Score:2)
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: (Score:2)
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
Heh... (Score:2)
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
Who put it on the 'net? (Score:2)
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.
Never trust odd version numbers. (Score:2)
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.
Open source software blamed for the breach huh? (Score:2)
I wonder what they used for their horribly broken website https://www.equifaxsecurity201... [equifaxsecurity2017.com], 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
Governance failure is root cause (Score:2)
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: (Score:2)
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.
Re: (Score:3)
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: (Score:2, Funny)
Hmm not sure about this story. Can you link me to a Amazon book about this scenario?
Re: (Score:2)
Maybe it was global warming. Or Trump.
Re: (Score:2)
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.