Thank you for the reply. I know all of this. This is not a PCI audit, but it could impact the business too much to fight. I used auditd to watch the folders. Excluding the OSSEC group and auid=-1. Also added a few more monitoring settings to auditd, like watching sudo and su usage. OSSEC looks at the auditd log as if it is a syslog. It reports each line (complete line in alert) as a separate event, but that is good enough. Thanks all for the help!
On Monday, January 12, 2015 at 6:24:54 PM UTC-6, David Lang wrote: > > On Mon, 12 Jan 2015, Christopher Dangerfield wrote: > > > After going through a security audit with my current employer something > > came up that I cannot figure out how to solve. No one online seems to > have > > ran into this. The auditor wants us to log and alert access to the > > /var/ossec/logs folder. I can do this, but every alert creates a log > change > > thus creates another alert and log change, etc, etc, etc. Has anyone > ever > > had to do this and cold help me? > > I've dealt with clueless auditors making requirements like this before > (what I > call checkbox secureity because they don't understand what's going on, > they are > just tryingto check off all the boxes in their checklist) > > What I've done is a combination of a few things. > > 1st, the logs in question are on a dedicated box that doesn't get accessed > much. > As such, the logs could only be tampered with during the time that someone > is > logged in to the box. > > 2nd, document the different risks from reading the logs vs changing them. > In the > vast majority of cases you don't care about reading the logs, only changes > to > them. > > 3rd, accept that you aren't going to be able to log every write to the > log, due > to the recursion that you are running into (yes, you could log elsewhere, > but > then how is that log protected?). Instead you accept that there is a small > window that the logs could be tampered with and have a periodic job > generate a > checksum of the log to that point (what you record needs to have both the > checksum and the number of lines that checksum covers). Then you need to > get > this checksum off the machine to somewhere more protected (a write-once > medium > like a printer with continuous feed paper that can print one line at a > time is > perfect for this) > > Other things you can do is to get the logs out of ossec to something like > rsyslog that includes a couple different mechanisms that you can use for a > critical log: > > a chain of hashes that tie all the lines of the logs together so that it's > not > possible to tamper with the log without re-writng the entire log file > > support for using a thrid party service to record and sign checksums that > prove > that the log wasn't tampered with > > If you do actually have to show that you have a log of any access to the > file, > then you have a couple choices > > 1. consider that anytime someone was logged into the box with the > appropriate > privileges to read the file that it was read at that time. > > 2. audit all reads of the file but not writes (so that writes don't > trigger > recursive writes. > > > And the most important thing to remember is that the Auditor is not able > to lay > down rules about what you must to on their own. They are supposed to be > working > to make sure that you are implementing the stated policy. The vast > majority of > the time, the policy they are checking that you are following is a policy > written by your organization, so make sure that your policies don't say > that you > do the impossible. > > Evn in cases like PCI audits this applies. PCI says that you must do some > things, but it doesn't say how in any technical details, instead they are > saying > what your company policies must cover. It's then up to your company > policies to > say how you are achieving the goal set by the PCI policies. The PCI > auditors > then do checks in two stages, they first check that your policies comply > with > the PCI policies, then they check that you are following your policies. > > A log of auditors like to forget this and think they know a lot more than > they > actually do, so when you run into an unreasonable auditor like you have > here > (and after you have made sure that your policies don't say that you do the > impossible), your management should go to the auditors company and say > that they > are being unreasonable. > > David Lang > -- --- You received this message because you are subscribed to the Google Groups "ossec-list" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
