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

From: Herve Debar <[email-masked]>
Date: Fri, 09 Jan 2004 08:27:19 +0100

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=...
		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.

> 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 ?

Hervé
-- 
Hervé Debar             <mailto:[email-masked]>
Tel: +33 (0)2 31 75 92 61            GSM: +33 (0)6 74 09 09 66
France Télécom R&D                   Fax: +33 (0)2 31 75 93 13
42 rue des Coutures  (--)  BP 6243  (--)  F-14066 Caen Cedex 4

---

From: "David A. Curry" <[email-masked]>
Date: Sun, 11 Jan 2004 21:01:17 -0500

>>>>> On Fri, 9 Jan 2004, Herve Debar, identified as "Herve" below, wrote:

  Herve> Yoann Vandoorselaere wrote:

  +> 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.

  Herve> I will create an issue for adding a textual name to an analyzer
  Herve> representation.

An analyzer can have a hostname (foo.bar.com), as the name is part of Node,
which is in turn part of Analyzer.  But I assume you're wanting something
like "Outside IDS 1" or something descriptive like that.

If we want to do this, I would suggest adding a "description" (or something)
field to Node.  That way you could have such descriptions on anything that
can be a Node (it would be left as an exercise for the analyzer or manager
to assign data to that field).

--Dave