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 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: ossec-list@googlegroups.com [mailto:ossec- > l...@googlegroups.com] On Behalf Of Daniel Cid > Sent: Monday, February 09, 2009 5:37 PM > To: ossec-list@googlegroups.com > 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 ) ossec.net > > > On Thu, Jan 29, 2009 at 1:12 PM, Alex Alexiou > <aalex...@targetsite.com> 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.
