4 ms·

Acronis, a german corporation, is implementing the GDPR too [0] and they recommend that if possible, you split backups per customer, if that is not practical at

by tscs37 8y ago

Acronis, a german corporation, is implementing the GDPR too [0] and they recommend that if possible, you split backups per customer, if that is not practical atleast do your best to protect the data and don't keep it for unnecessary time frames. You should have a retention policy and encrypt your backups. [0]: https://www.acronis.com/en-us/blog/posts/backups-and-gdpr-right-be-forgotten-recommendations https://www.acronis.com/en-us/blog/posts/backups-and-gdpr-ri... [A0]: http://www.gdprarticles.com/gdpr-articles/data-subject-rights/gdpr-right-to-be-forgotten-include-backups/ http://www.gdprarticles.com/gdpr-articles/data-subject-right... [A1]: GDPR Art. 5 §1 a, b, c and f, §2 [A2]: GDPR Art. 17 §1 b and c, §3 b and e >So now I can't perform impromptu analysis of my own data in any computationally easy way? Security analysis? Analyzing shipping information to optimize in the future? Any analysis will have to be done in a way to make sure you're not exceeding the bounds of network security or you're outside legitimate interest. Analyzing shipping information is the same, as long as you do everything to make sure the data is pseudonimized or not otherwise in risk of leaking personal data, it's fine or alternatively you ask customers about it. >What if retention is reasonably long (a year)? or not (10 years)? Use your own judgement of what is reasonable, worst case you get a letter from the EU asking you to reduce the retention timeframe as long as you made an actual effort to implement the regulation.

jimktrains2 8y ago
My question wasn't so much about doing the analysis, but about being unable to do it without fetching keys and decrypting on a per-log-entry basis. Not only would this be insufferably slow, I've not seen a feature like this in any COTS software and quite frankly seems incredibly difficult to write properly and securely, specifically the key management portion.
- acdha 8y ago
  > Not only would this be insufferably slow Why do you think that's a given? It seems like an implementation detail with a couple of easy solutions such as caching or batching, and it should encourage better system design in many cases where the analysis doesn't require PII and thus it's better from a security perspective not to have access to it there to begin with. There have been a ton of breaches over the years where reporting or test systems had data which they didn't even need but which had been loaded anyway since it was less work than subsetting the data.
  - jimktrains2 8y ago
    > analysis doesn't require PII and thus it's better from a security perspective not to have access to it there to begin with. Unless I'm pulling from a raw dump of shipping I've bought, which would contain the address so that it can be cross-checked if there is an issue and I didn't know ahead of time that I wanted to perform this analysis.
    - tscs37 8y ago
      If you want this analysis you should plan for it. Mozilla does this for example. Any kind of profiling or monitoring goes through several layers to ensure the minimum amount of data necessary is collected. If you want shipping analytics you'll have to decide that ahead of time. That way you reduce the risk for your customer in case you don't want to do this and if you do want it you still make an effort to reduce the data necessary. You should keep in mind that the basic premise of the GDPR is that the shipping address isn't yours to begin with. It's personal data of your customer and ultimately belongs to them. If they don't allow you to use it for analytics, tough luck.
      - jimktrains2 8y ago
        > If you want this analysis you should plan for it. Yes, I should be omniscient. Thanks for clearing that up. > Any kind of profiling or monitoring goes through several layers to ensure the minimum amount of data necessary is collected. Yes, because they need to collect it. It's not about looking at what they have. > If you want shipping analytics you'll have to decide that ahead of time. Again, I'm not omniscient. I can't figure out what my company will be doing in a year, and waiting another year to collect the data I already have could see me hemorrhaging money. > You should keep in mind that the basic premise of the GDPR is that the shipping address isn't yours to begin with. It's personal data of your customer and ultimately belongs to them. Which is an absolutely silly notion. It is the company's data, not the users. > If they don't allow you to use it for analytics, tough luck. Which is silly. It's the company's data; they should be able to use it to improve their business.
jimktrains2 8y ago
Another point, what about "personal data" that isn't really? Webserver log, for instance, contains an IP, which is covered under the law as personal information I believe. This is could be part of carrier grade Nat serving thousands (or even just regular Nat of 2 or 3 people), must I delete everyone? Who's keep would these be encrypted with in your solution?
- zaarn 8y ago
  Webserver logs should for most intents be covered under legitimate interest as part of securing your network. As long as you rotate your server logs, which is default for any distro installation (AFAIK), you don't have to delete those when a user requests them.
  - jimktrains2 8y ago
    Most companies collect and centralize logs, making logrotate irrelevant. What prevents a company from having decade long rotations? Also, who decides what is a legitimate interest?
    - zaarn 8y ago
      Even centralized logs can have rotation and retention. The company will have to decide for themselves, primarly, if some interest is legitimate. This means you weigh the data you collect by the single user against the continued function of the company, the great good and all other users. The company should then be able to demonstrate this process to the regulatory body. There is no nailed process but keeping logs for a short amount of time to ensure network security and keeping some logs longer for legal compliance will most certainly pass as legitimate interest. Network security benefits the user themself, the company and all other users by ensuring their data is secured against breaches. It goes beyond simple self-interest of the company and protects the users too. Similarly having an email address to contact a user can be legitimate interest. If you only send them informative mail, ie "Someone changed your password" and "We had a databreach" or even "Someone tried to login from Uganda using your password, check if that's alright please" it serves primarly to protect you, the customer and the relationship you build up. IMO that means it's legitimate. On the other hand, of course an adcorp could claim their personal tracking data is legitimate. The data collected does not benefit the user other than showing them ads and selling it to others. Of the three groups, only one benefits. Or keeping a webserver log for 20 years including usernames and emails. IMO that would mean it's not legitimate. If you are wrong in what you think is legitimate, you get a sternly worded letter from your favorite regulatory body asking you to fix it. If you think they are wrong about that, the best option is to write them back and explain why you think it's legitimate. You can work out a solution with them that satisfies both sides.

