Audit logs – the recorded evidence of each action or event that has happened in an information system – is an agreed best practice in the industry. But in many cases they are not just best practices – they are a necessity according to multiple standards and regulations, including ISO 27001, PCI-DSS, HIPAA, the PNR Directive and many more.
And although these standards and regulations have strong requirements for the integrity of the logs, these requirements often get covered only by organizational, rather than technical measures. ISO 27001 “12.4.2 Protection of log information” and PCI-DSS “Requirement 10.5 – Secure assessment trails so they cannot be altered” are often achieved by limiting access to the audit logs. Although it is generally recommended to use additional technical measures, it is rarely the case. And as one book on ISO 27001 warns:
System logs need to be protected, because if the data can be modified or data in them deleted, their existence may create a false sense of security.
So even though you may be formally ISO 27001 or PCI-DSS compliant, this may be a false sense of security if you rely just on limiting the access to the logs, as this does not prevent a malicious internal actor from tampering with the logs and that going undetected for a long period of time.
There are many ways to protect the audit logs in addition to the access control mechanisms. A recent article by our founder explains the different approaches. They include trusted timestamping of log files, hash chaining, hash chaining with external anchoring and WORM storage. More details can be found in the linked article, but implementing either of them is not trivial.
We decided that we can hide that complexity and wrap it in an easy-to-integrate service, LogSentinel, which applies all of the above techniques to protect the integrity of audit logs.
We recently conducted a survey (also found in the article above) and found that just half of the respondents have audit log implemented in their systems, and a little more than half of them actually have any technical measures to protect the logs. This somewhat confirms the “false sense of security” hypothesis and it should be addressed somehow.
It is clear that audit logs are not a primary feature of any product and they are often developed with minimal effort, just to tick some box, often for compliance reasons. But it is crucial to at least be aware that just having an audit log, or even making sure it is not accessible to a wide range of employees, doesn’t serve its actual purpose, and makes forensics much less valuable, as you can’t be certain that logs have not been tampered with. Compliance is one thing, but the purpose of that compliance is to actually protect your data. And that’s why cryptographic protection is strongly recommended.