Re: [[email protected]: New Version Notification - draft-ietf-idwg-idmef-xml-16.txt] - Analyzer path tracking
joël Winteregg <[email protected]> Tue, 28 Mar 2006 15:13:58 +0200
| Newsgroups | gmane.ietf.idwg |
|---|---|
| Message-ID | <[email protected]> |
Hi, it's me again...
Sorry to spam a bit ;-)
I just did a Huge mistake in my last mail. I didn't read the end of the
Analyzer attribute defintion of the new draft (soooory), which say:
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.
Now everything is clear cause the Analyzer class as said by the draft:
"[..] identifies the analyzer from which the alert or heartbeat message
originates[..]"
So the Analyzer attribute of the Analyzer class will save the path... I
get it :-)
As an excuse, i can just mention that there is a little mistake in how
you wrote "analyzer" in the Analyzer description section ;-). It's
written "manalyzer".
I still don't really understand why the draft say that path tracking
isn't available in the Analyzer class description ? Even so the fact
that analyzer attribute allow it...:
"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."
Sorry for my mistake and thanks for your help,
Jo=EBl.W
Le mardi 28 mars 2006 =E0 14:47 +0200, jo=EBl Winteregg a =E9crit :
> Hi,
>=20
> 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 1=
2
> and i found out that path tracking was available using multiple Analyze=
r
> 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 eac=
h
> 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 identit=
y
> of the "relay" analyzers along the path from the originating analyzer t=
o
> the manager that ultimately receives the alert".
>=20
>=20
> <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>
>=20
> 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.
>=20
> 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
>=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...
>=20
> Analyzer
>=20
> 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.
>=20
>=20
> Does the forwarding analyzer really substitue its information in the
> Analyzer attribute of the Analyzer class ? it shouldn't be the Analyzer
> class itself ?
>=20
> Hope my question is understandable ...
>=20
> Regards and thanks for your help,
>=20
>=20
> Jo=EBl.W
>=20
>=20
>=20
>=20
>=20
> 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 exprod7mx6=
9.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 veri=
fy=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.tx=
t=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.02=
32 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_H=
ELO=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.tx=
t
> > >=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