The problem is that encrypting once in a conventional database design does not add noticeable depth. The server needs to be able to decrypt automatically in order to function. Whatever the server does to decrypt, the attacker will do too.
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)
Lol, if you don't encrypt what keeps some employee from just walking in and stealing the hard drives? Insider attacks are huge, learn this in sec 101. RCE is your area, I am sure, but you are missing a huge category of trivial attacks if you don't encrypt.
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)