There are only two ways I see Equifax surviving. The first is if it "persuades" Congress to shelter it similar to the way Congress sheltered gun manufacturers. I'm not sure it has that sort of bribe money handy. The second is through a Johns-Manville type bankruptcy, where it creates a trust to pay off victims. But this isn't a situation where they can file a "tidy" prepackaged bankruptcy. So once they file, what form the restructuring or liquidation takes is anyone's guess.
So given that I believe Equifax must die, what can the rest of the tech industry learn from it? Here are my thoughts.
A lot of people are slamming Equifax for not patching their system once the vulnerability became public. But so-called "best practices" for Patch Management strongly suggest a delay before deployment, just in case the cure is worse than the disease. You can find the NIST document on the subject here.
That document is little changed from its 2005 predecessor, while the nature and severity of threats has changed immensely. As a result, corporate security groups have grown both in size and visibility. Inevitably with such growth, process replaces common sense in decision making. So while the NIST document does state, "in some operational environments, such as virtual hosts with snapshot capabilities enabled, it may be preferable to patch without testing as long as the organization is fully prepared to roll back the patches if they cause usability or functionality problems," suggesting such action becomes a career-limiting move.
I'm willing to bet that the patch for this particular vulnerability was "in the pipeline" at Equifax. Nor, from my experience, is a two month delay anything unusual in a large company. All that process, meetings, and documentation take time, after all, and any patches outside of a scheduled deployment "window" requires even more approvals.
While it's easy to say that this mindset should change, history shows us that it's nearly impossible. Large organizations are never going to be as nimble as a start-up, let alone as nimble as a small group of "bad guys." So while Equifax should have been able to reduce the window of vulnerability to, say, 2 weeks instead of 2 months, I fear that window will always exist.
Open Source Software
The software bug which gave the "bad guys" access to Equifax was in an open source project called Apache Struts. It was one of two critical software bugs found in that project so far this year. The source code for Struts is available online, for free, for anyone who cares enough to look at it. The bad news is that there is no way to hide weaknesses from "bad guys" with the skill to find them. But that also means there is no way to sweep weaknesses "under the rug," and no incentive for a developer to hide them. It is one of the axioms of open-source software that this benefit outweighs the risk, since bugs get detected and fixed sooner.
Whether open-source software in general is more or less secure than proprietary software is a continuing debate. But I think these Struts exploits show a weakness in the open-source assumptions. Struts is, shall we say, a "mature" offering. It's widely used, but there's no real excitement or positive "buzz" about it in technological circles. There's not a lot of "egoboo" or career advantage in contributing to the Struts project anymore. The combination of widespread adoption, source code access and developer ennui makes it an ideal target for hackers.
Speaking in generalities, software developers seek out the "latest and greatest" technology, while management types will often preferred "tried and true" solutions to reduce risk. Both viewpoints are valid, but like every product, software has a shelf life. With commercial software, the need to move off of stale software can be enforced by the vendor discontinuing support or simply going out of business. But I think the industry has to pay more attention to these "stale" open source efforts as well.
Beyond the Exploit
Through the CVE-2017-5638 exploit, the "bad guys" obtained the ability to execute arbitrary commands on Equifax's public facing servers. This is never good, but everyone knows it can happen. Once again, there are a series of "best practices" for such systems, and I have little doubt that Equifax's CIO thought they were using them. And indeed, the "best practices" do guard against a variety of once-common threats.
But here's the thing. The exploit could only give unlimited access to the attacker if it was running with administrative, or "root" privileges. Those "best practices" state that server-side software should run under an account with as few permissions as possible. Nor should any of those commands allowed access to other systems except through a controlled number of paths, and none of those paths should have allowed access to large quantities of data at a time.
Equifax is doomed to become a case study of "insecurity by design." Border security alone is never sufficient; for a high-profile target like a credit reporting agency, it has to be though of at every step of the process. For example, putting a database "behind the inner firewall" is useless if the DMZ machines can make arbitrary queries. Sanitizing inputs to prevent "little Bobby Tables" attacks is well and good, but once you reach a certain risk level, further measures are needed.
While the gory details will come out in due time, I strongly suggest that anyone with a large store of valuable or sensitive data take a very hard look at how that data can be accessed.