4 ms·

> What are the industry best practices for data deletion? Tokenization. Exchange the data for tokens, and store the sensitive data someplace very secure separa

> What are the industry best practices for data deletion? Tokenization. Exchange the data for tokens, and store the sensitive data someplace very secure separate from the main operational system. To process a delete, delete the token. Ideally this is handled via proxy, so it's a completely separate system from primary app. Having used this method, I feel it ought to be used for every app storing sensitive data. edit: I forgot to mention the biggest issue I have with crypto shredding (encryption per record) is that you can't correlate data between records as you can with tokens.

kevin_nisbet 4y ago
It's not clear to me that this is really sufficient, or even really answers the original question. On the sufficient side, I don't know that retaining an encrypted version of customer data would really meet a lot of compliance definitions for deleted data. Atleast, nothing I've heard of tested in court. Also, depending on the data, even tokenized / encrypted / etc approaches are easy to get wrong and still allow some correlation. In a previous company when it came to network tooling, we had to be extremely careful that we didn't intercept 1 bit of payload, as even though that 1 bit couldn't be used to meaningfully reproduce a phone call, by many legal definitions we would be illegally intercepting phone calls. And then circling back to the original question, the problem of how to manage data and customer deletions if just shifted to how to do this with the tokens. So my take on the original question is as follows. To my knowledge, the right to be forgotten compliance regimes do include time windows for deletions, understanding that it can take time to purge requested data. Also, some customers may want this in their contracts, so I'd try and align any contracts / terms of service with the most strict compliance regimes. When taking backups, if possible use WORM (on S3 I think this is called object locks), and set the lock to be less time than the compliance regime requires, but long enough that there is always locked backups that can't be deleted by a mistake or adversary. Depending on required history, you can then just let the backups expire. If you need longer backup history than the compliance regimes allow, then it comes to structuring backups so selective data can be removed, and then relocking the backup. And doing this on a rolling basis, so at no point in time or run of the cleanup are all backups being touched at the same time.
TazeTSchnitzel 4y ago
Tokenisation makes sense if you have a few very small pieces of highly sensitive data, like credit card data. But almost all data stored in an application might be something you legally must delete in certain circumstances. It's also the case that for some applications, all data is “sensitive”, for example a medical journal application, an application used by a trade union, a facial recognition system, or something as mundane as an HR system.
- ledgerdev 4y ago
  Excellent point. Do you feel encryption/crypto shredding is good for these scenarios where nearly all data is sensitive?

kevin_nisbet 4y ago

It's not clear to me that this is really sufficient, or even really answers the original question. On the sufficient side, I don't know that retaining an encrypted version of customer data would really meet a lot of compliance definitions for deleted data. Atleast, nothing I've heard of tested in court. Also, depending on the data, even tokenized / encrypted / etc approaches are easy to get wrong and still allow some correlation. In a previous company when it came to network tooling, we had to be extremely careful that we didn't intercept 1 bit of payload, as even though that 1 bit couldn't be used to meaningfully reproduce a phone call, by many legal definitions we would be illegally intercepting phone calls. And then circling back to the original question, the problem of how to manage data and customer deletions if just shifted to how to do this with the tokens. So my take on the original question is as follows. To my knowledge, the right to be forgotten compliance regimes do include time windows for deletions, understanding that it can take time to purge requested data. Also, some customers may want this in their contracts, so I'd try and align any contracts / terms of service with the most strict compliance regimes. When taking backups, if possible use WORM (on S3 I think this is called object locks), and set the lock to be less time than the compliance regime requires, but long enough that there is always locked backups that can't be deleted by a mistake or adversary. Depending on required history, you can then just let the backups expire. If you need longer backup history than the compliance regimes allow, then it comes to structuring backups so selective data can be removed, and then relocking the backup. And doing this on a rolling basis, so at no point in time or run of the cleanup are all backups being touched at the same time.

TazeTSchnitzel 4y ago

Tokenisation makes sense if you have a few very small pieces of highly sensitive data, like credit card data. But almost all data stored in an application might be something you legally must delete in certain circumstances. It's also the case that for some applications, all data is “sensitive”, for example a medical journal application, an application used by a trade union, a facial recognition system, or something as mundane as an HR system.

ledgerdev 4y ago
Excellent point. Do you feel encryption/crypto shredding is good for these scenarios where nearly all data is sensitive?