7 ms·

This article is so narrow-minded .. I've work with physical servers in many compagnies. Every time, storage devices have a lifecycle : they are bought new, the

This article is so narrow-minded .. I've work with physical servers in many compagnies. Every time, storage devices have a lifecycle : they are bought new, then plugged (and some data are written), then some times then move in another physical location, then they "die" (= put to the trash, either because they broke or for other reasons). Encryption at rest is an efficient way to secure data for the latter cases. The workers stole a hard disk ? No data is stolen. A hard disk is lost during transit, somehow ? No data is stolen. The device which is broken is retrieved by someone, opened-up, and being read-at directly ? No data is stolen. Your old device, put to the bin for some reasons, that could still be read if plugged on the proper hardware ? No data is stolen. All of that with little performance impact, and no software modification, few engineering overhead, very little work to do. It eases the lifecycle of storage devices, because storage devices are now worthless per-se (except for their physical cost, indeed). They carry virtually no data, no worth. Can you propose any other way to protect against those thread models ? Rewrite every software, so that every programs handle their own private keys ? Yeah, that's a nightmare, not gonna happen. And even if it did .. how would you encrypt your rootfs ? Ha yes : encryption at rest :)

tossandthrow 2y ago
For this thread model, the encryption should happen at the volume level, not application level. Which is also what the author write: >If you’re only interested in compliance requirements, you can probably just enable Full Disk Encryption and call it a day. Then, if your server’s hard drive grows legs and walks out of the data center, your users’ most sensitive data will remain confidential. > Unfortunately, for the server-side encryption at rest use case, that’s basically all that Disk Encryption protects against. (Something tells me that you did not read the article that is so narrow minded)
- JackSlateur 2y ago
  I think I've written enough to illustrate that storage devices moves around without "growing legs and walk out" But yes, if the author drops all security thread related to encryption at rest, then encryption at rest is useless. I agree.
  - CiPHPerCoder 2y ago
    It sounds to me like you read a different article than I wrote. The point of my article was not "Encryption-At-Rest Is Bad" as you seem to have taken it to mean. Rather, the point is that other techniques, when you sit down and actually think them through, do not provide any significant value over just phoning it in with Full Disk Encryption. How you get from "software libraries that encrypt-at-rest routinely fail to provide value on top of full disk encryption" to "Scott says FDE is bad" is unclear. Additionally: From a software perspective, the risks you all outlined are morally equivalent to the hard drives grew legs and walked because they are the same risk; namely, loss of control of the actual hard drives. The article in question is focused on threats when those drives are plugged in and the keys are being used to encrypt/decrypt data. As several others have pointed out already, I explicitly state this, repeatedly. I don't know how to make it more clear.
  - tossandthrow 2y ago
    All the risk vectors you list yourself are about physically being able to get the disk. The author states that "growing legs and walk out" (understood as people being able to physical access to the disk) is already mitigated by disk encryption. So not only are you not adding anything to the article. You actively try to dismiss that the author has thought the cases you bring up through (and calling them out as narrow minded on false grounds). I think we all would love to see a risk that is mitigated by encryption at rest and is not already being mitigated by disk encryption.
  - darkwater 2y ago
    Is it that complicated to admit you misread and/or misinterpreted TFA and you posted a wrong comment?
