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.¹

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:

• Bribe someone at your company
• Find a vulnerability in your application
• Phish someone with access to the data

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:

• All data is overwritten with zeroes before a disk is reused.
• People working in the data centers don't know which customer has data on which disk, so a targeted attack is very difficult.
• Disks contain fragments/shards of data from many different customers. It's not like taking a disk from one machine and putting it into another. Recovering this data and associating it with a specific customer is very hard.
• Physical access is recorded, logged, and protected by security guards.
• Employees are granted minimal physical access to specific areas only if they have a valid business justification. Access is also time limited.
• When a disk is taken out of service, it's physically destroyed.

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:

• You start at a new company or new position and inherit an infrastructure with unencrypted resources.
• Each team has its own AWS account and sometimes they forget to encrypt databases or use the default key rather than KMS.
• For cost reasons you need to use small databases (maybe you use many small databases to compartmentalize?) Encryption is not supported by all database types.
• The database was created before KMS was available.

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:

• Backing up to a different AWS account.
  • If the default key was used to encrypt a database, you can't copy backups to a different AWS account. Why? Because it's impossible to share the default key with a different AWS account. And no, AWS Backup won't help either.
• Delete the key and your data is gone.
  • If you delete the key to the key, your data is gone. Not very surprising of course, but it might be a problem since you can't backup these keys. Unlike some other services, KMS won't warn you if the key is used when you to delete it. In their defense, they have a 7-30 day retention time.
• Re-encrypting is a pain.
  • If you forgot to encrypt something, you'll need to start from over (as described above), which is very time-consuming and may require downtime. And don't forget to encrypt it with the right key or you'll have to do it all over again!
• Double trouble with access.
  • Not only do you need to configure IAM correctly (which isn't always the easiest) you also have to give the right key access. That's right, KMS has its own permission system on top of IAM, and you need both. This makes it twice as fun debugging permission errors!

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.