From takeshi_takahashi@nict.go.jp Mon Apr 1 01:53:23 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 7215A21F8881 for ; Mon, 1 Apr 2013 01:53:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.245 X-Spam-Level: * X-Spam-Status: No, score=1.245 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_JP=1.244] 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 kD4-pSFXaXdQ for ; Mon, 1 Apr 2013 01:53:22 -0700 (PDT) Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:df0:232:300::1]) by ietfa.amsl.com (Postfix) with ESMTP id 35C2421F88C0 for ; Mon, 1 Apr 2013 01:53:21 -0700 (PDT) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id r318rFN2001843; Mon, 1 Apr 2013 17:53:15 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id r318rETn010399; Mon, 1 Apr 2013 17:53:14 +0900 (JST) Received: from mail3.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id r318rEJE010395; Mon, 1 Apr 2013 17:53:14 +0900 (JST) Received: from mail3.nict.go.jp (localhost [127.0.0.1]) by mail3.nict.go.jp (NICT Mail) with ESMTP id 6E9F0164B3; Mon, 1 Apr 2013 17:53:14 +0900 (JST) Received: from VAIO (unknown [133.243.119.109]) by mail3.nict.go.jp (NICT Mail) with ESMTP id 68F6C16473; Mon, 1 Apr 2013 17:53:14 +0900 (JST) From: "Takeshi Takahashi" To: "'Moriarty, Kathleen'" , References: , <1C9F17D1873AFA47A969C4DD98F98A751926C4@xmb-rcd-x10.cisco.com> <8D3D17ACE214DC429325B2B98F3AE71290FA9202@MX15A.corp.emc.com> <000601ce279e$c8ab7940$5a026bc0$@nict.go.jp> In-Reply-To: Date: Mon, 1 Apr 2013 17:53:21 +0900 Message-ID: <006b01ce2eb6$5ca18d60$15e4a820$@nict.go.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFCibkFcoiRAxGJUwOvO7kpytpEUwHYmM6bAq+IVDUBugT0/gGrVkJYAnN+UnOZhU9p0A== Content-Language: ja Subject: Re: [mile] Consensus Call - SCI draft MMDEF as MTI 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, 01 Apr 2013 08:53:23 -0000 Hello all, Thank you for your kind support to the draft. Before the draft goes to the WGLC, we are currently reviewing the content of the draft once again. Let me update the draft and come back to the mailing list with revised version in a couple of weeks. Thank you. Take > -----Original Message----- > From: Moriarty, Kathleen [mailto:kathleen.moriarty@emc.com] > Sent: Thursday, March 28, 2013 9:59 AM > To: Takeshi Takahashi; mile@ietf.org > Subject: RE: [mile] Consensus Call - SCI draft MMDEF as MTI > > Hello, > > Thank you for voicing your opinions at the MILE meeting, the two week period > is up and we have full agreement. We will move forward with MMDEF as the > MTI for the SCI draft. > > Take - Thank you for updating the draft to include MMDEF as the MTI as well > as the update below. Could you expand the acronym for MTI in the draft > and update the version to the latest? > > Bets regards, > Kathleen > > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of > Takeshi Takahashi > Sent: Saturday, March 23, 2013 4:17 AM > To: mile@ietf.org > Subject: Re: [mile] Consensus Call - SCI draft MMDEF as MTI > > Hi all, > > I remember the discussion on the EICAR and agree upon David's kind > suggestion. > The attached is the revised SCI draft, whose section 10 talks about the > EICAR (with an example XML). > > Kind regards, > Take > > > > -----Original Message----- > > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf > > Of Black, David > > Sent: Thursday, March 14, 2013 11:54 PM > > To: Moriarty, Kathleen; mile@ietf.org > > Subject: Re: [mile] Consensus Call - SCI draft MMDEF as MTI > > > > I support MMDEF as the MTI, and since MMDEF is a malware spec, I'd > > like to resurrect a previously-discussed suggestion that the SCI draft > > include discussion of the "EICAR Standard Anti-Virus Test File" as a > > specific > example > > that SHOULD (or MUST?) be supported for black-box testing purposes. > > > > See: http://www.eicar.org/86-0-Intended-use.html > > > > Thanks, > > --David > > > > > -----Original Message----- > > > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf > > > Of Moriarty, Kathleen > > > Sent: Thursday, March 14, 2013 10:38 AM > > > To: Panos Kampanakis (pkampana); mile@ietf.org > > > Subject: Re: [mile] Consensus Call - SCI draft MMDEF as MTI > > > > > > Hello Panos, > > > > > > Thank you for joining us remotely! The recording is available for > > > those who were not able to attend during the session. > > > > > > We need to choose one included schema as MTI for 'black box' testing > > > of the method described. Essentially, if you can exchange using the > > > MTI spec, then any other specs supported should theoretically work > > > as the pattern has been established. > > > > > > MMDEF was recommended as it is in use by the eCrime WG as an > > extension > > > to IODEF/RFC5901. It replaced the method to include malware in > > > exchanges and seemed to make sense to adopt more broadly as it is > > > maintained by a group in IEEE focused on that particular problem. > > > > > > BTW, I meant to say the last call will end in two weeks from > > > yesterday, Wednesday March 27th. > > > > > > Thank you! > > > Kathleen > > > ________________________________________ > > > From: Panos Kampanakis (pkampana) [pkampana@cisco.com] > > > Sent: Thursday, March 14, 2013 9:59 AM > > > To: Moriarty, Kathleen; mile@ietf.org > > > Subject: RE: Consensus Call - SCI draft MMDEF as MTI > > > > > > I agree with MMDEF included in SCI. > > > I am not sure why it must be MTI. Due to some audio problems I > > > missed part of the call yesterday. Can you briefly summarize why we > > > want it > MTI? > > > > > > -----Original Message----- > > > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf > > > Of Moriarty, Kathleen > > > Sent: Wednesday, March 13, 2013 3:04 PM > > > To: mile@ietf.org > > > Subject: [mile] Consensus Call - SCI draft MMDEF as MTI > > > > > > Hello, > > > > > > In today's MILE session, a call for consensus began to include MMDEF > > > in the SCI draft as the mandatory-to-implement (MTI) specification. > > > The call for consensus will last for 2 weeks and we ask that you > contribute > > your opinion. > > > The vote in the room was unanimous and we want to make sure we hear > > > from participants not in attendance. > > > > > > Poll will end on Wednesday next week. > > > > > > Thank you! > > > Kathleen > > > _______________________________________________ > > > 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 eburger@standardstrack.com Mon Apr 1 05:36: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 BC4CC21F884F for ; Mon, 1 Apr 2013 05:36:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.999 X-Spam-Level: X-Spam-Status: No, score=-99.999 tagged_above=-999 required=5 tests=[BAYES_50=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 W3uRg1lCb28D for ; Mon, 1 Apr 2013 05:36:08 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [173.247.246.244]) by ietfa.amsl.com (Postfix) with ESMTP id C5BFB21F89C3 for ; Mon, 1 Apr 2013 05:36:08 -0700 (PDT) Received: from ip68-100-199-8.dc.dc.cox.net ([68.100.199.8]:56277 helo=[192.168.15.177]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1UMdy3-00018U-02; Mon, 01 Apr 2013 05:36:07 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Eric Burger In-Reply-To: <51543918.1050605@mitre.org> Date: Mon, 1 Apr 2013 08:36:06 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: , <1C9F17D1873AFA47A969C4DD98F98A751926C4@xmb-rcd-x10.cisco.com> <8D3D17ACE214DC429325B2B98F3AE71290FA9202@MX15A.corp.emc.com> <000601ce279e$c8ab7940$5a026bc0$@nict.go.jp> <1CBD9BD3-18CF-4787-B13E-3288FCB68AE0@cs.georgetown.edu> <5271802E-3724-426D-8DB8-E4718B0092AD@standardstrack.com> <51543918.1050605@mitre.org> To: "Martin, Robert A." X-Mailer: Apple Mail (2.1503) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Cc: mile@ietf.org Subject: Re: [mile] Consensus Call - SCI draft MMDEF as MTI 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, 01 Apr 2013 12:36:09 -0000 Next week that URI can change. It is not an IEEE standard, so there is = no P number. Since it is not an IEEE standard, you cannot buy or = reference the spec from IEEE. Is there someone involved with the MMDEF work who can find out about a = stable reference? We don't need an RFC, but we do need something that is = likely to be there next month. An individual informational RFC would = work, too. Another alternative is to do a wink and a nudge and have IODEF say there = are things out there for malware identification. One could use something = *like* MMDEF which you *might* be able to find at the IEEE-SA industry = site. It would be an informative reference, so there would be no = violation of IETF rules. That approach will not promise long-term = interoperability, but it is better than nothing. On Mar 28, 2013, at 8:35 AM, "Martin, Robert A." = wrote: > This page would seem to provide that. >=20 > >=20 > On 3/27/13 10:25 PM, Eric Burger wrote: >> Did we ever find a stable reference for MMDEF? >>=20 >> On Mar 27, 2013, at 8:59 PM, "Moriarty, Kathleen" = wrote: >>=20 >>> Hello, >>>=20 >>> Thank you for voicing your opinions at the MILE meeting, the two = week period is up and we have full agreement. We will move forward with = MMDEF as the MTI for the SCI draft. >>>=20 >>> Take - Thank you for updating the draft to include MMDEF as the MTI = as well as the update below. Could you expand the acronym for MTI in = the draft and update the version to the latest? >>>=20 >>> Bets regards, >>> Kathleen >>>=20 >>> -----Original Message----- >>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf = Of Takeshi Takahashi >>> Sent: Saturday, March 23, 2013 4:17 AM >>> To: mile@ietf.org >>> Subject: Re: [mile] Consensus Call - SCI draft MMDEF as MTI >>>=20 >>> Hi all, >>>=20 >>> I remember the discussion on the EICAR and agree upon David's kind >>> suggestion. >>> The attached is the revised SCI draft, whose section 10 talks about = the >>> EICAR (with an example XML). >>>=20 >>> Kind regards, >>> Take >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On = Behalf Of >>>> Black, David >>>> Sent: Thursday, March 14, 2013 11:54 PM >>>> To: Moriarty, Kathleen; mile@ietf.org >>>> Subject: Re: [mile] Consensus Call - SCI draft MMDEF as MTI >>>>=20 >>>> I support MMDEF as the MTI, and since MMDEF is a malware spec, I'd = like to >>>> resurrect a previously-discussed suggestion that the SCI draft = include >>>> discussion of the "EICAR Standard Anti-Virus Test File" as a = specific >>> example >>>> that SHOULD (or MUST?) be supported for black-box testing purposes. >>>>=20 >>>> See: http://www.eicar.org/86-0-Intended-use.html >>>>=20 >>>> Thanks, >>>> --David >>>>=20 >>>>> -----Original Message----- >>>>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On = Behalf >>>>> Of Moriarty, Kathleen >>>>> Sent: Thursday, March 14, 2013 10:38 AM >>>>> To: Panos Kampanakis (pkampana); mile@ietf.org >>>>> Subject: Re: [mile] Consensus Call - SCI draft MMDEF as MTI >>>>>=20 >>>>> Hello Panos, >>>>>=20 >>>>> Thank you for joining us remotely! The recording is available for >>>>> those who were not able to attend during the session. >>>>>=20 >>>>> We need to choose one included schema as MTI for 'black box' = testing >>>>> of the method described. Essentially, if you can exchange using = the >>>>> MTI spec, then any other specs supported should theoretically work = as >>>>> the pattern has been established. >>>>>=20 >>>>> MMDEF was recommended as it is in use by the eCrime WG as an >>>> extension >>>>> to IODEF/RFC5901. It replaced the method to include malware in >>>>> exchanges and seemed to make sense to adopt more broadly as it is >>>>> maintained by a group in IEEE focused on that particular problem. >>>>>=20 >>>>> BTW, I meant to say the last call will end in two weeks from >>>>> yesterday, Wednesday March 27th. >>>>>=20 >>>>> Thank you! >>>>> Kathleen >>>>> ________________________________________ >>>>> From: Panos Kampanakis (pkampana) [pkampana@cisco.com] >>>>> Sent: Thursday, March 14, 2013 9:59 AM >>>>> To: Moriarty, Kathleen; mile@ietf.org >>>>> Subject: RE: Consensus Call - SCI draft MMDEF as MTI >>>>>=20 >>>>> I agree with MMDEF included in SCI. >>>>> I am not sure why it must be MTI. Due to some audio problems I = missed >>>>> part of the call yesterday. Can you briefly summarize why we want = it >>> MTI? >>>>>=20 >>>>> -----Original Message----- >>>>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On = Behalf >>>>> Of Moriarty, Kathleen >>>>> Sent: Wednesday, March 13, 2013 3:04 PM >>>>> To: mile@ietf.org >>>>> Subject: [mile] Consensus Call - SCI draft MMDEF as MTI >>>>>=20 >>>>> Hello, >>>>>=20 >>>>> In today's MILE session, a call for consensus began to include = MMDEF >>>>> in the SCI draft as the mandatory-to-implement (MTI) = specification. >>>>> The call for consensus will last for 2 weeks and we ask that you >>> contribute >>>> your opinion. >>>>> The vote in the room was unanimous and we want to make sure we = hear >>>>> from participants not in attendance. >>>>>=20 >>>>> Poll will end on Wednesday next week. >>>>>=20 >>>>> Thank you! >>>>> Kathleen >>>>> _______________________________________________ >>>>> 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 >>>>=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 >>=20 >>=20 >>=20 >> _______________________________________________ >> mile mailing list >> mile@ietf.org >> https://www.ietf.org/mailman/listinfo/mile >> . >>=20 > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From eburger@standardstrack.com Mon Apr 1 07:27:22 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 06DA311E80BA for ; Mon, 1 Apr 2013 07:27:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.999 X-Spam-Level: X-Spam-Status: No, score=-100.999 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_50=0.001, GB_I_LETTER=-2, 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 00lq68WnxevZ for ; Mon, 1 Apr 2013 07:27:20 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [173.247.246.244]) by ietfa.amsl.com (Postfix) with ESMTP id BF2CA11E80B8 for ; Mon, 1 Apr 2013 07:27:20 -0700 (PDT) Received: from ip68-100-199-8.dc.dc.cox.net ([68.100.199.8]:57565 helo=[192.168.15.177]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1UMfhY-0005Jy-GP for mile@ietf.org; Mon, 01 Apr 2013 07:27:14 -0700 From: Eric Burger Content-Type: multipart/signed; boundary="Apple-Mail=_02649D8A-869C-4816-A4B4-13F862C5E8C4"; protocol="application/pgp-signature"; micalg=pgp-sha1 Message-Id: Date: Mon, 1 Apr 2013 10:27:10 -0400 To: "MILE" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Subject: [mile] SHOULD/RECOMMENDED Analysis / Suggestions 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, 01 Apr 2013 14:27:22 -0000 --Apple-Mail=_02649D8A-869C-4816-A4B4-13F862C5E8C4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii SHOULD's: 3.4. AlternativeID Class [...] The incident tracking numbers of the CSIRT that generated the IODEF document should never be considered an AlternativeID. Two schools of thought. The first is either one is saying something or = one is not. In that case, we should say: [...] The incident tracking numbers of the CSIRT that generated the IODEF document must never be considered an AlternativeID. The second is this is not describing protocol behavior, and as such = there is no enforcement. In that case, we should say: [...] Do not use the incident tracking numbers of the CSIRT that generated the IODEF document as an AlternativeID. 3.8.4. ReportTime The ReportTime class represents the time the incident was reported. This timestamp SHOULD coincide to the time at which the IODEF document is generated. What other time can the timestamp refer to? Why would it be something = different? Say so or turn this into a MUST. The ReportTime class represents the time the incident was reported. This timestamp MUST be the time at which the IODEF document is generated. 3.8.5. DateTime The DateTime class is a generic representation of a timestamp. Its semantics should be inferred from the parent class in which it is aggregated. Although not normative, this is very loose. When would one ever NOT = infer the DateTime class for a particular timestamp class = (start/end/report/detect)? Is there a reason not to just say: The DateTime class is a generic representation of a timestamp. Infer its semantics from the parent class in which it is aggregated. 3.10.4. Confidence Class [...] The element content expresses a numerical assessment in the confidence of the data when the value of the rating attribute is "numeric". Otherwise, this element should be empty. What else can it be? I do not think it could be anything: The element content expresses a numerical assessment in the confidence of the data when the value of the rating attribute is "numeric". Otherwise, this element MUST be empty. 3.13. Expectation Class [...] StartTime Zero or one. The time at which the action should be performed. A timestamp that is earlier than the ReportTime specified in the Incident class denotes that the expectation should be fulfilled as soon as possible. The absence of this element leaves the execution of the expectation to the discretion of the recipient. I would offer we not use the word 'should' here, as it is confused with = 'SHOULD.' How about rewording this to say: StartTime Zero or one. The time at which the sender would like the action performed. A timestamp that is earlier than the ReportTime specified in the Incident class denotes that the sender would like the action performed as soon as possible. The absence of this element indicates no expectations of when the recipient would like the action performed. EndTime Zero or one. The time by which the action should be completed. If the action is not carried out by this time, it should no longer be performed. Or else what? We should be brutal here. I would offer: EndTime Zero or one. The time by which the sender expects the recipient to complete the action. If the recipient cannot complete the action before EndTime, the recipient MUST NOT carry out the = action. NOTE: Because of tranist delays, clock drift, and so on, the = sender MUST be prepared for the recipient to have carried out the action, even if it completes past EndTime. 3.16. Node Class [...] DateTime Zero or one. A timestamp of when the resolution between the name and address was performed. This information SHOULD be provided if both an Address and NodeName are specified. What is this used for? Is it important? Are we worried about DNS = changes? What if the authoritative server does an update but the = resolver's TTL has not expired? What is the use case? Assuming it is useful (I am doubtful), I would offer: DateTime Zero or one. A timestamp of when the resolution between the name and address was performed. This information MUST be provided if both an Address and NodeName are specified. Otherwise, drop the element. 3.17. Service Class [...] For a given source, System@type=3D"source", a corresponding target, System@type=3D"target", maybe defined, or vice versa. When a = Portlist class is defined in the Service class of both the source and target in a given instance of the Flow class, there MUST be symmetry in the enumeration of the ports. Thus, if n-ports are listed for a source, n-ports should be listed for the target. Likewise, the ports should be listed in an identical sequence such that the n-th port in the source corresponds to the n-th port of the target. This symmetry in listing and sequencing of ports applies whether there are 1-to-1, 1-to-many, or many-to-many sources-to-targets. In the 1-to-many or many-to-many, the exact order in which the System classes are enumerated in the Flow class is significant. There MUST be symmetry, but it is only a good idea to actually do it? = Either there MUST be symmetry, or not. In being conservative in what = one sends, I would move everything to MUSTs. Also note a few = typographical errors that get fixed: For a given source, System@type=3D"source", a corresponding target, System@type=3D"target", may be defined, or vice versa. When a = Portlist class is defined in the Service class of both the source and target in a given instance of the Flow class, there MUST be symmetry in the enumeration of the ports. Thus, if N ports are listed for a source, N ports MUST be listed for the target. Likewise, the ports MUST be listed in an identical sequence such that the n-th port in the source corresponds to the n-th port of the target. This symmetry in listing and sequencing of ports applies whether there are 1-to-1, 1-to-many, or many-to-many sources-to-targets. In the 1-to-many or many-to-many, the exact order in which the System classes are enumerated in the Flow class is significant. Since the document brings it up, what does it mean to have a 1:1 = correspondence of sources-to-targets if there can be more targets than = sources? 3.19. Record Class The Record class is a container class for log and audit data that provides supportive information about the incident. The source of this data will often be the output of monitoring tools. These logs should substantiate the activity described in the document. What else can this class do? Take out one word and it is fine: The Record class is a container class for log and audit data that provides supportive information about the incident. The source of this data will often be the output of monitoring tools. These logs substantiate the activity described in the document. 3.19. Record Class [...] RecordData One or more. Log or audit data generated by a particular type of sensor. Separate instances of the RecordData class SHOULD be used for each sensor type. If there is ever a reason not to have separate insances of RecordData, = then enumerate them or explain how they get aggregated. Otherwise: RecordData One or more. Log or audit data generated by a particular type of sensor. Separate instances of the RecordData class MUST be used for each sensor type. 4.2. IODEF Namespace The IODEF schema declares a namespace of "urn:ietf:params:xml:ns:iodef-1.0" and registers it per [4]. Each IODEF document SHOULD include a valid reference to the IODEF schema using the "xsi:schemaLocation" attribute. An example of such a declaration would look as follows: When would one EVER not include a valid reference on purpose? The IODEF schema declares a namespace of "urn:ietf:params:xml:ns:iodef-1.0" and registers it per [4]. Each IODEF document MUST include a valid reference to the IODEF schema using the "xsi:schemaLocation" attribute. An example of such a declaration would look as follows: Remember, later on we say this whole thing is a joke and you should not = even try to dereference the URN, so it is safe to include the 32 bytes = the URN takes up. We are already paying the XML tax, so we might as well = really use it. 4.3. Validation The IODEF documents MUST be well-formed XML and SHOULD be validated against the schema described in Section 8. Here, finally, is a legitimate use of SHOULD. Well, actually, it should = be a recommendation: The IODEF documents MUST be well-formed XML. Recipients are RECOMMENDED to validate the received document against the schema described in Section 8. Situations where the recipient may choose not to validate the received document include deployments where there is limited Internet connectivity and as such access to the schemas is not available or timely; implementations where concerns about accessing external files at run time may conflict with local = policies; and situations where the integrity of the data is of little = importance to the recipient. 5.2. Extending Classes [...] 4. When a parser encounters an IODEF document with an extension it does not understand, this extension MUST be ignored (and not processed), but the remainder of the document MUST be processed. Parsers will able to identify these extensions for which they have no processing logic through the namespace declaration. Parsers that encounter an unrecognized element in a namespace that they do support SHOULD reject the document as a syntax error. When would they not reject the document? Enumerate likely scenarios, = like: Parsers that encounter an unrecognized element in a namespace that they do support SHOULD reject the document as a syntax error unless they can do meaningful processing without the element in question. If this is a real sitution, I would offer we would be better served with = a mechanism similar to the machinery described by RFC 3459. Say what we = mean, and if a sender sends something the recipient MUST understand, = mark it as such. If a sender sends optional, "value added" information = that can be ignored, mark it as such. Otherwise: Parsers that encounter an unrecognized element in a namespace that they do support MUST reject the document as a syntax error. 5.2. Extending Classes [...] 5. Implementations SHOULD NOT download schemas at runtime due to the security implications, and extensions MUST NOT be required to provide a resolvable location of their schema. This is incompatible with "The IODEF document ... SHOULD be validated." = Is it really validated or is it not? I would offer this gets deployed = in the real world: it will NOT be validated. That said, paragraph 5 does = not help the implmentor. We need some meat around the strictures. For = example: 5. There are security implications of requiring implementations to dynamically download schemas at run time. For example, malformed IODEF documents may launch a denial of service attack on a recipient by specifying bogus or numerous schema definition references in the document. Thus, implementations SHOULD NOT download schemas at runtime, unless implementations take appropriate precautions and are prepared for potentially = significant network, processing, and time-out demands. 6. Some users of the IODEF may have private schema definitions that might not be available on the Internet. In this situation, if a IODEF document leaks out of the private use space, references to some of those document schemas may not be resolvable. This has two implications. First, references to private schemas may never resolve. As such, in addition to the suggestion that implementations do not download schemas at runtime mentioned above, recipients MUST be prepared for a schema definition in an IODEF document never to resolve. I think the new #6 above is what we are really saying when we say, = "extensions MUST NOT be required to provide a resolvable location of = their schema." If I am wrong, then the old #5 is not clear and needs to = be fixed. 6. Internationalization Issues [...] The IODEF parser SHOULD extract the appropriate language relevant to the recipient. Two schools of thought. The first is this is an implentation issue: The IODEF parser can extract the appropriate language relevant to the recipient. - or - The IODEF parser extracts the most relevant language for the recipient. The second school of thought is this is a protocol issue: The IODEF parser MUST extract the appropriate language relevant to the recipient or return an error to the sender. I do not like this approach. RECOMMENDED's, all in Section 5.2, Extending Classes: [...] It is RECOMMENDED that the extension be placed in the most closely related class to the new information. Unless what? Will there ever be extensions that are not related to any = existing class? Say so if so. 2. The extension schema MUST declare a separate namespace. It is RECOMMENDED that these extensions have the prefix "iodef-". Sensible, but let us at least say why: 2. The extension schema MUST declare a separate namespace. It is RECOMMENDED that these extensions have the prefix "iodef-". This recommendation makes readability of the document easier by allowing the reader to infer which namespaces relate to IODEF by inspection. 3. It is RECOMMENDED that extension schemas follow the naming convention of the IODEF data model. The names of all elements are capitalized. For composed names, a capital letter is used for each word. Attribute names are lower case. Again, sensible, and again we should say why: 3. It is RECOMMENDED that extension schemas follow the naming convention of the IODEF data model. This makes reading an extended IODEF document look like any other IODEF document. The names of all elements are capitalized. For composed names, a capital letter is used for each word. Attribute names are = lower case.= --Apple-Mail=_02649D8A-869C-4816-A4B4-13F862C5E8C4 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----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) iQIcBAEBAgAGBQJRWZk/AAoJEDY/T2tCIPW3Cj4P/1h3xJuQu1lCu89SinttiERt xoF2YMCWNi41VzuudDvf/Nbw3AoSh4KTT2uY/5WQXIy9x6oCY6/FbnQT+n3tqCRw KAuKHxfPxOZEKS6khZ7TSUZixPhYObrE/ifNg0/ywjJQtmyRt2eVz7rz/sp+KeWX rHSponI79VygoSKk+kEEgpVEm1IMzCocPr8oksltYD1QyFfVgPAkKKZAYwIl0/CC lqqHHnXtEgJ3d+qJtA8t3NQlm+MpWCSSfSChBngJQL/EM09Dh9/Tub9sTyt4UR+j +lsj0DBY6dMLpT1FU8dgAWhStnfk0tJSsn5Gw87xhOqtEttd4NUHyM0y4CmYYuNk /kq/EtyspHq4YeBrw0RibQqBJo1H14/UVfXb6btC22TkxTuQ30PsTxNDsuwv2gkI rH8RTKZJ4wpagpwgo/O4vA0dhtiiP5nsjZsWt4qoUFrDZWwVAsWBU8aXOVZenbp2 naw1GNtRDZ1sREyqZpg5eyr5V/OH0tjKx9zCy60V5mYXezeR1z/x/6aia9GbbWwJ NyTYdea8hWwTQT8Ht4Kg5vnDhuvNP5Yw1rrh25cKXr4JTAyInz52yWqBWF7Xl6vJ 0QRq++bBpkfvupMXWQjh+e7LNRTN/q4FxqCBHmpz9BT0Fm/8KJt3LMUmNB/fzrNP gCLkS3V/k+jH8IcDTF4E =I1If -----END PGP SIGNATURE----- --Apple-Mail=_02649D8A-869C-4816-A4B4-13F862C5E8C4-- From johnp.field@emc.com Tue Apr 2 06:57:26 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 F156821F87D0 for ; Tue, 2 Apr 2013 06:57:25 -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=[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 9ACLnl37KmH8 for ; Tue, 2 Apr 2013 06:57:20 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 2582321F84F8 for ; Tue, 2 Apr 2013 06:57:19 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r32DvHgD019151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 2 Apr 2013 09:57:19 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd03.lss.emc.com [10.254.221.145]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor) for ; Tue, 2 Apr 2013 09:56:59 -0400 Received: from mxhub04.corp.emc.com (mxhub04.corp.emc.com [10.254.141.106]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r32DuxhA012924 for ; Tue, 2 Apr 2013 09:56:59 -0400 Received: from mx14a.corp.emc.com ([169.254.1.183]) by mxhub04.corp.emc.com ([10.254.141.106]) with mapi; Tue, 2 Apr 2013 09:56:58 -0400 From: "Field, John" To: "Moriarty, Kathleen" , "mile@ietf.org" Date: Tue, 2 Apr 2013 09:56:57 -0400 Thread-Topic: Updated charter for review Thread-Index: Ac4qYye3LkhMGx3rQjuIbJ1ARFHetAAGQt7AAUqL+pA= Message-ID: References: In-Reply-To: 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_B7873C71FEFD6E41B5468506E231FB6E012C50D13FMX14Acorpemcc_" MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [mile] Updated charter for review 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, 02 Apr 2013 13:57:26 -0000 --_000_B7873C71FEFD6E41B5468506E231FB6E012C50D13FMX14Acorpemcc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Kathleen, Thanks. Overall I think the charter looks good. I do have two comments/suggestions for the group's consideration. First, I= would add one additional sentence at the very beginning, as shown below. = In addition, I would add some additional text into the 4th paragraph. (Jus= t in case of CR/LF issues, the 4th paragraph is the paragraph that describe= s an incident). Here is the charter text with my suggested changes. Thanks, John An incident is an unplanned event that occurs in an information infrast= ructure. An incident could be a benign configuration issue, IT incident, an infraction to a service level agreement (SLA), a system compromise, socially engineered phishing attack, or a denial-of-service (DoS) attack, etc. When an incident is detected, the or suspected, there may be a need for organizations to collaborate. This collaboration effort may take several forms including joint analys= is, Information dissemination, and/or a coordinated operational response. Examples of response may include simply filing a report, notification to the source = of the incident, a request to a third party for resolution/mitigation, information sharing on identified indicators of compromise, or a request to locate the source. IODEF defines a data representation that provides a standard format for sharing information commonly exchanged about computer security incidents, which includes indicators with or without = the relevant context information. IODEF will be updated to meet the curren= t and future needs, maintaining the built in extensibility, of information sh= aring where indicators with rich context for actionable sharing is provided. RID enables the secure exchange of incident related information in an I= ODEF format providing options for security, privacy, and policy setting. MILE leverages collaboration and sharing experiences with prior work including the IODEF data model detailed in the IODEF, existing extensio= ns to the IODEF for Anti-phishing (RFC5901), and RID (RFC6545, RFC6546) fo= r the secure exchange of information. MILE will also leverage the experi= ence gained in using IODEF and RID in operational contexts. The MILE working group provides coordination for IODEF and RID extensio= ns that improve capabilities for exchanging indicator and incident information. MILE's objectives include the update of IODEF coupled with guidance inf= ormation to enhance interoperability, deployment ease, and applicability to curr= ent information security data sharing use cases. MILE will also describe a generalization of RID for secure exchange of other security-relevant XM= L formats. MILE will produce additional guidance needed for the successfu= l exchange of indicator and incident information for new use cases accord= ing to policy, security, and privacy requirements. Finally, MILE produced a document template with guidance for defining IODEF extensions to be followed whe= n producing extensions to IODEF as appropriate. From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Mor= iarty, Kathleen Sent: Tuesday, March 26, 2013 8:00 PM To: mile@ietf.org Subject: Re: [mile] Updated charter for review The good news, people are reading it, however, I sent out the wrong version= . The corrected one is included in this message. Please provide feedback over the next 2 weeks. We'll move the charter to t= he next stage in the approval process after April 9th. Thank you! Kathleen Managed Incident Lightweight Exchange (mile) -------------------------------------------- Charter Current Status: Active Chairs: Kathleen Moriarty Brian Trammell Security Area Directors: Stephen Farrell Sean Turner Security Area Advisor: Sean Turner Mailing Lists: General Discussion: mile@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/mile Archive: http://www.ietf.org/mail-archive/web/mile/ Description of Working Group: The Managed Incident Lightweight Exchange (MILE) working group develops standards for the purpose of improving incident and indicator informati= on sharing and handling capabilities. The Incident Object Description Exchange Format (IODEF) in RFC5070 and Real-time Inter-netw= ork Defense (RID) in RFC6045 were developed in the INCH working group by international Computer Security Incident Response Teams (CSIRTs) and industry to meet the needs of a global community interested in sharing, handling, and exchanging incident and indicator information. The working group will define enhancements and extensions to IODEF and = RID and provide guidance for applying them. It will also focus on improving= the interoperability of existing and new IODEF implementations, and the interoperation of IODEF and its extensions and enhancements with relate= d standards for information sharing. The extensions and guidance created = by the MILE working group assist with the daily operations of CSIRTs at an organization, service providers, law enforcement, and at the national l= evel. The working group has completed Proposed Standard revisions of RID (RFC= 6545) and RID transport (RFC 6546). This transport was designed to meet speci= fic usage requirements of CSIRTs and related industry groups. In order to meet di= fferent usage requirements for other communities, the working group will consid= er alternate transport or bindings for RID and IODEF information. An incident could be a benign configuration issue, IT incident, an infraction to a service level agreement (SLA), a system compromise, socially engineered phishing attack, or a denial-of-service (DoS) attack, etc. When an incident is detected, the response may include simply filing a report, notification to the source of the incident, a request to a third party for resolution/mitigation, information sharing on identified indicators of compromise, or a request to locate the source. IODEF defines a data representation that provides a standard format for sharing information commonly exchanged about computer security incidents, which includes indicators with or without = the relevant context information. IODEF will be updated to meet the curren= t and future needs, maintaining the built in extensibility, of information sh= aring where indicators with rich context for actionable sharing is provided. RID enables the secure exchange of incident related information in an I= ODEF format providing options for security, privacy, and policy setting. MILE leverages collaboration and sharing experiences with prior work including the IODEF data model detailed in the IODEF, existing extensio= ns to the IODEF for Anti-phishing (RFC5901), and RID (RFC6545, RFC6546) fo= r the secure exchange of information. MILE will also leverage the experi= ence gained in using IODEF and RID in operational contexts. The MILE working group provides coordination for IODEF and RID extensio= ns that improve capabilities for exchanging indicator and incident information. MILE's objectives include the update of IODEF coupled with guidance inf= ormation to enhance interoperability, deployment ease, and applicability to curr= ent information security data sharing use cases. MILE will also describe a generalization of RID for secure exchange of other security-relevant XM= L formats. MILE will produce additional guidance needed for the successfu= l exchange of indicator and incident information for new use cases accord= ing to policy, security, and privacy requirements. Finally, MILE produced a document template with guidance for defining IODEF extensions to be followed whe= n producing extensions to IODEF as appropriate. [Removed laundry list of drafts -- outdated. We should update the miles= tones below as well] Goals and Milestones: Done - WGLC Real-time Inter-network Defense (RID) Done - WGLC Transport for Real-time Inter-network Defense (RID) Done - Submit Real-time Inter-network Defense (RID) to IESG for consi= deration as Standards Track document Done - Submit Transport Real-time Inter-network Defense (RID) to IESG= for consideration as Standards Track document Done - WGLC Template for extensions to IODEF Done - WGLC IODEF Extensions in IANA XML Registry Apr 2013 - WGLC IODEF Extension to support structured cybersecurity infor= mation Done - Submit Template for extensions to IODEF to IESG for considerat= ion as Informational document Done - Submit IODEF Extensions in IANA XML Registry to IESG for consi= deration as Standards Track document Jun 2013 - Submit IODEF Extension to support structured cybersecurity inf= ormation to IESG for consideration as Standards Track document. TBD - WGLC RFC 5070bis TBD - Submit RFC 5070bis to IESG for consideration as a Standards Tr= ack document TBD - WGLC IODEF Reference Format TBD - Submit IODEF Reference Format to IESG for consideration as a S= tandards Track document TBD - WGLC Resource-Oriented Indicator Exchange TBD - Submit Resource-Oriented Indicator Exchange to IESG for consid= eration as a Standards Track document [ old milestone bits below ] [no doc]- WGLC IODEF Guidance [no doc] - Submit IODEF Extension Labeling for data protection, retention= , policies, and regulations to IESG for consideration as Standards Track do= cument [no doc] - Submit WGLC IODEF Guidance to IESG for consideration as Inform= ational document May 2012 - WGLC GRC Report Exchange [stalled] Jun 2012 - Submit GRC Report Exchange to IESG for consideration as Standa= rds Track document [stalled] Jun 2012 - WGLC Forensics extension [stalled] Jul 2012 - Submit IODEF Forensics extension to IESG for consideration as = Standards Track document [stalled] From: mile-bounces@ietf.org [mailto:mile-boun= ces@ietf.org] On Behalf Of Moriarty, Kathleen Sent: Tuesday, March 26, 2013 4:48 PM To: mile@ietf.org Subject: [mile] Updated charter for review As discussed at the MILE meeting, we need to revise the charter. Brian and= I updated the charter and it is attached for review and comment to the lis= t. Thank you in advance! Best regards, Kathleen & Brian [Outdated draft charter deleted] --_000_B7873C71FEFD6E41B5468506E231FB6E012C50D13FMX14Acorpemcc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Kathleen,=

 =

