Hacker News Reader

Comment by ozim | Hacker News Reader

I think reason is simple "encryption at rest" == "it is going to be encrypted in backup".

People asking about "encryption at rest" are really asking if backups of your web application data are encrypted.

Earlier I think it was quite a plague when just un-encrypted backup files were leaking out because someone exposed them on some open FTP to "quick and dirty" copy backups to new environment or to some test environment - and forgot to close it down or remove the files.

Other threat would be developers exposing database server directly to the internet because someone from marketing wants to connect "new shiny super business intelligence" and developers not knowing better than "allow all" on firewall, then someone might steal raw db files but might not really have access to web application and encryption keys.

For the reasons mentioned by author I can see how it seems like security theater. But I think my reasons are quite valid and on topic.

View on HN

The thing that's security theater isn't encrypting at rest in general.

The thing that's security theater is encrypting insecurely, or failing to authenticate your access patterns, such that an attacker with privileged access to your database hardware can realistically get all the plaintext records they want.

>> The thing that's security theater isn't encrypting at rest in general > The thing that's security theater is encrypting insecurely

Security theater should be defined as:

Doing things that outwardly appear to improve security but have de minimus or less effect on actual security.

The 93 section questionnaire from bigco's IT department is security theater. Filling it out does zero to improve security for bigco or myco or my users.

> Doing things that outwardly appear to improve security but have de minimus or less effect on actual security.

Right. And that's exactly the situation the article describes.

The accusation of "security theater" was only levied when IT departments reached for the "full disk encryption" potion to mitigate the ailment of "attacker has active, online access to our database via SQL injection", when that's not at all what it's designed to prevent.

They can insist that they're "encrypting their database", but does it actually matter for the threats they're worried about? No. Thus, security theater.

The same is true of insecure client-side encryption.

IDK, I have multiple times seen significant practical security improvements as a direct consequence of some "93 section questionnaire" because the very first section had a few questions "Are you doing this simple, well-known best practice thing?", which they were not, because it took some time, effort and/or money and they just didn't care.

But once the questionnaire mattered, they started doing it just so they could legally answer "yes" to that question. Things like finally changing the default admin passwords on that service they installed a year ago, and testing backup recovery to find out that it actually can't be done due to a bug in the backup script skipping some key data.

I do agree, well my boss would most likely never allow me to spend time on security until he got hit by "93 section questionnaire" from big co.

Once contract with big co was on the line I got permission to do security and do it good.

Even though 80% of questionnaire was not applicable it still did the good job.

Reply on news.ycombinator.com