IME, the reason customers spend so much time talking about encryption at rest / encryption in transit is many security frameworks explicitly call it out (eg NIST 800-53) and it’s easy to give a yes/no answer.
Those same frameworks also call out segregation of duties (which would cover things like IAM concerns) but that’s an ugly, difficult to assess topic and so it gets talked about less. Very few clients will ask about the finer encryption details (eg which TLS version, if mTLS is required, which ciphers, etc etc etc). They want to check the box/framework and say they are secure. I understand the desire!
Sadly, there are an infinite number of ways to make a service wildly insecure that will never be seen or understood by the auditors. However, if they can run through a checklist and see some basics covered, it makes everyone (business, board, market, insurer, government, etc) all feel much better.
Thank you for the comment! I see your point around auditors and evaluators focusing on things that are much more tractable to check. This explains basically every SOC 2 control; I will probably steal that concept in later blog posts.
I do have customers who go far deeper into this, though. This is the painful bit for me, if everyone was happy with asking a yes/no question about whether I press the S3 encryption checkbox I'd... still think it was silly, but not waste anyone's time blogging about it. Instead, some customers will happily spend 20 hours of their lives discussing encryption, so it's not just a time reason they ignore more significant risks.
I think I know a valid threat model under which encryption at rest in the cloud is not a useless chimp control.
It's possible for a cloud provider to get a discount on bulk purchases of HDDs, under one inconvenient contractual condition: HDDs that break in the first X years of their life MUST NOT be destroyed and MUST be returned to the manufacturer (for spare parts). Then, assume that an HDD breaks, but contains sensitive data. The cloud provider would rather wipe it before returning, but sometimes disks break so badly that they can't be even detected as disks, so such wiping becomes impossible. Yet, the manufacturer might have better data restoration equipment and can read this data. By encrypting the data beforehand, the cloud provider thwarts this threat.
Nice post.
IME, the reason customers spend so much time talking about encryption at rest / encryption in transit is many security frameworks explicitly call it out (eg NIST 800-53) and it’s easy to give a yes/no answer.
Those same frameworks also call out segregation of duties (which would cover things like IAM concerns) but that’s an ugly, difficult to assess topic and so it gets talked about less. Very few clients will ask about the finer encryption details (eg which TLS version, if mTLS is required, which ciphers, etc etc etc). They want to check the box/framework and say they are secure. I understand the desire!
Sadly, there are an infinite number of ways to make a service wildly insecure that will never be seen or understood by the auditors. However, if they can run through a checklist and see some basics covered, it makes everyone (business, board, market, insurer, government, etc) all feel much better.
Thank you for the comment! I see your point around auditors and evaluators focusing on things that are much more tractable to check. This explains basically every SOC 2 control; I will probably steal that concept in later blog posts.
I do have customers who go far deeper into this, though. This is the painful bit for me, if everyone was happy with asking a yes/no question about whether I press the S3 encryption checkbox I'd... still think it was silly, but not waste anyone's time blogging about it. Instead, some customers will happily spend 20 hours of their lives discussing encryption, so it's not just a time reason they ignore more significant risks.
I think I know a valid threat model under which encryption at rest in the cloud is not a useless chimp control.
It's possible for a cloud provider to get a discount on bulk purchases of HDDs, under one inconvenient contractual condition: HDDs that break in the first X years of their life MUST NOT be destroyed and MUST be returned to the manufacturer (for spare parts). Then, assume that an HDD breaks, but contains sensitive data. The cloud provider would rather wipe it before returning, but sometimes disks break so badly that they can't be even detected as disks, so such wiping becomes impossible. Yet, the manufacturer might have better data restoration equipment and can read this data. By encrypting the data beforehand, the cloud provider thwarts this threat.
This article is really great. Just subscribed -- please keep posting these!