Message Integrity

General discussions here

Moderator: rgerhards

Google Ads


Message Integrity

Postby cybersec » Thu Oct 12, 2017 11:32 pm

Hi,

What are the various approaches to message integrity when it comes to syslog messages?

I appreciate the use of transport level encryption gives a degree of assurance for integrity of messages whilst in transit from log source (i.e. device) and log collector. However, what I am looking to explore is that ways in which I can be confident the message that a log source/service generates is what i'm viewing in my log collector (i.e a commercial SIEM tool) -
untampered.

Does the rsyslogd have the ability (for my CentOS log sources) to ensure all messages process by rsyslogd are signed/hashed?

Thanks!
cybersec
New
 
Posts: 8
Joined: Thu Oct 12, 2017 11:01 pm

Urgent Question?

  • Pulling out your Hair?
  • Wasting Time and Money?
  • Deadline Approaching?

Re: Message Integrity

Postby dlang » Mon Oct 16, 2017 7:14 am

how could you trust the hash you receive? what would prevent a bad guy from creating a new log message and sending it with the appropriate hash?

Rsyslog does have various ways to add hashes.

We had (or have) a method to hash logs and have a third party on the Internet sign the hashes

We have a way to hash logs that depends on the prior logs (so you can't modify the file after the fact without re-creating the entire file), if you periodically send a copy of this to a tamper-resistant destination, you can check that the files haven't been tampered with.

I generally don't bother with either of these two. Instead I accept a small window of vulnerability by having my locked-down central servers hold the files for a short while, then compress them, encrypt/sign them, and ship them to offsite storage (cloud storage can be a good fit here) where there is a log from an uninterested third party showing when the file was uploaded. I keep a hash of the file that I sent offsite for quick validation, but the encryption can validate the file as well.
dlang
Frequent Poster
 
Posts: 1001
Joined: Mon Sep 15, 2008 7:44 am

Re: Message Integrity

Postby cybersec » Mon Oct 16, 2017 9:36 am

Thanks dlang.

I can accept the risk of not having assurance whether the log source did genuinely create and send a log message (non-repudiation) as TLS (mutual authentication) can provide little assurance around this.

In my scenario, I have CentOS servers reading the imjounral and sending these messages to a central rsyslogd (relay) server which forwards to a commercial SIEM solution. In the scenario, can the hashing capability you describe be used? Any pointers to documentation would be useful.

Thanks!
cybersec
New
 
Posts: 8
Joined: Thu Oct 12, 2017 11:01 pm

Re: Message Integrity

Postby dlang » Mon Oct 16, 2017 10:20 am

I expect that the SIEM would get confused by the hash.

it wouldn't have any way to validate the hash, and since it's unlikely to keep the log intact in the exact order received, I don't know that you could ever validate the hash after the SIEM got hold of the logs (trying to get logs our of a SIEM to do something with them is usually non-trival to say the least)

I would treat the SIEM as one of many recipients of the logs and have one of the other recipients deal with ensuring that you have a tamper resistant copy.

By the way, I very carefully say "tamper resistant" not "tamper proof" unless you have a third party system that has no admin overlap with your main systems, nothing you can do will stop a bad insider from recreating an entire new log file that has consistent hashes and signatures and replace your logstore in it's entirety.

Also, log volumes are high enough that you cannot implement full protection after receiving each log message, there is always going to be a window where you have received the log messages but not yet taken the action to make them tamper resistant.

The days of tamper proofing logs by writing them to write-only media are long gone, anything you have nowdays will buffer writes for some amount of time.
dlang
Frequent Poster
 
Posts: 1001
Joined: Mon Sep 15, 2008 7:44 am

Re: Message Integrity

Postby cybersec » Mon Oct 16, 2017 10:57 am

Thanks dlang. Good points raised. The integrity of a log message seems to be a very 'nice to have requirement' but a very 'difficult to implement' requirement especially with COTS log sources. I will focus on the assurance gained from TLS encryption and lockdown of log source to answer the integrity question.

Thanks once again.
cybersec
New
 
Posts: 8
Joined: Thu Oct 12, 2017 11:01 pm

Re: Message Integrity

Postby dlang » Mon Oct 16, 2017 11:07 am

remember, the primary reason you are trying to guarantee message integrity is to prevent a bad guy who gets on a box from covering their tracks by tampering with the logs.

The best protection against this is to just get the logs off the system in as near to real time as possible, that by itself will get you > 90% of the protection of all the other, more complicated methods

The secondary reason is to protect against insiders. This is much harder as your insiders probably have the ability to re-write the logs and re-do the log hashing/signatures
dlang
Frequent Poster
 
Posts: 1001
Joined: Mon Sep 15, 2008 7:44 am

Google Ads



Return to General

Who is online

Users browsing this forum: No registered users and 1 guest

cron