From trammell@tik.ee.ethz.ch Thu Oct 3 15:48:56 2013 Return-Path: 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 CBD0621F91BF for ; Thu, 3 Oct 2013 15:48:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 DGwAkTOkxjD3 for ; Thu, 3 Oct 2013 15:48:45 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 029A321F915C for ; Thu, 3 Oct 2013 15:48:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 952EBD9319 for ; Fri, 4 Oct 2013 00:48:43 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id dEDgPimff9Us for ; Fri, 4 Oct 2013 00:48:43 +0200 (MEST) Received: from [10.0.27.100] (cust-integra-122-165.antanet.ch [80.75.122.165]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 14C5FD9317 for ; Fri, 4 Oct 2013 00:48:43 +0200 (MEST) From: Brian Trammell Content-Type: multipart/signed; boundary="Apple-Mail=_7AF45C3B-80D3-40E5-B3DD-6FF1B44B5FAE"; protocol="application/pgp-signature"; micalg=pgp-sha512 Message-Id: <5E4EF3AE-6ACF-423D-98AA-0E740F8CE0D7@tik.ee.ethz.ch> Date: Fri, 4 Oct 2013 00:48:41 +0200 To: MILE IETF Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Subject: [mile] No MILE meeting in Vancouver; SCI submitted for publication X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 22:48:57 -0000 --Apple-Mail=_7AF45C3B-80D3-40E5-B3DD-6FF1B44B5FAE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Greetings, all, Given that the bulk of the energy of the working group is focused on the = continuing discussion of RFC5070-bis, and that this discussion is = working just fine on the mailing list, we will not be having a MILE = session at the IETF 88 meeting in Vancouver next month. In other news, we've submitted draft-ietf-mile-sci to the IESG for = publication today. Many thanks to the authors and the working group for = seeing this draft through to this point! Best regards, Brian --Apple-Mail=_7AF45C3B-80D3-40E5-B3DD-6FF1B44B5FAE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSTfRJAAoJENt3nsOmbNJcGwQH/2hfuUE9VqYxKZbwHnH2hrD5 M7awfIwJLNnKapJEybd6uHDoR7w0RqRRWOII+XmVY+qR89ldzruFnrs4Uvr+m1Z5 FkZmLbVQwKeClU7mvfy+RPQi2x2IRm2ZBljuUeYlE8cq7dO6ndMY4I+rG2+K+w2g pOIl2SO+4Pwogkk7xBEXRuprxt3uXQMDG6mRN8xAbpWDKPai8r9Chr8XB8iwDC0n qfzmKy/8nYOs2FVULT92fZ+/+1NtXT3jN7sWl1xHgavxP/858Y+Oa5XdR0T2yE3j L0Tq6sQlv4Edk8GRq0YGIh20mBEJq3IyRm5gyMcz3kEQe8DtHP6qcxRs5iyEvp8= =0mFC -----END PGP SIGNATURE----- --Apple-Mail=_7AF45C3B-80D3-40E5-B3DD-6FF1B44B5FAE-- From rdd@cert.org Fri Oct 4 12:14:25 2013 Return-Path: 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 8D14321F9A97 for ; Fri, 4 Oct 2013 12:14:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.11 X-Spam-Level: X-Spam-Status: No, score=-5.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4] 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 QUX8MvIayoQD for ; Fri, 4 Oct 2013 12:14:20 -0700 (PDT) Received: from plainfield.sei.cmu.edu (plainfield.sei.cmu.edu [192.58.107.45]) by ietfa.amsl.com (Postfix) with ESMTP id 932CC21F99FD for ; Fri, 4 Oct 2013 12:14:17 -0700 (PDT) Received: from timber.sei.cmu.edu (timber.sei.cmu.edu [10.64.21.23]) by plainfield.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id r94JE8wh024329; Fri, 4 Oct 2013 15:14:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1380914048; bh=W9htWOOzukPcuBmiRRRDT0lwsn4BU1PEBO2pzbtZ2Sg=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version:Sender: Reply-To:Cc; b=C2qQMeooyoEzTCvfTeMn9ErNAajjmTttOYHLM5JBgUdQGS/WkwMfrXXDxutrDN9kV fVdSe+rB58A7M+WITcTOL6/I2Q01I7rR+xEsWv8ScIXcTnGI/OO9pVAAzwQDGI6Dts yyH9Vw1avqK3yO9rLeHZQ3Ib6RwE+eiEaCffHKRE= Received: from CASCADE.ad.sei.cmu.edu (cascade.sei.cmu.edu [10.64.28.248]) by timber.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id r94JE62H007972; Fri, 4 Oct 2013 15:14:07 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.02.0347.000; Fri, 4 Oct 2013 15:14:06 -0400 From: "Roman D. Danyliw" To: "Moriarty, Kathleen" , "'Panos Kampanakis (pkampana)'" , "mile@ietf.org" , "'Anton Chuvakin'" Thread-Topic: 5070-bis scoping discussion #3: cyber incident reporting Thread-Index: Ac6tvkUQFEq5GVyGTJi/wsZPWohryABbKiHQAlCgEUABC/+ZkAEhEl9w Date: Fri, 4 Oct 2013 19:14:05 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC54B834FE@marathon> References: <359EC4B99E040048A7131E0F4E113AFC5415FA8A@marathon> <1C9F17D1873AFA47A969C4DD98F98A750489944C@xmb-rcd-x10.cisco.com> <359EC4B99E040048A7131E0F4E113AFC54B6677D@marathon> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mile] 5070-bis scoping discussion #3: cyber incident reporting X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 19:14:25 -0000 Hello! A few comments inline ... > -----Original Message----- > From: Moriarty, Kathleen [mailto:kathleen.moriarty@emc.com] > Sent: Saturday, September 28, 2013 6:58 PM > To: Roman D. Danyliw; 'Panos Kampanakis (pkampana)'; mile@ietf.org; > 'Anton Chuvakin' > Subject: RE: 5070-bis scoping discussion #3: cyber incident reporting >=20 > This poll was closed, but consensus was not clear on all items, so I am a= dding > some feedback and also requesting examples that may help people to chime > in with opinions. >=20 > Answers are in-line (with chair hat off), beginning with KM> >=20 > Thanks to Roman for running the poll and to all who chime in! > Kathleen >=20 > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of > Roman D. Danyliw > Sent: Monday, September 23, 2013 11:15 AM > To: 'Panos Kampanakis (pkampana)'; mile@ietf.org; 'Anton Chuvakin' > Subject: Re: [mile] 5070-bis scoping discussion #3: cyber incident report= ing >=20 > Hello! >=20 > My feedback is inline. I consolidated Anton Chuvakin's comments in the > same post so all feedback is in a single thread. Comments are annotated = as > follows: >=20 > PK =3D Panos Kampanakis > AC =3D Anton Chuvaki > RD =3D Roman Danyliw >=20 > (8) What data elements should be added to Expectation and HistoryItem? > **(a)** Predefined course of actions -- add another class (other than > Description) to encode the action when @action=3D"other"? > **(b)** Add a cost metric to the action? > **(c)** Add the ability to describe the (actual or expected) efficacy the > action? > PK> I think the Description can fit all the above. Adding separate fields= or > classes could help if the iodef consumers could use them to take action o= r > draw conclusions, but I don't think the new field can be used in such a w= ay. > AC> Per (a) and (b), I'd vote against it since it will simulate addition = of bad > quality data (=3D random numbers for costs). > RD> +1 on (a) > KM> I think a proposal for 8a would help. It seems like a good idea, but > Panos responded with a question, not a firm response. If there was a > proposal, then you should get more decisive answers. =20 I'll speak for (8.a). This attribute is supposed to classify the action be= ing requested. The details of this request are in Expectation/Description,= a field that as currently described is free-form not necessarily lending i= tself to automated processing. The question was do we want to support pre-= defined courses of action. One way to currently support this representatio= n is by using Expectation@action=3D"other", but that might not be the only = way. Suppose that two organizations (Organization #1 and #2) regularly share inf= ormation to the degree that they worked out distinct, multi-steps procedure= s for handling specific events. For simplicity, assume Procedure-A and Pro= cedure-B was negotiated for instances where one organization tells another = about an Expectation@action=3D"watch-and-warning" type event. In this exam= ple, Procedure-A and Procedure-B are predefined courses of action. Also as= sume that when Organization #1 tells #2 to run "Procedure-A" that Organizat= ion #2 can pull up this procedures out-of-band and proceed with execution. = =20 There are at least 5 different approaches to encoding a given predefined pr= ocedure per the example above: Option #1 =3D=3D=3D=3D=3D=3D=3D=3D Procedure-A Option #2 =3D=3D=3D=3D=3D=3D=3D=3D Procedure-A Option #3 =3D=3D=3D=3D=3D=3D=3D=3D Option #4 =3D=3D=3D=3D=3D=3D=3D=3D Procedure-A Option #5 =3D=3D=3D=3D=3D=3D=3D Procedure-A Without changes, Option #1 - #3 would be the way to implement this work-flo= w. The fact that there are multiple ways might be undesirable. Also, if m= ultiple Expectation/Description classes are used this might cause implement= ation confusion. Option #4 and #5 explicitly introduce a new class to desc= ribe this predefined action. To restate the (8.a) question again: ** Do we want to support the standardized exchange of this kind of predefin= ed courses of action information? ** If so, do we want to provide implementers guidance on how to do that giv= en the current data-model (i.e., choose between Options #1 - 3)? ** If Option #1 - 3 are not desirable, do we want to introduce another elem= ent (e.g., ) to explicitly encode this information? > For 8b, do people use > the impact costs now? If so, it could be helpful, but I have not heard t= hey > really use it. > I think Description could work for c, was there any input that was provid= ed to > put this question in the list to guide the responders? The argument against using the Description class would be that it would dif= ficult to know that this information is being passed without sophisticated = natural language processing. Thinking out loud, if some refactoring of the= Confidence class was used, the semantics of the information would be more = immediately clear. =20 > (9) What data elements should be added to System? > **(a)** Add the data element to represent an Asset Number? (or is it not > needed if System/AdditionalData/Platform used?) > PK> The latter (not needed). > AC> Asset tag is not necessarily a NUMBER. Asset tag is not a bad additi= on. > RD> +1 to add an asset tag identifier. > KM> An example may be helpful here too. We have SWID already, how > would an asset tag be added and represented (Anton's question). I'd propose that the asset tag number be an opaque identifier assigned by t= he entity owning the asset. In my organization, that would be what the IT = department scans for inventory purposes. My read of Application@swid is th= at it's a unique identifier for a given application. > **(b)** Add a Contact class? (is it needed if EventData/Contact is used?) > PK> IMO, Not needed. System is part of the Flow which is in EventData, > which has a contact. > KM> A why would have been helpful here. Is an instance of System getting > pulled out of the Flow class? If so, is it still in EventData, and is it= needed? >=20 > **(c)** Add some indication of the type of ownership (e.g., Corporate, > Partner, Personally-owned)? > PK> That could be to describe the asset or target. I could see some use h= ere, > but it could be a little subjective. I mean what is a Partner assets for = me could > be a corporate asset for the partner, so the iodef will not be describing= it > correctly. > AC> Per (b) and (c) A good idea indeed! > RD> +1 on adding (b) and (c) > KM> I do think this is helpful. >=20 > **(d)** What specific location information is needed beyond > System/Location? > AC> 2 locations: physical ( e.g. address, alt/long, etc) and administrat= ive (e.g. > located in datacenter 2) > RD> +1 on Anton's suggestion of two different Locations. I would like to= hear > specifically about how the community would like to represent each of thes= e. > KM> Can you offer a proposal or a couple of options? That will be the ea= siest > way to get feedback. To correct the error in the question, it should read "System/Node/Location"= . Location is currently an ML_STRING. =20 It appears that there are at least three different expressions of location: ** coordinates (e.g., 40.4417 N, 80.0000 W) ** postal address (e.g., Data Center Building, Carnegie Mellon University, = 5000 Forbes Ave, Pittsburgh, PA, 15213, USA) ** administrative (e.g., Slot 3 - 6, Rack 6, Row 9, Datacenter 2) Is that correct? > (10) What data elements should be added to Contact? > **(a)** Add a data element to represent a title (e.g., *Mr.* Smith, > *Captain* Johnson)? > RD> +1 since this was requested by an implementer > KM> Good reason, I am fine with that decision >=20 > **(b)** Should ContactName be split in into a given name and surname? (at > the Berlin IETF, Brian Trammell, the working group chair, voiced > RD> Concur with Brian Trammell as two complicated > KM> +1 >=20 > **(c)** Add a data element to represent a Department? > PK> I think the ContactName and Description can describe the above. For > simplicity I think there is no need for more fields. > RD> As an optional item, it could help. > KM> My answer depends. If department is used for the contact role, then > this could be helpful. I work at a large organization. Although we have= many > divisions, you deal with people without naming their specific division as= you > can look that up elsewhere. You could tie the application to a directory > server to grab that and then have no need to transport it around (search = on > their email and populate the application). Is there a reason? Is this f= or inter- > organization exchanges? >=20 > **(d)** Add a data element to represent a network user id (e.g., > LOCALNET\john) > PK> I don't see where this could be used. > RD> I can use for this as a unique ID for an individual. > KM> I think Panos was asking for an example. Is this for part of the inc= ident > information or part of the contact information for those sending or recei= ving > the report? I'm having difficulty finding the note from the implementer who had this re= quest. As I remember it, the network uid would be a substitute for Contact= /ContactName. > (11) What data elements should be added to Assessment? > **(a)** Add a summary of the impact to business/mission (add > Incident/Assessment/Description? Or some enumerated values to > qualitatively describe the impact?) > PK> I think a summary could be useful. Should not be mandatory. > RD> +1 > KM> +1 >=20 > **(b)** Add a means to enumerate the intended purpose of attack (e.g., > theft-of-IP, degradation of service, fraud) > PK> Could be useful. Should not be mandatory. > KM> +1 >=20 > Thanks! >=20 >=20 > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of > Roman D. Danyliw > Sent: Monday, September 09, 2013 8:42 PM > To: mile@ietf.org > Subject: [mile] 5070-bis scoping discussion #3: cyber incident reporting >=20 > Hello! >=20 > Per the announcement in [1], this note initiates topic discussion #3 on t= he > 5070bis scope. Please refer to discussion #1 [2] and #2 [3] in the archi= ve. >=20 > Discussion #3 is intended to clarify what additional data elements are > required for incident reporting. The power-point formatted version of th= is > text can be found in slides 8 and 9 of [4]. If you have a feelings on th= e > matter, please provide input by noon of September 23rd. Opinions to add > something or explicitly avoid it are welcome. In the case of the former, > proposals are welcome but not required. >=20 > (8) What data elements should be added to Expectation and HistoryItem? > **(a)** Predefined course of actions -- add another class (other than > Description) to encode the action when @action=3D"other"? > **(b)** Add a cost metric to the action? > **(c)** Add the ability to describe the (actual or expected) efficacy the > action? >=20 > (9) What data elements should be added to System? > **(a)** Add the data element to represent an Asset Number? (or is it not > needed if System/AdditionalData/Platform used?) > **(b)** Add a Contact class? (is it needed if EventData/Contact is used?) > **(c)** Add some indication of the type of ownership (e.g., Corporate, > Partner, Personally-owned)? > **(d)** What specific location information is needed beyond > System/Location? >=20 > (10) What data elements should be added to Contact? > **(a)** Add a data element to represent a title (e.g., *Mr.* Smith, > *Captain* Johnson)? > **(b)** Should ContactName be split in into a given name and surname? (at > the Berlin IETF, Brian Trammell, the working group chair, voiced > **(c)** Add a data element to represent a Department? > **(d)** Add a data element to represent a network user id (e.g., > LOCALNET\john) >=20 > (11) What data elements should be added to Assessment? > **(a)** Add a summary of the impact to business/mission (add > Incident/Assessment/Description? Or some enumerated values to > qualitatively describe the impact?) > **(b)** Add a means to enumerate the intended purpose of attack (e.g., > theft-of-IP, degradation of service, fraud) >=20 > Regards, > Roman >=20 > [1] http://www.ietf.org/mail-archive/web/mile/current/msg01146.html > [2] http://www.ietf.org/mail-archive/web/mile/current/msg01147.html > [3] http://www.ietf.org/mail-archive/web/mile/current/msg01182.html > [4] http://www.ietf.org/proceedings/87/slides/slides-87-mile-4.pdf >=20 > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From rdd@cert.org Mon Oct 7 05:34:44 2013 Return-Path: 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 C5F9C21E8098 for ; Mon, 7 Oct 2013 05:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.354 X-Spam-Level: X-Spam-Status: No, score=-5.354 tagged_above=-999 required=5 tests=[AWL=0.244, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 qOJw9NTiig36 for ; Mon, 7 Oct 2013 05:34:39 -0700 (PDT) Received: from shetland.sei.cmu.edu (shetland.sei.cmu.edu [192.58.107.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5C40321E8088 for ; Mon, 7 Oct 2013 05:34:39 -0700 (PDT) Received: from timber.sei.cmu.edu (timber.sei.cmu.edu [10.64.21.23]) by shetland.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id r97CYb4A030794; Mon, 7 Oct 2013 08:34:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1381149277; bh=0YnsObm5cf+xaJORZzGvZ2TD0JMZeIg2NKn3ASxKqNY=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version:Sender:Reply-To; b=DuWldd9gbCFgpPkpyAM+Sdcw+DVqSHDt3bIhWcxkC1X8y7JO1hjiYOI/qGu1KhZkF 9JlN1+9GZKZhhWedTm81Y7Mu1fZNWpiTL6eWMk9v+HA4mxTcUMh02WY0iuOopEtAXD 0Oz+NaTuMwglf2fk9vkyRXHhviBTf0zltLrDrqaM= Received: from CASCADE.ad.sei.cmu.edu (cascade.sei.cmu.edu [10.64.28.248]) by timber.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id r97CYbnI030907; Mon, 7 Oct 2013 08:34:37 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.02.0347.000; Mon, 7 Oct 2013 08:34:36 -0400 From: "Roman D. Danyliw" To: John Field Thread-Topic: [mile] 5070-bis scoping discussion #4: workflow Thread-Index: Ac65L4FTheRXU+s7RuCEhEjkL1kREABzI1IAAhcYUZA= Date: Mon, 7 Oct 2013 12:34:35 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC54B8489D@marathon> References: <359EC4B99E040048A7131E0F4E113AFC54B67BA7@marathon> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: multipart/related; boundary="_004_359EC4B99E040048A7131E0F4E113AFC54B8489Dmarathon_"; type="multipart/alternative" MIME-Version: 1.0 Cc: "mile@ietf.org" Subject: Re: [mile] 5070-bis scoping discussion #4: workflow X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 12:34:44 -0000 --_004_359EC4B99E040048A7131E0F4E113AFC54B8489Dmarathon_ Content-Type: multipart/alternative; boundary="_000_359EC4B99E040048A7131E0F4E113AFC54B8489Dmarathon_" --_000_359EC4B99E040048A7131E0F4E113AFC54B8489Dmarathon_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello! > (13) How should document updates be sent? +1 on the suggestion by John Field to keep it simple and using only a "simp= le replace operation" for updates. Roman From: John Field [mailto:jfield@gopivotal.com] Sent: Thursday, September 26, 2013 1:05 PM To: Roman D. Danyliw Cc: mile@ietf.org Subject: Re: [mile] 5070-bis scoping discussion #4: workflow All, RE: number 13... >>(13) How should document updates be sent? Understanding of an event will= evolve over the course of an investigation. Is there a desire >> to support, change or provide additional guidance on how a sender should= transmit an update to a previously sent IODEF document? Update messages raise a number of interesting questions. Based on my exper= ience implementing this in a POC last year, I would suggest we keep it very= simple. The semantic for updating an IODEF document should be a simple re= place operation. If an endpoint receives a message for an IncidentID that = it has already seen before, then that message would completely supersede th= e prior one. Supporting partial updates to an IODEF message will greatly increase the co= mplexity (and cost of implementation, testing, and deployment, etc.) consid= erably, so I would avoid this if at all possible. Having said that, it's possible that incidents *may* require a partial upda= te, but indicators would definitely seem to have a more natural "replace" s= emantic. If there is a need for partial update, then the RecordData and RecordItem e= lements are perhaps the place to focus. As an incident unfolds, perhaps mo= re information becomes available....if one receives an update, and there ar= e some new RecordItem elements that did not appear in the original document= , then I should probably add these to the original incident, and retain the= earlier RecordItem elements. If we need to specify CRUD actions on a per= -RecordItem basis, i.e. delete a specified RecordItem from the earlier repo= rt (but retain other RecordItems) then that would likely require that we le= verage the "ext-dtype," "meaning," or "formatid" attributes of that elemen= t/type. This would enable a sender to add more RecordItems to an earlier r= eport, remove an incorrect RecordItem, or update an existing RecordItem in = an earlier report. However, all this logic is significantly increasing the complexity on the r= eceiving side. So, instead, I would suggest that the sender just send an I= ODEF message that contains all of the most current information and the late= st message completely supersedes the previous one. Let the sender and the = receiver (separately) deal with any issues of versioning history locally. Thanks, John P.S. (It's worth noting that none of this is unique to cyber security info= rmation. All message-based distributed systems face these same questions o= f how to deal with issues like dropped messages, duplicates, messages recei= ved out of order, semantics for updates or partial updates, etc.) The diff= iculty in ensuring that partial update changes have been synchronized in a = distributed system is one reason we have seen architectures evolve to more = RESTful approaches. The client may get the latest representation of the re= source (IODEF document) at any time simply by asking for it. The provider = does not try to take responsibility of ensuring that all peers that may hav= e received a prior representation of the resource are kept are up to date, = because that is a very expensive requirement to satisfy. On Tue, Sep 24, 2013 at 10:19 AM, Roman D. Danyliw > wrote: Hello! Per the announcement in [1], this note initiates topic discussion #4 on the= 5070bis scope. Please refer to discussion #1 [2], #2 [3], and #3 [4] in t= he archive. This is the last of the discussion threads. For those expecti= ng this call yesterday as was planned, sorry for the delay. Discussion #4 is intended to clarify what additional work to the data model= is required to support specific work-flows. The power-point formatted ver= sion of this text can be found in slides 10 of [4]. If you have a feelings= on the matter, please provide input by noon of October 8th. Opinions to a= dd something or explicitly avoid it are welcome. In the case of the former= , proposals are welcome but not required. (12) How should indicator matches be returned? There has been much discuss= on which indicators to represent. With the Expectation class and the Inci= dent@purpose the reason for sending the document is conveyed. Should speci= fic support be provided to convey that a particular indicator matched. If = so, how? (13) How should document updates be sent? Understanding of an event will e= volve over the course of an investigation. Is there a desire to support, c= hange or provide additional guidance on how a sender should transmit an upd= ate to a previously sent IODEF document? Regards, Roman [1] http://www.ietf.org/mail-archive/web/mile/current/msg01146.html [2] http://www.ietf.org/mail-archive/web/mile/current/msg01147.html [3] http://www.ietf.org/mail-archive/web/mile/current/msg01182.html [4] http://www.ietf.org/mail-archive/web/mile/current/msg01189.html [5] http://www.ietf.org/proceedings/87/slides/slides-87-mile-4.pdf _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile -- John P. Field | Security Architect | Pivotal Direct: (908) 962-3394 | jfield@gopivotal.com [cid:332B1A9B-BFB1-42CC-8C13-5949BB4B8266] goPivotal.com --_000_359EC4B99E040048A7131E0F4E113AFC54B8489Dmarathon_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello!<= /p>

 <= /p>

> (13) How should document updates be sent? 

 <= /p>

+1 on the suggestion = by John Field to keep it simple and using only a “simple replace oper= ation” for updates.

 <= /p>

Roman

 <= /p>

From: John Fie= ld [mailto:jfield@gopivotal.com]
Sent: Thursday, September 26, 2013 1:05 PM
To: Roman D. Danyliw
Cc: mile@ietf.org
Subject: Re: [mile] 5070-bis scoping discussion #4: workflow

 

All,

 

RE: number 13...

 

>>(13) How should document updates be sent?  Under= standing of an event will evolve over the course of an investigation. = Is there a desire

>> to support, change or provide additional guidance on= how a sender should transmit an update to a previously sent IODEF document= ?

 

Update messages raise a number = of interesting questions.  Based on my experience implementing th= is in a POC last year, I would suggest we keep it very simple.  The semantic for updating an IODEF document should be a simple replace operati= on.  If an endpoint receives a message for an IncidentID that it has a= lready seen before, then that message would completely supersede the prior = one.

 

Supporting partial updates to a= n IODEF message will greatly increase the complexity (and cost of implement= ation, testing, and deployment, etc.) considerably, so I would avoid this if at all possible.

 

Having said that, it's possible= that incidents *may* require a partial update, but indicators would defini= tely seem to have a more natural "replace" semantic.

 

If there is a need for partial = update, then the RecordData and RecordItem elements are perhaps the place t= o focus.  As an incident unfolds, perhaps more information becomes available….if one receives an update, and there are some new= RecordItem elements that did not appear in the original document, then I s= hould probably add these to the original incident, and retain the earlier R= ecordItem elements.   If we need to specify CRUD actions on a per-RecordItem basis, i.e. delete a specified RecordItem= from the earlier report (but retain other RecordItems) then that would lik= ely require that we leverage the “ext-dtype,” “meaning,&#= 8221; or “formatid”  attributes of that element/type. = ; This would enable a sender to add more RecordItems to an earlier report, remove= an incorrect RecordItem, or update an existing RecordItem in an earlier re= port.  

 

However, all this logic is sign= ificantly increasing the complexity on the receiving side.  So, instea= d, I would suggest that the sender just send an IODEF message that contains all of the most current information and the latest message c= ompletely supersedes the previous one.  Let the sender and the receive= r (separately) deal with any issues of versioning history locally.

 

Thanks,

John

 

P.S.  (It’s worth no= ting that none of this is unique to cyber security information.  All m= essage-based distributed systems face these same questions of how to deal with issues like dropped messages, duplicates, messages received out of or= der, semantics for updates or partial updates, etc.)  The difficulty i= n ensuring that partial update changes have been synchronized in a distribu= ted system is one reason we have seen architectures evolve to more RESTful approaches.  The client may get = the latest representation of the resource (IODEF document) at any time simp= ly by asking for it.  The provider does not try to take responsibility= of ensuring that all peers that may have received a prior representation of the resource are kept are up to date, b= ecause that is a very expensive requirement to satisfy.

 

 

 

On Tue, Sep 24, 2013 at 10:19 AM, Roman D. Danyliw &= lt;rdd@cert.org> w= rote:

Hello!

 

Per the announcement in [1], this note initiates topic discussion #4 on = the 5070bis scope.  Please refer to discussion #1 [2], #2 [3], and #3 = [4] in the archive.  This is the last of the discussion threads. = For those expecting this call yesterday as was planned, sorry for the delay.

 

Discussion #4 is intended to clarify what additional work to the data mo= del is required to support specific work-flows.  The power-point forma= tted version of this text can be found in slides 10 of [4].  If you ha= ve a feelings on the matter, please provide input by noon of October 8th.  Opinions to add something or explicitl= y avoid it are welcome.  In the case of the former, proposals are welc= ome but not required.

 

(12) How should indicator matches be returned?  There has been much= discuss on which indicators to represent.  With the Expectation class= and the Incident@purpose the reason for sending the document is conveyed.&= nbsp; Should specific support be provided to convey that a particular indicator matched.  If so, how?

 

(13) How should document updates be sent?  Understanding of an even= t will evolve over the course of an investigation.  Is there a desire = to support, change or provide additional guidance on how a sender should tr= ansmit an update to a previously sent IODEF document?

 

Regards,

Roman

 

[1] http://www.ietf.org/mail-archive/web/mile/current/msg01146.html

[2] http://www.ietf.org/mail-archive/web/mile/current/msg01147.html

[3] http://www.ietf.org/mail-archive/web/mile/current/msg01182.html

[4] http://www.ietf.org/mail-archive/web/mile/current/msg01189.html

[5] http://www.ietf.org/proceedings/87/slides/slides-87-mile-4.pdf

 


_______________________________________________
mile mailing list
mile@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mile



 

--

John P. Field | Security Architect | P= ivotal

Direct: (908) 962-3394 | jfield@gopivotal.= com 

3D"cid:332B1A9B-BFB1-=

goPivotal.com

--_000_359EC4B99E040048A7131E0F4E113AFC54B8489Dmarathon_-- --_004_359EC4B99E040048A7131E0F4E113AFC54B8489Dmarathon_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=2872; creation-date="Mon, 07 Oct 2013 12:34:35 GMT"; modification-date="Mon, 07 Oct 2013 12:34:35 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAFIAAAAaCAYAAAAkJwuaAAAEJGlDQ1BJQ0MgUHJvZmlsZQAAOBGF Vd9v21QUPolvUqQWPyBYR4eKxa9VU1u5GxqtxgZJk6XtShal6dgqJOQ6N4mpGwfb6baqT3uBNwb8 AUDZAw9IPCENBmJ72fbAtElThyqqSUh76MQPISbtBVXhu3ZiJ1PEXPX6yznfOec7517bRD1fabWa GVWIlquunc8klZOnFpSeTYrSs9RLA9Sr6U4tkcvNEi7BFffO6+EdigjL7ZHu/k72I796i9zRiSJP wG4VHX0Z+AxRzNRrtksUvwf7+Gm3BtzzHPDTNgQCqwKXfZwSeNHHJz1OIT8JjtAq6xWtCLwGPLzY Zi+3YV8DGMiT4VVuG7oiZpGzrZJhcs/hL49xtzH/Dy6bdfTsXYNY+5yluWO4D4neK/ZUvok/17X0 HPBLsF+vuUlhfwX4j/rSfAJ4H1H0qZJ9dN7nR19frRTeBt4Fe9FwpwtN+2p1MXscGLHR9SXrmMgj ONd1ZxKzpBeA71b4tNhj6JGoyFNp4GHgwUp9qplfmnFW5oTdy7NamcwCI49kv6fN5IAHgD+0rbyo Bc3SOjczohbyS1drbq6pQdqumllRC/0ymTtej8gpbbuVwpQfyw66dqEZyxZKxtHpJn+tZnpnEdrY BbueF9qQn93S7HQGGHnYP7w6L+YGHNtd1FJitqPAR+hERCNOFi1i1alKO6RQnjKUxL1GNjwlMsiE hcPLYTEiT9ISbN15OY/jx4SMshe9LaJRpTvHr3C/ybFYP1PZAfwfYrPsMBtnE6SwN9ib7AhLwTrB DgUKcm06FSrTfSj187xPdVQWOk5Q8vxAfSiIUc7Z7xr6zY/+hpqwSyv0I0/QMTRb7RMgBxNodTfS Pqdraz/sDjzKBrv4zu2+a2t0/HHzjd2Lbcc2sG7GtsL42K+xLfxtUgI7YHqKlqHK8HbCCXgjHT1c AdMlDetv4FnQ2lLasaOl6vmB0CMmwT/IPszSueHQqv6i/qluqF+oF9TfO2qEGTumJH0qfSv9KH0n fS/9TIp0Wboi/SRdlb6RLgU5u++9nyXYe69fYRPdil1o1WufNSdTTsp75BfllPy8/LI8G7AUuV8e k6fkvfDsCfbNDP0dvRh0CrNqTbV7LfEEGDQPJQadBtfGVMWEq3QWWdufk6ZSNsjG2PQjp3ZcnOWW ing6noonSInvi0/Ex+IzAreevPhe+CawpgP1/pMTMDo64G0sTCXIM+KdOnFWRfQKdJvQzV1+Bt8O okmrdtY2yhVX2a+qrykJfMq4Ml3VR4cVzTQVz+UoNne4vcKLoyS+gyKO6EHe+75Fdt0Mbe5bRIf/ wjvrVmhbqBN97RD1vxrahvBOfOYzoosH9bq94uejSOQGkVM6sN/7HelL4t10t9F4gPdVzydEOx83 Gv+uNxo7XyL/FtFl8z9ZAHF4bBsrEwAABs9JREFUaAXtWX1oFEcUf2/3voQW24ggBAQhIAj5SylY hELEIggVQa4QPcFWkygUi1CwtFSEglIptFSaxI8SEiNNEKTSP6SCIA0UpKIQGioECoIghF4UCt4l t/v6m5n9vL29XBobi83A7cy8ee/NzG/nfcweiwitlKUjkFEq+FCpg9hdnVBn8ZwMXp5M0CMEPlRs I85u0CRrfkYGxx9Ghl/KJh/et1lvjMmR86P3VVsDiedXxPauRrvmIweIRJ5ibIjmqV8ujTyI8dm5 nWRZo4Zm9aM+Ght/GTsZ+1e9LYPLa6pttbRP5tXEfIxy/DuAPd2SzAtk4t7ieu7r3sp9+zct1zLM iYzOJnIJxn5Hk9hdS8Lr0d9FTO0e2wnuOzAtA8PgQ7FkGif2vG6LTOj6BT74SOlbsgpH9BJcUdYx tRzLaQTkLRkcuRKdnIvFHLUVhgHmu5rOcgK1BlL6RxXoBvio0P+snQSyAQAyPj7H7xU/oFx+L0zc xgntUOajAosOVBnu0mJSm5LBKxN8sLiO8oV3AlUO3ZQLw38E/boGHz6wgWzaocmOc1cujN6tYyGt s5BdTw7N+Q6+nifRt3gbrMeJ0WuVq3JxvBylYS9wXZlNCBmdOCwbSMis1a09ILc2Wc8flfXbLQGp mOW78RksSgWdNi1sZdehfki2vAFwBzWNbRVsJiiXQRZAhqYGMnQGz49Vs2HJUA/o6pSj2NtNjddV LNr0ev44WfwRFQprzTDoKgCS3CJXPlwgq+jGOrp9fUY+9wvqAEju3Q+ewjfgM/tSTKw5sRTAgx/2 /Yik8mazjKS1YKN0K/MmCVOkGs5GWhH+C0N34TvnNItIw4wgFJe9XnuGnlZuq7Y+gW35ewDxC3QN iB6TqWAFzPe4r3Q8Rl5Ex/hTZBwBiPIM4rAGiWcmOj7kwr03mKPlE0lrCurNwqxRFEDW/LRuN3h4 prcFJ0elRXjj3KkiqAxcTjh+nIhOpE8dRo1chRsxL6hQ+B60Tk/9bZjYpzRbu0+v5tspI3ug8xR+ eLn0JcCckoGRGx5vWCHYwN8rK0kUuJMuyrAJSiqNYTko/ZevRRlxEn8GyNuitLR2UyC173CzHdho FxKlz4IzzzwmA+PKzJsXR8bIZmNaQspnJoCE3ogvdcaUQgCzAyC9pZULXEW5sj0AmEidljPcU5rC a/1B8zB/jjoJpB5MedgCED0bFgA+EAcxRSqVnGra2MyPSCOekEo+tXnxK1qLyCT9WTmaqjE68KR6 00vmsWarsXkLm0yA6DE9qU144jsDNQ6djIAYkOX8yHV0/KC0WbuCYLSFBrM5aUKP4GdjWUoL0gmW VCATnCTwe9JP1erb2JjygQsW8D3DyVIbRpGtiPwxX6ciP8aN+boRsyZC7uoVp5J+RRU3HMtk/TzX l0ytdRAjUsESL7jOH6ZKNR9IN22GqYiahJECyGNyqxOtpAGJ6VyYt8UlAGZTFukTUcRn5f3TCLIx a09+VaAnSyZgBYRIg/lZ0LMklAmIKY3XyViXGhYKdaSwt0JOBVL6R861omBBntnqDSTzZR0ZmZR5 h0AyG/8oSKNmayotWZ4yC/DWBFOpgLXksgjT/mdzGf8mJhoydcGs9MkxPk22Gq1yLeYHmcNAZkVO T2IJ+AbgF5Ny+b2mNeaaC313xI00lWo++K8D6U0/ZmpeRW05E3RyeZXCeOmUczW2TKEwtXKyXbEx r2P8HC4Dqog4xPOpNydPpL7yrrW8kXu7W0px6hVE+8sDZLl6C5PO6InZ2mNqL+2BWatrZXRRNC9X NDiKaNmn64OU5m3LfQL/3eHJXcetw5xioTAQMqX7TZEhT1bNcVFfdQPC4hupPnLxqtIllNniFoFT hwQYtxzu2Vci2zJ5Ikn8NEKN+uaJ9GsIzffhW9txb/+Ne0tn0b5PrrsOsrjzW17+iduIyMlwdgRH vzCdgp6NflfXNTorF0emaXZuDJeMHtCwDt5IWbmHNd5B8FFfs84tcPWMqVSd5TmRaiYsDj+YIPya bQ9j8avQh6+qfq2GE6VcPYpx/YUJY2t1Lsv8kyfrByncgWl3bNPlCtwIPu3pgtyXuSf2sx2d9mif 7FZ2g9dLz1SerK+dAFd9Olxc8U+kmtgkt8zlRakw/EbWlYdpsup6iJN4ELckfCDQQQKmrq5wjf+a 0AGB6BD81xC+3p+A3k2Qw5cZgM88SS7Ss9nKGfCFpgwm1Ud+uoU4dwyAtIPX/C3gLywSlDx3sFv7 SLbhbwVffyzktY4X7HT6Z9yDE0m1QqyCuXnlzy8f4aXVy2faS1vnf156Bcjn9IpWgFwB8jkh8JzU /A3WyVI+PC3NMwAAAABJRU5ErkJggg== --_004_359EC4B99E040048A7131E0F4E113AFC54B8489Dmarathon_-- From rdd@cert.org Mon Oct 7 05:37:54 2013 Return-Path: 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 5B98C21E81E9 for ; Mon, 7 Oct 2013 05:37:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[AWL=0.622, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 H5UFiAQNvXuy for ; Mon, 7 Oct 2013 05:37:49 -0700 (PDT) Received: from shetland.sei.cmu.edu (shetland.sei.cmu.edu [192.58.107.44]) by ietfa.amsl.com (Postfix) with ESMTP id 32A9721E8098 for ; Mon, 7 Oct 2013 05:37:49 -0700 (PDT) Received: from timber.sei.cmu.edu (timber.sei.cmu.edu [10.64.21.23]) by shetland.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id r97CbmvR030853 for ; Mon, 7 Oct 2013 08:37:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1381149468; bh=VM8ID+JYI0xF7iKRL8y1GBfzKB6xUOShiMza2H1LL3I=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version:Sender: Reply-To:Cc:In-Reply-To:References; b=C7/fzC883rPKrcv2rul7zwYcasKrdZ6eKaWR65pOKvK8cvEdrA4QUcWWlXcOF6QuH VEhFSGuXX+/6fJ0eaAVpjOCJpyKmJn/8TYMtRZ9QG61zayYs5XLR0rqMrkk5hSsSVb dZMt9RUgZ81L+5wa5lAyyW79yx1sCBNbL+lZQKuc= Received: from CASSINA.ad.sei.cmu.edu (cassina.sei.cmu.edu [10.64.28.249]) by timber.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id r97CbmKD031774 for ; Mon, 7 Oct 2013 08:37:48 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.02.0347.000; Mon, 7 Oct 2013 08:37:48 -0400 From: "Roman D. Danyliw" To: "mile@ietf.org" Thread-Topic: Discussion #4 reminder (was: RE: 5070-bis scoping discussion #4: workflow) Thread-Index: Ac7DWalNov3r7JIETT+Hsum79q6pGA== Date: Mon, 7 Oct 2013 12:37:47 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC54B848F1@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: multipart/alternative; boundary="_000_359EC4B99E040048A7131E0F4E113AFC54B848F1marathon_" MIME-Version: 1.0 Subject: [mile] Discussion #4 reminder (was: RE: 5070-bis scoping discussion #4: workflow) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 12:37:54 -0000 --_000_359EC4B99E040048A7131E0F4E113AFC54B848F1marathon_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello! I wanted to send out a reminder to provide comments on the last 5070bis dis= cussion by noon tomorrow (October 8th). The items being discussed are belo= w. Please check the email archive for the latest comments. Roman From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Rom= an D. Danyliw Sent: Tuesday, September 24, 2013 10:20 AM To: mile@ietf.org Subject: [mile] 5070-bis scoping discussion #4: workflow Hello! Per the announcement in [1], this note initiates topic discussion #4 on the= 5070bis scope. Please refer to discussion #1 [2], #2 [3], and #3 [4] in t= he archive. This is the last of the discussion threads. For those expecti= ng this call yesterday as was planned, sorry for the delay. Discussion #4 is intended to clarify what additional work to the data model= is required to support specific work-flows. The power-point formatted ver= sion of this text can be found in slides 10 of [4]. If you have a feelings= on the matter, please provide input by noon of October 8th. Opinions to a= dd something or explicitly avoid it are welcome. In the case of the former= , proposals are welcome but not required. (12) How should indicator matches be returned? There has been much discuss= on which indicators to represent. With the Expectation class and the Inci= dent@purpose the reason for sending the document is conveyed. Should speci= fic support be provided to convey that a particular indicator matched. If = so, how? (13) How should document updates be sent? Understanding of an event will e= volve over the course of an investigation. Is there a desire to support, c= hange or provide additional guidance on how a sender should transmit an upd= ate to a previously sent IODEF document? Regards, Roman [1] http://www.ietf.org/mail-archive/web/mile/current/msg01146.html [2] http://www.ietf.org/mail-archive/web/mile/current/msg01147.html [3] http://www.ietf.org/mail-archive/web/mile/current/msg01182.html [4] http://www.ietf.org/mail-archive/web/mile/current/msg01189.html [5] http://www.ietf.org/proceedings/87/slides/slides-87-mile-4.pdf --_000_359EC4B99E040048A7131E0F4E113AFC54B848F1marathon_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello!

 

I wanted to send out a= reminder to provide comments on the last 5070bis discussion by noon tomorr= ow (October 8th).  The items being discussed are below.&nbs= p; Please check the email archive for the latest comments.

 

Roman

 

From: mile-bou= nces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Roman D. Danyliw
Sent: Tuesday, September 24, 2013 10:20 AM
To: mile@ietf.org
Subject: [mile] 5070-bis scoping discussion #4: workflow<= /span>

 

Hello!

 

Per the announcement in [1], this note initiates = topic discussion #4 on the 5070bis scope.  Please refer to discussion = #1 [2], #2 [3], and #3 [4] in the archive.  This is the last of the di= scussion threads.  For those expecting this call yesterday as was planned, sorry for the delay.

 

Discussion #4 is intended to clarify what additio= nal work to the data model is required to support specific work-flows. = ; The power-point formatted version of this text can be found in slides 10 = of [4].  If you have a feelings on the matter, please provide input by noon of October 8th.  Opinions to add= something or explicitly avoid it are welcome.  In the case of the for= mer, proposals are welcome but not required.

 

(12) How should indicator matches be returned?&nb= sp; There has been much discuss on which indicators to represent.  Wit= h the Expectation class and the Incident@purpose the reason for sending the= document is conveyed.  Should specific support be provided to convey that a particular indicator matched.  If so, ho= w?

 

(13) How should document updates be sent?  U= nderstanding of an event will evolve over the course of an investigation.&n= bsp; Is there a desire to support, change or provide additional guidance on= how a sender should transmit an update to a previously sent IODEF document?

 

Regards,

Roman

 

[1] http://www.ietf.org/mail-archive/web/mile/current/msg01146.html

[2] http://www.ietf.org/mail-archive/web/mile/current/msg01147.html

[3] http://www.ietf.org/mail-archive/web/mile/current/msg01182.html

[4] http://www.ietf.org/mail-archive/web/mile/current/msg01189.html

[5] http://www.ietf.org/proceedings/87/slides/slides-87-mile-4.pdf

 

--_000_359EC4B99E040048A7131E0F4E113AFC54B848F1marathon_-- From rdd@cert.org Tue Oct 8 12:41:30 2013 Return-Path: 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 688C921F9C60 for ; Tue, 8 Oct 2013 12:41:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.183 X-Spam-Level: X-Spam-Status: No, score=-6.183 tagged_above=-999 required=5 tests=[AWL=0.415, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 89mHkovLJw-Z for ; Tue, 8 Oct 2013 12:41:26 -0700 (PDT) Received: from shetland.sei.cmu.edu (shetland.sei.cmu.edu [192.58.107.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8D54321F9C28 for ; Tue, 8 Oct 2013 12:41:15 -0700 (PDT) Received: from timber.sei.cmu.edu (timber.sei.cmu.edu [10.64.21.23]) by shetland.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id r98JfE46004333 for ; Tue, 8 Oct 2013 15:41:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1381261274; bh=e9Zt1rC7AEFkMX9AcI5kocwbc3y2yB2ktS8tXwVj5DE=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version:Sender: Reply-To:Cc:In-Reply-To:References; b=R1fK7+lLqI+tAu5cFWem4F2TfJrEtZvSoavG7BJABcx+TY3/9JkwFwFo4tHNiRx7e NdDut5vwEe00BCoqpRARkaa7BqVtfvtU669uQ4aXY1ph05mtaiA90sWhx8tKZWL0sg cWz9TvFTRk7wmUxHWkhQ5GpW9QTzquJUN4c4eTes= Received: from CASSINA.ad.sei.cmu.edu (cassina.sei.cmu.edu [10.64.28.249]) by timber.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id r98JfEDw022070 for ; Tue, 8 Oct 2013 15:41:14 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.02.0347.000; Tue, 8 Oct 2013 15:41:13 -0400 From: "Roman D. Danyliw" To: "mile@ietf.org" Thread-Topic: Discussion #4 closed (was: RE: 5070-bis scoping discussion #4: workflow) Thread-Index: Ac7EUA+0qncVXgO+RuSyBUjVYx8ySQ== Date: Tue, 8 Oct 2013 19:41:13 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC54B872E0@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: multipart/alternative; boundary="_000_359EC4B99E040048A7131E0F4E113AFC54B872E0marathon_" MIME-Version: 1.0 Subject: [mile] Discussion #4 closed (was: RE: 5070-bis scoping discussion #4: workflow) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 19:41:30 -0000 --_000_359EC4B99E040048A7131E0F4E113AFC54B872E0marathon_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello! Thank you for your feedback on discussion #4. Per the timing announced in = the original announcement, discussions are closed. A summary write-up of t= he results will be forthcoming. Roman From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Rom= an D. Danyliw Sent: Monday, October 07, 2013 8:38 AM To: mile@ietf.org Subject: [mile] Discussion #4 reminder (was: RE: 5070-bis scoping discussio= n #4: workflow) Hello! I wanted to send out a reminder to provide comments on the last 5070bis dis= cussion by noon tomorrow (October 8th). The items being discussed are belo= w. Please check the email archive for the latest comments. Roman From: mile-bounces@ietf.org [mailto:mile-boun= ces@ietf.org] On Behalf Of Roman D. Danyliw Sent: Tuesday, September 24, 2013 10:20 AM To: mile@ietf.org Subject: [mile] 5070-bis scoping discussion #4: workflow Hello! Per the announcement in [1], this note initiates topic discussion #4 on the= 5070bis scope. Please refer to discussion #1 [2], #2 [3], and #3 [4] in t= he archive. This is the last of the discussion threads. For those expecti= ng this call yesterday as was planned, sorry for the delay. Discussion #4 is intended to clarify what additional work to the data model= is required to support specific work-flows. The power-point formatted ver= sion of this text can be found in slides 10 of [4]. If you have a feelings= on the matter, please provide input by noon of October 8th. Opinions to a= dd something or explicitly avoid it are welcome. In the case of the former= , proposals are welcome but not required. (12) How should indicator matches be returned? There has been much discuss= on which indicators to represent. With the Expectation class and the Inci= dent@purpose the reason for sending the document is conveyed. Should speci= fic support be provided to convey that a particular indicator matched. If = so, how? (13) How should document updates be sent? Understanding of an event will e= volve over the course of an investigation. Is there a desire to support, c= hange or provide additional guidance on how a sender should transmit an upd= ate to a previously sent IODEF document? Regards, Roman [1] http://www.ietf.org/mail-archive/web/mile/current/msg01146.html [2] http://www.ietf.org/mail-archive/web/mile/current/msg01147.html [3] http://www.ietf.org/mail-archive/web/mile/current/msg01182.html [4] http://www.ietf.org/mail-archive/web/mile/current/msg01189.html [5] http://www.ietf.org/proceedings/87/slides/slides-87-mile-4.pdf --_000_359EC4B99E040048A7131E0F4E113AFC54B872E0marathon_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello!

 

Thank you for your fee= dback on discussion #4.  Per the timing announced in the original anno= uncement, discussions are closed.  A summary write-up of the results w= ill be forthcoming.

 

Roman

 

From: mile-bou= nces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Roman D. Danyliw
Sent: Monday, October 07, 2013 8:38 AM
To: mile@ietf.org
Subject: [mile] Discussion #4 reminder (was: RE: 5070-bis scoping di= scussion #4: workflow)

 

Hello!

 

I wanted to send out a= reminder to provide comments on the last 5070bis discussion by noon tomorr= ow (October 8th).  The items being discussed are below.&nbs= p; Please check the email archive for the latest comments.

 

Roman

 

From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Roman D. Danyliw
Sent: Tuesday, September 24, 2013 10:20 AM
To: mile@ietf.org
Subject: [mile] 5070-bis scoping discussion #4: workflow<= /span>

 

Hello!

 

Per the announcement in [1], this note initiates = topic discussion #4 on the 5070bis scope.  Please refer to discussion = #1 [2], #2 [3], and #3 [4] in the archive.  This is the last of the di= scussion threads.  For those expecting this call yesterday as was planned, sorry for the delay.

 

Discussion #4 is intended to clarify what additio= nal work to the data model is required to support specific work-flows. = ; The power-point formatted version of this text can be found in slides 10 = of [4].  If you have a feelings on the matter, please provide input by noon of October 8th.  Opinions to add= something or explicitly avoid it are welcome.  In the case of the for= mer, proposals are welcome but not required.

 

(12) How should indicator matches be returned?&nb= sp; There has been much discuss on which indicators to represent.  Wit= h the Expectation class and the Incident@purpose the reason for sending the= document is conveyed.  Should specific support be provided to convey that a particular indicator matched.  If so, ho= w?

 

(13) How should document updates be sent?  U= nderstanding of an event will evolve over the course of an investigation.&n= bsp; Is there a desire to support, change or provide additional guidance on= how a sender should transmit an update to a previously sent IODEF document?

 

Regards,

Roman

 

[1] http://www.ietf.org/mail-archive/web/mile/current/msg01146.html

[2] http://www.ietf.org/mail-archive/web/mile/current/msg01147.html

[3] http://www.ietf.org/mail-archive/web/mile/current/msg01182.html

[4] http://www.ietf.org/mail-archive/web/mile/current/msg01189.html

[5] http://www.ietf.org/proceedings/87/slides/slides-87-mile-4.pdf

 

--_000_359EC4B99E040048A7131E0F4E113AFC54B872E0marathon_-- From iesg-secretary@ietf.org Tue Oct 8 16:18:16 2013 Return-Path: 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 38B3111E810F; Tue, 8 Oct 2013 16:18:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.365 X-Spam-Level: X-Spam-Status: No, score=-102.365 tagged_above=-999 required=5 tests=[AWL=0.235, BAYES_00=-2.599, NO_RELAYS=-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 bUdoAnFmfthT; Tue, 8 Oct 2013 16:18:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BB5021F98EE; Tue, 8 Oct 2013 16:18:15 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20131008231815.28645.87543.idtracker@ietfa.amsl.com> Date: Tue, 08 Oct 2013 16:18:15 -0700 Cc: mile@ietf.org Subject: [mile] Last Call: (IODEF-extension for structured cybersecurity information) to Proposed Standard X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Reply-To: ietf@ietf.org List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 23:18:16 -0000 The IESG has received a request from the Managed Incident Lightweight Exchange WG (mile) to consider the following document: - 'IODEF-extension for structured cybersecurity information' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-10-22. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document extends the Incident Object Description Exchange Format (IODEF) defined in RFC 5070 [RFC5070] to exchange enriched cybersecurity information among cybersecurity entities and facilitate their operations. It provides the capability of embedding structured information, such as identifier- and XML-based information. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mile-sci/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mile-sci/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1786/ http://datatracker.ietf.org/ipr/1787/ From Paul.Stoecker@rsa.com Tue Oct 8 18:18:39 2013 Return-Path: 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 2BD6F11E8102 for ; Tue, 8 Oct 2013 18:18:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.598 X-Spam-Level: X-Spam-Status: No, score=-1.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001] 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 WcFaJOZLeOxP for ; Tue, 8 Oct 2013 18:18:23 -0700 (PDT) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) by ietfa.amsl.com (Postfix) with ESMTP id C163B21F99DD for ; Tue, 8 Oct 2013 18:18:22 -0700 (PDT) Received: from maildlpprd52.lss.emc.com (maildlpprd52.lss.emc.com [10.106.48.156]) by mailuogwprd51.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id r991IHs4013002 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Oct 2013 21:18:17 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com r991IHs4013002 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=rsa.com; s=jan2013; t=1381281497; bh=R2CV8A/JVD56v2pGr2Jtv7rUpO4=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Reply-To:Content-Type:MIME-Version; b=bxHyUtt5rnHpxoIbkjjaBqq4WXaDFrozWM39Hjh/9H4tvuI63ELbc5f3M7hxQmsPF 3I/T0YrfMpm5xhjjX2YGD5l6+ErS+1bJeVsrzLE204nMZnQCXD1SKxAIqg89OEcfVD Ll2RDY52hSPHPlfeqs1xvLLaPeP0nM/rWr2dYcAc= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com r991IHs4013002 Received: from mailusrhubprd02.lss.emc.com (mailusrhubprd02.lss.emc.com [10.253.24.20]) by maildlpprd52.lss.emc.com (RSA Interceptor); Tue, 8 Oct 2013 21:18:10 -0400 Received: from mxhub16.corp.emc.com (mxhub16.corp.emc.com [128.222.70.237]) by mailusrhubprd02.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id r991I91B000558 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 8 Oct 2013 21:18:09 -0400 Received: from MXHUB108.corp.emc.com (10.253.58.24) by mxhub16.corp.emc.com (128.222.70.237) with Microsoft SMTP Server (TLS) id 8.3.297.1; Tue, 8 Oct 2013 21:18:08 -0400 Received: from MX103CL01.corp.emc.com ([169.254.5.122]) by MXHUB108.corp.emc.com ([10.253.58.24]) with mapi id 14.02.0342.003; Tue, 8 Oct 2013 21:18:09 -0400 From: "Stoecker, Paul" To: "Field, John (Pivotal)" , "rdd@cert.org" Thread-Topic: [mile] 5070-bis scoping discussion #4: workflow Thread-Index: Ac65L4FTheRXU+s7RuCEhEjkL1kREABzI1IAAmRWxu0= Date: Wed, 9 Oct 2013 01:18:08 +0000 Message-ID: References: <359EC4B99E040048A7131E0F4E113AFC54B67BA7@marathon>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Content-Type: multipart/related; boundary="_004_mdpieo40w9t2pwop0ish8seb1381281484146emailandroidcom_"; type="multipart/alternative" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd02.lss.emc.com X-EMM-GWVC: 1 X-EMM-McAfeeVC: 1 X-RSA-Classifications: DLM_1, public Cc: "mile@ietf.org" Subject: Re: [mile] 5070-bis scoping discussion #4: workflow X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "Stoecker, Paul" List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 01:18:39 -0000 --_004_mdpieo40w9t2pwop0ish8seb1381281484146emailandroidcom_ Content-Type: multipart/alternative; boundary="_000_mdpieo40w9t2pwop0ish8seb1381281484146emailandroidcom_" --_000_mdpieo40w9t2pwop0ish8seb1381281484146emailandroidcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable +1. Lets keep things simple ;-) Sent from my Verizon Wireless 4G LTE Smartphone -------- Original message -------- From: John Field Date: 09/26/2013 1:07 PM (GMT-05:00) To: "Roman D. Danyliw" Cc: mile@ietf.org Subject: Re: [mile] 5070-bis scoping discussion #4: workflow All, RE: number 13... >>(13) How should document updates be sent? Understanding of an event will= evolve over the course of an investigation. Is there a desire >> to support, change or provide additional guidance on how a sender should= transmit an update to a previously sent IODEF document? Update messages raise a number of interesting questions. Based on my exper= ience implementing this in a POC last year, I would suggest we keep it very= simple. The semantic for updating an IODEF document should be a simple re= place operation. If an endpoint receives a message for an IncidentID that = it has already seen before, then that message would completely supersede th= e prior one. Supporting partial updates to an IODEF message will greatly increase the co= mplexity (and cost of implementation, testing, and deployment, etc.) consid= erably, so I would avoid this if at all possible. Having said that, it's possible that incidents *may* require a partial upda= te, but indicators would definitely seem to have a more natural "replace" s= emantic. If there is a need for partial update, then the RecordData and RecordItem e= lements are perhaps the place to focus. As an incident unfolds, perhaps mo= re information becomes available=85.if one receives an update, and there ar= e some new RecordItem elements that did not appear in the original document= , then I should probably add these to the original incident, and retain the= earlier RecordItem elements. If we need to specify CRUD actions on a per= -RecordItem basis, i.e. delete a specified RecordItem from the earlier repo= rt (but retain other RecordItems) then that would likely require that we le= verage the =93ext-dtype,=94 =93meaning,=94 or =93formatid=94 attributes of= that element/type. This would enable a sender to add more RecordItems to = an earlier report, remove an incorrect RecordItem, or update an existing Re= cordItem in an earlier report. However, all this logic is significantly increasing the complexity on the r= eceiving side. So, instead, I would suggest that the sender just send an I= ODEF message that contains all of the most current information and the late= st message completely supersedes the previous one. Let the sender and the = receiver (separately) deal with any issues of versioning history locally. Thanks, John P.S. (It=92s worth noting that none of this is unique to cyber security in= formation. All message-based distributed systems face these same questions= of how to deal with issues like dropped messages, duplicates, messages rec= eived out of order, semantics for updates or partial updates, etc.) The di= fficulty in ensuring that partial update changes have been synchronized in = a distributed system is one reason we have seen architectures evolve to mor= e RESTful approaches. The client may get the latest representation of the = resource (IODEF document) at any time simply by asking for it. The provide= r does not try to take responsibility of ensuring that all peers that may h= ave received a prior representation of the resource are kept are up to date= , because that is a very expensive requirement to satisfy. On Tue, Sep 24, 2013 at 10:19 AM, Roman D. Danyliw > wrote: Hello! Per the announcement in [1], this note initiates topic discussion #4 on the= 5070bis scope. Please refer to discussion #1 [2], #2 [3], and #3 [4] in t= he archive. This is the last of the discussion threads. For those expecti= ng this call yesterday as was planned, sorry for the delay. Discussion #4 is intended to clarify what additional work to the data model= is required to support specific work-flows. The power-point formatted ver= sion of this text can be found in slides 10 of [4]. If you have a feelings= on the matter, please provide input by noon of October 8th. Opinions to a= dd something or explicitly avoid it are welcome. In the case of the former= , proposals are welcome but not required. (12) How should indicator matches be returned? There has been much discuss= on which indicators to represent. With the Expectation class and the Inci= dent@purpose the reason for sending the document is conveyed. Should speci= fic support be provided to convey that a particular indicator matched. If = so, how? (13) How should document updates be sent? Understanding of an event will e= volve over the course of an investigation. Is there a desire to support, c= hange or provide additional guidance on how a sender should transmit an upd= ate to a previously sent IODEF document? Regards, Roman [1] http://www.ietf.org/mail-archive/web/mile/current/msg01146.html [2] http://www.ietf.org/mail-archive/web/mile/current/msg01147.html [3] http://www.ietf.org/mail-archive/web/mile/current/msg01182.html [4] http://www.ietf.org/mail-archive/web/mile/current/msg01189.html [5] http://www.ietf.org/proceedings/87/slides/slides-87-mile-4.pdf _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile -- John P. Field | Security Architect | Pivotal Direct: (908) 962-3394 | jfield@gopivotal.com [cid:332B1A9B-BFB1-42CC-8C13-5949BB4B8266] goPivotal.com --_000_mdpieo40w9t2pwop0ish8seb1381281484146emailandroidcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
+1. Lets keep things simple ;-)


Sent from my Verizon Wireless 4= G LTE Smartphone



-------- Original message --------
From: John Field <jfield@gopivotal.com>
Date: 09/26/2013 1:07 PM (GMT-05:00)
To: "Roman D. Danyliw" <rdd@cert.org>
Cc: mile@ietf.org
Subject: Re: [mile] 5070-bis scoping discussion #4: workflow


All,


RE: number 13...


>>(13) How = should document updates be sent?  Understanding of an event will evolv= e over the course of an investigation.  Is there a desire

>> to suppo= rt, change or provide additional guidance on how a sender should transmit a= n update to a previously sent IODEF document?


Update messages raise a numb= er of interesting questions.  Based on my experience implementing= this in a POC last year, I would suggest we keep it very simple.  The= semantic for updating an IODEF document should be a simple replace operation.  If an endpoint receives a message for an= IncidentID that it has already seen before, then that message would comple= tely supersede the prior one.


Supporting partial updates t= o an IODEF message will greatly increase the complexity (and cost of implem= entation, testing, and deployment, etc.) considerably, so I would avoid thi= s if at all possible.


Having said that, it's possi= ble that incidents *may* require a partial update, but indicators would def= initely seem to have a more natural "replace" semantic.


If there is a need for parti= al update, then the RecordData and RecordItem elements are perhaps the plac= e to focus.  As an incident unfolds, perhaps more information becomes = available=85.if one receives an update, and there are some new RecordItem elements that did not appear in the original= document, then I should probably add these to the original incident, and r= etain the earlier RecordItem elements.   If we need to specify CR= UD actions on a per-RecordItem basis, i.e. delete a specified RecordItem from the earlier report (but retain other Re= cordItems) then that would likely require that we leverage the =93ext-dtype= ,=94 =93meaning,=94 or =93formatid=94  attributes of that element/type= .  This would enable a sender to add more RecordItems to an earlier report, remove an incorrect RecordItem, or update an existin= g RecordItem in an earlier report.  


However, all this logic is s= ignificantly increasing the complexity on the receiving side.  So, ins= tead, I would suggest that the sender just send an IODEF message that conta= ins all of the most current information and the latest message completely supersedes the previous one.  Let t= he sender and the receiver (separately) deal with any issues of versioning = history locally.


Thanks,

John


P.S.  (It=92s worth not= ing that none of this is unique to cyber security information.  All me= ssage-based distributed systems face these same questions of how to deal wi= th issues like dropped messages, duplicates, messages received out of order, semantics for updates or partial updates, etc.)&nbs= p; The difficulty in ensuring that partial update changes have been synchro= nized in a distributed system is one reason we have seen architectures evol= ve to more RESTful approaches.  The client may get the latest representation of the resource (IODEF document) at any = time simply by asking for it.  The provider does not try to take respo= nsibility of ensuring that all peers that may have received a prior represe= ntation of the resource are kept are up to date, because that is a very expensive requirement to satisfy.


 



On Tue, Sep 24, 2013 at 10:19 AM, Roman D. Danyl= iw <rdd@cert.org><= /span> wrote:

Hello!

 

Per the announcement in [1], this note initiates topic discussion #4 on = the 5070bis scope.  Please refer to discussion #1 [2], #2 [3], and #3 = [4] in the archive.  This is the last of the discussion threads. = For those expecting this call yesterday as was planned, sorry for the delay.

 

Discussion #4 is intended to clarify what additional work to the data mo= del is required to support specific work-flows.  The power-point forma= tted version of this text can be found in slides 10 of [4].  If you ha= ve a feelings on the matter, please provide input by noon of October 8th.  Opinions to add something or explicitl= y avoid it are welcome.  In the case of the former, proposals are welc= ome but not required.

 

(12) How should indicator matches be returned?  There has been much= discuss on which indicators to represent.  With the Expectation class= and the Incident@purpose the reason for sending the document is conveyed.&= nbsp; Should specific support be provided to convey that a particular indicator matched.  If so, how?

 

(13) How should document updates be sent?  Understanding of an even= t will evolve over the course of an investigation.  Is there a desire = to support, change or provide additional guidance on how a sender should tr= ansmit an update to a previously sent IODEF document?

 

Regards,

Roman

 

[1] http://www.ietf.org/mail-archive/web/mile/current/msg01146.html<= u>

[2] http://www.ietf.org/mail-archive/web/mile/current/msg01147.html<= u>

[3] http://www.ietf.org/mail-archive/web/mile/current/msg01182.html<= u>

[4] http://www.ietf.org/mail-archive/web/mile/current/msg01189.html<= u>

[5] http://www.ietf.org/proceedings/87/slides/slides-87-mile-4.pdf

 


_______________________________________________
mile mailing list
mile@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mile




--

John P. Field | Security Architect | Pivotal

Direct: (908) 962-3394 | jfield@gopivotal.= com 

3D"ci=<= /b>

goPivotal.com
--_000_mdpieo40w9t2pwop0ish8seb1381281484146emailandroidcom_-- --_004_mdpieo40w9t2pwop0ish8seb1381281484146emailandroidcom_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=2872; creation-date="Thu, 26 Sep 2013 17:07:05 GMT"; modification-date="Thu, 26 Sep 2013 17:07:05 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAFIAAAAaCAYAAAAkJwuaAAAEJGlDQ1BJQ0MgUHJvZmlsZQAAOBGF Vd9v21QUPolvUqQWPyBYR4eKxa9VU1u5GxqtxgZJk6XtShal6dgqJOQ6N4mpGwfb6baqT3uBNwb8 AUDZAw9IPCENBmJ72fbAtElThyqqSUh76MQPISbtBVXhu3ZiJ1PEXPX6yznfOec7517bRD1fabWa GVWIlquunc8klZOnFpSeTYrSs9RLA9Sr6U4tkcvNEi7BFffO6+EdigjL7ZHu/k72I796i9zRiSJP wG4VHX0Z+AxRzNRrtksUvwf7+Gm3BtzzHPDTNgQCqwKXfZwSeNHHJz1OIT8JjtAq6xWtCLwGPLzY Zi+3YV8DGMiT4VVuG7oiZpGzrZJhcs/hL49xtzH/Dy6bdfTsXYNY+5yluWO4D4neK/ZUvok/17X0 HPBLsF+vuUlhfwX4j/rSfAJ4H1H0qZJ9dN7nR19frRTeBt4Fe9FwpwtN+2p1MXscGLHR9SXrmMgj ONd1ZxKzpBeA71b4tNhj6JGoyFNp4GHgwUp9qplfmnFW5oTdy7NamcwCI49kv6fN5IAHgD+0rbyo Bc3SOjczohbyS1drbq6pQdqumllRC/0ymTtej8gpbbuVwpQfyw66dqEZyxZKxtHpJn+tZnpnEdrY BbueF9qQn93S7HQGGHnYP7w6L+YGHNtd1FJitqPAR+hERCNOFi1i1alKO6RQnjKUxL1GNjwlMsiE hcPLYTEiT9ISbN15OY/jx4SMshe9LaJRpTvHr3C/ybFYP1PZAfwfYrPsMBtnE6SwN9ib7AhLwTrB DgUKcm06FSrTfSj187xPdVQWOk5Q8vxAfSiIUc7Z7xr6zY/+hpqwSyv0I0/QMTRb7RMgBxNodTfS Pqdraz/sDjzKBrv4zu2+a2t0/HHzjd2Lbcc2sG7GtsL42K+xLfxtUgI7YHqKlqHK8HbCCXgjHT1c AdMlDetv4FnQ2lLasaOl6vmB0CMmwT/IPszSueHQqv6i/qluqF+oF9TfO2qEGTumJH0qfSv9KH0n fS/9TIp0Wboi/SRdlb6RLgU5u++9nyXYe69fYRPdil1o1WufNSdTTsp75BfllPy8/LI8G7AUuV8e k6fkvfDsCfbNDP0dvRh0CrNqTbV7LfEEGDQPJQadBtfGVMWEq3QWWdufk6ZSNsjG2PQjp3ZcnOWW ing6noonSInvi0/Ex+IzAreevPhe+CawpgP1/pMTMDo64G0sTCXIM+KdOnFWRfQKdJvQzV1+Bt8O okmrdtY2yhVX2a+qrykJfMq4Ml3VR4cVzTQVz+UoNne4vcKLoyS+gyKO6EHe+75Fdt0Mbe5bRIf/ wjvrVmhbqBN97RD1vxrahvBOfOYzoosH9bq94uejSOQGkVM6sN/7HelL4t10t9F4gPdVzydEOx83 Gv+uNxo7XyL/FtFl8z9ZAHF4bBsrEwAABs9JREFUaAXtWX1oFEcUf2/3voQW24ggBAQhIAj5SylY hELEIggVQa4QPcFWkygUi1CwtFSEglIptFSaxI8SEiNNEKTSP6SCIA0UpKIQGioECoIghF4UCt4l t/v6m5n9vL29XBobi83A7cy8ee/NzG/nfcweiwitlKUjkFEq+FCpg9hdnVBn8ZwMXp5M0CMEPlRs I85u0CRrfkYGxx9Ghl/KJh/et1lvjMmR86P3VVsDiedXxPauRrvmIweIRJ5ibIjmqV8ujTyI8dm5 nWRZo4Zm9aM+Ght/GTsZ+1e9LYPLa6pttbRP5tXEfIxy/DuAPd2SzAtk4t7ieu7r3sp9+zct1zLM iYzOJnIJxn5Hk9hdS8Lr0d9FTO0e2wnuOzAtA8PgQ7FkGif2vG6LTOj6BT74SOlbsgpH9BJcUdYx tRzLaQTkLRkcuRKdnIvFHLUVhgHmu5rOcgK1BlL6RxXoBvio0P+snQSyAQAyPj7H7xU/oFx+L0zc xgntUOajAosOVBnu0mJSm5LBKxN8sLiO8oV3AlUO3ZQLw38E/boGHz6wgWzaocmOc1cujN6tYyGt s5BdTw7N+Q6+nifRt3gbrMeJ0WuVq3JxvBylYS9wXZlNCBmdOCwbSMis1a09ILc2Wc8flfXbLQGp mOW78RksSgWdNi1sZdehfki2vAFwBzWNbRVsJiiXQRZAhqYGMnQGz49Vs2HJUA/o6pSj2NtNjddV LNr0ev44WfwRFQprzTDoKgCS3CJXPlwgq+jGOrp9fUY+9wvqAEju3Q+ewjfgM/tSTKw5sRTAgx/2 /Yik8mazjKS1YKN0K/MmCVOkGs5GWhH+C0N34TvnNItIw4wgFJe9XnuGnlZuq7Y+gW35ewDxC3QN iB6TqWAFzPe4r3Q8Rl5Ex/hTZBwBiPIM4rAGiWcmOj7kwr03mKPlE0lrCurNwqxRFEDW/LRuN3h4 prcFJ0elRXjj3KkiqAxcTjh+nIhOpE8dRo1chRsxL6hQ+B60Tk/9bZjYpzRbu0+v5tspI3ug8xR+ eLn0JcCckoGRGx5vWCHYwN8rK0kUuJMuyrAJSiqNYTko/ZevRRlxEn8GyNuitLR2UyC173CzHdho FxKlz4IzzzwmA+PKzJsXR8bIZmNaQspnJoCE3ogvdcaUQgCzAyC9pZULXEW5sj0AmEidljPcU5rC a/1B8zB/jjoJpB5MedgCED0bFgA+EAcxRSqVnGra2MyPSCOekEo+tXnxK1qLyCT9WTmaqjE68KR6 00vmsWarsXkLm0yA6DE9qU144jsDNQ6djIAYkOX8yHV0/KC0WbuCYLSFBrM5aUKP4GdjWUoL0gmW VCATnCTwe9JP1erb2JjygQsW8D3DyVIbRpGtiPwxX6ciP8aN+boRsyZC7uoVp5J+RRU3HMtk/TzX l0ytdRAjUsESL7jOH6ZKNR9IN22GqYiahJECyGNyqxOtpAGJ6VyYt8UlAGZTFukTUcRn5f3TCLIx a09+VaAnSyZgBYRIg/lZ0LMklAmIKY3XyViXGhYKdaSwt0JOBVL6R861omBBntnqDSTzZR0ZmZR5 h0AyG/8oSKNmayotWZ4yC/DWBFOpgLXksgjT/mdzGf8mJhoydcGs9MkxPk22Gq1yLeYHmcNAZkVO T2IJ+AbgF5Ny+b2mNeaaC313xI00lWo++K8D6U0/ZmpeRW05E3RyeZXCeOmUczW2TKEwtXKyXbEx r2P8HC4Dqog4xPOpNydPpL7yrrW8kXu7W0px6hVE+8sDZLl6C5PO6InZ2mNqL+2BWatrZXRRNC9X NDiKaNmn64OU5m3LfQL/3eHJXcetw5xioTAQMqX7TZEhT1bNcVFfdQPC4hupPnLxqtIllNniFoFT hwQYtxzu2Vci2zJ5Ikn8NEKN+uaJ9GsIzffhW9txb/+Ne0tn0b5PrrsOsrjzW17+iduIyMlwdgRH vzCdgp6NflfXNTorF0emaXZuDJeMHtCwDt5IWbmHNd5B8FFfs84tcPWMqVSd5TmRaiYsDj+YIPya bQ9j8avQh6+qfq2GE6VcPYpx/YUJY2t1Lsv8kyfrByncgWl3bNPlCtwIPu3pgtyXuSf2sx2d9mif 7FZ2g9dLz1SerK+dAFd9Olxc8U+kmtgkt8zlRakw/EbWlYdpsup6iJN4ELckfCDQQQKmrq5wjf+a 0AGB6BD81xC+3p+A3k2Qw5cZgM88SS7Ss9nKGfCFpgwm1Ud+uoU4dwyAtIPX/C3gLywSlDx3sFv7 SLbhbwVffyzktY4X7HT6Z9yDE0m1QqyCuXnlzy8f4aXVy2faS1vnf156Bcjn9IpWgFwB8jkh8JzU /A3WyVI+PC3NMwAAAABJRU5ErkJggg== --_004_mdpieo40w9t2pwop0ish8seb1381281484146emailandroidcom_-- From kathleen.moriarty@emc.com Mon Oct 14 13:17:31 2013 Return-Path: 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 3660821E80E2 for ; Mon, 14 Oct 2013 13:17:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 CsgR2bufxNtd for ; Mon, 14 Oct 2013 13:17:27 -0700 (PDT) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 3CC2D21E8105 for ; Mon, 14 Oct 2013 13:17:26 -0700 (PDT) Received: from maildlpprd02.lss.emc.com (maildlpprd02.lss.emc.com [10.253.24.34]) by mailuogwprd03.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id r9EKHPmg026595 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 14 Oct 2013 16:17:25 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com r9EKHPmg026595 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1381781846; bh=EogoTotMW/wK2DwZlS9xIiV2lQo=; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; b=IsH+339m291YQYkmx3sS+vVZ6++71Xo60xs2T9nuqOMps9FLpwIvvvnychtb9AYxs xDEYFezRIlaBxisr+B3IOtt6rYtk8OTuNfVLnx6IxSkfakt4vN1SVtBcO4PUbr38Zm gcNHHqG0rFSmtTyFHFPpM1nCBiWETJVW4GcxNCZw= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com r9EKHPmg026595 Received: from mailusrhubprd53.lss.emc.com (mailusrhubprd53.lss.emc.com [10.106.48.18]) by maildlpprd02.lss.emc.com (RSA Interceptor) for ; Mon, 14 Oct 2013 16:17:14 -0400 Received: from mxhub19.corp.emc.com (mxhub19.corp.emc.com [10.254.93.48]) by mailusrhubprd53.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id r9EKHDHP018544 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 14 Oct 2013 16:17:14 -0400 Received: from mx15a.corp.emc.com ([169.254.1.46]) by mxhub19.corp.emc.com ([10.254.93.48]) with mapi; Mon, 14 Oct 2013 16:17:13 -0400 From: "Moriarty, Kathleen" To: "mile@ietf.org" Date: Mon, 14 Oct 2013 16:17:12 -0400 Thread-Topic: MILE Wiki - Informational page Thread-Index: Ac7JGfR97cZ4ZixyRDmlgMPEoC14nA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F5063677821E3B4F81ACFB7905573F24049E8BC813MX15Acorpemcc_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd53.lss.emc.com X-EMM-GWVC: 1 X-RSA-Classifications: public X-EMM-McAfeeVC: 1 Subject: [mile] MILE Wiki - Informational page X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 20:17:31 -0000 --_000_F5063677821E3B4F81ACFB7905573F24049E8BC813MX15Acorpemcc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, At the workshop in Berlin, we received some requests for an overview of the= work in MILE. The goal was to make it easier for people to get up-to-spee= d and either participate in the working group or to use the working group R= FCs and draft materials. If there is additional information that you think= should be covered in the wiki, please let us know. These efforts are all = volunteer driven, and assistance is appreciated. http://trac.tools.ietf.org/wg/mile/trac/wiki/WikiStart# The overview video was also part of the effort to provide the background ma= terials. Best regards, Kathleen --_000_F5063677821E3B4F81ACFB7905573F24049E8BC813MX15Acorpemcc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

At the = workshop in Berlin, we received some requests for an overview of the work i= n MILE.  The goal was to make it easier for people to get up-to-speed = and either participate in the working group or to use the working group RFC= s and draft materials.  If there is additional information that you th= ink should be covered in the wiki, please let us know.  These efforts = are all volunteer driven, and assistance is appreciated.

 

http://trac.tools.ietf.= org/wg/mile/trac/wiki/WikiStart#

 

The overview video was also part of = the effort to provide the background materials. 

 

Best regards,=

Kathleen

=  

= --_000_F5063677821E3B4F81ACFB7905573F24049E8BC813MX15Acorpemcc_-- From pkampana@cisco.com Tue Oct 15 12:09:41 2013 Return-Path: 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 EDEBB11E8163 for ; Tue, 15 Oct 2013 12:09:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 2f+Xkj+T7Aw3 for ; Tue, 15 Oct 2013 12:09:35 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 2C3EE11E8152 for ; Tue, 15 Oct 2013 12:09:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5173; q=dns/txt; s=iport; t=1381864172; x=1383073772; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=P5lmcsdd5xYXu53Sl5YfTONnBj0efbON7+XMpzcAjoE=; b=X7aUSPfTvm/jdwRXau9H/xaZWR3/hCgjISQnVwBL1M0QlFwJR42gZ61N 6s54yM+V5J7fIr6ggVXTrw50xo3d4Qv3es05BjJdDWGUyoqHQsqRfVS0v fP8ziqpt5+h3GQegVw2xx69DS6XUMk79/jaASguqzRxsGmAPaGL4R+PTr k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuwFAOaRXVKtJV2Z/2dsb2JhbABagkNEOFK5X4hLgSMWdIIlAQEBBC1cAgEIEQQBAQsdBzIUCQgBAQQBEgiHfgy9box/gho3AYMfgQYDmTOQU4Mkgik X-IronPort-AV: E=Sophos;i="4.93,501,1378857600"; d="scan'208,217";a="272435357" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP; 15 Oct 2013 19:09:29 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r9FJ9SjJ023947 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 15 Oct 2013 19:09:28 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.33]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Tue, 15 Oct 2013 14:09:28 -0500 From: "Panos Kampanakis (pkampana)" To: "Moriarty, Kathleen" , "mile@ietf.org" Thread-Topic: MILE Wiki - Informational page Thread-Index: Ac7JGfR97cZ4ZixyRDmlgMPEoC14nAAwBQxw Date: Tue, 15 Oct 2013 19:09:27 +0000 Message-ID: <1C9F17D1873AFA47A969C4DD98F98A750B82E315@xmb-rcd-x10.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.89.126] Content-Type: multipart/alternative; boundary="_000_1C9F17D1873AFA47A969C4DD98F98A750B82E315xmbrcdx10ciscoc_" MIME-Version: 1.0 Subject: Re: [mile] MILE Wiki - Informational page X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 19:09:41 -0000 --_000_1C9F17D1873AFA47A969C4DD98F98A750B82E315xmbrcdx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thank you, this is a pretty good summary. From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Mor= iarty, Kathleen Sent: Monday, October 14, 2013 4:17 PM To: mile@ietf.org Subject: [mile] MILE Wiki - Informational page Hello, At the workshop in Berlin, we received some requests for an overview of the= work in MILE. The goal was to make it easier for people to get up-to-spee= d and either participate in the working group or to use the working group R= FCs and draft materials. If there is additional information that you think= should be covered in the wiki, please let us know. These efforts are all = volunteer driven, and assistance is appreciated. http://trac.tools.ietf.org/wg/mile/trac/wiki/WikiStart# The overview video was also part of the effort to provide the background ma= terials. Best regards, Kathleen --_000_1C9F17D1873AFA47A969C4DD98F98A750B82E315xmbrcdx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thank you, this is a p= retty good summary.

 

 

From: mile-bou= nces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Moriarty, Kathleen
Sent: Monday, October 14, 2013 4:17 PM
To: mile@ietf.org
Subject: [mile] MILE Wiki - Informational page

 

Hello,

 

At the workshop in Berlin, we received some requests= for an overview of the work in MILE.  The goal was to make it easier = for people to get up-to-speed and either participate in the working group o= r to use the working group RFCs and draft materials.  If there is additional information that you think should = be covered in the wiki, please let us know.  These efforts are all vol= unteer driven, and assistance is appreciated.

 

http://trac.tools.ietf.org/wg/mile/trac/wiki/WikiStart#<= o:p>

 

The overview video was also part of the effort to pr= ovide the background materials. 

 

Best regards,

Kathleen

 

--_000_1C9F17D1873AFA47A969C4DD98F98A750B82E315xmbrcdx10ciscoc_-- From chatlga2000@yahoo.com Tue Oct 15 13:59:09 2013 Return-Path: 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 73FE821F9A1C for ; Tue, 15 Oct 2013 13:59:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, REPTO_QUOTE_YAHOO=2.599] 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 OwyKSKKcWuo7 for ; Tue, 15 Oct 2013 13:59:04 -0700 (PDT) Received: from nm6.bullet.mail.bf1.yahoo.com (nm6.bullet.mail.bf1.yahoo.com [98.139.212.165]) by ietfa.amsl.com (Postfix) with ESMTP id B39B521F9D0E for ; Tue, 15 Oct 2013 13:59:03 -0700 (PDT) Received: from [66.196.81.170] by nm6.bullet.mail.bf1.yahoo.com with NNFMP; 15 Oct 2013 20:59:02 -0000 Received: from [98.139.212.192] by tm16.bullet.mail.bf1.yahoo.com with NNFMP; 15 Oct 2013 20:59:02 -0000 Received: from [127.0.0.1] by omp1001.mail.bf1.yahoo.com with NNFMP; 15 Oct 2013 20:59:02 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 637782.95423.bm@omp1001.mail.bf1.yahoo.com Received: (qmail 94044 invoked by uid 60001); 15 Oct 2013 20:59:02 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1381870742; bh=I3R1sOYm7uNyEsvkS6Dyv3+5TqputxuEK39oQVicMzo=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=2NbcT+2HztC+weiRgfAsje+Hi9r+3CHzYtWtm6+rldUaiEAo9+gbWLweXWYYhPK3qgj9waAe2Su1OJW1cMOtACbPBAs6X9J31q2vSY4lDSYipBHguBtGcZ5Oa5dHBW7y1RV0ag5anrAhgsoYxF3vLgP9cKSbDKXcI4QJFKn+Xsk= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=gGTZXFcnVwTejihO+NPUIx1Pu87kGdfWTPGFbWeONVuf0OHpbHyZoqKQuvWFINUamG/vLNJUSYmT4CK4/5rofssn3sI9nmnWOQublyC9xBP+AI0LB1csB1O1Hwzam3HW7q1ThmLVT/c57dvES8GkdCMHaXytc/vPyPrWEUDYB8c=; X-YMail-OSG: PU0JfzUVM1kuYiwb.xzRlfpig5cI9cWo3aRpejutxEZywpc BazcBwiNEhXB97DnwIvZpb1qMsXFfAchPij_JWs6Sz9hPiPTNET71HD5nRaQ JqQHtJt_xhW6NyBScOOQSeW4B_LgDWXZsxuNXZlD.Xx28AVb8Y0NzVTdt9pX 5bgUwNG894mKYOHECP9qa2S3VL.hcn_Oiefwn77M3rP_AMZMePWwgOhnYD2t zv6qEUsRX_S4erpSK08h_4U1_SatBD00zqZMzUwu3xt7urvxNdcvZr5rP2A3 nEk7iVgBl1FBK3YwKbWJ60orCOhevOZ8oLJqz3KePwytLyjAUMRKykRt1Kc1 lVUAphPOM97L2kEmpoaVS2n.arJrkMxpVcR6AYTByYwGCy8u71pg8a4c.is1 chnOW0ouKOMVWpe.cokxSnpoLSIGT9lfCjMYvjZ3oLInPfyQfle9EElmZOFO NSZK5SbfbxBsReVV96YRpsL7SVRAp7iEgjH5qnlNJU7KY00YBLd7yYOqtwpL _zriYT.tJ.HtbL6m9MrbCkJTViEau6FaF_ANy2yxWcQntT6GlIgeJVUquMde trEX3ClevQzzggxsWtAccKr3BAxqoyakYd3ImWGBPi2SE Received: from [184.77.47.142] by web121604.mail.ne1.yahoo.com via HTTP; Tue, 15 Oct 2013 13:59:01 PDT X-Rocket-MIMEInfo: 002.001, VGhhbmtzIEthdGhsZWVuLgoKwqAKQy4gSGVucnkgQWRhbXMKCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KIEZyb206ICJtaWxlLXJlcXVlc3RAaWV0Zi5vcmciIDxtaWxlLXJlcXVlc3RAaWV0Zi5vcmc.ClRvOiBtaWxlQGlldGYub3JnIApTZW50OiBUdWVzZGF5LCBPY3RvYmVyIDE1LCAyMDEzIDM6MDAgUE0KU3ViamVjdDogbWlsZSBEaWdlc3QsIFZvbCAzMCwgSXNzdWUgNQogCgotLS0tLSBGb3J3YXJkZWQgTWVzc2FnZSAtLS0tLQoKSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBkaWdlc3QBMAEBAQE- X-Mailer: YahooMailWebService/0.8.160.587 References: Message-ID: <1381870741.82994.YahooMailNeo@web121604.mail.ne1.yahoo.com> Date: Tue, 15 Oct 2013 13:59:01 -0700 (PDT) From: "C. Henry Adams & BIE" To: "mile@ietf.org" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-36511695-1559845803-1381870741=:82994" Subject: Re: [mile] mile Digest, Vol 30, Issue 5 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "C. Henry Adams & BIE" List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 20:59:09 -0000 ---36511695-1559845803-1381870741=:82994 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Thanks Kathleen.=0A=0A=A0=0AC. Henry Adams=0A=0A=0A=0A_____________________= ___________=0A From: "mile-request@ietf.org" =0ATo: = mile@ietf.org =0ASent: Tuesday, October 15, 2013 3:00 PM=0ASubject: mile Di= gest, Vol 30, Issue 5=0A =0A=0A----- Forwarded Message -----=0A=0AIf you ha= ve received this digest without all the individual message=0Aattachments yo= u will need to update your digest options in your list=0Asubscription.=A0 T= o do so, go to =0A=0Ahttps://www.ietf.org/mailman/listinfo/mile=0A=0AClick = the 'Unsubscribe or edit options' button, log in, and set "Get=0AMIME or Pl= ain Text Digests?" to MIME.=A0 You can set this option=0Aglobally for all t= he list digests you receive at this point.=0A=0A=0A=0ASend mile mailing lis= t submissions to=0A=A0=A0=A0 mile@ietf.org=0A=0ATo subscribe or unsubscribe= via the World Wide Web, visit=0A=A0=A0=A0 https://www.ietf.org/mailman/lis= tinfo/mile=0Aor, via email, send a message with subject or body 'help' to= =0A=A0=A0=A0 mile-request@ietf.org=0A=0AYou can reach the person managing t= he list at=0A=A0=A0=A0 mile-owner@ietf.org=0A=0AWhen replying, please edit = your Subject line so it is more specific=0Athan "Re: Contents of mile diges= t..."=0A=0AToday's Topics:=0A=0A=A0 1. MILE Wiki - Informational page (Mor= iarty, Kathleen)=0A=0AHello,=0A=A0=0AAt the workshop in Berlin, we received= some requests for an overview of the work in MILE.=A0 The goal was to make= it easier for people to get up-to-speed and either participate in the work= ing group or to use the working group RFCs and draft materials.=A0 If there= is additional information that you think should be covered in the wiki, pl= ease let us know.=A0 These efforts are all volunteer driven, and assistance= is appreciated.=0A=A0=0Ahttp://trac.tools.ietf.org/wg/mile/trac/wiki/WikiS= tart#=0A=A0=0AThe overview video was also part of the effort to provide the= background materials.=A0 =0A=A0=0ABest regards,=0AKathleen=0A=A0=0A_______= ________________________________________=0Amile mailing list=0Amile@ietf.or= g=0Ahttps://www.ietf.org/mailman/listinfo/mile ---36511695-1559845803-1381870741=:82994 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks Kathleen.
 
C. Henry Adams

From: "mile-request@ietf.org" <mi= le-request@ietf.org>
To: mile@ietf.org
Sent:= Tuesday, October 15, 2013 3:00 PM
Subject: mile Digest, Vol 30, Issue 5
<= div class=3D"y_msg_container">
----- Forwarded Message -----

If y= ou have received this digest without all the individual message
attachme= nts you will need to update your digest options in your list
subscription.  To do so= , go to

https://www.ietf.org/mailman/listinfo/mile

Click t= he 'Unsubscribe or edit options' button, log in, and set "Get
MIME or Pl= ain Text Digests?" to MIME.  You can set this option
globally for a= ll the list digests you receive at this point.



Send mile mai= ling list submissions to
    mile@ietf.org

To subscribe= or unsubscribe via the World Wide Web, visit
    https://w= ww.ietf.org/mailman/listinfo/mile
or, via email, send a message with= subject or body 'help' to
    mile-request@ietf.org

You= can reach the person managing the list at
    mile-ow= ner@ietf.org

When replying, please edit your Subject line so it = is more specific
than "Re: Contents of mile digest..."

Today's To= pics:

  1. MILE Wiki - Informational page (Moriarty, Kathleen)=
Hello,
 
At the workshop in Berlin, we received some requests for an= overview of the work in MILE.  The goal was to make it easier for peo= ple to get up-to-speed and either participate in the working group or to us= e the working group RFCs and draft materials.  If there is additional = information that you think should be covered in the wiki, please let us kno= w.  These efforts are all volunteer driven, and assistance is apprecia= ted.
 
http://trac.tools.ietf.= org/wg/mile/trac/wiki/WikiStart#
 
The overview video was also part of the effort to provide the background mater= ials. 
 
Best regards,
Kathleen
 

_______________________________________________mile mailing list
mile@ietf.org
https://www.ietf.org/mailman/listinfo/mile=


---36511695-1559845803-1381870741=:82994-- From trammell@tik.ee.ethz.ch Tue Oct 15 23:16:59 2013 Return-Path: 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 4076711E810C for ; Tue, 15 Oct 2013 23:16:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 0Zm9tI-OudcV for ; Tue, 15 Oct 2013 23:16:54 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 947CA11E8249 for ; Tue, 15 Oct 2013 23:16:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 161B0D9302 for ; Wed, 16 Oct 2013 08:16:48 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 7NXWERVfwqMR for ; Wed, 16 Oct 2013 08:16:47 +0200 (MEST) Received: from [10.0.27.100] (cust-integra-122-165.antanet.ch [80.75.122.165]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id CDAD9D9300 for ; Wed, 16 Oct 2013 08:16:47 +0200 (MEST) From: Brian Trammell Content-Type: multipart/signed; boundary="Apple-Mail=_E44F19AF-5DDE-4A7E-8EAD-ED124BB39D77"; protocol="application/pgp-signature"; micalg=pgp-sha512 Message-Id: Date: Wed, 16 Oct 2013 08:16:47 +0200 To: MILE IETF Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Subject: [mile] 5070-bis scope discussion 3 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 06:16:59 -0000 --Apple-Mail=_E44F19AF-5DDE-4A7E-8EAD-ED124BB39D77 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Greetings, all, Thanks again to Roman for organizing the discussion on next steps in = 5070bis.=20 Having reviewed the discussion to date on the mailing list, there = appears to be consensus from the first three discussion points to = address (at least) the following issues in trac: http://trac.tools.ietf.org/wg/mile/trac/ticket/15 : describe missing = attributes and classes in text http://trac.tools.ietf.org/wg/mile/trac/ticket/22 : define classes and = attributes for actors and tactics http://trac.tools.ietf.org/wg/mile/trac/ticket/23 : define extension = point for arbitraty system info http://trac.tools.ietf.org/wg/mile/trac/ticket/25 : new enum values for = HashInformation type attr for certs http://trac.tools.ietf.org/wg/mile/trac/ticket/26 : add a class for = arbitrary application headers http://trac.tools.ietf.org/wg/mile/trac/ticket/27 : add a class to = contain (externally defined) signatures http://trac.tools.ietf.org/wg/mile/trac/ticket/28 : describe time window = of indicator validity http://trac.tools.ietf.org/wg/mile/trac/ticket/30 : add indicator-uid = attribute to DomainData class http://trac.tools.ietf.org/wg/mile/trac/ticket/32 : add predefined = courses of action http://trac.tools.ietf.org/wg/mile/trac/ticket/33 : add Asset Identifier = to System http://trac.tools.ietf.org/wg/mile/trac/ticket/34 : add type of = ownership to System http://trac.tools.ietf.org/wg/mile/trac/ticket/35 : add title to Contact http://trac.tools.ietf.org/wg/mile/trac/ticket/36 : add business impact = summary to Assessment=20 http://trac.tools.ietf.org/wg/mile/trac/ticket/37 : add intended purpose = of attack to Assessment The discussion continues. Best regards, Brian (as chair) --Apple-Mail=_E44F19AF-5DDE-4A7E-8EAD-ED124BB39D77 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSXi9PAAoJENt3nsOmbNJcc94H/iq+Vf+5OWwzv0pFizj/RL/e OVM/uvcmfyxBsORy8RPfN6DDdu4F2hrw4gNqI/33JyUtIkcgGzgFcNx32bersbDC j9YaNjtyqfyYv6bh43ChBNuBO9WEgDE1zyQvIx0Xc2Ii1CVBPFKEWoYggcSvXEV+ 2+AtF6/6SQbolBGDt0i2MmnLWEn8BFwW9vnixIQLs3bD0trRR5gjM7plmd0dLftM fmvxzx1vKFgU5h++NLqxvm3JDg+ivIAysrmqbR9e17HX7EY+7f4IxQ4zGOOr5nnN xEstPugGXvJlPfM4acszZRf21mYC0Qfp3aDrk7ue3qvsz3wUNyFobp45p7j0qiM= =vjns -----END PGP SIGNATURE----- --Apple-Mail=_E44F19AF-5DDE-4A7E-8EAD-ED124BB39D77-- From rdd@cert.org Fri Oct 18 10:02:55 2013 Return-Path: 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 23BCD11E8302 for ; Fri, 18 Oct 2013 10:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.287 X-Spam-Level: X-Spam-Status: No, score=-6.287 tagged_above=-999 required=5 tests=[AWL=0.312, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 u4JxAJZfNVoo for ; Fri, 18 Oct 2013 10:02:49 -0700 (PDT) Received: from shetland.sei.cmu.edu (shetland.sei.cmu.edu [192.58.107.44]) by ietfa.amsl.com (Postfix) with ESMTP id 20B5111E82E7 for ; Fri, 18 Oct 2013 10:02:46 -0700 (PDT) Received: from pawpaw.sei.cmu.edu (pawpaw.sei.cmu.edu [10.64.21.22]) by shetland.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id r9IH2i26004808 for ; Fri, 18 Oct 2013 13:02:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1382115765; bh=7StSEzPi7C6bo18P8dMilUC2Jkd/ZwfIHh6U1jNWlwo=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version:Sender:Reply-To:Cc: In-Reply-To:References; b=KveVKGXlM8ltzirkh1lKTdyUsvE+jpeutXC2PdLgihIIf5EdVoOWctsZudEjGagAI ntp1s6umv9ErwUWZusUiPblBPmA7XxoE0Q1pHfys+OSaexRAcDra5AXiK+UF8LOXRX P9KCSpwnKtV1Ffz8fQzlFNcyzJ02FyfgdPMhQ900= Received: from CASCADE.ad.sei.cmu.edu (cascade.sei.cmu.edu [10.64.28.248]) by pawpaw.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id r9IH2v3i007136 for ; Fri, 18 Oct 2013 13:02:57 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.02.0347.000; Fri, 18 Oct 2013 13:02:44 -0400 From: "Roman D. Danyliw" To: "mile@ietf.org" Thread-Topic: Details on ReportID Thread-Index: Ac7MI9z+YM180Lq7RKqO+8EBfVlpbg== Date: Fri, 18 Oct 2013 17:02:44 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC54B9DA3D@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [mile] Details on ReportID X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 17:02:55 -0000 Hello! Per issue #15 (http://trac.tools.ietf.org/wg/mile/trac/ticket/15), there ar= e a few changes in the schema not described in the text, discussed on the m= ailing list, or in a presentation at a meeting. I was hoping to get insigh= t into Incident/ReportID. This text is currently in the -01 schema: --[snip]-- --[ snip ]-- TXML comment suggests the ReportID is motivated by a use case where only in= dicators are shared. >From the name alone, I don't want to jump to any conclusions. A few questi= ons: ** When does one use a ReportID instead of an IncidentID (the schema sugges= ts they're mutually exclusive)? ** Are there any advantages or disadvantages in supporting both at the same= time? ** Is a ReportID a unique identifier for a given IODEF-Document? IODEF-Doc= ument/Incident? ** In discussion #4, there was talk of providing document updates. Does a = ReportID change when an update is provided?** Is there a format for the Rep= ortID? ** What does it mean when an Incident/AlternativeID is included and no Inci= dent/IncidentID provided? Roman From internet-drafts@ietf.org Fri Oct 18 11:49:55 2013 Return-Path: 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 F393111E82E9; Fri, 18 Oct 2013 11:49:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, NO_RELAYS=-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 1pS1l+7GwjL1; Fri, 18 Oct 2013 11:49:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 656C611E8322; Fri, 18 Oct 2013 11:49:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131018184942.4087.12333.idtracker@ietfa.amsl.com> Date: Fri, 18 Oct 2013 11:49:42 -0700 Cc: mile@ietf.org Subject: [mile] I-D Action: draft-ietf-mile-iodef-guidance-02.txt X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 18:49:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Managed Incident Lightweight Exchange Wor= king Group of the IETF. Title : IODEF Usage Guidance Author(s) : Panos Kampanakis Filename : draft-ietf-mile-iodef-guidance-02.txt Pages : 19 Date : 2013-10-18 Abstract: The Incident Object Description Exchange Format [RFC5070] defines a data representation that provides a framework for sharing information commonly exchanged by Computer Security Incident Response Teams (CSIRTs) about computer security incidents. Since the IODEF model includes a wealth of available options that can be used to describe a security incident or issue, it can be challenging for implementers to develop tools that can Leverage IODEF for incident sharing. This document provides guidelines for IODEF implementers. It will also address how common security indicators can be represented in IODEF. The goal of this document is to make IODEF's adoption by vendors easier and encourage faster and wider adoption of the model by Computer Security Incident Response Teams (CSIRTs) around the world. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mile-iodef-guidance There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mile-iodef-guidance-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mile-iodef-guidance-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Paul.Stoecker@rsa.com Fri Oct 18 12:28:31 2013 Return-Path: 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 3554D11E814C for ; Fri, 18 Oct 2013 12:28:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.389 X-Spam-Level: * X-Spam-Status: No, score=1.389 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_STOCK2=3.988] 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 cnL9pJHKQXVb for ; Fri, 18 Oct 2013 12:28:27 -0700 (PDT) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 9228611E8266 for ; Fri, 18 Oct 2013 12:28:25 -0700 (PDT) Received: from maildlpprd01.lss.emc.com (maildlpprd01.lss.emc.com [10.253.24.33]) by mailuogwprd03.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id r9IJSKsH023687 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Oct 2013 15:28:21 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com r9IJSKsH023687 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=rsa.com; s=jan2013; t=1382124501; bh=X6gKxZqJx6n0fx38ngLduXQcoBg=; h=From:To:Subject:Date:Message-ID:In-Reply-To:Content-Type: Content-ID:Content-Transfer-Encoding:MIME-Version; b=NUV8gzpoFGuyiCCckJkrU7FunjudPI0fLcvkL+fEdrgPsrWXt5uq4bsMq8ucwA2qw pS1b7J0Xyf58boDzMWdVH0zlgOdcbCbfIcCQC6W72YShy6NJ/i5rFxCxqyDHDbQeU4 +TqOLjfDlI4GOICmIfOZHtvlf3sWTDPsYmol0baQ= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com r9IJSKsH023687 Received: from mailusrhubprd54.lss.emc.com (mailusrhubprd54.lss.emc.com [10.106.48.19]) by maildlpprd01.lss.emc.com (RSA Interceptor); Fri, 18 Oct 2013 15:28:04 -0400 Received: from mxhub19.corp.emc.com (mxhub19.corp.emc.com [10.254.93.48]) by mailusrhubprd54.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id r9IJS3Tw022991 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 18 Oct 2013 15:28:03 -0400 Received: from MXHUB108.corp.emc.com (10.253.58.24) by mxhub19.corp.emc.com (10.254.93.48) with Microsoft SMTP Server (TLS) id 8.3.297.1; Fri, 18 Oct 2013 15:28:03 -0400 Received: from MX103CL01.corp.emc.com ([169.254.5.19]) by MXHUB108.corp.emc.com ([10.253.58.24]) with mapi id 14.03.0158.001; Fri, 18 Oct 2013 15:28:03 -0400 From: "Stoecker, Paul" To: "Roman D. Danyliw" , "mile@ietf.org" Thread-Topic: [mile] Details on ReportID Thread-Index: Ac7MI9z+YM180Lq7RKqO+8EBfVlpbgAFEuCA Date: Fri, 18 Oct 2013 19:28:02 +0000 Message-ID: In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC54B9DA3D@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [10.96.46.168] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd54.lss.emc.com X-RSA-Classifications: public Subject: Re: [mile] Details on ReportID X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 19:28:31 -0000 It almost seems like you would use it because you don't necessarily like the term IncidentID. That is all you want to do is to share some IOCs or a watch list and it isn't in any way related to an Incident, so you call it a Report. I would stick with one term. There is an incidentID and it can be just information that you want to share that is related to Incidents. I say we keep it simple. Paul W. Stoecker, Ph.D. Security Analytics Product Management Team RSA, The Security Division of EMC cell: 302.379.3375 | e: paul.stoecker@rsa.com On 10/18/13 1:02 PM, "Roman D. Danyliw" wrote: >Hello! > >Per issue #15 (http://trac.tools.ietf.org/wg/mile/trac/ticket/15), there >are a few changes in the schema not described in the text, discussed on >the mailing list, or in a presentation at a meeting. I was hoping to get >insight into Incident/ReportID. This text is currently in the -01 schema: > >--[snip]-- > > > > > > > > >--[ snip ]-- > >TXML comment suggests the ReportID is motivated by a use case where only >indicators are shared. >From the name alone, I don't want to jump to any conclusions. A few >questions: > >** When does one use a ReportID instead of an IncidentID (the schema >suggests they're mutually exclusive)? >** Are there any advantages or disadvantages in supporting both at the >same time? >** Is a ReportID a unique identifier for a given IODEF-Document? >IODEF-Document/Incident? >** In discussion #4, there was talk of providing document updates. Does >a ReportID change when an update is provided?** Is there a format for the >ReportID? >** What does it mean when an Incident/AlternativeID is included and no >Incident/IncidentID provided? > >Roman > >_______________________________________________ >mile mailing list >mile@ietf.org >https://www.ietf.org/mailman/listinfo/mile > From pkampana@cisco.com Fri Oct 18 12:55:52 2013 Return-Path: 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 B2D5D11E8319 for ; Fri, 18 Oct 2013 12:55:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 35KhQApScvtI for ; Fri, 18 Oct 2013 12:55:38 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 5759211E82B9 for ; Fri, 18 Oct 2013 12:55:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2624; q=dns/txt; s=iport; t=1382126137; x=1383335737; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=oxG2dVy4CMx6toLw8tq6YFTxBbtJ5hevw1i4aDGcL7M=; b=TIVMn684b9uuljHPiAVw5Y1VHFluK45gW8OxPWJ9fiDQtqMP/cvIRfp2 hE7FLltBxD8uTsgvM//MN1RagS1uNxdWmjcX5IthGiDjRZ8pezzZfWq/C vesSoXDtlnpVaXpmKllScB7HyTfHXsgfDKIPZ3JaqJfQshJKa7WlczRtU w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4FAGuRYVKtJXG//2dsb2JhbABagwc4TAa+I4EkFm0HgiUBAQEEAQEBNzQGEQQCAQgRBAEBCxQJBycLFAkIAgQTCAGHfQcFwH+PJQ8pBoMZgQoDmTiQWIMkgik X-IronPort-AV: E=Sophos;i="4.93,524,1378857600"; d="scan'208";a="273951089" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-3.cisco.com with ESMTP; 18 Oct 2013 19:55:36 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r9IJtZaT006014 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 18 Oct 2013 19:55:35 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.143]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Fri, 18 Oct 2013 14:55:35 -0500 From: "Panos Kampanakis (pkampana)" To: "mile@ietf.org" Thread-Topic: [mile] I-D Action: draft-ietf-mile-iodef-guidance-02.txt Thread-Index: AQHOzDLxXyibVCNaUEid2nEqeMvbq5n63vgA Date: Fri, 18 Oct 2013 19:55:34 +0000 Message-ID: <1C9F17D1873AFA47A969C4DD98F98A750FA586A1@xmb-aln-x10.cisco.com> References: <20131018184942.4087.12333.idtracker@ietfa.amsl.com> In-Reply-To: <20131018184942.4087.12333.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.89.126] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mile] I-D Action: draft-ietf-mile-iodef-guidance-02.txt X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 19:55:53 -0000 Hello, This is the updated iodef-guidance draft. I updated are the predicate logic section, to make it clearer after Roman's= suggestions. Also added one more subsection with the multi-vendor poc in the examples s= ection. The draft is still in early stage and some sections need further work. Feedback and discussion welcome. Panos -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of int= ernet-drafts@ietf.org Sent: Friday, October 18, 2013 2:50 PM To: i-d-announce@ietf.org Cc: mile@ietf.org Subject: [mile] I-D Action: draft-ietf-mile-iodef-guidance-02.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Managed Incident Lightweight Exchange Wor= king Group of the IETF. Title : IODEF Usage Guidance Author(s) : Panos Kampanakis Filename : draft-ietf-mile-iodef-guidance-02.txt Pages : 19 Date : 2013-10-18 Abstract: The Incident Object Description Exchange Format [RFC5070] defines a data representation that provides a framework for sharing information commonly exchanged by Computer Security Incident Response Teams (CSIRTs) about computer security incidents. Since the IODEF model includes a wealth of available options that can be used to describe a security incident or issue, it can be challenging for implementers to develop tools that can Leverage IODEF for incident sharing. This document provides guidelines for IODEF implementers. It will also address how common security indicators can be represented in IODEF. The goal of this document is to make IODEF's adoption by vendors easier and encourage faster and wider adoption of the model by Computer Security Incident Response Teams (CSIRTs) around the world. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mile-iodef-guidance There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mile-iodef-guidance-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mile-iodef-guidance-02 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile From pkampana@cisco.com Fri Oct 18 12:57:10 2013 Return-Path: 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 5EC8A11E832E for ; Fri, 18 Oct 2013 12:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.605 X-Spam-Level: X-Spam-Status: No, score=-8.605 tagged_above=-999 required=5 tests=[AWL=-1.994, BAYES_00=-2.599, FRT_STOCK2=3.988, RCVD_IN_DNSWL_HI=-8] 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 kpkvVk-5RBWa for ; Fri, 18 Oct 2013 12:57:02 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 663DE11E832D for ; Fri, 18 Oct 2013 12:57:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2985; q=dns/txt; s=iport; t=1382126220; x=1383335820; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=PzzGeLcTsIkkA/N379KZGqw4P2eIFkAQc/oXkDuby5c=; b=kHYi33uOvQlWHAQD6KIWsVP0WHOryzHC1HXaZje6O92C4g1YapDmf2YI 9CJ7qKbFKlnk3x16AmQiC3q9nB8UnBZS1hN1Ne896NWUV8OETgRP7OrE1 N4gx6zNo+NQeVlmSzcWgVvudhwbfjxfPgSqC/gbdx+etyi8mqNY40Cs8v M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FANuRYVKtJXG8/2dsb2JhbABXA4MHOFK+I4EkFnSCJQEBAQQBAQEkEzQXBAIBCBEEAQELFAkHJwsUCQgBAQQBEgiHfgzBAI4nfiEXBguDDoEKA5k4kFiDJIIp X-IronPort-AV: E=Sophos;i="4.93,524,1378857600"; d="scan'208";a="274008913" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-4.cisco.com with ESMTP; 18 Oct 2013 19:57:00 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r9IJuxkn023545 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 18 Oct 2013 19:56:59 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.143]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.004; Fri, 18 Oct 2013 14:56:59 -0500 From: "Panos Kampanakis (pkampana)" To: "Stoecker, Paul" , "Roman D. Danyliw" , "mile@ietf.org" Thread-Topic: [mile] Details on ReportID Thread-Index: Ac7MI9z+YM180Lq7RKqO+8EBfVlpbgAFEuCAAAEB0CA= Date: Fri, 18 Oct 2013 19:56:59 +0000 Message-ID: <1C9F17D1873AFA47A969C4DD98F98A750FA586B8@xmb-aln-x10.cisco.com> References: <359EC4B99E040048A7131E0F4E113AFC54B9DA3D@marathon> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.89.126] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mile] Details on ReportID X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 19:57:10 -0000 +1 -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Sto= ecker, Paul Sent: Friday, October 18, 2013 3:28 PM To: Roman D. Danyliw; mile@ietf.org Subject: Re: [mile] Details on ReportID It almost seems like you would use it because you don't necessarily like th= e term IncidentID. That is all you want to do is to share some IOCs or a w= atch list and it isn't in any way related to an Incident, so you call it a = Report. I would stick with one term. There is an incidentID and it can be= just information that you want to share that is related to Incidents. I s= ay we keep it simple. Paul W. Stoecker, Ph.D. Security Analytics Product Management Team RSA, The Security Division of EM= C cell: 302.379.3375 | e: paul.stoecker@rsa.com On 10/18/13 1:02 PM, "Roman D. Danyliw" wrote: >Hello! > >Per issue #15 (http://trac.tools.ietf.org/wg/mile/trac/ticket/15),=20 >there are a few changes in the schema not described in the text,=20 >discussed on the mailing list, or in a presentation at a meeting. I=20 >was hoping to get insight into Incident/ReportID. This text is currently = in the -01 schema: > >--[snip]-- > > > > > > > > >--[ snip ]-- > >TXML comment suggests the ReportID is motivated by a use case where=20 >only indicators are shared. >From the name alone, I don't want to jump to any conclusions. A few >questions: > >** When does one use a ReportID instead of an IncidentID (the schema=20 >suggests they're mutually exclusive)? >** Are there any advantages or disadvantages in supporting both at the=20 >same time? >** Is a ReportID a unique identifier for a given IODEF-Document? >IODEF-Document/Incident? >** In discussion #4, there was talk of providing document updates. =20 >Does a ReportID change when an update is provided?** Is there a format=20 >for the ReportID? >** What does it mean when an Incident/AlternativeID is included and no=20 >Incident/IncidentID provided? > >Roman > >_______________________________________________ >mile mailing list >mile@ietf.org >https://www.ietf.org/mailman/listinfo/mile > _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile From kathleen.moriarty@emc.com Fri Oct 18 13:05:35 2013 Return-Path: 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 C295C11E819E for ; Fri, 18 Oct 2013 13:05:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.314 X-Spam-Level: X-Spam-Status: No, score=-0.314 tagged_above=-999 required=5 tests=[AWL=-1.703, BAYES_00=-2.599, FRT_STOCK2=3.988] 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 7dFV0LVY68Yw for ; Fri, 18 Oct 2013 13:05:32 -0700 (PDT) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) by ietfa.amsl.com (Postfix) with ESMTP id 7DCBF11E8311 for ; Fri, 18 Oct 2013 13:05:29 -0700 (PDT) Received: from maildlpprd51.lss.emc.com (maildlpprd51.lss.emc.com [10.106.48.155]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id r9IK5OUN018742 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Oct 2013 16:05:25 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com r9IK5OUN018742 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1382126725; bh=ieqeguF65GOeAAs+5eQ7fS9E87I=; h=From:To:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=nS1rz4mlNfYj9lpIFh9s375MguWVHr2X+hxBGXrYYNSUrRBsu94EW7nRcv0xwyWsy jheirPKNPQ0s4s/L0Bkk3xvJ9HjkhKQ+3Dzh7GcIkpd5kZsBwBkwMDKN5VPCdfMMq7 qK2Q7u7YlPd+eeP7dubvcO+epk1CtP14GmsJaJ8I= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com r9IK5OUN018742 Received: from mailusrhubprd54.lss.emc.com (mailusrhubprd54.lss.emc.com [10.106.48.19]) by maildlpprd51.lss.emc.com (RSA Interceptor); Fri, 18 Oct 2013 16:05:10 -0400 Received: from mxhub10.corp.emc.com (mxhub10.corp.emc.com [10.254.92.105]) by mailusrhubprd54.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id r9IK50MB011178 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 18 Oct 2013 16:05:09 -0400 Received: from mx15a.corp.emc.com ([169.254.1.46]) by mxhub10.corp.emc.com ([10.254.92.105]) with mapi; Fri, 18 Oct 2013 16:05:05 -0400 From: "Moriarty, Kathleen" To: "Panos Kampanakis (pkampana)" , "Stoecker, Paul" , "Roman D. Danyliw" , "mile@ietf.org" Date: Fri, 18 Oct 2013 16:04:28 -0400 Thread-Topic: [mile] Details on ReportID Thread-Index: Ac7MI9z+YM180Lq7RKqO+8EBfVlpbgAFEuCAAAEB0CAAAEQPdg== Message-ID: References: <359EC4B99E040048A7131E0F4E113AFC54B9DA3D@marathon> , <1C9F17D1873AFA47A969C4DD98F98A750FA586B8@xmb-aln-x10.cisco.com> In-Reply-To: <1C9F17D1873AFA47A969C4DD98F98A750FA586B8@xmb-aln-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd54.lss.emc.com X-RSA-Classifications: public Subject: Re: [mile] Details on ReportID X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 20:05:35 -0000 I am fine with either approach, but am hoping the folks who pushed for anot= her term chime in as well. It would be great to hear their perspective. Thanks! Kathleen ________________________________________ From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of Panos Kamp= anakis (pkampana) [pkampana@cisco.com] Sent: Friday, October 18, 2013 3:56 PM To: Stoecker, Paul; Roman D. Danyliw; mile@ietf.org Subject: Re: [mile] Details on ReportID +1 -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Sto= ecker, Paul Sent: Friday, October 18, 2013 3:28 PM To: Roman D. Danyliw; mile@ietf.org Subject: Re: [mile] Details on ReportID It almost seems like you would use it because you don't necessarily like th= e term IncidentID. That is all you want to do is to share some IOCs or a w= atch list and it isn't in any way related to an Incident, so you call it a = Report. I would stick with one term. There is an incidentID and it can be= just information that you want to share that is related to Incidents. I s= ay we keep it simple. Paul W. Stoecker, Ph.D. Security Analytics Product Management Team RSA, The Security Division of EM= C cell: 302.379.3375 | e: paul.stoecker@rsa.com On 10/18/13 1:02 PM, "Roman D. Danyliw" wrote: >Hello! > >Per issue #15 (http://trac.tools.ietf.org/wg/mile/trac/ticket/15), >there are a few changes in the schema not described in the text, >discussed on the mailing list, or in a presentation at a meeting. I >was hoping to get insight into Incident/ReportID. This text is currently = in the -01 schema: > >--[snip]-- > > > > > > > > >--[ snip ]-- > >TXML comment suggests the ReportID is motivated by a use case where >only indicators are shared. >From the name alone, I don't want to jump to any conclusions. A few >questions: > >** When does one use a ReportID instead of an IncidentID (the schema >suggests they're mutually exclusive)? >** Are there any advantages or disadvantages in supporting both at the >same time? >** Is a ReportID a unique identifier for a given IODEF-Document? >IODEF-Document/Incident? >** In discussion #4, there was talk of providing document updates. >Does a ReportID change when an update is provided?** Is there a format >for the ReportID? >** What does it mean when an Incident/AlternativeID is included and no >Incident/IncidentID provided? > >Roman > >_______________________________________________ >mile mailing list >mile@ietf.org >https://www.ietf.org/mailman/listinfo/mile > _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile From internet-drafts@ietf.org Sat Oct 19 18:09:05 2013 Return-Path: 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 6106F11E831F; Sat, 19 Oct 2013 18:09:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.573 X-Spam-Level: X-Spam-Status: No, score=-100.573 tagged_above=-999 required=5 tests=[AWL=-1.961, BAYES_00=-2.599, FRT_STOCK2=3.988, NO_RELAYS=-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 EQe3xqmC698v; Sat, 19 Oct 2013 18:09:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 48E3111E831C; Sat, 19 Oct 2013 18:09:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131020010903.9565.35908.idtracker@ietfa.amsl.com> Date: Sat, 19 Oct 2013 18:09:03 -0700 Cc: mile@ietf.org Subject: [mile] I-D Action: draft-ietf-mile-rfc5070-bis-02.txt X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Oct 2013 01:09:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Managed Incident Lightweight Exchange Wor= king Group of the IETF. Title : The Incident Object Description Exchange Format v2 Author(s) : Roman Danyliw Paul Stoecker Filename : draft-ietf-mile-rfc5070-bis-02.txt Pages : 112 Date : 2013-10-19 Abstract: The Incident Object Description Exchange Format (IODEF) defines a data representation that provides a framework for sharing information commonly exchanged by Computer Security Incident Response Teams (CSIRTs) about computer security incidents. This document describes the information model for the IODEF and provides an associated data model specified with XML Schema. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mile-rfc5070-bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mile-rfc5070-bis-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mile-rfc5070-bis-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From rdd@cert.org Sat Oct 19 18:11:05 2013 Return-Path: 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 085C911E8319 for ; Sat, 19 Oct 2013 18:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.356 X-Spam-Level: X-Spam-Status: No, score=-4.356 tagged_above=-999 required=5 tests=[AWL=-1.745, BAYES_00=-2.599, FRT_STOCK2=3.988, RCVD_IN_DNSWL_MED=-4] 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 L9bXJA4Zhzm3 for ; Sat, 19 Oct 2013 18:11:01 -0700 (PDT) Received: from plainfield.sei.cmu.edu (plainfield.sei.cmu.edu [192.58.107.45]) by ietfa.amsl.com (Postfix) with ESMTP id EAAA011E80EE for ; Sat, 19 Oct 2013 18:11:00 -0700 (PDT) Received: from timber.sei.cmu.edu (timber.sei.cmu.edu [10.64.21.23]) by plainfield.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id r9K1B0jg026920 for ; Sat, 19 Oct 2013 21:11:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1382231460; bh=JsAcviG+y0hVtXi6nyHeTA3RPxO8Ob4YJUhwWPkOKec=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version:Sender: Reply-To:Cc; b=iEI3M/eFIpccDrsVmxf2TGmYkAewX07BR2mASKXIh2VsNrsb2jQidUPkaLKKYTANs h9UDJmeYWgJwaYF3djV076fJjjlMk0EAwuk4Fc5znYLc7B8GCuKVqynlcVkSWL2O/V LH/ZFX0sYtRwEVJ4L9ZLfhcgtQALbvTxz3YUsVVM= Received: from CASCADE.ad.sei.cmu.edu (cascade.sei.cmu.edu [10.64.28.248]) by timber.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id r9K1B0RR011887 for ; Sat, 19 Oct 2013 21:11:00 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.02.0347.000; Sat, 19 Oct 2013 21:10:59 -0400 From: "Roman D. Danyliw" To: "mile@ietf.org" Thread-Topic: [mile] I-D Action: draft-ietf-mile-rfc5070-bis-02.txt Thread-Index: AQHOzTD8j9fIG+KLhEqd5GsSRi326Jn8x76w Date: Sun, 20 Oct 2013 01:10:58 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC54B9E89A@marathon> References: <20131020010903.9565.35908.idtracker@ietfa.amsl.com> In-Reply-To: <20131020010903.9565.35908.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [mile] FW: I-D Action: draft-ietf-mile-rfc5070-bis-02.txt X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Oct 2013 01:11:05 -0000 Hello! A new version of 5070bis has been published as -02. The following is a lis= t of the changes: ** (schema) Added Contact/ContactTitle to describe the title of the contact= (Issue #35) ** (schema) Added System/AssetId to represent an opaque asset identifier (I= ssue #33) ** (schema) Added RelatedActivity/{ThreadActor, Campaign, Confidence, Descr= iption, AdditionalData} (Issue #31 and partial #22) ** (schema) Changed cardinality of Incident/RelatedActivity to be 0..many i= n Incident (needed for Issue #31) ** (schema) Added System@virtual to convey whether a device is physical or = virtual (Issue #16) ** (schema) Added Incident@purpose=3D{watch} (Issue #17) ** (schema) Added System@ownership to describe asset ownership (Issue #34) ** (schema) Various fixes to schema to make it valid=20 ** (editorial) Minor spelling fixes Roman -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of int= ernet-drafts@ietf.org Sent: Saturday, October 19, 2013 9:09 PM To: i-d-announce@ietf.org Cc: mile@ietf.org Subject: [mile] I-D Action: draft-ietf-mile-rfc5070-bis-02.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Managed Incident Lightweight Exchange Wor= king Group of the IETF. Title : The Incident Object Description Exchange Format v2 Author(s) : Roman Danyliw Paul Stoecker Filename : draft-ietf-mile-rfc5070-bis-02.txt Pages : 112 Date : 2013-10-19 Abstract: The Incident Object Description Exchange Format (IODEF) defines a data representation that provides a framework for sharing information commonly exchanged by Computer Security Incident Response Teams (CSIRTs) about computer security incidents. This document describes the information model for the IODEF and provides an associated data model specified with XML Schema. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mile-rfc5070-bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mile-rfc5070-bis-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mile-rfc5070-bis-02 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile