Re: Cooked audit log format

[Matthew Booth <mbooth@redhat.com>]

[-- Attachment #1.1: Type: text/plain, Size: 3341 bytes --]

Steve Grubb wrote:
>> Simple starters would include:
>> * Translating the architecture and syscall names into human.
> 
> libauparse, ausearch, & ausyscall can do this.
> 
>> * Jumping one way or the other with the hex strings business
> 
> not sure what you mean by this. ausearch, aureport, & libauparse can handle 
> them.

Strings should be either always hex encoded, or always escaped 
(preferably the latter).

>> * Translating socket addresses into human.
> 
> libauparse, ausearch, and aureport all do this.
> 
>> * Translating timestamps into human.
> 
> libauparse, ausearch, and aureport all do this.

No doubt, but I'm interested in a general agreement around the output, 
not which tools can generate it. My customer is using a third party 
audit tool to collate logs from a large number of sources including 
Linux accounting logs, but also including HP-UX, Solaris, Windows, AIX, 
door sensors, etc... There is currently no good steer for third party 
tool vendors about what log format they should support, hence I have 
recommended uncooked. However, the problem with uncooked logs is that 
they are offensive to the human eye ;) This makes life difficult for an 
operator presented with a bunch of logs to look at, which together form 
some interesting event.

>> * Ditching uninteresting records, such as PATH with no name for the
>> dynamic linker, and 2 PATH records when execing a script.

Oh, also:

* Ditching CWD and making all PATH records absolute.

>> with an ultimate goal of:
>> * Defining an expected set of data for every system call and putting
>> them all on a single line in a well defined format.
> 
> I have a feeling that too will become an abomination. aureport tries to get 
> the audit events down to the bare essentials. But what you wind up with is 
> something that makes you want more details. When you add more details you 
> feel like you want less.

The goal is semi human-readability in a standard, machine-readable 
format. So include all the abominable details, but at the end of the 
line ;) And put everything on 1 line. And define exactly what will be on 
that line, every time.

>> Is anybody doing any work in this direction?
> 
> Not really. Part of the problem is that I occasionally hear complaints about 
> the audit format, but then no one that is actually /using/ the audit output 
> is willing to help define what an auditor needs. I'd really like this to come 
> from people who do this as their job. 
> 
> I can take a guess at what's needed. But I really want to hear it from the 
> Security Officer's perspective.
> 
> One thing that is on the TODO list is to make a output format that is like 
> strace for syscall records. At least people have experience reading strace 
> output and it might help make one class of record easier to understand. Doing 
> this will be a big job, so I want to get some important things like remote 
> logging finished before jumping into it.
> 

I don't underestimate the size of the task: it's a huge mountain of 
donkey work, but it really has to be done. And maintained...

Matt
-- 
Matthew Booth, RHCA, RHCSS
Red Hat, Global Professional Services

M:       +44 (0)7977 267231
GPG ID:  D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]