The basis of this take is "because it doesn't happen very often, it's snake oil". Has DrRobinson considered that the mere fact they think this is proof it works?
The entire point of encryption at rest (on the cloud) is that when any of the following happen you have nothing to worry about.
1. A machine/disk is rendered inoperable and can't be wiped.
2. The data stream coming off of a disk cluster is tapped.
3. An employee steals a disk or is lost.
4. An actor violates their account segmentation and can read raw data from segments of YOUR sectors of the shared disk.
5. SSD firmware goes bad/gets hacked and starts returning incorrect sectors of disk.
6. Memory pointers go bad and return sectors from the wrong area of the disk.
It's incredibly naïve to not use encryption at rest on AWS with how incredibly easy and problem free it is to deploy.
I agree calling it snake oil is a bit too much, because I know there are benefits.
As I mention elsewhere in the thread, I use encryption, but I don't consider it to be of high value compared to other security mitigations one can spend time on.
As mentioned in the blog post, setting up encryption isn't always easy and problem free though.
Regarding 1, disks are physically destroyed if they are inoperable. Thanks for sharing the list of potential problems, it's always interesting to see how other people think and what they worry about!
>disks are physically destroyed if they are inoperable
'Supposed to be' is missing from this statement. We have seen many vendors over the years say 'we destroy disks' only to have a disk show up in the wild.
I'm equally interested to see what lengths people like yourself will go to when given the option!
Where is it you draw the line?
Do you bother with Spectre mitigations since Amazon policy is to deny service to those who would attack you?
Do you bother requiring authentication on your database since policy is to use a closed VPC?
Hell, we haven't seen any man in the middle attacks lately, let's just drop SSL because you know your customers are wired and trust the endpoint networks.
SSL is the best example subject to the same common failures (including expiration, key loss, downtime to initially deploy) as you describe disk encryption migrations.
Encrypting disks is mandatory and there is zero justification otherwise.
> Do you bother with Spectre mitigations since Amazon policy is to deny service to those who would attack you?
I don't go out of my way to mitigate that, no. Have you seen any real attacks with this? They seem very rare and hard to execute, especially if you have someone specific in mind.
> Do you bother requiring authentication on your database since policy is to use a closed VPC?
Yes. Usually you have multiple services running in the same VPC, by using authentication you limit the potential impact if one service is hacked. Adding authentication to a database that previously had none is also very easy.
> Hell, we haven't seen any man in the middle attacks lately, let's just drop SSL because you know your customers are wired and trust the endpoint networks.
MITM attacks are quite common actually. Internally inside AWS (i.e. between instances) the benefit of TLS is maybe questionable, especially since traffic is encrypted between instances automatically (depending on the instance type).
> Encrypting disks is mandatory and there is zero justification otherwise.
I disagree that there is "zero justification otherwise." I've updated the blog post some and I'm interested to hear your thoughts about it. But in short, adding encryption to an unencrypted machine can take a lot of time and effort. Setting it up correctly from the start is usually easy, but it's not always whoever set it up initially did that. There are many things one can do to improve security, and most things will probably be more beneficial than re-encrypting disks.
Backwards compatibility — GCP started enough later that their hardware could do this at close to zero cost but by then AWS had many large customers who had made decisions based on the performance delta.
By now that's moot so I'd assume they'll set it by default for new accounts at some point but there's a regional option which you can turn on by default:
If you use tools like Security Hub with the Amazon Foundational Security Best Practices suite of controls enabled there's a specific check for that setting:
That's a good sentiment. But you can say the same for the aws encryption.
I.e. how do you even know it's working and your data is encrypted?
Just because API says so, doesn't mean it's so. There is no way for you to verify. Is there?
Unless you encrypt on your end, you can't be sure.
I know people who work there. I've read the infrastructure designs. I know Amazon audits themselves. I know AWS has third party audits. I know AWS has government and enterprise users who require their partners be legally liable for improper implementation. I do not subscribe to conspiracy.
The same is true for other points one through six, if you choose to trust aws. But somehow "It's incredibly naïve to not use encryption at rest on AWS".
The entire point of encryption at rest (on the cloud) is that when any of the following happen you have nothing to worry about.
1. A machine/disk is rendered inoperable and can't be wiped.
2. The data stream coming off of a disk cluster is tapped.
3. An employee steals a disk or is lost.
4. An actor violates their account segmentation and can read raw data from segments of YOUR sectors of the shared disk.
5. SSD firmware goes bad/gets hacked and starts returning incorrect sectors of disk.
6. Memory pointers go bad and return sectors from the wrong area of the disk.
It's incredibly naïve to not use encryption at rest on AWS with how incredibly easy and problem free it is to deploy.