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. On Feb 9, 6:33 pm, Carl Hill <ch...@mec.ca> 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.
