Concluded

The Intrusion Detection Working Group is done.  The IESG has accepted
our documents and they will be published as Experimental RFCs.

The mailing list for the workgroup, idwg-l <at> hmc.edu, will be shut down
in the next couple of days.

mike

--

-- 
Mike Erlinger, Professor and Chair Computer Science
www:      http://www.cs.hmc.edu/~mike
email:    mike <at> cs.hmc.edu
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"

ICNS 2006: Early Registration Ends April 1

International Conference on Network Security 2006

IDMEF Draft 15

IDMEF draft 15 answers all the comments received from
the IESG.  The draft was sent to the Internet Drafts
directory today and a zip version is attached to this
message.

By 25 February, we would like to get all applicable 
comments.  Again, we are not making changes to the
substance of the document, but rather just cleaning up
an typo type problems.  Once we are done with the
document, we will ask that it be published as an 
experimental rfc.

mike

--

-- 
Mike Erlinger, Professor and Chair Computer Science
www:      http://www.cs.hmc.edu/~mike
email:    mike <at> cs.hmc.edu
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"

Re: [IDWG] Closing on IDMEF

Hi all,

Regarding applications using IDMEF I'm the maintainner of snort-idmef
(sf.net/projects/snort-idmef), an output plugin for the Open Source IDS
Snort as well as the co-author of libidmef (sf.net/projects/libidmef) which
is already conforming to draft 14 (using DTD).

From the feedback I got regarding those projects they are used in
educational as well as commercial environments.

snort-idmef is pending inclusion in the stock snort distribution btw.

Regarding DTD vs schema I don't have a special preference.

And one last note: I didn't receive much feedback for my asset proposal, an
addition to IDMEF for defining assets. As I understand that there is no
chance to be included in the current IDMEF how is the way for further
discussion on that issue.

Thank you,
Sandro

--

-- 
Telefonieren Sie schon oder sparen Sie noch?
NEU: GMX Phone_Flat http://www.gmx.net/de/go/telefonie

Finishing Off IDWG

Hi Everyone

IDWG was on my list of things to do after the New Year.  Sam Hartman,
the Security Area Director beat me to it.  Basically, the IDWG Working
Group has been idle for over a year; IDMEF is still an Internet Draft;
the IESG has issues with the use of both DTD and Schemas in IDMEF.

Herve Debar, the primary author of IDMEF, is willing to make changes
recommended by the IESG.  He has sent out email to the list asking
for information about the use of IDMEF and whether a DTD or Schema
is the better choice.  He will use the responses to drive a new
document.  Once we have a new document, Sam will assist
us in getting IDMEF published as an Experimental RFC.  This would
finish the IDWG Working Group efforts and the Working Group would
be closed.

So, very soon Herve will post a new Internet Draft to the mailing
list.  I will then post the ID to the ID database.  Once this is
done, I would ask people to read the document and post any typo
issues (since IDMEF passed a Working Group last call and was
forwarded to the AD and IESG, we are past making serious
modifications to the IDMEF, except as directed by the IESG).

Once the Working Group is happy with the document, I would ask
that it be published as an Experimental RFC.

mike

--

-- 
Mike Erlinger, Professor and Chair Computer Science
www:      http://www.cs.hmc.edu/~mike
email:    mike <at> cs.hmc.edu
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"

Re: Question: DARPA's Common Intrusion Detection Framework (CIDF)and the IDWG effort to refine the CIDF and get it commercially accepted

>>>>> "Daniel" == Daniel White <dwhite <at> securecommercesystems.com> writes:

    Daniel> Gentlemen, Having installed more ISS RealSecure/
    Daniel> Proventia, Snort, Cisco IDS, Juniper / Netscreen IPS, and
    Daniel> some Enterasys ( and then there is LAncope , Intrusion
    Daniel> .com and all the others), I believe the IDWG, in my
    Daniel> opinion should not be disbanded, but rather evolve and be
    Daniel> retooled with commercial IDS/IPS participation.

Can you get the commercial IDS vendors to come to the table, commit to
reviewing and working on documents and implementing the result?

If so, why haven't you already done so?  I brought up problems with WG
participation over a year ago.

If not, then we are going to have to close the WG, possibly publishing
the current work as an experimental snapshot until someone can bring
the right players to the table.

--Sam

Re: Question: DARPA's Common Intrusion Detection Framework (CIDF)and the IDWG effort to refine the CIDF and get it commercially accepted

.  Hi.  I do sympathize with the desire to get a standardized
intrusion detection format.

If IDMEF and IDWG do fail, it will not prevent future efforts from
being considered in the IETF or elsewhere.

I would be happy to be approached by efforts that are likely to meet
engineering success.

However, the IETF is not an appropriate forum to "do science."  In
particular, the IETF is not an appropriate forum to research new
proposals or to design experiments.  The IRTF may be such a forum.

The IETF is an appropriate forum when we get to a point where we can
design standards (possibly based on research) for use in products
deployed on production networks.

One implication of this is that for an effort to be successful in the
IETF you will need vendors who plan to implement the standard
involved.  If there are no such vendors, then the effort is very
unlikely to succeed.

Sam hartman
Security Area Director

[IDWG] Closing on IDMEF

Dear all,

as you have seen from Sam Hartman's message, we have one last chance to
make IDMEF an experimental RFC, hence finalizing the document. I am
enclosing for your perusal version -14, which has been reviewed by Sam
Hartman, and the tentative -15 version, which I would like to be the
final RFC. The -15 version contains minor corrections from -14.

The key issue there is to show the IESG and Sam Hartman that there is
support from the community to have a schema instead of a DTD. Hence, I
would like to have an opinion from all of you who care about this issue.
Please let me know by feb. 7th midnight if you support:

- the DTD as normative (in which case -14 is the final version with DTD
and schema swaped)

or

- the schema as normative (in which case -15 is the final version)

and additionally, whether you are using IDMEF as
- an academic
- an industrial vendor (including references / number of deployments if
you can publicly state them.
[In both cases a web site will be appreciated].

Depending on the number of answers I receive, I will make one last
attempt to push for the schema being normative, or I will swap DTD and
schema in the final document and move it to the RFC editor.

Best regards, and thanks to you all for helping.

Hervé
--

-- 
Hervé Debar             <mailto:herve.debar <at> francetelecom.com>
Tel: +33 (0)2 31 75 92 61            GSM: +33 (0)6 74 09 09 66
France Télécom R&D              (new)Fax: +33 (0)2 31 37 83 43
42 rue des Coutures  (--)  BP 6243  (--)  F-14066 Caen Cedex 4

Required changes to draft-ietf-idwg-idmef-xml-14

Hi.  I apologize for the long time it has taken me to review the idmef
draft.

One problem with the IESG job is that if something has been delayed
for a long time, you get into the trap of assuming that additional
delay won't hurt much more and so you focus on things that are not yet
behind.  Clearly this is not the correct strategy but it seems to be
the trap I've fallen into here.

I have also been slow because I needed to seek significant input from
the rest of the IESG.

When e last talked, I was going to go off and review the document.  I
said that if no significant changes were needed I'd take it to the
IESG and not think too hard about whether there is still an active
working group here.  

Unfortunately, I believe there are changes required.  So I have
evaluated the question of whether there has been enough active
participation in the last versions of the document and in the first
part of this year to consider IDWG an active working group.  Based on
my own conclusions and on the strong opinions of other area directors
I've consulted with, IDWG no longer constitutes an active working
group.  There is an insufficient core of active
participants--particularly participants not involved in the
document--to generate an informed consensus on changes.

However it is desirable to publish IDMEF in at least some form.  The
IESG said it would be willing to support publication of IDMEF as an
experimental RFC provided that some consistency problems are fixed.
The existing protocol document would be reclassified as an
experimental RFC.

So, what changes are required?

The only critical change is that while the schema is normative, all
the document is written in terms of the DTD not the schema.  As an
example, IDMEF messages are required to include DTD declarations, and
all of the class semantics are written in terms of the schema.

For this reason, I do not believe the schema can be normative.  Also,
based on discussing this transition with others, I have very low
confidence that the schema and DTD will be consistent.  

So I request that the schema be removed and the DTD become normative
again.

We can discuss alternatives, but you will need to convince me that the
resulting document is self consistent and that you have the necessary
resources to make that evaluation.

If we have not made significant progress by the end of IETF 65 (end of
March), then I will close the WG and mark the documents as dead.

Re: Proposal for additional asset infos in IDMEF

After some discussion on the prelude-ids list I added a more accurate 
description to the Tool class' manucfacturer attribute as follows:

manufacturer
       Optional.  The manufacturer of the tool software. If the name
       attribute is set to "manual" the manufacturer attribute could be
       set to the name or the personnell ID or some other descriptive
       term.

Regards,
Sandro