Re: [RFC] programmatic IDS routing
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.
Attachments:
- attachment.sig (application/pgp-signature — 226 bytes)