Non-repudiation is a key property in many contexts – it means that the author of some message cannot deny that they produced the message. This property has a particular meaning in the context of audit trail and logs in general. As pointed out by Eric Knapp:
Non[-]repudiation refers to the process of ensuring that a log file has not been tampered with, so that the original raw log file can be presented as evidence, without question of authenticity, within a court of law.
Since logs belong to an organization, the property allows the organization to prove that the logs it presents (to auditor, regulators or courts) cannot be disputed. It’s basically “proof of integrity” in this context.
Many standards and regulations are leaning towards this property of logs although to make things simpler, many organizations and auditors alike, have accepted solutions that don’t have strong non-repudiation. This is quickly changing as organizations and auditors are starting to realize that the false sense of security of logs without proof of integrity is a significant security risk. If you can’t rely on the only thing that must give you traceability – your audit logs – you can’t rely on anything. But how to achieve non-repudiation and proof of integrity of logs? There are many approaches, including digital signatures, hashing, storing on write-only media.
However, all of these approaches have issues – signing a portion of the logs loses the chain of different portions, meaning a portion can easily disappear, or reappear with the same sequence number but different data. Hashing has the same issue if applied at file level, plus the risk of a malicious actor (internal or external) rehashing a particular file. And WORM can be expensive given the large volumes of log data – you don’t want to throw away hardware every week. Enter blockchain.
A technology that is actually a set of sophisticated components, aimed at solving the problems of trust and integrity. One of these components is the merkle tree – an efficient data structure that combines the hashes of multiple entries into a tree and provides standard and efficient ways to prove to 3rd parties that the data inside it is intact. No entry can be back-datated, no parts of the tree can be deleted without breaking the consistency guarantees.
The other component of blockchain, the distributed consensus, at first appears at odds with the needs of an organization trying to securely store logs. And that’s correct to an extent – you wouldn’t want to rely on anonymous parties to agree on all of your logs – it will be expensive and corporate secrets may leak into the wild. But a public blockchain can be an anchor of trust for merkle trees – regularly pushing data to blockchain structure backed by distributed consensus is sufficient to prove that your internal logs have not been tampered with, thus providing non-repudiation.
At LogSentinel we strongly focus on the proof of integrity of logs as it turns out to be crucial in precisely the moments when you need it most. Alternatively, if you don’t have proof of integrity for your logs, this can ruin a court case, an audit or government scrutiny as precisely the wrong moment. And the issue with logs is that you can’t retroactively make them non-repudiable. Once you hit the issue where you’d need to prove that your audit logs are intact, you can’t take emergency measures to make them so. Fortunately, our technology can be integrated pretty easily with practically any system to turn a bunch of text files and database rows into logs with strong non-repudiation, thus reducing risk of non-compliance and unpleasant auditing and court surprises.
If you’re curious to see how LogSentinel’s immutable audit logs will be visualised in one command center, check out our DEMO: