Subject: [Fwd: Re: [prelude-devel] [IDMEF][Issue 9] Alert routing (fwd)]

From: Yoann Vandoorselaere <[email-masked]>
Date: Sat, 17 Jan 2004 00:56:59 +0000

didn't made it... re-sending...

-- 
Yoann Vandoorselaere, http://www.prelude-ids.org

"Programming is a race between programmers, who try and make more and 
 more idiot-proof software, and universe, which produces more and more 
 remarkable idiots. Until now, universe leads the race"  -- R. Cook

Subject: Re: [prelude-devel] [IDMEF][Issue 9] Alert routing (fwd)
From: Yoann Vandoorselaere <[email-masked]>
To: Krzysztof Zaraska <[email-masked]>
Cc: [email-masked], Herve Debar <[email-masked]>, intrusion detection wg <[email-masked]>
Date: Thu, 08 Jan 2004 23:18:46 +0000

On Thu, 2004-01-08 at 13:34, Krzysztof Zaraska wrote:
> Now, what about that one? 

[...]
Note: please CC me as I'm not on the idwd list.

> Subject: [IDMEF][Issue 9] Alert routing
> 
> Tthe draft should be more explicit on hte hierarchy between manager 
> and analyzer
> 
> Situation 1 (serial/transfer)
> -----------
> Imagine 3 boxes, A=analyzer, B=manager/analyzer, C=manager, connected
> thus:
> 
> Analyzer-A -> (Manager-B / Analyzer-B) -> Manager-C
> 
> You should ([even must ?] not have alerts on C whose analyzerid is
> Analyzer-A.

Herve, if I recall well about our old discussion, analyzerID can be
anything as long as it is unique across the whole IDS environment. 

I previously tried to express the need to be able to give a "name" to an
analyzer, and that the analyzerID field might not be the best place for
doing so as there might be real concern on checking whether a name is
unique to the whole IDS environment, and that practicaly combining
"analyzerID" + "manager analizerID", for uniqueness might not be doable
in a given implementation.

So, following your schema here, analyzerID will be lost once the
analyzer A alert come through the Manager B to Manager C. So how does an
user looking at an alert coming from analyzer A on Manager C refer to
the analyzer ?

> Situation 2 (parallelism/duplication)
> -----------
> 
> Imagine 3 boxes, A=analyzer, B=manager, C=manager, connected thus:
> 
>               /---> Manager-B
> Analyzer-A -<
>               \---> Manager-C
> 
> The same alert on Manager-B and Manager C should [must ?] have the 
> same analyzerid+alertid.
> 
> I believe that with these two constructs we cover any arrangement that 
> anybody may want to make.
> 
> I'm not sure this has to go in the document, but it would probably 
> clear some misunderstanding.
> 
> 
>  From Krzysztof Zaraska on Situation 1:
> I'd like to know a rationale for this. In Prelude it's a typical 
> situation that C sees alerts generated by A. And it's therefore very 
> useful to know where the alert actually originated. We were also 
> proposing is a "path record" inside the alert, specifying the managers 
> the alert has travelled through.

Recording the path of an alert is something I started implementing
sometime ago in Prelude... My intent is simply to insert the interface
the alert was received on, and the interface the alert is going to be
sent to if any. I used additional data for doing this, but having
defined field withing IDMEF for that might be a better idea.

-- 
Yoann Vandoorselaere <[email-masked]>