4 ms·

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

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.
    - Dylan16807 2y ago
      The problem is that after that common denominator is recognized, the post implies that it is outside the threat model of "web applications and/or cloud services", when it is not. It doesn't need in-depth discussion, and the way data is still highly exposed despite disk encryption is very important, but that implication is not great.
thelittleone 2y ago
Definitely true and a layered defense against data loss / theft has obvious advantages. But take for instance a small SaaS running on a cloud PaaS (e.g., AWS, GCP etc). What it the likelihood of improper disposal of a hard disk? And then what is the likelihood this improperly disposed of hard disk survives the process of removal / improper disposal to then be found by someone nefarious? And then, what is the likelihood that that particular drive was in a volume that contained anything sensitive. Then what is the cost / overhead / complexity / other cons of adding encryption at rest? Cyber budgets often go crazy I see so many clients that are buying tech based on marketing hype or the security teams lusts for cool tech rather than what reduces the risk the most for the dollars available.
- JackSlateur 2y ago
  Last time I implemented encryption at rest (when I worked for a small cloud provider), it was as easy as adding an option when creating the disk. The option triggered the implementation of a dm-crypt layer between the physical device and the upper storage layers. Crypto keys were stored in the storage system. Once revoked, the whole server was rendered useless (from a data thief point of view). We benchmarked the stuff a bit. Indeed, there was a loss. While dm-crypt uses AES (with hardware acceleration) and since we had multi-hundreds of thousands IOPS per device, we did not care.
  - thelittleone 2y ago
    Most of my clients won't care about that slight performance hit either. Thanks for the info.

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.
  - Dylan16807 2y ago
    The problem is that after that common denominator is recognized, the post implies that it is outside the threat model of "web applications and/or cloud services", when it is not. It doesn't need in-depth discussion, and the way data is still highly exposed despite disk encryption is very important, but that implication is not great.

thelittleone 2y ago

Definitely true and a layered defense against data loss / theft has obvious advantages. But take for instance a small SaaS running on a cloud PaaS (e.g., AWS, GCP etc). What it the likelihood of improper disposal of a hard disk? And then what is the likelihood this improperly disposed of hard disk survives the process of removal / improper disposal to then be found by someone nefarious? And then, what is the likelihood that that particular drive was in a volume that contained anything sensitive. Then what is the cost / overhead / complexity / other cons of adding encryption at rest? Cyber budgets often go crazy I see so many clients that are buying tech based on marketing hype or the security teams lusts for cool tech rather than what reduces the risk the most for the dollars available.

JackSlateur 2y ago
Last time I implemented encryption at rest (when I worked for a small cloud provider), it was as easy as adding an option when creating the disk. The option triggered the implementation of a dm-crypt layer between the physical device and the upper storage layers. Crypto keys were stored in the storage system. Once revoked, the whole server was rendered useless (from a data thief point of view). We benchmarked the stuff a bit. Indeed, there was a loss. While dm-crypt uses AES (with hardware acceleration) and since we had multi-hundreds of thousands IOPS per device, we did not care.
- thelittleone 2y ago
  Most of my clients won't care about that slight performance hit either. Thanks for the info.