Mellow Root

Disk encryption in AWS is close to useless and potentially harmful

Security theater is the practice of taking security measures that are considered to provide the feeling of improved security while doing little or nothing to achieve it.1

Old-school compliance requires your data to be encrypted, which is great in case someone steals your disk. This compliance has followed to the cloud even though you don't even own the disk, instead you check a box in the AWS web interface and now your data is encrypted.

But what problems does it solve? Are you worried about someone breaking into the AWS data center, stealing the specific disks your data is stored on, and restoring and analyzing the disk data to target your organization? Just imagine how much effort such an attack would take.

What is much more likely to happen is the attacker tries to:

Doing a mission impossible type of thing is probably the last thing they'll try.

What AWS does to protect your disks

AWS has strong incentives to keep the disks you use secure regardless of whether it's encrypted or not. Here are some things they do to make your data more secure:

Generally, physical security is Amazon's part of the shared responsibility model. They do a very good job at this and attacks on this layer are very unlikely, and because of sharding, the potential impact is very small.

Encrypting isn't always easy

To be clear, if you are in a position where you can set this up correctly from the start, just do it. Encrypt all your databases and disks with a KMS key (not the default key.)

Encrypting something correctly on the initial setup is trivial, but if you have an unencrypted database that's already running in production it'll be a pain to encrypt it. You need to:

  1. Stop the database.
  2. Take a snapshop.
  3. Create a new database instance based on the snapshot.
  4. Update DNS records to point to the new database, and other application-specific configuration changes.
  5. Delete the old database (keep in mind that automatic backups are deleted with it.)

There is more than one way to do this of course, but this serves as a common example.

In an ideal world, you can set things up correctly from the start, but unfortunately, we don't live in an ideal world. Some scenarios I've encountered:

These are just a few scenarios but you get the point. Going back in time is unfortunately still not an option.

Problems caused by encryption

Encrypting data this way can be very cumbersome and makes some things harder, or (depending on the configuration) impossible. Doing things wrong can cause harm (in terms of cost), here are some examples:

I haven't seen it yet, but I expect ransomware groups to abuse the KMS policies to lock data.

Where encryption helps

There are cases where this encryption helps. If your IAM access configuration is bad your KMS access configuration might save you. For example, if a bucket is encrypted with a KMS key (not default key) and the bucket is accidentally made public, the KMS key policy won't allow everyone to view the data anyway. Note though that this isn't about encryption specifically but the KMS key policy, you could just as well have been protected by a bucket policy. Why not spend time on fixing the bucket security instead (maybe with a bucket policy)?

Then there is the long tail of problems with disk destruction failing, faulty firmware in the disk, and similar. But how likely is that, what impact would it realistically have, and how much of your time does it justify?

Time spent on re-encrypting is time taken from other security mitigations

I suggest spending your time on IAM permissions, backups, disaster recovery, appsec, or pretty much anything else before disk encryption. This AWS security maturity model is a good guideline (notice how encryption isn't even mentioned.)

Focusing on cloud encryption is probably one of the last things to focus on unless you have some urgent compliance requirements. Trying to exploit an unencrypted drive is not worth it for an attacker.

Compliance is a tool to make sure organizations have a baseline for security, but forcing people to spend a lot of time on re-encrypting is usually counter-productive. That time could instead be spent on other, more relevant, security mitigations. That means re-encrypting data actually reduces security (in terms of lost opportunities.)

If you do a risk analysis, I'm sure encrypting disks won't be at the top of your list, unless you have legal or compliance requirements.

  1. Security theater - Wikipedia

#aws #rant #security