log file integrity checking

[Alex Alexiou]

Hi,

 

I have been exploring ossec for use in a PCI environment. One of the requirements that we’ve been given is file-integrity checking for log files, which I’m not sure ossec can do; I’m assuming it does not put log files into the default integrity-checking options because they change size by definition. I did read about log file signing, but it appears that this would only work with old logs. I tested this by altering the current /var/log/secure log of a machine with the ossec agent, and it didn’t seem to notice anything in particular amiss. Anyone know if there’s any way to do this in ossec, or do I need to use a separate tool such as syslog-ng for this?

[Daniel Cid]

Hi Alex,

I don't think PCI requires that. Can you point where it says that? In addition
to that, I don't think there is any tool that can guarantee the integrity of a
log file (specially via syslog)...

However, as soon as the log is written, ossec reads them and forwards
to a remote
system (the ossec server), where the event is stored/analyzed in a (hopefully)
safer place. So, even if one system is hacked, the logs are still safe in the
ossec server.

In addition to that, as an extra precaution, the agent will alert if
the size of a log
file is reduced or the file is rotated during monitoring... An alert
will look like:

2009 Feb 08 18:31:15 brrkey->ossec-logcollector
Rule: 591 (level 3) -> 'Log file rotated.'
ossec: File rotated (inode changed): '/var/log/messages'.

Thanks,

--
Daniel B. Cid
dcid ( at ) ossec.net

[Carl Hill]

It is part of PCI-DSS:
10.5.5 Use file integrity monitoring and change detection software on logs to ensure that existing log data cannot be changed without generating alerts (although new data being added should not cause an alert).

Also worth noting is a separate point:
10.5.3 Promptly back-up audit trail files to a centralized log server or media that is difficult to alter.

Now the fun begins. I am going to lead into this with the standard I am not a QSA and you shouldn't depend on this email for your compliance decisions.

First of all, you may not use one part of the standard (10.5.3) to address another requirement. They *all* must be met. 10.5.3 is probably your best security when it comes to protecting log integrity, but the act of meeting 10.5.3 dopes not get you off the hook for 10.5.5.

Second, there is a lot of confusion out there around 10.5.5. Does it mean that logs must be signed the second they are created? And, does it mean that every instance of every log must be signed. Once again, do not base your compliance or decisions on this email. I have asked a number of qualified people these questions. The consensus was:

No, a log needn't be signed/re-signed every time a new entry is written. It doesn't make sense and truthfully, it is likely nearly impossible -- at the least it could cripple the resources. The consensus was that it is reasonable to calculate your checksums at regular intervals. i.e. when rotating the files. How often you rotate those files is a case by case decision. You'll need to do your own risk analysis and determine what you can live with. For some, a 24 hour rotation may well be good enough, for others you may need shorter periods. Then, when the log is rotated, calculate your checksum.

This is also where a central log server is going to be a further advantage for you. If the server is collecting all of the pertinent logs from agents (i.e. your ossec server), then you can probably be okay with performing the previous checksum calculations on the centrally stored files -- not on every instance of every log (which is probably impossible anyway).

I'm sure there will be varying and differing opinions on the list about these. The only thing that I will say with absolute certainty is that you cannot use the act of meeting one requirement (i.e. 10.5.3) as compensating control for another requirement (i.e. 10.5.5). After that, talk to your QSA to get approval for your decision.

Carl Hill

Hi Alex,

Thanks,

This message is intended only for the use of the individual or entity to which it is addressed and may contain information which is privileged, confidential or proprietary. If the reader of this e-mail is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, any dissemination, publication or copying of this e-mail is strictly prohibited. If you have received this message in error, please notify us immediately by return e-mail and destroy and delete all copies of the message.
Internet communications cannot be guaranteed to be secure or error-free as information can be intercepted, corrupted, lost, arrive late or contain viruses. The sender does not accept any responsibility for any loss, disruption or damage to your data or computer system that may occur while using data contained in, or transmitted with, this e-mail.
--------------
Ce courrier ?lectronique peut renfermer des renseignements privil?gi?s et confidentiels ? l'intention exclusive du destinataire. Si vous n'?tes pas le destinataire, ni la personne charg?e de lui transmettre ce message, vous n'avez aucun droit d'utiliser cette information, de la copier, de la distribuer ou de la diffuser. Si vous avez re?u ce courrier ?lectronique par erreur, veuillez en aviser l'exp?diteur imm?diatement par courriel et d?truire ce message ainsi que les fichiers en annexe.
Il est impossible de garantir que les donn?es transmises sur Internet sont s?curitaires et exemptes d'erreurs puisqu'elles ne sont pas enti?rement prot?g?es contre l'interception, la modification, la perte, les retards ou les virus. L'exp?diteur n'assume aucune responsabilit? quant ? la perte, ? l'interception ou ? la modification de vos renseignements, ainsi qu'? tout dommage caus? ? votre ordinateur, pouvant r?sulter de la transmission de ce courriel.

[cryogen]

Hmmm.... Reading this reminded me of something I saw a few years
back. After a couple applications of google I found this:

Logcrypt: Forward Security and Public Verification for Secure Audit Logs
http://eprint.iacr.org/2005/002.pdf

And I think the code lives here:
http://isrl.cs.byu.edu/logcrypt/index.html

FYI

[Bruce Martins]

You could take a look at http://la-samhna.de/samhain/s_faq.html

Although I don't want to promote a competing product, and I have not personally tested this as of yet, you may want to look at the above as an alternative if this is for PCI as they specifically call this item out.

[Anton Chuvakin]

Just FYI, most people interpret "Use file integrity monitoring and

change detection software on logs to ensure that existing log data

cannot be changed without generating alerts" as:

- collect logs
- hash them (SHA or - god forbid! - MD5)
- store logs and hashes separately (hopefully)

(and that is what most vendors do)

Live per record hashing is way ahead of the curve... even though it is
kinda nice, technically.