Subject: Re: IDMEF Draft 15

From: [email-masked]
Date: Fri, 24 Feb 2006 14:41:16 +0000

Hi Herve,

As GuardTower from SCS was largely one of the first SEMs developed in 2000 for an American
Telco, we have a vested interest in the proceedings of this group, as does Anton. I believe that
standardization in data export would go a long way in making ubiquitous information sharing.
for IPS incident response reporting.

Unfortunately, recent changes in hardware on commerical appliance IPS that scale to carrier class
bandwidths ( a necessity for signature comparison at such speeds) have the industry 
moving back into an exclusive proprietary SIM/SEM reporting models , I suspect for driving revenue for their 
proprietary architecures reporting consoles/ SEMs. This appears to be really playing fits with the managed services 
providers for supporting the new IPS appliances, I hear. This development is really a misguided tangential
direction, and I believe represents.the reason why the attempted standardization for this group and the group itself's charter.
Perhaps getting on with it.. and having IETF acceptance, is better, rather than perfection or agreement on the
draft.contents. In this way we can have the user community ask ( well does you IPS support the IDMEF 
standard for reporting Mr. IPS Vendor?, because that is a Mandatory requirement in our RFP, so we can conttinue 
to use our current SEM/SIM or choose an SEM/SIM as seperate best of breed solution based on it supporting our
organization's technology set.

What does this mean for IDS/IPS schema and RFC? Well point me to the latest draft and I will try to
make an articulate evaluation, but I would hope encrypted HTTPS transmission of the sreported chema /incident datagrams
would be in the RFC?

Dan White
CEO- Secure Commerce Systems
www. securecommercesystems.com
866- SEC COMM

>-----Original Message-----
>From: Herve Debar [mailto:[email-masked]]
>Sent: Friday, February 24, 2006 03:47 AM
>To: 'Anton Chuvakin, Ph.D.'
>Cc: ''intrusion detection wg''
>Subject: Re: IDMEF Draft 15
>
>Anton Chuvakin, Ph.D. wrote:
>> I am wondering if this message to the list actually got thru. If it did,
>> IDMEF is truly dead since nobody even bothered to respond to the
>> comments about its death...
>
>Well, it did go to the list, but I'm not sure there is much to respond
>to. You are voicing your opinion, which is fair enough, and at the same
>time not being specific enough to enable a response, IMO. And I'm really
>not interested in a flamefest at this stage.
>
>>> All,
>>>
>>>> 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.
>>>
>>> So, IDMEF is officially "dead" then? IDS might not be dead, but IDMEF
>>> largely is... I haven't posted to this list that much, but I've been
>>> watching IDMEF for many years. In fact, netForensics nFX SIM solutions's
>>> early XML event tranfer protocol, defined back in 2000, was loosely
>>> inspired
>>> by the IDMEF. However, IDMEF always was and remains largely unsuitable
>>> for
>>> our purposes, and I suspect other vendors in the SIM/SIEM/correlation
>>> space
>>> would agree with me. And so would the IDS (now IPS, for the most part)
>>> vendors. The issues are too numerous to list here. Even something as
>>> basic
>>> as alert vs hearbeart distinction raises some questions.
>
>There are SIM environments using IDMEF, commercially.
>
>>> One area where I can see shreds of IDMEF surviving is
>>> cross-organizational
>>> data sharing. A little problem with this is that it largely does not
>>> exist... I can see how a hybrid of IDMEF and IODEF with inherent and
>>> well-defined data sanitization might come handy. Other than that,
>>> utilization of IDMEF in four other use cases (from the page 4 of the
>>> doc) is
>>> totally irrelevant and is being better addressed by other means.
>
>As far as I can tell, INCH is also nearing completion, so again you may
>be late bringing in comments.
>
>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 (new)Fax: +33 (0)2 31 37 83 43
>42 rue des Coutures (--) BP 6243 (--) F-14066 Caen Cedex 4
>

---

From: Herve Debar <[email-masked]>
Date: Fri, 24 Feb 2006 16:22:41 +0100

[email-masked] wrote:
> As GuardTower from SCS was largely one of the first SEMs developed in
>  2000 for an American Telco, we have a vested interest in the
> proceedings of this group, as does Anton. I believe that 
> standardization in data export would go a long way in making
> ubiquitous information sharing for IPS incident response reporting.
> 
> Unfortunately, recent changes in hardware on commerical  appliance
> IPS that scale to carrier class bandwidths ( a necessity for
> signature comparison at such speeds) have the industry moving back
> into an exclusive proprietary SIM/SEM reporting models , I suspect
> for driving revenue for their proprietary architecures reporting
> consoles/ SEMs. This appears to be really playing fits with the
> managed services providers for supporting the new IPS appliances, I
> hear. This development is really a misguided tangential direction,
> and I believe represents the reason why the attempted standardization
> for this group and the group itself's charter. Perhaps getting on
> with it.. and having IETF acceptance, is better, rather than
> perfection or agreement on the draft contents. In this way we can
> have the user community ask ( well does you IPS support the IDMEF 
> standard for reporting Mr. IPS Vendor?, because that is a Mandatory 
> requirement in our RFP, so we can conttinue to use our current
> SEM/SIM or choose an SEM/SIM  as seperate best of breed solution
> based on it supporting our organization's technology set.

I share pretty much all of this. I need to be able to buy my sensors and
my SIM (or SIMs) from different vendors, and all these heterogenous
components should interoperate, and integrate with the specifics of the
environment we run. I do believe that without an RFC, it will be
impossible to put a standards requirement into RFPs.

> make an articulate evaluation, but I would hope encrypted HTTPS 
> transmission of the sreported chema /incident datagrams
> would be in the RFC?

IDMEF is the format. IDXP is the draft that specifies secure transport.
I will send you the draft in a separate mail.

Best regards,

Hervé