Subject: [[email-masked]: New Version Notification - draft-ietf-idwg-idmef-xml-16.txt]

From: Mike Erlinger <[email-masked]>
Date: Wed, 22 Mar 2006 18:10:24 -0800

fyi

mike

-- 
Mike Erlinger, Professor and Chair Computer Science
www:      http://www.cs.hmc.edu/~mike
email:    [email-masked]
smail:    Computer Science Dept., Harvey Mudd College,
          301 E. 12th Street, Claremont, CA, 91711 
          909-621-8912,   FAX: 909-607-8364
"As for the future, your task is not to foresee, but to enable it"
>From mike  Wed Mar 22 15:50:13 2006
To: <[email-masked]>, <[email-masked]>,
	[email-masked], [email-masked]
Cc: 
From: ID Tracker <[email-masked]>
Subject: New Version Notification - draft-ietf-idwg-idmef-xml-16.txt 
Date: Wed, 22 Mar 2006 18:50:02 -0500

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

IETF Secretariat.

---

From: joël Winteregg <[email-masked]>
Date: Tue, 28 Mar 2006 14:47:10 +0200

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="abc123" name="transporter" class="relay"
ostype="Linux" osversion="Debian">
         <Process>
           <name>relay</name>
           <pid>10818</pid>
           <path>/usr/bin/relay</path>
         </Process>
         <Analyzer name="DMZdetector" class="NIDS">
           <Node category="unknown">
             <name>localhost</name>
             <Address category="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). 

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ël.W

Le mercredi 22 mars 2006 à 18:10 -0800, Mike Erlinger a écrit :
> fyi
> 
> mike
> 
> pièce jointe message de courriel
> > -------- Message transféré --------
> > Sujet: No Subject
> > Date: Thu, 23 Mar 2006 08:23:53 +0100
> > 
> > Return-Path: <[email-masked]>
> > X-Original-To: [email-masked]
> > Delivered-To: [email-masked]
> > 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-masked]>; 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-masked]>; 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=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
> > 	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="utf-8"
> > Mime-Version: 1.0
> > Message-Id: <[email-masked]>
> > 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 
> > X-pstn-addresses: from <[email-masked]> [db-null] 
> > X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on turing
> > X-Spam-Status: No, score=0.1 required=7.5 tests=FORGED_RCVD_HELO 
> > 	autolearn=disabled version=3.0.1
> > X-Spam-Level: 
> > 
-- 
________________________________________________________________________

Joël Winteregg, Ingénieur HES en télécommunication
Phone: +41 24 557 64 73

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

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

---

From: joël Winteregg <[email-masked]>
Date: Tue, 28 Mar 2006 15:13:58 +0200

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

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ël.W