Slashdot Mirror
Equifax Blames Open-Source Software For Its Record-Breaking Security Breach (zdnet.com)
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.
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.
Comment removed based on user account deletion
They have NO ONE to blame but themselves, it is OPEN SOURCE which means they can actually review the code and fix issue.
>> 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.
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.
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!
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.
"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.
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
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.
> 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.