[ossec-list] Re: log file integrity checking
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
[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: 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
[ossec-list] Re: log file integrity checking
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
[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?
