One nice example of this which I once saw in a real system is that a system that collects credit card numbers from the public might not need to be able to read those numbers after they're recorded, if the charges are going to be made by a later batch process. So the credit card number receiving system can use a public key to encrypt the incoming data in such a way that the batch processor will later be able to decrypt it. In this case, there is certainly a machine that has the capacity to read the data, but it's not the same machine that stores the data or that is exposed to connections from the general public. (But that paradigm is a lot easier for the case of offline batch processing, which is mostly different from the applications that you were describing... but wherever a system has a component like this, it may be possible to reduce the window of exposure with this pattern.)
Another example is that a database server might be compromised via a different vector from its clients. If some database fields were encrypted, the impact of a database-only compromise would be reduced.
Edit: elsewhere in this thread someone points out that your argument may be meant to be more specific to this breach, and I think it's most likely right with respect to this particular incident.
All the data is hot data. That's what Equifax exists at all. There are multiple internal services which can cause "pull that entire file." If you lose any of them, your data store doesn't matter; there goes the ball game.
Someone's about to say "But rate limiting!" and not understand that Bank of America can ask for 10 million files at a time. (One cron job talking to a another cron job, etc etc, will fetch an update to a substantial fraction of all of their customers to update their internal records for underwriting. A larger recurring use case is "Refresh the soft pull on everyone in our marketing funnel whose pull is stale." Note that that is a sizable portion of the adult population.)
One of the more interesting bits of the project is that soft-real-time is not a requirement, so some simpler, slower and older algorithms become feasible (interactive ZKPs, even fully-HE systems perhaps). A very specific use case has allowed for the possibility. But it’s amazing to work on :)
It's possible that you've protected the data at rest, but if some 'get' operation is just going to serve it up, what is the effective difference?
Edit: the key comes from the user, its not stored anywhere on a server. The key can optionally never leave the user's device.
This presupposes you know what you're doing, security-wise, on your network, and with your backups, and with temporary data on servers. All of your interior traffic is encrypted, right? Right.
It doesn't sound like Equifax was even on the map.
Does it mean if user loses his key - he wont be able to get access to his data?
An attacker is forced to either exfiltrate the data slowly (so the surge isn't noticed) or alert ops monitoring that the decryption service is unusually active.
Defense in depth raises the difficulty in going unnoticed and raises the time it takes to succeed.
It's small, but it is something.
The other reason to do it, frankly, is because when you end up in the news, this is the first thing everyone asks. It's easier to say yes than to "no, but..." and explain why this is a dumb question to ask (as you are trying to do here, with a far more technical audience).
I think you mean "encryption wouldn't have mattered for the known attack", but there are lots of cases where encryption would help... even in cases that don't involve hacking, like hard-drive disposal.
If you're a defender, I would go further and say you must assume it.
See the example vulnerable web service here: https://gist.github.com/emidln/a43b9fee4fc55273106c4b850f6b4...
Is the assumption that control over the db can pivot back to the server or that if there are basic issues with db access that there must be other exploitable issues (probably a fair assumption)?
In general I am not sure if we wish to conflate systems security and cryptographic security - cryptographic security ideally should guard against system security failures. Although in practice I grant you that broad system failures which expose crypto secrets (code execution would fall into that) would lead to crypto failures as well.
To get a dump you'd need to compromise two systems - a database server that has access to all the data, but in the data it stores and returns all the interesting columns are encrypted; and an app server that can decrypt data that it gets (and it has the keys only for the columns that this app server actually needs to use, if you have different classes of confidential data) but can't get all the data from the database freely, only a predefined subset in a limited and logged manner controlled by the database system.
Granted, if the attackers can get RCE on one of those systems then it's likely that with some effort they can get the other system as well in a similar manner, but still it's an useful defense in depth.
> If you're a defender, I would go further and say you must assume it.
The assumptions you make when reacting to a known compromise are wildly different than what access an attacker actually has and what they might be able to do.
Just a couple days ago, I heard a mathematician call a certain complicated knot invariant "space math" because of how out there the approach was, but that was idiosyncratic.
For all the horrible stuff ups Equifax management has had, it sounds like congress would be substantively happier with them if they said "yes our SAN has an FDE feature". The media would certainly be kinder to them.
I'm in two minds about rolling something objectively pointless just so I can address these sorts of concerns.
This is a problem even with HSM designs; in real-world systems, HSMs usually just present an oracle interface to data. The hope is that with sufficient monitoring, you can use the oracle to buy time for defenders to detect a compromise before all your data is exfiltrated.
I think most penetration testers have the experience of owning up a server and going on the brief treasure hunt for the static key stored somewhere on the filesystem.
Among probable hits, "hierarchical storage management" and "hardware security module".
Is it because the keys are easily comprimisable, or stolen?
TL;DR: If a machine can actually use the data in the database, it has to be able to get the data in a decrypted form. If an attacker compromises that machine, the attacker can also get the data in decrypted form.
The compromised component at Equifax was the running application which is built to retrieve data from the database - it knows how to log in to the database and do whatever decryption is required to retrieve data. You don't particularly need to compromise passwords or encryption keys or whatever, because the application will just use them for you.
Encryption protects against compromising the server itself either physically or at the OS level, which is not nothing, but also doesn't help if you have an underpaid janitor with a gambling problem with all the keys in his pocket guarding the loading bays out back.
So why Fortune 500 companies only? I am just trying to understand what this has to do with the scale of a company.
It helps here to understand two things:
1. When we talk about protecting servers with encryption, we're stipulating attackers with RCE. That was the case with the Equifax attacker and is routinely the case in real-world applications.
2. SQLI, the app-layer non-RCE attack that gives you direct access to raw database rows (ie: the one non-RCE case in which you'd get access to the data we're encrypting) almost always equates to RCE anyways.
There are real designs that involve cryptography that mitigate these problems. They fall into two buckets:
1. HSM/Crypto "oracle" schemes that are backed by intensive staffing and monitoring. Yes: nobody disagrees that Equifax should have had a serious security team doing serious monitoring. But: if it had that, it wouldn't have had this breach, which involved a published critical framework vulnerability. In other words: in bucket 1, "encryption" isn't helping you, "better security team" is.
2. Moon math schemes. I'm all for moon math, but when people say "phwat!? Equifax worn't even encrypticated?", they do not as a rule have a particular moon math scheme in mind (or, likely, an appreciation for what it means to be the first at-scale deployment of a new moon math scheme).
I am not mounting an argument that people shouldn't encrypt things. Hard drives do get lost. I'm just saying that as an operational security mitigation, encryption isn't doing what 99.99% of developers think it's doing in this scenario.
(by the way, I can't take credit for the term "moon math" but it is super useful)
Elsewhere in this thread you said that a compromise of a database is likely associated with a compromise of systems that access that database, but this is not necessary true if the platforms and administration of these systems are very heterogeneous (say, different operating systems), and in any case it doesn't make it not an application of defense in depth. (Suppose that 90% of attacks that penetrate the database also penetrate the client; now this use of encryption has managed to beneficially mitigate 10% of these attacks.)