ziddoap 2y ago
>This article is so narrow-minded .. Indeed, they said exactly that. See: >Important: I’m chiefly interested in discussing one use-case, and not focusing on other use cases. Namely, I’m focusing on encryption-at-rest in the narrow context of web applications and/or cloud services.
- l33t7332273 2y ago
  In web applications and cloud services drives could still be misplaced, stolen, or improperly disposed of. Further, if data is encrypted at rest then there are multiple levels of auth that must fail for a breach to occur, namely access to the data and access to the key.
  - ziddoap 2y ago
    While threat modeling, you talk about specific scenarios and specific threats. That does not mean other scenarios and threats don't exist. It just means they aren't the focus of that particular conversion. >In web applications and cloud services drives could still be misplaced, stolen, or improperly disposed of. This is explicitly called out in the article by the author, despite it not being part of the threat model the author is examining. And people are still bringing it up like some sort of gotcha. See (again): >This is not a comprehensive blog post covering every possible use case or threat model relating to encryption at rest.
    - l33t7332273 2y ago
      I’d say the author is being so restrictive in the scope of threats that it isn’t very useful. Regardless, even in their very restrictive scenario, it provides defense in depth as I said.
      - CiPHPerCoder 2y ago
        > I’d say the author is being so restrictive in the scope of threats that it isn’t very useful. Loss of control of the hard disks may have many different ways it can manifest in the real world, but from a cryptography and software development perspective, is congruent to other flavors of the same underlying problem. That's not being "restrictive", it's recognizing the common denominator.
velcrovan 2y ago
From the article: "Disk Encryption is important for disk disposal and mitigating hardware theft, not preventing data leakage to online attackers."
- KennyBlanken 2y ago
  ...which is a concept nearly anyone working in IT understands. I don't think the vast majority of people with IT/ops experience seriously thinks that encryption at rest provides data protection from people getting unauthorized access to the system, in person or remotely...aside from maybe management that ended up in charge of IT and engineering departments without almost any practical-skills background in either. The author is confusing "it costs us nothing (now that encryption can be done in hardware and is integrated into most desktop operating systems) and protects in some scenarios, so yeah, we just decided to mandate it always be done" with "PEOPLE THINK ENCRYPTION AT REST IS A MAGIC BULLET LOOK AT ME I'M INSIGHTFUL, POST LINKS TO MY BLOG ON LINKEDIN!" The whole post is insulting to the intelligence of even a fairly junior desktop support technician.
  - CiPHPerCoder 2y ago
    > The author is confusing "it costs us nothing (now that encryption can be done in hardware and is integrated into most desktop operating systems) and protects in some scenarios, so yeah, we just decided to mandate it always be done" with "PEOPLE THINK ENCRYPTION AT REST IS A MAGIC BULLET LOOK AT ME I'M INSIGHTFUL, POST LINKS TO MY BLOG ON LINKEDIN!" What in the article gave you that impression? I do not hold this confusion in my mind, nor did I deliberately encode such a statement in my blog. I'm curious why you think this is what I was saying. > The whole post is insulting to the intelligence of even a fairly junior desktop support technician. If that was true, every time someone posts "Show HN: My Hot New Database Encryption Library in Haskell", they would be mitigating the confused deputy attack by design, rather than what we see today: Namely, failing to even protect against padding oracle attacks. That's what the article was actually talking about.
  - deleted 2y ago
    [deleted]
j-bos 2y ago
Comments like these are doubly great, useful tech perspectives, and a reminder that the comments often do not reflect understanding of the original submissions.
- PaulStatezny 2y ago
  Ha, I also love the irony of your parent comment. Seems to totally miss the point, but I still upvoted because it illuminates the purpose of disk-level encryption so well, adding color to the conversation.