Thanks. 

Overall I think the charter looks good. 

 

I do have two comments/suggestions for the groupR= 17;s consideration.  First, I would add one additional sentence at the= very beginning, as shown below.  In addition, I would add some additi= onal text into the 4th paragraph.  (Just in case of CR/LF i= ssues, the 4th paragraph is the paragraph that describes an inci= dent).

 

Here is the charter text with my sugge= sted changes. 

 

Thanks,

John

 

 

    <= add text>

   =  An incident is an unplanned event that occurs in an information infra= structure.

   &l= t;/add text>

 = ;

    An inciden= t could be a benign configuration issue, IT incident, an<= /p>

    infraction to a service l= evel agreement (SLA), a system compromise,

    socially engineered phishing attack, or= a denial-of-service (DoS)

    attack, etc.  When an incident is detected, <= /o:p>

 

   <delete text><= /span>

    the

    </delete tex= t>

 

    <add text>

    or suspect= ed, there may be a need for organizations to collaborate.=

    This collaboration effor= t may take several forms including joint analysis,  =

    Information dissemi= nation, and/or a coordinated operational response.  =

    Examples of  <= o:p>

   </add= text>

 

   response may inc= lude simply filing a report, notification to the source of the incident, a<= o:p>

    request= to a third party for resolution/mitigation, information sharing=

    on identified ind= icators of compromise, or a request to

    locate the source.  IODEF defines a da= ta representation that provides a

    standard format for sharing information commonly= exchanged about

 &nb= sp;  computer security incidents, which includes indicators with or wi= thout the

  &nbs= p; relevant context information.  IODEF will be updated to meet the cu= rrent and

  &nbs= p; future needs, maintaining the built in extensibility, of information sha= ring

    wh= ere indicators with rich context for actionable sharing is provided.

    RID enables t= he secure exchange of incident related information in an IODEF

    format providing op= tions for security, privacy, and policy setting.

 

    MILE leverages collaboration and sharing experiences= with prior work

 &nb= sp;  including the IODEF data model detailed in the IODEF, existing ex= tensions

   = ; to the IODEF for Anti-phishing (RFC5901), and RID (RFC6545, RFC6546) for<= o:p>

    the sec= ure exchange of information.  MILE will also leverage the experience

    gained i= n using IODEF and RID in operational contexts.

    

    The MILE working group provide= s coordination for IODEF and RID extensions that

    improve capabilities for exchangi= ng indicator and incident information.

    MILE's objectives include the update of IOD= EF coupled with guidance information

    to enhance interoperability, deployment ease,= and applicability to current

    information security data sharing use cases. MILE wi= ll also describe a

 &= nbsp;  generalization of RID for secure exchange of other security-rel= evant XML

  &nbs= p; formats. MILE will produce additional guidance needed for the successful=

    exchan= ge of indicator and incident information for new use cases according to pol= icy,

    se= curity, and privacy requirements. Finally, MILE produced a document

    template with = guidance for defining IODEF extensions to be followed when

    producing extensions to= IODEF as appropriate.

 

 

 

 

