[slashdev]

I think the author and the commenters here are using two different threat models. A lot of people here are saying you should encrypt the disks because it’s best practice for security. Or because it protects against some specific, if implausible, scenario. They’re talking about theoretical security.

The author is saying the probability that it improves your security is so low that any time it takes away from other security related work is actually making your security worse. That’s a different threat model, and it’s probably the better way to approach security, and the author is probably correct - if he actually uses that saved time to improve security in other ways.

I have a question though, what are the laws that require encryption? I can think of HIPPA, SOC2 maybe? What about GDPR?

[lazide]

There are secondary effects to not using encryption you can see.

For instance, it greatly expands the scope of ‘I lost your data/I exposed your data’ notifications in places like California, and for those under many of those other rulesets.

Someone getting access to a repo of encrypted drive images, or someone losing an encrypted drive, doesn’t count. And for reasonableish reasons.

It’s a basic risk mitigation/blast radius limiting move.

For physical/on-prem especially, since old disks tend to ‘wander’ after retirement, and it’s a great idea to always have had them full disk encrypted to reduce the odds someone sensitive gets exposed years down the line.

[acdha]

It’s more that the author is arguing that their inexperience is universally applicable. “Why do banks have guards, I’ve never had someone break into my couch cushions?”

Beyond the compliance requirements (e.g. CIS), it’s wrong to assume that disks are always perfectly disposed of – simply never having to worry about featuring in one of those “look what I found on eBay!” posts and notifying your customers is worth the basically non-existent cost of basic encryption. It’s something you turn on and basically never think about again - the performance hit disappeared around 2010 and it’s easy to enable globally.

Beyond that, however, there are two key benefits - the author even almost discovers one of them but didn’t think about it enough: encryption means deletion is probably fast - delete the key and you don’t need to monkey around wiping disks and snapshots.

The other, bigger, one is that it can protect against mistakes or compromises. If you share a KMS-encrypted resource accidentally, an attacker won’t have access to the data. An attacker can’t access a resource with a custom KMS policy unless they compromise the specific role which has access or do more invasive things which will trip alerts. Again, not perfect but it protects against common mistakes like the Capitol One firewall breach, which is why all of those standards started recommending it.

[DrRobinson]

> It’s more that the author is arguing that their inexperience is universally applicable. “Why do banks have guards, I’ve never had someone break into my couch cushions?”

That was not my intention and it's unfortunate that's how it sounds. Just like most people don't need armed guards, most people don't need bank level security for their disks either. Encrypting disk encryption is usually not the most effective thing you can do to improve your security, there are usually other actions with better payoff.

AWS zeroes the disks before they're reused, so from your point of view it's instant. As mentioned in the post, deleting a KMS key takes at least 7 days (and up to 30 days, depending on your configuration.) Regarding other point, that's also mentioned in the post as "if your IAM access configuration is bad your KMS access configuration might save you," which is referring to what you mention.

> It’s something you turn on and basically never think about again - the performance hit disappeared around 2010 and it’s easy to enable globally.

This is true if you, or the one you inherit the infrastructure from, configured it correctly from the start. But re-encrypting disks, databases, S3-buckets etc is time consuming and might require downtime. So it's not always easy or cost free (in terms of labor.) I'm not sure what you're referring to with "easy to enable globally", enable what?

Thanks for sharing your perspective!

[acdha]

> AWS zeroes the disks before they're reused, so from your point of view it's instant. As mentioned in the post, deleting a KMS key takes at least 7 days (and up to 30 days, depending on your configuration.)

Yes, the point is that it separates physical and logical concerns. That's why all of the major services have been moving to have it on by default since it means that there's no way for lost hardware to cause a data breach, and while the KMS delays to prevent accidental / ransomware deletion are not instantaneous they're visible and deterministic: things are deleted when you think they are.

> Regarding other point, that's also mentioned in the post as "if your IAM access configuration is bad your KMS access configuration might save you," which is referring to what you mention.

I guess I'm just not seeing how that's “close to useless and potentially harmful” – defense in depth is a useful hardening technique, especially if you have to worry about admins being compromised or demonstrate that sysadmins can't access data without following a standard logged path.

> This is true if you, or the one you inherit the infrastructure from, configured it correctly from the start. But re-encrypting disks, databases, S3-buckets etc is time consuming and might require downtime.

Saying that something is hard to clean up later isn't “close to useless and potentially harmful” — if anything, I'd take the opposite position that if you do the “pointless” compliance work, you're not going to be in that position later when you have a ton of data and busy applications.

> So it's not always easy or cost free (in terms of labor.) I'm not sure what you're referring to with "easy to enable globally", enable what?

Partially I was thinking about https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncry... but the more general point was just that these are easy to set up when you're creating new resources and there isn't a runtime impediment for having done so the way there was decades ago when performance was a reasonable concern.

In general, when the entire industry is saying you should do something or, as is the case for the major cloud providers, turning it on by default, I would stop to ask whether it is in fact unnecessary or them trying to prevent yet another customer from ending up in a situation where the work required to deal with a problem is considerably greater than preventing it would have been.

[DrRobinson]

> Saying that something is hard to clean up later isn't “close to useless and potentially harmful”

The "close to useless" is based on it lowering any risk with very little, it's not a big payoff security wise in most cases. "Potentially harmful" refers to the cost of potentially having to re-encrypt data, that is cost/effort that could instead be spent on other security mitigations with better cost:benefit ratio.

You have a limited amount of resources, and with those resources you want to lower the risk as much as possible. I consider re-encrypting data to fare badly in such calculation. It's a high effort low benefit mitigation in most cases. If encryption is done correctly, it might cost little effort and gives little benefit and might therefore be worth it. It's very common to not do it correctly though, and that requires re-encrypting. I have not found an SCP that allows KMS keys but not default encryption keys, which means manual effort is spent on teaching developers and/or build/use tooling.