On 12/14/2015 08:34 AM, Steve Grubb wrote:
That is not exactly what I proposed. What I was proposing was to record the translation of things that could change between systems and thus prevent correct interpretation later. Doing all translations is technically possible but would slow down auditd just a bit and increase the amount of data on disk. But doing this is not really necessary for the native audit tools.But I guess this gives me an opportunity to ask the community what tools they are using for audit log collection and viewing? Its been a couple years since e had this discussion on the mail list and I think some things have changed. Do people use ELK? Apache Flume? Something else? It might be possible to write a plugin to translate the audit logs into the native format of these tools.
Sorry for the late reply. Translating the salient details is for me important.
This is especially true on systems where:- aggregation is happening from one or more different machines (and cannot assume federated UIDs), and - where records are required to be kept over long periods of time (system updates happen, UIDs are changed, people leave, etc)
I realize it carries a processing burden somewhere; this is inevitable and I believe we'll need to design for this. We're auditing for a reason; we need proof of who did what and in varying degrees I believe this means persistence of accountability.
Because I'm almost a one-stop shop where I work, and the auditing requirements are specific and particular, I have a homegrown log collection and viewing solution for now but would prefer to incorporate a flexible, more useful user tool. So I'm in the "something else" category but somewhat open to change.
LCB -- LC (Lenny) Bruzenak [email protected]
smime.p7s
Description: S/MIME Cryptographic Signature
-- Linux-audit mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-audit
