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