Fr= om: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of= Moriarty, Kathleen
Sent: Tuesday, March 26, 2013 8:00 PM
= To: mile@ietf.org
Subject: Re: [mile] Updated charter for = review

 

The good news, people are reading it, ho= wever, I sent out the wrong version.  The corrected one is included in= this message.

 =

Please provide feedback over t= he next 2 weeks.  We’ll move the charter to the next stage in th= e approval process after April 9th. 

=

 

Thank you!

Kath= leen

 

Managed Incident Lightweight Exchange (m= ile)

---------------------= -----------------------

 

Charter

 

Current Status: Active

 

Chai= rs:

   &nbs= p; Kathleen Moriarty

&nbs= p;    Brian Trammell

 

Sec= urity Area Directors:

&nbs= p;    Stephen Farrell

     Sean Turner

 

Security Area Advisor:

=      Sean Turner

 

Mailing Lists:

 &nbs= p;   General Discussion: mile@ie= tf.org

  &nb= sp;  To Subscribe:       https://www.ietf.org/mailman/listin= fo/mile

  &n= bsp;  Archive:         &n= bsp;  http://ww= w.ietf.org/mail-archive/web/mile/

 

Descrip= tion of Working Group:

 

 

    The Managed Inci= dent Lightweight Exchange (MILE) working group develops

    standards for the purpose = of improving incident and indicator information

    sharing and handling capabilities.= The Incident Object

&nbs= p;   Description Exchange Format (IODEF) in RFC5070 and Real-time= Inter-network

  = ;  Defense (RID) in RFC6045 were developed in the INCH working group b= y

    inter= national Computer Security Incident Response Teams (CSIRTs) and<= /span>

    industry to meet t= he needs of a global community interested in sharing,

=

    handling, and exchanging inc= ident and indicator information.

    

=     The working group will define enhancements a= nd extensions to IODEF and RID

    and provide guidance for applying them. It will als= o focus on improving the

&= nbsp;   interoperability of existing and new IODEF implementation= s, and the

  &nb= sp; interoperation of IODEF and its extensions and enhancements with relate= d

    stand= ards for information sharing. The extensions and guidance created by

    the MILE work= ing group assist with the daily operations of CSIRTs at an

    organization, service p= roviders, law enforcement, and at the national level.

=

   

    The working group has complet= ed Proposed Standard revisions of RID (RFC 6545)

    and RID transport (RFC 6546). Thi= s transport was designed to meet specific usage

    requirements of CSIR= Ts and related industry groups. In order to meet different

    usage requirements for other communities, the working group will consi= der

    alt= ernate transport or bindings for RID and IODEF information.

   

=

    An incident could be a = benign configuration issue, IT incident, an

    infraction to a service level agreem= ent (SLA), a system compromise,

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'>    socially engineered phishing attack, or a denial-o= f-service (DoS)

 &nbs= p;  attack, etc.  When an incident is detected, the response may = include

   = simply filing a report, notification to the source of the incident, a=

    request to = a third party for resolution/mitigation, information sharing

    on identified indicat= ors of compromise, or a request to

    locate the source.  IODEF defines a data r= epresentation that provides a

    standard format for sharing information commonly exc= hanged about

  &= nbsp; computer security incidents, which includes indicators with or withou= t the

    r= elevant context information.  IODEF will be updated to meet the curren= t and

    f= uture needs, maintaining the built in extensibility, of information sharing=

    where = indicators with rich context for actionable sharing is provided.=

    RID enables the s= ecure exchange of incident related information in an IODEF

    format providing option= s for security, privacy, and policy setting.

   

    MILE leverages collaboration and shar= ing experiences with prior work

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'>    including the IODEF data model detailed in the IOD= EF, existing extensions

&n= bsp;   to the IODEF for Anti-phishing (RFC5901), and RID (RFC6545= , RFC6546) for

  = ;  the secure exchange of information.  MILE will also leverage t= he experience

  =   gained in using IODEF and RID in operational contexts.

    

    The MILE workin= g group provides coordination for IODEF and RID extensions that<= /span>

    improve capabiliti= es for exchanging indicator and incident information.

=

    MILE's objectives include th= e update of IODEF coupled with guidance information

    to enhance interoperability, d= eployment ease, and applicability to current

    information security data sharing us= e cases. MILE will also describe a

    generalization of RID for secure exchange of ot= her security-relevant XML

=     formats. MILE will produce additional guidance needed fo= r the successful

 &nb= sp;  exchange of indicator and incident information for new use cases = according to policy,

&nbs= p;   security, and privacy requirements. Finally, MILE produced a= document

  &nbs= p; template with guidance for defining IODEF extensions to be followed when=

    produc= ing extensions to IODEF as appropriate.

 

&nbs= p;   [Removed laundry list of drafts -- outdated. We should updat= e the milestones below as well]

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'> 

Goals and Mil= estones:

  Done =     - WGLC Real-time Inter-network Defense (RID)<= /span>

  Done     -= WGLC Transport for Real-time Inter-network Defense (RID)=

  Done     - Submi= t Real-time Inter-network Defense (RID) to IESG for consideration as Standa= rds Track document

  = Done     - Submit Transport Real-time Inter-network Def= ense (RID) to IESG for consideration as Standards Track document=

  Done     = - WGLC Template for extensions to IODEF

  Done     - WGLC IODEF Extensions i= n IANA XML Registry

&nbs= p; Apr 2013 - WGLC IODEF Extension to support structured cybersecurity info= rmation

  Done &= nbsp;   - Submit Template for extensions to IODEF to IESG for con= sideration as Informational document

  Done     - Submit IODEF Extensions in= IANA XML Registry to IESG for consideration as Standards Track document

  Jun 2013 - Submit IOD= EF Extension to support structured cybersecurity information to IESG for co= nsideration as Standards Track document.

  TBD      - WGLC RFC 5070bis<= o:p>

  TBD  &nbs= p;   - Submit RFC 5070bis to IESG for consideration as a Standard= s Track document

  TB= D      - WGLC IODEF Reference Format

  TBD     = ; - Submit IODEF Reference Format to IESG for consideration as a Standards = Track document

  TBD&= nbsp;     - WGLC Resource-Oriented Indicator Exchange

  TBD   = ;   - Submit Resource-Oriented Indicator Exchange to IESG for con= sideration as a Standards Track document

 

&nb= sp; [ old milestone bits below ]

 

&nbs= p; [no doc]- WGLC IODEF Guidance

  [no doc] - Submit IODEF Extension Labeling for data prot= ection, retention, policies, and regulations to IESG for consideration as S= tandards Track document

&n= bsp; [no doc] - Submit WGLC IODEF Guidance to IESG for consideration as Inf= ormational document

&nbs= p; May 2012 - WGLC GRC Report Exchange [stalled]

  Jun 2012 - Submit GRC Report Exchange to IESG= for consideration as Standards Track document [stalled]<= /p>

  Jun 2012 - WGLC Forensics extension [= stalled]

  Jul 2012 -= Submit IODEF Forensics extension to IESG for consideration as Standards Tr= ack document [stalled]

 

From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of <= /b>Moriarty, Kathleen
Sent: Tuesday, March 26, 2013 4:48 PM
To: mile@ietf.org
Subject:<= /b> [mile] Updated charter for review

 

As discussed at the MILE me= eting, we need to revise the charter.  Brian and I updated the charter= and it is attached for review and comment to the list.

 

Thank you in = advance!

 

Best regards,

Kathlee= n & Brian

 =

 

&n= bsp;[Outdated draft charter deleted]=

 

