Re: [[email protected]: New Version Notification - draft-ietf-idwg-idmef-xml-16.txt] - Analyzer path tracking

Hi,

I'm writing you because i'm not sure to understand very well a part of
the new draft (analyzer path tracking). I have been looking the draft 12
and i found out that path tracking was available using multiple Analyzer
attribute in the Analyzer class (as shown below), even if the the
section 4.2.4.1 was saying:
"The Analyzer class identifies the analyzer from which the alert or
heartbeat message originates.  Only one analyzer may be encoded for each
alert or heartbeat, and that MUST be the analyzer at which the alert or
heartbeat originated.  Although the IDMEF data model does not prevent
the use of hierarchical intrusion detection systems (where alerts get
relayed up the tree), it does not provide any way to record the identity
of the "relay" analyzers along the path from the originating analyzer to
the manager that ultimately receives the alert".


<Analyzer analyzerid=3D"abc123" name=3D"transporter" class=3D"relay"
ostype=3D"Linux" osversion=3D"Debian">
         <Process>
           <name>relay</name>
           <pid>10818</pid>
           <path>/usr/bin/relay</path>
         </Process>
         <Analyzer name=3D"DMZdetector" class=3D"NIDS">
           <Node category=3D"unknown">
             <name>localhost</name>
             <Address category=3D"ipv4-addr">
               <address>127.0.0.1</address>
             </Address>
           </Node>
           <Process>
             <name>snort</name>
             <pid>13386</pid>
             <path>/usr/bin/snort</path>
           </Process>
         </Analyzer>
</Analyzer>

The draft 12 was saying:
Analyzer
      Zero or one.  Information about the analyzer from which the
      message may have gone through.  The idea behind this mechanism is
      that when a manager receives an alert and want to forward it to
      another manalyzer, it needs to substitute the original analyzer
      information with its own.  To preserve the original analyzer
      information, it may be included in the new analyzer definition.
      This will allow analyzer path tracking.

The 2 last sentences seems to be very important because they really
explain how/where will be stored the original analyzer description (the
new Analyzer include the other one and not the opposit).=20

In the new draft (16), i don't really understand the same thing... It's
possible that is coming from my bad english understanding :-( so sorry
if it's the case...

 Analyzer

      Zero or one.  Information about the analyzer from which the
      message may have gone through.  The idea behind this mechanism is
      that when a manager receives an alert and want to forward it to
      another manalyzer, it needs to substitute the original analyzer.


Does the forwarding analyzer really substitue its information in the
Analyzer attribute of the Analyzer class ? it shouldn't be the Analyzer
class itself ?

Hope my question is understandable ...

Regards and thanks for your help,


Jo=EBl.W





Le mercredi 22 mars 2006 =E0 18:10 -0800, Mike Erlinger a =E9crit :
> fyi
>=20
> mike
>=20
> pi=E8ce jointe message de courriel
> > -------- Message transf=E9r=E9 --------
> > Sujet: No Subject
> > Date: Thu, 23 Mar 2006 08:23:53 +0100
> >=20
> > >From mike  Wed Mar 22 15:50:13 2006
> > Return-Path: <[email protected]>
> > X-Original-To: [email protected]
> > Delivered-To: [email protected]
> > Received: from mail2.ac.hmc.edu (Mail.AC.HMC.Edu [134.173.32.22])
> > 	by turing.cs.hmc.edu (Postfix) with ESMTP id 4217253201
> > 	for <[email protected]>; Wed, 22 Mar 2006 15:50:08 -0800 (PST)
> > Received: from psmtp.com (exprod7mx69.postini.com [64.18.2.71])
> > 	by mail2.ac.hmc.edu (8.12.10/8.12.10) with SMTP id k2MNo7VJ000518
> > 	for <[email protected]>; Wed, 22 Mar 2006 15:50:07 -0800
> > Received: from source ([209.173.53.84]) (using TLSv1) by exprod7mx69.=
postini.com ([64.18.6.10]) with SMTP;
> > 	Wed, 22 Mar 2006 15:50:07 PST
> > Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [=
10.31.47.10])
> > 	by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k2MNo29W024929
> > 	(version=3DTLSv1/SSLv3 cipher=3DDHE-RSA-AES256-SHA bits=3D256 verify=
=3DNO);
> > 	Wed, 22 Mar 2006 23:50:02 GMT
> > Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
> > 	id 1FMD5W-0002F8-81; Wed, 22 Mar 2006 18:50:02 -0500
> > Content-Type: text/plain; charset=3D"utf-8"
> > Mime-Version: 1.0
> > To: <[email protected]>, <[email protected]>,
> > 	[email protected], [email protected]
> > Cc:=20
> > From: ID Tracker <[email protected]>
> > Subject: New Version Notification - draft-ietf-idwg-idmef-xml-16.txt=20
> > Message-Id: <[email protected]>
> > Date: Wed, 22 Mar 2006 18:50:02 -0500
> > X-pstn-levels:     (S:20.84439/99.90000 R:95.9108 P:95.9108 M:97.0232=
 C:98.7678 )
> > X-pstn-settings: 3 (1.0000:1.0000) s gt3 gt2 gt1 r p m c=20
> > X-pstn-addresses: from <[email protected]> [db-null]=20
> > X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on turing
> > X-Spam-Status: No, score=3D0.1 required=3D7.5 tests=3DFORGED_RCVD_HEL=
O=20
> > 	autolearn=3Ddisabled version=3D3.0.1
> > X-Spam-Level:=20
> >=20
> > New version (-16) has been submitted for draft-ietf-idwg-idmef-xml-16=
.txt.
> > http://www.ietf.org/internet-drafts/draft-ietf-idwg-idmef-xml-16.txt
> >=20
> >=20
> >=20
> > IETF Secretariat.
--=20
________________________________________________________________________

Jo=EBl Winteregg, Ing=E9nieur HES en t=E9l=E9communication
Phone: +41 24 557 64 73

      =3D> http://www.fullsecurity.ch <=3D

Swiss University of Applied Sciences, Institute for ICT
=C9cole d'Ing=E9nieurs du Canton de Vaud (EIVD)
Route de Cheseaux 1
1401 Yverdon-les-Bains
Switzerland