5 ms·

It's not true that you don't need to worry about GDPR if you're only going to use this information for a limited time to analyze attacks. It's a lot more compl

by gyulai 5y ago

It's not true that you don't need to worry about GDPR if you're only going to use this information for a limited time to analyze attacks. It's a lot more complicated than that.

Nextgrid 5y ago
Could you explain? Keeping the information for a reasonable amount of time for security or fraud-detection purposes would definitely fall under legitimate interest. I really don't see any bad outcome happening from doing the reasonable thing. Enforcement is near non-existent (Google and Facebook are still around after all), and when it does happen it still very much skews towards assuming good faith (even when it shouldn't) so you'll definitely be fine even if you get it wrong in which case you'll just be given guidance on how to do better.
layer8 5y ago
I didn’t say you don’t need to worry about GDPR, I said that GDPR doesn’t prohibit keeping such logs.
- gyulai 5y ago
  I just jumped in with a clarification to make sure others who read this don't think that.
gyulai 5y ago
> Could you explain? > Keeping the information for a reasonable amount of time for security or fraud- > detection purposes would definitely fall under legitimate interest. Yes, but not being allowed to collect the data at all is not the only way you can fall foul of GDPR compliance. E.g. you also have to give the data subjects processes for getting info about what data you have on them, getting it corrected if they want to, getting it deleted if they want to. Those are tied to mandatory maximum response times. You have to have a data processing register that the regulator can ask you to show them. You have to have co-controller or subcontractor agreements in place if third parties get to see the data in any way. -- There's a host of things you have to do.
- Nextgrid 5y ago
  > you also have to give the data subjects processes for getting info about what data you have on them Nobody is going to do that for web server logs unless you associate them with user accounts. If it happens once because someone wants to joke around, you can handle it as a one-off. You could also decline unless they can provide a letter from their ISP certifying that the provided IP address is static and has been assigned to them for the requested timeframe, both as a way to verify the legitimacy of the requestor as well as to deter such obviously-malicious requests. > getting it corrected if they want to It's web server logs - those are generated automatically based on incoming request data; there's nothing to "correct" there. > getting it deleted if they want to Up to you how you want to handle this (this depends on whether you need those logs). If you're keeping them for legitimate interest for a certain period of time, you can just refuse, and you can obviously refuse as above until they go through a (admin-intensive) process of actually proving they have owned this IP address for the requested timeframe.
  - gyulai 5y ago
    I quite agree with you that it would be highly unpractical to set up that kind of system around access logs. For that reason, the sensible thing to do is to not have IP addresses in your access log.
- alkonaut 5y ago
  > E.g. you also have to give the data subjects processes for getting info about what data you have on them, getting it corrected if they want to, getting it deleted if they want to. A Policy note is standard for most sites. An email address or form where users can request their data isn't possible for web logs storing IP alone. So long as the analysis window for the logs is shorter than the max response time to data requests, you can always autorespond at the end of the response time window saying "Thanks for your request on date D. We have no data stored for you from date D and earlier". Which would be true since the logs are then already flushed out. The paperwork if there is zero real per-user data, zero third parties/subcontractors etc. will be pretty minimal (thankfully). This is of course assuming 2 things: 1) that you can do all your log analysis in a very short window and 2) that you can do it in house and won't send it to a third party.

by gyulai 5y ago

It's not true that you don't need to worry about GDPR if you're only going to use this information for a limited time to analyze attacks. It's a lot more complicated than that.

Nextgrid 5y ago

Could you explain? Keeping the information for a reasonable amount of time for security or fraud-detection purposes would definitely fall under legitimate interest. I really don't see any bad outcome happening from doing the reasonable thing. Enforcement is near non-existent (Google and Facebook are still around after all), and when it does happen it still very much skews towards assuming good faith (even when it shouldn't) so you'll definitely be fine even if you get it wrong in which case you'll just be given guidance on how to do better.

layer8 5y ago

I didn’t say you don’t need to worry about GDPR, I said that GDPR doesn’t prohibit keeping such logs.

gyulai 5y ago
I just jumped in with a clarification to make sure others who read this don't think that.

gyulai 5y ago

> Could you explain? > Keeping the information for a reasonable amount of time for security or fraud- > detection purposes would definitely fall under legitimate interest. Yes, but not being allowed to collect the data at all is not the only way you can fall foul of GDPR compliance. E.g. you also have to give the data subjects processes for getting info about what data you have on them, getting it corrected if they want to, getting it deleted if they want to. Those are tied to mandatory maximum response times. You have to have a data processing register that the regulator can ask you to show them. You have to have co-controller or subcontractor agreements in place if third parties get to see the data in any way. -- There's a host of things you have to do.

Nextgrid 5y ago
> you also have to give the data subjects processes for getting info about what data you have on them Nobody is going to do that for web server logs unless you associate them with user accounts. If it happens once because someone wants to joke around, you can handle it as a one-off. You could also decline unless they can provide a letter from their ISP certifying that the provided IP address is static and has been assigned to them for the requested timeframe, both as a way to verify the legitimacy of the requestor as well as to deter such obviously-malicious requests. > getting it corrected if they want to It's web server logs - those are generated automatically based on incoming request data; there's nothing to "correct" there. > getting it deleted if they want to Up to you how you want to handle this (this depends on whether you need those logs). If you're keeping them for legitimate interest for a certain period of time, you can just refuse, and you can obviously refuse as above until they go through a (admin-intensive) process of actually proving they have owned this IP address for the requested timeframe.
- gyulai 5y ago
  I quite agree with you that it would be highly unpractical to set up that kind of system around access logs. For that reason, the sensible thing to do is to not have IP addresses in your access log.
alkonaut 5y ago
> E.g. you also have to give the data subjects processes for getting info about what data you have on them, getting it corrected if they want to, getting it deleted if they want to. A Policy note is standard for most sites. An email address or form where users can request their data isn't possible for web logs storing IP alone. So long as the analysis window for the logs is shorter than the max response time to data requests, you can always autorespond at the end of the response time window saying "Thanks for your request on date D. We have no data stored for you from date D and earlier". Which would be true since the logs are then already flushed out. The paperwork if there is zero real per-user data, zero third parties/subcontractors etc. will be pretty minimal (thankfully). This is of course assuming 2 things: 1) that you can do all your log analysis in a very short window and 2) that you can do it in house and won't send it to a third party.