3 ms·

Simply overwriting with zeros isn't a 100% fix by any means and actually it does involve writing perhaps 1TB of data in sequence. For any storage array that's a

Simply overwriting with zeros isn't a 100% fix by any means and actually it does involve writing perhaps 1TB of data in sequence. For any storage array that's a lot of data to write. It doesn't matter if its 0s or something else. Better is to use random data but even so you still have forensic techniques to revert this. You say encryption is complicated but actually as a vendor its implicit in our system. As a customer you just mark the drive upon creation and then its invisible to both you as a customer and the cloud servers that are using the drive. That's really the whole idea, to make security measures that are convenient so people actually use them. Our customers see usually about a 10%-15% performance difference and we've got pretty high storage performance to begin with so it rarely means taking a performance hit compared with other platforms. We also allow multiple drives so users can categorise data by drives for encryption or not. Of course I'm biased regarding performance but the principles stand. The other point of the blog post is to ask; what do other vendors do and do their customers have the ability to find out? Security through obscurity isn't an acceptable approach in the cloud. Everyone needs to be transparent and work to build confidence through solid information and education on how to use the cloud securely and effectively. Kind regards, Patrick

moe 16y ago
Better is to use random data but even so you still have forensic techniques to revert this. How does one revert this without physical access to the drive? We overwrite our EBS volumes with zeros before deleting them and I was under the impression that should protect us against leakage to other customers. Naturally it can't protect us against a malicious amazon employee pulling the drive physically (or taking snapshots without our knowledge), but frankly I don't see how your "vendor encryption" helps with that either. If all I do is set a checkbox to "mark the drive for encryption" then that means a) You have the encryption key, I don't. b) The checkbox could just as well be a placebo and not have any effect. Thus we're back to square 1 and the same old question: "Do I trust you?" No need to take a 10%-15% performance hit for that.
- cloudsigma 16y ago
  You raise a number of interesting points. Firstly we can't comment on the arrangements of other companies for whom we don't have visibility. As a customer you can of course ask them and one would hope they are able to provide you with a full answer. On the blog we raise and answer (in our case) the various aspects for data storage, not just of security but also legal issues and data migration aspects. How many customers currently using an IaaS cloud can answer those questions or get their vendor to provide answers? Building confidence in cloud computing is all about transparency, education and creating secure ways of working. Different users will choose different solutions and regimes that they feel are 'secure' for them and we are all for that. We'd also like people to be able to make informed choices which means having the right information. Secondly, there is a big difference between a vendor that has sole root access and full visibility of all your data and one that doesn't (as in our case); in our cloud the customer retains sole root access to cloud servers. This means our employees don't have visibility into cloud servers in the way you suggest. Further, as clearly stated in the blog, the issue raised is about data leakage i.e. data being accessible between cloud users. There are other issues regarding vendor security but this doesn't negate the points being made about data leakage. Finally, your point regarding the encryption being a placebo is specious. There is a big difference between making systems secure against casual data theft/leakage or the actions of rogue employees and a company that is institutionally set up to lie and steal their customers' data. If you think your vendor is actually of that nature then no security measure can help and that's the case for any company you have dealings with. It really isn't a valid criticism of any security measure that may be put in place. The measures we outline and have implemented on the vendor side do address the real issue of data leakage that occurs with block storage devices in IaaS clouds; they are effective and they are convenient. Our storage performance is generally higher than many other vendors to begin with and we have much feedback from customers regarding this even after using encryption. These customers are getting good performance in a secured cloud. For them it makes sense. Best wishes, Patrick
  - moe 16y ago
    I can't help it, it just doesn't make sense to me. The only people it would theoretically protect me against are your people (those with physical access). And if I don't trust your people then why should I trust your encryption? The issue of data leakage between customers (who don't have physical access) seems so trivial to prevent to me that I'm honestly wondering if I'm missing something fundamental here. What's wrong with just making a loopback file and mounting that to the customer node? I had in fact assumed that this is how most clouds do it (for sanity reasons alone, security being the bonus). Hence I'm rather baffled by the whole claim of "data leakage through reading the raw volume". Has that ever happened on any cloud provider?

moe 16y ago

Better is to use random data but even so you still have forensic techniques to revert this. How does one revert this without physical access to the drive? We overwrite our EBS volumes with zeros before deleting them and I was under the impression that should protect us against leakage to other customers. Naturally it can't protect us against a malicious amazon employee pulling the drive physically (or taking snapshots without our knowledge), but frankly I don't see how your "vendor encryption" helps with that either. If all I do is set a checkbox to "mark the drive for encryption" then that means a) You have the encryption key, I don't. b) The checkbox could just as well be a placebo and not have any effect. Thus we're back to square 1 and the same old question: "Do I trust you?" No need to take a 10%-15% performance hit for that.

cloudsigma 16y ago
You raise a number of interesting points. Firstly we can't comment on the arrangements of other companies for whom we don't have visibility. As a customer you can of course ask them and one would hope they are able to provide you with a full answer. On the blog we raise and answer (in our case) the various aspects for data storage, not just of security but also legal issues and data migration aspects. How many customers currently using an IaaS cloud can answer those questions or get their vendor to provide answers? Building confidence in cloud computing is all about transparency, education and creating secure ways of working. Different users will choose different solutions and regimes that they feel are 'secure' for them and we are all for that. We'd also like people to be able to make informed choices which means having the right information. Secondly, there is a big difference between a vendor that has sole root access and full visibility of all your data and one that doesn't (as in our case); in our cloud the customer retains sole root access to cloud servers. This means our employees don't have visibility into cloud servers in the way you suggest. Further, as clearly stated in the blog, the issue raised is about data leakage i.e. data being accessible between cloud users. There are other issues regarding vendor security but this doesn't negate the points being made about data leakage. Finally, your point regarding the encryption being a placebo is specious. There is a big difference between making systems secure against casual data theft/leakage or the actions of rogue employees and a company that is institutionally set up to lie and steal their customers' data. If you think your vendor is actually of that nature then no security measure can help and that's the case for any company you have dealings with. It really isn't a valid criticism of any security measure that may be put in place. The measures we outline and have implemented on the vendor side do address the real issue of data leakage that occurs with block storage devices in IaaS clouds; they are effective and they are convenient. Our storage performance is generally higher than many other vendors to begin with and we have much feedback from customers regarding this even after using encryption. These customers are getting good performance in a secured cloud. For them it makes sense. Best wishes, Patrick
- moe 16y ago
  I can't help it, it just doesn't make sense to me. The only people it would theoretically protect me against are your people (those with physical access). And if I don't trust your people then why should I trust your encryption? The issue of data leakage between customers (who don't have physical access) seems so trivial to prevent to me that I'm honestly wondering if I'm missing something fundamental here. What's wrong with just making a loopback file and mounting that to the customer node? I had in fact assumed that this is how most clouds do it (for sanity reasons alone, security being the bonus). Hence I'm rather baffled by the whole claim of "data leakage through reading the raw volume". Has that ever happened on any cloud provider?