Re: IDMEF Draft 15
[email protected] Fri, 24 Feb 2006 14:41:16 +0000
| Newsgroups | gmane.ietf.idwg |
|---|---|
| Message-ID | <W9067928291325581140792076@webmail4> |
----=_vm_0011_W9067928291_32558_1140792076 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mail2.ac.hmc.edu id k1OEfIVJ023984 Hi Herve, As GuardTower from SCS was largely one of the first SEMs developed in 200= 0 for an American Telco, we have a vested interest in the proceedings of this group, as doe= s Anton. I believe that standardization in data export would go a long way in making ubiquitous i= nformation sharing. for IPS incident response reporting. Unfortunately, recent changes in hardware on commerical appliance IPS tha= t scale to carrier class bandwidths ( a necessity for signature comparison at such speeds) have th= e industry=20 moving back into an exclusive proprietary SIM/SEM reporting models , I su= spect for driving revenue for their=20 proprietary architecures reporting consoles/ SEMs. This appears to be rea= lly playing fits with the managed services=20 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 standard= ization for this group and the group itself's charter. Perhaps getting on with it.. and having IETF acceptance, is better, rathe= r than perfection or agreement on the draft.contents. In this way we can have the user community ask ( well doe= s you IPS support the IDMEF=20 standard for reporting Mr. IPS Vendor?, because that is a Mandatory requi= rement in our RFP, so we can conttinue=20 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 late= st draft and I will try to make an articulate evaluation, but I would hope encrypted HTTPS transmiss= ion 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 protected]] >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 di= d, >> 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 j= ust >>> 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 solution= s's >>> early XML event tranfer protocol, defined back in 2000, was loosely >>> inspired >>> by the IDMEF. However, IDMEF always was and remains largely unsuitabl= e >>> 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=E9 >--=20 >Herv=E9 Debar <mailto:[email protected]> >Tel: +33 (0)2 31 75 92 61 GSM: +33 (0)6 74 09 09 66 >France T=E9l=E9com R&D (new)Fax: +33 (0)2 31 37 83 43 >42 rue des Coutures (--) BP 6243 (--) F-14066 Caen Cedex 4 > ----=_vm_0011_W9067928291_32558_1140792076 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html><P>Hi Herve,</P> <P><BR>As GuardTower from SCS was largely one of the first SEMs developed= in 2000 for an American</P> <P>Telco, we have a vested interest in the proceedings of this group, as = does Anton. I believe that</P> <P>standardization in data export would go a long way in making ubiquitou= s information sharing.</P> <P>for IPS incident response reporting.</P> <P> </P> <P>Unfortunately, recent changes in hardware on commerical applianc= e IPS that scale to carrier class</P> <P>bandwidths ( a necessity for signature comparison at such speeds) have= the industry </P> <P>moving back into an exclusive proprietary SIM/SEM reporting model= s , I suspect for driving revenue for their </P> <P>proprietary architecures reporting consoles/ SEMs. This appears to be = really playing fits with the managed services </P> <P>providers for supporting the new IPS appliances, I hear. This developm= ent is really a misguided tangential</P> <P>direction, and I believe represents.the reason why the attempted stand= ardization for this group and the group itself's charter.</P> <P>Perhaps getting on with it.. and having IETF acceptance, is better, ra= ther than perfection or agreement on the</P> <P>draft.contents. In this way we can have the user community ask ( well = does you IPS support the IDMEF </P> <P>standard for reporting Mr. IPS Vendor?, because that is a Mandatory re= quirement in our RFP, so we can conttinue </P> <P>to use our current SEM/SIM or choose an SEM/SIM as seperate best= of breed solution based on it supporting our</P> <P>organization's technology set.</P> <P> </P> <P>What does this mean for IDS/IPS schema and RFC? Well point me to the l= atest draft and I will try to</P> <P>make an articulate evaluation, but I would hope encrypted HTTPS transm= ission of the sreported chema /incident datagrams</P> <P>would be in the RFC?</P> <P> </P> <P>Dan White</P> <P>CEO- Secure Commerce Systems</P> <P>www. securecommercesystems.com</P> <P>866- SEC COMM<BR><BR>>-----Original Message-----<BR>>From: Herve= Debar [mailto:[email protected]]<BR>>Sent: Friday, Februa= ry 24, 2006 03:47 AM<BR>>To: 'Anton Chuvakin, Ph.D.'<BR>>Cc: ''intr= usion detection wg''<BR>>Subject: Re: IDMEF Draft 15<BR>><BR>>An= ton Chuvakin, Ph.D. wrote:<BR>>> I am wondering if this message to = the list actually got thru. If it did,<BR>>> IDMEF is truly dead si= nce nobody even bothered to respond to the<BR>>> comments about its= death...<BR>><BR>>Well, it did go to the list, but I'm not sure th= ere is much to respond<BR>>to. You are voicing your opinion, which is = fair enough, and at the same<BR>>time not being specific enough to ena= ble a response, IMO. And I'm really<BR>>not interested in a flamefest = at this stage.<BR>><BR>>>> All,<BR>>>><BR>>>&g= t;> By 25 February, we would like to get all applicable comments. Agai= n, we<BR>>>> are not making changes to the substance of the docu= ment, but rather just<BR>>>> cleaning up an typo type problems.<= BR>>>>> Once we are done with the document, we will ask that = it be published<BR>>>>> as an<BR>>>> experimental rf= c.<BR>>>><BR>>>> So, IDMEF is officially "dead" then? I= DS might not be dead, but IDMEF<BR>>>> largely is... I haven't p= osted to this list that much, but I've been<BR>>>> watching IDME= F for many years. In fact, netForensics nFX SIM solutions's<BR>>>&g= t; early XML event tranfer protocol, defined back in 2000, was loosely<BR= >>>> inspired<BR>>>> by the IDMEF. However, IDMEF alway= s was and remains largely unsuitable<BR>>>> for<BR>>>> = our purposes, and I suspect other vendors in the SIM/SIEM/correlation<BR>= >>> space<BR>>>> would agree with me. And so would the = IDS (now IPS, for the most part)<BR>>>> vendors. The issues are = too numerous to list here. Even something as<BR>>>> basic<BR>>= ;>> as alert vs hearbeart distinction raises some questions.<BR>>= ;<BR>>There are SIM environments using IDMEF, commercially.<BR>><BR= >>>> One area where I can see shreds of IDMEF surviving is<BR>&g= t;>> cross-organizational<BR>>>> data sharing. A little pr= oblem with this is that it largely does not<BR>>>> exist... I ca= n see how a hybrid of IDMEF and IODEF with inherent and<BR>>>> w= ell-defined data sanitization might come handy. Other than that,<BR>>&= gt;> utilization of IDMEF in four other use cases (from the page 4 of = the<BR>>>> doc) is<BR>>>> totally irrelevant and is bei= ng better addressed by other means.<BR>><BR>>As far as I can tell, = INCH is also nearing completion, so again you may<BR>>be late bringing= in comments.<BR>><BR>>Herv=E9<BR>>-- <BR>>Herv=E9 Debar <= mailto:[email protected]><BR>>Tel: +33 (0)2 31 75 92 61= GSM: +33 (0)6 74 09 09 66<BR>>France T=E9l=E9com R&D (new)Fax: +3= 3 (0)2 31 37 83 43<BR>>42 rue des Coutures (--) BP 6243 (--) F-14066 C= aen Cedex 4<BR>></P></html> ----=_vm_0011_W9067928291_32558_1140792076--