From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: [RFC] programmatic IDS routing Date: Wed, 19 Mar 2008 13:55:38 -0400 Message-ID: <200803191355.38855.sgrubb@redhat.com> References: <200803191302.48434.sgrubb@redhat.com> <47E14976.9050308@hp.com> <200803191340.22092.sgrubb@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <200803191340.22092.sgrubb@redhat.com> Content-Disposition: inline List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: linux-audit@redhat.com List-Id: linux-audit@redhat.com On Wednesday 19 March 2008 13:40:21 Steve Grubb wrote: > 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. And I should add, the IDS could run on each remote system, or off an aggregator. This means expressing rules gets more complicated when you have to express rules as on this particular host, I am looking for files in this location. To me, its just simpler and hopefully less error prone to use the key field like this. -Steve