<= /html>= --_000_B7873C71FEFD6E41B5468506E231FB6E012C50D13FMX14Acorpemcc_-- From takeshi_takahashi@nict.go.jp Wed Apr 3 04:08: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 58A2821F8A6D for ; Wed, 3 Apr 2013 04:08:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.055 X-Spam-Level: X-Spam-Status: No, score=-0.055 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_EQ_JP=1.244] 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 WyWFc5iIzHE0 for ; Wed, 3 Apr 2013 04:08:04 -0700 (PDT) Received: from ns2.nict.go.jp (ns2.nict.go.jp [IPv6:2001:df0:232:300::2]) by ietfa.amsl.com (Postfix) with ESMTP id 04A4721F8A91 for ; Wed, 3 Apr 2013 04:08:03 -0700 (PDT) Received: from gw2.nict.go.jp (gw2 [133.243.18.251]) by ns2.nict.go.jp with ESMTP id r33B82dP028789; Wed, 3 Apr 2013 20:08:02 +0900 (JST) Received: from gw2.nict.go.jp (localhost [127.0.0.1]) by gw2.nict.go.jp with ESMTP id r33B82Rl002733; Wed, 3 Apr 2013 20:08:02 +0900 (JST) Received: from mail1.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw2.nict.go.jp with ESMTP id r33B81Ii002730; Wed, 3 Apr 2013 20:08:01 +0900 (JST) Received: from mail1.nict.go.jp (localhost [127.0.0.1]) by mail1.nict.go.jp (NICT Mail) with ESMTP id AEFD716843; Wed, 3 Apr 2013 20:08:01 +0900 (JST) Received: from VAIO (unknown [133.243.119.109]) by mail1.nict.go.jp (NICT Mail) with ESMTP id A80421679B; Wed, 3 Apr 2013 20:08:01 +0900 (JST) From: "Takeshi Takahashi" To: "'Eric Burger'" , "'Martin, Robert A.'" References: , <1C9F17D1873AFA47A969C4DD98F98A751926C4@xmb-rcd-x10.cisco.com> <8D3D17ACE214DC429325B2B98F3AE71290FA9202@MX15A.corp.emc.com> <000601ce279e$c8ab7940$5a026bc0$@nict.go.jp> <1CBD9BD3-18CF-4787-B13E-3288FCB68AE0@cs.georgetown.edu> <5271802E-3724-426D-8DB8-E4718B0092AD@standardstrack.com> <51543918.1050605@mitre.org> In-Reply-To: Date: Wed, 3 Apr 2013 20:08:09 +0900 Message-ID: <011801ce305b$86b04820$9410d860$@nict.go.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFCibkFcoiRAxGJUwOvO7kpytpEUwHYmM6bAq+IVDUBugT0/gGrVkJYAnN+UnMBXPoi3AJ6PqwpAmZS0DEBsQWkKQKeNtMamTQyUQA= Content-Language: ja Cc: mile@ietf.org Subject: Re: [mile] Consensus Call - SCI draft MMDEF as MTI 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, 03 Apr 2013 11:08:05 -0000 Hi Eric, Thank you for your kind email. Yes, this is an issue that had been bothered us. I appreciate your kind consideration. I understood that we have somehow agreed to use MMDEF as an MTI, though it is not an official IEEE standard, because the link seems to be stable (with version control). Do I need to change the above understanding? Hopefully not, but if necessary, we need to do that. If so, I am not sure what would be a feasible approach for that. One approach is, as you have suggested, to use MMDEF as an MTI and reference it as an informative reference. Alternatively, could we include the schema of the MMDEF so that the draft itself can become a stable reference? (of course, we need to ask permission to the MMDEF community.) The name space could be changed to http://www.ietf.org/draft-IODEF-SCI-mti, for instance. The purpose of having MTI is to check interoperability, thus the above approach could be ok, I guess. I would appreciate any assistance or guidance. Thank you. Take > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of > Eric Burger > Sent: Monday, April 1, 2013 9:36 PM > To: Martin, Robert A. > Cc: mile@ietf.org > Subject: Re: [mile] Consensus Call - SCI draft MMDEF as MTI > > Next week that URI can change. It is not an IEEE standard, so there is no > P number. Since it is not an IEEE standard, you cannot buy or reference > the spec from IEEE. > > Is there someone involved with the MMDEF work who can find out about a stable > reference? We don't need an RFC, but we do need something that is likely > to be there next month. An individual informational RFC would work, too. > > Another alternative is to do a wink and a nudge and have IODEF say there > are things out there for malware identification. One could use something > *like* MMDEF which you *might* be able to find at the IEEE-SA industry site. > It would be an informative reference, so there would be no violation of > IETF rules. That approach will not promise long-term interoperability, > but it is better than nothing. > > On Mar 28, 2013, at 8:35 AM, "Martin, Robert A." wrote: > > > This page would seem to provide that. > > > > > > > > On 3/27/13 10:25 PM, Eric Burger wrote: > >> Did we ever find a stable reference for MMDEF? > >> > >> On Mar 27, 2013, at 8:59 PM, "Moriarty, Kathleen" > wrote: > >> > >>> Hello, > >>> > >>> Thank you for voicing your opinions at the MILE meeting, the two week > period is up and we have full agreement. We will move forward with MMDEF > as the MTI for the SCI draft. > >>> > >>> Take - Thank you for updating the draft to include MMDEF as the MTI > as well as the update below. Could you expand the acronym for MTI in the > draft and update the version to the latest? > >>> > >>> Bets regards, > >>> Kathleen > >>> > >>> -----Original Message----- > >>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf > >>> Of Takeshi Takahashi > >>> Sent: Saturday, March 23, 2013 4:17 AM > >>> To: mile@ietf.org > >>> Subject: Re: [mile] Consensus Call - SCI draft MMDEF as MTI > >>> > >>> Hi all, > >>> > >>> I remember the discussion on the EICAR and agree upon David's kind > >>> suggestion. > >>> The attached is the revised SCI draft, whose section 10 talks about > >>> the EICAR (with an example XML). > >>> > >>> Kind regards, > >>> Take > >>> > >>> > >>>> -----Original Message----- > >>>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On > >>>> Behalf Of Black, David > >>>> Sent: Thursday, March 14, 2013 11:54 PM > >>>> To: Moriarty, Kathleen; mile@ietf.org > >>>> Subject: Re: [mile] Consensus Call - SCI draft MMDEF as MTI > >>>> > >>>> I support MMDEF as the MTI, and since MMDEF is a malware spec, I'd > >>>> like to resurrect a previously-discussed suggestion that the SCI > >>>> draft include discussion of the "EICAR Standard Anti-Virus Test > >>>> File" as a specific > >>> example > >>>> that SHOULD (or MUST?) be supported for black-box testing purposes. > >>>> > >>>> See: http://www.eicar.org/86-0-Intended-use.html > >>>> > >>>> Thanks, > >>>> --David > >>>> > >>>>> -----Original Message----- > >>>>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On > >>>>> Behalf Of Moriarty, Kathleen > >>>>> Sent: Thursday, March 14, 2013 10:38 AM > >>>>> To: Panos Kampanakis (pkampana); mile@ietf.org > >>>>> Subject: Re: [mile] Consensus Call - SCI draft MMDEF as MTI > >>>>> > >>>>> Hello Panos, > >>>>> > >>>>> Thank you for joining us remotely! The recording is available for > >>>>> those who were not able to attend during the session. > >>>>> > >>>>> We need to choose one included schema as MTI for 'black box' > >>>>> testing of the method described. Essentially, if you can exchange > >>>>> using the MTI spec, then any other specs supported should > >>>>> theoretically work as the pattern has been established. > >>>>> > >>>>> MMDEF was recommended as it is in use by the eCrime WG as an > >>>> extension > >>>>> to IODEF/RFC5901. It replaced the method to include malware in > >>>>> exchanges and seemed to make sense to adopt more broadly as it is > >>>>> maintained by a group in IEEE focused on that particular problem. > >>>>> > >>>>> BTW, I meant to say the last call will end in two weeks from > >>>>> yesterday, Wednesday March 27th. > >>>>> > >>>>> Thank you! > >>>>> Kathleen > >>>>> ________________________________________ > >>>>> From: Panos Kampanakis (pkampana) [pkampana@cisco.com] > >>>>> Sent: Thursday, March 14, 2013 9:59 AM > >>>>> To: Moriarty, Kathleen; mile@ietf.org > >>>>> Subject: RE: Consensus Call - SCI draft MMDEF as MTI > >>>>> > >>>>> I agree with MMDEF included in SCI. > >>>>> I am not sure why it must be MTI. Due to some audio problems I > >>>>> missed part of the call yesterday. Can you briefly summarize why > >>>>> we want it > >>> MTI? > >>>>> > >>>>> -----Original Message----- > >>>>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On > >>>>> Behalf Of Moriarty, Kathleen > >>>>> Sent: Wednesday, March 13, 2013 3:04 PM > >>>>> To: mile@ietf.org > >>>>> Subject: [mile] Consensus Call - SCI draft MMDEF as MTI > >>>>> > >>>>> Hello, > >>>>> > >>>>> In today's MILE session, a call for consensus began to include > >>>>> MMDEF in the SCI draft as the mandatory-to-implement (MTI) > specification. > >>>>> The call for consensus will last for 2 weeks and we ask that you > >>> contribute > >>>> your opinion. > >>>>> The vote in the room was unanimous and we want to make sure we > >>>>> hear from participants not in attendance. > >>>>> > >>>>> Poll will end on Wednesday next week. > >>>>> > >>>>> Thank you! > >>>>> Kathleen > >>>>> _______________________________________________ > >>>>> 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 > >>> _______________________________________________ > >>> 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 > > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From eburger@standardstrack.com Wed Apr 3 17:40:08 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 D148321F900D for ; Wed, 3 Apr 2013 17:40:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.799 X-Spam-Level: X-Spam-Status: No, score=-101.799 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, 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 f81qDhiqE3UG for ; Wed, 3 Apr 2013 17:40:07 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [173.247.246.237]) by ietfa.amsl.com (Postfix) with ESMTP id 8B32C21F8F0A for ; Wed, 3 Apr 2013 17:40:07 -0700 (PDT) Received: from ip68-100-199-8.dc.dc.cox.net ([68.100.199.8]:57311 helo=[192.168.15.177]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1UNYDm-00030p-Bg; Wed, 03 Apr 2013 17:40:06 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Eric Burger In-Reply-To: <011801ce305b$86b04820$9410d860$@nict.go.jp> Date: Wed, 3 Apr 2013 19:00:21 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: , <1C9F17D1873AFA47A969C4DD98F98A751926C4@xmb-rcd-x10.cisco.com> <8D3D17ACE214DC429325B2B98F3AE71290FA9202@MX15A.corp.emc.com> <000601ce279e$c8ab7940$5a026bc0$@nict.go.jp> <1CBD9BD3-18CF-4787-B13E-3288FCB68AE0@cs.georgetown.edu> <5271802E-3724-426D-8DB8-E4718B0092AD@standardstrack.com> <51543918.1050605@mitre.org> <011801ce305b$86b04820$9410d860$@nict.go.jp> To: Takeshi Takahashi X-Mailer: Apple Mail (2.1503) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Cc: mile@ietf.org Subject: Re: [mile] Consensus Call - SCI draft MMDEF as MTI 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, 04 Apr 2013 00:40:08 -0000 The approach you mention, importing the markup, with permission, into an = appendix, is precisely what we did for RFC 6787. We imported the NLSML = markup once we found out that (1) no one planned to use EMMA and (2) the = W3C did not plan on publishing NLSML. On Apr 3, 2013, at 7:08 AM, Takeshi Takahashi = wrote: > Hi Eric, >=20 > Thank you for your kind email. > Yes, this is an issue that had been bothered us. > I appreciate your kind consideration. >=20 > I understood that we have somehow agreed to use MMDEF as an MTI, = though it > is not an official IEEE standard, because the link seems to be stable = (with > version control). > Do I need to change the above understanding? > Hopefully not, but if necessary, we need to do that. >=20 > If so, I am not sure what would be a feasible approach for that. > One approach is, as you have suggested, to use MMDEF as an MTI and = reference > it as an informative reference. >=20 > Alternatively, could we include the schema of the MMDEF so that the = draft > itself can become a stable reference? > (of course, we need to ask permission to the MMDEF community.) > The name space could be changed to = http://www.ietf.org/draft-IODEF-SCI-mti, > for instance. >=20 > The purpose of having MTI is to check interoperability, thus the above > approach could be ok, I guess. >=20 > I would appreciate any assistance or guidance. >=20 > Thank you. > Take >=20 >=20 >> -----Original Message----- >> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf = Of >> Eric Burger >> Sent: Monday, April 1, 2013 9:36 PM >> To: Martin, Robert A. >> Cc: mile@ietf.org >> Subject: Re: [mile] Consensus Call - SCI draft MMDEF as MTI >>=20 >> Next week that URI can change. It is not an IEEE standard, so there = is no >> P number. Since it is not an IEEE standard, you cannot buy or = reference >> the spec from IEEE. >>=20 >> Is there someone involved with the MMDEF work who can find out about = a > stable >> reference? We don't need an RFC, but we do need something that is = likely >> to be there next month. An individual informational RFC would work, = too. >>=20 >> Another alternative is to do a wink and a nudge and have IODEF say = there >> are things out there for malware identification. One could use = something >> *like* MMDEF which you *might* be able to find at the IEEE-SA = industry > site. >> It would be an informative reference, so there would be no violation = of >> IETF rules. That approach will not promise long-term = interoperability, >> but it is better than nothing. >>=20 >> On Mar 28, 2013, at 8:35 AM, "Martin, Robert A." > wrote: >>=20 >>> This page would seem to provide that. >>>=20 >>> >>>=20 >>> On 3/27/13 10:25 PM, Eric Burger wrote: >>>> Did we ever find a stable reference for MMDEF? >>>>=20 >>>> On Mar 27, 2013, at 8:59 PM, "Moriarty, Kathleen" >> wrote: >>>>=20 >>>>> Hello, >>>>>=20 >>>>> Thank you for voicing your opinions at the MILE meeting, the two = week >> period is up and we have full agreement. We will move forward with = MMDEF >> as the MTI for the SCI draft. >>>>>=20 >>>>> Take - Thank you for updating the draft to include MMDEF as the = MTI >> as well as the update below. Could you expand the acronym for MTI in = the >> draft and update the version to the latest? >>>>>=20 >>>>> Bets regards, >>>>> Kathleen >>>>>=20 >>>>> -----Original Message----- >>>>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On = Behalf >>>>> Of Takeshi Takahashi >>>>> Sent: Saturday, March 23, 2013 4:17 AM >>>>> To: mile@ietf.org >>>>> Subject: Re: [mile] Consensus Call - SCI draft MMDEF as MTI >>>>>=20 >>>>> Hi all, >>>>>=20 >>>>> I remember the discussion on the EICAR and agree upon David's kind >>>>> suggestion. >>>>> The attached is the revised SCI draft, whose section 10 talks = about >>>>> the EICAR (with an example XML). >>>>>=20 >>>>> Kind regards, >>>>> Take >>>>>=20 >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On >>>>>> Behalf Of Black, David >>>>>> Sent: Thursday, March 14, 2013 11:54 PM >>>>>> To: Moriarty, Kathleen; mile@ietf.org >>>>>> Subject: Re: [mile] Consensus Call - SCI draft MMDEF as MTI >>>>>>=20 >>>>>> I support MMDEF as the MTI, and since MMDEF is a malware spec, = I'd >>>>>> like to resurrect a previously-discussed suggestion that the SCI >>>>>> draft include discussion of the "EICAR Standard Anti-Virus Test >>>>>> File" as a specific >>>>> example >>>>>> that SHOULD (or MUST?) be supported for black-box testing = purposes. >>>>>>=20 >>>>>> See: http://www.eicar.org/86-0-Intended-use.html >>>>>>=20 >>>>>> Thanks, >>>>>> --David >>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On >>>>>>> Behalf Of Moriarty, Kathleen >>>>>>> Sent: Thursday, March 14, 2013 10:38 AM >>>>>>> To: Panos Kampanakis (pkampana); mile@ietf.org >>>>>>> Subject: Re: [mile] Consensus Call - SCI draft MMDEF as MTI >>>>>>>=20 >>>>>>> Hello Panos, >>>>>>>=20 >>>>>>> Thank you for joining us remotely! The recording is available = for >>>>>>> those who were not able to attend during the session. >>>>>>>=20 >>>>>>> We need to choose one included schema as MTI for 'black box' >>>>>>> testing of the method described. Essentially, if you can = exchange >>>>>>> using the MTI spec, then any other specs supported should >>>>>>> theoretically work as the pattern has been established. >>>>>>>=20 >>>>>>> MMDEF was recommended as it is in use by the eCrime WG as an >>>>>> extension >>>>>>> to IODEF/RFC5901. It replaced the method to include malware in >>>>>>> exchanges and seemed to make sense to adopt more broadly as it = is >>>>>>> maintained by a group in IEEE focused on that particular = problem. >>>>>>>=20 >>>>>>> BTW, I meant to say the last call will end in two weeks from >>>>>>> yesterday, Wednesday March 27th. >>>>>>>=20 >>>>>>> Thank you! >>>>>>> Kathleen >>>>>>> ________________________________________ >>>>>>> From: Panos Kampanakis (pkampana) [pkampana@cisco.com] >>>>>>> Sent: Thursday, March 14, 2013 9:59 AM >>>>>>> To: Moriarty, Kathleen; mile@ietf.org >>>>>>> Subject: RE: Consensus Call - SCI draft MMDEF as MTI >>>>>>>=20 >>>>>>> I agree with MMDEF included in SCI. >>>>>>> I am not sure why it must be MTI. Due to some audio problems I >>>>>>> missed part of the call yesterday. Can you briefly summarize why >>>>>>> we want it >>>>> MTI? >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On >>>>>>> Behalf Of Moriarty, Kathleen >>>>>>> Sent: Wednesday, March 13, 2013 3:04 PM >>>>>>> To: mile@ietf.org >>>>>>> Subject: [mile] Consensus Call - SCI draft MMDEF as MTI >>>>>>>=20 >>>>>>> Hello, >>>>>>>=20 >>>>>>> In today's MILE session, a call for consensus began to include >>>>>>> MMDEF in the SCI draft as the mandatory-to-implement (MTI) >> specification. >>>>>>> The call for consensus will last for 2 weeks and we ask that you >>>>> contribute >>>>>> your opinion. >>>>>>> The vote in the room was unanimous and we want to make sure we >>>>>>> hear from participants not in attendance. >>>>>>>=20 >>>>>>> Poll will end on Wednesday next week. >>>>>>>=20 >>>>>>> Thank you! >>>>>>> Kathleen >>>>>>> _______________________________________________ >>>>>>> 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 >>>>>>=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 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> mile mailing list >>>> mile@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mile >>>> . >>>>=20 >>> _______________________________________________ >>> mile mailing list >>> mile@ietf.org >>> https://www.ietf.org/mailman/listinfo/mile >>=20 >> _______________________________________________ >> mile mailing list >> mile@ietf.org >> https://www.ietf.org/mailman/listinfo/mile >=20 From takeshi_takahashi@nict.go.jp Wed Apr 3 17:54: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 A64A421F92E9 for ; Wed, 3 Apr 2013 17:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.705 X-Spam-Level: X-Spam-Status: No, score=-0.705 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HELO_EQ_JP=1.244] 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 9f87OJKcwTky for ; Wed, 3 Apr 2013 17:54:53 -0700 (PDT) Received: from ns2.nict.go.jp (ns2.nict.go.jp [IPv6:2001:df0:232:300::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7873A21F92DC for ; Wed, 3 Apr 2013 17:54:53 -0700 (PDT) Received: from gw2.nict.go.jp (gw2 [133.243.18.251]) by ns2.nict.go.jp with ESMTP id r340sq4O017168; Thu, 4 Apr 2013 09:54:52 +0900 (JST) Received: from gw2.nict.go.jp (localhost [127.0.0.1]) by gw2.nict.go.jp with ESMTP id r340sqWN007845; Thu, 4 Apr 2013 09:54:52 +0900 (JST) Received: from mail2.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw2.nict.go.jp with ESMTP id r340spJq007842; Thu, 4 Apr 2013 09:54:51 +0900 (JST) Received: from mail2.nict.go.jp (localhost [127.0.0.1]) by mail2.nict.go.jp (NICT Mail) with ESMTP id D1D1616106; Thu, 4 Apr 2013 09:54:51 +0900 (JST) Received: from VAIO (unknown [133.243.119.109]) by mail2.nict.go.jp (NICT Mail) with ESMTP id CB93E160BF; Thu, 4 Apr 2013 09:54:51 +0900 (JST) From: "Takeshi Takahashi" To: "'Eric Burger'" References: , <1C9F17D1873AFA47A969C4DD98F98A751926C4@xmb-rcd-x10.cisco.com> <8D3D17ACE214DC429325B2B98F3AE71290FA9202@MX15A.corp.emc.com> <000601ce279e$c8ab7940$5a026bc0$@nict.go.jp> <1CBD9BD3-18CF-4787-B13E-3288FCB68AE0@cs.georgetown.edu> <5271802E-3724-426D-8DB8-E4718B0092AD@standardstrack.com> <51543918.1050605@mitre.org> <011801ce305b$86b04820$9410d860$@nict.go.jp> In-Reply-To: Date: Thu, 4 Apr 2013 09:54:59 +0900 Message-ID: <003101ce30cf$0888f540$199adfc0$@nict.go.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFCibkFcoiRAxGJUwOvO7kpytpEUwHYmM6bAq+IVDUBugT0/gGrVkJYAnN+UnMBXPoi3AJ6PqwpAmZS0DEBsQWkKQKeNtMaAnL4LIkCHbpFjpkQlpNQ Content-Language: ja Cc: mile@ietf.org Subject: Re: [mile] Consensus Call - SCI draft MMDEF as MTI 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, 04 Apr 2013 00:54:54 -0000 Ok, then let me try to contact them. I will post some messages to MMDEF's mailing list. Hopefully they could give us a good answer. Let me come back to here later. Take > -----Original Message----- > From: Eric Burger [mailto:eburger@standardstrack.com] > Sent: Thursday, April 4, 2013 8:00 AM > To: Takeshi Takahashi > Cc: mile@ietf.org > Subject: Re: [mile] Consensus Call - SCI draft MMDEF as MTI > > The approach you mention, importing the markup, with permission, into an > appendix, is precisely what we did for RFC 6787. We imported the NLSML markup > once we found out that (1) no one planned to use EMMA and (2) the W3C did > not plan on publishing NLSML. > > On Apr 3, 2013, at 7:08 AM, Takeshi Takahashi > wrote: > > > Hi Eric, > > > > Thank you for your kind email. > > Yes, this is an issue that had been bothered us. > > I appreciate your kind consideration. > > > > I understood that we have somehow agreed to use MMDEF as an MTI, > > though it is not an official IEEE standard, because the link seems to > > be stable (with version control). > > Do I need to change the above understanding? > > Hopefully not, but if necessary, we need to do that. > > > > If so, I am not sure what would be a feasible approach for that. > > One approach is, as you have suggested, to use MMDEF as an MTI and > > reference it as an informative reference. > > > > Alternatively, could we include the schema of the MMDEF so that the > > draft itself can become a stable reference? > > (of course, we need to ask permission to the MMDEF community.) The > > name space could be changed to > > http://www.ietf.org/draft-IODEF-SCI-mti, > > for instance. > > > > The purpose of having MTI is to check interoperability, thus the above > > approach could be ok, I guess. > > > > I would appreciate any assistance or guidance. > > > > Thank you. > > Take > > > > > >> -----Original Message----- > >> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf > >> Of Eric Burger > >> Sent: Monday, April 1, 2013 9:36 PM > >> To: Martin, Robert A. > >> Cc: mile@ietf.org > >> Subject: Re: [mile] Consensus Call - SCI draft MMDEF as MTI > >> > >> Next week that URI can change. It is not an IEEE standard, so there > >> is no P number. Since it is not an IEEE standard, you cannot buy or > >> reference the spec from IEEE. > >> > >> Is there someone involved with the MMDEF work who can find out about > >> a > > stable > >> reference? We don't need an RFC, but we do need something that is > >> likely to be there next month. An individual informational RFC would > work, too. > >> > >> Another alternative is to do a wink and a nudge and have IODEF say > >> there are things out there for malware identification. One could use > >> something > >> *like* MMDEF which you *might* be able to find at the IEEE-SA > >> industry > > site. > >> It would be an informative reference, so there would be no violation > >> of IETF rules. That approach will not promise long-term > >> interoperability, but it is better than nothing. > >> > >> On Mar 28, 2013, at 8:35 AM, "Martin, Robert A." > > wrote: > >> > >>> This page would seem to provide that. > >>> > >>> > >>> > >>> On 3/27/13 10:25 PM, Eric Burger wrote: > >>>> Did we ever find a stable reference for MMDEF? > >>>> > >>>> On Mar 27, 2013, at 8:59 PM, "Moriarty, Kathleen" > >> wrote: > >>>> > >>>>> Hello, > >>>>> > >>>>> Thank you for voicing your opinions at the MILE meeting, the two > >>>>> week > >> period is up and we have full agreement. We will move forward with > >> MMDEF as the MTI for the SCI draft. > >>>>> > >>>>> Take - Thank you for updating the draft to include MMDEF as the > >>>>> MTI > >> as well as the update below. Could you expand the acronym for MTI in > >> the draft and update the version to the latest? > >>>>> > >>>>> Bets regards, > >>>>> Kathleen > >>>>> > >>>>> -----Original Message----- > >>>>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On > >>>>> Behalf Of Takeshi Takahashi > >>>>> Sent: Saturday, March 23, 2013 4:17 AM > >>>>> To: mile@ietf.org > >>>>> Subject: Re: [mile] Consensus Call - SCI draft MMDEF as MTI > >>>>> > >>>>> Hi all, > >>>>> > >>>>> I remember the discussion on the EICAR and agree upon David's kind > >>>>> suggestion. > >>>>> The attached is the revised SCI draft, whose section 10 talks > >>>>> about the EICAR (with an example XML). > >>>>> > >>>>> Kind regards, > >>>>> Take > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On > >>>>>> Behalf Of Black, David > >>>>>> Sent: Thursday, March 14, 2013 11:54 PM > >>>>>> To: Moriarty, Kathleen; mile@ietf.org > >>>>>> Subject: Re: [mile] Consensus Call - SCI draft MMDEF as MTI > >>>>>> > >>>>>> I support MMDEF as the MTI, and since MMDEF is a malware spec, > >>>>>> I'd like to resurrect a previously-discussed suggestion that the > >>>>>> SCI draft include discussion of the "EICAR Standard Anti-Virus > >>>>>> Test File" as a specific > >>>>> example > >>>>>> that SHOULD (or MUST?) be supported for black-box testing purposes. > >>>>>> > >>>>>> See: http://www.eicar.org/86-0-Intended-use.html > >>>>>> > >>>>>> Thanks, > >>>>>> --David > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On > >>>>>>> Behalf Of Moriarty, Kathleen > >>>>>>> Sent: Thursday, March 14, 2013 10:38 AM > >>>>>>> To: Panos Kampanakis (pkampana); mile@ietf.org > >>>>>>> Subject: Re: [mile] Consensus Call - SCI draft MMDEF as MTI > >>>>>>> > >>>>>>> Hello Panos, > >>>>>>> > >>>>>>> Thank you for joining us remotely! The recording is available > >>>>>>> for those who were not able to attend during the session. > >>>>>>> > >>>>>>> We need to choose one included schema as MTI for 'black box' > >>>>>>> testing of the method described. Essentially, if you can > >>>>>>> exchange using the MTI spec, then any other specs supported > >>>>>>> should theoretically work as the pattern has been established. > >>>>>>> > >>>>>>> MMDEF was recommended as it is in use by the eCrime WG as an > >>>>>> extension > >>>>>>> to IODEF/RFC5901. It replaced the method to include malware in > >>>>>>> exchanges and seemed to make sense to adopt more broadly as it > >>>>>>> is maintained by a group in IEEE focused on that particular problem. > >>>>>>> > >>>>>>> BTW, I meant to say the last call will end in two weeks from > >>>>>>> yesterday, Wednesday March 27th. > >>>>>>> > >>>>>>> Thank you! > >>>>>>> Kathleen > >>>>>>> ________________________________________ > >>>>>>> From: Panos Kampanakis (pkampana) [pkampana@cisco.com] > >>>>>>> Sent: Thursday, March 14, 2013 9:59 AM > >>>>>>> To: Moriarty, Kathleen; mile@ietf.org > >>>>>>> Subject: RE: Consensus Call - SCI draft MMDEF as MTI > >>>>>>> > >>>>>>> I agree with MMDEF included in SCI. > >>>>>>> I am not sure why it must be MTI. Due to some audio problems I > >>>>>>> missed part of the call yesterday. Can you briefly summarize why > >>>>>>> we want it > >>>>> MTI? > >>>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On > >>>>>>> Behalf Of Moriarty, Kathleen > >>>>>>> Sent: Wednesday, March 13, 2013 3:04 PM > >>>>>>> To: mile@ietf.org > >>>>>>> Subject: [mile] Consensus Call - SCI draft MMDEF as MTI > >>>>>>> > >>>>>>> Hello, > >>>>>>> > >>>>>>> In today's MILE session, a call for consensus began to include > >>>>>>> MMDEF in the SCI draft as the mandatory-to-implement (MTI) > >> specification. > >>>>>>> The call for consensus will last for 2 weeks and we ask that you > >>>>> contribute > >>>>>> your opinion. > >>>>>>> The vote in the room was unanimous and we want to make sure we > >>>>>>> hear from participants not in attendance. > >>>>>>> > >>>>>>> Poll will end on Wednesday next week. > >>>>>>> > >>>>>>> Thank you! > >>>>>>> Kathleen > >>>>>>> _______________________________________________ > >>>>>>> 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 > >>>>> _______________________________________________ > >>>>> 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 > >> > >> _______________________________________________ > >> mile mailing list > >> mile@ietf.org > >> https://www.ietf.org/mailman/listinfo/mile > > From kathleen.moriarty@emc.com Tue Apr 9 08:05: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 1952421F93EE for ; Tue, 9 Apr 2013 08:05:56 -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=[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 2FVVyAn1wWiw for ; Tue, 9 Apr 2013 08:05:50 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 1A4CC21F93F1 for ; Tue, 9 Apr 2013 08:05:46 -0700 (PDT) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r39F5h4t007355 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 9 Apr 2013 11:05:44 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd04.lss.emc.com [10.254.222.226]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor) for ; Tue, 9 Apr 2013 11:05:21 -0400 Received: from mxhub18.corp.emc.com (mxhub18.corp.emc.com [10.254.93.47]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r39F5LN8007481 for ; Tue, 9 Apr 2013 11:05:21 -0400 Received: from mx15a.corp.emc.com ([169.254.1.81]) by mxhub18.corp.emc.com ([10.254.93.47]) with mapi; Tue, 9 Apr 2013 11:05:21 -0400 From: "Moriarty, Kathleen" To: "Field, John" , "mile@ietf.org" Date: Tue, 9 Apr 2013 11:05:19 -0400 Thread-Topic: Updated charter for review Thread-Index: Ac4qYye3LkhMGx3rQjuIbJ1ARFHetAAGQt7AAUqL+pABYzxiwA== Message-ID: References: In-Reply-To: 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_F5063677821E3B4F81ACFB7905573F24DA95B486MX15Acorpemccom_" MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [mile] Updated charter for review 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, 09 Apr 2013 15:05:56 -0000 --_000_F5063677821E3B4F81ACFB7905573F24DA95B486MX15Acorpemccom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi John, Thank you for the feedback. Your suggestions look good. Are there any other suggestions or views on John's input as we close out th= e review end of day today. Thank you, Kathleen From: Field, John Sent: Tuesday, April 02, 2013 9:57 AM To: Moriarty, Kathleen; mile@ietf.org Subject: RE: Updated charter for review Kathleen, Thanks. Overall I think the charter looks good. I do have two comments/suggestions for the group's consideration. First, I= would add one additional sentence at the very beginning, as shown below. = In addition, I would add some additional text into the 4th paragraph. (Jus= t in case of CR/LF issues, the 4th paragraph is the paragraph that describe= s an incident). Here is the charter text with my suggested changes. Thanks, John An incident is an unplanned event that occurs in an information infrast= ructure. An incident could be a benign configuration issue, IT incident, an infraction to a service level agreement (SLA), a system compromise, socially engineered phishing attack, or a denial-of-service (DoS) attack, etc. When an incident is detected, the or suspected, there may be a need for organizations to collaborate. This collaboration effort may take several forms including joint analys= is, Information dissemination, and/or a coordinated operational response. Examples of response may include simply filing a report, notification to the source = of the incident, a request to a third party for resolution/mitigation, information sharing on identified indicators of compromise, or a request to locate the source. IODEF defines a data representation that provides a standard format for sharing information commonly exchanged about computer security incidents, which includes indicators with or without = the relevant context information. IODEF will be updated to meet the curren= t and future needs, maintaining the built in extensibility, of information sh= aring where indicators with rich context for actionable sharing is provided. RID enables the secure exchange of incident related information in an I= ODEF format providing options for security, privacy, and policy setting. MILE leverages collaboration and sharing experiences with prior work including the IODEF data model detailed in the IODEF, existing extensio= ns to the IODEF for Anti-phishing (RFC5901), and RID (RFC6545, RFC6546) fo= r the secure exchange of information. MILE will also leverage the experi= ence gained in using IODEF and RID in operational contexts. The MILE working group provides coordination for IODEF and RID extensio= ns that improve capabilities for exchanging indicator and incident information. MILE's objectives include the update of IODEF coupled with guidance inf= ormation to enhance interoperability, deployment ease, and applicability to curr= ent information security data sharing use cases. MILE will also describe a generalization of RID for secure exchange of other security-relevant XM= L formats. MILE will produce additional guidance needed for the successfu= l exchange of indicator and incident information for new use cases accord= ing to policy, security, and privacy requirements. Finally, MILE produced a document template with guidance for defining IODEF extensions to be followed whe= n producing extensions to IODEF as appropriate. From: mile-bounces@ietf.org [mailto:mile-boun= ces@ietf.org] On Behalf Of Moriarty, Kathleen Sent: Tuesday, March 26, 2013 8:00 PM To: mile@ietf.org Subject: Re: [mile] Updated charter for review The good news, people are reading it, however, I sent out the wrong version= . The corrected one is included in this message. Please provide feedback over the next 2 weeks. We'll move the charter to t= he next stage in the approval process after April 9th. Thank you! Kathleen Managed Incident Lightweight Exchange (mile) -------------------------------------------- Charter Current Status: Active Chairs: Kathleen Moriarty Brian Trammell Security Area Directors: Stephen Farrell Sean Turner Security Area Advisor: Sean Turner Mailing Lists: General Discussion: mile@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/mile Archive: http://www.ietf.org/mail-archive/web/mile/ Description of Working Group: The Managed Incident Lightweight Exchange (MILE) working group develops standards for the purpose of improving incident and indicator informati= on sharing and handling capabilities. The Incident Object Description Exchange Format (IODEF) in RFC5070 and Real-time Inter-netw= ork Defense (RID) in RFC6045 were developed in the INCH working group by international Computer Security Incident Response Teams (CSIRTs) and industry to meet the needs of a global community interested in sharing, handling, and exchanging incident and indicator information. The working group will define enhancements and extensions to IODEF and = RID and provide guidance for applying them. It will also focus on improving= the interoperability of existing and new IODEF implementations, and the interoperation of IODEF and its extensions and enhancements with relate= d standards for information sharing. The extensions and guidance created = by the MILE working group assist with the daily operations of CSIRTs at an organization, service providers, law enforcement, and at the national l= evel. The working group has completed Proposed Standard revisions of RID (RFC= 6545) and RID transport (RFC 6546). This transport was designed to meet speci= fic usage requirements of CSIRTs and related industry groups. In order to meet di= fferent usage requirements for other communities, the working group will consid= er alternate transport or bindings for RID and IODEF information. An incident could be a benign configuration issue, IT incident, an infraction to a service level agreement (SLA), a system compromise, socially engineered phishing attack, or a denial-of-service (DoS) attack, etc. When an incident is detected, the response may include simply filing a report, notification to the source of the incident, a request to a third party for resolution/mitigation, information sharing on identified indicators of compromise, or a request to locate the source. IODEF defines a data representation that provides a standard format for sharing information commonly exchanged about computer security incidents, which includes indicators with or without = the relevant context information. IODEF will be updated to meet the curren= t and future needs, maintaining the built in extensibility, of information sh= aring where indicators with rich context for actionable sharing is provided. RID enables the secure exchange of incident related information in an I= ODEF format providing options for security, privacy, and policy setting. MILE leverages collaboration and sharing experiences with prior work including the IODEF data model detailed in the IODEF, existing extensio= ns to the IODEF for Anti-phishing (RFC5901), and RID (RFC6545, RFC6546) fo= r the secure exchange of information. MILE will also leverage the experi= ence gained in using IODEF and RID in operational contexts. The MILE working group provides coordination for IODEF and RID extensio= ns that improve capabilities for exchanging indicator and incident information. MILE's objectives include the update of IODEF coupled with guidance inf= ormation to enhance interoperability, deployment ease, and applicability to curr= ent information security data sharing use cases. MILE will also describe a generalization of RID for secure exchange of other security-relevant XM= L formats. MILE will produce additional guidance needed for the successfu= l exchange of indicator and incident information for new use cases accord= ing to policy, security, and privacy requirements. Finally, MILE produced a document template with guidance for defining IODEF extensions to be followed whe= n producing extensions to IODEF as appropriate. [Removed laundry list of drafts -- outdated. We should update the miles= tones below as well] Goals and Milestones: Done - WGLC Real-time Inter-network Defense (RID) Done - WGLC Transport for Real-time Inter-network Defense (RID) Done - Submit Real-time Inter-network Defense (RID) to IESG for consi= deration as Standards Track document Done - Submit Transport Real-time Inter-network Defense (RID) to IESG= for consideration as Standards Track document Done - WGLC Template for extensions to IODEF Done - WGLC IODEF Extensions in IANA XML Registry Apr 2013 - WGLC IODEF Extension to support structured cybersecurity infor= mation Done - Submit Template for extensions to IODEF to IESG for considerat= ion as Informational document Done - Submit IODEF Extensions in IANA XML Registry to IESG for consi= deration as Standards Track document Jun 2013 - Submit IODEF Extension to support structured cybersecurity inf= ormation to IESG for consideration as Standards Track document. TBD - WGLC RFC 5070bis TBD - Submit RFC 5070bis to IESG for consideration as a Standards Tr= ack document TBD - WGLC IODEF Reference Format TBD - Submit IODEF Reference Format to IESG for consideration as a S= tandards Track document TBD - WGLC Resource-Oriented Indicator Exchange TBD - Submit Resource-Oriented Indicator Exchange to IESG for consid= eration as a Standards Track document [ old milestone bits below ] [no doc]- WGLC IODEF Guidance [no doc] - Submit IODEF Extension Labeling for data protection, retention= , policies, and regulations to IESG for consideration as Standards Track do= cument [no doc] - Submit WGLC IODEF Guidance to IESG for consideration as Inform= ational document May 2012 - WGLC GRC Report Exchange [stalled] Jun 2012 - Submit GRC Report Exchange to IESG for consideration as Standa= rds Track document [stalled] Jun 2012 - WGLC Forensics extension [stalled] Jul 2012 - Submit IODEF Forensics extension to IESG for consideration as = Standards Track document [stalled] From: mile-bounces@ietf.org [mailto:mile-boun= ces@ietf.org] On Behalf Of Moriarty, Kathleen Sent: Tuesday, March 26, 2013 4:48 PM To: mile@ietf.org Subject: [mile] Updated charter for review As discussed at the MILE meeting, we need to revise the charter. Brian and= I updated the charter and it is attached for review and comment to the lis= t. Thank you in advance! Best regards, Kathleen & Brian [Outdated draft charter deleted] --_000_F5063677821E3B4F81ACFB7905573F24DA95B486MX15Acorpemccom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi John,<= o:p>

 

Thank you for the feedback.  Your sugges= tions look good.

&nbs= p;

Are there any other suggesti= ons or views on John’s input as we close out the review end of day to= day.

 

Thank you,

Kathleen

 

From: Field= , John
Sent: Tuesday, April 02, 2013 9:57 AM
To: Moria= rty, Kathleen; mile@ietf.org
Subject: RE: Updated charter for rev= iew

 =

Kathleen,

 

Th= anks. 

Overall I thi= nk the charter looks good. 

 

I do have t= wo comments/suggestions for the group’s consideration.  First, I= would add one additional sentence at the very beginning, as shown below.&n= bsp; In addition, I would add some additional text into the 4th = paragraph.  (Just in case of CR/LF issues, the 4th paragrap= h is the paragraph that describes an incident).

 

Here is the charter text with my suggested changes. 

 

Thanks,

J= ohn

 

 

    <add text>

    An incident is an unplanned eve= nt that occurs in an information infrastructure.

   </add text>

=

 

    An incident could be a benign configuration iss= ue, IT incident, an

&nbs= p;   infraction to a service level agreement (SLA), a system comp= romise,

   = socially engineered phishing attack, or a denial-of-service (DoS)

    attack, etc.&nb= sp; When an incident is detected,

 

 &nbs= p; <delete text>

    the

    </delete text>

 

    <add text>

    or suspected, there may be a need for organiz= ations to collaborate.

&nb= sp;   This collaboration effort may take several forms including = joint analysis,  

&nb= sp;   Information dissemination, and/or a coordinated operat= ional response.  

&nb= sp;   Examples of  

   </add text>

 

   response may include simply filing a report, notific= ation to the source of the incident, a

    request to a third party for resolution/mit= igation, information sharing

    on identified indicators of compromise, or a request = to

    loca= te the source.  IODEF defines a data representation that provides a

    standard = format for sharing information commonly exchanged about

    computer security incident= s, which includes indicators with or without the

    relevant context information.&nbs= p; IODEF will be updated to meet the current and

    future needs, maintaining the bui= lt in extensibility, of information sharing

    where indicators with rich context f= or actionable sharing is provided.

    RID enables the secure exchange of incident rel= ated information in an IODEF

    format providing options for security, privacy, and p= olicy setting.

 =

    MILE levera= ges collaboration and sharing experiences with prior work=

    including the IODEF data= model detailed in the IODEF, existing extensions

    to the IODEF for Anti-phishing (= RFC5901), and RID (RFC6545, RFC6546) for

    the secure exchange of information. = MILE will also leverage the experience

    gained in using IODEF and RID in operation= al contexts.

  =   

  &= nbsp; The MILE working group provides coordination for IODEF and RID e= xtensions that

  = ;  improve capabilities for exchanging indicator and incident informat= ion.

    MI= LE's objectives include the update of IODEF coupled with guidance informati= on

    to e= nhance interoperability, deployment ease, and applicability to current=

    information= security data sharing use cases. MILE will also describe a

    generalization of RID = for secure exchange of other security-relevant XML

    formats. MILE will produce addi= tional guidance needed for the successful

    exchange of indicator and incident infor= mation for new use cases according to policy,

    security, and privacy requirements. = Finally, MILE produced a document

    template with guidance for defining IODEF extens= ions to be followed when

&= nbsp;   producing extensions to IODEF as appropriate.<= /span>

 

 

 

 <= /span>

From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Moriarty, Kat= hleen
Sent: Tuesday, March 26, 2013 8:00 PM
To: mile@ietf.org
Subject: Re: [mile] U= pdated charter for review

 

The good news, people= are reading it, however, I sent out the wrong version.  The corrected= one is included in this message.

 

Please prov= ide feedback over the next 2 weeks.  We’ll move the charter to t= he next stage in the approval process after April 9th. 

 

=

Thank you!

Kathleen

 

Managed Incident Lightw= eight Exchange (mile)

----= ----------------------------------------

 

Char= ter

 

Current Status: Active<= /p>

 

Chairs:

