Log Integrity: How SIEMs Address the Issue and Is It Enough?

There are three approaches here – hashing of files (or blocks/chunks/buckets), signing of logs (or blocks), and relying on organizational/segregation approaches. Let’s discuss why those solve only part of the problem (and why there’s an asterisk after each “Yes” above):

• Hashing – hashing of files or chunks of files (depending on the internal representation of data) is the minimum that should be available. It is not turned on by default anywhere, probably because for many of the logs connected data integrity is not of paramount importance. But if you use the same tool to store audit logs, that’s a different story. Even when turned on, this does not make sure your data is not tampered with. It only ensures that the log data hash matches the stored hash. The hash is usually stored in either a separate file or in a database. Tampering with that separate file or database is still easy, and regenerating a new hash after the original data is tampered with is also easy (some of the solutions even provide tools for regenerating the hashes so an attacker/insider doesn’t even have to reverse engineer anything). And while modifying logs may require hash regeneration, deleting logs doesn’t even have to do that (with some exceptions, where multiple hashes are hashed together). If you delete a file/block/chunk and delete the corresponding hash, there’s no way to tell if there was something there. In some cases sequence numbers may be used to address that, but these sequence numbers can also be modified or fake files with the right sequence number can be generated and hashed. Furthermore, the hashes don’t give you any non-repudiation because you can’t prove to anyone that the logs have not been tampered with by providing a hash of the current logs.
• Signing – signing is slightly better, as it requires access to a private key, and that access can be further protected. Signing, however, suffers from similar issues as hashing – you can delete a signed chunk altogether, and then nobody will know there was something there in the first place. Sequence numbers can be spoofed – e.g. delete an old file/chunk, and create a fake one in its place with its sequence number. Re-signing is possible (although harder than rehashing). The signing also requires additional infrastructure (PKI), and ultimately hardware (HSM) to store the private keys. Managing the access to the connected HSM for the log signing process is also not trivial, and if signing is implemented by just throwing a key somewhere where the log collector has easy, unaudited access, then signing is no better than hashing. It does, however, give some non-repudiation – only one with access to the private key could have signed the logs.
• Organizational – some vendors rely on the fact that their solutions are “in the cloud” and therefore the organization staff does not have access to the underlying infrastructure that would give them access to modify logs. Other variations of that exist in the form of “chain of custody”, where multiple people have to approve or monitor access to the infrastructure where logs are stored. These organizational measures should exist, but they do not give non-repudiation (how do you prove that your procedures were followed) and do not protect from coordinated insider attacks. The “cloud” is certainly a strong argument, and many audits (e.g. PCI-DSS) have passed just on that ground, but the same issues above are faced by the cloud provider. And if you can prove somehow that your organization has followed the procedures that exist on paper, it’s harder to do that for a 3rd party.

Instead, we at LogSentinel employ what the scientific literature recommends: