5 ms·

Any service that reuses the same physical drive space should be vulnerable unless they either store encrypted or do secure deletion. Having used secure deletion

Any service that reuses the same physical drive space should be vulnerable unless they either store encrypted or do secure deletion. Having used secure deletion before on dedicated hardware it is really hitting the drive performance. That is why I am guessing vendors don't use secure deletion. Using encryption overall looks more efficient overall.

cloudsigma 16y ago
Secure deletion on physical spindles is extremely resource heavy especially if someone is deleting a very large drive. Storing encrypted first does affect performance but it is generally much less and more predictable (doing a big secure delete on a drive inflicts an immediate and unexpected hit on that part of a storage array). We think encryption is also just a lot more robust. If you don't lay down the data in the first place in readable form on the physical drives, its eliminates a lot of data leakage possibilities. Best wishes, Patrick
moe 16y ago
Sorry, but this is really bordering on FUD here. Have you ever looked at a freshly mounted EBS volume on EC2? It shows all zero's for me. And I'm almost sure that was not just a coincidence for the volumes I looked at. Moreover there are more efficient ways than encryption or "full sweep overwrite" to address this at the storage-level.
- cloudsigma 16y ago
  Our post is regarding IaaS clouds in general and has nothing specifically to do with EC2 or any other particular vendor. It may be the case that EC2 does have secure measures in place; I wonder how many of their customers can articulate them (or customers of other IaaS clouds for that matter)? We are merely raising an important issue. You can look at the many other posts we have on the other various aspects of security in the cloud of which this post forms the latest instalment regarding data storage. "there are more efficient ways than encryption or "full sweep overwrite" to address this at the storage-level." Your suggestion would be? Kind regards, Patrick
  - cloudsigma 16y ago
    Vukk, The issue there is more about tracking. You'd have to track every single block and return zero for any that hadn't been used/altered since drive creation. I'm guessing it would prove pretty costly in terms of latency for drive access after initial drive creation but its a good idea potentially. I'll pass it onto our technical guys as well to ask about its feasibility. Best wishes, Patrick
  - moe 16y ago
    Your suggestion would be? See my reply above about using a loopback-file. It's a one-liner: dd if=/dev/zero of=/vols/customer123/vol234 seek=$SIZE bs=1 count=1 There's surely quite a few other ways to skin this cat (eventually arriving at the multi-tenancy features in proprietary SAN appliances), but this seems the most obvious one.
  - vukk 16y ago
    Since we are not directly accessing the HDD, couldn't the virtualization layer say if(disk block not written before) return 0; and thus the customer wouldn't have to worry? Or is this too inefficient?

cloudsigma 16y ago

Secure deletion on physical spindles is extremely resource heavy especially if someone is deleting a very large drive. Storing encrypted first does affect performance but it is generally much less and more predictable (doing a big secure delete on a drive inflicts an immediate and unexpected hit on that part of a storage array). We think encryption is also just a lot more robust. If you don't lay down the data in the first place in readable form on the physical drives, its eliminates a lot of data leakage possibilities. Best wishes, Patrick

moe 16y ago

Sorry, but this is really bordering on FUD here. Have you ever looked at a freshly mounted EBS volume on EC2? It shows all zero's for me. And I'm almost sure that was not just a coincidence for the volumes I looked at. Moreover there are more efficient ways than encryption or "full sweep overwrite" to address this at the storage-level.

cloudsigma 16y ago
Our post is regarding IaaS clouds in general and has nothing specifically to do with EC2 or any other particular vendor. It may be the case that EC2 does have secure measures in place; I wonder how many of their customers can articulate them (or customers of other IaaS clouds for that matter)? We are merely raising an important issue. You can look at the many other posts we have on the other various aspects of security in the cloud of which this post forms the latest instalment regarding data storage. "there are more efficient ways than encryption or "full sweep overwrite" to address this at the storage-level." Your suggestion would be? Kind regards, Patrick
- cloudsigma 16y ago
  Vukk, The issue there is more about tracking. You'd have to track every single block and return zero for any that hadn't been used/altered since drive creation. I'm guessing it would prove pretty costly in terms of latency for drive access after initial drive creation but its a good idea potentially. I'll pass it onto our technical guys as well to ask about its feasibility. Best wishes, Patrick
- moe 16y ago
  Your suggestion would be? See my reply above about using a loopback-file. It's a one-liner: dd if=/dev/zero of=/vols/customer123/vol234 seek=$SIZE bs=1 count=1 There's surely quite a few other ways to skin this cat (eventually arriving at the multi-tenancy features in proprietary SAN appliances), but this seems the most obvious one.
- vukk 16y ago
  Since we are not directly accessing the HDD, couldn't the virtualization layer say if(disk block not written before) return 0; and thus the customer wouldn't have to worry? Or is this too inefficient?