Auditing File Changes

[Valdis.Kletnieks at vt.edu]

On Mon, 10 Jul 2006 14:56:47 CDT, LC Bruzenak said:

(Addressing the actual design seperately)

> As Steve Grubb said, instrument the processes with trusted access.
> Have file watches which note when certain "critical" files are opened
> for write/append.
> Have an audit analysis program which compares the trusted accesses to
> the total accesses; the delta shows potentially interesting mods.

Ahh... but to find that delta, you don't really need to record the actual
changes, do you?  You can (hopefully/presumably) then recover the old version
of the modified file and diff it.

And "comparing trusted accesses to total accesses" is quite possibly flawed as
well - I've lost count of times that the audit trail has clearly said that a
"trusted program" did something, and the *actual* security issue was the user
went to the bathroom and a locking screensaver wasn't engaged, allowing
somebody else to run the program surreptitiously....

Yes, a proper and correct audit trail is required - but on *any* realistic
system, the result is a fire hose of data, and no amount of data mining will
produce anything but wrong answers if you ask it the wrong questions....

(Sorry for those on the list who have a grasp on that - I find an incredible
number of people in the security industry need reminding on a regular basis..)


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 226 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/linux-audit/attachments/20060710/e8abc2c1/attachment.sig>