&nbs= p;    Kathleen Moriarty

     Brian Trammell

 

Security Area Directors:

     Stephen Farrell

     Sean Turner

 

=

Security Area Advisor:

     Sean Turner

 

Mailing Lists:

     General Discussion: mile@ietf.org

     To Subscribe:     &nb= sp; https://www.ietf= .org/mailman/listinfo/mile

     Archive:      &= nbsp;     http://www.ietf.org/mail-archive/web/mile/<= /p>

 

Description of Working Group:

 

&nb= sp;

   &nb= sp;The Managed Incident Lightweight Exchange (MILE) working group develops<= o:p>

    standar= ds for the purpose of improving incident and indicator information

    sharing and han= dling capabilities. The Incident Object

    Description Exchange Format (IODEF) in RFC= 5070 and Real-time Inter-network

=     Defense (RID) in RFC6045 were developed in the IN= CH working group by

&nbs= p;   international Computer Security Incident Response Teams (CSI= RTs) and

   = ; industry to meet the needs of a global community interested in sharing,

    handling= , and exchanging incident and indicator information.

=

    

<= p class=3DMsoNormal>    The working group will d= efine enhancements and extensions to IODEF and RID

    and provide guidance for applyi= ng them. It will also focus on improving the

    interoperability of existing and new= IODEF implementations, and the

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'>    interoperation of IODEF and its extensions and enh= ancements with related

&nb= sp;   standards for information sharing. The extensions and guida= nce created by

  = ;  the MILE working group assist with the daily operations of CSIRTs a= t an

    or= ganization, service providers, law enforcement, and at the national level.<= o:p>

   

    The work= ing group has completed Proposed Standard revisions of RID (RFC 6545)<= /o:p>

    and RID tran= sport (RFC 6546). This transport was designed to meet specific usage

    requirements = of CSIRTs and related industry groups. In order to meet different

    usage requiremen= ts for other communities, the working group will consider=

    alternate transport or b= indings for RID and IODEF information.

   

=     An incident could be a benign configuration = issue, IT incident, an

&nb= sp;   infraction to a service level agreement (SLA), a system com= promise,

   = ; socially engineered phishing attack, or a denial-of-service (DoS)

    attack, etc.&n= bsp; When an incident is detected, the response may include

    simply filing a report= , notification to the source of the incident, a

    request to a third party for resol= ution/mitigation, information sharing

    on identified indicators of compromise, or a= request to

  &n= bsp; locate the source.  IODEF defines a data representation that prov= ides a

    = standard format for sharing information commonly exchanged about=

    computer security= incidents, which includes indicators with or without the=

    relevant context informa= tion.  IODEF will be updated to meet the current and=

    future needs, maintainin= g the built in extensibility, of information sharing

<= p class=3DMsoNormal>    where indicators with rich co= ntext for actionable sharing is provided.

    RID enables the secure exchange of incid= ent related information in an IODEF

    format providing options for security, privacy= , and policy setting.

&nbs= p;  

 &nbs= p;  MILE leverages collaboration and sharing experiences with pri= or work

   = including the IODEF data model detailed in the IODEF, existing extensions<= o:p>

    to the = IODEF for Anti-phishing (RFC5901), and RID (RFC6545, RFC6546) for

    the secure excha= nge of information.  MILE will also leverage the experience=

    gained in using I= ODEF and RID in operational contexts.

    

    The MILE working group provides coordin= ation for IODEF and RID extensions that

    improve capabilities for exchanging indica= tor and incident information.

    MILE's objectives include the update of IODEF couple= d with guidance information

    to enhance interoperability, deployment ease, and appl= icability to current

&nbs= p;   information security data sharing use cases. MILE will also = describe a

  &nb= sp; generalization of RID for secure exchange of other security-relevant XM= L

    forma= ts. MILE will produce additional guidance needed for the successful

    exchange of in= dicator and incident information for new use cases according to policy,

    security, = and privacy requirements. Finally, MILE produced a document

    template with guidance= for defining IODEF extensions to be followed when

    producing extensions to IODEF a= s appropriate.

 =

    [Removed la= undry list of drafts -- outdated. We should update the milestones below as = well]

 

Goals and Milestones:=

  Done     - WGLC = Real-time Inter-network Defense (RID)

  Done     - WGLC Transport for Real-t= ime Inter-network Defense (RID)

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'>  Done     - Submit Real-time Inter-network = Defense (RID) to IESG for consideration as Standards Track document

  Done   &nbs= p; - Submit Transport Real-time Inter-network Defense (RID) to IESG for con= sideration as Standards Track document

  Done     - WGLC Template for extens= ions to IODEF

  Done&= nbsp;    - WGLC IODEF Extensions in IANA XML Registry

  Apr 2013 - WGLC IODEF Ext= ension to support structured cybersecurity information

  Done     - Submit T= emplate for extensions to IODEF to IESG for consideration as Informational = document

  Done =     - Submit IODEF Extensions in IANA XML Registry to IESG f= or consideration as Standards Track document

  Jun 2013 - Submit IODEF Extension to support str= uctured cybersecurity information to IESG for consideration as Standards Tr= ack document.

  TBD&n= bsp;     - WGLC RFC 5070bis

  TBD      - Submit RFC= 5070bis to IESG for consideration as a Standards Track document=

  TBD    &n= bsp; - WGLC IODEF Reference Format

  TBD      - Submit IODEF Reference = Format to IESG for consideration as a Standards Track document

  TBD    &nbs= p; - WGLC Resource-Oriented Indicator Exchange

  TBD      - Submit Reso= urce-Oriented Indicator Exchange to IESG for consideration as a Standards T= rack document

  =

  [ old milestone bi= ts below ]

 

  [no doc]- WGLC IODEF = Guidance

  [no doc] -= Submit IODEF Extension Labeling for data protection, retention, policies, = and regulations to IESG for consideration as Standards Track document<= /o:p>

  [no doc] - Submit WGLC I= ODEF Guidance to IESG for consideration as Informational document

  May 2012 - WGLC GRC Report E= xchange [stalled]

  J= un 2012 - Submit GRC Report Exchange to IESG for consideration as Standards= Track document [stalled]

=   Jun 2012 - WGLC Forensics extension [stalled]

<= p class=3DMsoNormal>  Jul 2012 - Submit IODEF Forensics extensi= on to IESG for consideration as Standards Track document [stalled]

 

<= div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0= in 0in'>

From: m= ile-bounces@ietf.org [mailto:m= ile-bounces@ietf.org] On Behalf Of Moriarty, Kathleen
Sent= : Tuesday, March 26, 2013 4:48 PM
To: mile@ietf.org
Subject: [mile] Updated charter for r= eview

 

As discussed at the MILE meeting, we need to revise the cha= rter.  Brian and I updated the charter and it is attached for review a= nd comment to the list.

 

Thank you in advance!

 

<= span style=3D'font-size:10.0pt;font-family:"Courier New"'>Best regards,

Kathleen & Brian

 

 = ;

 = [Outdated draft charter deleted]

&n= bsp;

