I've worked with Leigh before, he's a great guy. He implemented some
fixes for me with the Irix versions of Snare and posted my sat2text
script on sourceforge
(
http://www.intersectalliance.com/projects/SnareIrix/Download/sat2text-1
.1-beta.pl).
I haven't looked at the Snare Micro Server in a while. The last time I
looked at some snapshots of its output, it was collecting logs from
multiple UNIX platforms, but the messages themselves still had pieces
(strings) in the more native/difficult to read format, so I never really
pursued demoing the package. Lots may have changed in recent revisions,
and it might be worth another look.
Of the GUIs I've seen, many have similar problems, but most of the
issues I have are not in the GUI developer's handling of the audit data,
but in the audit data itself: the number and type of fields in each
record varies greatly depending on the type of record, and this makes it
very difficult to process the data in a human-understandable way.
Some of the problems I've seen with older GUIs are illustrated by
looking at the old snare GUI from Red Hat 9:
1. The snare guys handled the varying record field problem by showing
the common fields in the top level of the GUI. If you wanted to get the
event-specific details from the record though, you had to open every
single one individually which is time consuming. I don't think there
were any high level AI interfaces for determining if joe-user tried to
break into the machine or was messing around with system confif files, I
think you had to open each record and look at its specific data fields
to determine that type of thing, and isn't very practical if you have a
lot of audit data or a lot of systems to review. (Again, the snare
microserver may have more analysis capabilities now)
2. You could only look at data from one system at a time (I know that
the Snare microserver can help with this issue).
3. The old SNARE Gui would also only show you the audit file that was
currently being written. If you wanted to go back and look at old audit
data that you had archived, you couldn't open it with the GUI, you had
to look at the audit data in its native format which is very difficult
to interpret. (Leigh told me a while back that he would take a look at
writing something for the next release that would allow you to open
older audit files with the GUI, but I haven't checked in a while to see
if that's available).
I should really take a look at the Snare micro server and see what
current versions can do for me. I imagine lots of cool features have
been added since my last look.
So, what would I want in a tool or GUI?
--------------------------------------
I'm not sure I could come up with a great way to display/analyze this
data, but as a user and as someone who is required to determine if
someone is doing something nasty on my systems, I do know that the tools
need to be easy to use. Sometimes we configure machines for a facility,
but then a not-necessarily savvy facility administrator may be the one
doing the weekly audit log reviews. Most wouldn't take the time to
learn how to manipulate the data with aureport (or comparable tools) to
really understand what's happening on their machines, so the more
user-friendly the tool, the better.
It's also a big help to review data from multiple systems at a time (and
there don't necessarily need to be agents out there doing a central
collection, I may simply have set up the log rotation to stash the
rotated logs in a central place with names like audit.daterange.system1,
audit.daterange.system2, etc.).
The Bottom line? The basic minimum is that I'd to be able to display
audit records in some sort of language-like format. It might be nice to
sort/group data so we can look at big chunks of similar events at a
time (makes the review process go faster). Another nice to have would be
the ability to do this for multiple systems at once, and even better
would be to have some analysis/filtering capability to reduce some of
the noise on harmless audit records, allow us to take a closer look at
the more interesting stuff, and to ultimately help determine whether
someone is doing something bad on the machine.
Thanks a million for listening, you have been very patient and helpful.
I greatly appreciate it.
Karen Wieprecht