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

From: Yoann Vandoorselaere <[email-masked]>
Date: Sat, 17 Jan 2004 00:57:41 +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: [email-masked]
Cc: Krzysztof Zaraska <[email-masked]>, [email-masked], intrusion detection wg <[email-masked]>
Date: Fri, 09 Jan 2004 09:42:19 +0000

On Fri, 2004-01-09 at 07:27, Herve Debar wrote:
> Yoann Vandoorselaere wrote:
> > On Thu, 2004-01-08 at 13:34, Krzysztof Zaraska wrote:
> >>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. 
> 
> Right.
> 
> > 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.
> 
> I will create an issue for adding a textual name to an analyzer 
> representation.
> 
> > 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 ?
> 
> I have been looking at this for a long time. I have the same 
> operational problem because people have the same alert in multiple 
> databases, and I have come to the conclusion that:
> 
> 1) either B adds value to the alert (correlation, ...) and then it's a 
> new alert with analyzerid=B and alertid=...

This sound ok to me, as long as the name field, discussed above, is not
modified.

> 		OR
> 2) B doesn't add value to the alert, and then the situation is 
> equivalent to having A send the alert to B and C. As such, B is some 
> sort of network router pushing alerts instead of packets, but it does 
> not modify them.

sound ok also.

> > 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.
> 
> Could you please phrase a proposal for altering the draft ?

Roughly : 
- add a list of the following AlertPath object within the Message class.

+---------------------+
|      AlertPath      |
+---------------------+
| STRING name         |       0..1 +----------+
| STRING hop          |<>----------|InAddress |
|                     |            +----------+
|                     |       0..1 +----------+
|                     |<>----------|OutAddress|
|                     |            +----------+
+---------------------+

Or something like it.

- name could contain the name of the Analyzer/Manager this alert passed
through.

- hop is the hop number for this path element...

- InAddress, of the Addresss class is address where the alert was
received, if any.

- OutAddress, of the Addresss class is address where the alert is sent
to, if any.

BTW, it might be better to change InAddress, and OutAddress to Node...

-- 
Yoann Vandoorselaere <[email-masked]>