[upstarter]

> The problem is that Equifax put within webserver's reach information that had no business being there.

Can you please link to your preferred tutorials (or other sources) which explain how to set up the most secure server architecture, with regards to this story/subject, for those of us who would like to do a better job?

Thanks a lot!

[sillysaurus3]

It doesn't really exist. You "can't" because some computer still needs access to the data.

You can do layered security, but how? Think about a customer service rep. They need access to ~everybody's data at a moment's notice because they're a CS rep. That's what they do. That means every CS rep machine has access to all the data.

I'm not sure this is solvable. SSN's are the problem, not the way that we store SSNs. They still need you to read off your SSN when you call in, so you can't just encrypt it.

Think about Equifax in particular. They're a credit bureau. Of course they need all the data available all the time -- that's what a credit bureau does. The question is, how would you partition the data so that a failure in one place wouldn't lead to exfiltrating all the data everywhere?

The trouble is, it wasn't just "they popped Struts and then ran an scp." Even if you partition the data, they popped Struts! They have RCE inside your network. It's absurdly easy to pivot from one machine to another in a given network. You keep a helpful ~/.bash_history file that says exactly what's important and where everything is installed. Stuff like this is why I argued for deleting it, since it was the #1 most helpful tool I had that helped me pivot inside a target network. But then you get people yelling about taking away their bash history.

You can imagine how terrible this problem becomes in practice. Nobody here gives a crap about Equifax; they just want their heads to roll. Unfortunately you'll be next on the chopping block because no one has solved these issues. As soon as the world goes crazy over the lack of security, it's game over for us all because it leads to a highly regulated world that won't be much safer.

See how resistant we all were to the mere mention of increasing security procedures: https://news.ycombinator.com/item?id=14104156

I was snarky in that thread which certainly didn't help, but you have an uphill battle if you want to implement anything on a large scale.

[perlgeek]

> You can do layered security, but how? Think about a customer service rep. They need access to ~everybody's data at a moment's notice because they're a CS rep. That's what they do. That means every CS rep machine has access to all the data.

That is true. But you can observe that a typical CS rep accesses maybe 10 customer's data sets per hour. If they work 8 hours a day, 200 days a year, that's 16k customers they could leak per anno without arousing suspicion Maybe 60k if you allow a fudge factor of 4 to prevent false-positives from highly motivated CS reps.

But only if you monitor for this kind of thing. (And better yet, you should rate limit, and monitor).

Most security problems don't have perfect solutions, but they do have some solutions that get you 80% there. And if you invest in sufficiently many such 80% solutions, you get to a point where it's not economical for an attacker to continue hammering on your application.

[rfzabick]

Monitoring for anomalous access patterns is a good idea.

It wouldn't have helped in the face of RCE in struts. RCE in struts would let the adversary scp off all the files that make up the database, for instance. This would completely bypass any application-level checks or monitoring.

[pbourke]

At the very least, you could separate identity and data access and treat each person's data as a separate tenant.

The main data store that contains everyone's credit reports (high side), should have physical and network isolation from the public site (low side). Only copy from high side to low side when someone becomes a customer.

(disclaimer: IANA security expert, but the perfect is the enemy of the good)

[perlgeek]

There is no one-size-fits-all solution, and probably no "most secure", but lots of people have thought about stuff like that. If you google for "software architecture for security" or such terms, you'll find some helpful material.

https://www.computer.org/cms/CYBSI/docs/Top-10-Flaws.pdf (PDF warning) might be an interesting start.

The principles below it aren't too hard though: encrypt data in transit and in rest, think hard about key management. Keep attack surface minimal. Validate at all layers where it makes sense (for example in a multi-tenant application, you should authorize access to a row by tenant both in the application layer, and use row-level security in the DB as second layer of defense). Make your assumptions explicit; write them down. If possible, write automated tests that check if they still hold up.

While the principles are not hard to understand, designing an application with them in mind can be quite a different beast, and keeping stuff secure as features and integrations creep in requires quite some dedication.

[jlgaddis]

Step 1: Patch your shit.