Dear Michael, our posts got mixed up in time. Regarding this particular feedback:
Thanks for your opinion on the interpretation which sounds reasonable enough. We were looking for actual tampering detection of log file entries- e.g. *log @ minute1 logfile size 1k: * Minute 1: User1 has authenticated *log @ minute2 logfile size 2k:* Minute 1: User1 has authenticated Minute 2: Some other logging *log @ minute4, tampering: User1 entry is deleted / modified, but size 3k due to growing logfile: * Minute 2: Some other logging Minute 3: Some other logging Minute 4: Some other logging* *Our opinion/interpretation of PCI 10.5.5. was that the HIDS should detect the tampering. But if detection of shrinking is the only possibility this needs be enough. We will try to test this scenario (we do have rotating logfiles of course) and will update this post if it was succesful. On Wednesday, September 19, 2012 4:42:09 PM UTC+2, Michael Starks wrote: > > On 19.09.2012 05:59, Andreas Lang wrote: > > Hello, > > Hi. > > > We have some questions regarding analysing log files with OSSEC > > referring to the log file requirements in PCI-DSS 10.5.5. > > > > PCI DSS 10.5.5.: > > _Use file-integrity monitoring or 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)._ > > I have experience in PCI, but I am not a QSA, nor do I play one on TV, > so take this for what it's worth. This is my take on the requirement and > I have never had it be a problem in audits: > > No current tool that I know of can be 100% sure that running logs have > not been modified. What OSSEC *can* do, however, is to alert you if the > running log file size has been reduced, which is an indication of > tampering. OSSEC can also check *rotated* logs in real time. There is no > good reason for a rotated log file to change. If you rotate logs once > per day, along with acting on the log size reduced alerts, *I* believe > that this reasonably meets the requirement. I think a QSA would have a > hard time arguing otherwise and demonstrating a better way. >
