3 ms·

I wonder about this a bit. If I'm already storing all the PII in my database, probably on other people's computers via a managed database or at least a cloud se

by rfrey 4y ago

I wonder about this a bit. If I'm already storing all the PII in my database, probably on other people's computers via a managed database or at least a cloud server, why are logs different? Is it because they don't receive the same security scrutiny, e.g. any dev can view them versus having special permissions for the database? Or is there more there than authorization that I should be thinking about? (Obviously I'm not talking about logging cleartext passwords, which don't belong in the database either.)

oandhjakk 4y ago
I believe the main concern here, from dealing with clients that have mandated no PII in logs, is both authorisation as well as control. If it’s in your service logs, then it could be in your Splunk logs, it could be in a storage repository and it could be in your requests that you send to the service provider to troubleshoot some issue. Unless there is a valid use case for logging PII (and I can’t think of any which can’t be engineered around) then I think it’s best to avoid it in principle. I think of it as the same as logging passwords, keys or tokens.
throwaway74829 4y ago
Permissions is the big one. Second is potential for DDoS (either intentionally or unintentionally). Third is possibility of "oopsies" via me intentionally or unintentionally including my passwords/sensitive info/what have you in the POST body. Now you have to add branch to look for and scrub sensitive info in your logger -- otherwise my PII has now been logged (and if I were a massive asshole looking for a quick payday, I could throw up a fuss). It's fine in dev, but shouldn't be in prod. Too much liability.
michaelmior 4y ago
I believe this also plays into "right to be forgotten legislation" such as in the GDPR. Suppose you log PII and then a user requests all their PII be deleted. I believe you would then also be required to scrub those logs instead of just dropping records from a database.

by rfrey 4y ago

oandhjakk 4y ago

I believe the main concern here, from dealing with clients that have mandated no PII in logs, is both authorisation as well as control. If it’s in your service logs, then it could be in your Splunk logs, it could be in a storage repository and it could be in your requests that you send to the service provider to troubleshoot some issue. Unless there is a valid use case for logging PII (and I can’t think of any which can’t be engineered around) then I think it’s best to avoid it in principle. I think of it as the same as logging passwords, keys or tokens.

throwaway74829 4y ago

Permissions is the big one. Second is potential for DDoS (either intentionally or unintentionally). Third is possibility of "oopsies" via me intentionally or unintentionally including my passwords/sensitive info/what have you in the POST body. Now you have to add branch to look for and scrub sensitive info in your logger -- otherwise my PII has now been logged (and if I were a massive asshole looking for a quick payday, I could throw up a fuss). It's fine in dev, but shouldn't be in prod. Too much liability.

michaelmior 4y ago

I believe this also plays into "right to be forgotten legislation" such as in the GDPR. Suppose you log PII and then a user requests all their PII be deleted. I believe you would then also be required to scrub those logs instead of just dropping records from a database.