cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Wayne_Evans
Newcomer III

CCSP - Crypto Shredding and Migration away from one provider to another

Hi,

As I was studying for CCSP, I was thinking about the end of life of a customers contract with a Cloud Service Provider (CSP). Something along the lines of the customer moves away from a particular CSP to another.

Naturally, I expect as with most things the risk profile of the data/information determines the level of destruction/erasure assurance required on departure from a CSP. I see and understand the sense of crypto shredding, and it makes complete sense as the viable solution. 

However, I am thinking that unless your data was encrypted at implementation time, you could not assert with any real confidence that the data will not be recovered either by brute force decryption or via the CSP having unencrypted backups, or the encryption keys.

I would like to think that any CSP has policies that deal with the migration away from their platform? My googling hasn't turned up any example policies; I doubt they would be publicly available.

Does anyone have experience of this migrating across from one CSP to another CSP and ensuring data/information removal? Any example, policies from a CSP in this regard people are willing to share?

From what I can tell the customer would have just to believe the CSP that they do not hold any residual information. IE That the cloud provider does not have random backups on their replicated SANs/backup services or old LTO tapes.

Where is the line drawn, does it come down to simple trust (via contractual obligation?)? ("No friends in Crypto" springs to my mind) That you believe the assertions of the CSP that they have not retained any of your data as you migrate away.  However, what is their motivation to be diligent and attentive to a departing customer?

Also, would this encrypting, and destroying the encryption keys be enough to prove due diligence and care was taken with that data/information, and would that be a viable defence if the information was "stole" and identified coming from the old CSP?


Just random thoughts as I’m studying… Thanks in advance, for any input.


Wayne

1 Reply
Early_Adopter
Community Champion

Caveat - for your exam read the book/listen to the expensive certified trainer.. Having said that here are some semi-informed ramblings.

 

IaaS or SaaS, or even PaaS for your new compiled applications?

 

Well if you hyper paranoid, yes the data is encrypted before it hits the service by a GW service this is a classic CASB GW use case - CASB Via API obviously means the data went to the CSP you want to secure against.

 

If that is another CSP then what's to stop them from sneaking a look at your data? I could encrypt for you but slurp as I did it if I was running EvilCloudTM.

 

Maybe one to store and one to process is good? but take Salesforce as an example. If your data any good to you if the CSP can't process it? Homomorphic Encryption is a way off. So in most cases with the cloud, you'll need to trust someone.

 

Reputation for Amazon, Microsoft, and even Google is IMHO essential, that includes departing customers, anyone with that business model with a bad rep is in a lot of trouble.

 

I have no Idea if there are Backup Tapes in Equinix data centers? I figure everything is on disk that is freed up quickly and repurposed efficiently and disks are transported or the data is backed up over fat pipes  - operations churn probably means just as much as crypto shredding, smaller managed service providers might have tapes. If the data is deleted - how long for an overwrite? If you leave me I probably want to delete your data ASAP to get my storage back(unless regulation/contract means I need to keep a copy).

 

If it's encrypted but you have the key in a key store on your premise, in another cloud or on an HSM, then you stop making that available the CSP can't open new files/access new records? like crypt shredding a bit, just withholding the top key.

 

I've never migrated off an existing cloud, but customers migrate onto and off the cloud services the company I work for offers regularly (much more off than on I'm glad to say) and we'd want to make sure we did everything right by the customer, and we're robustly audited on any end of service activities.

 

Bottom line if data was ever in plain text then EvilCloudTM could snaffle it even with crypto shredding unless they never had the plaintext, but I can't see EvilCloudTM getting away with this for very long.