You could take a look at

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.

-----Original Message-----
From: [] On 
Behalf Of Carl Hill
Sent: Monday, February 09, 2009 9:33 PM
To: ''
Subject: [ossec-list] Re: log file integrity checking

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

-----Original Message-----
From: [] On 
Behalf Of Daniel Cid
Sent: Monday, February 09, 2009 5:37 PM
Subject: [ossec-list] Re: log file integrity checking

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'.


Daniel B. Cid
dcid ( at )

On Thu, Jan 29, 2009 at 1:12 PM, Alex Alexiou <> wrote:
> 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?

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 

Reply via email to