Menu
The suggestion to encrypt log files as a means of protecting the personal data that might be contained in them is widespread.
What I've not seen is a good reference implementation, which is surprising given how many companies will need this.
In our particular case, we want to use public key encryption so that the files can not be read on the (weakly protected) system that generates them, and must be sent back to head office where we can look at them.
The best suggestion I've seen so far is "use log4net but write your own appender using the RFC 3852 streaming implementation from BouncyCastle". Does anyone have an advance on that?
383
Article 32 of the UK GDPR includes encryption as an example of an appropriate technical measure, depending on the nature and risks of your processing activities. Encryption is a widely-available measure with relatively low costs of implementation.
Logging consent and the accompanying circumstances – date, time, IP address, etc. Then you can also log consent withdrawal, and the history of the consent of the data subject will be visible in one place and you will be able to prove to regulators when you had and when you didn't have consent for processing.
Although not mandatory under the GDPR, encryption of personal data helps companies to reduce the probability of a breach and thus avoid fines. Encryption can ensure protection for both data in motion and at rest.
Another very useful technique for log protection is to encrypt the log files. When attackers try to edit the files, they will not be able to alter them meaningfully without the encryption key. The attacker's only option will be to delete the log file, a very noticeable action.
Technically, encrypting your log messages should be pretty easy. Using something like Serilog you could simply create a custom sink.
Just blind encrypting the whole log is probably going to limit the usefulness of the logs though. If you're centralizing your logging using something like ELK then you won't be able to search based on any field/part of your logs that you encrypt (for example, if you encrypt the machine name then you don't even know where the logs come from!).
If the kind of information that you're dealing with genuinely is personally identifiable information covered by GDPR then maybe you just have to suck that up - but I'd make an effort to encrypt only sensitive information from your logs rather than just blanket encrypting everything... that would require a more sophisticated sink but it will make your log data way less crippled.
70
I agree with some of the commentators; personal data should not be a part of the log files. GDPR is not about the encryption - if you just encrypt personal data that does not mean that you're GDPR compliant. What will happen with the personal data in your log files when you receive "forget me" (Right to erasure) request from the individual? Or "change my data" (Right to rectification)?
However, if you need to log personal data, maybe the option can be to hash the information and store hashed version in the logs. In that case, you'll be able to find the specific data in the logs, by calculating the hash from the search string.
Related to a public key encryption part of your question, take a look: https://aws.amazon.com/kms or https://azure.microsoft.com/en-us/services/key-vault/
39
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
