Does Your SIEM Guarantee Log Integrity? And Does It Make You Compliant?

It is for a good reason that “integrity” is one of the three main aspects of information security. Lack of data integrity can be a serious issue in many cases, as we have already discussed in our post “3 Reasons Not to Ignore Data Integrity”.

But many times integrity is an abstract concept that one assumes is handle at lower level technical protocols and is not a business requirement. That’s a wrong assumption, but in many cases infosec teams that barely have time and resources, just get a SIEM to tick some compliance and security boxes and life goes on.

SIEMs are there to collect logs from various sources. These logs, allegedly, can be used later as an audit trail to help figure out what happened. Unfortunately, if you can’t trust the audit logs, you can’t be sure what happened. Not only that – you can’t convince anyone else.

How to Guarantee Log Integrity Using SIEM?

Unfortunately, SIEMs don’t have good integrity guarantees. Some attempts exist, but they are so rudimentary that any half-knowledgeable admin can get around them. Practically, a privileged user with some knowledge on the internal structure of the SIEM data can easily delete logs, backdate logs, or modify existing logs. Here are three techniques usually in use by SIEMs and how they can be circumvented:

  • Hashing – hashing log files or bulks of log entries and storing the hash on disk for future verification. This can be easily circumvented by simply modifying the file and recalculating the hash.
  • Signing / Timestamping – for signing and timestamping you need a well-managed PKI with secure hardware storage for keys. Even then, a privileged user typically has access and can use the same facilities to re-sign the modified logs. Whole log files can be deleted, together with their signature and secure timestamp. Backdating a timestamp is slightly harder, but entirely feasible.
  • Chain of custody – some vendors rely on rules and procedures to ensure that no tampering occurred – e.g. if every time you log in to a SIEM machine, you need to have the approval and oversight of a supervisor, then even though you technically can tamper with the logs, you wouldn’t. This, of course, assumes non-conspiring employees, strict rule-following and the likes, and so is certainly not the solution in the edge cases that matter.

In all of the above cases, the integrity of the logs is de-facto not guaranteed. Not only that, but you don’t have decent non-repudiation of logs. And that’s a key issue with integrity. If you can’t prove you have integrity, do you really have it? Especially for compliance and regulatory purposes. And, of course, legal disputes and court cases.

How to Turn Logs Into a Proper Audit Trail?

Fortunately, you can turn your collected logs into a proper audit trail with all the necessary features without dropping your SIEM. At LogSentinel, we have taken state-of-the-art research and applied it to this compliance issue by letting you forward any subset of your SIEM logs to our dedicated secure audit trail solution which employs hash chainingtimestamping and Merkle trees (all of which are components of blockchain) to really guarantee log integrity.

You can have that both as an add-on to your SIEM, or use our full-featured next-gen LogSentinel SIEM.

Because “compliance” is not just a boring checklist – in order to really reap the benefits of compliance, one has to do things right, and doing them right without the proper tools is a steep mountain to climb.

Like this article? Share it with your network!