by tscs37 8y ago

jimktrains2 8y ago

My question wasn't so much about doing the analysis, but about being unable to do it without fetching keys and decrypting on a per-log-entry basis. Not only would this be insufferably slow, I've not seen a feature like this in any COTS software and quite frankly seems incredibly difficult to write properly and securely, specifically the key management portion.

acdha 8y ago
> Not only would this be insufferably slow Why do you think that's a given? It seems like an implementation detail with a couple of easy solutions such as caching or batching, and it should encourage better system design in many cases where the analysis doesn't require PII and thus it's better from a security perspective not to have access to it there to begin with. There have been a ton of breaches over the years where reporting or test systems had data which they didn't even need but which had been loaded anyway since it was less work than subsetting the data.
- jimktrains2 8y ago
  > analysis doesn't require PII and thus it's better from a security perspective not to have access to it there to begin with. Unless I'm pulling from a raw dump of shipping I've bought, which would contain the address so that it can be cross-checked if there is an issue and I didn't know ahead of time that I wanted to perform this analysis.
  - tscs37 8y ago
    If you want this analysis you should plan for it. Mozilla does this for example. Any kind of profiling or monitoring goes through several layers to ensure the minimum amount of data necessary is collected. If you want shipping analytics you'll have to decide that ahead of time. That way you reduce the risk for your customer in case you don't want to do this and if you do want it you still make an effort to reduce the data necessary. You should keep in mind that the basic premise of the GDPR is that the shipping address isn't yours to begin with. It's personal data of your customer and ultimately belongs to them. If they don't allow you to use it for analytics, tough luck.
    - jimktrains2 8y ago
      > If you want this analysis you should plan for it. Yes, I should be omniscient. Thanks for clearing that up. > Any kind of profiling or monitoring goes through several layers to ensure the minimum amount of data necessary is collected. Yes, because they need to collect it. It's not about looking at what they have. > If you want shipping analytics you'll have to decide that ahead of time. Again, I'm not omniscient. I can't figure out what my company will be doing in a year, and waiting another year to collect the data I already have could see me hemorrhaging money. > You should keep in mind that the basic premise of the GDPR is that the shipping address isn't yours to begin with. It's personal data of your customer and ultimately belongs to them. Which is an absolutely silly notion. It is the company's data, not the users. > If they don't allow you to use it for analytics, tough luck. Which is silly. It's the company's data; they should be able to use it to improve their business.

jimktrains2 8y ago

Another point, what about "personal data" that isn't really? Webserver log, for instance, contains an IP, which is covered under the law as personal information I believe. This is could be part of carrier grade Nat serving thousands (or even just regular Nat of 2 or 3 people), must I delete everyone? Who's keep would these be encrypted with in your solution?

zaarn 8y ago
Webserver logs should for most intents be covered under legitimate interest as part of securing your network. As long as you rotate your server logs, which is default for any distro installation (AFAIK), you don't have to delete those when a user requests them.
- jimktrains2 8y ago
  Most companies collect and centralize logs, making logrotate irrelevant. What prevents a company from having decade long rotations? Also, who decides what is a legitimate interest?
  - zaarn 8y ago
    Even centralized logs can have rotation and retention. The company will have to decide for themselves, primarly, if some interest is legitimate. This means you weigh the data you collect by the single user against the continued function of the company, the great good and all other users. The company should then be able to demonstrate this process to the regulatory body. There is no nailed process but keeping logs for a short amount of time to ensure network security and keeping some logs longer for legal compliance will most certainly pass as legitimate interest. Network security benefits the user themself, the company and all other users by ensuring their data is secured against breaches. It goes beyond simple self-interest of the company and protects the users too. Similarly having an email address to contact a user can be legitimate interest. If you only send them informative mail, ie "Someone changed your password" and "We had a databreach" or even "Someone tried to login from Uganda using your password, check if that's alright please" it serves primarly to protect you, the customer and the relationship you build up. IMO that means it's legitimate. On the other hand, of course an adcorp could claim their personal tracking data is legitimate. The data collected does not benefit the user other than showing them ads and selling it to others. Of the three groups, only one benefits. Or keeping a webserver log for 20 years including usernames and emails. IMO that would mean it's not legitimate. If you are wrong in what you think is legitimate, you get a sternly worded letter from your favorite regulatory body asking you to fix it. If you think they are wrong about that, the best option is to write them back and explain why you think it's legitimate. You can work out a solution with them that satisfies both sides.