[RFC] programmatic IDS routing

[Valdis.Kletnieks at vt.edu]

On Wed, 19 Mar 2008 13:40:21 EDT, Steve Grubb said:
> On Wednesday 19 March 2008 13:12:22 Linda Knippers wrote:
> > Rather than using the key for two purposes and introducing special key
> > words, couldn't an admin just tell the IDS which he's are of interest?
> > And what the priority of each one is?
> 
> The problem is that you can tell the IDS that you want any reads 
> of /opt/my-secrets, but unless you have a matching audit rule you will not 
> get any records. This allows you to make sure you have a watch paired with 
> its meaning.

You have this backwards.

If you have a "special" watch on /foo/bar, and you see an event arrive, the
IDS should already know that /foo/bar is special and handle it accordingly,
and it doesn't need to be told "this is special" in the audit record.  One
can make the case that it's *helpful* so that the IDS can note "Oh yes, this
is a special file, and the audit record says it's special, so it matches".

However, *no* amount of special tagging will allow the IDS to disambiguate
these two cases:

1) An audit rule was set, but no events generated because no activity matched.

2) An audit rule wasn't set at all.

"unless you have a matching audit rule you will not get any records" means
exactly that - so tagging the records you don't receive isn't useful.

There *is* the more general case of "I had a generic rule and a special watch
and *both* fired" - but that problem is in no way IDS specific, but applies
to *any* time that an event triggers more than one rule. We shouldn't be
coding IDS-specific solutions to the general problem.
-------------- 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/20080319/f35d7e3d/attachment.sig>