= --_000_F5063677821E3B4F81ACFB7905573F24DA95B486MX15Acorpemccom_-- From johnp.field@emc.com Wed Apr 10 06:29:33 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 44F8E21F9579 for ; Wed, 10 Apr 2013 06:29:33 -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=[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 yY3iyLeJCeyW for ; Wed, 10 Apr 2013 06:29:27 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id F02EB21F9097 for ; Wed, 10 Apr 2013 06:29:26 -0700 (PDT) Received: from hop04-l1d11-si04.isus.emc.com (HOP04-L1D11-SI04.isus.emc.com [10.254.111.24]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r3ADTQti002688 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 10 Apr 2013 09:29:26 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd05.lss.emc.com [10.254.222.129]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor) for ; Wed, 10 Apr 2013 09:29:15 -0400 Received: from mxhub07.corp.emc.com (mxhub07.corp.emc.com [128.222.70.204]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r3ADTD2M021698 for ; Wed, 10 Apr 2013 09:29:14 -0400 Received: from mx14a.corp.emc.com ([169.254.1.183]) by mxhub07.corp.emc.com ([128.222.70.204]) with mapi; Wed, 10 Apr 2013 09:29:13 -0400 From: "Field, John" To: "Moriarty, Kathleen" , "mile@ietf.org" Date: Wed, 10 Apr 2013 09:29:11 -0400 Thread-Topic: Updated charter for review Thread-Index: Ac4qYye3LkhMGx3rQjuIbJ1ARFHetAAGQt7AAUqL+pABYzxiwAAu3t/g Message-ID: References: In-Reply-To: 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_B7873C71FEFD6E41B5468506E231FB6E012C50D7E6MX14Acorpemcc_" MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [mile] Updated charter for review 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, 10 Apr 2013 13:29:33 -0000 --_000_B7873C71FEFD6E41B5468506E231FB6E012C50D7E6MX14Acorpemcc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Kathleen, Thanks. One clarification on my prior note....I previously wrote: >>First, I would add one additional sentence at the very beginning, as show= n below. I meant to say that this first text insertion would be at the very beginnin= g (of the immediately following) paragraph... *not* at the very beginning o= f the charter. So, the text will read as it appears below. Regards, John From: Moriarty, Kathleen Sent: Tuesday, April 09, 2013 11:05 AM To: Field, John; mile@ietf.org Subject: RE: Updated charter for review Hi John, Thank you for the feedback. Your suggestions look good. Are there any other suggestions or views on John's input as we close out th= e review end of day today. Thank you, Kathleen From: Field, John Sent: Tuesday, April 02, 2013 9:57 AM To: Moriarty, Kathleen; mile@ietf.org Subject: RE: Updated charter for review Kathleen, Thanks. Overall I think the charter looks good. I do have two comments/suggestions for the group's consideration. First, I= would add one additional sentence at the very beginning, as shown below. = In addition, I would add some additional text into the 4th paragraph. (Jus= t in case of CR/LF issues, the 4th paragraph is the paragraph that describe= s an incident). Here is the charter text with my suggested changes. Thanks, John An incident is an unplanned event that occurs in an information infrast= ructure. An incident could be a benign configuration issue, IT incident, an infraction to a service level agreement (SLA), a system compromise, socially engineered phishing attack, or a denial-of-service (DoS) attack, etc. When an incident is detected, the or suspected, there may be a need for organizations to collaborate. This collaboration effort may take several forms including joint analys= is, Information dissemination, and/or a coordinated operational response. Examples of response may include simply filing a report, notification to the source = of the incident, a request to a third party for resolution/mitigation, information sharing on identified indicators of compromise, or a request to locate the source. IODEF defines a data representation that provides a standard format for sharing information commonly exchanged about computer security incidents, which includes indicators with or without = the relevant context information. IODEF will be updated to meet the curren= t and future needs, maintaining the built in extensibility, of information sh= aring where indicators with rich context for actionable sharing is provided. RID enables the secure exchange of incident related information in an I= ODEF format providing options for security, privacy, and policy setting. MILE leverages collaboration and sharing experiences with prior work including the IODEF data model detailed in the IODEF, existing extensio= ns to the IODEF for Anti-phishing (RFC5901), and RID (RFC6545, RFC6546) fo= r the secure exchange of information. MILE will also leverage the experi= ence gained in using IODEF and RID in operational contexts. The MILE working group provides coordination for IODEF and RID extensio= ns that improve capabilities for exchanging indicator and incident information. MILE's objectives include the update of IODEF coupled with guidance inf= ormation to enhance interoperability, deployment ease, and applicability to curr= ent information security data sharing use cases. MILE will also describe a generalization of RID for secure exchange of other security-relevant XM= L formats. MILE will produce additional guidance needed for the successfu= l exchange of indicator and incident information for new use cases accord= ing to policy, security, and privacy requirements. Finally, MILE produced a document template with guidance for defining IODEF extensions to be followed whe= n producing extensions to IODEF as appropriate. From: mile-bounces@ietf.org [mailto:mile-boun= ces@ietf.org] On Behalf Of Moriarty, Kathleen Sent: Tuesday, March 26, 2013 8:00 PM To: mile@ietf.org Subject: Re: [mile] Updated charter for review The good news, people are reading it, however, I sent out the wrong version= . The corrected one is included in this message. Please provide feedback over the next 2 weeks. We'll move the charter to t= he next stage in the approval process after April 9th. Thank you! Kathleen Managed Incident Lightweight Exchange (mile) -------------------------------------------- Charter Current Status: Active Chairs: Kathleen Moriarty Brian Trammell Security Area Directors: Stephen Farrell Sean Turner Security Area Advisor: Sean Turner Mailing Lists: General Discussion: mile@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/mile Archive: http://www.ietf.org/mail-archive/web/mile/ Description of Working Group: The Managed Incident Lightweight Exchange (MILE) working group develops standards for the purpose of improving incident and indicator informati= on sharing and handling capabilities. The Incident Object Description Exchange Format (IODEF) in RFC5070 and Real-time Inter-netw= ork Defense (RID) in RFC6045 were developed in the INCH working group by international Computer Security Incident Response Teams (CSIRTs) and industry to meet the needs of a global community interested in sharing, handling, and exchanging incident and indicator information. The working group will define enhancements and extensions to IODEF and = RID and provide guidance for applying them. It will also focus on improving= the interoperability of existing and new IODEF implementations, and the interoperation of IODEF and its extensions and enhancements with relate= d standards for information sharing. The extensions and guidance created = by the MILE working group assist with the daily operations of CSIRTs at an organization, service providers, law enforcement, and at the national l= evel. The working group has completed Proposed Standard revisions of RID (RFC= 6545) and RID transport (RFC 6546). This transport was designed to meet speci= fic usage requirements of CSIRTs and related industry groups. In order to meet di= fferent usage requirements for other communities, the working group will consid= er alternate transport or bindings for RID and IODEF information. An incident could be a benign configuration issue, IT incident, an infraction to a service level agreement (SLA), a system compromise, socially engineered phishing attack, or a denial-of-service (DoS) attack, etc. When an incident is detected, the response may include simply filing a report, notification to the source of the incident, a request to a third party for resolution/mitigation, information sharing on identified indicators of compromise, or a request to locate the source. IODEF defines a data representation that provides a standard format for sharing information commonly exchanged about computer security incidents, which includes indicators with or without = the relevant context information. IODEF will be updated to meet the curren= t and future needs, maintaining the built in extensibility, of information sh= aring where indicators with rich context for actionable sharing is provided. RID enables the secure exchange of incident related information in an I= ODEF format providing options for security, privacy, and policy setting. MILE leverages collaboration and sharing experiences with prior work including the IODEF data model detailed in the IODEF, existing extensio= ns to the IODEF for Anti-phishing (RFC5901), and RID (RFC6545, RFC6546) fo= r the secure exchange of information. MILE will also leverage the experi= ence gained in using IODEF and RID in operational contexts. The MILE working group provides coordination for IODEF and RID extensio= ns that improve capabilities for exchanging indicator and incident information. MILE's objectives include the update of IODEF coupled with guidance inf= ormation to enhance interoperability, deployment ease, and applicability to curr= ent information security data sharing use cases. MILE will also describe a generalization of RID for secure exchange of other security-relevant XM= L formats. MILE will produce additional guidance needed for the successfu= l exchange of indicator and incident information for new use cases accord= ing to policy, security, and privacy requirements. Finally, MILE produced a document template with guidance for defining IODEF extensions to be followed whe= n producing extensions to IODEF as appropriate. [Removed laundry list of drafts -- outdated. We should update the miles= tones below as well] Goals and Milestones: Done - WGLC Real-time Inter-network Defense (RID) Done - WGLC Transport for Real-time Inter-network Defense (RID) Done - Submit Real-time Inter-network Defense (RID) to IESG for consi= deration as Standards Track document Done - Submit Transport Real-time Inter-network Defense (RID) to IESG= for consideration as Standards Track document Done - WGLC Template for extensions to IODEF Done - WGLC IODEF Extensions in IANA XML Registry Apr 2013 - WGLC IODEF Extension to support structured cybersecurity infor= mation Done - Submit Template for extensions to IODEF to IESG for considerat= ion as Informational document Done - Submit IODEF Extensions in IANA XML Registry to IESG for consi= deration as Standards Track document Jun 2013 - Submit IODEF Extension to support structured cybersecurity inf= ormation to IESG for consideration as Standards Track document. TBD - WGLC RFC 5070bis TBD - Submit RFC 5070bis to IESG for consideration as a Standards Tr= ack document TBD - WGLC IODEF Reference Format TBD - Submit IODEF Reference Format to IESG for consideration as a S= tandards Track document TBD - WGLC Resource-Oriented Indicator Exchange TBD - Submit Resource-Oriented Indicator Exchange to IESG for consid= eration as a Standards Track document [ old milestone bits below ] [no doc]- WGLC IODEF Guidance [no doc] - Submit IODEF Extension Labeling for data protection, retention= , policies, and regulations to IESG for consideration as Standards Track do= cument [no doc] - Submit WGLC IODEF Guidance to IESG for consideration as Inform= ational document May 2012 - WGLC GRC Report Exchange [stalled] Jun 2012 - Submit GRC Report Exchange to IESG for consideration as Standa= rds Track document [stalled] Jun 2012 - WGLC Forensics extension [stalled] Jul 2012 - Submit IODEF Forensics extension to IESG for consideration as = Standards Track document [stalled] From: mile-bounces@ietf.org [mailto:mile-boun= ces@ietf.org] On Behalf Of Moriarty, Kathleen Sent: Tuesday, March 26, 2013 4:48 PM To: mile@ietf.org Subject: [mile] Updated charter for review As discussed at the MILE meeting, we need to revise the charter. Brian and= I updated the charter and it is attached for review and comment to the lis= t. Thank you in advance! Best regards, Kathleen & Brian [Outdated draft charter deleted] --_000_B7873C71FEFD6E41B5468506E231FB6E012C50D7E6MX14Acorpemcc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Kathleen,=

 <= /p>

Thanks. 

 

One clarification on my prior note….I previously wrote:

 

>>First, I would add one additional sentence at t= he very beginning, as shown below. 

 

I me= ant to say that this first text insertion would be at the very beginning (o= f the immediately following) paragraph… *not* at the very begi= nning of the charter. 

 

So, the text wil= l read as it appears below.

 

Regards,

John

 

 

 <= /span>

From: Moriarty, Kathleen
= Sent: Tuesday, April 09, 2013 11:05 AM
To: Field, John; mile@= ietf.org
Subject: RE: Updated charter for review

 

Hi John,

 

Thank you for the feedb= ack.  Your suggestions look good.

 

Are = there any other suggestions or views on John’s input as we close out = the review end of day today.

 

Thank you,<= /o:p>

Kathleen

<= p class=3DMsoNormal> 

From: Field, John
Sent: Tuesday, April 02, 2013 9:5= 7 AM
To: Moriarty, Kathleen; mil= e@ietf.org
Subject: RE: Updated charter for review=

 

Kathleen,

 

Thanks.  =

Overall I think the chart= er looks good. 

 

I do have two comments/= suggestions for the group’s consideration.  First, I would add o= ne additional sentence at the very beginning, as shown below.  In addi= tion, I would add some additional text into the 4th paragraph. &= nbsp;(Just in case of CR/LF issues, the 4th paragraph is the par= agraph that describes an incident).

 

Here is t= he charter text with my suggested changes. 

 

Thanks,

John

 

 

    <add text>

    An incident is an unplanned event that occu= rs in an information infrastructure.

   </add text>

 

&nb= sp;   An incident could be a benign configuration issue, IT incid= ent, an

   = infraction to a service level agreement (SLA), a system compromise,

    socially engi= neered phishing attack, or a denial-of-service (DoS)

<= p class=3DMsoNormal>    attack, etc.  When an in= cident is detected,

 

   <d= elete text>

  = ;  the

 &nb= sp;  </delete text>

 

  &n= bsp; <add text>

&nbs= p;   or suspected, there may be a need for organizations to colla= borate.

   = This collaboration effort may take several forms including joint analysis,=  

   =  Information dissemination, and/or a coordinated operational response.=  

   =  Examples of  

&= nbsp;  </add text>

 

 &nbs= p; response may include simply filing a report, notification to the so= urce of the incident, a

&n= bsp;   request to a third party for resolution/mitigation, inform= ation sharing

  =   on identified indicators of compromise, or a request to

    locate the source.&= nbsp; IODEF defines a data representation that provides a=

    standard format for shar= ing information commonly exchanged about

    computer security incidents, which includ= es indicators with or without the

    relevant context information.  IODEF will b= e updated to meet the current and

    future needs, maintaining the built in extensibi= lity, of information sharing

    where indicators with rich context for actionable sha= ring is provided.

 &n= bsp;  RID enables the secure exchange of incident related information = in an IODEF

  &n= bsp; format providing options for security, privacy, and policy setting.

 

=

    MILE leverages collaboration= and sharing experiences with prior work

    including the IODEF data model detailed i= n the IODEF, existing extensions

=     to the IODEF for Anti-phishing (RFC5901), and RID= (RFC6545, RFC6546) for

&n= bsp;   the secure exchange of information.  MILE will also l= everage the experience

&nb= sp;   gained in using IODEF and RID in operational contexts.

    =

    The MI= LE working group provides coordination for IODEF and RID extensions that

    improve c= apabilities for exchanging indicator and incident information.

    MILE's objectives i= nclude the update of IODEF coupled with guidance information

    to enhance interopera= bility, deployment ease, and applicability to current

=

    information security data sh= aring use cases. MILE will also describe a

    generalization of RID for secure exchan= ge of other security-relevant XML

    formats. MILE will produce additional guidance n= eeded for the successful

&= nbsp;   exchange of indicator and incident information for new us= e cases according to policy,

    security, and privacy requirements. Finally, MILE pro= duced a document

 &nb= sp;  template with guidance for defining IODEF extensions to be follow= ed when

   = producing extensions to IODEF as appropriate.

 

 

 =

 

From: mil= e-bounces@ietf.org [mailto:mil= e-bounces@ietf.org] On Behalf Of Moriarty, Kathleen
Sent:<= /b> Tuesday, March 26, 2013 8:00 PM
To: mile@ietf.org
Subject: Re: [mile] Updated charter for= review

 

The good news, people are reading it, h= owever, I sent out the wrong version.  The corrected one is included i= n this message.

 = ;

Please provide feedback over = the next 2 weeks.  We’ll move the charter to the next stage in t= he approval process after April 9th. 

 

Thank you!

Kath= leen

 

Managed Incident Lightweight Exchange (m= ile)

---------------------= -----------------------

 

Charter

 

Current Status: Active

 

Chai= rs:

   &nbs= p; Kathleen Moriarty

&nbs= p;    Brian Trammell

 

Sec= urity Area Directors:

&nbs= p;    Stephen Farrell

     Sean Turner

 

Security Area Advisor:

=      Sean Turner

 

Mailing Lists:

 &nbs= p;   General Discussion: mile@ie= tf.org

  &nb= sp;  To Subscribe:       https://www.ietf.org/mailman/listin= fo/mile

  &n= bsp;  Archive:         &n= bsp;  http://ww= w.ietf.org/mail-archive/web/mile/

 

Descrip= tion of Working Group:

 

 

    The Managed Inci= dent Lightweight Exchange (MILE) working group develops

    standards for the purpose = of improving incident and indicator information

    sharing and handling capabilities.= The Incident Object

&nbs= p;   Description Exchange Format (IODEF) in RFC5070 and Real-time= Inter-network

  = ;  Defense (RID) in RFC6045 were developed in the INCH working group b= y

    inter= national Computer Security Incident Response Teams (CSIRTs) and<= /span>

    industry to meet t= he needs of a global community interested in sharing,

=

    handling, and exchanging inc= ident and indicator information.

    

=     The working group will define enhancements a= nd extensions to IODEF and RID

    and provide guidance for applying them. It will als= o focus on improving the

&= nbsp;   interoperability of existing and new IODEF implementation= s, and the

  &nb= sp; interoperation of IODEF and its extensions and enhancements with relate= d

    stand= ards for information sharing. The extensions and guidance created by

    the MILE work= ing group assist with the daily operations of CSIRTs at an

    organization, service p= roviders, law enforcement, and at the national level.

=

   

    The working group has complet= ed Proposed Standard revisions of RID (RFC 6545)

    and RID transport (RFC 6546). Thi= s transport was designed to meet specific usage

    requirements of CSIRTs and related= industry groups. In order to meet different

    usage requirements for other communi= ties, the working group will consider

    alternate transport or bindings for RID and = IODEF information.

 &= nbsp; 

  &= nbsp; An incident could be a benign configuration issue, IT incident, = an

    infr= action to a service level agreement (SLA), a system compromise,<= /span>

    socially engineere= d phishing attack, or a denial-of-service (DoS)

    attack, etc.  When an inciden= t is detected, the response may include

    simply filing a report, notification to th= e source of the incident, a

    request to a third party for resolution/mitigation, in= formation sharing

 &n= bsp;  on identified indicators of compromise, or a request to

    locate the sour= ce.  IODEF defines a data representation that provides a

    standard format for = sharing information commonly exchanged about

    computer security incidents, which i= ncludes indicators with or without the

    relevant context information.  IODEF w= ill be updated to meet the current and

    future needs, maintaining the built in exte= nsibility, of information sharing

    where indicators with rich context for actionabl= e sharing is provided.

&nb= sp;   RID enables the secure exchange of incident related informa= tion in an IODEF

 &nb= sp;  format providing options for security, privacy, and policy settin= g.

   

    MILE = leverages collaboration and sharing experiences with prior work<= /span>

    including the IODE= F data model detailed in the IODEF, existing extensions

    to the IODEF for Anti-phis= hing (RFC5901), and RID (RFC6545, RFC6546) for

    the secure exchange of information.=   MILE will also leverage the experience

    gained in using IODEF and RID in ope= rational contexts.

&nbs= p;   

&nbs= p;   The MILE working group provides coordination for IODEF = and RID extensions that

&n= bsp;   improve capabilities for exchanging indicator and incident= information.

  =   MILE's objectives include the update of IODEF coupled with guidance = information

  &n= bsp; to enhance interoperability, deployment ease, and applicability to cur= rent

    in= formation security data sharing use cases. MILE will also describe a

    generalizatio= n of RID for secure exchange of other security-relevant XML

    formats. MILE will pro= duce additional guidance needed for the successful

    exchange of indicator and incid= ent information for new use cases according to policy,

    security, and privacy requi= rements. Finally, MILE produced a document

    template with guidance for defining IOD= EF extensions to be followed when

    producing extensions to IODEF as appropriate.

 

=

    [Removed laundry list of dra= fts -- outdated. We should update the milestones below as well]<= /span>

 

Goals and Milestones:

  Done     - WGLC Real-time Inter-= network Defense (RID)

&nbs= p; Done     - WGLC Transport for Real-time Inter-networ= k Defense (RID)

  Don= e     - Submit Real-time Inter-network Defense (RID) to= IESG for consideration as Standards Track document

  Done     - Submit Tran= sport Real-time Inter-network Defense (RID) to IESG for consideration as St= andards Track document

&nb= sp; Done     - WGLC Template for extensions to IODEF

  Done   = ;  - WGLC IODEF Extensions in IANA XML Registry

<= p class=3DMsoNormal>  Apr 2013 - WGLC IODEF Extension to suppor= t structured cybersecurity information

  Done     - Submit Template for exte= nsions to IODEF to IESG for consideration as Informational document

  Done   &nbs= p; - Submit IODEF Extensions in IANA XML Registry to IESG for consideration= as Standards Track document

  Jun 2013 - Submit IODEF Extension to support structured cybersecu= rity information to IESG for consideration as Standards Track document.

  TBD   &= nbsp;  - WGLC RFC 5070bis

  TBD      - Submit RFC 5070bis to IESG = for consideration as a Standards Track document

  TBD      - WGLC IODEF= Reference Format

  T= BD      - Submit IODEF Reference Format to IESG fo= r consideration as a Standards Track document

  TBD      - WGLC Resourc= e-Oriented Indicator Exchange

  TBD      - Submit Resource-Oriented Ind= icator Exchange to IESG for consideration as a Standards Track document

 

=

  [ old milestone bits below ]

 

  [no doc]- WGLC IODEF Guidance

  [no doc] - Submit IODEF Ext= ension Labeling for data protection, retention, policies, and regulations t= o IESG for consideration as Standards Track document

<= p class=3DMsoNormal>  [no doc] - Submit WGLC IODEF Guidance to = IESG for consideration as Informational document

  May 2012 - WGLC GRC Report Exchange [stalled]=

  Jun 2012 - Submit = GRC Report Exchange to IESG for consideration as Standards Track document [= stalled]

  Jun 2012 -= WGLC Forensics extension [stalled]

  Jul 2012 - Submit IODEF Forensics extension to IESG for co= nsideration as Standards Track document [stalled]

 

From: mile-bounces@ietf= .org [mailto:mile-bounces@ietf= .org] On Behalf Of Moriarty, Kathleen
Sent: Tuesday, M= arch 26, 2013 4:48 PM
To: mile@i= etf.org
Subject: [mile] Updated charter for review=

 

= As discussed at the MILE meeting, we need to revise the charter.  Bria= n and I updated the charter and it is attached for review and comment to th= e list.

 

Thank you in advance!

&n= bsp;

Best regards,

Kathleen & Brian

 

 

 [Outdated draft = charter deleted]

 

= --_000_B7873C71FEFD6E41B5468506E231FB6E012C50D7E6MX14Acorpemcc_-- From johnsonhammond1@hushmail.com Sat Apr 27 10:37: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 BFCCD21F983B for ; Sat, 27 Apr 2013 10:37:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 jyA565waW6xK for ; Sat, 27 Apr 2013 10:37:56 -0700 (PDT) Received: from smtp5.hushmail.com (smtp5a.hushmail.com [65.39.178.235]) by ietfa.amsl.com (Postfix) with ESMTP id 8655021F9839 for ; Sat, 27 Apr 2013 10:37:56 -0700 (PDT) Received: from smtp5.hushmail.com (smtp5a.hushmail.com [65.39.178.235]) by smtp5.hushmail.com (Postfix) with SMTP id 3E201580AD for ; Sat, 27 Apr 2013 17:37:56 +0000 (UTC) Received: from smtp.hushmail.com (w5.hushmail.com [65.39.178.80]) by smtp5.hushmail.com (Postfix) with ESMTP for ; Sat, 27 Apr 2013 17:37:56 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id 05620E6718; Sat, 27 Apr 2013 17:37:55 +0000 (UTC) MIME-Version: 1.0 Date: Sat, 27 Apr 2013 13:37:55 -0400 To: mile@ietf.org From: johnsonhammond1@hushmail.com Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20130427173756.05620E6718@smtp.hushmail.com> Subject: [mile] Biggest Fake Conference in Computer Science 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: Sat, 27 Apr 2013 18:31:51 -0000 Biggest Fake Conference in Computer Science We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without any reviews) and we were invited to submit the final paper and a payment of $500+ fee to present the paper. We decided to use the fee for better purposes than making Prof. Hamid Arabnia (Chairman of WORLDCOMP) rich. After that, we received few reminders from WORLDCOMP to pay the fee but we never responded. We MUST say that you should look at the above website if you have any thoughts to submit a paper to WORLDCOMP. DBLP and other indexing agencies have stopped indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of http://sites.google.com/site/dumpconf for comments from well-known researchers about WORLDCOMP. The status of your WORLDCOMP papers can be changed from scientific to other (i.e., junk or non-technical) at any time. Better not to have a paper than having it in WORLDCOMP and spoil the resume and peace of mind forever! Our study revealed that WORLDCOMP is a money making business, using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing out a small chunk of that money (around 20 dollars per paper published in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) who publicizes WORLDCOMP and also defends it at various forums, using fake/anonymous names. The puppet uses fake names and defames other conferences to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). That is, the puppet does all his best to get a maximum number of papers published at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has refused to provide the venue for WORLDCOMP’13 because of the fears of their image being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 is taking place at a different resort. WORLDCOMP will not be held after 2013. The draft paper submission deadline is over but still there are no committee members, no reviewers, and there is no conference Chairman. The only contact details available on WORLDCOMP’s website is just an email address! Let us make a direct request to Prof. Hamid arabnia: publish all reviews for all the papers (after blocking identifiable details) since 2000 conference. Reveal the names and affiliations of all the reviewers (for each year) and how many papers each reviewer had reviewed on average. We also request him to look at the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 Sorry for posting to multiple lists. Spreading the word is the only way to stop this bogus conference. Please forward this message to other mailing lists and people. We are shocked with Prof. Hamid Arabnia and his puppet’s activities http://worldcomp-fake-bogus.blogspot.com Search Google using the keyword worldcomp fake for additional links. From internet-drafts@ietf.org Mon Apr 29 20:22: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 3ABDA21F9C21; Mon, 29 Apr 2013 20:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 KM-k7e6GXOpO; Mon, 29 Apr 2013 20:22:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F79C21F9ADD; Mon, 29 Apr 2013 20:22:04 -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.44.p4 Message-ID: <20130430032204.31696.26883.idtracker@ietfa.amsl.com> Date: Mon, 29 Apr 2013 20:22:04 -0700 Cc: mile@ietf.org Subject: [mile] I-D Action: draft-ietf-mile-iodef-guidance-00.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: Tue, 30 Apr 2013 03:22: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 : IODEF Usage Guidance Author(s) : Panos Kampanakis Filename : draft-ietf-mile-iodef-guidance-00.txt Pages : 7 Date : 2013-04-26 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 users and 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-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From pkampana@cisco.com Tue Apr 30 06:13:28 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 185E321F9B07 for ; Tue, 30 Apr 2013 06:13:28 -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=[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 S8sVhXSX2m8u for ; Tue, 30 Apr 2013 06:13:23 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 53ECD21F9B61 for ; Tue, 30 Apr 2013 06:13:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2429; q=dns/txt; s=iport; t=1367327602; x=1368537202; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=SaF4yOeJxLnYQdGWaNirq9EKwF+7JvkoLis3VgxCR0M=; b=ZRhCB+G7gsXM8DpN1yd4gC2TBkwAKDREH1k6EpEpqvbokd26Ffcrcrqm kcSXkUban8xd9H6cHzcDv9JihxtuFoNmHzWtDBestjynMPtT/eSH9zn8j 7RMZ10T6WqoJydbEQeZ7v9A6ovbVaMqsViGqMldGYDSBmCYq+KE1xc6MW E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArUFACDCf1GtJV2b/2dsb2JhbABSgwc2vleBABZtB4IfAQEBBAEBATc0FwQCAQgRBAEBCxQJBycLFAkIAgQTCIgODLFEjj6OaTgGgmhhA5NPhHWQBIMRgig X-IronPort-AV: E=Sophos;i="4.87,582,1363132800"; d="scan'208";a="204765539" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP; 30 Apr 2013 13:13:22 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r3UDDLZ2013595 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 30 Apr 2013 13:13:21 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.150]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Tue, 30 Apr 2013 08:13:21 -0500 From: "Panos Kampanakis (pkampana)" To: "mile@ietf.org" Thread-Topic: [mile] I-D Action: draft-ietf-mile-iodef-guidance-00.txt Thread-Index: AQHORVHz/tYyKOBI3E66nfKMLe1+DJjuvXsg Date: Tue, 30 Apr 2013 13:13:21 +0000 Message-ID: <1C9F17D1873AFA47A969C4DD98F98A751D453A@xmb-rcd-x10.cisco.com> References: <20130430032204.31696.26883.idtracker@ietfa.amsl.com> In-Reply-To: <20130430032204.31696.26883.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.108] 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-00.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: Tue, 30 Apr 2013 13:13:28 -0000 Hello everyone, This is the starting point of the IODEF Guidance doc that we wanted to writ= e in order to motivate vendors to adopt and implement IODEF.=20 It is far from being done, but it is a starting point. Its last section wit= h the usecases might end up in the bis document that will come later, but f= or now I put them in the iodef guidance. Comments and feedback are welcome. Regards, Panos -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of int= ernet-drafts@ietf.org Sent: Monday, April 29, 2013 11:22 PM To: i-d-announce@ietf.org Cc: mile@ietf.org Subject: [mile] I-D Action: draft-ietf-mile-iodef-guidance-00.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-00.txt Pages : 7 Date : 2013-04-26 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 users and 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-00 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 turners@ieca.com Tue Apr 30 09:25:37 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 06A9E21F9A30 for ; Tue, 30 Apr 2013 09:25:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 qDUkJ2j86FeV for ; Tue, 30 Apr 2013 09:25:31 -0700 (PDT) Received: from gateway07.websitewelcome.com (gateway07.websitewelcome.com [69.56.176.23]) by ietfa.amsl.com (Postfix) with ESMTP id A5C3D21F98CA for ; Tue, 30 Apr 2013 09:25:14 -0700 (PDT) Received: by gateway07.websitewelcome.com (Postfix, from userid 5007) id 2737A1C5F151B; Tue, 30 Apr 2013 11:25:08 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway07.websitewelcome.com (Postfix) with ESMTP id 1AF801C5F14F6 for ; Tue, 30 Apr 2013 11:25:08 -0500 (CDT) Received: from [198.180.150.142] (port=50536 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UXDMe-0003wh-1i; Tue, 30 Apr 2013 11:25:12 -0500 Message-ID: <517FF065.8050703@ieca.com> Date: Tue, 30 Apr 2013 10:25:09 -0600 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Moriarty, Kathleen" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [198.180.150.142]:50536 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: "mile@ietf.org" Subject: Re: [mile] Updated charter for review 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, 30 Apr 2013 16:25:37 -0000 I've got a couple of questions: On 3/26/13 5:59 PM, Moriarty, Kathleen wrote: ..snip > > Description of Working Group: > > The Managed Incident Lightweight Exchange (MILE) working group develops > standards for the purpose of improving incident and indicator > information > sharing and handling capabilities. The Incident Object > Description Exchange Format (IODEF) in RFC5070 and Real-time > Inter-network > Defense (RID) in RFC6045 were developed in the INCH working group by > international Computer Security Incident Response Teams (CSIRTs) and > industry to meet the needs of a global community interested in sharing, > handling, and exchanging incident and indicator information. When reading this, I need to know when the WG can declare success. For the next item how will that happen and when can we say we're done defining enhancements? Do we need some kind of requirements document to say what's being considering for inclusion? > The working group will define enhancements and extensions to IODEF > and RID > and provide guidance for applying them. This I understand, one implementation did foo and one did bar. Is there a list of these somewhere? Are we planning on doing bake-offs to find them out? > It will also focus on > improving the > interoperability of existing and new IODEF implementations, What does this mean and how will this be done? What are the related information sharing standards? > and the > interoperation of IODEF and its extensions and enhancements with > related > standards for information sharing. Isn't the last sentence advertising? I mean the guidance might certainly provide guidance if those groups use them, but if not then it won't right? Are members from the communities going to come and speak up wrt to whether they think the guidance provided is actually useful? > The extensions and guidance > created by > the MILE working group assist with the daily operations of CSIRTs at an > organization, service providers, law enforcement, and at the > national level. The following makes it seem like we need a document that lists different communities and their requirements - no? Can we give an example of another community? > The working group has completed Proposed Standard revisions of RID > (RFC 6545) > and RID transport (RFC 6546). This transport was designed to meet > specific usage > requirements of CSIRTs and related industry groups. In order to > meet different > usage requirements for other communities, the working > group will consider > alternate transport or bindings for RID and IODEF information. I think we need to move what an incident is earlier, but we'll do that after I figure somethings out. > An incident could be a benign configuration issue, IT incident, an > infraction to a service level agreement (SLA), a system compromise, > socially engineered phishing attack, or a denial-of-service (DoS) > attack, etc. When an incident is detected, the response may include > simply filing a report, notification to the source of the incident, a > request to a third party for resolution/mitigation, I think we need to define what information sharing is somewhere. I think I know what it means and I bet a lot of people on this list know what it means, but I very much doubt some of my fellow ADs will know what's it's supposed to be. How's "information sharing" different than submitting a report - I shared some information right? > information sharing > on identified indicators of compromise, > or a request to > locate the source. IODEF defines a data representation that provides a > standard format for sharing information commonly exchanged about > computer security incidents, which includes indicators with or > without the > relevant context information. Is there a document that's going to specify what the requirements are for the future needs? > IODEF will be updated to meet the > current and > future needs, maintaining the built in extensibility, of > information sharing > where indicators with rich context for actionable sharing is provided. > RID enables the secure exchange of incident related information in > an IODEF > format providing options for security, privacy, and policy setting. There's some duplication below that we could work on removing, but getting the earlier questions answered first is more important. > MILE leverages collaboration and sharing experiences with prior work > including the IODEF data model detailed in the IODEF, existing > extensions > to the IODEF for Anti-phishing (RFC5901), and RID (RFC6545, > RFC6546) for > the secure exchange of information. MILE will also leverage the > experience > gained in using IODEF and RID in operational contexts. > > The MILE working group provides coordination for IODEF and RID > extensions that > improve capabilities for exchanging indicator and incident information. > MILE's objectives include the update of IODEF coupled with guidance > information > to enhance interoperability, deployment ease, and applicability to > current > information security data sharing use cases. MILE will also describe a > generalization of RID for secure exchange of other > security-relevant XML > formats. MILE will produce additional guidance needed for the > successful > exchange of indicator and incident information for new use cases > according to policy, > security, and privacy requirements. Finally, MILE produced a document > template with guidance for defining IODEF extensions to be followed > when > producing extensions to IODEF as appropriate. Agreed a lesson learned is to include the names of the drafts on which your work will be listed, but we really need to include the > [Removed laundry list of drafts -- outdated. We should update the > milestones below as well] > > Goals and Milestones: > > Done - WGLC Real-time Inter-network Defense (RID) > > Done - WGLC Transport for Real-time Inter-network Defense (RID) > > Done - Submit Real-time Inter-network Defense (RID) to IESG for > consideration as Standards Track document > > Done - Submit Transport Real-time Inter-network Defense (RID) to > IESG for consideration as Standards Track document > > Done - WGLC Template for extensions to IODEF > > Done - WGLC IODEF Extensions in IANA XML Registry > > Apr 2013 - WGLC IODEF Extension to support structured cybersecurity > information > > Done - Submit Template for extensions to IODEF to IESG for > consideration as Informational document > > Done - Submit IODEF Extensions in IANA XML Registry to IESG for > consideration as Standards Track document > > Jun 2013 - Submit IODEF Extension to support structured cybersecurity > information to IESG for consideration as Standards Track document. > > TBD - WGLC RFC 5070bis > > TBD - Submit RFC 5070bis to IESG for consideration as a > Standards Track document > > TBD - WGLC IODEF Reference Format > > TBD - Submit IODEF Reference Format to IESG for consideration as > a Standards Track document > > TBD - WGLC Resource-Oriented Indicator Exchange > > TBD - Submit Resource-Oriented Indicator Exchange to IESG for > consideration as a Standards Track document > > [ old milestone bits below ] > > [no doc]- WGLC IODEF Guidance > > [no doc] - Submit IODEF Extension Labeling for data protection, > retention, policies, and regulations to IESG for consideration as > Standards Track document > > [no doc] - Submit WGLC IODEF Guidance to IESG for consideration as > Informational document > > May 2012 - WGLC GRC Report Exchange [stalled] > > Jun 2012 - Submit GRC Report Exchange to IESG for consideration as > Standards Track document [stalled] > > Jun 2012 - WGLC Forensics extension [stalled] > > Jul 2012 - Submit IODEF Forensics extension to IESG for consideration > as Standards Track document [stalled] > > *From:*mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] *On Behalf > Of *Moriarty, Kathleen > *Sent:* Tuesday, March 26, 2013 4:48 PM > *To:* mile@ietf.org > *Subject:* [mile] Updated charter for review > > As discussed at the MILE meeting, we need to revise the charter. Brian > and I updated the charter and it is attached for review and comment to > the list. > > Thank you in advance! > > Best regards, > > Kathleen & Brian > > [Outdated draft charter deleted] > > > > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile > From turners@ieca.com Tue Apr 30 10:52:48 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 CC7D121F843E for ; Tue, 30 Apr 2013 10:52:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 8oIAtxMxo8YO for ; Tue, 30 Apr 2013 10:52:43 -0700 (PDT) Received: from gateway01.websitewelcome.com (gateway01.websitewelcome.com [69.93.139.19]) by ietfa.amsl.com (Postfix) with ESMTP id BF43E21F9B84 for ; Tue, 30 Apr 2013 10:52:43 -0700 (PDT) Received: by gateway01.websitewelcome.com (Postfix, from userid 5007) id 4A899BAC94C7B; Tue, 30 Apr 2013 12:52:43 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway01.websitewelcome.com (Postfix) with ESMTP id 3C1FABAC94C38 for ; Tue, 30 Apr 2013 12:52:43 -0500 (CDT) Received: from [198.180.150.142] (port=50652 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UXEjK-00088E-Sv; Tue, 30 Apr 2013 12:52:43 -0500 Message-ID: <518004E9.2010204@ieca.com> Date: Tue, 30 Apr 2013 11:52:41 -0600 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Panos Kampanakis (pkampana)" References: <20130430032204.31696.26883.idtracker@ietfa.amsl.com> <1C9F17D1873AFA47A969C4DD98F98A751D453A@xmb-rcd-x10.cisco.com> In-Reply-To: <1C9F17D1873AFA47A969C4DD98F98A751D453A@xmb-rcd-x10.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [198.180.150.142]:50652 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: "mile@ietf.org" Subject: Re: [mile] I-D Action: draft-ietf-mile-iodef-guidance-00.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: Tue, 30 Apr 2013 17:52:48 -0000 Panos, The audience for this document is both implementers and users. Most of the time RFCs are targeted at implementers. It'd be good to make sure it's clear which bis apply to which audience. spt On 4/30/13 7:13 AM, Panos Kampanakis (pkampana) wrote: > Hello everyone, > > This is the starting point of the IODEF Guidance doc that we wanted to write in order to motivate vendors to adopt and implement IODEF. > It is far from being done, but it is a starting point. Its last section with the usecases might end up in the bis document that will come later, but for now I put them in the iodef guidance. > > Comments and feedback are welcome. > > Regards, > Panos > > > > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org > Sent: Monday, April 29, 2013 11:22 PM > To: i-d-announce@ietf.org > Cc: mile@ietf.org > Subject: [mile] I-D Action: draft-ietf-mile-iodef-guidance-00.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Managed Incident Lightweight Exchange Working Group of the IETF. > > Title : IODEF Usage Guidance > Author(s) : Panos Kampanakis > Filename : draft-ietf-mile-iodef-guidance-00.txt > Pages : 7 > Date : 2013-04-26 > > 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 users and 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-00 > > > 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 > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile > From pkampana@cisco.com Tue Apr 30 14:10: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 AEA6521F91A3 for ; Tue, 30 Apr 2013 14:10:54 -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=[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 Soo9LS8eqOOs for ; Tue, 30 Apr 2013 14:10:49 -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 2D5BC21F9A30 for ; Tue, 30 Apr 2013 14:10:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3529; q=dns/txt; s=iport; t=1367356245; x=1368565845; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=JtXDSx95OMlG2vrn8X7voOQoLgxd1PvR9CXcWNz9Huk=; b=O/hulD4npBj1rRfYipva3ihzZC/4LrgDnUUzPPyjx8LNA208SBLsWhKF QgaNIrViVMMT3JySd6AeVLwVZ6Dh6qGC72iiAHEEhYkS6PIbIXztxvqqW 5156QcHoNVe7LtFdsY+d7RJHuXieovEtAOPaPDCYbX/JLkUJDaIb3Zlg0 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFANIygFGtJXG9/2dsb2JhbABSgwc2vmN/FnSCHwEBAQQBAQE3NAsMBAIBCBEEAQEBChQJBycLFAkIAgQOBQiIBAywf45kjmgxBwaCaWEDk1eEdZAHgw2CJw X-IronPort-AV: E=Sophos;i="4.87,584,1363132800"; d="scan'208";a="205048033" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-4.cisco.com with ESMTP; 30 Apr 2013 21:10:25 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r3ULAPbN003171 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 30 Apr 2013 21:10:25 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.150]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.004; Tue, 30 Apr 2013 16:10:25 -0500 From: "Panos Kampanakis (pkampana)" To: Sean Turner Thread-Topic: [mile] I-D Action: draft-ietf-mile-iodef-guidance-00.txt Thread-Index: AQHORcuC/tYyKOBI3E66nfKMLe1+DJjvDitA Date: Tue, 30 Apr 2013 21:10:24 +0000 Message-ID: <1C9F17D1873AFA47A969C4DD98F98A751D4E62@xmb-rcd-x10.cisco.com> References: <20130430032204.31696.26883.idtracker@ietfa.amsl.com> <1C9F17D1873AFA47A969C4DD98F98A751D453A@xmb-rcd-x10.cisco.com> <518004E9.2010204@ieca.com> In-Reply-To: <518004E9.2010204@ieca.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.89.108] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mile@ietf.org" Subject: Re: [mile] I-D Action: draft-ietf-mile-iodef-guidance-00.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: Tue, 30 Apr 2013 21:10:54 -0000 Thanks Paul. To clarify, the bis will be for 5070. This i0def-guidance-00 doc is mostly for implementers, but having more impl= ementation will also mean that it will be easier for users to adopt it. So,= it will benefit implementers first and users indirectly. I will make sure = it is clearer in the doc. Rgs, Panos -----Original Message----- From: Sean Turner [mailto:turners@ieca.com]=20 Sent: Tuesday, April 30, 2013 1:53 PM To: Panos Kampanakis (pkampana) Cc: mile@ietf.org Subject: Re: [mile] I-D Action: draft-ietf-mile-iodef-guidance-00.txt Panos, The audience for this document is both implementers and users. Most of the= time RFCs are targeted at implementers. It'd be good to make sure it's cl= ear which bis apply to which audience. spt On 4/30/13 7:13 AM, Panos Kampanakis (pkampana) wrote: > Hello everyone, > > This is the starting point of the IODEF Guidance doc that we wanted to wr= ite in order to motivate vendors to adopt and implement IODEF. > It is far from being done, but it is a starting point. Its last section w= ith the usecases might end up in the bis document that will come later, but= for now I put them in the iodef guidance. > > Comments and feedback are welcome. > > Regards, > Panos > > > > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf=20 > Of internet-drafts@ietf.org > Sent: Monday, April 29, 2013 11:22 PM > To: i-d-announce@ietf.org > Cc: mile@ietf.org > Subject: [mile] I-D Action: draft-ietf-mile-iodef-guidance-00.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Managed Incident Lightweight Exchange = Working Group of the IETF. > > Title : IODEF Usage Guidance > Author(s) : Panos Kampanakis > Filename : draft-ietf-mile-iodef-guidance-00.txt > Pages : 7 > Date : 2013-04-26 > > 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 users and 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-00 > > > 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 > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile > From turners@ieca.com Tue Apr 30 14:33: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 415E221F9A82 for ; Tue, 30 Apr 2013 14:33:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 GFBaj-6ZttA8 for ; Tue, 30 Apr 2013 14:33:47 -0700 (PDT) Received: from gateway04.websitewelcome.com (gateway04.websitewelcome.com [67.18.21.5]) by ietfa.amsl.com (Postfix) with ESMTP id AAAEA21F8CB4 for ; Tue, 30 Apr 2013 14:33:34 -0700 (PDT) Received: by gateway04.websitewelcome.com (Postfix, from userid 5007) id C0320CB7A054; Tue, 30 Apr 2013 16:33:11 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway04.websitewelcome.com (Postfix) with ESMTP id B4735CB7A02B for ; Tue, 30 Apr 2013 16:33:11 -0500 (CDT) Received: from [147.28.0.178] (port=50888 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UXIAp-00005o-NI; Tue, 30 Apr 2013 16:33:19 -0500 Message-ID: <5180389E.4030402@ieca.com> Date: Tue, 30 Apr 2013 15:33:18 -0600 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Panos Kampanakis (pkampana)" References: <20130430032204.31696.26883.idtracker@ietfa.amsl.com> <1C9F17D1873AFA47A969C4DD98F98A751D453A@xmb-rcd-x10.cisco.com> <518004E9.2010204@ieca.com> <1C9F17D1873AFA47A969C4DD98F98A751D4E62@xmb-rcd-x10.cisco.com> In-Reply-To: <1C9F17D1873AFA47A969C4DD98F98A751D4E62@xmb-rcd-x10.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [147.28.0.178]:50888 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 4 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: "mile@ietf.org" Subject: Re: [mile] I-D Action: draft-ietf-mile-iodef-guidance-00.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: Tue, 30 Apr 2013 21:33:52 -0000 Ah so this will only be for IODEF and not for RID? I think you might be able to weasel word it by saying users might also find this document of interest ;) spt On 4/30/13 3:10 PM, Panos Kampanakis (pkampana) wrote: > Thanks Paul. > > To clarify, the bis will be for 5070. > This i0def-guidance-00 doc is mostly for implementers, but having more implementation will also mean that it will be easier for users to adopt it. So, it will benefit implementers first and users indirectly. I will make sure it is clearer in the doc. > > Rgs, > Panos > > > -----Original Message----- > From: Sean Turner [mailto:turners@ieca.com] > Sent: Tuesday, April 30, 2013 1:53 PM > To: Panos Kampanakis (pkampana) > Cc: mile@ietf.org > Subject: Re: [mile] I-D Action: draft-ietf-mile-iodef-guidance-00.txt > > Panos, > > The audience for this document is both implementers and users. Most of the time RFCs are targeted at implementers. It'd be good to make sure it's clear which bis apply to which audience. > > spt > > On 4/30/13 7:13 AM, Panos Kampanakis (pkampana) wrote: >> Hello everyone, >> >> This is the starting point of the IODEF Guidance doc that we wanted to write in order to motivate vendors to adopt and implement IODEF. >> It is far from being done, but it is a starting point. Its last section with the usecases might end up in the bis document that will come later, but for now I put them in the iodef guidance. >> >> Comments and feedback are welcome. >> >> Regards, >> Panos >> >> >> >> -----Original Message----- >> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf >> Of internet-drafts@ietf.org >> Sent: Monday, April 29, 2013 11:22 PM >> To: i-d-announce@ietf.org >> Cc: mile@ietf.org >> Subject: [mile] I-D Action: draft-ietf-mile-iodef-guidance-00.txt >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the Managed Incident Lightweight Exchange Working Group of the IETF. >> >> Title : IODEF Usage Guidance >> Author(s) : Panos Kampanakis >> Filename : draft-ietf-mile-iodef-guidance-00.txt >> Pages : 7 >> Date : 2013-04-26 >> >> 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 users and 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-00 >> >> >> 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 >> _______________________________________________ >> mile mailing list >> mile@ietf.org >> https://www.ietf.org/mailman/listinfo/mile >> >