Auditd versus other FIM for purely maintaining audit of file access

Latest response

Hello

When looking through the topic of File Integrety Monitoring for Linux, one will stumple upon several products that will handle this issue.
My question goes along the lines of:

Why introduce a third party product that can risk not being compatible with current kernel modules when the kernel itself ships with a rather powerful audit method whom are able to be quite customized towards the need?

If the sole goal is to ensure a full audit trail of file changes or file access, why introduce products like Tripwire or McAfee when the Kernel can handle this just fine by auditd?

My general assumption would be to go with the standard Kernel modules, rather than relying on 3rd party vendors, yet when browsing through the net, I don't really see auditd being mentioned (might be my search skills..) in comparison to products like Tripwire or McAfee.

Why is that?

Is there a universal belief that the products yield more than auditd does?

Responses

The issue here is a few layers deep.

The first layer is that Red Hat does not sell auditd as a product, therefore they don't directly spend advertising dollars marketing it to customers. A good example of this is Red Hat Identity Management, its an excellent component of RHEL that gets no attention from the industry (Gartner etc).

The second layer is that auditd is platform specific to RHEL (and other linux with auditd) and not Windows (largest factor), AIX, whatever remains of Solaris. Things like Tripwire provide FIM for an organization as a whole, and generally managers don't like having to run two products so they would rather spend money on one that does everything.

The final layer is that running auditd with any real kind of FIM ruleset and/or selinux correlation requires something like Splunk (or ELK) to make heads and tails out of it since data spit out by auditd becomes non trivial to manage at any kind of scale. (Also Splunk can provide dashboards which things like Tripwire etc pride themselves on)

Hi Greg

Thanks for your reply.

I get that most organisations require full scale solutions, however as you also describe, the loginfo needs to be correlated at some point and given that SIEM solutions is (if not then should be) common for most organisations, I do not really see the issue in the FIM module being auditd for Linux machines. That would probably also save time and money on propriatary solutions like McAfee CC or the likes. Auditd resides naturally in the Kernel whereas some of the others have been known to cause trouble (just a quick look through the problems or bugreports show this).

I am somehow entrieged by your reply as well, as I do not read any actual claims towards auditd not being fit, merely the fact that it is not a standalone product and hence not advertised for its versatile features. I think I'll try to dig deeper into this.

Thanks!

Best regards Casper

Close

Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.