Re: [mile] IODEF Guidance and existing implementations

Eric Burger <eburger@standardstrack.com> Sun, 14 July 2013 21:58 UTC

Return-Path: <eburger@standardstrack.com>
X-Original-To: mile@ietfa.amsl.com
Delivered-To: mile@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A93B921F9BCA for <mile@ietfa.amsl.com>; Sun, 14 Jul 2013 14:58:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.389
X-Spam-Level:
X-Spam-Status: No, score=-101.389 tagged_above=-999 required=5 tests=[AWL=-0.280, BAYES_05=-1.11, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fl11ZFI6iSWm for <mile@ietfa.amsl.com>; Sun, 14 Jul 2013 14:58:32 -0700 (PDT)
Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.15]) by ietfa.amsl.com (Postfix) with ESMTP id B7D6321F8D6D for <mile@ietf.org>; Sun, 14 Jul 2013 14:58:32 -0700 (PDT)
Received: from ip68-100-196-226.dc.dc.cox.net ([68.100.196.226]:55827 helo=[192.168.15.100]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from <eburger@standardstrack.com>) id 1UyUJB-0005fA-BJ for mile@ietf.org; Sun, 14 Jul 2013 14:58:30 -0700
From: Eric Burger <eburger@standardstrack.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_FAC3C6A3-1221-44D2-9FBA-838205C59680"; protocol="application/pgp-signature"; micalg="pgp-sha1"
Message-Id: <03ECCD98-EB64-4468-90D9-8B44205F4F35@standardstrack.com>
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
Date: Sun, 14 Jul 2013 17:58:21 -0400
References: <F5063677821E3B4F81ACFB7905573F24DF1B8373@MX15A.corp.emc.com> <1C9F17D1873AFA47A969C4DD98F98A753DB4F8@xmb-rcd-x10.cisco.com>
To: "mile@ietf.org IETF" <mile@ietf.org>
In-Reply-To: <1C9F17D1873AFA47A969C4DD98F98A753DB4F8@xmb-rcd-x10.cisco.com>
X-Mailer: Apple Mail (2.1508)
X-OutGoing-Spam-Status: No, score=-0.2
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - standardstrack.com
X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed
X-Source:
X-Source-Args:
X-Source-Dir:
Subject: Re: [mile] IODEF Guidance and existing implementations
X-BeenThere: mile@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" <mile.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mile>, <mailto:mile-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mile>
List-Post: <mailto:mile@ietf.org>
List-Help: <mailto:mile-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mile>, <mailto:mile-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 14 Jul 2013 21:58:36 -0000

On the one hand, it is nice to have everything in a single document. On the other hand, it is really hard to get big documents reviewed, revised, reviewed, revised, area reviewed, revised, IESG reviewed, revised, and IETF reviewed. A pair of smaller documents will be much easier to get done. Moreover, the use cases will expand over time (I hope), yet the protocol will not change that much (I hope). Thus, two documents may be easier to manage and ultimately get published.

On Jul 2, 2013, at 10:50 AM, Panos Kampanakis (pkampana) <pkampana@cisco.com> wrote:

> Thank you Kathleen.
>  
> > I would like to see us use the IODEF guidance document to work through use cases and document what gets shared with whom for various use cases, then demonstrated using RFC5070-bis. 
> I can keep the usecases and document them in the Guidance doc. But what is going to be different compared to the usecases in the bis doc? Will we just describe them using prose text and the bis document will have the actual XML?
>  
> Panos
>  
>  
>  
>  
> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Moriarty, Kathleen
> Sent: Friday, June 28, 2013 11:32 AM
> To: mile@ietf.org
> Subject: [mile] IODEF Guidance and existing implementations
>  
> Hi Panos & Others,
>  
> Panos had asked about moving the examples from the IODEF Guidance to RFC5070-bis, was that the right thing to do?
>  
> I would like to see us use the IODEF guidance document to work through use cases and document what gets shared with whom for various use cases, then demonstrated using RFC5070-bis.  Implementations are increasing and I think this would be really helpful so that those implementations have guidance to implement the use cases relevant to their users.
>  
> We could start with documentation on some of the existing use cases that have been implemented, some in development, and then look to see how we can share effectively with new use cases.
>  
> The existing and active implementations I am aware of include:
> o   APWG Anti-phishing – using IODEF
> o   APWG eCrime – using IODEF
> o   XMPP Operators using IODEF over XMPP for active exchanges
> o   Blackthorn – Using IODEF + extensions for communications between several nations, with IODEF accessed on mobile platforms
>  
> Names may not be ready to be public:
> o   energy sector organization using IODEF over XMPP
> o   reports sent via IODEF for consumption from a sharing group
>  
> PoCs:
> o  Multiple PoCs in play using IODEF + RID between several vendors in support of the MACCSA framework
>  
> Implementations:
> DFLabs – has the Digital Investigation Manager product using IODEF since at least 2007
> Arcsite supports imports of RFC5070 formatted IODEF reports, there may be other vendors?
> Blackthorn – product using IODEF + private extensions for active sharing
> Open Source RID Agent with RFC5070-bis support in java from EMC/RSA – on GitHub: https://github.com/RSAIntelShare/RID-Server
> Open source RID Agent implementation in Python from MITRE – I don’t have the link, but it is compatible with the EMC/RSA one
> CSI Extension support for IODEF on Github from NICT in Java:
> https://github.com/TakeshiTakahashi/IODEF-SCI/wiki/IODEF-SCI-tools
> eCRISP-X:  Suports eCrime use cases using IODEF RFC5070, from Pat Cain:
> http://sourceforge.net/projects/ecrisp-x
> eCRISP-X: Phisihing report support – can’t find the link, but know it exists for the APWG use case
> iodeflib: a python library to create, parse & edit IODEF:
> http://www.decalage.info/python/iodeflib
> IODEF/RID – older versions (RFC6045, RFC6046 and RFC5070) in open source from Japan: http://www.ipa.go.jp/security/fy16/development/IODEF/api/index.html
> IODEF & RID implementation in Japanese from the Information technology Protection Agency (IPA):
> http://www.cysols.com/research/iodef/IODEFApp.html
> CPAN IODEF perl module to create & parse IODEF:
> http://search.cpan.org/~johng/XML-IODEF-0.06/
> Collective Intelligence Framework (CIF) from Ren-ISAC uses a modified version of IODEF for their active sharing platform
> The CERT.org site that tracked this in the past has a few others listed and also says the following organizations have active projects using IODEF on their pagehttp://www.cert.org/ietf/inch/inch.html :  CERT/CC: AirCERT, JPCERT/CC: Internet Scan Data Acquisition Systems (ISDAS), and eCSIRT.net: The European CSIRT Network
>  
> If I missed any, please add to the list.  It would be good to get these on a web page or wiki as a running list that can be amended as there is a lot of development/PoC activity right now.
>  
> For the IODEF Guidance, we can look at the use cases, determine what is successful and get the use cases documented.
>  
> Thank you,
> Kathleen
>  
> _______________________________________________
> mile mailing list
> mile@ietf.org
> https://www.ietf.org/mailman/listinfo/mile