KRAKRISMOTT 2y ago
It also defends against cultural indifference to privacy violations. If you go to Reddit r/sysadmin, most SREs and DevOps folks generally do not care too much for challenging subpoenas and government data requests. If a three letter spook shows up to their data center and demands data, it's just another Tuesday for them. IT people are very different from software engineers who are more likely to protest online and offline about civil right violations and government overreach.
- EPWN3D 2y ago
  Yeah I've always gotten power tripping vibes from sysadmins. They're happy to fork over data just to show that they can.
  - Volundr 2y ago
    This is a weird take. For one, handing over data because someone in power told you too is the exact opposite of power tripping. It's pretty much the entire description of disempowering. But secondly, the idea that anyone who actually has a say in if the data is turned over (the legal team, executives) give a flying fork about how a random sysadmin in their data center feels about it is wildly off base. The data is going out or not according to legals instructions. Either sysadmin Bob does it, or he takes a principled stand, gets fired, and Bob 2 takes care of it.
  - KAMSPioneer 2y ago
    I'm a sysadmin and I have no idea what you're referring to. Yeah there are guys in my field who are happy to overreach in terms of data access, but I'm sure we can come up with some anecdotes about devs over-harvesting data on...virtually any modern online platform. Most of my colleagues (at least those I've met) tend to be conscientious about data access and privacy. I host several E2EE services for friends/family because I believe in privacy and data sovereignty. But if my company's legal department says "give access to <these guys>," as a sibling commenter said, if I refuse then I'm fired and those guys will still get access. So I do what legal says and keep my job, TYVM.
- blitzar 2y ago
redleader55 2y ago
> A hard disk is lost during transit, somehow ? No data is stolen. Arguably, customer data should not leave a secure location on a physical disk. If you want to move your server, backup the data, wipe the disk, move the server/disk/etc, and then put the data back on the disk once it is back in a secure location. The author mentions this in the article - define a secure boundary, don't let the data exit that boundary unencrypted.
- yjftsjthsd-h 2y ago
  > Arguably, customer data should not leave a secure location on a physical disk. Okay, let's argue. Under what threat model is it a problem to transport sensitive data on encrypted disks?
  - forty 2y ago
    Maybe "they can replace the disk firmware during transport while the driver was peeing" kind of attackers?
    - yjftsjthsd-h 2y ago
      That doesn't have anything to do with the customer's data and isn't helped by the suggestion of wiping the drives before transport. The data is encrypted no matter what happens to firmware; that is at best a way to compromise the server(s) after transport.
  - spydum 2y ago
    If the device is lost or stolen during transport physically, all it takes is the attacker to gain control of the key, or find a weakness in that firmware or encryption method. While those are stupidly improbable, the reality is once you lose physical custody, the attacker has a lot more options.
- brongondwana 2y ago
  Never underestimate the bandwidth of a stationwagon loaded with tapes. Arguably, your position is bogus. Why cause a bunch of extra copying around to move a server. "Back up" indeed - to what? Another disk? It's turtles all the way down.
deleted 2y ago
[deleted]
yourapostasy 2y ago
> Rewrite every software, so that every programs handle their own private keys ? Yeah, that's a nightmare, not gonna happen. PCI 4.0 disallows using Full Disk Encryption to fulfill its encryption at rest requirements, because it demands a finer-grained encryption authorization model. For applications subject to PCI 4.0 compliance, my clients have to encrypt beyond the application level, and down to the service account level used by the application (most of these applications use multiple service accounts for representing teams that use the applications), with different files encrypted for different authorization groups. There are very few enterprise scale solutions addressing this at the moment, and the stopgap I've seen is indeed the application teams are resorting to handling their own keys if the enterprise doesn't offer a finer-grained solution. The QSA's don't yet understand how seismic a shift this is, nor how inadequate the assumed authorization schema is for the many edge cases out there that will be unable to adopt the assumption a single key for a single group is sufficient to model all use cases. It will be a little messy until folks sort through the edge cases coming down the pike.
- motymichaely 2y ago
  You’re absolutely right! Full disk encryption (FDE) does indeed fall short of PCI 4.0 requirements because it transparently decrypts data for anything running on the OS or accessed by the user, which isn't sufficient for finer-grained control. PCI 4.0 demands more granular encryption authorization models, where data is either encrypted at the file or column level, or access to plain data is restricted to more specific roles than just the OS user account. This is to reduce the risk of unauthorized access. There are a few dev-centric data protection solutions that address these requirements seamlessly. These solutions allow you to store and encrypt any type of data with simple APIs while transparently managing keys, rotation, and granular access controls. I am currently evaluating Piiano Vault (https://www.piiano.com/pii-data-privacy-vault https://www.piiano.com/pii-data-privacy-vault) as one such solution for a new product that I am currently working on that would require a PCI compliant zero-data solution. Seems like its delivery model is very flexible - it can be fully self-hosted or consumed as a managed SaaS, providing robust data protection tailored to my specific needs. Will update with my findings!
