Furthermore, do you have evidence that the PII was improperly stored, or that Equifax's security practices were lacking in any way? The vulnerability provided full RCE, and I know of no info-sec magic that inoculates you against that.
I'm wondering if Equifax is using Struts-provided REST for its entire architecture. If that's the case, gaining access to the web server was only the first step. From there the attacker could perform RCE on sensitive services.
You may want to think twice. Try to design an architecture that doesn't have that. If you think it through, you'll realize the best you can do is not to deny access, but to monitor access so that any statistical deviation in requests-per-hour will trigger an alarm. Yet nobody does that, so why should Equifax have been a pioneer in this method?
This is the uncomfortable truth that everyone is obscuring here. There wasn't a solution. Equifax got owned, and they happened to have a trove of data. Everyone now wants to see their heads roll, but you too would find yourself in the same situation if you have an RCE on your servers.
We have an architecture like that where I work. It's not that hard. Our web applications have very little direct access to databases; most of it is mediated by services downstream of the web app. That's certainly not a silver bullet, but it makes it impossible to exploit a RCE vuln in the web server in such a way that it lets you have arbitrary access to the database.
Once you've compromised a server, learning how to ask for the data you want is not hard. You have access to all the webserver's code, can make full dumps of communications occurring normally in the app, etc.
Of course, another option would be to use the web server compromise to then jump to the database service and compromise that box as well, but, again, more hurdles to jump means less of a chance of success.
Nothing is perfectly secure, but you can design systems with defense in both breadth and depth, and you can slow down or defeat many attackers that way. It's not about making Fort Knox, it's just about making breaking in more expensive than they can handle.
That means, barring other exploits, you can only access the info from the users who logged in while you had control of the machine.
It occurs to me that maybe it might seem like pivoting is a big process that takes months. In reality you can map out an internal network within a few hours. Most people keep the servers at the edge of their network meticulously up to date. Once you're inside, you find way more old software. Not to mention creds just laying around the system in many cases since the devs don't expect anybody to be able to access them.
I feel like the worst offense Equifax could be accused of is not getting regular pentests. A netpen would have caught the outdated Struts issue, and they had money to get monthly tests. But very few of us get regular pentests.
We do have monthly tests, scans, and network BGP issues. And our governmental side has a different set of scans, which also include system security scans.
Whomever the oncall is, ends up doing them during the week. It's usually pretty quick, but can turn into a slog.
Oh, and all our machines are updated appropriately, not just the border machines. There are some services we're not able to adequately update, like FreeRadius - but for each of those we review the criticality and determine if we need the resources to make it work (aka: remote priv exploit)
For one.
If the vulnerability used turns out to be the Struts one that was announced at the beginning of the year, then the "magic" here would have been quite muggle-like: update the damn dependency. Not doing so is negligence, plain and simple.
(I agree with you, though, that EFX will almost certainly come out of this relatively unscathed.)
In retrospect it seems more cost effective to do so too, even if Equifax manages somehow to pay only a few hundred million dollars.
The argument would be that the very fact that PII security was breached demonstrates defendant's negligent data storage/security practices. If those practices had been adequate, the breach would not have occurred.
But I think higher expectations, helped along with civil legal machinery that's likely to mete out meaningful punishment, would move us faster to finding out whether the problems are mostly just sloppy practice (which responds to economic penalties) or whether they're more fundamental and need a different fix.
Going long may make sense but we've not hit bottom yet.
Not really accurate because the exploit name, especially as generic as RCE, does not tell you how it was done. RCE can be a number of things that can be fixed in numerous ways. For example, file upload functionality with path manipulation and no file type validation may lead to RCE. This can certainly be removed with properly crafted file upload handling.
Some RCE, particularly on lower layers of the application stack, may be more difficult to defend against, especially in the case of unknown exploits.
The webservers should be treated as if they're potentially compromised, not given arbitrary access to a database...
Specifically: if you're working with a lot of very sensitive information, you structure your application such that there are multiple layers separating that data from the outside world. In the case of Equifax, that might mean implementing the "credit score check" as an internal service exposed through the public web servers (or whatever).
* Credential vaults that allow only-once retrieval on application startup and only keep credentials in memory
* anomaly detectors for request patterns (suspicious payload formats, processing time, CPU/memory usage, etc),
* Honeypot records in sensitive data stores (records you know should never be accessed, if they are you've been breached)
If you're storing information this sensitive you need to be paranoid, because an attacker has a $4B incentive ($30/identity on the black market * 143 million records) to crack your systems.
It seems amazing that nothing tripped up some monitoring or something.