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

And I think the code lives here:


On Feb 9, 2009, at 6:33 PM, Carl Hill wrote:

> 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: [mailto:ossec- 
>] On Behalf Of Daniel Cid
> Sent: Monday, February 09, 2009 5:37 PM
> To:
> 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'.
> Thanks,
> --
> 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  
> courriel.

Reply via email to