jiveturkey 2y ago
laptop theft is actually far worse a problem than data center. well, not in terms of scope, but in terms of frequency at least. you can actually expect laptops to be stolen. i think you misread the article. i found it to be a great, even excellent, discussion of WHY and then explaining HOW in terms of the WHY.

tossandthrow 2y ago

For this thread model, the encryption should happen at the volume level, not application level. Which is also what the author write: >If you’re only interested in compliance requirements, you can probably just enable Full Disk Encryption and call it a day. Then, if your server’s hard drive grows legs and walks out of the data center, your users’ most sensitive data will remain confidential. > Unfortunately, for the server-side encryption at rest use case, that’s basically all that Disk Encryption protects against. (Something tells me that you did not read the article that is so narrow minded)

JackSlateur 2y ago
I think I've written enough to illustrate that storage devices moves around without "growing legs and walk out" But yes, if the author drops all security thread related to encryption at rest, then encryption at rest is useless. I agree.
- CiPHPerCoder 2y ago
  It sounds to me like you read a different article than I wrote. The point of my article was not "Encryption-At-Rest Is Bad" as you seem to have taken it to mean. Rather, the point is that other techniques, when you sit down and actually think them through, do not provide any significant value over just phoning it in with Full Disk Encryption. How you get from "software libraries that encrypt-at-rest routinely fail to provide value on top of full disk encryption" to "Scott says FDE is bad" is unclear. Additionally: From a software perspective, the risks you all outlined are morally equivalent to the hard drives grew legs and walked because they are the same risk; namely, loss of control of the actual hard drives. The article in question is focused on threats when those drives are plugged in and the keys are being used to encrypt/decrypt data. As several others have pointed out already, I explicitly state this, repeatedly. I don't know how to make it more clear.
- tossandthrow 2y ago
  All the risk vectors you list yourself are about physically being able to get the disk. The author states that "growing legs and walk out" (understood as people being able to physical access to the disk) is already mitigated by disk encryption. So not only are you not adding anything to the article. You actively try to dismiss that the author has thought the cases you bring up through (and calling them out as narrow minded on false grounds). I think we all would love to see a risk that is mitigated by encryption at rest and is not already being mitigated by disk encryption.
- darkwater 2y ago
  Is it that complicated to admit you misread and/or misinterpreted TFA and you posted a wrong comment?

ziddoap 2y ago

>This article is so narrow-minded .. Indeed, they said exactly that. See: >Important: I’m chiefly interested in discussing one use-case, and not focusing on other use cases. Namely, I’m focusing on encryption-at-rest in the narrow context of web applications and/or cloud services.

l33t7332273 2y ago
In web applications and cloud services drives could still be misplaced, stolen, or improperly disposed of. Further, if data is encrypted at rest then there are multiple levels of auth that must fail for a breach to occur, namely access to the data and access to the key.
- ziddoap 2y ago
  While threat modeling, you talk about specific scenarios and specific threats. That does not mean other scenarios and threats don't exist. It just means they aren't the focus of that particular conversion. >In web applications and cloud services drives could still be misplaced, stolen, or improperly disposed of. This is explicitly called out in the article by the author, despite it not being part of the threat model the author is examining. And people are still bringing it up like some sort of gotcha. See (again): >This is not a comprehensive blog post covering every possible use case or threat model relating to encryption at rest.
  - l33t7332273 2y ago
    I’d say the author is being so restrictive in the scope of threats that it isn’t very useful. Regardless, even in their very restrictive scenario, it provides defense in depth as I said.
    - CiPHPerCoder 2y ago
      > I’d say the author is being so restrictive in the scope of threats that it isn’t very useful. Loss of control of the hard disks may have many different ways it can manifest in the real world, but from a cryptography and software development perspective, is congruent to other flavors of the same underlying problem. That's not being "restrictive", it's recognizing the common denominator.

velcrovan 2y ago

From the article: "Disk Encryption is important for disk disposal and mitigating hardware theft, not preventing data leakage to online attackers."

KennyBlanken 2y ago
...which is a concept nearly anyone working in IT understands. I don't think the vast majority of people with IT/ops experience seriously thinks that encryption at rest provides data protection from people getting unauthorized access to the system, in person or remotely...aside from maybe management that ended up in charge of IT and engineering departments without almost any practical-skills background in either. The author is confusing "it costs us nothing (now that encryption can be done in hardware and is integrated into most desktop operating systems) and protects in some scenarios, so yeah, we just decided to mandate it always be done" with "PEOPLE THINK ENCRYPTION AT REST IS A MAGIC BULLET LOOK AT ME I'M INSIGHTFUL, POST LINKS TO MY BLOG ON LINKEDIN!" The whole post is insulting to the intelligence of even a fairly junior desktop support technician.
- CiPHPerCoder 2y ago
  > The author is confusing "it costs us nothing (now that encryption can be done in hardware and is integrated into most desktop operating systems) and protects in some scenarios, so yeah, we just decided to mandate it always be done" with "PEOPLE THINK ENCRYPTION AT REST IS A MAGIC BULLET LOOK AT ME I'M INSIGHTFUL, POST LINKS TO MY BLOG ON LINKEDIN!" What in the article gave you that impression? I do not hold this confusion in my mind, nor did I deliberately encode such a statement in my blog. I'm curious why you think this is what I was saying. > The whole post is insulting to the intelligence of even a fairly junior desktop support technician. If that was true, every time someone posts "Show HN: My Hot New Database Encryption Library in Haskell", they would be mitigating the confused deputy attack by design, rather than what we see today: Namely, failing to even protect against padding oracle attacks. That's what the article was actually talking about.
- deleted 2y ago
  [deleted]

j-bos 2y ago

Comments like these are doubly great, useful tech perspectives, and a reminder that the comments often do not reflect understanding of the original submissions.

PaulStatezny 2y ago
Ha, I also love the irony of your parent comment. Seems to totally miss the point, but I still upvoted because it illuminates the purpose of disk-level encryption so well, adding color to the conversation.

KRAKRISMOTT 2y ago

It also defends against cultural indifference to privacy violations. If you go to Reddit r/sysadmin, most SREs and DevOps folks generally do not care too much for challenging subpoenas and government data requests. If a three letter spook shows up to their data center and demands data, it's just another Tuesday for them. IT people are very different from software engineers who are more likely to protest online and offline about civil right violations and government overreach.

EPWN3D 2y ago
Yeah I've always gotten power tripping vibes from sysadmins. They're happy to fork over data just to show that they can.
- Volundr 2y ago
  This is a weird take. For one, handing over data because someone in power told you too is the exact opposite of power tripping. It's pretty much the entire description of disempowering. But secondly, the idea that anyone who actually has a say in if the data is turned over (the legal team, executives) give a flying fork about how a random sysadmin in their data center feels about it is wildly off base. The data is going out or not according to legals instructions. Either sysadmin Bob does it, or he takes a principled stand, gets fired, and Bob 2 takes care of it.
- KAMSPioneer 2y ago
  I'm a sysadmin and I have no idea what you're referring to. Yeah there are guys in my field who are happy to overreach in terms of data access, but I'm sure we can come up with some anecdotes about devs over-harvesting data on...virtually any modern online platform. Most of my colleagues (at least those I've met) tend to be conscientious about data access and privacy. I host several E2EE services for friends/family because I believe in privacy and data sovereignty. But if my company's legal department says "give access to <these guys>," as a sibling commenter said, if I refuse then I'm fired and those guys will still get access. So I do what legal says and keep my job, TYVM.
blitzar 2y ago

redleader55 2y ago

> A hard disk is lost during transit, somehow ? No data is stolen. Arguably, customer data should not leave a secure location on a physical disk. If you want to move your server, backup the data, wipe the disk, move the server/disk/etc, and then put the data back on the disk once it is back in a secure location. The author mentions this in the article - define a secure boundary, don't let the data exit that boundary unencrypted.

yjftsjthsd-h 2y ago
> Arguably, customer data should not leave a secure location on a physical disk. Okay, let's argue. Under what threat model is it a problem to transport sensitive data on encrypted disks?
- forty 2y ago
  Maybe "they can replace the disk firmware during transport while the driver was peeing" kind of attackers?
  - yjftsjthsd-h 2y ago
    That doesn't have anything to do with the customer's data and isn't helped by the suggestion of wiping the drives before transport. The data is encrypted no matter what happens to firmware; that is at best a way to compromise the server(s) after transport.
- spydum 2y ago
  If the device is lost or stolen during transport physically, all it takes is the attacker to gain control of the key, or find a weakness in that firmware or encryption method. While those are stupidly improbable, the reality is once you lose physical custody, the attacker has a lot more options.
brongondwana 2y ago
Never underestimate the bandwidth of a stationwagon loaded with tapes. Arguably, your position is bogus. Why cause a bunch of extra copying around to move a server. "Back up" indeed - to what? Another disk? It's turtles all the way down.

deleted 2y ago

[deleted]

yourapostasy 2y ago

> Rewrite every software, so that every programs handle their own private keys ? Yeah, that's a nightmare, not gonna happen. PCI 4.0 disallows using Full Disk Encryption to fulfill its encryption at rest requirements, because it demands a finer-grained encryption authorization model. For applications subject to PCI 4.0 compliance, my clients have to encrypt beyond the application level, and down to the service account level used by the application (most of these applications use multiple service accounts for representing teams that use the applications), with different files encrypted for different authorization groups. There are very few enterprise scale solutions addressing this at the moment, and the stopgap I've seen is indeed the application teams are resorting to handling their own keys if the enterprise doesn't offer a finer-grained solution. The QSA's don't yet understand how seismic a shift this is, nor how inadequate the assumed authorization schema is for the many edge cases out there that will be unable to adopt the assumption a single key for a single group is sufficient to model all use cases. It will be a little messy until folks sort through the edge cases coming down the pike.

motymichaely 2y ago
You’re absolutely right! Full disk encryption (FDE) does indeed fall short of PCI 4.0 requirements because it transparently decrypts data for anything running on the OS or accessed by the user, which isn't sufficient for finer-grained control. PCI 4.0 demands more granular encryption authorization models, where data is either encrypted at the file or column level, or access to plain data is restricted to more specific roles than just the OS user account. This is to reduce the risk of unauthorized access. There are a few dev-centric data protection solutions that address these requirements seamlessly. These solutions allow you to store and encrypt any type of data with simple APIs while transparently managing keys, rotation, and granular access controls. I am currently evaluating Piiano Vault (https://www.piiano.com/pii-data-privacy-vault https://www.piiano.com/pii-data-privacy-vault) as one such solution for a new product that I am currently working on that would require a PCI compliant zero-data solution. Seems like its delivery model is very flexible - it can be fully self-hosted or consumed as a managed SaaS, providing robust data protection tailored to my specific needs. Will update with my findings!

jiveturkey 2y ago

laptop theft is actually far worse a problem than data center. well, not in terms of scope, but in terms of frequency at least. you can actually expect laptops to be stolen. i think you misread the article. i found it to be a great, even excellent, discussion of WHY and then explaining HOW in terms of the WHY.