From ylafon@w3.org Mon Apr 2 06:30:40 2012 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 1B52F21F84FA; Mon, 2 Apr 2012 06:30:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_111=0.6, 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 Zf1pPjhwKeC8; Mon, 2 Apr 2012 06:30:39 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id 8DF2021F84F7; Mon, 2 Apr 2012 06:30:39 -0700 (PDT) Received: from ylafon by jay.w3.org with local (Exim 4.69) (envelope-from ) id 1SEhL8-0001Nx-3a; Mon, 02 Apr 2012 09:30:34 -0400 Date: Mon, 2 Apr 2012 09:30:34 -0400 (EDT) From: Yves Lafon To: apps-discuss@ietf.org, draft-ietf-mile-sci.all@tools.ietf.org Message-ID: User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=ISO-8859-15 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Mailman-Approved-At: Mon, 02 Apr 2012 06:38:19 -0700 Cc: mile@ietf.org Subject: [mile] Review of draft-ietf-mile-sci-02. 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, 02 Apr 2012 13:30:40 -0000 All, I have been selected as the Applications Area Directorate reviewer for=20 this draft (for background on appsdir, please see [1]). Document: draft-ietf-mile-sci-02 Title: IODEF-extension to support structured cybersecurity information Reviewer: Yves Lafon Review Date: April 2, 2012 Review Summary: This draft is almost ready for publication, small=20 important issues needs to be addressed or clarified before publication. Document Summary: The document define a 'wrapper' document to present in a common format=20 different cybersecurity report formats. Major Issues: There are two issues. * In the normative reference section, there are reference to many document= =20 where the licensing information is not clear, like [CAPEC]. It would be=20 good to clarify the license information of the documents linked in the=20 normative section. * The schema provided is invalid, this line needs to be fixed based on=20 intent: Both issues are major issues as they need being fixed, but I consider them= =20 easy to fix. Minor Issue: In the definition of 'AttackPattern' class, the restriction in the prose=20 (4.3.1) is not expressed in the schema. << AttackPatternID: OPTIONAL. STRING. An identifier of an attack pattern to be reported. This attribute SHOULD be used whenever such identifier is available, but could be omitted if no such one is available. In this case, either RawData or Reference elements, or both of them, MUST be provided. >> Same issue with 'Platform', 'Vulnerability', 'Weakness', 'EventReport',=20 'Verification'... Also the other MUST-level requirement of ensuring consistency of the value= =20 might be tested using a schematron schema, that could be a useful addition= =20 if the goal of the schema is to provice automated verification. In the example, the foreign namespaces definition also include links to=20 schemas, it might be better to remove those and keep in the main schema=20 the list of possible namespaces (and their schemas), ie: keep the schema=20 referring to other schema for people requiring schema validation, and=20 remove verbosity in instances (it should affect only the definition of=20 XMLDATA). The downside being that the main schema needs to be updated=20 when the list in 4.1 is updated (and schema link should be in the list in= =20 4.1). HTH, [1] --=20 Baroula que barouleras, au ti=E9u toujou t'entourneras. ~~Yves From takeshi_takahashi@nict.go.jp Mon Apr 2 19:50:09 2012 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 978DE21F8769; Mon, 2 Apr 2012 19:50:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.755 X-Spam-Level: X-Spam-Status: No, score=-0.755 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, J_CHICKENPOX_111=0.6] 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 M5PokqkLhRpk; Mon, 2 Apr 2012 19:50:09 -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 C20CF21F8767; Mon, 2 Apr 2012 19:50:08 -0700 (PDT) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id q332o3bx005042; Tue, 3 Apr 2012 11:50:03 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id q332o3Af007310; Tue, 3 Apr 2012 11:50:03 +0900 (JST) Received: from mail2.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id q332o3v4007303; Tue, 3 Apr 2012 11:50:03 +0900 (JST) Received: from mail2.nict.go.jp (localhost [127.0.0.1]) by mail2.nict.go.jp (NICT Mail) with ESMTP id 232331608B; Tue, 3 Apr 2012 11:50:03 +0900 (JST) Received: from takeVAIO2 (unknown [133.243.119.6]) by mail2.nict.go.jp (NICT Mail) with ESMTP id 1CD3B16003; Tue, 3 Apr 2012 11:50:03 +0900 (JST) From: "Takeshi Takahashi" To: "'Yves Lafon'" , , References: In-Reply-To: Date: Tue, 3 Apr 2012 11:50:02 +0900 Message-ID: <00c601cd1144$77565f90$66031eb0$@nict.go.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGXb20xT+3R8pLmZ4LMaTVwjZ7Jb5bzqVlQ Content-Language: ja Cc: mile@ietf.org Subject: Re: [mile] Review of draft-ietf-mile-sci-02. 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, 03 Apr 2012 02:50:09 -0000 Thank you very much, Yves, for your kind review. I appreciate that very much. Let me modify the draft to handle the issues you kindly pointed out = along with the other issues raised at the Paris meeting. Kind Regards, Take > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf = Of > Yves Lafon > Sent: Monday, April 02, 2012 10:31 PM > To: apps-discuss@ietf.org; draft-ietf-mile-sci.all@tools.ietf.org > Cc: mile@ietf.org > Subject: [mile] Review of draft-ietf-mile-sci-02. >=20 > All, > I have been selected as the Applications Area Directorate reviewer for > this draft (for background on appsdir, please see [1]). >=20 > Document: draft-ietf-mile-sci-02 > Title: IODEF-extension to support structured cybersecurity information > Reviewer: Yves Lafon > Review Date: April 2, 2012 >=20 > Review Summary: This draft is almost ready for publication, small > important issues needs to be addressed or clarified before = publication. >=20 > Document Summary: > The document define a 'wrapper' document to present in a common format > different cybersecurity report formats. >=20 > Major Issues: >=20 > There are two issues. > * In the normative reference section, there are reference to many = document > where the licensing information is not clear, like [CAPEC]. It would = be > good to clarify the license information of the documents linked in the > normative section. >=20 > * The schema provided is invalid, this line needs to be fixed based on > intent: > use=3D"prohibited" value=3D"xml"/> >=20 > Both issues are major issues as they need being fixed, but I consider > them easy to fix. >=20 > Minor Issue: >=20 > In the definition of 'AttackPattern' class, the restriction in the = prose > (4.3.1) is not expressed in the schema. > << > AttackPatternID: OPTIONAL. STRING. An identifier of an attack > pattern to be reported. This attribute SHOULD be used whenever > such identifier is available, but could be omitted if no such = one > is available. In this case, either RawData or Reference = elements, > or both of them, MUST be provided. > >> > Same issue with 'Platform', 'Vulnerability', 'Weakness', = 'EventReport', > 'Verification'... > Also the other MUST-level requirement of ensuring consistency of the = value > might be tested using a schematron schema, that could be a useful = addition > if the goal of the schema is to provice automated verification. >=20 > In the example, the foreign namespaces definition also include links = to > schemas, it might be better to remove those and keep in the main = schema > the list of possible namespaces (and their schemas), ie: keep the = schema > referring to other schema for people requiring schema validation, and > remove verbosity in instances (it should affect only the definition of > XMLDATA). The downside being that the main schema needs to be updated > when the list in 4.1 is updated (and schema link should be in the list > in 4.1). >=20 > HTH, >=20 > [1] > torate> >=20 > -- > Baroula que barouleras, au ti=E9u toujou t'entourneras. >=20 > ~~Yves >=20 > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From bakerj@mitre.org Tue Apr 3 09:41:44 2012 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 3402A11E8075 for ; Tue, 3 Apr 2012 09:41:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.185 X-Spam-Level: X-Spam-Status: No, score=-4.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tTtXfU1fYLsF for ; Tue, 3 Apr 2012 09:41:43 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 5443421F8512 for ; Tue, 3 Apr 2012 09:41:36 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id B6C1521B0235 for ; Tue, 3 Apr 2012 12:41:35 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id AC8F321B02B3 for ; Tue, 3 Apr 2012 12:41:35 -0400 (EDT) Received: from IMCMBX03.MITRE.ORG ([169.254.3.93]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.01.0339.001; Tue, 3 Apr 2012 12:41:35 -0400 From: "Baker, Jon" To: "mile@ietf.org" Thread-Topic: cybox+ maec and IEEE MMDEF WG - paris wg meeting follow Thread-Index: Ac0RuJ+MMAqIerIDT5OzLuU43DGRCA== Date: Tue, 3 Apr 2012 16:41:34 +0000 Message-ID: <6C1C15D8B5510B4B8FF132B10D386513702163@IMCMBX03.MITRE.ORG> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.175.2] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [mile] cybox+ maec and IEEE MMDEF WG - paris wg meeting follow 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, 03 Apr 2012 16:41:44 -0000 At the Paris WG meeting I was asked about any plans for CybOX and MAEC and = the IEEE. During the meeting I was able to give a short description of the = activities with the Malware Metadata Exchange Format Working Group (MMDEF) = and committed to providing a bit more information about the activity as a f= ollow up on this list. More information about this group is available here= : http://standards.ieee.org/develop/indconn/icsg/mmdef.html I talked Penny Chase, who leads the MAEC effort about their involvement wit= h the MMDEF WG. Here is what she had to say: -------------------------------------- When we started to develop MAEC in 2010 we became aware of the first versio= n of the IEEE Industry Connections Security Group (ICSG) Malware Metadata E= xchange Format schema. The IEEE ICSG working group that developed schema co= nsisted of several anti-virus vendor and their goal was to share a minimal = amount of malware metadata when exchanging samples. MAEC 1.0 (released in J= une 2010) imported elements of the MMDEF schema. Over a year ago we were approached by the IEEE ICSG. After working on some = other projects, they decided that they wanted to expand MMDEF schema to cha= racterize malware behavior. At that time the resources who had worked on th= e schema were no longer available. In addition and having looked at MAEC, w= hich focused on characterizing results from dynamic analysis, they thought = that it made sense to integrate MAEC into the new IEEE ICSG schema. IEEE IC= SG launched a new working group to developed MMDEF v 2.0, with Ivan Kirillo= v, MAEC's lead architect, as co-chair.=20 Before agreeing to participate, we had discussions about the relationship b= etween MAEC and the MMDEF schema. We were assured that IEEE ICSG was willin= g to have MAEC as an independent schema that the MMDEF schema could refer t= o. The MMDEF working group's goal =A0is to import selected portions of MAEC= /CybOX into the IEEE ICSG MMDEF v 2.0 schema. It is not clear if MMDEF v 2.0 will become an IEEE standard. MMDEF v 1.0 is= available for people to use, but isn't an official IEEE standard (ICSG pro= ducts do not necessarily become IEEE standards). Some people in the working= group have brought it up, but it hasn't been discussed in-depth. -------------------------------------- I hope this additional information about MAEC and the IEEE MMDEF WG address= es your questions. Let me know if there is anything else I can help with. Regards, Jon =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Jonathan O. Baker G022 - IA Industry Collaboration The MITRE Corporation Email: bakerj@mitre.org From trammell@tik.ee.ethz.ch Thu Apr 5 06:33:40 2012 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 E04CE21F8827 for ; Thu, 5 Apr 2012 06:33:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tnoVpcKiCGz1 for ; Thu, 5 Apr 2012 06:33:40 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 0D4FD21F86C6 for ; Thu, 5 Apr 2012 06:33:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id AAB31D9321; Thu, 5 Apr 2012 15:33:38 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ppPhMhq+nq+Y; Thu, 5 Apr 2012 15:33:38 +0200 (MEST) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 74C4CD9312; Thu, 5 Apr 2012 15:33:38 +0200 (MEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Brian Trammell In-Reply-To: <4F730008.1080103@mitre.org> Date: Thu, 5 Apr 2012 15:33:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <54982566-63C3-454B-90A1-294D9343A7FD@tik.ee.ethz.ch> References: <4F730008.1080103@mitre.org> To: "" X-Mailer: Apple Mail (2.1257) Subject: Re: [mile] Adoption of draft-moriarty-mile-grc-exchange as a MILE WG item 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, 05 Apr 2012 13:33:41 -0000 Greetings, all, Given the hum in the room last week in Paris and the comments in this = thread, I see clear consensus for the adoption of = draft-moriarty-mile-grc-exchange as a MILE working group. I ask the authors to submit the next revision of the document as = draft-ietf-mile-grc-exchange-00. Many thanks, and best regards, Brian On Mar 28, 2012, at 2:11 PM, Martin, Robert A. wrote: > I agree that GRC Exchange would be a valuable addition to the MILE = work items. >=20 > Sorry I couldn't join you all at the meeting - I am tied up hosting = the DoD/DHS/NIST Software Assurance Forum here at MITRE McLean with over = 300 participants. >=20 > Planning on being at the next IETF meeting though... >=20 > Bob >=20 > On 3/28/12 5:17 AM, Adam Montville wrote: >> Agree. I would like to see this item adopted by the WG as well. >>=20 >> From: = kent_landfield= > >> Date: Wed, 28 Mar 2012 03:21:55 -0500 >> = To:>,> >> Subject: Re: [mile] Adoption of draft-moriarty-mile-grc-exchange as a = MILE WG item >>=20 >> I would like to see this adopted as a working group item. >>=20 >> FYI, yesterday's meeting was very productive time spent=85 Thanks = all. >>=20 >> Kent Landfield >> Director Content Strategy, Architecture and Standards >>=20 >> McAfee | An Intel Company >> 5000 Headquarters Dr. >> Plano, Texas 75024 >>=20 >> Direct: +1.972.963.7096 >> Mobile: +1.817.637.8026 >> Web: www.mcafee.com >>=20 >> From: Brian = Trammell> >> Date: Wed, 28 Mar 2012 03:16:09 -0500 >> To: = ">"> >> Subject: [mile] Adoption of draft-moriarty-mile-grc-exchange as a = MILE WG item >>=20 >> Greetings, all, >>=20 >> At the MILE WG meeting yesterday, there was consensus in the room to = adopt draft-moriarty-mile-grc-exchange as a working group item. I would = like to confirm this consensus call on the list; if anyone has = additional objections or comments about the adoption of this draft, = please let them be known on the list by next Tuesday. >>=20 >> Many thanks, and best regards, >>=20 >> Brian >> _______________________________________________ >> 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 trammell@tik.ee.ethz.ch Thu Apr 5 06:35:28 2012 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 497E221F8831 for ; Thu, 5 Apr 2012 06:35:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sdmfqsxkby68 for ; Thu, 5 Apr 2012 06:35:27 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 63F2821F882E for ; Thu, 5 Apr 2012 06:35:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id C479BD930B for ; Thu, 5 Apr 2012 15:35:26 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id UiB4n-gCnHXT for ; Thu, 5 Apr 2012 15:35:26 +0200 (MEST) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 980D4D9300 for ; Thu, 5 Apr 2012 15:35:26 +0200 (MEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1257) From: Brian Trammell In-Reply-To: <54982566-63C3-454B-90A1-294D9343A7FD@tik.ee.ethz.ch> Date: Thu, 5 Apr 2012 15:35:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F730008.1080103@mitre.org> <54982566-63C3-454B-90A1-294D9343A7FD@tik.ee.ethz.ch> To: "" X-Mailer: Apple Mail (2.1257) Subject: Re: [mile] Adoption of draft-moriarty-mile-grc-exchange as a MILE WG item 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, 05 Apr 2012 13:35:28 -0000 (as a MILE working group *document*...) On Apr 5, 2012, at 3:33 PM, Brian Trammell wrote: > Greetings, all, >=20 > Given the hum in the room last week in Paris and the comments in this = thread, I see clear consensus for the adoption of = draft-moriarty-mile-grc-exchange as a MILE working group. >=20 > I ask the authors to submit the next revision of the document as = draft-ietf-mile-grc-exchange-00. >=20 > Many thanks, and best regards, >=20 > Brian >=20 > On Mar 28, 2012, at 2:11 PM, Martin, Robert A. wrote: >=20 >> I agree that GRC Exchange would be a valuable addition to the MILE = work items. >>=20 >> Sorry I couldn't join you all at the meeting - I am tied up hosting = the DoD/DHS/NIST Software Assurance Forum here at MITRE McLean with over = 300 participants. >>=20 >> Planning on being at the next IETF meeting though... >>=20 >> Bob >>=20 >> On 3/28/12 5:17 AM, Adam Montville wrote: >>> Agree. I would like to see this item adopted by the WG as well. >>>=20 >>> From: = kent_landfield= > >>> Date: Wed, 28 Mar 2012 03:21:55 -0500 >>> = To:>,> >>> Subject: Re: [mile] Adoption of draft-moriarty-mile-grc-exchange as = a MILE WG item >>>=20 >>> I would like to see this adopted as a working group item. >>>=20 >>> FYI, yesterday's meeting was very productive time spent=85 Thanks = all. >>>=20 >>> Kent Landfield >>> Director Content Strategy, Architecture and Standards >>>=20 >>> McAfee | An Intel Company >>> 5000 Headquarters Dr. >>> Plano, Texas 75024 >>>=20 >>> Direct: +1.972.963.7096 >>> Mobile: +1.817.637.8026 >>> Web: www.mcafee.com >>>=20 >>> From: Brian = Trammell> >>> Date: Wed, 28 Mar 2012 03:16:09 -0500 >>> To: = ">"> >>> Subject: [mile] Adoption of draft-moriarty-mile-grc-exchange as a = MILE WG item >>>=20 >>> Greetings, all, >>>=20 >>> At the MILE WG meeting yesterday, there was consensus in the room to = adopt draft-moriarty-mile-grc-exchange as a working group item. I would = like to confirm this consensus call on the list; if anyone has = additional objections or comments about the adoption of this draft, = please let them be known on the list by next Tuesday. >>>=20 >>> Many thanks, and best regards, >>>=20 >>> Brian >>> _______________________________________________ >>> 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 >=20 > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From kathleen.moriarty@emc.com Thu Apr 5 07:33:16 2012 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 9D9C521F8597 for ; Thu, 5 Apr 2012 07:33:16 -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 Lbah3q7eRFJN for ; Thu, 5 Apr 2012 07:33:15 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 84E8121F8596 for ; Thu, 5 Apr 2012 07:33:15 -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 q35EXAgB006434 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 5 Apr 2012 10:33:13 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd04.lss.emc.com [10.254.222.226]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor) for ; Thu, 5 Apr 2012 10:33:01 -0400 Received: from mxhub29.corp.emc.com (mxhub29.corp.emc.com [128.222.70.169]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q35EX0g9001496 for ; Thu, 5 Apr 2012 10:33:01 -0400 Received: from mx06a.corp.emc.com ([169.254.1.106]) by mxhub29.corp.emc.com ([128.222.70.169]) with mapi; Thu, 5 Apr 2012 10:33:00 -0400 From: To: Date: Thu, 5 Apr 2012 10:32:58 -0400 Thread-Topic: [mile] Adoption of draft-trammell-mile-iodef-xmlreg-01 as a MILE WG item Thread-Index: AQHNDN3sPUaACnnjFEOURZhbBsiSLpaMVy7g 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [mile] Adoption of draft-trammell-mile-iodef-xmlreg-01 as a MILE WG item 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, 05 Apr 2012 14:33:16 -0000 Hello, There is clear consensus for the adoption of draft-trammell-mile-iodef-xmlr= eg-01 as a MILE working group document from the hum in the MILE meeting in = Paris and comments to the list. Brian, please submit the next revision of the document as draft-ietf-mile-i= odef-xmlreg-00. Thank you! Kathleen -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of kat= hleen.moriarty@emc.com Sent: Wednesday, March 28, 2012 8:25 AM To: mile@ietf.org Subject: [mile] Adoption of draft-trammell-mile-iodef-xmlreg-01 as a MILE W= G item Hello, At the MILE WG meeting yesterday, there was consensus in the room to adopt = draft-trammell-mile-iodef-xmlreg-01 as a working group item. I would like t= o confirm this consensus call on the list; if anyone has additional objecti= ons or comments about the adoption of this draft, please let them be known = on the list by next Tuesday. http://tools.ietf.org/html/draft-trammell-mile-iodef-xmlreg-01 Thank you! Kathleen _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile From kathleen.moriarty@emc.com Thu Apr 5 07:50:34 2012 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 B7DEA21F86D6 for ; Thu, 5 Apr 2012 07:50:34 -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 eJBrchA1ch8D for ; Thu, 5 Apr 2012 07:50:33 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 82CBD21F86BE for ; Thu, 5 Apr 2012 07:50:33 -0700 (PDT) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q35EoWk2021749 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Apr 2012 10:50:32 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.226]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Thu, 5 Apr 2012 10:50:19 -0400 Received: from mxhub20.corp.emc.com (mxhub20.corp.emc.com [10.254.93.49]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q35EoJ0h019801; Thu, 5 Apr 2012 10:50:19 -0400 Received: from mx06a.corp.emc.com ([169.254.1.106]) by mxhub20.corp.emc.com ([10.254.93.49]) with mapi; Thu, 5 Apr 2012 10:50:18 -0400 From: To: , Date: Thu, 5 Apr 2012 10:50:16 -0400 Thread-Topic: cybox+ maec and IEEE MMDEF WG - paris wg meeting follow Thread-Index: Ac0RuJ+MMAqIerIDT5OzLuU43DGRCABf6mug Message-ID: References: <6C1C15D8B5510B4B8FF132B10D386513702163@IMCMBX03.MITRE.ORG> In-Reply-To: <6C1C15D8B5510B4B8FF132B10D386513702163@IMCMBX03.MITRE.ORG> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [mile] cybox+ maec and IEEE MMDEF WG - paris wg meeting follow 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, 05 Apr 2012 14:50:34 -0000 Thank you for the update, Jon! I have a few follow up questions to help determine the path forward and opt= ions for MILE. From the message below, you may not have the answers yet, s= o if you can keep MILE posted as this evolves, it would be appreciated! Will the work stay in IEEE? If so, is there a chance that a normative refe= rence will be possible? =20 MAEC impacts the SCI draft and possibly the forensics draft as a (possible)= referenced specification. It sounds like the only reference that may emer= ge from the WG is for MMDEF and that is not certain. Is that correct? Since part of CybOX is included in your IEEE effort, can you explain what t= hat means for any possible standardization efforts around CybOX? Will CybO= X show up in multiple standards efforts or just the IEEE (where it may not = become a normative reference and it appears to be part of MMDEF)? Is there= a chance it would be proposed to MILE for the integration possibilities wi= th IODEF? I just to make sure we are clear on options, it sounds like we won't have a= normative reference through the IEEE effort, is that right? Does this jus= t apply to MAEC or are other specifications as well (CybOX, CAPEC, etc.)? = As mentioned at the MILE meeting, it sounds like we need to move forward on= the forensics document to cover the MILE charter item and WG needs. If a = standard that can be referenced emerges we can consider it later, but need = to work towards meeting the charter items until that happens. =20 Thank you, Kathleen -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Bak= er, Jon Sent: Tuesday, April 03, 2012 12:42 PM To: mile@ietf.org Subject: [mile] cybox+ maec and IEEE MMDEF WG - paris wg meeting follow At the Paris WG meeting I was asked about any plans for CybOX and MAEC and = the IEEE. During the meeting I was able to give a short description of the = activities with the Malware Metadata Exchange Format Working Group (MMDEF) = and committed to providing a bit more information about the activity as a f= ollow up on this list. More information about this group is available here= : http://standards.ieee.org/develop/indconn/icsg/mmdef.html I talked Penny Chase, who leads the MAEC effort about their involvement wit= h the MMDEF WG. Here is what she had to say: -------------------------------------- When we started to develop MAEC in 2010 we became aware of the first versio= n of the IEEE Industry Connections Security Group (ICSG) Malware Metadata E= xchange Format schema. The IEEE ICSG working group that developed schema co= nsisted of several anti-virus vendor and their goal was to share a minimal = amount of malware metadata when exchanging samples. MAEC 1.0 (released in J= une 2010) imported elements of the MMDEF schema. Over a year ago we were approached by the IEEE ICSG. After working on some = other projects, they decided that they wanted to expand MMDEF schema to cha= racterize malware behavior. At that time the resources who had worked on th= e schema were no longer available. In addition and having looked at MAEC, w= hich focused on characterizing results from dynamic analysis, they thought = that it made sense to integrate MAEC into the new IEEE ICSG schema. IEEE IC= SG launched a new working group to developed MMDEF v 2.0, with Ivan Kirillo= v, MAEC's lead architect, as co-chair.=20 Before agreeing to participate, we had discussions about the relationship b= etween MAEC and the MMDEF schema. We were assured that IEEE ICSG was willin= g to have MAEC as an independent schema that the MMDEF schema could refer t= o. The MMDEF working group's goal =A0is to import selected portions of MAEC= /CybOX into the IEEE ICSG MMDEF v 2.0 schema. It is not clear if MMDEF v 2.0 will become an IEEE standard. MMDEF v 1.0 is= available for people to use, but isn't an official IEEE standard (ICSG pro= ducts do not necessarily become IEEE standards). Some people in the working= group have brought it up, but it hasn't been discussed in-depth. -------------------------------------- I hope this additional information about MAEC and the IEEE MMDEF WG address= es your questions. Let me know if there is anything else I can help with. Regards, Jon =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Jonathan O. Baker G022 - IA Industry Collaboration The MITRE Corporation Email: bakerj@mitre.org _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile From amontville@tripwire.com Mon Apr 9 11:38:20 2012 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 B4C3A21F87D6 for ; Mon, 9 Apr 2012 11:38:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 n+OO6emMTqiG for ; Mon, 9 Apr 2012 11:38:20 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe002.messaging.microsoft.com [216.32.180.12]) by ietfa.amsl.com (Postfix) with ESMTP id CA52D21F87CF for ; Mon, 9 Apr 2012 11:38:19 -0700 (PDT) Received: from mail30-va3-R.bigfish.com (10.7.14.247) by VA3EHSOBE008.bigfish.com (10.7.40.28) with Microsoft SMTP Server id 14.1.225.23; Mon, 9 Apr 2012 18:38:18 +0000 Received: from mail30-va3 (localhost [127.0.0.1]) by mail30-va3-R.bigfish.com (Postfix) with ESMTP id 842431C02E5 for ; Mon, 9 Apr 2012 18:38:18 +0000 (UTC) X-SpamScore: -12 X-BigFish: VPS-12(zz1415J9f17Rzz1202hzz8275bhz2dh2a8h668h839h944h) X-Forefront-Antispam-Report: CIP:174.47.84.216; KIP:(null); UIP:(null); IPV:NLI; H:PDXHB01.tripwire.com; RD:174-47-84-216.static.twtelecom.net; EFVD:NLI Received: from mail30-va3 (localhost.localdomain [127.0.0.1]) by mail30-va3 (MessageSwitch) id 133399669651256_15448; Mon, 9 Apr 2012 18:38:16 +0000 (UTC) Received: from VA3EHSMHS014.bigfish.com (unknown [10.7.14.235]) by mail30-va3.bigfish.com (Postfix) with ESMTP id 0435C1A00B5 for ; Mon, 9 Apr 2012 18:38:16 +0000 (UTC) Received: from PDXHB01.tripwire.com (174.47.84.216) by VA3EHSMHS014.bigfish.com (10.7.99.24) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 9 Apr 2012 18:38:15 +0000 Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 9 Apr 2012 11:47:50 -0700 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0355.002; Mon, 9 Apr 2012 11:38:13 -0700 From: Adam Montville To: "mile@ietf.org" Thread-Topic: IODEF Reference Format for Enumerations Thread-Index: AQHNFn/rimqKx0bIq0Wznd3Jbi9osA== Date: Mon, 9 Apr 2012 18:38:13 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [172.30.0.234] x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: tripwire.com Subject: [mile] IODEF Reference Format for Enumerations 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, 09 Apr 2012 18:38:20 -0000 All: There is an identified need to specify a format to include relevant enumeration values in an IODEF document. The initial idea is to place enumeration values and their references in IODEF's Reference class. There are several ways to accomplish this goal. I'll do my best to enumerate some options here, then I hope to hear some feedback/opinions about the different approaches from the list. >From the Structured Cybersecurity Information draft (draft-takahashi-mile-sci-02), we may be interested to include the following (not an inclusive list) enumerations in an IODEF document: CAPEC, CCE, CPE, CVE, CWE, IEC 19770-2. The IODEF Reference class is described in 3.9.1 of RFC 5070, where a Reference must have a ReferenceName and zero or more of URL or Description respectively. For each option described below, we can consider use of the IANA registry. The registry may be used to identify the identifier category and potentially the appropriate identification format for that category. Option 1: Simple ID =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The first option would simply embed the relevant identifier in the ReferenceName element of the Reference class. This may look like the following: id http://www.example.com/path http://www.otherexample.com/path Description Using this option, a variety of specific identifier formats could be specified. CVE, for example, would start with "CVE-" and this convention may be registered in an IANA table. No changes to IODEF are required for this option. Option 2: ID with coupled ID type =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D The second option would prepend the identifier with it's type, which may look something like the following. id_type:id http://www.example.com/path http://www.otherexample.com/path Description Using this option, a variety of specific identifier types could be specified, such that the identifier itself would not necessarily be constrained, nor would new identifier formats necessarily need to be specified in the future. An IANA table may be used for this solution as well. No changes to IODEF would be required for this option. Option 3: ID with type expressed in Reference attribute =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D The third option would require opening IODEF to update the Reference class with an attribute, which may look something like the following. id http://www.example.com/path http://www.otherexample.com/path Description Changes to IODEF are required for this option. ---- I look forward to fielding responses to these options, including any additional options you may see, but which are not listed. What is your solution preference? Regards, Adam W. Montville | Security and Compliance Architect Direct: 503 276-7661 Mobile: 360 471-7815 TRIPWIRE | Take CONTROL http://www.tripwire.com From Thomas.Millar@us-cert.gov Mon Apr 9 12:40:58 2012 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 4A42721F87B9 for ; Mon, 9 Apr 2012 12:40:58 -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 0H4ektbLSHG6 for ; Mon, 9 Apr 2012 12:40:57 -0700 (PDT) Received: from shaggy.brass.us-cert.gov (shaggy.brass.us-cert.gov [208.73.184.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4756721F8493 for ; Mon, 9 Apr 2012 12:40:56 -0700 (PDT) Received: from shaggy.brass.us-cert.gov (localhost.localdomain [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id E4E0C50A2B; Mon, 9 Apr 2012 19:40:55 +0000 (UTC) Received: from dabba.bronze.us-cert.gov (dabba.bronze.us-cert.gov [192.168.16.121]) by shaggy.brass.us-cert.gov (Postfix) with ESMTP id C358050A2A; Mon, 9 Apr 2012 19:40:55 +0000 (UTC) Received: from needle.bronze.us-cert.gov (needle.bronze.us-cert.gov [192.168.16.109]) by dabba.bronze.us-cert.gov (Postfix) with ESMTP id 9B47A6E45D; Mon, 9 Apr 2012 19:40:55 +0000 (UTC) Received: from hive.bronze.us-cert.gov ([192.168.16.108]) by needle.bronze.us-cert.gov with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 Apr 2012 14:40:55 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 9 Apr 2012 14:40:54 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mile] IODEF Reference Format for Enumerations Thread-Index: AQHNFn/rimqKx0bIq0Wznd3Jbi9osJaS4t/g References: From: To: , X-OriginalArrivalTime: 09 Apr 2012 19:40:55.0656 (UTC) FILETIME=[AE23D680:01CD1688] X-TM-AS-Product-Ver: IMSS-7.1.0.1350-6.8.0.1017-18828.000 X-TM-AS-Result: No--17.620-5.0-31-10 X-imss-scan-details: No--17.620-5.0-31-10 X-TMASE-MatchedRID: 0dFPYP4mu5TWKlsMlVwfQ9aZQXm25YCOeEA/UnKXgYoiFs20Vxq/wrmR LdJVdEm/B4nXQQumWv1UFwdbPogKxXbXWvzc46hW6rBZUF8y6+hu/Xr6CKXiN5J5XtPVefA9zdl o26al4KHmYe1UWnReIu0MWNt2MSe0uZxfSEY3BwLtP6Pv+A+w88pJJjzkRuR1PxPqlK7F9mPwRB 9hRkLXB2o+e3Fq818IOk3QcWyDDB92svS9kAH/GLMjW/sniEQKM3PBQtDBME88xv0w5FklStEw+ lHrZKHlY8qL6lVnpK+OXYAAA85B0ZedMXZXJ9hcUylSIDEm+MebKpAlY2y6SeJGB65J3jNQ48fE 6PIFskCrjx1CmlQYTekFggkz1/z6fTnBV6dlHiKZroPNdqiG8zZ/CJoFmAP86VtdwUtYTw2GXEG XfeFQbWjyko0752kYgs9TRfv65SbvXvInwhwK2xzwnpmtY/+rlfGwpNSPVn6cUrtUT/EvSfoLR4 +zsDTtAqYBE3k9Mpw= X-IMSS-DKIM-White-List: No Subject: Re: [mile] IODEF Reference Format for Enumerations 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, 09 Apr 2012 19:40:58 -0000 I vote option 1, for the sake of simplicity. I realize it may not result = in perfect interpretation every time, but neither will the other = options. =A0- Tom Millar, US-CERT thomas.millar@us-cert.gov BB: thomas.millar@dhs.gov / 202-631-1915 24x7: soc@us-cert.gov / 888-282-0870=20 -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of = Adam Montville Sent: Monday, April 09, 2012 2:38 PM To: mile@ietf.org Subject: [mile] IODEF Reference Format for Enumerations All: There is an identified need to specify a format to include relevant = enumeration values in an IODEF document. The initial idea is to place = enumeration values and their references in IODEF's Reference class. = There are several ways to accomplish this goal. I'll do my best to = enumerate some options here, then I hope to hear some feedback/opinions = about the different approaches from the list. >From the Structured Cybersecurity Information draft = (draft-takahashi-mile-sci-02), we may be interested to include the = following (not an inclusive list) enumerations in an IODEF document: CAPEC, CCE, CPE, CVE, CWE, IEC 19770-2. The IODEF Reference class is described in 3.9.1 of RFC 5070, where a = Reference must have a ReferenceName and zero or more of URL or = Description respectively. For each option described below, we can consider use of the IANA = registry. The registry may be used to identify the identifier category and = potentially the appropriate identification format for that category. Option 1: Simple ID =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The first option would simply embed the relevant identifier in the = ReferenceName element of the Reference class. This may look like the following: id http://www.example.com/path http://www.otherexample.com/path Description Using this option, a variety of specific identifier formats could be = specified. CVE, for example, would start with "CVE-" and this = convention may be registered in an IANA table. No changes to IODEF are required for this option. Option 2: ID with coupled ID type =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D The second option would prepend the identifier with it's type, which may = look something like the following. id_type:id http://www.example.com/path http://www.otherexample.com/path Description Using this option, a variety of specific identifier types could be = specified, such that the identifier itself would not necessarily be = constrained, nor would new identifier formats necessarily need to be = specified in the future. An IANA table may be used for this solution as = well. No changes to IODEF would be required for this option. Option 3: ID with type expressed in Reference attribute = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D The third option would require opening IODEF to update the Reference = class with an attribute, which may look something like the following. id http://www.example.com/path http://www.otherexample.com/path Description Changes to IODEF are required for this option. ---- I look forward to fielding responses to these options, including any = additional options you may see, but which are not listed. What is your solution preference? Regards, Adam W. Montville | Security and Compliance Architect Direct: 503 276-7661 Mobile: 360 471-7815 TRIPWIRE | Take CONTROL http://www.tripwire.com _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile From david.waltermire@nist.gov Mon Apr 9 14:53:15 2012 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 803D721F87FE for ; Mon, 9 Apr 2012 14:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.116 X-Spam-Level: X-Spam-Status: No, score=-5.116 tagged_above=-999 required=5 tests=[AWL=-0.183, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_FWDLOOK=1.666] 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 hzPY-UT61kay for ; Mon, 9 Apr 2012 14:53:14 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id EB9A821F87E3 for ; Mon, 9 Apr 2012 14:53:13 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 9 Apr 2012 17:53:10 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Mon, 9 Apr 2012 17:52:18 -0400 From: "Waltermire, David A." To: Adam Montville , "mile@ietf.org" Date: Mon, 9 Apr 2012 17:53:11 -0400 Thread-Topic: IODEF Reference Format for Enumerations Thread-Index: AQHNFn/rimqKx0bIq0Wznd3Jbi9osJaS2mYA 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: text/plain; charset="us-ascii" MIME-Version: 1.0 Subject: Re: [mile] IODEF Reference Format for Enumerations 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, 09 Apr 2012 21:53:15 -0000 My preference would be to use option #2. This approadch will essentially provide a namespace for identifiers which conveys more semantics than a simple string. Although maybe forward looking, this will be useful in cases where different identification schemes may have similar syntax but differ in meaning. It is also useful to denote revisions for a given scheme where there may be partial overlap in instances. This approach provides greater overall flexibility without the need to revise IODEF. If IODEF is revised, we may want to consider option 3 to avoid a secondary parsing step to separate the namespace from the value. Sincerely, Dave Waltermire > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of > Adam Montville > Sent: Monday, April 09, 2012 2:38 PM > To: mile@ietf.org > Subject: [mile] IODEF Reference Format for Enumerations > > All: > > There is an identified need to specify a format to include relevant > enumeration values in an IODEF document. The initial idea is to place > enumeration values and their references in IODEF's Reference class. > There are several ways to accomplish this goal. I'll do my best to > enumerate some options here, then I hope to hear some feedback/opinions > about the different approaches from the list. > > From the Structured Cybersecurity Information draft (draft-takahashi- > mile-sci-02), we may be interested to include the following (not an > inclusive list) enumerations in an IODEF document: > CAPEC, CCE, CPE, CVE, CWE, IEC 19770-2. > > The IODEF Reference class is described in 3.9.1 of RFC 5070, where a > Reference must have a ReferenceName and zero or more of URL or > Description respectively. > > For each option described below, we can consider use of the IANA > registry. > The registry may be used to identify the identifier category and > potentially the appropriate identification format for that category. > > > Option 1: Simple ID > =================== > The first option would simply embed the relevant identifier in the > ReferenceName element of the Reference class. This may look like the > following: > > > id > http://www.example.com/path > http://www.otherexample.com/path > Description > > > Using this option, a variety of specific identifier formats could be > specified. CVE, for example, would start with "CVE-" and this > convention may be registered in an IANA table. > > No changes to IODEF are required for this option. > > > > Option 2: ID with coupled ID type > ================================= > The second option would prepend the identifier with it's type, which > may look something like the following. > > > id_type:id > http://www.example.com/path > http://www.otherexample.com/path > Description > > > Using this option, a variety of specific identifier types could be > specified, such that the identifier itself would not necessarily be > constrained, nor would new identifier formats necessarily need to be > specified in the future. An IANA table may be used for this solution > as well. > > No changes to IODEF would be required for this option. > > > > Option 3: ID with type expressed in Reference attribute > ======================================================= > The third option would require opening IODEF to update the Reference > class with an attribute, which may look something like the following. > > > id > http://www.example.com/path > http://www.otherexample.com/path > Description > > > > > Changes to IODEF are required for this option. > > > ---- > > I look forward to fielding responses to these options, including any > additional options you may see, but which are not listed. > > What is your solution preference? > > > Regards, > > Adam W. Montville | Security and Compliance Architect > > Direct: 503 276-7661 > Mobile: 360 471-7815 > > TRIPWIRE | Take CONTROL > http://www.tripwire.com > > > > > > > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From david.black@emc.com Mon Apr 9 15:02:48 2012 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 E25BE21F87FF for ; Mon, 9 Apr 2012 15:02:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.42 X-Spam-Level: X-Spam-Status: No, score=-109.42 tagged_above=-999 required=5 tests=[AWL=-0.487, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_FWDLOOK=1.666, 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 W-UzaAF8QaIQ for ; Mon, 9 Apr 2012 15:02:48 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 16FFC21F87F9 for ; Mon, 9 Apr 2012 15:02:47 -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 q39M2kaX001524 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Apr 2012 18:02:47 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.129]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Mon, 9 Apr 2012 18:02:25 -0400 Received: from mxhub31.corp.emc.com (mxhub31.corp.emc.com [128.222.70.171]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q39M2Ogw003607; Mon, 9 Apr 2012 18:02:25 -0400 Received: from mx15a.corp.emc.com ([169.254.1.107]) by mxhub31.corp.emc.com ([128.222.70.171]) with mapi; Mon, 9 Apr 2012 18:02:24 -0400 From: To: , Date: Mon, 9 Apr 2012 18:02:23 -0400 Thread-Topic: IODEF Reference Format for Enumerations Thread-Index: AQHNFn/rimqKx0bIq0Wznd3Jbi9osJaS2mYAgAAwdIA= Message-ID: <8D3D17ACE214DC429325B2B98F3AE71203412B@MX15A.corp.emc.com> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [mile] IODEF Reference Format for Enumerations 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, 09 Apr 2012 22:02:49 -0000 I agree with Dave on #2 - having a separate namespace above the identifier = avoids possible future problems with identifier collisions (e.g., if some future s= tandard of interest uses "CVE-" as the string prefix for something completely diffe= rent than the CVE we're currently familiar with). Thanks, --David > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of > Waltermire, David A. > Sent: Monday, April 09, 2012 5:53 PM > To: Adam Montville; mile@ietf.org > Subject: Re: [mile] IODEF Reference Format for Enumerations >=20 > My preference would be to use option #2. This approadch will essentially > provide a namespace for identifiers which conveys more semantics than a s= imple > string. Although maybe forward looking, this will be useful in cases whe= re > different identification schemes may have similar syntax but differ in > meaning. It is also useful to denote revisions for a given scheme where = there > may be partial overlap in instances. This approach provides greater over= all > flexibility without the need to revise IODEF. If IODEF is revised, we may= want > to consider option 3 to avoid a secondary parsing step to separate the > namespace from the value. >=20 > Sincerely, > Dave Waltermire >=20 > > -----Original Message----- > > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of > > Adam Montville > > Sent: Monday, April 09, 2012 2:38 PM > > To: mile@ietf.org > > Subject: [mile] IODEF Reference Format for Enumerations > > > > All: > > > > There is an identified need to specify a format to include relevant > > enumeration values in an IODEF document. The initial idea is to place > > enumeration values and their references in IODEF's Reference class. > > There are several ways to accomplish this goal. I'll do my best to > > enumerate some options here, then I hope to hear some feedback/opinions > > about the different approaches from the list. > > > > From the Structured Cybersecurity Information draft (draft-takahashi- > > mile-sci-02), we may be interested to include the following (not an > > inclusive list) enumerations in an IODEF document: > > CAPEC, CCE, CPE, CVE, CWE, IEC 19770-2. > > > > The IODEF Reference class is described in 3.9.1 of RFC 5070, where a > > Reference must have a ReferenceName and zero or more of URL or > > Description respectively. > > > > For each option described below, we can consider use of the IANA > > registry. > > The registry may be used to identify the identifier category and > > potentially the appropriate identification format for that category. > > > > > > Option 1: Simple ID > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > The first option would simply embed the relevant identifier in the > > ReferenceName element of the Reference class. This may look like the > > following: > > > > > > id > > http://www.example.com/path > > http://www.otherexample.com/path > > Description > > > > > > Using this option, a variety of specific identifier formats could be > > specified. CVE, for example, would start with "CVE-" and this > > convention may be registered in an IANA table. > > > > No changes to IODEF are required for this option. > > > > > > > > Option 2: ID with coupled ID type > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > The second option would prepend the identifier with it's type, which > > may look something like the following. > > > > > > id_type:id > > http://www.example.com/path > > http://www.otherexample.com/path > > Description > > > > > > Using this option, a variety of specific identifier types could be > > specified, such that the identifier itself would not necessarily be > > constrained, nor would new identifier formats necessarily need to be > > specified in the future. An IANA table may be used for this solution > > as well. > > > > No changes to IODEF would be required for this option. > > > > > > > > Option 3: ID with type expressed in Reference attribute > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > > The third option would require opening IODEF to update the Reference > > class with an attribute, which may look something like the following. > > > > > > id > > http://www.example.com/path > > http://www.otherexample.com/path > > Description > > > > > > > > > > Changes to IODEF are required for this option. > > > > > > ---- > > > > I look forward to fielding responses to these options, including any > > additional options you may see, but which are not listed. > > > > What is your solution preference? > > > > > > Regards, > > > > Adam W. Montville | Security and Compliance Architect > > > > Direct: 503 276-7661 > > Mobile: 360 471-7815 > > > > TRIPWIRE | Take CONTROL > > http://www.tripwire.com > > > > > > > > > > > > > > _______________________________________________ > > 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 Philippe.Lagadec@nc3a.nato.int Tue Apr 10 01:18:52 2012 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 CAEFA21F8782 for ; Tue, 10 Apr 2012 01:18:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.933 X-Spam-Level: X-Spam-Status: No, score=-4.933 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_FWDLOOK=1.666] 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 NCuSTOeGStD2 for ; Tue, 10 Apr 2012 01:18:51 -0700 (PDT) Received: from ironport01.nc3a.nato.int (ironport01.nc3a.nato.int [195.169.117.174]) by ietfa.amsl.com (Postfix) with ESMTP id 0811021F87CC for ; Tue, 10 Apr 2012 01:18:48 -0700 (PDT) From: Lagadec Philippe Received: from nunc3sv0100.nc3a.nato.int (HELO NUMIMESWEEPER.nu.nc3a) ([192.168.1.100]) by ironport01.nc3a.nato.int with ESMTP; 10 Apr 2012 10:14:11 +0200 Received: from NRNC3EX1002.NR.NC3A (unverified) by NUMIMESWEEPER.nu.nc3a (Clearswift SMTPRS 5.4.0) with ESMTP id for ; Tue, 10 Apr 2012 10:24:12 +0200 Received: from NRNC3EX1003.NR.NC3A ([fe80::50d2:d966:5c2f:ce3f]) by NRNC3EX1002.NR.NC3A ([fe80::cd04:b9ae:663:8f58%10]) with mapi id 14.01.0339.001; Tue, 10 Apr 2012 10:18:17 +0200 To: "mile@ietf.org" Thread-Topic: IODEF Reference Format for Enumerations Thread-Index: AQHNFn/rimqKx0bIq0Wznd3Jbi9osJaS2mYAgAAwdICAAKcikA== Date: Tue, 10 Apr 2012 08:18:16 +0000 Message-ID: References: <8D3D17ACE214DC429325B2B98F3AE71203412B@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE71203412B@MX15A.corp.emc.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.124.103] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mile] IODEF Reference Format for Enumerations 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, 10 Apr 2012 08:18:53 -0000 Hello, Personally I think option #3 looks cleaner for parsing and more in the spir= it of XML than option #2. It would also be compatible with option #1, for parsers which ignore the re= gistryId attribute. Of course, modifying IODEF would take more time. So maybe a solution could be to start with option #1, until IODEF is modifi= ed towards option #3? BTW is there a plan to modify IODEF in the future? There are quite a few other issues that would need to be fixed here and the= re. Philippe. -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of dav= id.black@emc.com Sent: 10 April 2012 00:02 To: david.waltermire@nist.gov; mile@ietf.org Subject: Re: [mile] IODEF Reference Format for Enumerations I agree with Dave on #2 - having a separate namespace above the identifier = avoids possible future problems with identifier collisions (e.g., if some f= uture standard of interest uses "CVE-" as the string prefix for something c= ompletely different than the CVE we're currently familiar with). Thanks, --David > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf=20 > Of Waltermire, David A. > Sent: Monday, April 09, 2012 5:53 PM > To: Adam Montville; mile@ietf.org > Subject: Re: [mile] IODEF Reference Format for Enumerations >=20 > My preference would be to use option #2. This approadch will=20 > essentially provide a namespace for identifiers which conveys more=20 > semantics than a simple string. Although maybe forward looking, this=20 > will be useful in cases where different identification schemes may=20 > have similar syntax but differ in meaning. It is also useful to=20 > denote revisions for a given scheme where there may be partial overlap=20 > in instances. This approach provides greater overall flexibility=20 > without the need to revise IODEF. If IODEF is revised, we may want to=20 > consider option 3 to avoid a secondary parsing step to separate the names= pace from the value. >=20 > Sincerely, > Dave Waltermire >=20 > > -----Original Message----- > > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf=20 > > Of Adam Montville > > Sent: Monday, April 09, 2012 2:38 PM > > To: mile@ietf.org > > Subject: [mile] IODEF Reference Format for Enumerations > > > > All: > > > > There is an identified need to specify a format to include relevant=20 > > enumeration values in an IODEF document. The initial idea is to=20 > > place enumeration values and their references in IODEF's Reference clas= s. > > There are several ways to accomplish this goal. I'll do my best to=20 > > enumerate some options here, then I hope to hear some=20 > > feedback/opinions about the different approaches from the list. > > > > From the Structured Cybersecurity Information draft=20 > > (draft-takahashi- mile-sci-02), we may be interested to include the=20 > > following (not an inclusive list) enumerations in an IODEF document: > > CAPEC, CCE, CPE, CVE, CWE, IEC 19770-2. > > > > The IODEF Reference class is described in 3.9.1 of RFC 5070, where a=20 > > Reference must have a ReferenceName and zero or more of URL or=20 > > Description respectively. > > > > For each option described below, we can consider use of the IANA=20 > > registry. > > The registry may be used to identify the identifier category and=20 > > potentially the appropriate identification format for that category. > > > > > > Option 1: Simple ID > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > The first option would simply embed the relevant identifier in the=20 > > ReferenceName element of the Reference class. This may look like=20 > > the > > following: > > > > > > id > > http://www.example.com/path > > http://www.otherexample.com/path > > Description > > > > > > Using this option, a variety of specific identifier formats could be=20 > > specified. CVE, for example, would start with "CVE-" and this=20 > > convention may be registered in an IANA table. > > > > No changes to IODEF are required for this option. > > > > > > > > Option 2: ID with coupled ID type > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > The second option would prepend the identifier with it's type, which=20 > > may look something like the following. > > > > > > id_type:id > > http://www.example.com/path > > http://www.otherexample.com/path > > Description > > > > > > Using this option, a variety of specific identifier types could be=20 > > specified, such that the identifier itself would not necessarily be=20 > > constrained, nor would new identifier formats necessarily need to be=20 > > specified in the future. An IANA table may be used for this=20 > > solution as well. > > > > No changes to IODEF would be required for this option. > > > > > > > > Option 3: ID with type expressed in Reference attribute=20 > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > > The third option would require opening IODEF to update the Reference=20 > > class with an attribute, which may look something like the following. > > > > > > id > > http://www.example.com/path > > http://www.otherexample.com/path > > Description > > > > > > > > > > Changes to IODEF are required for this option. > > > > > > ---- > > > > I look forward to fielding responses to these options, including any=20 > > additional options you may see, but which are not listed. > > > > What is your solution preference? > > > > > > Regards, > > > > Adam W. Montville | Security and Compliance Architect > > > > Direct: 503 276-7661 > > Mobile: 360 471-7815 > > > > TRIPWIRE | Take CONTROL > > http://www.tripwire.com > > > > > > > > > > > > > > _______________________________________________ > > 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 10 04:37:31 2012 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 5E07721F85CE for ; Tue, 10 Apr 2012 04:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.766 X-Spam-Level: X-Spam-Status: No, score=-9.766 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_FWDLOOK=1.666] 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 Mdya502zHnFx for ; Tue, 10 Apr 2012 04:37:30 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 8BAFD21F85B4 for ; Tue, 10 Apr 2012 04:37:29 -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 q3ABbRd5010593 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Apr 2012 07:37:28 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.145]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Tue, 10 Apr 2012 07:37:04 -0400 Received: from mxhub35.corp.emc.com (mxhub35.corp.emc.com [10.254.93.83]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q3ABb3mJ001758; Tue, 10 Apr 2012 07:37:04 -0400 Received: from mx06a.corp.emc.com ([169.254.1.106]) by mxhub35.corp.emc.com ([::1]) with mapi; Tue, 10 Apr 2012 07:37:03 -0400 From: To: , Date: Tue, 10 Apr 2012 07:37:02 -0400 Thread-Topic: IODEF Changes Thread-Index: AQHNFn/rimqKx0bIq0Wznd3Jbi9osJaS2mYAgAAwdICAAKcikIAAPBAQ Message-ID: References: <8D3D17ACE214DC429325B2B98F3AE71203412B@MX15A.corp.emc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: [mile] IODEF Changes 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, 10 Apr 2012 11:37:31 -0000 Hello Philippe, Thank you for chiming in on both accounts. We know there are issues with h= ow internationalization was specified in IODEF, so we may need to open it u= p to fix it. If there are other issues that should be resolved or updating= that needs to happen, helping to figure that out on list will drive a resu= lt from the working group. If you or others want to take on leading the di= scussion on possible updates and managing the document revision (editor), t= han we can start to look at an RFC5070-bis. These types of initiatives are = led by the working group members and volunteers, so help is appreciated! Thank you, Kathleen -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Lag= adec Philippe Sent: Tuesday, April 10, 2012 4:18 AM To: mile@ietf.org Subject: Re: [mile] IODEF Reference Format for Enumerations Hello, Personally I think option #3 looks cleaner for parsing and more in the spir= it of XML than option #2. It would also be compatible with option #1, for parsers which ignore the re= gistryId attribute. Of course, modifying IODEF would take more time. So maybe a solution could be to start with option #1, until IODEF is modifi= ed towards option #3? BTW is there a plan to modify IODEF in the future? There are quite a few other issues that would need to be fixed here and the= re. Philippe. -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of dav= id.black@emc.com Sent: 10 April 2012 00:02 To: david.waltermire@nist.gov; mile@ietf.org Subject: Re: [mile] IODEF Reference Format for Enumerations I agree with Dave on #2 - having a separate namespace above the identifier = avoids possible future problems with identifier collisions (e.g., if some f= uture standard of interest uses "CVE-" as the string prefix for something c= ompletely different than the CVE we're currently familiar with). Thanks, --David > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf=20 > Of Waltermire, David A. > Sent: Monday, April 09, 2012 5:53 PM > To: Adam Montville; mile@ietf.org > Subject: Re: [mile] IODEF Reference Format for Enumerations >=20 > My preference would be to use option #2. This approadch will=20 > essentially provide a namespace for identifiers which conveys more=20 > semantics than a simple string. Although maybe forward looking, this=20 > will be useful in cases where different identification schemes may=20 > have similar syntax but differ in meaning. It is also useful to=20 > denote revisions for a given scheme where there may be partial overlap=20 > in instances. This approach provides greater overall flexibility=20 > without the need to revise IODEF. If IODEF is revised, we may want to=20 > consider option 3 to avoid a secondary parsing step to separate the names= pace from the value. >=20 > Sincerely, > Dave Waltermire >=20 > > -----Original Message----- > > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf=20 > > Of Adam Montville > > Sent: Monday, April 09, 2012 2:38 PM > > To: mile@ietf.org > > Subject: [mile] IODEF Reference Format for Enumerations > > > > All: > > > > There is an identified need to specify a format to include relevant=20 > > enumeration values in an IODEF document. The initial idea is to=20 > > place enumeration values and their references in IODEF's Reference clas= s. > > There are several ways to accomplish this goal. I'll do my best to=20 > > enumerate some options here, then I hope to hear some=20 > > feedback/opinions about the different approaches from the list. > > > > From the Structured Cybersecurity Information draft=20 > > (draft-takahashi- mile-sci-02), we may be interested to include the=20 > > following (not an inclusive list) enumerations in an IODEF document: > > CAPEC, CCE, CPE, CVE, CWE, IEC 19770-2. > > > > The IODEF Reference class is described in 3.9.1 of RFC 5070, where a=20 > > Reference must have a ReferenceName and zero or more of URL or=20 > > Description respectively. > > > > For each option described below, we can consider use of the IANA=20 > > registry. > > The registry may be used to identify the identifier category and=20 > > potentially the appropriate identification format for that category. > > > > > > Option 1: Simple ID > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > The first option would simply embed the relevant identifier in the=20 > > ReferenceName element of the Reference class. This may look like=20 > > the > > following: > > > > > > id > > http://www.example.com/path > > http://www.otherexample.com/path > > Description > > > > > > Using this option, a variety of specific identifier formats could be=20 > > specified. CVE, for example, would start with "CVE-" and this=20 > > convention may be registered in an IANA table. > > > > No changes to IODEF are required for this option. > > > > > > > > Option 2: ID with coupled ID type > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > The second option would prepend the identifier with it's type, which=20 > > may look something like the following. > > > > > > id_type:id > > http://www.example.com/path > > http://www.otherexample.com/path > > Description > > > > > > Using this option, a variety of specific identifier types could be=20 > > specified, such that the identifier itself would not necessarily be=20 > > constrained, nor would new identifier formats necessarily need to be=20 > > specified in the future. An IANA table may be used for this=20 > > solution as well. > > > > No changes to IODEF would be required for this option. > > > > > > > > Option 3: ID with type expressed in Reference attribute=20 > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > > The third option would require opening IODEF to update the Reference=20 > > class with an attribute, which may look something like the following. > > > > > > id > > http://www.example.com/path > > http://www.otherexample.com/path > > Description > > > > > > > > > > Changes to IODEF are required for this option. > > > > > > ---- > > > > I look forward to fielding responses to these options, including any=20 > > additional options you may see, but which are not listed. > > > > What is your solution preference? > > > > > > Regards, > > > > Adam W. Montville | Security and Compliance Architect > > > > Direct: 503 276-7661 > > Mobile: 360 471-7815 > > > > TRIPWIRE | Take CONTROL > > http://www.tripwire.com > > > > > > > > > > > > > > _______________________________________________ > > 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 Richard.Struse@HQ.DHS.GOV Tue Apr 10 05:06:28 2012 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 B955221F85CE for ; Tue, 10 Apr 2012 05:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.933 X-Spam-Level: X-Spam-Status: No, score=-1.933 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_FWDLOOK=1.666] 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 0ahSmTmYDP+4 for ; Tue, 10 Apr 2012 05:06:27 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe001.messaging.microsoft.com [216.32.181.181]) by ietfa.amsl.com (Postfix) with ESMTP id A1A1E21F85CD for ; Tue, 10 Apr 2012 05:06:27 -0700 (PDT) Received: from mail149-ch1-R.bigfish.com (10.43.68.231) by CH1EHSOBE014.bigfish.com (10.43.70.64) with Microsoft SMTP Server id 14.1.225.23; Tue, 10 Apr 2012 12:06:25 +0000 Received: from mail149-ch1 (localhost [127.0.0.1]) by mail149-ch1-R.bigfish.com (Postfix) with ESMTP id 4A0EC1A0147 for ; Tue, 10 Apr 2012 12:06:25 +0000 (UTC) X-SpamScore: -35 X-BigFish: VPS-35(zz9371I1415J542M1432N4015Izz1202hzz1033IL8275bh8275dhz2dh2a8h668h839h944hd25h) X-Forefront-Antispam-Report: CIP:216.81.89.167; KIP:(null); UIP:(null); IPV:NLI; H:D1IBLPRHQ102.dhs.gov; RD:none; EFVD:NLI Received: from mail149-ch1 (localhost.localdomain [127.0.0.1]) by mail149-ch1 (MessageSwitch) id 1334059583617878_31952; Tue, 10 Apr 2012 12:06:23 +0000 (UTC) Received: from CH1EHSMHS012.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.229]) by mail149-ch1.bigfish.com (Postfix) with ESMTP id 8989C1400A4 for ; Tue, 10 Apr 2012 12:06:23 +0000 (UTC) Received: from D1IBLPRHQ102.dhs.gov (216.81.89.167) by CH1EHSMHS012.bigfish.com (10.43.70.12) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 10 Apr 2012 12:06:22 +0000 Received: from D1IBLPRHQ107.dhs.gov (192.168.49.137) by D1IBLPRHQ102.dhs.gov (10.84.128.101) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 10 Apr 2012 08:08:00 -0400 Received: from D1ABLPRHQ103.DSA.DHS (10.16.146.33) by D1IBLPRHQ107.dhs.gov (10.84.132.102) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 10 Apr 2012 08:10:37 -0400 Received: from ZAS1UG-0361.DHSNET.DS1.DHS (10.79.65.246) by D1ABLPRHQ103.DSA.DHS (10.16.146.33) with Microsoft SMTP Server id 14.1.355.2; Tue, 10 Apr 2012 08:06:00 -0400 Received: from ZAU1UG-0316.DHSNET.DS1.DHS ([10.79.65.218]) by ZAS1UG-0361.DHSNET.DS1.DHS with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 Apr 2012 08:06:00 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Apr 2012 08:05:59 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mile] IODEF Reference Format for Enumerations Thread-Index: AQHNFn/rimqKx0bIq0Wznd3Jbi9osJaS2mYAgAAwdICAAKcikIAARWOQ References: <8D3D17ACE214DC429325B2B98F3AE71203412B@MX15A.corp.emc.com> From: "Struse, Richard" To: X-OriginalArrivalTime: 10 Apr 2012 12:06:00.0015 (UTC) FILETIME=[4B154DF0:01CD1712] X-OriginatorOrg: hq.dhs.gov Subject: Re: [mile] IODEF Reference Format for Enumerations 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, 10 Apr 2012 12:06:28 -0000 I'd opt for #2 with a plan for getting to #3 during the next rev of IODEF. Rich -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Lagadec Philippe Sent: Tuesday, April 10, 2012 4:18 AM To: mile@ietf.org Subject: Re: [mile] IODEF Reference Format for Enumerations Hello, Personally I think option #3 looks cleaner for parsing and more in the spirit of XML than option #2. It would also be compatible with option #1, for parsers which ignore the registryId attribute. Of course, modifying IODEF would take more time. So maybe a solution could be to start with option #1, until IODEF is modified towards option #3? BTW is there a plan to modify IODEF in the future? There are quite a few other issues that would need to be fixed here and there. Philippe. -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of david.black@emc.com Sent: 10 April 2012 00:02 To: david.waltermire@nist.gov; mile@ietf.org Subject: Re: [mile] IODEF Reference Format for Enumerations I agree with Dave on #2 - having a separate namespace above the identifier avoids possible future problems with identifier collisions (e.g., if some future standard of interest uses "CVE-" as the string prefix for something completely different than the CVE we're currently familiar with). Thanks, --David > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf=20 > Of Waltermire, David A. > Sent: Monday, April 09, 2012 5:53 PM > To: Adam Montville; mile@ietf.org > Subject: Re: [mile] IODEF Reference Format for Enumerations >=20 > My preference would be to use option #2. This approadch will=20 > essentially provide a namespace for identifiers which conveys more=20 > semantics than a simple string. Although maybe forward looking, this=20 > will be useful in cases where different identification schemes may=20 > have similar syntax but differ in meaning. It is also useful to=20 > denote revisions for a given scheme where there may be partial overlap > in instances. This approach provides greater overall flexibility=20 > without the need to revise IODEF. If IODEF is revised, we may want to=20 > consider option 3 to avoid a secondary parsing step to separate the namespace from the value. >=20 > Sincerely, > Dave Waltermire >=20 > > -----Original Message----- > > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf > > Of Adam Montville > > Sent: Monday, April 09, 2012 2:38 PM > > To: mile@ietf.org > > Subject: [mile] IODEF Reference Format for Enumerations > > > > All: > > > > There is an identified need to specify a format to include relevant=20 > > enumeration values in an IODEF document. The initial idea is to=20 > > place enumeration values and their references in IODEF's Reference class. > > There are several ways to accomplish this goal. I'll do my best to=20 > > enumerate some options here, then I hope to hear some=20 > > feedback/opinions about the different approaches from the list. > > > > From the Structured Cybersecurity Information draft=20 > > (draft-takahashi- mile-sci-02), we may be interested to include the=20 > > following (not an inclusive list) enumerations in an IODEF document: > > CAPEC, CCE, CPE, CVE, CWE, IEC 19770-2. > > > > The IODEF Reference class is described in 3.9.1 of RFC 5070, where a > > Reference must have a ReferenceName and zero or more of URL or=20 > > Description respectively. > > > > For each option described below, we can consider use of the IANA=20 > > registry. > > The registry may be used to identify the identifier category and=20 > > potentially the appropriate identification format for that category. > > > > > > Option 1: Simple ID > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > The first option would simply embed the relevant identifier in the=20 > > ReferenceName element of the Reference class. This may look like=20 > > the > > following: > > > > > > id > > http://www.example.com/path > > http://www.otherexample.com/path > > Description > > > > > > Using this option, a variety of specific identifier formats could be > > specified. CVE, for example, would start with "CVE-" and this=20 > > convention may be registered in an IANA table. > > > > No changes to IODEF are required for this option. > > > > > > > > Option 2: ID with coupled ID type > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D > > The second option would prepend the identifier with it's type, which > > may look something like the following. > > > > > > id_type:id > > http://www.example.com/path > > http://www.otherexample.com/path > > Description > > > > > > Using this option, a variety of specific identifier types could be=20 > > specified, such that the identifier itself would not necessarily be=20 > > constrained, nor would new identifier formats necessarily need to be > > specified in the future. An IANA table may be used for this=20 > > solution as well. > > > > No changes to IODEF would be required for this option. > > > > > > > > Option 3: ID with type expressed in Reference attribute=20 > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > > The third option would require opening IODEF to update the Reference > > class with an attribute, which may look something like the following. > > > > > > id > > http://www.example.com/path > > http://www.otherexample.com/path > > Description > > > > > > > > > > Changes to IODEF are required for this option. > > > > > > ---- > > > > I look forward to fielding responses to these options, including any > > additional options you may see, but which are not listed. > > > > What is your solution preference? > > > > > > Regards, > > > > Adam W. Montville | Security and Compliance Architect > > > > Direct: 503 276-7661 > > Mobile: 360 471-7815 > > > > TRIPWIRE | Take CONTROL > > http://www.tripwire.com > > > > > > > > > > > > > > _______________________________________________ > > 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 bakerj@mitre.org Tue Apr 10 05:51:39 2012 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 700ED21F8474 for ; Tue, 10 Apr 2012 05:51:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.392 X-Spam-Level: X-Spam-Status: No, score=-5.392 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FBcXCtFdlISw for ; Tue, 10 Apr 2012 05:51:36 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 52AC221F8472 for ; Tue, 10 Apr 2012 05:51:36 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 2B6B221B1901 for ; Tue, 10 Apr 2012 08:51:35 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 153D221B1915 for ; Tue, 10 Apr 2012 08:51:35 -0400 (EDT) Received: from IMCMBX03.MITRE.ORG ([169.254.3.93]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.01.0339.001; Tue, 10 Apr 2012 08:51:34 -0400 From: "Baker, Jon" To: "mile@ietf.org" Thread-Topic: IODEF Reference Format for Enumerations Thread-Index: AQHNFn/rimqKx0bIq0Wznd3Jbi9osJaT+jLA Date: Tue, 10 Apr 2012 12:51:34 +0000 Message-ID: <6C1C15D8B5510B4B8FF132B10D38651374BDC5@IMCMBX03.MITRE.ORG> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.175.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mile] IODEF Reference Format for Enumerations 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, 10 Apr 2012 12:51:39 -0000 Based upon current IODEF structures, I would prefer option one. I would rat= her avoid adding additional syntax to the ReferenceName element as option t= wo suggests. If option one is selected and there are later changes to IODEF= we could migrate to option 3 fairly easily.=20 Jon =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Jonathan O. Baker G022 - IA Industry Collaboration The MITRE Corporation Email: bakerj@mitre.org >-----Original Message----- >From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of >Adam Montville >Sent: Monday, April 09, 2012 2:38 PM >To: mile@ietf.org >Subject: [mile] IODEF Reference Format for Enumerations > >All: > >There is an identified need to specify a format to include relevant >enumeration values in an IODEF document. The initial idea is to place >enumeration values and their references in IODEF's Reference class. There >are several ways to accomplish this goal. I'll do my best to enumerate >some options here, then I hope to hear some feedback/opinions about the >different approaches from the list. > >From the Structured Cybersecurity Information draft >(draft-takahashi-mile-sci-02), we may be interested to include the >following (not an inclusive list) enumerations in an IODEF document: >CAPEC, CCE, CPE, CVE, CWE, IEC 19770-2. > >The IODEF Reference class is described in 3.9.1 of RFC 5070, where a >Reference must have a ReferenceName and zero or more of URL or Description >respectively. > >For each option described below, we can consider use of the IANA registry. >The registry may be used to identify the identifier category and >potentially the appropriate identification format for that category. > > >Option 1: Simple ID >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >The first option would simply embed the relevant identifier in the >ReferenceName element of the Reference class. This may look like the >following: > > > id > http://www.example.com/path > http://www.otherexample.com/path > Description > > >Using this option, a variety of specific identifier formats could be >specified. CVE, for example, would start with "CVE-" and this convention >may be registered in an IANA table. > >No changes to IODEF are required for this option. > > > >Option 2: ID with coupled ID type >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D >The second option would prepend the identifier with it's type, which may >look something like the following. > > > id_type:id > http://www.example.com/path > http://www.otherexample.com/path > Description > > >Using this option, a variety of specific identifier types could be >specified, such that the identifier itself would not necessarily be >constrained, nor would new identifier formats necessarily need to be >specified in the future. An IANA table may be used for this solution as >well. > >No changes to IODEF would be required for this option. > > > >Option 3: ID with type expressed in Reference attribute >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D >The third option would require opening IODEF to update the Reference class >with an attribute, which may look something like the following. > > > id > http://www.example.com/path > http://www.otherexample.com/path > Description > > > > >Changes to IODEF are required for this option. > > >---- > >I look forward to fielding responses to these options, including any >additional options you may see, but which are not listed. > >What is your solution preference? > > >Regards, > >Adam W. Montville | Security and Compliance Architect > >Direct: 503 276-7661 >Mobile: 360 471-7815 > >TRIPWIRE | Take CONTROL >http://www.tripwire.com > > > > > > >_______________________________________________ >mile mailing list >mile@ietf.org >https://www.ietf.org/mailman/listinfo/mile From pkampana@cisco.com Tue Apr 10 06:40:34 2012 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 1B67E21F859B for ; Tue, 10 Apr 2012 06:40:34 -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 FKF5+S+ICEUZ for ; Tue, 10 Apr 2012 06:40:33 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id DB23C21F8582 for ; Tue, 10 Apr 2012 06:40:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkampana@cisco.com; l=4722; q=dns/txt; s=iport; t=1334065233; x=1335274833; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=wvykZtWXR0HI+nvCfp9BuK3jwGxUfijVXsUIRR52bsc=; b=jvDiXz+mU/6VPVInmKqvj51ATD3fL345BKyqbamKFOOwCAXQ7aDB9pcv SEJ1utKv0qL77Mbsl5h0iLLwE9h6u2btw5BEa1TWUn2i5zbcUB4Bkhrge UvKlazW6n1AvVv6B2OVcRWFKdtI4yhJxVRQocoa7wq5ZkIQUYhg0ZpsIe A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhUFAE43hE+tJXG//2dsb2JhbAA5BwOpWY9egQeCCQEBAQQBAQEFCgEVAhAbGRcBAwIJDwIEAQEoBxkOHwkIAgQTCxAHh2wLnkyYZ4sZgh+DKQSNb5M5gxGBaYMDgUA X-IronPort-AV: E=Sophos;i="4.75,399,1330905600"; d="scan'208";a="73470895" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-5.cisco.com with ESMTP; 10 Apr 2012 13:40:27 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id q3ADeRHV029539 for ; Tue, 10 Apr 2012 13:40:27 GMT Received: from xmb-rcd-107.cisco.com ([72.163.62.149]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 Apr 2012 08:40:26 -0500 Received: from WIN-ICH1QO6NCS6 ([64.102.220.197]) by xmb-rcd-107.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 Apr 2012 08:40:26 -0500 Received: from WINICH1QO6NCS6 by WIN-ICH1QO6NCS6 (PGP Universal service); Tue, 10 Apr 2012 09:39:38 -0500 X-PGP-Universal: processed; by WIN-ICH1QO6NCS6 on Tue, 10 Apr 2012 09:39:38 -0500 From: "Panos Kampanakis" To: References: <6C1C15D8B5510B4B8FF132B10D38651374BDC5@IMCMBX03.MITRE.ORG> In-Reply-To: <6C1C15D8B5510B4B8FF132B10D38651374BDC5@IMCMBX03.MITRE.ORG> Date: Tue, 10 Apr 2012 09:39:36 -0400 Organization: Cisco Systems Inc. Message-ID: <002501cd171f$5f0599c0$1d10cd40$@com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHNFn/rimqKx0bIq0Wznd3Jbi9osJaT+jLAgAAXNtA= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us X-OriginalArrivalTime: 10 Apr 2012 13:40:26.0620 (UTC) FILETIME=[7CA49BC0:01CD171F] Subject: Re: [mile] IODEF Reference Format for Enumerations 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, 10 Apr 2012 13:40:34 -0000 Agree. #1 until #3 is possible. Panos -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Baker, Jon Sent: Tuesday, April 10, 2012 8:52 AM To: mile@ietf.org Subject: Re: [mile] IODEF Reference Format for Enumerations Based upon current IODEF structures, I would prefer option one. I would rather avoid adding additional syntax to the ReferenceName element as option two suggests. If option one is selected and there are later changes to IODEF we could migrate to option 3 fairly easily. Jon ============================================ Jonathan O. Baker G022 - IA Industry Collaboration The MITRE Corporation Email: bakerj@mitre.org >-----Original Message----- >From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of >Adam Montville >Sent: Monday, April 09, 2012 2:38 PM >To: mile@ietf.org >Subject: [mile] IODEF Reference Format for Enumerations > >All: > >There is an identified need to specify a format to include relevant >enumeration values in an IODEF document. The initial idea is to place >enumeration values and their references in IODEF's Reference class. >There are several ways to accomplish this goal. I'll do my best to >enumerate some options here, then I hope to hear some feedback/opinions >about the different approaches from the list. > >From the Structured Cybersecurity Information draft >(draft-takahashi-mile-sci-02), we may be interested to include the >following (not an inclusive list) enumerations in an IODEF document: >CAPEC, CCE, CPE, CVE, CWE, IEC 19770-2. > >The IODEF Reference class is described in 3.9.1 of RFC 5070, where a >Reference must have a ReferenceName and zero or more of URL or >Description respectively. > >For each option described below, we can consider use of the IANA registry. >The registry may be used to identify the identifier category and >potentially the appropriate identification format for that category. > > >Option 1: Simple ID >=================== >The first option would simply embed the relevant identifier in the >ReferenceName element of the Reference class. This may look like the >following: > > > id > http://www.example.com/path > http://www.otherexample.com/path > Description > > >Using this option, a variety of specific identifier formats could be >specified. CVE, for example, would start with "CVE-" and this >convention may be registered in an IANA table. > >No changes to IODEF are required for this option. > > > >Option 2: ID with coupled ID type >================================= >The second option would prepend the identifier with it's type, which >may look something like the following. > > > id_type:id > http://www.example.com/path > http://www.otherexample.com/path > Description > > >Using this option, a variety of specific identifier types could be >specified, such that the identifier itself would not necessarily be >constrained, nor would new identifier formats necessarily need to be >specified in the future. An IANA table may be used for this solution >as well. > >No changes to IODEF would be required for this option. > > > >Option 3: ID with type expressed in Reference attribute >======================================================= >The third option would require opening IODEF to update the Reference >class with an attribute, which may look something like the following. > > > id > http://www.example.com/path > http://www.otherexample.com/path > Description > > > > >Changes to IODEF are required for this option. > > >---- > >I look forward to fielding responses to these options, including any >additional options you may see, but which are not listed. > >What is your solution preference? > > >Regards, > >Adam W. Montville | Security and Compliance Architect > >Direct: 503 276-7661 >Mobile: 360 471-7815 > >TRIPWIRE | Take CONTROL >http://www.tripwire.com > > > > > > >_______________________________________________ >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 Kent_Landfield@mcafee.com Tue Apr 10 10:17:19 2012 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 B80B721F867A for ; Tue, 10 Apr 2012 10:17:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.765 X-Spam-Level: X-Spam-Status: No, score=-5.765 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_FWDLOOK=1.666] 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 Evyul8SkFZNX for ; Tue, 10 Apr 2012 10:17:18 -0700 (PDT) Received: from dalsmrelay2.nai.com (dalsmrelay2.nai.com [205.227.136.216]) by ietfa.amsl.com (Postfix) with ESMTP id 3FF0711E80B8 for ; Tue, 10 Apr 2012 10:17:18 -0700 (PDT) Received: from DALEXHT2.corp.nai.org (unknown [10.64.5.52]) by dalsmrelay2.nai.com with smtp id 50ad_0429_9339be8d_4fa2_46ea_802b_9a6c0bbcf07b; Tue, 10 Apr 2012 12:17:07 -0500 Received: from AMERDALEXMB1.corp.nai.org ([fe80::b534:4a0d:1289:2d2d]) by DALEXHT2.corp.nai.org ([::1]) with mapi; Tue, 10 Apr 2012 12:15:54 -0500 From: To: , , Date: Tue, 10 Apr 2012 12:16:23 -0500 Thread-Topic: [mile] IODEF Reference Format for Enumerations Thread-Index: Ac0XPZW2FDRggL6jQy2RsM7puS3HkQ== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CBA8D31A30835kentlandfieldmcafeecom_" MIME-Version: 1.0 Subject: Re: [mile] IODEF Reference Format for Enumerations 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, 10 Apr 2012 17:17:19 -0000 --_000_CBA8D31A30835kentlandfieldmcafeecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I like option two as well for all the same reasons. Knowing what it is to = be applied to before makes it easier than having to parse the string itsel= f. Kent Landfield Director Content Strategy, Architecture and Standards McAfee | An Intel Company 5000 Headquarters Dr. Plano, Texas 75024 Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: David Waltermire > Date: Mon, 9 Apr 2012 16:53:11 -0500 To: Adam Montville = >, "mile@ietf.org" > Subject: Re: [mile] IODEF Reference Format for Enumerations My preference would be to use option #2. This approadch will essentially p= rovide a namespace for identifiers which conveys more semantics than a simp= le string. Although maybe forward looking, this will be useful in cases wh= ere different identification schemes may have similar syntax but differ in = meaning. It is also useful to denote revisions for a given scheme where th= ere may be partial overlap in instances. This approach provides greater ov= erall flexibility without the need to revise IODEF. If IODEF is revised, we= may want to consider option 3 to avoid a secondary parsing step to separat= e the namespace from the value. Sincerely, Dave Waltermire -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-boun= ces@ietf.org] On Behalf Of Adam Montville Sent: Monday, April 09, 2012 2:38 PM To: mile@ietf.org Subject: [mile] IODEF Reference Format for Enumerations All: There is an identified need to specify a format to include relevant enumeration values in an IODEF document. The initial idea is to place enumeration values and their references in IODEF's Reference class. There are several ways to accomplish this goal. I'll do my best to enumerate some options here, then I hope to hear some feedback/opinions about the different approaches from the list. >From the Structured Cybersecurity Information draft (draft-takahashi- mile-sci-02), we may be interested to include the following (not an inclusive list) enumerations in an IODEF document: CAPEC, CCE, CPE, CVE, CWE, IEC 19770-2. The IODEF Reference class is described in 3.9.1 of RFC 5070, where a Reference must have a ReferenceName and zero or more of URL or Description respectively. For each option described below, we can consider use of the IANA registry. The registry may be used to identify the identifier category and potentially the appropriate identification format for that category. Option 1: Simple ID =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The first option would simply embed the relevant identifier in the ReferenceName element of the Reference class. This may look like the following: id http://www.example.com/path http://www.otherexample.com/path Description Using this option, a variety of specific identifier formats could be specified. CVE, for example, would start with "CVE-" and this convention may be registered in an IANA table. No changes to IODEF are required for this option. Option 2: ID with coupled ID type =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D The second option would prepend the identifier with it's type, which may look something like the following. id_type:id http://www.example.com/path http://www.otherexample.com/path Description Using this option, a variety of specific identifier types could be specified, such that the identifier itself would not necessarily be constrained, nor would new identifier formats necessarily need to be specified in the future. An IANA table may be used for this solution as well. No changes to IODEF would be required for this option. Option 3: ID with type expressed in Reference attribute =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D The third option would require opening IODEF to update the Reference class with an attribute, which may look something like the following. id http://www.example.com/path http://www.otherexample.com/path Description Changes to IODEF are required for this option. ---- I look forward to fielding responses to these options, including any additional options you may see, but which are not listed. What is your solution preference? Regards, Adam W. Montville | Security and Compliance Architect Direct: 503 276-7661 Mobile: 360 471-7815 TRIPWIRE | Take CONTROL http://www.tripwire.com _______________________________________________ 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 --_000_CBA8D31A30835kentlandfieldmcafeecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I li= ke option two as well for all the same reasons.  Knowing what it is to= be applied to  before makes it easier than having to parse the string= itself. 


Kent Landfield<= /span>
= Director Content = Strategy, Architecture and Standards

McAfee | An Intel Company
5000 Headquarters Dr.
Plano, Texas 75024

Direct: +1.972.963.7096 
Mobile: +1.817.637.= 8026
Web:=  www.mcafee.com

From: David Waltermire <= david.waltermire@nist.gov&= gt;
Date: Mon, 9 Apr 2012 16:53= :11 -0500
To: Adam Montville &l= t;amontville@tripwire.com>= ;, "mile@ietf.org" <mile@ietf.org>
Subject: Re: [mile] IODEF Reference Format for Enumerations

=
My preference would be to use option #2.  This approadc= h will essentially provide a namespace for identifiers which conveys more s= emantics than a simple string.  Although maybe forward looking, t= his will be useful in cases where different identification schemes may have= similar syntax but differ in meaning.  It is also useful to deno= te revisions for a given scheme where there may be partial overlap in insta= nces.  This approach provides greater overall flexibility without= the need to revise IODEF. If IODEF is revised, we may want to consider opt= ion 3 to avoid a secondary parsing step to separate the namespace from the = value.

Sincerely,
Dave Waltermire
<= div>
-= ----Original Message-----
Adam Montville<= /div>
Sent: Monday, April 09, 2012 2:38 PM
Subject: [mile] IODEF Ref= erence Format for Enumerations
All:
There is an identified need to specify a format to include relevant<= /div>
enumeration values in an IODEF document.  The initial = idea is to place
enumeration values and their references in IODE= F's Reference class.
There are several ways to accomplish this g= oal.  I'll do my best to
enumerate some options here, = then I hope to hear some feedback/opinions
about the different a= pproaches from the list.
From the Structured Cyberse= curity Information draft (draft-takahashi-
mile-sci-02), we may = be interested to include the following (not an
inclusive list) e= numerations in an IODEF document:
CAPEC, CCE, CPE, CVE, CWE, IEC= 19770-2.
The IODEF Reference class is described in = 3.9.1 of RFC 5070, where a
Reference must have a ReferenceName a= nd zero or more of URL or
Description respectively.
<= /div>
For each option described below, we can consider use of the IANA=
registry.
The registry may be used to identify the i= dentifier category and
potentially the appropriate identificatio= n format for that category.
Option 1: Si= mple ID
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D
The first option would simply embed the relevant identifier = in the
ReferenceName element of the Reference class.  = This may look like the
following:
 &n= bsp;   <Reference>
     =     <ReferenceName>id</ReferenceName>
=          <URL>http://www.example.com/path</URL>= ;
     &nb= sp;   <Description>Description</Description>
     </Reference>
Using = this option, a variety of specific identifier formats could be
s= pecified.  CVE, for example, would start with "CVE-" and this
convention may be registered in an IANA table.
No changes to IODEF are required for this option.
=
Option 2: ID with coupled ID type
=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D
The second option would prepend the identi= fier with it's type, which
may look something like the following= .
     <Reference>
         <ReferenceName>id_= type:id</ReferenceName>
      = ;   <URL>http://www.example.com/path</URL>
   &= nbsp;     <URL>http://www.otherexample.com/path</URL>
         <Description>= Description</Description>
     </Ref= erence>
Using this option, a variety of specific = identifier types could be
specified, such that the identifier it= self would not necessarily be
constrained, nor would new identif= ier formats necessarily need to be
specified in the future. = ; An IANA table may be used for this solution
as well.
No changes to IODEF would be required for this option.
Option 3: ID with type expres= sed in Reference attribute
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
The third= option would require opening IODEF to update the Reference
clas= s with an attribute, which may look something like the following.
     <Reference registryId=3D"id_type"&= gt;
         <Referenc= eName>id</ReferenceName>
     &= nbsp;   <URL>http://www.example.com/path</URL>
  &nb= sp;      <URL>http://www.otherexample.com/path</URL>=
         <Description= >Description</Description>
     <= /Reference>
Changes to IO= DEF are required for this option.
----
I look forward to fielding responses to these options= , including any
additional options you may see, but which are no= t listed.
What is your solution preference?
Regards,
Adam W. Montvill= e | Security and Compliance Architect
Direct: 503 27= 6-7661
Mobile: 360 471-7815
TRIPWIRE | Ta= ke CONTROL
_______________________________________________
mile mailing list
______= _________________________________________
mile mailing list
=

--_000_CBA8D31A30835kentlandfieldmcafeecom_-- From internet-drafts@ietf.org Tue Apr 10 21:07:30 2012 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 275A221F865E; Tue, 10 Apr 2012 21:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.063, 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 iqD6HlgOq3lr; Tue, 10 Apr 2012 21:07:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FA2D21F8658; Tue, 10 Apr 2012 21:07:29 -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.00 Message-ID: <20120411040729.15326.84517.idtracker@ietfa.amsl.com> Date: Tue, 10 Apr 2012 21:07:29 -0700 Cc: mile@ietf.org Subject: [mile] I-D Action: draft-ietf-mile-sci-03.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: Wed, 11 Apr 2012 04:07:30 -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= Working Group of the IETF. Title : IODEF-extension to support structured cybersecurity info= rmation Author(s) : Takeshi Takahashi Kent Landfield Thomas Millar Youki Kadobayashi Filename : draft-ietf-mile-sci-03.txt Pages : 38 Date : 2012-04-10 This document extends the Incident Object Description Exchange Format (IODEF) defined in RFC 5070 [RFC5070] to facilitate enriched cybersecurity information exchange among cybersecurity entities by embedding structured information formatted by specifications, including CAPEC[TM] [CAPEC], CEE[TM] [CEE], CPE[TM] [CPE], CVE(R) [CVE], CVRF [CVRF], CVSS [CVSS], CWE[TM] [CWE], CWSS[TM] [CWSS], OCIL [OCIL], OVAL(R) [OVAL], and XCCDF [XCCDF]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mile-sci-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mile-sci-03.txt From takeshi_takahashi@nict.go.jp Tue Apr 10 21:19:27 2012 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 1719111E8096 for ; Tue, 10 Apr 2012 21:19:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.222 X-Spam-Level: X-Spam-Status: No, score=-0.222 tagged_above=-999 required=5 tests=[AWL=-0.533, BAYES_00=-2.599, HELO_EQ_JP=1.244, SARE_FWDLOOK=1.666] 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 Pp+0XfNrCFQO for ; Tue, 10 Apr 2012 21:19:26 -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 DADFA11E8079 for ; Tue, 10 Apr 2012 21:19:25 -0700 (PDT) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id q3B4JOoH023334; Wed, 11 Apr 2012 13:19:24 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id q3B4JOVF016101; Wed, 11 Apr 2012 13:19:24 +0900 (JST) Received: from mail3.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id q3B4JO6J016098; Wed, 11 Apr 2012 13:19:24 +0900 (JST) Received: from mail3.nict.go.jp (localhost [127.0.0.1]) by mail3.nict.go.jp (NICT Mail) with ESMTP id 037E9161D0; Wed, 11 Apr 2012 13:19:24 +0900 (JST) Received: from takeVAIO2 (unknown [133.243.119.6]) by mail3.nict.go.jp (NICT Mail) with ESMTP id E9D2116170; Wed, 11 Apr 2012 13:19:23 +0900 (JST) From: "Takeshi Takahashi" To: , , , References: In-Reply-To: Date: Wed, 11 Apr 2012 13:19:20 +0900 Message-ID: <001401cd179a$44a63c80$cdf2b580$@nict.go.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGwZSoksi5fvAD5Xdb/AUMScMcdjpbOY0HA Content-Language: ja Subject: Re: [mile] IODEF Reference Format for Enumerations 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, 11 Apr 2012 04:19:27 -0000 Hi Adam and all,=20 I also like option 2. By the way, I am a bit behind the conversation, so I would appreciate if = you could clarify the below question. I think we are defining the use of Reference class as a container for various identifiers (e.g. CVE-ID). Then, "are we thinking to adopt this use of the Reference class for the = SCI draft?" In my humble opinion, the current SCI draft has the same kind of = philosophy, with different structure. If we look at the Vulnerability class of the SCI draft, we have the structure like below. +------------------------+ | Vulnerability | +------------------------+ | ENUM SpecID |<>--(0..*)-[ RawData ] | STRING ext-SpecID |<>--(0..*)-[ Reference ] | STRING VulnerabilityID |<>--(0..*)-[ Platform ] | |<>--(0..*)-[ Scoring ] +------------------------+ SpecID corresponds to the id_type (of the option 2) while = VulnerabilityID corresponds to e.g., CVE-ID. By the way, the latest version of the SCI draft is available below. I've uploaded the SCI draft I've shared to the MILE mailing list on 21st March. http://www.ietf.org/internet-drafts/draft-ietf-mile-sci-03.txt Thank you. Take From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Kent_Landfield@McAfee.com Sent: Wednesday, April 11, 2012 2:16 AM To: david.waltermire@nist.gov; amontville@tripwire.com; mile@ietf.org Subject: Re: [mile] IODEF Reference Format for Enumerations I like option two as well for all the same reasons. =A0Knowing what it = is to be applied to =A0before makes it easier than having to parse the string itself.=A0 Kent Landfield Director Content Strategy, Architecture and Standards McAfee | An Intel Company 5000 Headquarters Dr. Plano, Texas 75024 Direct: +1.972.963.7096=A0 Mobile: +1.817.637.8026 Web:=A0www.mcafee.com From: David Waltermire Date: Mon, 9 Apr 2012 16:53:11 -0500 To: Adam Montville , "mile@ietf.org" Subject: Re: [mile] IODEF Reference Format for Enumerations My preference would be to use option #2.=A0=A0This approadch will = essentially provide a namespace for identifiers which conveys more semantics than a simple string.=A0=A0Although maybe forward looking, this will be useful = in cases where different identification schemes may have similar syntax but = differ in meaning.=A0=A0It is also useful to denote revisions for a given scheme = where there may be partial overlap in instances.=A0=A0This approach provides = greater overall flexibility without the need to revise IODEF. If IODEF is = revised, we may want to consider option 3 to avoid a secondary parsing step to separate the namespace from the value. Sincerely, Dave Waltermire -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Adam Montville Sent: Monday, April 09, 2012 2:38 PM To: mile@ietf.org Subject: [mile] IODEF Reference Format for Enumerations All: There is an identified need to specify a format to include relevant enumeration values in an IODEF document.=A0=A0The initial idea is to = place enumeration values and their references in IODEF's Reference class. There are several ways to accomplish this goal.=A0=A0I'll do my best to enumerate some options here, then I hope to hear some feedback/opinions about the different approaches from the list. >From the Structured Cybersecurity Information draft (draft-takahashi- mile-sci-02), we may be interested to include the following (not an inclusive list) enumerations in an IODEF document: CAPEC, CCE, CPE, CVE, CWE, IEC 19770-2. The IODEF Reference class is described in 3.9.1 of RFC 5070, where a Reference must have a ReferenceName and zero or more of URL or Description respectively. For each option described below, we can consider use of the IANA registry. The registry may be used to identify the identifier category and potentially the appropriate identification format for that category. Option 1: Simple ID =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The first option would simply embed the relevant identifier in the ReferenceName element of the Reference class.=A0=A0This may look like = the following: =A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0 id =A0=A0=A0=A0=A0=A0=A0=A0 http://www.example.com/path =A0=A0=A0=A0=A0=A0=A0=A0 http://www.otherexample.com/path =A0=A0=A0=A0=A0=A0=A0=A0 Description =A0=A0=A0=A0 Using this option, a variety of specific identifier formats could be specified.=A0=A0CVE, for example, would start with "CVE-" and this convention may be registered in an IANA table. No changes to IODEF are required for this option. Option 2: ID with coupled ID type =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D The second option would prepend the identifier with it's type, which may look something like the following. =A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0 id_type:id =A0=A0=A0=A0=A0=A0=A0=A0 http://www.example.com/path =A0=A0=A0=A0=A0=A0=A0=A0 http://www.otherexample.com/path =A0=A0=A0=A0=A0=A0=A0=A0 Description =A0=A0=A0=A0 Using this option, a variety of specific identifier types could be specified, such that the identifier itself would not necessarily be constrained, nor would new identifier formats necessarily need to be specified in the future.=A0=A0An IANA table may be used for this = solution as well. No changes to IODEF would be required for this option. Option 3: ID with type expressed in Reference attribute =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D The third option would require opening IODEF to update the Reference class with an attribute, which may look something like the following. =A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0 id =A0=A0=A0=A0=A0=A0=A0=A0 http://www.example.com/path =A0=A0=A0=A0=A0=A0=A0=A0 http://www.otherexample.com/path =A0=A0=A0=A0=A0=A0=A0=A0 Description =A0=A0=A0=A0 Changes to IODEF are required for this option. ---- I look forward to fielding responses to these options, including any additional options you may see, but which are not listed. What is your solution preference? Regards, Adam W. Montville | Security and Compliance Architect Direct: 503 276-7661 Mobile: 360 471-7815 TRIPWIRE | Take CONTROL http://www.tripwire.com _______________________________________________ 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 trammell@tik.ee.ethz.ch Wed Apr 11 02:29:22 2012 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 F046721F86F8 for ; Wed, 11 Apr 2012 02:29:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.537 X-Spam-Level: X-Spam-Status: No, score=-3.537 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, SARE_FWDLOOK=1.666] 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 NtgLBZZOvghI for ; Wed, 11 Apr 2012 02:29:21 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 2F49A21F86F2 for ; Wed, 11 Apr 2012 02:29:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 43020D930A; Wed, 11 Apr 2012 11:29:16 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id fwH5Jf5WOBoT; Wed, 11 Apr 2012 11:29:16 +0200 (MEST) Received: from [10.159.161.156] (unknown [213.55.184.207]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id C5701D9307; Wed, 11 Apr 2012 11:29:15 +0200 (MEST) References: <001401cd179a$44a63c80$cdf2b580$@nict.go.jp> In-Reply-To: <001401cd179a$44a63c80$cdf2b580$@nict.go.jp> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <0FBB3E6B-4E20-41F1-8E50-7C940FC30143@tik.ee.ethz.ch> X-Mailer: iPhone Mail (9B176) From: Brian Trammell Date: Wed, 11 Apr 2012 11:29:10 +0200 To: Takeshi Takahashi Cc: "" Subject: Re: [mile] IODEF Reference Format for Enumerations 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, 11 Apr 2012 09:29:22 -0000 Hi, Take, I've read this conversation to date as covering a different draft; incorpora= tion of content and reference to enumeration are different things with diffe= rent use cases. Best regards, Brian Sent from my iPhone On 11.04.2012, at 06:19, "Takeshi Takahashi" w= rote: > Hi Adam and all,=20 >=20 > I also like option 2. >=20 > By the way, I am a bit behind the conversation, so I would appreciate if y= ou > could clarify the below question. >=20 > I think we are defining the use of Reference class as a container for > various identifiers (e.g. CVE-ID). > Then, "are we thinking to adopt this use of the Reference class for the SC= I > draft?" >=20 > In my humble opinion, the current SCI draft has the same kind of philosoph= y, > with different structure. > If we look at the Vulnerability class of the SCI draft, we have the > structure like below. >=20 > +------------------------+ > | Vulnerability | > +------------------------+ > | ENUM SpecID |<>--(0..*)-[ RawData ] > | STRING ext-SpecID |<>--(0..*)-[ Reference ] > | STRING VulnerabilityID |<>--(0..*)-[ Platform ] > | |<>--(0..*)-[ Scoring ] > +------------------------+ >=20 > SpecID corresponds to the id_type (of the option 2) while VulnerabilityID > corresponds to e.g., CVE-ID. >=20 > By the way, the latest version of the SCI draft is available below. > I've uploaded the SCI draft I've shared to the MILE mailing list on 21st > March. >=20 > http://www.ietf.org/internet-drafts/draft-ietf-mile-sci-03.txt >=20 > Thank you. > Take >=20 >=20 >=20 >=20 >=20 > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of > Kent_Landfield@McAfee.com > Sent: Wednesday, April 11, 2012 2:16 AM > To: david.waltermire@nist.gov; amontville@tripwire.com; mile@ietf.org > Subject: Re: [mile] IODEF Reference Format for Enumerations >=20 > I like option two as well for all the same reasons. Knowing what it is to= > be applied to before makes it easier than having to parse the string > itself.=20 >=20 >=20 > Kent Landfield > Director Content Strategy, Architecture and Standards >=20 > McAfee | An Intel Company > 5000 Headquarters Dr. > Plano, Texas 75024 >=20 > Direct: +1.972.963.7096=20 > Mobile: +1.817.637.8026 > Web: www.mcafee.com >=20 > From: David Waltermire > Date: Mon, 9 Apr 2012 16:53:11 -0500 > To: Adam Montville , "mile@ietf.org" > > Subject: Re: [mile] IODEF Reference Format for Enumerations >=20 > My preference would be to use option #2. This approadch will essentially > provide a namespace for identifiers which conveys more semantics than a > simple string. Although maybe forward looking, this will be useful in cas= es > where different identification schemes may have similar syntax but differ i= n > meaning. It is also useful to denote revisions for a given scheme where > there may be partial overlap in instances. This approach provides greater= > overall flexibility without the need to revise IODEF. If IODEF is revised,= > we may want to consider option 3 to avoid a secondary parsing step to > separate the namespace from the value. >=20 > Sincerely, > Dave Waltermire >=20 > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of > Adam Montville > Sent: Monday, April 09, 2012 2:38 PM > To: mile@ietf.org > Subject: [mile] IODEF Reference Format for Enumerations > All: > There is an identified need to specify a format to include relevant > enumeration values in an IODEF document. The initial idea is to place > enumeration values and their references in IODEF's Reference class. > There are several ways to accomplish this goal. I'll do my best to > enumerate some options here, then I hope to hear some feedback/opinions > about the different approaches from the list. >> =46rom the Structured Cybersecurity Information draft (draft-takahashi- > mile-sci-02), we may be interested to include the following (not an > inclusive list) enumerations in an IODEF document: > CAPEC, CCE, CPE, CVE, CWE, IEC 19770-2. > The IODEF Reference class is described in 3.9.1 of RFC 5070, where a > Reference must have a ReferenceName and zero or more of URL or > Description respectively. > For each option described below, we can consider use of the IANA > registry. > The registry may be used to identify the identifier category and > potentially the appropriate identification format for that category. > Option 1: Simple ID > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > The first option would simply embed the relevant identifier in the > ReferenceName element of the Reference class. This may look like the > following: > > id > http://www.example.com/path > http://www.otherexample.com/path > Description > > Using this option, a variety of specific identifier formats could be > specified. CVE, for example, would start with "CVE-" and this > convention may be registered in an IANA table. > No changes to IODEF are required for this option. > Option 2: ID with coupled ID type > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D > The second option would prepend the identifier with it's type, which > may look something like the following. > > id_type:id > http://www.example.com/path > http://www.otherexample.com/path > Description > > Using this option, a variety of specific identifier types could be > specified, such that the identifier itself would not necessarily be > constrained, nor would new identifier formats necessarily need to be > specified in the future. An IANA table may be used for this solution > as well. > No changes to IODEF would be required for this option. > Option 3: ID with type expressed in Reference attribute > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > The third option would require opening IODEF to update the Reference > class with an attribute, which may look something like the following. > > id > http://www.example.com/path > http://www.otherexample.com/path > Description > > Changes to IODEF are required for this option. > ---- > I look forward to fielding responses to these options, including any > additional options you may see, but which are not listed. > What is your solution preference? > Regards, > Adam W. Montville | Security and Compliance Architect > Direct: 503 276-7661 > Mobile: 360 471-7815 > TRIPWIRE | Take CONTROL > http://www.tripwire.com > _______________________________________________ > 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 > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From takeshi_takahashi@nict.go.jp Wed Apr 11 05:04:40 2012 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 C480721F8531 for ; Wed, 11 Apr 2012 05:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.044 X-Spam-Level: X-Spam-Status: No, score=0.044 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599, HELO_EQ_JP=1.244, SARE_FWDLOOK=1.666] 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 tIQfx7uKqmdf for ; Wed, 11 Apr 2012 05:04:40 -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 AD5D621F84A6 for ; Wed, 11 Apr 2012 05:04:39 -0700 (PDT) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id q3BC4cMm027524; Wed, 11 Apr 2012 21:04:38 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id q3BC4cY1009979; Wed, 11 Apr 2012 21:04:38 +0900 (JST) Received: from takeVAIO2 (ssh.nict.go.jp [133.243.3.49]) by gw1.nict.go.jp with ESMTP id q3BC4bps009956; Wed, 11 Apr 2012 21:04:37 +0900 (JST) From: "Takeshi Takahashi" To: "'Brian Trammell'" References: <001401cd179a$44a63c80$cdf2b580$@nict.go.jp> <0FBB3E6B-4E20-41F1-8E50-7C940FC30143@tik.ee.ethz.ch> In-Reply-To: <0FBB3E6B-4E20-41F1-8E50-7C940FC30143@tik.ee.ethz.ch> Date: Wed, 11 Apr 2012 21:04:33 +0900 Message-ID: <017e01cd17db$42bcab70$c8360250$@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: AQEEywXEBq+AvzPkvb7OEoQJUz7ZNgGwZSokAY1JwRwBvhfgz5f+QhoA Content-Language: ja Cc: mile@ietf.org Subject: Re: [mile] IODEF Reference Format for Enumerations 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, 11 Apr 2012 12:04:40 -0000 Hi Brian, Thank you very much for the clarification :) Best Regards, Take > -----Original Message----- > From: Brian Trammell [mailto:trammell@tik.ee.ethz.ch] > Sent: Wednesday, April 11, 2012 6:29 PM > To: Takeshi Takahashi > Cc: ; ; > ; > Subject: Re: [mile] IODEF Reference Format for Enumerations > > Hi, Take, > > I've read this conversation to date as covering a different draft; > incorporation of content and reference to enumeration are different > things with different use cases. > > Best regards, > > Brian > > Sent from my iPhone > > On 11.04.2012, at 06:19, "Takeshi Takahashi" > wrote: > > > Hi Adam and all, > > > > I also like option 2. > > > > By the way, I am a bit behind the conversation, so I would appreciate > > if you could clarify the below question. > > > > I think we are defining the use of Reference class as a container for > > various identifiers (e.g. CVE-ID). > > Then, "are we thinking to adopt this use of the Reference class for > > the SCI draft?" > > > > In my humble opinion, the current SCI draft has the same kind of > > philosophy, with different structure. > > If we look at the Vulnerability class of the SCI draft, we have the > > structure like below. > > > > +------------------------+ > > | Vulnerability | > > +------------------------+ > > | ENUM SpecID |<>--(0..*)-[ RawData ] > > | STRING ext-SpecID |<>--(0..*)-[ Reference ] > > | STRING VulnerabilityID |<>--(0..*)-[ Platform ] > > | |<>--(0..*)-[ Scoring ] > > +------------------------+ > > > > SpecID corresponds to the id_type (of the option 2) while > > VulnerabilityID corresponds to e.g., CVE-ID. > > > > By the way, the latest version of the SCI draft is available below. > > I've uploaded the SCI draft I've shared to the MILE mailing list on > > 21st March. > > > > http://www.ietf.org/internet-drafts/draft-ietf-mile-sci-03.txt > > > > Thank you. > > Take > > > > > > > > > > > > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf > > Of Kent_Landfield@McAfee.com > > Sent: Wednesday, April 11, 2012 2:16 AM > > To: david.waltermire@nist.gov; amontville@tripwire.com; > mile@ietf.org > > Subject: Re: [mile] IODEF Reference Format for Enumerations > > > > I like option two as well for all the same reasons. Knowing what it > > is to be applied to before makes it easier than having to parse the > > string itself. > > > > > > Kent Landfield > > Director Content Strategy, Architecture and Standards > > > > McAfee | An Intel Company > > 5000 Headquarters Dr. > > Plano, Texas 75024 > > > > Direct: +1.972.963.7096 > > Mobile: +1.817.637.8026 > > Web: www.mcafee.com > > > > From: David Waltermire > > Date: Mon, 9 Apr 2012 16:53:11 -0500 > > To: Adam Montville , "mile@ietf.org" > > > > Subject: Re: [mile] IODEF Reference Format for Enumerations > > > > My preference would be to use option #2. This approadch will > > essentially provide a namespace for identifiers which conveys more > > semantics than a simple string. Although maybe forward looking, this > > will be useful in cases where different identification schemes may > > have similar syntax but differ in meaning. It is also useful to > > denote revisions for a given scheme where there may be partial overlap > > in instances. This approach provides greater overall flexibility > > without the need to revise IODEF. If IODEF is revised, we may want to > > consider option 3 to avoid a secondary parsing step to separate the > namespace from the value. > > > > Sincerely, > > Dave Waltermire > > > > -----Original Message----- > > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf > > Of Adam Montville > > Sent: Monday, April 09, 2012 2:38 PM > > To: mile@ietf.org > > Subject: [mile] IODEF Reference Format for Enumerations > > All: > > There is an identified need to specify a format to include relevant > > enumeration values in an IODEF document. The initial idea is to place > > enumeration values and their references in IODEF's Reference class. > > There are several ways to accomplish this goal. I'll do my best to > > enumerate some options here, then I hope to hear some > > feedback/opinions about the different approaches from the list. > >> From the Structured Cybersecurity Information draft (draft-takahashi- > > mile-sci-02), we may be interested to include the following (not an > > inclusive list) enumerations in an IODEF document: > > CAPEC, CCE, CPE, CVE, CWE, IEC 19770-2. > > The IODEF Reference class is described in 3.9.1 of RFC 5070, where a > > Reference must have a ReferenceName and zero or more of URL or > > Description respectively. > > For each option described below, we can consider use of the IANA > > registry. > > The registry may be used to identify the identifier category and > > potentially the appropriate identification format for that category. > > Option 1: Simple ID > > =================== > > The first option would simply embed the relevant identifier in the > > ReferenceName element of the Reference class. This may look like the > > following: > > > > id > > http://www.example.com/path > > http://www.otherexample.com/path > > Description > > > > Using this option, a variety of specific identifier formats could be > > specified. CVE, for example, would start with "CVE-" and this > > convention may be registered in an IANA table. > > No changes to IODEF are required for this option. > > Option 2: ID with coupled ID type > > ================================= > > The second option would prepend the identifier with it's type, which > > may look something like the following. > > > > id_type:id > > http://www.example.com/path > > http://www.otherexample.com/path > > Description > > > > Using this option, a variety of specific identifier types could be > > specified, such that the identifier itself would not necessarily be > > constrained, nor would new identifier formats necessarily need to be > > specified in the future. An IANA table may be used for this solution > > as well. > > No changes to IODEF would be required for this option. > > Option 3: ID with type expressed in Reference attribute > > ======================================================= > > The third option would require opening IODEF to update the Reference > > class with an attribute, which may look something like the following. > > > > id > > http://www.example.com/path > > http://www.otherexample.com/path > > Description > > > > Changes to IODEF are required for this option. > > ---- > > I look forward to fielding responses to these options, including any > > additional options you may see, but which are not listed. > > What is your solution preference? > > Regards, > > Adam W. Montville | Security and Compliance Architect > > Direct: 503 276-7661 > > Mobile: 360 471-7815 > > TRIPWIRE | Take CONTROL > > http://www.tripwire.com > > _______________________________________________ > > 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 david.black@emc.com Wed Apr 11 16:39:26 2012 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 07F5A21F854B for ; Wed, 11 Apr 2012 16:39:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.367 X-Spam-Level: X-Spam-Status: No, score=-110.367 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 FkhvuhS7Z4O3 for ; Wed, 11 Apr 2012 16:39:24 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id B3D1F21F853A for ; Wed, 11 Apr 2012 16:39:21 -0700 (PDT) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q3BNdGUw026418 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Apr 2012 19:39:19 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.130]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Wed, 11 Apr 2012 19:39:10 -0400 Received: from mxhub36.corp.emc.com (mxhub36.corp.emc.com [10.254.93.84]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q3BNd9hc032121; Wed, 11 Apr 2012 19:39:09 -0400 Received: from mx15a.corp.emc.com ([169.254.1.107]) by mxhub36.corp.emc.com ([::1]) with mapi; Wed, 11 Apr 2012 19:39:09 -0400 From: To: , Date: Wed, 11 Apr 2012 19:39:07 -0400 Thread-Topic: IODEF Reference Format for Enumerations Thread-Index: AQHNFn/rimqKx0bIq0Wznd3Jbi9osJaWP6vw Message-ID: <8D3D17ACE214DC429325B2B98F3AE7120535ED@MX15A.corp.emc.com> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [mile] IODEF Reference Format for Enumerations 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, 11 Apr 2012 23:39:26 -0000 Adam, I have a couple more comments. [1] 19770-2 > From the Structured Cybersecurity Information draft > (draft-takahashi-mile-sci-02), we may be interested to include the > following (not an inclusive list) enumerations in an IODEF document: > CAPEC, CCE, CPE, CVE, CWE, IEC 19770-2. I don't think 19770-2 belongs on the list of possible references. A 19770-2 software tag appears to be XML, and hence belongs only in the SCI draft. Here's the XML schema for 19770-2 tags: http://standards.iso.org/iso/19770/-2/2009/schema.xsd FWIW, the current version of the SCI draft is draft-ietf-mile-sci-03, and it no longer includes 19770-2. [2] ReferenceName string format Beyond 19770-2, the other five specifications were all developed by Mitre, who carefully ensured that each of them uses a different initial portion of their enumeration strings. That approach is likely to be problematic for an IETF standard that will need to accommodate multiple other independently developed enumeration specifications. While IANA can perform the corresponding function for IETF via a registry, there's a problem. In contrast to Mitre, one can't realistically expect developers of enumeration specifications to approach IANA in advance to obtain a string prefix, and that's especially true for existing specifications ;-). So, option 1 appears problematic if the specification and its reference syntax have to be inferred from the identifier format in a fashion that is not guaranteed to prevent collisions among different specifications: > Using this option, a variety of specific identifier formats could be > specified. CVE, for example, would start with "CVE-" and this convention > may be registered in an IANA table. To take a simple example, suppose two different enumeration specifications just use numbers for their enumerations, starting from 1. When "42" shows up as the ReferenceName, what does that refer to (aside from the answer to life, the universe and everything)? There should be a deterministic way to figure out which specification (and hence which format) to use to interpret ReferenceName - for option 1 this could be done by requiring that the first URL be a "Reference URI" from the IANA registry established by the SCI draft. This also deals with potential enumeration specifications that don't use a constant initial portion of their reference strings. While this approach could also be used for options 2 and 3, they both have an explicit ID that addresses this problem. For these two options, it seem= s like a good idea to use a single specification registry for both references and XML inclusion, and hence I'd suggest adding this ID as a registered element to the IANA registry created by the SCI draft if option 2 or 3 is chosen. Bottom line: If option 1 is chosen, the first URL in the Reference MUST be the Reference URI for the IANA-registered specification. An interesting observation is that if option 1 is chosen, the result is a common means of referencing specifications between the SCI draft and the new draft on use of the IODEF reference format. Thanks, --David > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of A= dam > Montville > Sent: Monday, April 09, 2012 2:38 PM > To: mile@ietf.org > Subject: [mile] IODEF Reference Format for Enumerations >=20 > All: >=20 > There is an identified need to specify a format to include relevant > enumeration values in an IODEF document. The initial idea is to place > enumeration values and their references in IODEF's Reference class. Ther= e > are several ways to accomplish this goal. I'll do my best to enumerate > some options here, then I hope to hear some feedback/opinions about the > different approaches from the list. >=20 > From the Structured Cybersecurity Information draft > (draft-takahashi-mile-sci-02), we may be interested to include the > following (not an inclusive list) enumerations in an IODEF document: > CAPEC, CCE, CPE, CVE, CWE, IEC 19770-2. >=20 > The IODEF Reference class is described in 3.9.1 of RFC 5070, where a > Reference must have a ReferenceName and zero or more of URL or Descriptio= n > respectively. >=20 > For each option described below, we can consider use of the IANA registry= . > The registry may be used to identify the identifier category and > potentially the appropriate identification format for that category. >=20 >=20 > Option 1: Simple ID > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > The first option would simply embed the relevant identifier in the > ReferenceName element of the Reference class. This may look like the > following: >=20 > > id > http://www.example.com/path > http://www.otherexample.com/path > Description > >=20 > Using this option, a variety of specific identifier formats could be > specified. CVE, for example, would start with "CVE-" and this convention > may be registered in an IANA table. >=20 > No changes to IODEF are required for this option. >=20 >=20 >=20 > Option 2: ID with coupled ID type > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > The second option would prepend the identifier with it's type, which may > look something like the following. >=20 > > id_type:id > http://www.example.com/path > http://www.otherexample.com/path > Description > >=20 > Using this option, a variety of specific identifier types could be > specified, such that the identifier itself would not necessarily be > constrained, nor would new identifier formats necessarily need to be > specified in the future. An IANA table may be used for this solution as > well. >=20 > No changes to IODEF would be required for this option. >=20 >=20 >=20 > Option 3: ID with type expressed in Reference attribute > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > The third option would require opening IODEF to update the Reference clas= s > with an attribute, which may look something like the following. >=20 > > id > http://www.example.com/path > http://www.otherexample.com/path > Description > >=20 >=20 >=20 > Changes to IODEF are required for this option. >=20 >=20 > ---- >=20 > I look forward to fielding responses to these options, including any > additional options you may see, but which are not listed. >=20 > What is your solution preference? >=20 >=20 > Regards, >=20 > Adam W. Montville | Security and Compliance Architect >=20 > Direct: 503 276-7661 > Mobile: 360 471-7815 >=20 > TRIPWIRE | Take CONTROL > http://www.tripwire.com >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From amontville@tripwire.com Thu Apr 12 11:24:16 2012 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 181E221F84FB for ; Thu, 12 Apr 2012 11:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 ImGdfsF48gSR for ; Thu, 12 Apr 2012 11:24:14 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe006.messaging.microsoft.com [213.199.154.144]) by ietfa.amsl.com (Postfix) with ESMTP id 7E48021F84F3 for ; Thu, 12 Apr 2012 11:24:13 -0700 (PDT) Received: from mail46-db3-R.bigfish.com (10.3.81.250) by DB3EHSOBE003.bigfish.com (10.3.84.23) with Microsoft SMTP Server id 14.1.225.23; Thu, 12 Apr 2012 18:24:12 +0000 Received: from mail46-db3 (localhost [127.0.0.1]) by mail46-db3-R.bigfish.com (Postfix) with ESMTP id 76584480503 for ; Thu, 12 Apr 2012 18:24:12 +0000 (UTC) X-SpamScore: -39 X-BigFish: VPS-39(zzbb2dI9371I1415J542M1432N98dK4015Izz1202hzz1033IL8275bh8275dhz2dh2a8h668h839h944h) X-Forefront-Antispam-Report: CIP:174.47.84.216; KIP:(null); UIP:(null); IPV:NLI; H:PDXHB01.tripwire.com; RD:174-47-84-216.static.twtelecom.net; EFVD:NLI Received: from mail46-db3 (localhost.localdomain [127.0.0.1]) by mail46-db3 (MessageSwitch) id 1334255050532175_26752; Thu, 12 Apr 2012 18:24:10 +0000 (UTC) Received: from DB3EHSMHS008.bigfish.com (unknown [10.3.81.234]) by mail46-db3.bigfish.com (Postfix) with ESMTP id 7D0B3140095; Thu, 12 Apr 2012 18:24:10 +0000 (UTC) Received: from PDXHB01.tripwire.com (174.47.84.216) by DB3EHSMHS008.bigfish.com (10.3.87.108) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 12 Apr 2012 18:24:08 +0000 Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 12 Apr 2012 11:33:39 -0700 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0355.002; Thu, 12 Apr 2012 11:24:06 -0700 From: Adam Montville To: "david.black@emc.com" , "mile@ietf.org" Thread-Topic: IODEF Reference Format for Enumerations Thread-Index: AQHNFn/rimqKx0bIq0Wznd3Jbi9osJaWP6vwgAFGNgA= Date: Thu, 12 Apr 2012 18:24:05 +0000 Message-ID: In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE7120535ED@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [172.30.0.234] x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: tripwire.com Subject: Re: [mile] IODEF Reference Format for Enumerations 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, 12 Apr 2012 18:24:16 -0000 This is good information, David, thank you. I'll be sending another note to the list in a few minutes assessing where we are, and I'll include this advice therein. Adam On 4/11/12 4:39 PM, "david.black@emc.com" wrote: >Adam, > >I have a couple more comments. > >[1] 19770-2 > >> From the Structured Cybersecurity Information draft >> (draft-takahashi-mile-sci-02), we may be interested to include the >> following (not an inclusive list) enumerations in an IODEF document: >> CAPEC, CCE, CPE, CVE, CWE, IEC 19770-2. > >I don't think 19770-2 belongs on the list of possible references. >A 19770-2 software tag appears to be XML, and hence belongs only in >the SCI draft. Here's the XML schema for 19770-2 tags: > > http://standards.iso.org/iso/19770/-2/2009/schema.xsd > >FWIW, the current version of the SCI draft is draft-ietf-mile-sci-03, >and it no longer includes 19770-2. > >[2] ReferenceName string format > >Beyond 19770-2, the other five specifications were all developed by Mitre, >who carefully ensured that each of them uses a different initial portion >of their enumeration strings. That approach is likely to be problematic >for an IETF standard that will need to accommodate multiple other >independently developed enumeration specifications. While IANA can >perform >the corresponding function for IETF via a registry, there's a problem. >In contrast to Mitre, one can't realistically expect developers of >enumeration specifications to approach IANA in advance to obtain a string >prefix, and that's especially true for existing specifications ;-). > >So, option 1 appears problematic if the specification and its reference >syntax have to be inferred from the identifier format in a fashion that is >not guaranteed to prevent collisions among different specifications: > >> Using this option, a variety of specific identifier formats could be >> specified. CVE, for example, would start with "CVE-" and this >>convention >> may be registered in an IANA table. > >To take a simple example, suppose two different enumeration specifications >just use numbers for their enumerations, starting from 1. When "42" shows >up as the ReferenceName, what does that refer to (aside from the answer to >life, the universe and everything)? > >There should be a deterministic way to figure out which specification (and >hence which format) to use to interpret ReferenceName - for option 1 this >could be done by requiring that the first URL be a "Reference URI" from >the >IANA registry established by the SCI draft. > >This also deals with potential enumeration specifications that don't use >a constant initial portion of their reference strings. > >While this approach could also be used for options 2 and 3, they both have >an explicit ID that addresses this problem. For these two options, it >seems >like a good idea to use a single specification registry for both >references >and XML inclusion, and hence I'd suggest adding this ID as a registered >element to the IANA registry created by the SCI draft if option 2 or 3 is >chosen. > >Bottom line: If option 1 is chosen, the first URL in the Reference MUST be >the Reference URI for the IANA-registered specification. > >An interesting observation is that if option 1 is chosen, the result is >a common means of referencing specifications between the SCI draft and the >new draft on use of the IODEF reference format. > >Thanks, >--David > >> -----Original Message----- >> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of >>Adam >> Montville >> Sent: Monday, April 09, 2012 2:38 PM >> To: mile@ietf.org >> Subject: [mile] IODEF Reference Format for Enumerations >>=20 >> All: >>=20 >> There is an identified need to specify a format to include relevant >> enumeration values in an IODEF document. The initial idea is to place >> enumeration values and their references in IODEF's Reference class. >>There >> are several ways to accomplish this goal. I'll do my best to enumerate >> some options here, then I hope to hear some feedback/opinions about the >> different approaches from the list. >>=20 >> From the Structured Cybersecurity Information draft >> (draft-takahashi-mile-sci-02), we may be interested to include the >> following (not an inclusive list) enumerations in an IODEF document: >> CAPEC, CCE, CPE, CVE, CWE, IEC 19770-2. >>=20 >> The IODEF Reference class is described in 3.9.1 of RFC 5070, where a >> Reference must have a ReferenceName and zero or more of URL or >>Description >> respectively. >>=20 >> For each option described below, we can consider use of the IANA >>registry. >> The registry may be used to identify the identifier category and >> potentially the appropriate identification format for that category. >>=20 >>=20 >> Option 1: Simple ID >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> The first option would simply embed the relevant identifier in the >> ReferenceName element of the Reference class. This may look like the >> following: >>=20 >> >> id >> http://www.example.com/path >> http://www.otherexample.com/path >> Description >> >>=20 >> Using this option, a variety of specific identifier formats could be >> specified. CVE, for example, would start with "CVE-" and this >>convention >> may be registered in an IANA table. >>=20 >> No changes to IODEF are required for this option. >>=20 >>=20 >>=20 >> Option 2: ID with coupled ID type >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D >> The second option would prepend the identifier with it's type, which may >> look something like the following. >>=20 >> >> id_type:id >> http://www.example.com/path >> http://www.otherexample.com/path >> Description >> >>=20 >> Using this option, a variety of specific identifier types could be >> specified, such that the identifier itself would not necessarily be >> constrained, nor would new identifier formats necessarily need to be >> specified in the future. An IANA table may be used for this solution as >> well. >>=20 >> No changes to IODEF would be required for this option. >>=20 >>=20 >>=20 >> Option 3: ID with type expressed in Reference attribute >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D >> The third option would require opening IODEF to update the Reference >>class >> with an attribute, which may look something like the following. >>=20 >> >> id >> http://www.example.com/path >> http://www.otherexample.com/path >> Description >> >>=20 >>=20 >>=20 >> Changes to IODEF are required for this option. >>=20 >>=20 >> ---- >>=20 >> I look forward to fielding responses to these options, including any >> additional options you may see, but which are not listed. >>=20 >> What is your solution preference? >>=20 >>=20 >> Regards, >>=20 >> Adam W. Montville | Security and Compliance Architect >>=20 >> Direct: 503 276-7661 >> Mobile: 360 471-7815 >>=20 >> TRIPWIRE | Take CONTROL >> http://www.tripwire.com >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> mile mailing list >> mile@ietf.org >> https://www.ietf.org/mailman/listinfo/mile > > From amontville@tripwire.com Thu Apr 12 11:28:31 2012 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 16AEE21F85A2 for ; Thu, 12 Apr 2012 11:28:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 Qw8vXmfPKwEU for ; Thu, 12 Apr 2012 11:28:30 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe001.messaging.microsoft.com [216.32.181.181]) by ietfa.amsl.com (Postfix) with ESMTP id E301B21F84DA for ; Thu, 12 Apr 2012 11:28:29 -0700 (PDT) Received: from mail129-ch1-R.bigfish.com (10.43.68.241) by CH1EHSOBE015.bigfish.com (10.43.70.65) with Microsoft SMTP Server id 14.1.225.23; Thu, 12 Apr 2012 18:28:29 +0000 Received: from mail129-ch1 (localhost [127.0.0.1]) by mail129-ch1-R.bigfish.com (Postfix) with ESMTP id 454054E02E7 for ; Thu, 12 Apr 2012 18:28:29 +0000 (UTC) X-SpamScore: -38 X-BigFish: VPS-38(zzbb2dI9371I1415Jdf9M1432N98dKzz1202hzz1033IL8275bh8275dhz2dh2a8h668h839h944h) X-Forefront-Antispam-Report: CIP:174.47.84.216; KIP:(null); UIP:(null); IPV:NLI; H:PDXHB01.tripwire.com; RD:174-47-84-216.static.twtelecom.net; EFVD:NLI Received: from mail129-ch1 (localhost.localdomain [127.0.0.1]) by mail129-ch1 (MessageSwitch) id 1334255306968528_6760; Thu, 12 Apr 2012 18:28:26 +0000 (UTC) Received: from CH1EHSMHS028.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.246]) by mail129-ch1.bigfish.com (Postfix) with ESMTP id DEB00120130 for ; Thu, 12 Apr 2012 18:28:26 +0000 (UTC) Received: from PDXHB01.tripwire.com (174.47.84.216) by CH1EHSMHS028.bigfish.com (10.43.70.28) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 12 Apr 2012 18:28:26 +0000 Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 12 Apr 2012 11:37:57 -0700 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0355.002; Thu, 12 Apr 2012 11:28:25 -0700 From: Adam Montville To: Adam Montville , "mile@ietf.org" Thread-Topic: [mile] IODEF Reference Format for Enumerations Thread-Index: AQHNFn/rimqKx0bIq0Wznd3Jbi9osJaXhxIA Date: Thu, 12 Apr 2012 18:28:24 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [172.30.0.234] x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: tripwire.com Subject: Re: [mile] IODEF Reference Format for Enumerations 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, 12 Apr 2012 18:28:31 -0000 All: So far, it seems as though more people are speaking up in favor of Option 2. There are also several comments expressing a desire to choose either Option 1 or Option 2, but then move to Option 3 at some point in the future. I'd like to understand more about what that really means - choosing one option and then moving to another. Would it make more sense to wait until IODEF is "opened" for an update to address this issue? For those of you who prefer Option 1 or Option 2, but have not indicated a preference with respect to later moving to Option 3, do you have an opinion about such a move? David Black has put forward some additional insight where, "if Option 1 is chosen, the result is a common means of referencing specifications between the SCI draft and the new draft on use of the IODEF reference format." This statement references the notion of requiring the first URL of on IODEF element (associated with the ) to be a reference URI from the IANA registry established by the SCI draft. It would seem, then, that we have deterministic methods of understanding what a is, and thus how to parse it, but that we have several different mechanisms by which to accomplish this. Comments? Opinions? Regards, Adam On 4/9/12 11:38 AM, "Adam Montville" wrote: >All: > >There is an identified need to specify a format to include relevant >enumeration values in an IODEF document. The initial idea is to place >enumeration values and their references in IODEF's Reference class. There >are several ways to accomplish this goal. I'll do my best to enumerate >some options here, then I hope to hear some feedback/opinions about the >different approaches from the list. > >From the Structured Cybersecurity Information draft >(draft-takahashi-mile-sci-02), we may be interested to include the >following (not an inclusive list) enumerations in an IODEF document: >CAPEC, CCE, CPE, CVE, CWE, IEC 19770-2. > >The IODEF Reference class is described in 3.9.1 of RFC 5070, where a >Reference must have a ReferenceName and zero or more of URL or Description >respectively. > >For each option described below, we can consider use of the IANA registry. >The registry may be used to identify the identifier category and >potentially the appropriate identification format for that category. > > >Option 1: Simple ID >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >The first option would simply embed the relevant identifier in the >ReferenceName element of the Reference class. This may look like the >following: > > > id > http://www.example.com/path > http://www.otherexample.com/path > Description > > >Using this option, a variety of specific identifier formats could be >specified. CVE, for example, would start with "CVE-" and this convention >may be registered in an IANA table. > >No changes to IODEF are required for this option. > > > >Option 2: ID with coupled ID type >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D >The second option would prepend the identifier with it's type, which may >look something like the following. > > > id_type:id > http://www.example.com/path > http://www.otherexample.com/path > Description > > >Using this option, a variety of specific identifier types could be >specified, such that the identifier itself would not necessarily be >constrained, nor would new identifier formats necessarily need to be >specified in the future. An IANA table may be used for this solution as >well. > >No changes to IODEF would be required for this option. > > > >Option 3: ID with type expressed in Reference attribute >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D >The third option would require opening IODEF to update the Reference class >with an attribute, which may look something like the following. > > > id > http://www.example.com/path > http://www.otherexample.com/path > Description > > > > >Changes to IODEF are required for this option. > > >---- > >I look forward to fielding responses to these options, including any >additional options you may see, but which are not listed. > >What is your solution preference? > > >Regards, > >Adam W. Montville | Security and Compliance Architect > >Direct: 503 276-7661 >Mobile: 360 471-7815 > >TRIPWIRE | Take CONTROL >http://www.tripwire.com > > > > > > >_______________________________________________ >mile mailing list >mile@ietf.org >https://www.ietf.org/mailman/listinfo/mile > From kathleen.moriarty@emc.com Thu Apr 12 11:56:39 2012 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 CA09821F860D for ; Thu, 12 Apr 2012 11:56:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.391 X-Spam-Level: X-Spam-Status: No, score=-10.391 tagged_above=-999 required=5 tests=[AWL=0.208, 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 gtrGvsJlpYap for ; Thu, 12 Apr 2012 11:56:38 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id BE15121F85F7 for ; Thu, 12 Apr 2012 11:56:38 -0700 (PDT) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q3CIubQk018922 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Apr 2012 14:56:37 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.129]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Thu, 12 Apr 2012 14:56:16 -0400 Received: from mxhub30.corp.emc.com (mxhub30.corp.emc.com [128.222.70.170]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q3CIuGPJ015211; Thu, 12 Apr 2012 14:56:16 -0400 Received: from mx06a.corp.emc.com ([169.254.1.106]) by mxhub30.corp.emc.com ([128.222.70.170]) with mapi; Thu, 12 Apr 2012 14:56:15 -0400 From: To: , Date: Thu, 12 Apr 2012 14:56:14 -0400 Thread-Topic: [mile] IODEF Reference Format for Enumerations Thread-Index: AQHNFn/rimqKx0bIq0Wznd3Jbi9osJaXhxIAgAACw5A= 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [mile] IODEF Reference Format for Enumerations 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, 12 Apr 2012 18:56:39 -0000 Hi Adam, Thank you for running the list of options by the WG and to those participat= ing in the decision process! We have had a couple of reasons discussed to 'open' up IODEF. If we get a = volunteer to help with the editing of an RFC5070 soon, then option 3 may be= worth considering. I would expect that a revision to RFC5070 would take s= ome time as the list works through issues and options. What do others think about this and Adam's other questions? Thanks, Kathleen -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Ada= m Montville Sent: Thursday, April 12, 2012 2:28 PM To: Adam Montville; mile@ietf.org Subject: Re: [mile] IODEF Reference Format for Enumerations All: So far, it seems as though more people are speaking up in favor of Option 2. There are also several comments expressing a desire to choose either Option 1 or Option 2, but then move to Option 3 at some point in the future. I'd like to understand more about what that really means - choosing one option and then moving to another. Would it make more sense to wait until IODEF is "opened" for an update to address this issue? For those of you who prefer Option 1 or Option 2, but have not indicated a preference with respect to later moving to Option 3, do you have an opinion about such a move? David Black has put forward some additional insight where, "if Option 1 is chosen, the result is a common means of referencing specifications between the SCI draft and the new draft on use of the IODEF reference format." This statement references the notion of requiring the first URL of on IODEF element (associated with the ) to be a reference URI from the IANA registry established by the SCI draft. It would seem, then, that we have deterministic methods of understanding what a is, and thus how to parse it, but that we have several different mechanisms by which to accomplish this. Comments? Opinions? Regards, Adam On 4/9/12 11:38 AM, "Adam Montville" wrote: >All: > >There is an identified need to specify a format to include relevant >enumeration values in an IODEF document. The initial idea is to place >enumeration values and their references in IODEF's Reference class. There >are several ways to accomplish this goal. I'll do my best to enumerate >some options here, then I hope to hear some feedback/opinions about the >different approaches from the list. > >From the Structured Cybersecurity Information draft >(draft-takahashi-mile-sci-02), we may be interested to include the >following (not an inclusive list) enumerations in an IODEF document: >CAPEC, CCE, CPE, CVE, CWE, IEC 19770-2. > >The IODEF Reference class is described in 3.9.1 of RFC 5070, where a >Reference must have a ReferenceName and zero or more of URL or Description >respectively. > >For each option described below, we can consider use of the IANA registry. >The registry may be used to identify the identifier category and >potentially the appropriate identification format for that category. > > >Option 1: Simple ID >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >The first option would simply embed the relevant identifier in the >ReferenceName element of the Reference class. This may look like the >following: > > > id > http://www.example.com/path > http://www.otherexample.com/path > Description > > >Using this option, a variety of specific identifier formats could be >specified. CVE, for example, would start with "CVE-" and this convention >may be registered in an IANA table. > >No changes to IODEF are required for this option. > > > >Option 2: ID with coupled ID type >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D >The second option would prepend the identifier with it's type, which may >look something like the following. > > > id_type:id > http://www.example.com/path > http://www.otherexample.com/path > Description > > >Using this option, a variety of specific identifier types could be >specified, such that the identifier itself would not necessarily be >constrained, nor would new identifier formats necessarily need to be >specified in the future. An IANA table may be used for this solution as >well. > >No changes to IODEF would be required for this option. > > > >Option 3: ID with type expressed in Reference attribute >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D >The third option would require opening IODEF to update the Reference class >with an attribute, which may look something like the following. > > > id > http://www.example.com/path > http://www.otherexample.com/path > Description > > > > >Changes to IODEF are required for this option. > > >---- > >I look forward to fielding responses to these options, including any >additional options you may see, but which are not listed. > >What is your solution preference? > > >Regards, > >Adam W. Montville | Security and Compliance Architect > >Direct: 503 276-7661 >Mobile: 360 471-7815 > >TRIPWIRE | Take CONTROL >http://www.tripwire.com > > > > > > >_______________________________________________ >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 david.waltermire@nist.gov Fri Apr 13 07:03:35 2012 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 181D021F867A for ; Fri, 13 Apr 2012 07:03:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.888 X-Spam-Level: X-Spam-Status: No, score=-5.888 tagged_above=-999 required=5 tests=[AWL=0.711, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n0OpJ+-t8UKz for ; Fri, 13 Apr 2012 07:03:34 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id F21D021F866A for ; Fri, 13 Apr 2012 07:03:33 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 13 Apr 2012 10:03:24 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Fri, 13 Apr 2012 10:02:25 -0400 From: "Waltermire, David A." To: Adam Montville , "mile@ietf.org" Date: Fri, 13 Apr 2012 10:03:31 -0400 Thread-Topic: [mile] IODEF Reference Format for Enumerations Thread-Index: AQHNFn/rimqKx0bIq0Wznd3Jbi9osJaXhxIAgAFGmSA= 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: text/plain; charset="us-ascii" MIME-Version: 1.0 Subject: Re: [mile] IODEF Reference Format for Enumerations X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 14:03:35 -0000 Referencing security identifiers seems like an issue that will surface in other efforts. If we create an IANA registry, it would be ideal if this registry could support reference use cases in other models. Although each model may have sligtly different reference syntax, the general method for defining the type and identifier based the registry could be the same. Have you put any thought into how this could be accomplished? One idea would be to have the draft you are focused on define the mechanism for defining identifier types and then have IODEF define how to represent a reference using the Reference class. Other models could follow suit. Sincerely, David Waltermire > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of > Adam Montville > Sent: Thursday, April 12, 2012 2:28 PM > To: Adam Montville; mile@ietf.org > Subject: Re: [mile] IODEF Reference Format for Enumerations > > All: > > So far, it seems as though more people are speaking up in favor of > Option 2. There are also several comments expressing a desire to > choose either Option 1 or Option 2, but then move to Option 3 at some > point in the future. I'd like to understand more about what that > really means - choosing one option and then moving to another. > > Would it make more sense to wait until IODEF is "opened" for an update > to address this issue? > > For those of you who prefer Option 1 or Option 2, but have not > indicated a preference with respect to later moving to Option 3, do you > have an opinion about such a move? > > David Black has put forward some additional insight where, "if Option 1 > is chosen, the result is a common means of referencing specifications > between the SCI draft and the new draft on use of the IODEF reference > format." > This statement references the notion of requiring the first URL of on > IODEF element (associated with the ) to be a > reference URI from the IANA registry established by the SCI draft. > > It would seem, then, that we have deterministic methods of > understanding what a is, and thus how to parse it, but > that we have several different mechanisms by which to accomplish this. > > Comments? Opinions? > > Regards, > > Adam > > On 4/9/12 11:38 AM, "Adam Montville" wrote: > > >All: > > > >There is an identified need to specify a format to include relevant > >enumeration values in an IODEF document. The initial idea is to place > >enumeration values and their references in IODEF's Reference class. > >There are several ways to accomplish this goal. I'll do my best to > >enumerate some options here, then I hope to hear some > feedback/opinions > >about the different approaches from the list. > > > >From the Structured Cybersecurity Information draft > >(draft-takahashi-mile-sci-02), we may be interested to include the > >following (not an inclusive list) enumerations in an IODEF document: > >CAPEC, CCE, CPE, CVE, CWE, IEC 19770-2. > > > >The IODEF Reference class is described in 3.9.1 of RFC 5070, where a > >Reference must have a ReferenceName and zero or more of URL or > >Description respectively. > > > >For each option described below, we can consider use of the IANA > registry. > >The registry may be used to identify the identifier category and > >potentially the appropriate identification format for that category. > > > > > >Option 1: Simple ID > >=================== > >The first option would simply embed the relevant identifier in the > >ReferenceName element of the Reference class. This may look like the > >following: > > > > > > id > > http://www.example.com/path > > http://www.otherexample.com/path > > Description > > > > > >Using this option, a variety of specific identifier formats could be > >specified. CVE, for example, would start with "CVE-" and this > >convention may be registered in an IANA table. > > > >No changes to IODEF are required for this option. > > > > > > > >Option 2: ID with coupled ID type > >================================= > >The second option would prepend the identifier with it's type, which > >may look something like the following. > > > > > > id_type:id > > http://www.example.com/path > > http://www.otherexample.com/path > > Description > > > > > >Using this option, a variety of specific identifier types could be > >specified, such that the identifier itself would not necessarily be > >constrained, nor would new identifier formats necessarily need to be > >specified in the future. An IANA table may be used for this solution > >as well. > > > >No changes to IODEF would be required for this option. > > > > > > > >Option 3: ID with type expressed in Reference attribute > >======================================================= > >The third option would require opening IODEF to update the Reference > >class with an attribute, which may look something like the following. > > > > > > id > > http://www.example.com/path > > http://www.otherexample.com/path > > Description > > > > > > > > > >Changes to IODEF are required for this option. > > > > > >---- > > > >I look forward to fielding responses to these options, including any > >additional options you may see, but which are not listed. > > > >What is your solution preference? > > > > > >Regards, > > > >Adam W. Montville | Security and Compliance Architect > > > >Direct: 503 276-7661 > >Mobile: 360 471-7815 > > > >TRIPWIRE | Take CONTROL > >http://www.tripwire.com > > > > > > > > > > > > > >_______________________________________________ > >mile mailing list > >mile@ietf.org > >https://www.ietf.org/mailman/listinfo/mile > > > > > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From internet-drafts@ietf.org Fri Apr 13 23:42:57 2012 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 025B221F86EA; Fri, 13 Apr 2012 23:42:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 C1gLvf8fYer4; Fri, 13 Apr 2012 23:42:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39D0D21F86CF; Fri, 13 Apr 2012 23:42:56 -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.00 Message-ID: <20120414064256.15686.28183.idtracker@ietfa.amsl.com> Date: Fri, 13 Apr 2012 23:42:56 -0700 Cc: mile@ietf.org Subject: [mile] I-D Action: draft-ietf-mile-grc-exchange-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: Sat, 14 Apr 2012 06:42:57 -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= Working Group of the IETF. Title : GRC Report Exchange Author(s) : Kathleen M. Moriarty Said Tabet David Waltermire Filename : draft-ietf-mile-grc-exchange-00.txt Pages : 68 Date : 2012-04-13 Governance, risk, and compliance (GRC) programs provide oversight (governance) of risks and compliance initiatives within an organization. GRC reports are increasingly provided in an XML format. This specification defines a common method to securely transport GRC and other XML reports. The defined messaging capability provides policy options and markings in an XML schema, options for confidentiality at the document/report level, and security for the end-to-end communication. XML reports may be shared between service providers and clients, enterprises, or within enterprises. Reports may also be exchanged for official purposes such as business report filings, compliance report filings, and the handling of legal incidents (eWarrant, eDiscovery, etc.) This work is a generalized format derived from the secure exchange of incident information defined by RFC6545, Real-time Inter-network Defense (RID). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mile-grc-exchange-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mile-grc-exchange-00.txt From takeshi_takahashi@nict.go.jp Mon Apr 16 01:46:07 2012 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 414D621F86DE for ; Mon, 16 Apr 2012 01:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[AWL=0.655, 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 1m9m3hqaRlue for ; Mon, 16 Apr 2012 01:46:06 -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 2315021F8650 for ; Mon, 16 Apr 2012 01:46:05 -0700 (PDT) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id q3G8k0af027960; Mon, 16 Apr 2012 17:46:00 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id q3G8k0ph022807; Mon, 16 Apr 2012 17:46:00 +0900 (JST) Received: from mail2.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id q3G8k0mK022804; Mon, 16 Apr 2012 17:46:00 +0900 (JST) Received: from mail2.nict.go.jp (localhost [127.0.0.1]) by mail2.nict.go.jp (NICT Mail) with ESMTP id 3AA5416BCC; Mon, 16 Apr 2012 17:46:00 +0900 (JST) Received: from takeVAIO2 (unknown [133.243.119.6]) by mail2.nict.go.jp (NICT Mail) with ESMTP id 2FF49168C3; Mon, 16 Apr 2012 17:46:00 +0900 (JST) From: "Takeshi Takahashi" To: , , References: In-Reply-To: Date: Mon, 16 Apr 2012 17:45:54 +0900 Message-ID: <001701cd1bad$5608c580$021a5080$@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: AQM1WayDYhKsYJzZ9gEOTtLhPBVz+wI6GrMnAqD/9cKTpcqEMA== Content-Language: ja Subject: Re: [mile] IODEF Reference Format for Enumerations 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, 16 Apr 2012 08:46:07 -0000 Hi all, If we are going to update option 3, that would be one direction. IMHO, the option 3 is very close to the expected use of the Vulnerability class of SCI draft. (and some other classes as well) The expected usage of the Vulnerability class of current SCI draft, with CVE identifier, is as follows. The slight difference between the SCI draft and the option 3 is that the SCI draft took a semantic approach (vulnerability, attackpattern, etc.), while the option three takes general container approach. The URLs to the information of the specification (in this case CVE 1.0) are described in the IANA table in case of the SCI draft approach. I think both approach is viable, but proper description on how to choose either of the approaches could be helpful for readers. Thank you. Take > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of > kathleen.moriarty@emc.com > Sent: Friday, April 13, 2012 3:56 AM > To: amontville@tripwire.com; mile@ietf.org > Subject: Re: [mile] IODEF Reference Format for Enumerations > > Hi Adam, > > Thank you for running the list of options by the WG and to those > participating in the decision process! > > We have had a couple of reasons discussed to 'open' up IODEF. If we get > a volunteer to help with the editing of an RFC5070 soon, then option 3 > may be worth considering. I would expect that a revision to RFC5070 would > take some time as the list works through issues and options. > > What do others think about this and Adam's other questions? > > Thanks, > Kathleen > > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of > Adam Montville > Sent: Thursday, April 12, 2012 2:28 PM > To: Adam Montville; mile@ietf.org > Subject: Re: [mile] IODEF Reference Format for Enumerations > > All: > > So far, it seems as though more people are speaking up in favor of Option > 2. There are also several comments expressing a desire to choose either > Option 1 or Option 2, but then move to Option 3 at some point in the future. > I'd like to understand more about what that really means - choosing one > option and then moving to another. > > Would it make more sense to wait until IODEF is "opened" for an update > to address this issue? > > For those of you who prefer Option 1 or Option 2, but have not indicated > a preference with respect to later moving to Option 3, do you have an > opinion about such a move? > > David Black has put forward some additional insight where, "if Option > 1 is chosen, the result is a common means of referencing specifications > between the SCI draft and the new draft on use of the IODEF reference > format." > This statement references the notion of requiring the first URL of on > IODEF element (associated with the ) to be > a reference URI from the IANA registry established by the SCI draft. > > It would seem, then, that we have deterministic methods of understanding > what a is, and thus how to parse it, but that we have > several different mechanisms by which to accomplish this. > > Comments? Opinions? > > Regards, > > Adam > > On 4/9/12 11:38 AM, "Adam Montville" wrote: > > >All: > > > >There is an identified need to specify a format to include relevant > >enumeration values in an IODEF document. The initial idea is to place > >enumeration values and their references in IODEF's Reference class. > >There are several ways to accomplish this goal. I'll do my best to > >enumerate some options here, then I hope to hear some feedback/opinions > >about the different approaches from the list. > > > >From the Structured Cybersecurity Information draft > >(draft-takahashi-mile-sci-02), we may be interested to include the > >following (not an inclusive list) enumerations in an IODEF document: > >CAPEC, CCE, CPE, CVE, CWE, IEC 19770-2. > > > >The IODEF Reference class is described in 3.9.1 of RFC 5070, where a > >Reference must have a ReferenceName and zero or more of URL or > >Description respectively. > > > >For each option described below, we can consider use of the IANA registry. > >The registry may be used to identify the identifier category and > >potentially the appropriate identification format for that category. > > > > > >Option 1: Simple ID > >=================== > >The first option would simply embed the relevant identifier in the > >ReferenceName element of the Reference class. This may look like the > >following: > > > > > > id > > http://www.example.com/path > > http://www.otherexample.com/path > > Description > > > > > >Using this option, a variety of specific identifier formats could be > >specified. CVE, for example, would start with "CVE-" and this > >convention may be registered in an IANA table. > > > >No changes to IODEF are required for this option. > > > > > > > >Option 2: ID with coupled ID type > >================================= > >The second option would prepend the identifier with it's type, which > >may look something like the following. > > > > > > id_type:id > > http://www.example.com/path > > http://www.otherexample.com/path > > Description > > > > > >Using this option, a variety of specific identifier types could be > >specified, such that the identifier itself would not necessarily be > >constrained, nor would new identifier formats necessarily need to be > >specified in the future. An IANA table may be used for this solution > >as well. > > > >No changes to IODEF would be required for this option. > > > > > > > >Option 3: ID with type expressed in Reference attribute > >======================================================= > >The third option would require opening IODEF to update the Reference > >class with an attribute, which may look something like the following. > > > > > > id > > http://www.example.com/path > > http://www.otherexample.com/path > > Description > > > > > > > > > >Changes to IODEF are required for this option. > > > > > >---- > > > >I look forward to fielding responses to these options, including any > >additional options you may see, but which are not listed. > > > >What is your solution preference? > > > > > >Regards, > > > >Adam W. Montville | Security and Compliance Architect > > > >Direct: 503 276-7661 > >Mobile: 360 471-7815 > > > >TRIPWIRE | Take CONTROL > >http://www.tripwire.com > > > > > > > > > > > > > >_______________________________________________ > >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 sbarnum@mitre.org Mon Apr 16 13:05:01 2012 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 EAADC21F86FE for ; Mon, 16 Apr 2012 13:05:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4bWGXy6NMK4I for ; Mon, 16 Apr 2012 13:04:57 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 7743B21F86FA for ; Mon, 16 Apr 2012 13:04:57 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id A477621B0BCA; Mon, 16 Apr 2012 16:04:54 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 89AFA21B0B10; Mon, 16 Apr 2012 16:04:54 -0400 (EDT) Received: from IMCMBX03.MITRE.ORG ([169.254.3.179]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.02.0283.003; Mon, 16 Apr 2012 16:04:54 -0400 From: "Barnum, Sean D." To: "idxwg@nicwg.org" , "mile@ietf.org" Thread-Topic: CybOX v1.0 (Draft) is now released and live on the website Thread-Index: Ac0cC5d+AmQj+T0kR7yrc02aMAE2BgAAA7pg Date: Mon, 16 Apr 2012 20:04:53 +0000 Message-ID: <7F48813B48558A4BB5CB7BB714E5B5A91706E3@IMCMBX03.MITRE.ORG> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [128.29.5.22] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0059_01CD1BEA.A5E26FB0" MIME-Version: 1.0 Cc: "'Doug Wilson \(dallendoug@gmail.com\)'" , "IPA-Masato Terada \(m-terada@ipa.go.jp\)" Subject: [mile] CybOX v1.0 (Draft) is now released and live on the website 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, 16 Apr 2012 20:05:01 -0000 ------=_NextPart_000_0059_01CD1BEA.A5E26FB0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_005A_01CD1BEA.A5E26FB0" ------=_NextPart_001_005A_01CD1BEA.A5E26FB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hey everyone, I just wanted to let you all know that CybOX v1.0 (Draft) content is now live on the website. http://cybox.mitre.org The release notes are provided inline below. The key items of note are: . The release of two formal specifications for the CybOX language (one for the core language and one for the defined objects) . The XML Schema has gone through extensive improvements for expressiveness, clarity, consistency, efficiency, alignment to existing normative references and documentation. . This release includes an initial set of language utilities: a draft Snort -> CybOX transform, a draft OpenIOC -> CybOX transform, and a set of Python bindings for the CybOX language. . The website now includes a small set of content examples. This set will grow going forward. This release involved a lot of hard work from a diverse group of people. Thank you all for your contributions and effort. We could not have done it without you. We look forward to everyone's feedback and collaboration as we continue to improve and mature the CybOX language. Sean Barnum CybOX v1.0 (Draft) Release Notes The Version 1.0 (Draft) release of Cyber Observable eXpression (CybOXT) is intended as a draft release of an initial major version of the CybOX Language that could be utilized for practical operational use and integration into other standards efforts. This release consists of three primary components: a pair of formal language specifications for the core language content and defined objects content, a set of language implementation XML schemas (core, common_types, and ~70 defined object schemas), and a small initial set of language utilities including an initial draft Snort->CybOX transform, an initial draft OpenIOC->CybOX transform and a set of CybOX language Python bindings. Recognizing that this is the first time that the formal language specifications will be available for review and as such will likely generate feedback from new stakeholders, this initial major version is being released as a "draft" v1.0 with the expectation of cycles of new feedback and revision before a "final" v1.0 is released. The CybOX v1.0 (Draft) XML schemas include a significant number of changes from v0.7 to improve: . Clarity, documentation, and descriptive formality for reference and implementation by other standards and users. . Consistency, simplicity, and efficiency. . Alignment (as appropriate) to existing normative references. . Expressiveness of the schema to better support the broad set of use cases it targets (malware characterization, indicator and incident data sharing, event management, etc.) including the addition of an initial set of network-related defined objects. Summary of changes from CybOX_v0.7 to CybOX_v1.0_(Draft): * Refinement of namespaces and schema locations for better effectiveness and flexibility going forward. * Normalized all content according to an established set of naming conventions. * Fully annotated all language items (types, attributes, elements, etc.). * Moved several commonly leveraged types out of the core schema and into common_types. * Achieved full typing of entire schema structure such that all attributes and elements are definitively typed. * Changed all identifiers from ID and IDREF types to be QNames enabling globally unique identifiers and flexibility for domain-specific users of CybOX to define their own identifier syntax locally. * Reordered attributes and elements in numerous types to better reflect common usage and priority. * Added major_version and minor_version attributes for core schema. * Added capability to characterize source of overall observable package data and for individual observables. * Modified the logical composition structure such that any such compositions are now contained within a Observable_Composition element providing improved simplicity and modularity. * Removed the Delta element from ObservableType and relocated the appropriate portions (Change, Trend, and Frequency) to appropriate locations under Stateful_Measure and Event. * Added a Domain_Specific_Object_Attributes field to Object utilizing an abstract type that will allow domain-specific use cases to add in their own domain-specific attributes for Objects. * Added a Tool-Specific_Data field to ToolInformationType utilizing an abstract type that will allow addition of tool-specific data. * Added an Indicators field to MeasureSourceType utilizing an abstract type that will allow characterizing differing formats or standards of indicators that may have led to the identification of the observable data. * Enhanced the Hash structure to capture full fuzzy hashes in addition to simple hashes * Added a new ExtractedFeaturesType that can be used to adorn differing objects (e.g., files, memory, etc.) to capture extracted strings, imports, functions and code snippets * Added a ByteRunsType to enable capture of byte runs within various objects. * Added object_reference attribute to DefinedObjectType to better support referencing of independently defined Objects from within another Object definition. * Added a generic DataSegmentType to provide a relatively abstract way of characterizing data segments that may be written/read/transmitted or otherwise utilized in actions or defined in objects. . Added several new defined object schemas (API, Code, Device, DNS_Record, Network_Flow, Network_Packet, Network_Route_Entry, Network_Subnet, Unix_Network_Route_Entry) including an initial set of network-centric defined objects. * Modified every defined object schema with added annotations as well as minor and in some cases substantive changes to fix errors, improve consistency and alignment with existing normative references, and to improve expressiveness in support of the targeted use cases. Detailed changes from CybOX_v0.7 to CybOX_v1.0_(Draft): The level of changes within v1.0 (Draft) in the core schema, common_types and the defined object schemas is too great to list every change in these release notes. Detailed difference reports are available for each individual schema at: http://cybox.mitre.org/XMLSchema/release_notes/cybox_v1.0(draft)_diff_report s.zip =============================================== Sean Barnum Cyber Security Principal The MITRE Corporation Email: sbarnum@mitre.org ------=_NextPart_001_005A_01CD1BEA.A5E26FB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hey = everyone,

 

I just wanted to let you all know that CybOX v1.0 = (Draft) content is now live on the website. http://cybox.mitre.org

=

The release notes are provided inline = below.

The key items of note = are:

·        = The release of two formal specifications = for the CybOX language (one for the core language and one for the = defined objects)

·        = The XML Schema has gone through extensive = improvements for expressiveness, clarity, consistency, efficiency, = alignment to existing normative references and = documentation.

·        = This release includes an initial set of = language utilities: a draft Snort -> CybOX transform, a draft OpenIOC = -> CybOX transform, and a set of Python bindings for the CybOX = language.

·        = The website now includes a small set of = content examples. This set will grow going forward.

This release involved a lot of hard work from a = diverse group of people. Thank you all for your contributions and = effort. We could not have done it without you.

We look forward to everyone’s feedback and = collaboration as we continue to improve and mature the CybOX = language.

 

Sean Barnum

 

 

 

CybOX v1.0 (Draft) Release = Notes

The = Version 1.0 (Draft) release of Cyber Observable eXpression = (CybOX™) is intended as a draft release of an initial major = version of the CybOX Language that could be utilized for practical = operational use and integration into other standards efforts. This = release consists of three primary components: a pair of formal language = specifications for the core language content and defined objects = content, a set of language implementation XML schemas (core, = common_types, and ~70 defined object schemas), and a small initial set = of language utilities including an initial draft Snort->CybOX = transform, an initial draft OpenIOC->CybOX transform and a set of = CybOX language Python bindings. Recognizing that this is the first time = that the formal language specifications will be available for review and = as such will likely generate feedback from new stakeholders, this = initial major version is being released as a “draft” v1.0 = with the expectation of cycles of new feedback and revision before a = “final” v1.0 is released.

The = CybOX v1.0 (Draft) XML schemas include a significant number of changes = from v0.7 to improve:

·       = Clarity, documentation, and descriptive formality for = reference and implementation by other standards and = users.

·       = Consistency, simplicity, and = efficiency.

·       = Alignment (as appropriate) to existing normative = references.

·       = Expressiveness of the schema to better support the broad = set of use cases it targets (malware characterization, indicator and = incident data sharing, event management, etc.) including the addition of = an initial set of network-related defined = objects.

Summary = of changes from CybOX_v0.7 to = CybOX_v1.0_(Draft):

  • Refinement of namespaces and schema locations for better = effectiveness and flexibility going forward.
  • Normalized all content according to an established set = of naming conventions.
  • Fully annotated all language items (types, attributes, = elements, etc.).
  • Moved several commonly leveraged types out of the core = schema and into common_types.
  • Achieved full typing of entire schema structure such = that all attributes and elements are definitively = typed.
  • Changed all identifiers from ID and IDREF types to be = QNames enabling globally unique identifiers and flexibility for = domain-specific users of CybOX to define their own identifier syntax = locally.
  • Reordered attributes and elements in numerous types to = better reflect common usage and priority.
  • Added major_version and minor_version attributes for = core schema.
  • Added capability to characterize source of overall = observable package data and for individual = observables.
  • Modified the logical composition structure such that any = such compositions are now contained within a Observable_Composition = element providing improved simplicity and = modularity.
  • Removed the Delta element from ObservableType and = relocated the appropriate portions (Change, Trend, and Frequency) to = appropriate locations under Stateful_Measure and = Event.
  • Added a Domain_Specific_Object_Attributes field to = Object utilizing an abstract type that will allow domain-specific use = cases to add in their own domain-specific attributes for = Objects.
  • Added a Tool-Specific_Data field to ToolInformationType = utilizing an abstract type that will allow addition of tool-specific = data.
  • Added an Indicators field to MeasureSourceType utilizing = an abstract type that will allow characterizing differing formats or = standards of indicators that may have led to the identification of the = observable data.
  • Enhanced the Hash structure to capture full fuzzy hashes = in addition to simple hashes
  • Added a new ExtractedFeaturesType that can be used to = adorn differing objects (e.g., files, memory, etc.) to capture extracted = strings, imports, functions and code snippets
  • Added a ByteRunsType to enable capture of byte runs = within various objects.
  • Added object_reference attribute to DefinedObjectType to = better support referencing of independently defined Objects from within = another Object definition.
  • Added a generic DataSegmentType to provide a relatively = abstract way of characterizing data segments that may be = written/read/transmitted or otherwise utilized in actions or defined in = objects.

·        = Added = several new defined object schemas (API, Code, Device, DNS_Record, = Network_Flow, Network_Packet, Network_Route_Entry, Network_Subnet, = Unix_Network_Route_Entry) including an initial set of network-centric = defined objects.

  • Modified every defined object schema with added = annotations as well as minor and in some cases substantive changes to = fix errors, improve consistency and alignment with existing normative = references, and to improve expressiveness in support of the targeted use = cases.

Detailed changes from CybOX_v0.7 to = CybOX_v1.0_(Draft):

The = level of changes within v1.0 (Draft) in the core schema, common_types = and the defined object schemas is too great to list every change in = these release notes. Detailed difference reports are available for each = individual schema at: http://cybox.mitre.org/XMLSchema/release_notes/cybox_v1.0= (draft)_diff_reports.zip

 

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D

Sean = Barnum

Cyber Security = Principal

The MITRE = Corporation

Email: sbarnum@mitre.org=

 

------=_NextPart_001_005A_01CD1BEA.A5E26FB0-- ------=_NextPart_000_0059_01CD1BEA.A5E26FB0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYNDCCBS0w ggMVoAMCAQICEEw6UhQhT9OgRBVHf7KQ+1AwDQYJKoZIhvcNAQELBQAwKTEnMCUGA1UEAxMeTUlU UkUgQ29ycG9yYXRpb24gUEUgUm9vdCBDQS0xMB4XDTExMDQyNjE5NDU0NVoXDTIxMDQyNjE5NDgy MlowKTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUEUgUm9vdCBDQS0xMIICIjANBgkqhkiG 9w0BAQEFAAOCAg8AMIICCgKCAgEAtp8hR0hRq3im+Alwfb5ZHGP5k2OSY2TlVHYHIMUDH3MfW7b6 8lB3j3MwAMsxGK1ke/t6O4K0t9wRH4QDgOQ1CthmOGZW7xiN81h0vP1Yf14SNugUa7ZvH9KP3iXs y8QnOHal1bKf0Pa9KXib58qUuwfaZSCTW5P2ekqd8z4TETvfBWvPgDxyxnVsiAO6yL9WaRpMiSVM hYLWy3KRuU/gue0bVEi+qdg+hENh1NSNXpoqseS262nq5cx5wybR/PF0YstQ9NNlYDM5cLECKYHH zD6cXKJozuFXriswlE8rdna7VaxyZrfgC0ueEIY/tsj/65IyUhyPBwO0ZpW+Ls9Cd4Y+ERSu5mR5 Fd8w42eVzuosmk3s3AxrKC+Z4tXYkjaiWUduIegAiST1vJBwkS53vR+zrBX3Ep56l7MFVvW/GcsZ 9wUT2HG65JOeiVc2YzCEqLgQ3ZCBHn09oBag2lnMac+E2sKm9aKL3xzHs6cyD8qCJK9O8QLCqo3C mzASlOwtTFiLYgpPW/MSmgYOt9JrwHAzk97DHFKTFttjrXGMmhMVzadt1EjMn1Wv8t5WLBI0qSoX /MYi2CaeiDsEiWRu9Nmpu3pmi8m7tIR9csdbAVPks2soNMWOopGEpFQSDvU1+m77v2jIKQKYxYmN 2zUOJ4TJFL1osnZ/71MmLCDVd+ECAwEAAaNRME8wCwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMB Af8wHQYDVR0OBBYEFFuHfZ/+bL4C6fPgKTqKVCUsnzgvMBAGCSsGAQQBgjcVAQQDAgEAMA0GCSqG SIb3DQEBCwUAA4ICAQAy78sXsP/eqHH8/uOYyxQ6TBDhkCBxNoy8MF2c9UDns5ADL1qyxPAlpDBs L+2h1Zzt3FvPjg0SoRE/9juyG1qxMzhlv0jdQx12tESdo3uBb61b1uuc4H/VxCJWDI4KZL/B53EI 8HGPjUBdLADgOmG99uffm5uarSkjtIX//Bz3U6QfzTPlVWFi4SmzRI2mp16GQ8RPuJ/WMloaAn8X H6EjS2oLjGZC8Pw8/C46W48NvZ1JZTrZvYZr7GmuvmplYK68SZv/T5Su+FlLRTy9uNXQLHtm6jKv nDH2yB66zTwfaDpnjILnrC2O7ANRVZc0KywiKiW3nB7Joq74/XVuMI1PiSByt2Qu+RIS/WAI5wMi bTmwSiBxQZqvuth+dXoakJyOP2Wg5jvL55v9RLZhDqMtRI5ovnOFvTgNJQqNPSekGtA+m6Ctl/vh kSg65FFCMhaSkn7vY2Il+R8HouWJN8wTaudeexnyHcD+Mlt8QaB5CErpDjeeGZfQ0FcYm+6TtlMz Dw5eFhT/J6QrABCxfgLkVFHurMcQD4JkmXXkq5bP+GNkY0Uy2LMbw/UD94OEV1LpfAqUkT+mu5Yb vxg+elFtsad+Ix8owW372xynIADh9q1bHm+j1OHPJmGALWK9miRpC4t3isfu3ZB0QpI/e2Po6MED 393Jb0YbzrcElFv6ZDCCBhYwggP+oAMCAQICChrDbcgAAgAAN/wwDQYJKoZIhvcNAQEFBQAwUDET MBEGCgmSJomT8ixkARkWA09SRzEVMBMGCgmSJomT8ixkARkWBU1JVFJFMSIwIAYDVQQDExlNSVRS RSBDb3Jwb3JhdGlvbiBQRSBDQS0xMB4XDTEyMDMxMjE1MTgyN1oXDTE1MDMxMjE1MTgyN1owSjEL MAkGA1UEBhMCVVMxDjAMBgNVBAoTBU1JVFJFMQ8wDQYDVQQLEwZQZW9wbGUxGjAYBgNVBAMTEUJh cm51bS5TZWFuLjMxNTQzMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA9/I6RU7OcouL 6lcEJMAg8G3myNbQu84QnflS8p3PWOjgC6P50RDqGX5UxelDqMQPN5IsNYRXVY9/b7yN/RSH4goI JfYKMitndKuCKz1q38Nh0YycEm5x2t/IN/60b01T1uOmhZfptLDoDzj0UQZwMQ19mhM/ldsrC8bR GGuHXdQVaSyXygfhzNhqC06vZo5fvCBUJ6z7JtVrfRTHdudg19JYK+gds9p+Lvp/DOEXQmgpfpMl jfNKMnrG+kPMMngrIJUsF5lcbhHuc5mO+O8eR8FxM2KF7gfKVmUmZxs7Y6uLenVJVEmllP0XgUu1 sv3bClFgUo5x5Aq6rXshtHuVuQIDAQABo4IB9jCCAfIwKAYDVR0lBCEwHwYIKwYBBQUHAwQGCSsG AQQBcwIBBwYIKwYBBQUHAwIwHQYDVR0OBBYEFDvU1Ph/OVxGkxRmwvRx1TBf5PKqMA4GA1UdDwEB /wQEAwIGwDAcBgNVHREEFTATgRFzYmFybnVtQG1pdHJlLm9yZzAfBgNVHSMEGDAWgBRpZyAh1EjB 0BsGbvMIKOI6gn1BMTBJBgNVHR8EQjBAMD6gPKA6hjhodHRwOi8vcGtpLm1pdHJlLm9yZy9NSVRS RSUyMENvcnBvcmF0aW9uJTIwUEUlMjBDQS0xLmNybDB/BggrBgEFBQcBAQRzMHEwRwYIKwYBBQUH MAKGO2h0dHA6Ly9wa2kubWl0cmUub3JnL01JVFJFJTIwQ29ycG9yYXRpb24lMjBQRSUyMENBLTEo MikuY3J0MCYGCCsGAQUFBzABhhpodHRwOi8vb2NzcC5taXRyZS5vcmcvb2NzcDA+BgkrBgEEAYI3 FQcEMTAvBicrBgEEAYI3FQiDrqwjho6WV4GNiT2CpKsShb6uAYE2g9KXfYeg+0kCAWQCAQcwFgYD VR0gBA8wDTALBgkrBgEEAXMCAQgwNAYJKwYBBAGCNxUKBCcwJTAKBggrBgEFBQcDBDALBgkrBgEE AXMCAQcwCgYIKwYBBQUHAwIwDQYJKoZIhvcNAQEFBQADggIBAC2wqKo7QWQxIqnEKRznPrAQ5vQ9 X5JhB5keH8KMWu1W5n1RuSZH+3TYp4xccdYh+rV5b5+cJcWEYhtYpZriWm4kMHPaB6gKO9rbVfF9 R8Wp8sXvCKogbNhdkZwvXW4QymB1ASlMzDI1cCV8mzYgbIhWaCbV1zZBUVgOGa4LZIgdbdmgo5r/ O2gmnSftTYiE/tQ+DBs/25Bw/jC5HOiMXJqr+JctzJTqpEVLa7GKHnXWGuzGEPYkKBplxIyhz3Mv qc/yuKM7tZzAr8Qn5qf7VI9O2xp56QLjT2+mySOUR6Vml860FMpjjgZNMxAqOJt7OgY0PoUU9d18 yw1wiKSt0LUQoMcVvp7FifBjtBCG1sB/VOzxNvcNm6lO6EO23pvcjt6+WCG1X3pgnZ5UEohsM3c0 oLzYiuSYeVf85IO2yh9fWLWw2RGkf2szck1Xg0DsAQ54/YlZYyehELh43KbS3lpnTt8UlO7C0TMT 7JQwz4fTQg1a0e9rRPFnNDUG2fS2k3tz9IYILDB3F8uiZzzXptEzaYqzIqe5CK8ZGJQcw+w/CBen 6i+MV/y7yJmhio43Y1x9hIqoynqoSMV3CKYCoOwCvFUAGsNllDpExsQZoXrdd5gcuglqbh3t8wOM jtXDSQllQ/hXDZJf8rnH0wGx3K+WA+LKNvKqNCw9spEtsfG0MIIGYjCCBEqgAwIBAgIKFJcW0gAA AAAABDANBgkqhkiG9w0BAQsFADApMScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQRSBSb290 IENBLTEwHhcNMTEwNjE0MTc0NDQ0WhcNMTcwNjE0MTc1NDQ0WjBQMRMwEQYKCZImiZPyLGQBGRYD T1JHMRUwEwYKCZImiZPyLGQBGRYFTUlUUkUxIjAgBgNVBAMTGU1JVFJFIENvcnBvcmF0aW9uIFBF IENBLTEwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDSxK9RXieqdTz4JWRkRMs/EOuF 0P0S9SbspadLJkx/LDDnaAwmAnqfqm1n7/p82oVjy1yCye3SZu4Yp7fmDIAtWbkHvYOfxHkRv1ho /fhaNN0YRkd65oJJz2ngEbNZxdIiCoialQfX/iWU7ApQ+ovKbFV60v5E0p2mPncs20NYRfsaetdh nBZbFD9flDcXwJqSvGGGBfm7ifFCR1LrtEcNKjMwf7YEWZO0Vk3ZyhVq+k7JNLEbKv0OfBz8DU8G iGU+j88QlrgGW8PLkwNk7nsS/DJp8aLudTuVqIE2CA9mqn5QjU/EZYNHGzSfCr+/usUmbojyVSJu khhrAXspRAMz+Cia3yi3q3w8TnAljXWN1dhx1iuUv5GxyzMjfqK1tMuCUU2XzGNNqoVa1mqolBiy DTCOr9d/IC0YHYMBSpQ+xi0x9zjXKt4FmQmkEAZgF4hsZZqcJYL/iCQiwiz8fEyVPZuvoWvdEXOo zFYCpmkT0MZCJwyIux0Z6vJp6VLtN/6rZgc2y54HlTrp3ifazmpsfrk3NdHxlZTZug9kjEI+vEoy p/79nAPyTWQQ1MEP0ErCWav80/HOi0MLx/7lIUfvVOjkOFgFb+iDvR4T3RAQrnEpgTO+fc7Jyzh9 LpFDqm0slwDP4Hj9cC3IzdED5BU43PGAe+HoZ8OD/1ovVgwo/wIDAQABo4IBYzCCAV8wEAYJKwYB BAGCNxUBBAMCAQIwIwYJKwYBBAGCNxUCBBYEFFCiOtgZb+Zdflkw5sC2y01sUQaVMB0GA1UdDgQW BBRpZyAh1EjB0BsGbvMIKOI6gn1BMTAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTALBgNVHQ8E BAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAfBgNVHSMEGDAWgBRbh32f/my+Aunz4Ck6ilQlLJ84LzBQ BgNVHR8ESTBHMEWgQ6BBhj9odHRwOi8vcGtpLm1pdHJlLm9yZy9NSVRSRSUyMENvcnBvcmF0aW9u JTIwUEUlMjBSb290JTIwQ0EtMS5jcmwwWwYIKwYBBQUHAQEETzBNMEsGCCsGAQUFBzAChj9odHRw Oi8vcGtpLm1pdHJlLm9yZy9NSVRSRSUyMENvcnBvcmF0aW9uJTIwUEUlMjBSb290JTIwQ0EtMS5j cnQwDQYJKoZIhvcNAQELBQADggIBAHnDPfdYKxqNOtAYXMyyel83Vs8cCDAQZhSuIB0c6GkGoEdF rmWH9pwi42V96rCp7TvbNNKNJXbVHfJUAp+uqw663DL/sXXff9ZFxPxKOdPnpA8cKM7RBH9e437N w3d28A7PaGbP6tXmSqhXAhYZ4U12y1U5cOf2G/phUoAAMlnVJdfmXzMazvLo2SIeixAJyCze6rHQ TFQ/N+gAjbVuRJ+Hs8FEKVzMSwqlNoupe2ELqL4dMAKT6P08sAfxm2SrRlQvcWPYvqM/1C10bgc2 tdu+WGzRuP5Wx9Yr15KO9SW4z7fn2RVEXQgoDDno5vCIcfUPuKB5n+Kt9eBCitsgSD9yYsNUN9LE VIvjAb8MV2LWLfge1bumo6g7QMRa4Fgifw5siGwi7V2EaJQo6UAIVvxKKFC7W4p6CkrY2ga1d7GI Q0DPiWZOezOakJVAxL5gf+3WdNt0igKc/yLfbdHn6hCd1KPgDqkSKr8zWOZI/jiDBW957xAmaO6Q dGQDBZrQHWpIVwQGzF5bGrqms2kq49l3t7KmBu0C/9tExqKAmlf4Y5lfQGdCbKQpAq712DVQHYuD XmVQEAc2vlJ1C5hS3Iw9DwBWTfJ4vyB48buhBhbIhPiFta5OizXlKcsIi99ikA1yiZx/DBtjaw4J U6qJzWUFB2ecyGCNPtNbYjURA0A9MIIGfzCCBGegAwIBAgIKGsNq2wACAAA3+jANBgkqhkiG9w0B AQUFADBQMRMwEQYKCZImiZPyLGQBGRYDT1JHMRUwEwYKCZImiZPyLGQBGRYFTUlUUkUxIjAgBgNV BAMTGU1JVFJFIENvcnBvcmF0aW9uIFBFIENBLTEwHhcNMTIwMzEyMTUxODI3WhcNMTUwMzEyMTUx ODI3WjBKMQswCQYDVQQGEwJVUzEOMAwGA1UEChMFTUlUUkUxDzANBgNVBAsTBlBlb3BsZTEaMBgG A1UEAxMRQmFybnVtLlNlYW4uMzE1NDMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCW InZvCSslmSfSyhTVVSqnokCDajlsCNZHfUlkwkV1++2O71BYvMpjFHWR2XFIx963Hl63lFZzzVci OjIwLb1c/0YXhFfUdAvrbpjlu+ttlO05OEUW0h+5HO+qaebJPamxA00w0bokquRcPxUvwa3jiyL0 WfCwE3+/b5PCOW2xh7FXFKv262FnKIwxnQGXqkiXRP5D/SmdtcZSzxHkDThrhaiHPhJJhZ4XxwBk aGcAlMg8YH6uxshXm8e6c7XUu7gB5p+XThS0dqXujpQp/UQDp5t079+UrDcrpjfDBXIt9qCzLn26 uV5a4cD4xRKwA32f1cXFtiKXM0wYgUM3fEPDAgMBAAGjggJfMIICWzATBgNVHSUEDDAKBggrBgEF BQcDBDCBlAYJKoZIhvcNAQkPBIGGMIGDMA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DBAICAIAw BwYFKw4DAgcwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBLTALBglghkgBZQME ARYwCwYJYIZIAWUDBAEZMAsGCWCGSAFlAwQBAjALBglghkgBZQMEAQUwHQYDVR0OBBYEFIrbKa+E Rxo2/Sth2C6jZqZqvRE7MA4GA1UdDwEB/wQEAwIFIDAcBgNVHREEFTATgRFzYmFybnVtQG1pdHJl Lm9yZzAfBgNVHSMEGDAWgBRpZyAh1EjB0BsGbvMIKOI6gn1BMTBJBgNVHR8EQjBAMD6gPKA6hjho dHRwOi8vcGtpLm1pdHJlLm9yZy9NSVRSRSUyMENvcnBvcmF0aW9uJTIwUEUlMjBDQS0xLmNybDB/ BggrBgEFBQcBAQRzMHEwRwYIKwYBBQUHMAKGO2h0dHA6Ly9wa2kubWl0cmUub3JnL01JVFJFJTIw Q29ycG9yYXRpb24lMjBQRSUyMENBLTEoMikuY3J0MCYGCCsGAQUFBzABhhpodHRwOi8vb2NzcC5t aXRyZS5vcmcvb2NzcDA+BgkrBgEEAYI3FQcEMTAvBicrBgEEAYI3FQiDrqwjho6WV4GNiT2CpKsS hb6uAYE2hquSaISo7EUCAWQCAQ8wFgYDVR0gBA8wDTALBgkrBgEEAXMCAQgwGwYJKwYBBAGCNxUK BA4wDDAKBggrBgEFBQcDBDANBgkqhkiG9w0BAQUFAAOCAgEAGmmL43yA+J5lEockM1cxSoyxfSES HUGLVJyrhObbdFD4yO3jf0R4lHLuJlhp1486d9LRZAyzAnl9q8Zf3Tx1rl1kEd3pw0wMuO+ATscc rArEW/rJxjz6zTrNO3PFkFuOEdmKpHaRiFpuSX602INiBEBPluei3uZlWxHW9VqC7hz2diQpOlzS jtPMbL3o7ACjWaq7sQ0xB4rZ6oWyqOZEfHWQA1b7nFgL4nEbmEHNdU4jAjcxkROku4O04205kb5n Loveoz3TSQNt8zalFayZAjt+JEcKuG1f5cyhYI6QwvkS/3M+CjJezuNaSmno29Lm+ToZnwUm4nIB YkBx4r9ZDU2W8029tr5og00A5MGo1LK+unWtHBa7zuPblfSiYgXIHWU+OKrSFaA935Yb4fLXFe9S BmApBr1gohHYos1hct5q90WPufSKIQ9WT+vJYXvW3FpseO4ZLKVnJsO7gVoQEEnWJUwyABBPQrii F0gh++ApKZJROTuR36PsEEx4duI6U4VXMCiIcnEjvNR8Mt5Q/Vp4W4Mp5fCv+QzYkqq9EWD7QuUW Yul6R8Hf7ZTxbUk0NfJgu8escLrgQSwMdP/kE/09vJAAslQBkNnIS7iIhWt4l5XQJBrJc+6popRE R8ykWf25e4CliaUgbAl1tBQKivQ3tlX99WykI2XK3sTk9nsxggMjMIIDHwIBATBeMFAxEzARBgoJ kiaJk/IsZAEZFgNPUkcxFTATBgoJkiaJk/IsZAEZFgVNSVRSRTEiMCAGA1UEAxMZTUlUUkUgQ29y cG9yYXRpb24gUEUgQ0EtMQIKGsNtyAACAAA3/DAJBgUrDgMCGgUAoIIBmjAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjA0MTYyMDA0NDhaMCMGCSqGSIb3DQEJBDEW BBR6ymHmxidIGZXxw/I70DwqR7jabTBbBgkqhkiG9w0BCQ8xTjBMMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMC GjBtBgkrBgEEAYI3EAQxYDBeMFAxEzARBgoJkiaJk/IsZAEZFgNPUkcxFTATBgoJkiaJk/IsZAEZ FgVNSVRSRTEiMCAGA1UEAxMZTUlUUkUgQ29ycG9yYXRpb24gUEUgQ0EtMQIKGsNq2wACAAA3+jBv BgsqhkiG9w0BCRACCzFgoF4wUDETMBEGCgmSJomT8ixkARkWA09SRzEVMBMGCgmSJomT8ixkARkW BU1JVFJFMSIwIAYDVQQDExlNSVRSRSBDb3Jwb3JhdGlvbiBQRSBDQS0xAgoaw2rbAAIAADf6MA0G CSqGSIb3DQEBAQUABIIBAEkIKa4DefBQ3aKJ1/p1UsovekbdcKSLOf3Kb+H7WX5TqqKYFsT0RbAj RH0VGNxUUjv4sEvnv8pEfsN2mXfnJECBaDOV1nHoc2kzfhTVwx3I/zGXCMqp2HxVYetYG7ODBQOC 67TLLDqTqglGkQ0E6g8Ke1xH2ax4ydH+LbuJCC8/zaHVzucUX8TJbaoD+cfI4vq74BezS9MILE7/ rG5FeBeN1Tvmxj0H3Vj5ytm/IXmWNi3Hm+P8yXycvnpu2iK5Wh+BNFpy5F55YE+g3s9M5A1E8PH0 1kCXewWe3xDdcEdVhr8dgLyMgUS3T02iNr76V2g8WaCrbVfcRpfUPQZZwCUAAAAAAAA= ------=_NextPart_000_0059_01CD1BEA.A5E26FB0-- From lnunez@c3isecurity.com Mon Apr 16 15:44:37 2012 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 5999921F85F4 for ; Mon, 16 Apr 2012 15:44:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 qZn88NJtSIpF for ; Mon, 16 Apr 2012 15:44:36 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id CE2D421F8548 for ; Mon, 16 Apr 2012 15:44:35 -0700 (PDT) Received: by yhkk25 with SMTP id k25so3160990yhk.31 for ; Mon, 16 Apr 2012 15:44:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=XrgEASCk75iFDhXByDrfOhSIGUeGFRWnnwrfaWULXLU=; b=DjCYYA5G1p66euSLvSTWucx3f+zs4RMUjcGJjeqWqa36DdawItTEU0om5syXCn9frk EsDhBcKN8YKM6iaPDigJpjcdjlOKPfas3uH/TcWCebFW/KXtKl4ZzrqB7MWZXMaFbG+x nuHbRDocPOeJ6fi35+hYBL4oYRfb1LZyUz5y3ye7qVrlOhBtFidXnh/0VE2f6VJHUjL+ wqUU+uvZlfp7wtRjGEuJ5+82QsICDs2rCQftIDuSQZpqs09mnYbyqTXxaKsmX0lsWDUg AAZ8u7Zy9m3yQqWczK6PN9xP1OOEhrh+15Dfn2N5PGrC/C8OVl9FkjvYaTH7VkFN1+8y Tx/g== Received: by 10.100.233.35 with SMTP id f35mr3263105anh.37.1334616275197; Mon, 16 Apr 2012 15:44:35 -0700 (PDT) Received: from [172.16.1.104] (cpe-066-057-025-190.nc.res.rr.com. [66.57.25.190]) by mx.google.com with ESMTPS id 34sm33657192anu.6.2012.04.16.15.44.32 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 16 Apr 2012 15:44:33 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_787FBBB9-7AC9-43C0-A176-8C5F1F332347" From: Luis Nunez In-Reply-To: <7F48813B48558A4BB5CB7BB714E5B5A91706E3@IMCMBX03.MITRE.ORG> Date: Mon, 16 Apr 2012 18:44:28 -0400 Message-Id: <870A23D4-BA94-4431-B613-F3D7734B8DB5@c3isecurity.com> References: <7F48813B48558A4BB5CB7BB714E5B5A91706E3@IMCMBX03.MITRE.ORG> To: "Barnum, Sean D." X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQlw4a2qenQciensZ/RE1SdUez0S0EPUgowt6zIOs7+WUhUEALGsW4Owo6QCceKxloby121j Cc: idxwg@nicwg.org, mile@ietf.org, "Doug Wilson \(dallendoug@gmail.com\)" , sacm@ietf.org, "IPA-Masato Terada \(m-terada@ipa.go.jp\)" Subject: Re: [mile] CybOX v1.0 (Draft) is now released and live on the website 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, 16 Apr 2012 22:44:37 -0000 --Apple-Mail=_787FBBB9-7AC9-43C0-A176-8C5F1F332347 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I like the inclusion of the network-centric objects. IPFIX (netflow) = will add an additional perspective from an incident information sharing = standpoint. =20 -ln On Apr 16, 2012, at 4:04 PM, Barnum, Sean D. wrote: > Hey everyone, > =20 > I just wanted to let you all know that CybOX v1.0 (Draft) content is = now live on the website. http://cybox.mitre.org > The release notes are provided inline below. > The key items of note are: > =B7 The release of two formal specifications for the CybOX = language (one for the core language and one for the defined objects) > =B7 The XML Schema has gone through extensive improvements for = expressiveness, clarity, consistency, efficiency, alignment to existing = normative references and documentation. > =B7 This release includes an initial set of language utilities: = a draft Snort -> CybOX transform, a draft OpenIOC -> CybOX transform, = and a set of Python bindings for the CybOX language. > =B7 The website now includes a small set of content examples. = This set will grow going forward. >=20 > This release involved a lot of hard work from a diverse group of = people. Thank you all for your contributions and effort. We could not = have done it without you. > We look forward to everyone=92s feedback and collaboration as we = continue to improve and mature the CybOX language. > =20 > Sean Barnum > =20 > =20 > =20 > CybOX v1.0 (Draft) Release Notes >=20 > The Version 1.0 (Draft) release of Cyber Observable eXpression = (CybOX=99) is intended as a draft release of an initial major version of = the CybOX Language that could be utilized for practical operational use = and integration into other standards efforts. This release consists of = three primary components: a pair of formal language specifications for = the core language content and defined objects content, a set of language = implementation XML schemas (core, common_types, and ~70 defined object = schemas), and a small initial set of language utilities including an = initial draft Snort->CybOX transform, an initial draft OpenIOC->CybOX = transform and a set of CybOX language Python bindings. Recognizing that = this is the first time that the formal language specifications will be = available for review and as such will likely generate feedback from new = stakeholders, this initial major version is being released as a =93draft=94= v1.0 with the expectation of cycles of new feedback and revision before = a =93final=94 v1.0 is released. > The CybOX v1.0 (Draft) XML schemas include a significant number of = changes from v0.7 to improve: > =B7 Clarity, documentation, and descriptive formality for = reference and implementation by other standards and users. > =B7 Consistency, simplicity, and efficiency. > =B7 Alignment (as appropriate) to existing normative references. > =B7 Expressiveness of the schema to better support the broad set = of use cases it targets (malware characterization, indicator and = incident data sharing, event management, etc.) including the addition of = an initial set of network-related defined objects. >=20 > Summary of changes from CybOX_v0.7 to CybOX_v1.0_(Draft): > Refinement of namespaces and schema locations for better effectiveness = and flexibility going forward. > Normalized all content according to an established set of naming = conventions. > Fully annotated all language items (types, attributes, elements, = etc.). > Moved several commonly leveraged types out of the core schema and into = common_types. > Achieved full typing of entire schema structure such that all = attributes and elements are definitively typed. > Changed all identifiers from ID and IDREF types to be QNames enabling = globally unique identifiers and flexibility for domain-specific users of = CybOX to define their own identifier syntax locally. > Reordered attributes and elements in numerous types to better reflect = common usage and priority. > Added major_version and minor_version attributes for core schema. > Added capability to characterize source of overall observable package = data and for individual observables. > Modified the logical composition structure such that any such = compositions are now contained within a Observable_Composition element = providing improved simplicity and modularity. > Removed the Delta element from ObservableType and relocated the = appropriate portions (Change, Trend, and Frequency) to appropriate = locations under Stateful_Measure and Event. > Added a Domain_Specific_Object_Attributes field to Object utilizing an = abstract type that will allow domain-specific use cases to add in their = own domain-specific attributes for Objects. > Added a Tool-Specific_Data field to ToolInformationType utilizing an = abstract type that will allow addition of tool-specific data. > Added an Indicators field to MeasureSourceType utilizing an abstract = type that will allow characterizing differing formats or standards of = indicators that may have led to the identification of the observable = data. > Enhanced the Hash structure to capture full fuzzy hashes in addition = to simple hashes > Added a new ExtractedFeaturesType that can be used to adorn differing = objects (e.g., files, memory, etc.) to capture extracted strings, = imports, functions and code snippets > Added a ByteRunsType to enable capture of byte runs within various = objects. > Added object_reference attribute to DefinedObjectType to better = support referencing of independently defined Objects from within another = Object definition. > Added a generic DataSegmentType to provide a relatively abstract way = of characterizing data segments that may be written/read/transmitted or = otherwise utilized in actions or defined in objects. > =B7 Added several new defined object schemas (API, Code, = Device, DNS_Record, Network_Flow, Network_Packet, Network_Route_Entry, = Network_Subnet, Unix_Network_Route_Entry) including an initial set of = network-centric defined objects. > Modified every defined object schema with added annotations as well as = minor and in some cases substantive changes to fix errors, improve = consistency and alignment with existing normative references, and to = improve expressiveness in support of the targeted use cases. > Detailed changes from CybOX_v0.7 to CybOX_v1.0_(Draft): > The level of changes within v1.0 (Draft) in the core schema, = common_types and the defined object schemas is too great to list every = change in these release notes. Detailed difference reports are available = for each individual schema = at:http://cybox.mitre.org/XMLSchema/release_notes/cybox_v1.0(draft)_diff_r= eports.zip > =20 > =20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Sean Barnum > Cyber Security Principal > The MITRE Corporation > Email: sbarnum@mitre.org > =20 > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile --Apple-Mail=_787FBBB9-7AC9-43C0-A176-8C5F1F332347 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I like the inclusion of the network-centric = objects.  IPFIX (netflow)  will add an additional perspective = from an incident information sharing standpoint. =  

-ln

On Apr 16, 2012, = at 4:04 PM, Barnum, Sean D. wrote:

Hey = everyone,
 
I just wanted to let you all know that CybOX v1.0 (Draft) = content is now live on the website. http://cybox.mitre.org
The release notes are provided inline = below.
The key items of note are:
=B7 The = release of two formal specifications for the CybOX language (one for the = core language and one for the defined objects)
=B7 The = XML Schema has gone through extensive improvements for expressiveness, = clarity, consistency, efficiency, alignment to existing normative = references and documentation.
        This = release includes an initial set of language utilities: a draft Snort = -> CybOX transform, a draft OpenIOC -> CybOX transform, and a set = of Python bindings for the CybOX language.

=B7 The = website now includes a small set of content examples. This set will grow = going forward.

This release involved a lot of = hard work from a diverse group of people. Thank you all for your = contributions and effort. We could not have done it without = you.
We look forward to everyone=92s feedback and = collaboration as we continue to improve and mature the CybOX = language.
 
Sean Barnum
 
 
 

CybOX v1.0 (Draft) Release = Notes

The Version 1.0 (Draft) release = of Cyber Observable eXpression (CybOX=99) is intended as a draft = release of an initial major version of the CybOX Language that could be = utilized for practical operational use and integration into other = standards efforts. This release consists of three primary components: a = pair of formal language specifications for the core language content and = defined objects content, a set of language implementation XML schemas = (core, common_types, and ~70 defined object schemas), and a small = initial set of language utilities including an initial draft = Snort->CybOX transform, an initial draft OpenIOC->CybOX transform = and a set of CybOX language Python bindings. Recognizing that this is = the first time that the formal language specifications will be available = for review and as such will likely generate feedback from new = stakeholders, this initial major version is being released as a =93draft=94= v1.0 with the expectation of cycles of new feedback and revision before = a =93final=94 v1.0 is released.
The CybOX v1.0 (Draft) XML schemas include a = significant number of changes from v0.7 to = improve:
=B7       =B7 =B7 =B7 Summary of changes from CybOX_v0.7 to = CybOX_v1.0_(Draft):
  • Refinement of namespaces and schema locations for = better effectiveness and flexibility going = forward.
  • Normalized all content according to an established set = of naming conventions.
  • Fully annotated all language items (types, attributes, = elements, etc.).
  • Moved several commonly leveraged types out of the core = schema and into common_types.
  • Achieved full typing of entire schema = structure such that all attributes and elements are definitively = typed.
  • Reordered attributes and elements in numerous types to = better reflect common usage and priority.
  • Added major_version and minor_version = attributes for core schema.
  • Added capability to characterize source of overall = observable package data and for individual = observables.
  • Modified the logical composition structure such that = any such compositions are now contained within a Observable_Composition = element providing improved simplicity and = modularity.
  • Removed the Delta element from ObservableType and = relocated the appropriate portions (Change, Trend, and Frequency) to = appropriate locations under Stateful_Measure and = Event.
  • Added = a Domain_Specific_Object_Attributes field to Object utilizing an = abstract type that will allow domain-specific use cases to add in their = own domain-specific attributes for Objects.
  • Added a Tool-Specific_Data field to = ToolInformationType utilizing an abstract type that will allow addition = of tool-specific data.
  • Added an Indicators field to MeasureSourceType = utilizing an abstract type that will allow characterizing differing = formats or standards of indicators that may have led to the = identification of the observable data.
  • Enhanced the Hash structure to capture full = fuzzy hashes in addition to simple hashes
  • Added a new ExtractedFeaturesType that can = be used to adorn differing objects (e.g., files, memory, etc.) to = capture extracted strings, imports, functions and code = snippets
  • Added a ByteRunsType to enable capture of byte runs = within various objects.
  • Added object_reference attribute to DefinedObjectType = to better support referencing of independently defined Objects from = within another Object definition.
  • Added a generic DataSegmentType to provide a = relatively abstract way of characterizing data segments that may be = written/read/transmitted or otherwise utilized in actions or defined in = objects.
        Added several new defined object schemas = (API, Code, Device, DNS_Record, Network_Flow, Network_Packet, = Network_Route_Entry, Network_Subnet, Unix_Network_Route_Entry) including = an initial set of network-centric defined = objects.
  • Modified every defined object schema with added = annotations as well as minor and in some cases substantive changes to = fix errors, improve consistency and alignment with existing normative = references, and to improve expressiveness in support of the targeted use = cases.
The = level of changes within v1.0 (Draft) in the core schema, common_types = and the defined object schemas is too great to list every change in = these release notes. Detailed difference reports are available for each = individual schema at: 
 
___________________________________________= ____
mile mailing list
To: Luis Nunez Thread-Topic: [mile] CybOX v1.0 (Draft) is now released and live on the website Thread-Index: Ac0cC5d+AmQj+T0kR7yrc02aMAE2BgAAA7pgAA4W5AAAAKzAMA== Date: Tue, 17 Apr 2012 03:14:18 +0000 Message-ID: <7F48813B48558A4BB5CB7BB714E5B5A9171AEB@IMCMBX03.MITRE.ORG> References: <7F48813B48558A4BB5CB7BB714E5B5A91706E3@IMCMBX03.MITRE.ORG> <870A23D4-BA94-4431-B613-F3D7734B8DB5@c3isecurity.com> In-Reply-To: <870A23D4-BA94-4431-B613-F3D7734B8DB5@c3isecurity.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.31.136.182] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_003A_01CD1C26.A2A48B80" MIME-Version: 1.0 Cc: "idxwg@nicwg.org" , "mile@ietf.org" , "Doug Wilson \(dallendoug@gmail.com\)" , "sacm@ietf.org" , "IPA-Masato Terada \(m-terada@ipa.go.jp\)" Subject: Re: [mile] CybOX v1.0 (Draft) is now released and live on the website 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, 17 Apr 2012 03:14:25 -0000 ------=_NextPart_000_003A_01CD1C26.A2A48B80 Content-Type: multipart/alternative; boundary="----=_NextPart_001_003B_01CD1C26.A2A48B80" ------=_NextPart_001_003B_01CD1C26.A2A48B80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I am glad to hear that you find it useful Luis. We felt that a minimum initial set of network-related objects was an important part of any sort of 1.0 release. The initial set of network-related objects for CybOX v1.0 (Draft) includes: Address, Port, URI, Socket, DNS_Record, DNS_Cache, Network_Flow, Network_Packet, Network_Route_Entry, Unix_Network_Route_Entry, Win_Network_Route_Entry, Network_Route, Network_Subnet, and Win_Network_Share. From our discussions with various knowledgeable parties, this seemed like a good initial baseline. If any of you experts have suggestions on other objects that would be useful for current needs or suggestions on refinements to these existing objects, we humbly welcome your input. Thanks Luis, sean From: Luis Nunez [mailto:lnunez@c3isecurity.com] Sent: Monday, April 16, 2012 6:44 PM To: Barnum, Sean D. Cc: idxwg@nicwg.org; mile@ietf.org; Doug Wilson (dallendoug@gmail.com); IPA-Masato Terada (m-terada@ipa.go.jp); sacm@ietf.org Subject: Re: [mile] CybOX v1.0 (Draft) is now released and live on the website I like the inclusion of the network-centric objects. IPFIX (netflow) will add an additional perspective from an incident information sharing standpoint. -ln On Apr 16, 2012, at 4:04 PM, Barnum, Sean D. wrote: Hey everyone, I just wanted to let you all know that CybOX v1.0 (Draft) content is now live on the website. http://cybox.mitre.org The release notes are provided inline below. The key items of note are: . The release of two formal specifications for the CybOX language (one for the core language and one for the defined objects) . The XML Schema has gone through extensive improvements for expressiveness, clarity, consistency, efficiency, alignment to existing normative references and documentation. . This release includes an initial set of language utilities: a draft Snort -> CybOX transform, a draft OpenIOC -> CybOX transform, and a set of Python bindings for the CybOX language. . The website now includes a small set of content examples. This set will grow going forward. This release involved a lot of hard work from a diverse group of people. Thank you all for your contributions and effort. We could not have done it without you. We look forward to everyone's feedback and collaboration as we continue to improve and mature the CybOX language. Sean Barnum CybOX v1.0 (Draft) Release Notes The Version 1.0 (Draft) release of Cyber Observable eXpression (CybOXT) is intended as a draft release of an initial major version of the CybOX Language that could be utilized for practical operational use and integration into other standards efforts. This release consists of three primary components: a pair of formal language specifications for the core language content and defined objects content, a set of language implementation XML schemas (core, common_types, and ~70 defined object schemas), and a small initial set of language utilities including an initial draft Snort->CybOX transform, an initial draft OpenIOC->CybOX transform and a set of CybOX language Python bindings. Recognizing that this is the first time that the formal language specifications will be available for review and as such will likely generate feedback from new stakeholders, this initial major version is being released as a "draft" v1.0 with the expectation of cycles of new feedback and revision before a "final" v1.0 is released. The CybOX v1.0 (Draft) XML schemas include a significant number of changes from v0.7 to improve: . Clarity, documentation, and descriptive formality for reference and implementation by other standards and users. . Consistency, simplicity, and efficiency. . Alignment (as appropriate) to existing normative references. . Expressiveness of the schema to better support the broad set of use cases it targets (malware characterization, indicator and incident data sharing, event management, etc.) including the addition of an initial set of network-related defined objects. Summary of changes from CybOX_v0.7 to CybOX_v1.0_(Draft): . Refinement of namespaces and schema locations for better effectiveness and flexibility going forward. . Normalized all content according to an established set of naming conventions. . Fully annotated all language items (types, attributes, elements, etc.). . Moved several commonly leveraged types out of the core schema and into common_types. . Achieved full typing of entire schema structure such that all attributes and elements are definitively typed. . Changed all identifiers from ID and IDREF types to be QNames enabling globally unique identifiers and flexibility for domain-specific users of CybOX to define their own identifier syntax locally. . Reordered attributes and elements in numerous types to better reflect common usage and priority. . Added major_version and minor_version attributes for core schema. . Added capability to characterize source of overall observable package data and for individual observables. . Modified the logical composition structure such that any such compositions are now contained within a Observable_Composition element providing improved simplicity and modularity. . Removed the Delta element from ObservableType and relocated the appropriate portions (Change, Trend, and Frequency) to appropriate locations under Stateful_Measure and Event. . Added a Domain_Specific_Object_Attributes field to Object utilizing an abstract type that will allow domain-specific use cases to add in their own domain-specific attributes for Objects. . Added a Tool-Specific_Data field to ToolInformationType utilizing an abstract type that will allow addition of tool-specific data. . Added an Indicators field to MeasureSourceType utilizing an abstract type that will allow characterizing differing formats or standards of indicators that may have led to the identification of the observable data. . Enhanced the Hash structure to capture full fuzzy hashes in addition to simple hashes . Added a new ExtractedFeaturesType that can be used to adorn differing objects (e.g., files, memory, etc.) to capture extracted strings, imports, functions and code snippets . Added a ByteRunsType to enable capture of byte runs within various objects. . Added object_reference attribute to DefinedObjectType to better support referencing of independently defined Objects from within another Object definition. . Added a generic DataSegmentType to provide a relatively abstract way of characterizing data segments that may be written/read/transmitted or otherwise utilized in actions or defined in objects. . Added several new defined object schemas (API, Code, Device, DNS_Record, Network_Flow, Network_Packet, Network_Route_Entry, Network_Subnet, Unix_Network_Route_Entry) including an initial set of network-centric defined objects. . Modified every defined object schema with added annotations as well as minor and in some cases substantive changes to fix errors, improve consistency and alignment with existing normative references, and to improve expressiveness in support of the targeted use cases. Detailed changes from CybOX_v0.7 to CybOX_v1.0_(Draft): The level of changes within v1.0 (Draft) in the core schema, common_types and the defined object schemas is too great to list every change in these release notes. Detailed difference reports are available for each individual schema at: http://cybox.mitre.org/XMLSchema/release_notes/cybox_v1.0(draft)_diff_report s.zip =============================================== Sean Barnum Cyber Security Principal The MITRE Corporation Email: sbarnum@mitre.org _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile ------=_NextPart_001_003B_01CD1C26.A2A48B80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am glad to hear that you find it useful = Luis.

We felt that a minimum initial set of network-related objects was an = important part of any sort of 1.0 release.

The initial set of network-related objects for CybOX v1.0 (Draft) = includes: Address, Port, URI, Socket, DNS_Record, DNS_Cache, = Network_Flow, Network_Packet, Network_Route_Entry, = Unix_Network_Route_Entry, Win_Network_Route_Entry, Network_Route, = Network_Subnet, and Win_Network_Share. From our discussions with various = knowledgeable parties, this seemed like a good initial = baseline.

 

If any of you experts have suggestions on other objects that would be = useful for current needs or suggestions on refinements to these existing = objects, we humbly welcome your input.

 

Thanks Luis,

 

sean

 

From:= = Luis Nunez [mailto:lnunez@c3isecurity.com]
Sent: Monday, = April 16, 2012 6:44 PM
To: Barnum, Sean D.
Cc: = idxwg@nicwg.org; mile@ietf.org; Doug Wilson (dallendoug@gmail.com); = IPA-Masato Terada (m-terada@ipa.go.jp); sacm@ietf.org
Subject: = Re: [mile] CybOX v1.0 (Draft) is now released and live on the = website

 

I like the inclusion of the network-centric = objects.  IPFIX (netflow)  will add an additional perspective = from an incident information sharing standpoint. =  

 

-ln

 

On Apr 16, 2012, at 4:04 = PM, Barnum, Sean D. wrote:



Hey = everyone,

 =

The = release notes are provided inline = below.

The key = items of note are:

·        The = release of two formal specifications for the CybOX language (one for the = core language and one for the defined = objects)

·        The XML = Schema has gone through extensive improvements for expressiveness, = clarity, consistency, efficiency, alignment to existing normative = references and documentation.

·        This = release includes an initial set of language utilities: a draft Snort = -> CybOX transform, a draft OpenIOC -> CybOX transform, and a set = of Python bindings for the CybOX language.

·        The = website now includes a small set of content examples. This set will grow = going forward.

This = release involved a lot of hard work from a diverse group of people. = Thank you all for your contributions and effort. We could not have done = it without you.

We look = forward to everyone’s feedback and collaboration as we continue to = improve and mature the CybOX = language.

 =

Sean = Barnum

 =

 =

 =

CybOX v1.0 (Draft) Release = Notes

The Version 1.0 (Draft) release of Cyber = Observable eXpression (CybOX™) is intended as a draft release of an initial major version of = the CybOX Language that could be utilized for practical operational use = and integration into other standards efforts. This release consists of = three primary components: a pair of formal language specifications for = the core language content and defined objects content, a set of language = implementation XML schemas (core, common_types, and ~70 defined object = schemas), and a small initial set of language utilities including an = initial draft Snort->CybOX transform, an initial draft = OpenIOC->CybOX transform and a set of CybOX language Python bindings. = Recognizing that this is the first time that the formal language = specifications will be available for review and as such will likely = generate feedback from new stakeholders, this initial major version is = being released as a “draft” v1.0 with the expectation of = cycles of new feedback and revision before a “final” v1.0 is = released.=

The CybOX v1.0 (Draft) XML schemas include a = significant number of changes from v0.7 to improve:=

·       Clarity, = documentation, and descriptive formality for reference and = implementation by other standards and users.=

·       Consistency, = simplicity, and efficiency.=

·       Alignment (as = appropriate) to existing normative references.=

·       Expressiveness of the = schema to better support the broad set of use cases it targets (malware = characterization, indicator and incident data sharing, event management, = etc.) including the addition of an initial set of network-related = defined objects.=

Summary = of changes from CybOX_v0.7 to CybOX_v1.0_(Draft):=

·        = Refinement of namespaces and schema = locations for better effectiveness and flexibility going forward.=

·        = Normalized all content according to an = established set of naming conventions.=

·        = Fully annotated all language items = (types, attributes, elements, etc.).=

·        = Moved several commonly leveraged types = out of the core schema and into common_types.=

·        = Achieved full typing of entire schema = structure such that all attributes and elements are definitively = typed.=

·        = Changed all identifiers from ID and IDREF = types to be QNames enabling globally unique identifiers and flexibility = for domain-specific users of CybOX to define their own identifier syntax = locally.=

·        = Reordered attributes and elements in = numerous types to better reflect common usage and priority.=

·        = Added major_version and minor_version = attributes for core schema.=

·        = Added capability to characterize source = of overall observable package data and for individual observables.=

·        = Modified the logical composition = structure such that any such compositions are now contained within a = Observable_Composition element providing improved simplicity and = modularity.=

·        = Removed the Delta element from = ObservableType and relocated the appropriate portions (Change, Trend, = and Frequency) to appropriate locations under Stateful_Measure and = Event.=

·        = Added a Domain_Specific_Object_Attributes = field to Object utilizing an abstract type that will allow = domain-specific use cases to add in their own domain-specific attributes = for Objects.=

·        = Added a Tool-Specific_Data field to = ToolInformationType utilizing an abstract type that will allow addition = of tool-specific data.=

·        = Added an Indicators field to = MeasureSourceType utilizing an abstract type that will allow = characterizing differing formats or standards of indicators that may = have led to the identification of the observable data.=

·        = Enhanced the Hash structure to capture = full fuzzy hashes in addition to simple hashes=

·        = Added a new ExtractedFeaturesType that = can be used to adorn differing objects (e.g., files, memory, etc.) to = capture extracted strings, imports, functions and code snippets=

·        = Added a ByteRunsType to enable capture of = byte runs within various objects.=

·        = Added object_reference attribute to = DefinedObjectType to better support referencing of independently defined = Objects from within another Object definition.=

·        = Added a generic DataSegmentType to = provide a relatively abstract way of characterizing data segments that = may be written/read/transmitted or otherwise utilized in actions or = defined in objects.=

·        Added several new = defined object schemas (API, Code, Device, DNS_Record, Network_Flow, = Network_Packet, Network_Route_Entry, Network_Subnet, = Unix_Network_Route_Entry) including an initial set of network-centric = defined objects.

·        = Modified every defined object schema with = added annotations as well as minor and in some cases substantive changes = to fix errors, improve consistency and alignment with existing normative = references, and to improve expressiveness in support of the targeted use = cases.=

Detailed changes from CybOX_v0.7 to = CybOX_v1.0_(Draft):=

The level of changes within v1.0 (Draft) in = the core schema, common_types and the defined object schemas is too = great to list every change in these release notes. Detailed difference = reports are available for each individual schema at:http://cybox.mitre.org/XMLSchema/release_notes/cybox_v1.0= (draft)_diff_reports.zip

 =

 =

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

Sean Barnum=

Cyber Security Principal=

The MITRE Corporation=

 =

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

 

------=_NextPart_001_003B_01CD1C26.A2A48B80-- ------=_NextPart_000_003A_01CD1C26.A2A48B80 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYNDCCBS0w ggMVoAMCAQICEEw6UhQhT9OgRBVHf7KQ+1AwDQYJKoZIhvcNAQELBQAwKTEnMCUGA1UEAxMeTUlU UkUgQ29ycG9yYXRpb24gUEUgUm9vdCBDQS0xMB4XDTExMDQyNjE5NDU0NVoXDTIxMDQyNjE5NDgy MlowKTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUEUgUm9vdCBDQS0xMIICIjANBgkqhkiG 9w0BAQEFAAOCAg8AMIICCgKCAgEAtp8hR0hRq3im+Alwfb5ZHGP5k2OSY2TlVHYHIMUDH3MfW7b6 8lB3j3MwAMsxGK1ke/t6O4K0t9wRH4QDgOQ1CthmOGZW7xiN81h0vP1Yf14SNugUa7ZvH9KP3iXs y8QnOHal1bKf0Pa9KXib58qUuwfaZSCTW5P2ekqd8z4TETvfBWvPgDxyxnVsiAO6yL9WaRpMiSVM hYLWy3KRuU/gue0bVEi+qdg+hENh1NSNXpoqseS262nq5cx5wybR/PF0YstQ9NNlYDM5cLECKYHH zD6cXKJozuFXriswlE8rdna7VaxyZrfgC0ueEIY/tsj/65IyUhyPBwO0ZpW+Ls9Cd4Y+ERSu5mR5 Fd8w42eVzuosmk3s3AxrKC+Z4tXYkjaiWUduIegAiST1vJBwkS53vR+zrBX3Ep56l7MFVvW/GcsZ 9wUT2HG65JOeiVc2YzCEqLgQ3ZCBHn09oBag2lnMac+E2sKm9aKL3xzHs6cyD8qCJK9O8QLCqo3C mzASlOwtTFiLYgpPW/MSmgYOt9JrwHAzk97DHFKTFttjrXGMmhMVzadt1EjMn1Wv8t5WLBI0qSoX /MYi2CaeiDsEiWRu9Nmpu3pmi8m7tIR9csdbAVPks2soNMWOopGEpFQSDvU1+m77v2jIKQKYxYmN 2zUOJ4TJFL1osnZ/71MmLCDVd+ECAwEAAaNRME8wCwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMB Af8wHQYDVR0OBBYEFFuHfZ/+bL4C6fPgKTqKVCUsnzgvMBAGCSsGAQQBgjcVAQQDAgEAMA0GCSqG SIb3DQEBCwUAA4ICAQAy78sXsP/eqHH8/uOYyxQ6TBDhkCBxNoy8MF2c9UDns5ADL1qyxPAlpDBs L+2h1Zzt3FvPjg0SoRE/9juyG1qxMzhlv0jdQx12tESdo3uBb61b1uuc4H/VxCJWDI4KZL/B53EI 8HGPjUBdLADgOmG99uffm5uarSkjtIX//Bz3U6QfzTPlVWFi4SmzRI2mp16GQ8RPuJ/WMloaAn8X H6EjS2oLjGZC8Pw8/C46W48NvZ1JZTrZvYZr7GmuvmplYK68SZv/T5Su+FlLRTy9uNXQLHtm6jKv nDH2yB66zTwfaDpnjILnrC2O7ANRVZc0KywiKiW3nB7Joq74/XVuMI1PiSByt2Qu+RIS/WAI5wMi bTmwSiBxQZqvuth+dXoakJyOP2Wg5jvL55v9RLZhDqMtRI5ovnOFvTgNJQqNPSekGtA+m6Ctl/vh kSg65FFCMhaSkn7vY2Il+R8HouWJN8wTaudeexnyHcD+Mlt8QaB5CErpDjeeGZfQ0FcYm+6TtlMz Dw5eFhT/J6QrABCxfgLkVFHurMcQD4JkmXXkq5bP+GNkY0Uy2LMbw/UD94OEV1LpfAqUkT+mu5Yb vxg+elFtsad+Ix8owW372xynIADh9q1bHm+j1OHPJmGALWK9miRpC4t3isfu3ZB0QpI/e2Po6MED 393Jb0YbzrcElFv6ZDCCBhYwggP+oAMCAQICChrDbcgAAgAAN/wwDQYJKoZIhvcNAQEFBQAwUDET MBEGCgmSJomT8ixkARkWA09SRzEVMBMGCgmSJomT8ixkARkWBU1JVFJFMSIwIAYDVQQDExlNSVRS RSBDb3Jwb3JhdGlvbiBQRSBDQS0xMB4XDTEyMDMxMjE1MTgyN1oXDTE1MDMxMjE1MTgyN1owSjEL MAkGA1UEBhMCVVMxDjAMBgNVBAoTBU1JVFJFMQ8wDQYDVQQLEwZQZW9wbGUxGjAYBgNVBAMTEUJh cm51bS5TZWFuLjMxNTQzMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA9/I6RU7OcouL 6lcEJMAg8G3myNbQu84QnflS8p3PWOjgC6P50RDqGX5UxelDqMQPN5IsNYRXVY9/b7yN/RSH4goI JfYKMitndKuCKz1q38Nh0YycEm5x2t/IN/60b01T1uOmhZfptLDoDzj0UQZwMQ19mhM/ldsrC8bR GGuHXdQVaSyXygfhzNhqC06vZo5fvCBUJ6z7JtVrfRTHdudg19JYK+gds9p+Lvp/DOEXQmgpfpMl jfNKMnrG+kPMMngrIJUsF5lcbhHuc5mO+O8eR8FxM2KF7gfKVmUmZxs7Y6uLenVJVEmllP0XgUu1 sv3bClFgUo5x5Aq6rXshtHuVuQIDAQABo4IB9jCCAfIwKAYDVR0lBCEwHwYIKwYBBQUHAwQGCSsG AQQBcwIBBwYIKwYBBQUHAwIwHQYDVR0OBBYEFDvU1Ph/OVxGkxRmwvRx1TBf5PKqMA4GA1UdDwEB /wQEAwIGwDAcBgNVHREEFTATgRFzYmFybnVtQG1pdHJlLm9yZzAfBgNVHSMEGDAWgBRpZyAh1EjB 0BsGbvMIKOI6gn1BMTBJBgNVHR8EQjBAMD6gPKA6hjhodHRwOi8vcGtpLm1pdHJlLm9yZy9NSVRS RSUyMENvcnBvcmF0aW9uJTIwUEUlMjBDQS0xLmNybDB/BggrBgEFBQcBAQRzMHEwRwYIKwYBBQUH MAKGO2h0dHA6Ly9wa2kubWl0cmUub3JnL01JVFJFJTIwQ29ycG9yYXRpb24lMjBQRSUyMENBLTEo MikuY3J0MCYGCCsGAQUFBzABhhpodHRwOi8vb2NzcC5taXRyZS5vcmcvb2NzcDA+BgkrBgEEAYI3 FQcEMTAvBicrBgEEAYI3FQiDrqwjho6WV4GNiT2CpKsShb6uAYE2g9KXfYeg+0kCAWQCAQcwFgYD VR0gBA8wDTALBgkrBgEEAXMCAQgwNAYJKwYBBAGCNxUKBCcwJTAKBggrBgEFBQcDBDALBgkrBgEE AXMCAQcwCgYIKwYBBQUHAwIwDQYJKoZIhvcNAQEFBQADggIBAC2wqKo7QWQxIqnEKRznPrAQ5vQ9 X5JhB5keH8KMWu1W5n1RuSZH+3TYp4xccdYh+rV5b5+cJcWEYhtYpZriWm4kMHPaB6gKO9rbVfF9 R8Wp8sXvCKogbNhdkZwvXW4QymB1ASlMzDI1cCV8mzYgbIhWaCbV1zZBUVgOGa4LZIgdbdmgo5r/ O2gmnSftTYiE/tQ+DBs/25Bw/jC5HOiMXJqr+JctzJTqpEVLa7GKHnXWGuzGEPYkKBplxIyhz3Mv qc/yuKM7tZzAr8Qn5qf7VI9O2xp56QLjT2+mySOUR6Vml860FMpjjgZNMxAqOJt7OgY0PoUU9d18 yw1wiKSt0LUQoMcVvp7FifBjtBCG1sB/VOzxNvcNm6lO6EO23pvcjt6+WCG1X3pgnZ5UEohsM3c0 oLzYiuSYeVf85IO2yh9fWLWw2RGkf2szck1Xg0DsAQ54/YlZYyehELh43KbS3lpnTt8UlO7C0TMT 7JQwz4fTQg1a0e9rRPFnNDUG2fS2k3tz9IYILDB3F8uiZzzXptEzaYqzIqe5CK8ZGJQcw+w/CBen 6i+MV/y7yJmhio43Y1x9hIqoynqoSMV3CKYCoOwCvFUAGsNllDpExsQZoXrdd5gcuglqbh3t8wOM jtXDSQllQ/hXDZJf8rnH0wGx3K+WA+LKNvKqNCw9spEtsfG0MIIGYjCCBEqgAwIBAgIKFJcW0gAA AAAABDANBgkqhkiG9w0BAQsFADApMScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQRSBSb290 IENBLTEwHhcNMTEwNjE0MTc0NDQ0WhcNMTcwNjE0MTc1NDQ0WjBQMRMwEQYKCZImiZPyLGQBGRYD T1JHMRUwEwYKCZImiZPyLGQBGRYFTUlUUkUxIjAgBgNVBAMTGU1JVFJFIENvcnBvcmF0aW9uIFBF IENBLTEwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDSxK9RXieqdTz4JWRkRMs/EOuF 0P0S9SbspadLJkx/LDDnaAwmAnqfqm1n7/p82oVjy1yCye3SZu4Yp7fmDIAtWbkHvYOfxHkRv1ho /fhaNN0YRkd65oJJz2ngEbNZxdIiCoialQfX/iWU7ApQ+ovKbFV60v5E0p2mPncs20NYRfsaetdh nBZbFD9flDcXwJqSvGGGBfm7ifFCR1LrtEcNKjMwf7YEWZO0Vk3ZyhVq+k7JNLEbKv0OfBz8DU8G iGU+j88QlrgGW8PLkwNk7nsS/DJp8aLudTuVqIE2CA9mqn5QjU/EZYNHGzSfCr+/usUmbojyVSJu khhrAXspRAMz+Cia3yi3q3w8TnAljXWN1dhx1iuUv5GxyzMjfqK1tMuCUU2XzGNNqoVa1mqolBiy DTCOr9d/IC0YHYMBSpQ+xi0x9zjXKt4FmQmkEAZgF4hsZZqcJYL/iCQiwiz8fEyVPZuvoWvdEXOo zFYCpmkT0MZCJwyIux0Z6vJp6VLtN/6rZgc2y54HlTrp3ifazmpsfrk3NdHxlZTZug9kjEI+vEoy p/79nAPyTWQQ1MEP0ErCWav80/HOi0MLx/7lIUfvVOjkOFgFb+iDvR4T3RAQrnEpgTO+fc7Jyzh9 LpFDqm0slwDP4Hj9cC3IzdED5BU43PGAe+HoZ8OD/1ovVgwo/wIDAQABo4IBYzCCAV8wEAYJKwYB BAGCNxUBBAMCAQIwIwYJKwYBBAGCNxUCBBYEFFCiOtgZb+Zdflkw5sC2y01sUQaVMB0GA1UdDgQW BBRpZyAh1EjB0BsGbvMIKOI6gn1BMTAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTALBgNVHQ8E BAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAfBgNVHSMEGDAWgBRbh32f/my+Aunz4Ck6ilQlLJ84LzBQ BgNVHR8ESTBHMEWgQ6BBhj9odHRwOi8vcGtpLm1pdHJlLm9yZy9NSVRSRSUyMENvcnBvcmF0aW9u JTIwUEUlMjBSb290JTIwQ0EtMS5jcmwwWwYIKwYBBQUHAQEETzBNMEsGCCsGAQUFBzAChj9odHRw Oi8vcGtpLm1pdHJlLm9yZy9NSVRSRSUyMENvcnBvcmF0aW9uJTIwUEUlMjBSb290JTIwQ0EtMS5j cnQwDQYJKoZIhvcNAQELBQADggIBAHnDPfdYKxqNOtAYXMyyel83Vs8cCDAQZhSuIB0c6GkGoEdF rmWH9pwi42V96rCp7TvbNNKNJXbVHfJUAp+uqw663DL/sXXff9ZFxPxKOdPnpA8cKM7RBH9e437N w3d28A7PaGbP6tXmSqhXAhYZ4U12y1U5cOf2G/phUoAAMlnVJdfmXzMazvLo2SIeixAJyCze6rHQ TFQ/N+gAjbVuRJ+Hs8FEKVzMSwqlNoupe2ELqL4dMAKT6P08sAfxm2SrRlQvcWPYvqM/1C10bgc2 tdu+WGzRuP5Wx9Yr15KO9SW4z7fn2RVEXQgoDDno5vCIcfUPuKB5n+Kt9eBCitsgSD9yYsNUN9LE VIvjAb8MV2LWLfge1bumo6g7QMRa4Fgifw5siGwi7V2EaJQo6UAIVvxKKFC7W4p6CkrY2ga1d7GI Q0DPiWZOezOakJVAxL5gf+3WdNt0igKc/yLfbdHn6hCd1KPgDqkSKr8zWOZI/jiDBW957xAmaO6Q dGQDBZrQHWpIVwQGzF5bGrqms2kq49l3t7KmBu0C/9tExqKAmlf4Y5lfQGdCbKQpAq712DVQHYuD XmVQEAc2vlJ1C5hS3Iw9DwBWTfJ4vyB48buhBhbIhPiFta5OizXlKcsIi99ikA1yiZx/DBtjaw4J U6qJzWUFB2ecyGCNPtNbYjURA0A9MIIGfzCCBGegAwIBAgIKGsNq2wACAAA3+jANBgkqhkiG9w0B AQUFADBQMRMwEQYKCZImiZPyLGQBGRYDT1JHMRUwEwYKCZImiZPyLGQBGRYFTUlUUkUxIjAgBgNV BAMTGU1JVFJFIENvcnBvcmF0aW9uIFBFIENBLTEwHhcNMTIwMzEyMTUxODI3WhcNMTUwMzEyMTUx ODI3WjBKMQswCQYDVQQGEwJVUzEOMAwGA1UEChMFTUlUUkUxDzANBgNVBAsTBlBlb3BsZTEaMBgG A1UEAxMRQmFybnVtLlNlYW4uMzE1NDMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCW InZvCSslmSfSyhTVVSqnokCDajlsCNZHfUlkwkV1++2O71BYvMpjFHWR2XFIx963Hl63lFZzzVci OjIwLb1c/0YXhFfUdAvrbpjlu+ttlO05OEUW0h+5HO+qaebJPamxA00w0bokquRcPxUvwa3jiyL0 WfCwE3+/b5PCOW2xh7FXFKv262FnKIwxnQGXqkiXRP5D/SmdtcZSzxHkDThrhaiHPhJJhZ4XxwBk aGcAlMg8YH6uxshXm8e6c7XUu7gB5p+XThS0dqXujpQp/UQDp5t079+UrDcrpjfDBXIt9qCzLn26 uV5a4cD4xRKwA32f1cXFtiKXM0wYgUM3fEPDAgMBAAGjggJfMIICWzATBgNVHSUEDDAKBggrBgEF BQcDBDCBlAYJKoZIhvcNAQkPBIGGMIGDMA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DBAICAIAw BwYFKw4DAgcwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBLTALBglghkgBZQME ARYwCwYJYIZIAWUDBAEZMAsGCWCGSAFlAwQBAjALBglghkgBZQMEAQUwHQYDVR0OBBYEFIrbKa+E Rxo2/Sth2C6jZqZqvRE7MA4GA1UdDwEB/wQEAwIFIDAcBgNVHREEFTATgRFzYmFybnVtQG1pdHJl Lm9yZzAfBgNVHSMEGDAWgBRpZyAh1EjB0BsGbvMIKOI6gn1BMTBJBgNVHR8EQjBAMD6gPKA6hjho dHRwOi8vcGtpLm1pdHJlLm9yZy9NSVRSRSUyMENvcnBvcmF0aW9uJTIwUEUlMjBDQS0xLmNybDB/ BggrBgEFBQcBAQRzMHEwRwYIKwYBBQUHMAKGO2h0dHA6Ly9wa2kubWl0cmUub3JnL01JVFJFJTIw Q29ycG9yYXRpb24lMjBQRSUyMENBLTEoMikuY3J0MCYGCCsGAQUFBzABhhpodHRwOi8vb2NzcC5t aXRyZS5vcmcvb2NzcDA+BgkrBgEEAYI3FQcEMTAvBicrBgEEAYI3FQiDrqwjho6WV4GNiT2CpKsS hb6uAYE2hquSaISo7EUCAWQCAQ8wFgYDVR0gBA8wDTALBgkrBgEEAXMCAQgwGwYJKwYBBAGCNxUK BA4wDDAKBggrBgEFBQcDBDANBgkqhkiG9w0BAQUFAAOCAgEAGmmL43yA+J5lEockM1cxSoyxfSES HUGLVJyrhObbdFD4yO3jf0R4lHLuJlhp1486d9LRZAyzAnl9q8Zf3Tx1rl1kEd3pw0wMuO+ATscc rArEW/rJxjz6zTrNO3PFkFuOEdmKpHaRiFpuSX602INiBEBPluei3uZlWxHW9VqC7hz2diQpOlzS jtPMbL3o7ACjWaq7sQ0xB4rZ6oWyqOZEfHWQA1b7nFgL4nEbmEHNdU4jAjcxkROku4O04205kb5n Loveoz3TSQNt8zalFayZAjt+JEcKuG1f5cyhYI6QwvkS/3M+CjJezuNaSmno29Lm+ToZnwUm4nIB YkBx4r9ZDU2W8029tr5og00A5MGo1LK+unWtHBa7zuPblfSiYgXIHWU+OKrSFaA935Yb4fLXFe9S BmApBr1gohHYos1hct5q90WPufSKIQ9WT+vJYXvW3FpseO4ZLKVnJsO7gVoQEEnWJUwyABBPQrii F0gh++ApKZJROTuR36PsEEx4duI6U4VXMCiIcnEjvNR8Mt5Q/Vp4W4Mp5fCv+QzYkqq9EWD7QuUW Yul6R8Hf7ZTxbUk0NfJgu8escLrgQSwMdP/kE/09vJAAslQBkNnIS7iIhWt4l5XQJBrJc+6popRE R8ykWf25e4CliaUgbAl1tBQKivQ3tlX99WykI2XK3sTk9nsxggMjMIIDHwIBATBeMFAxEzARBgoJ kiaJk/IsZAEZFgNPUkcxFTATBgoJkiaJk/IsZAEZFgVNSVRSRTEiMCAGA1UEAxMZTUlUUkUgQ29y cG9yYXRpb24gUEUgQ0EtMQIKGsNtyAACAAA3/DAJBgUrDgMCGgUAoIIBmjAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjA0MTcwMzE0MTJaMCMGCSqGSIb3DQEJBDEW BBS6PGbfJaQSbUFP5tSYZkxr8MMGXzBbBgkqhkiG9w0BCQ8xTjBMMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMC GjBtBgkrBgEEAYI3EAQxYDBeMFAxEzARBgoJkiaJk/IsZAEZFgNPUkcxFTATBgoJkiaJk/IsZAEZ FgVNSVRSRTEiMCAGA1UEAxMZTUlUUkUgQ29ycG9yYXRpb24gUEUgQ0EtMQIKGsNq2wACAAA3+jBv BgsqhkiG9w0BCRACCzFgoF4wUDETMBEGCgmSJomT8ixkARkWA09SRzEVMBMGCgmSJomT8ixkARkW BU1JVFJFMSIwIAYDVQQDExlNSVRSRSBDb3Jwb3JhdGlvbiBQRSBDQS0xAgoaw2rbAAIAADf6MA0G CSqGSIb3DQEBAQUABIIBABSeDhgYsEWq3Tg5fbNfccadfDni4D9kcCYYbTcyBJbAcIheiuNZQG8l kunqbsWuVd28aH1MymHziA2IDkBJtX8eGtwwN08jKaUsBuOAmi9V62trT8JhhsISzWPW4cmu+6Yz PRHTorB/Zr7TDaJCsC68UlJ01s9e/SZWHXaeAYWj3SWyNu+ksosNgBP3LeTOnvQMhnpIH+bQnAbV 5zNUcAsvEgPAlZWrjfSHeckNAnLxQkG77bdfSTdoWSslA/bcY5a8yhEGRCEscSEfI76D6XIWWy/N KyG8RbVH1r1Tz/8ZkJMUE7e6o0uoW6mRerfgnKe5pNyLPUwGlrONT5f+htkAAAAAAAA= ------=_NextPart_000_003A_01CD1C26.A2A48B80-- From sbarnum@mitre.org Mon Apr 16 20:29:16 2012 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 1160221F8581; Mon, 16 Apr 2012 20:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mIMSrriailwK; Mon, 16 Apr 2012 20:29:09 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 4129821F8585; Mon, 16 Apr 2012 20:29:09 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id C3E0521B0E26; Mon, 16 Apr 2012 23:29:08 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id A008921B0E23; Mon, 16 Apr 2012 23:29:08 -0400 (EDT) Received: from IMCMBX03.MITRE.ORG ([169.254.3.179]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.02.0283.003; Mon, 16 Apr 2012 23:29:08 -0400 From: "Barnum, Sean D." To: "Omar Santos (osantos)" , Luis Nunez Thread-Topic: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe website Thread-Index: AQHNHC91EoahZz2AEEqd+yKyGmroMJaeWIaQ Date: Tue, 17 Apr 2012 03:29:07 +0000 Message-ID: <7F48813B48558A4BB5CB7BB714E5B5A9171B16@IMCMBX03.MITRE.ORG> References: <7F48813B48558A4BB5CB7BB714E5B5A91706E3@IMCMBX03.MITRE.ORG> <870A23D4-BA94-4431-B613-F3D7734B8DB5@c3isecurity.com> <953A2E460DBE7C43AC13E30B87C5B4FF080A1BAD@XMB-RCD-106.cisco.com> In-Reply-To: <953A2E460DBE7C43AC13E30B87C5B4FF080A1BAD@XMB-RCD-106.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.31.136.182] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0042_01CD1C28.B47EA280" MIME-Version: 1.0 Cc: "idxwg@nicwg.org" , "mile@ietf.org" , "dallendoug@gmail.com" , "sacm@ietf.org" , "m-terada@ipa.go.jp" Subject: Re: [mile] [sacm] CybOX v1.0 (Draft) is now released and live onthe website 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, 17 Apr 2012 03:29:16 -0000 ------=_NextPart_000_0042_01CD1C28.B47EA280 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0043_01CD1C28.B47EA280" ------=_NextPart_001_0043_01CD1C28.B47EA280 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thanks Omar. To answer your question, first let me point out to other readers that the two entries that Omar is quoting here exist as values in an enumeration called EventTypeEnum which as its name implies contains a list of different labels for grouping types (or classes) of events to be used as low-granularity buckets for characterizing and classifying events. Other entries in this enumeration include things like "File Ops (CRUD)", "Process Mgt", "Authorization (ACL)", etc. The "Packet Traffic" value is intended to characterize events dealing with network packet traffic as its name implies. The "Data Flow" value is intended to characterize events dealing with forms of data flow at a higher level of abstraction than just packet traffic. The relationship between these two values could be viewed as "Packet Traffic" being a more detailed form of "Data Flow" just as the values "App Layer Traffic" and "HTTP Layer Traffic", also in this enumeration, could be other levels in this same abstraction stack. The idea behind the varying levels of abstraction is to leave buckets large enough to capture a wide variety of potential event types (e.g. data flow events other than obvious things like packet traffic) but also enable the use of smaller more specific buckets when they are appropriate and commonly used. Does this make sense? sean From: Omar Santos (osantos) [mailto:osantos@cisco.com] Sent: Monday, April 16, 2012 8:17 PM To: Luis Nunez; Barnum, Sean D. Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; m-terada@ipa.go.jp Subject: RE: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe website I echo Luis' comments. It is good to see the inclusion of network objects. Quick question to the team related to your netflow comment. I am looking at: http://cybox.mitre.org/XMLSchema/cybox_core_v1.0%28draft%29.xsd . and it looks that we renamed it to "Data Flow"? Specifies the class of events dealing with data flow. What is the difference between that and "Packet Traffic"? Specifies the class of events dealing with packet traffic. Regards, Omar Santos Incident Manager, PSIRT Security Research and Operations Cisco Systems, Inc. Email: os@cisco.com Phone: +1 919 392 8635 PGP Key: 0x3AF27EDC Cisco.com - http://www.cisco.com Cisco Security Advisories and Notices - http://www.cisco.com/go/psirt This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message. For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Luis Nunez Sent: Monday, April 16, 2012 6:44 PM To: Barnum, Sean D. Cc: idxwg@nicwg.org; mile@ietf.org; Doug Wilson (dallendoug@gmail.com); sacm@ietf.org; IPA-Masato Terada (m-terada@ipa.go.jp) Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe website I like the inclusion of the network-centric objects. IPFIX (netflow) will add an additional perspective from an incident information sharing standpoint. -ln On Apr 16, 2012, at 4:04 PM, Barnum, Sean D. wrote: Hey everyone, I just wanted to let you all know that CybOX v1.0 (Draft) content is now live on the website. http://cybox.mitre.org The release notes are provided inline below. The key items of note are: . The release of two formal specifications for the CybOX language (one for the core language and one for the defined objects) . The XML Schema has gone through extensive improvements for expressiveness, clarity, consistency, efficiency, alignment to existing normative references and documentation. . This release includes an initial set of language utilities: a draft Snort -> CybOX transform, a draft OpenIOC -> CybOX transform, and a set of Python bindings for the CybOX language. . The website now includes a small set of content examples. This set will grow going forward. This release involved a lot of hard work from a diverse group of people. Thank you all for your contributions and effort. We could not have done it without you. We look forward to everyone's feedback and collaboration as we continue to improve and mature the CybOX language. Sean Barnum CybOX v1.0 (Draft) Release Notes The Version 1.0 (Draft) release of Cyber Observable eXpression (CybOXT) is intended as a draft release of an initial major version of the CybOX Language that could be utilized for practical operational use and integration into other standards efforts. This release consists of three primary components: a pair of formal language specifications for the core language content and defined objects content, a set of language implementation XML schemas (core, common_types, and ~70 defined object schemas), and a small initial set of language utilities including an initial draft Snort->CybOX transform, an initial draft OpenIOC->CybOX transform and a set of CybOX language Python bindings. Recognizing that this is the first time that the formal language specifications will be available for review and as such will likely generate feedback from new stakeholders, this initial major version is being released as a "draft" v1.0 with the expectation of cycles of new feedback and revision before a "final" v1.0 is released. The CybOX v1.0 (Draft) XML schemas include a significant number of changes from v0.7 to improve: . Clarity, documentation, and descriptive formality for reference and implementation by other standards and users. . Consistency, simplicity, and efficiency. . Alignment (as appropriate) to existing normative references. . Expressiveness of the schema to better support the broad set of use cases it targets (malware characterization, indicator and incident data sharing, event management, etc.) including the addition of an initial set of network-related defined objects. Summary of changes from CybOX_v0.7 to CybOX_v1.0_(Draft): . Refinement of namespaces and schema locations for better effectiveness and flexibility going forward. . Normalized all content according to an established set of naming conventions. . Fully annotated all language items (types, attributes, elements, etc.). . Moved several commonly leveraged types out of the core schema and into common_types. . Achieved full typing of entire schema structure such that all attributes and elements are definitively typed. . Changed all identifiers from ID and IDREF types to be QNames enabling globally unique identifiers and flexibility for domain-specific users of CybOX to define their own identifier syntax locally. . Reordered attributes and elements in numerous types to better reflect common usage and priority. . Added major_version and minor_version attributes for core schema. . Added capability to characterize source of overall observable package data and for individual observables. . Modified the logical composition structure such that any such compositions are now contained within a Observable_Composition element providing improved simplicity and modularity. . Removed the Delta element from ObservableType and relocated the appropriate portions (Change, Trend, and Frequency) to appropriate locations under Stateful_Measure and Event. . Added a Domain_Specific_Object_Attributes field to Object utilizing an abstract type that will allow domain-specific use cases to add in their own domain-specific attributes for Objects. . Added a Tool-Specific_Data field to ToolInformationType utilizing an abstract type that will allow addition of tool-specific data. . Added an Indicators field to MeasureSourceType utilizing an abstract type that will allow characterizing differing formats or standards of indicators that may have led to the identification of the observable data. . Enhanced the Hash structure to capture full fuzzy hashes in addition to simple hashes . Added a new ExtractedFeaturesType that can be used to adorn differing objects (e.g., files, memory, etc.) to capture extracted strings, imports, functions and code snippets . Added a ByteRunsType to enable capture of byte runs within various objects. . Added object_reference attribute to DefinedObjectType to better support referencing of independently defined Objects from within another Object definition. . Added a generic DataSegmentType to provide a relatively abstract way of characterizing data segments that may be written/read/transmitted or otherwise utilized in actions or defined in objects. . Added several new defined object schemas (API, Code, Device, DNS_Record, Network_Flow, Network_Packet, Network_Route_Entry, Network_Subnet, Unix_Network_Route_Entry) including an initial set of network-centric defined objects. . Modified every defined object schema with added annotations as well as minor and in some cases substantive changes to fix errors, improve consistency and alignment with existing normative references, and to improve expressiveness in support of the targeted use cases. Detailed changes from CybOX_v0.7 to CybOX_v1.0_(Draft): The level of changes within v1.0 (Draft) in the core schema, common_types and the defined object schemas is too great to list every change in these release notes. Detailed difference reports are available for each individual schema at: http://cybox.mitre.org/XMLSchema/release_notes/cybox_v1.0(draft)_diff_report s.zip =============================================== Sean Barnum Cyber Security Principal The MITRE Corporation Email: sbarnum@mitre.org _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile ------=_NextPart_001_0043_01CD1C28.B47EA280 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks Omar.

 

To answer your question, first let me point out to other readers that = the two entries that Omar is quoting here exist as values in an = enumeration called EventTypeEnum which as its name implies contains a = list of different labels for grouping types (or classes) of events to be = used as low-granularity buckets for characterizing and classifying = events.

Other entries in this enumeration include things like “File Ops = (CRUD)”, “Process Mgt”, “Authorization = (ACL)”, etc.

 

The “Packet Traffic” value is intended to characterize = events dealing with network packet traffic as its name = implies.

The “Data Flow” value is intended to characterize events = dealing with forms of data flow at a higher level of abstraction than = just packet traffic. The relationship between these two values could be = viewed as “Packet Traffic” being a more detailed form of = “Data Flow” just as the values “App Layer = Traffic” and “HTTP Layer Traffic”, also in this = enumeration, could be other levels in this same abstraction = stack.

The idea behind the varying levels of abstraction is to leave =  buckets large enough to capture a wide variety of potential event = types (e.g. data flow events other than obvious things like packet = traffic) but also enable the use of smaller more specific buckets when = they are appropriate and commonly used.

 

Does this make sense?

 

sean

 

From:= = Omar Santos (osantos) [mailto:osantos@cisco.com]
Sent: = Monday, April 16, 2012 8:17 PM
To: Luis Nunez; Barnum, Sean = D.
Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; = sacm@ietf.org; m-terada@ipa.go.jp
Subject: RE: [sacm] [mile] = CybOX v1.0 (Draft) is now released and live onthe = website

 

I echo Luis’ comments. It is good to see the inclusion of = network objects. Quick question to the team related to your netflow = comment.

 

I am looking at:

= http://cybox.mitre.org/XMLSchema/cybox_core_v1.0%28draft%29.xsd<= /o:p>

 

… and it looks that we renamed it to “Data = Flow”?

 

<xs:enumeration = value=3D"Data Flow">

   = <xs:annotation>

        = <xs:documentation>Specifies the class of events dealing with data = flow.</xs:documentation>

   = </xs:annotation>

</xs:enumeration>

 

 

What is the difference between that and “Packet = Traffic”?

 

<xs:enumeration value=3D"Packet =
Traffic">
   =
<xs:annotation>
     =
<xs:documentation>Specifies the class of events dealing with =
packet traffic.</xs:documentation>
   =
</xs:annotation>
</xs:enumeration>

 

 

 

 

Regards,

Omar Santos
Incident Manager, = PSIRT
Security Research and Operations
Cisco Systems, = Inc.
Email: os@cisco.com
Phone: +1 919 392 = 8635
PGP Key: 0x3AF27EDC

Cisco.com - http://www.cisco.com
Cisco Security = Advisories and Notices - http://www.cisco.com/go/psirt<= br>
This email may contain confidential and privileged material for = the sole
use of the intended recipient. Any review, use, distribution = or
disclosure by others is strictly prohibited. If you are not the = intended
recipient (or authorized to receive for the recipient), = please contact
the sender by reply email and delete all copies of = this message.

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html=

 

From:= = sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.= org] On Behalf Of Luis Nunez
Sent: Monday, April = 16, 2012 6:44 PM
To: Barnum, Sean D.
Cc: idxwg@nicwg.org; mile@ietf.org; Doug Wilson (dallendoug@gmail.com); sacm@ietf.org; IPA-Masato Terada (m-terada@ipa.go.jp)
Subject:= Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe = website

 

I like the inclusion of the network-centric = objects.  IPFIX (netflow)  will add an additional perspective = from an incident information sharing standpoint. =  

 

-ln

 

On Apr 16, 2012, at 4:04 = PM, Barnum, Sean D. wrote:

 

Hey = everyone,

 =

I just = wanted to let you all know that CybOX v1.0 (Draft) content is now live = on the website. http://cybox.mitre.org

The = release notes are provided inline = below.

The key = items of note are:

·        The = release of two formal specifications for the CybOX language (one for the = core language and one for the defined = objects)

·        The XML = Schema has gone through extensive improvements for expressiveness, = clarity, consistency, efficiency, alignment to existing normative = references and documentation.

·        This = release includes an initial set of language utilities: a draft Snort = -> CybOX transform, a draft OpenIOC -> CybOX transform, and a set = of Python bindings for the CybOX language.

·        The = website now includes a small set of content examples. This set will grow = going forward.

This = release involved a lot of hard work from a diverse group of people. = Thank you all for your contributions and effort. We could not have done = it without you.

We look = forward to everyone’s feedback and collaboration as we continue to = improve and mature the CybOX = language.

 =

Sean = Barnum

 =

 =

 =

CybOX v1.0 (Draft) Release = Notes

The Version 1.0 (Draft) release of Cyber = Observable eXpression (CybOX™) is intended as a draft release of an initial major version of = the CybOX Language that could be utilized for practical operational use = and integration into other standards efforts. This release consists of = three primary components: a pair of formal language specifications for = the core language content and defined objects content, a set of language = implementation XML schemas (core, common_types, and ~70 defined object = schemas), and a small initial set of language utilities including an = initial draft Snort->CybOX transform, an initial draft = OpenIOC->CybOX transform and a set of CybOX language Python bindings. = Recognizing that this is the first time that the formal language = specifications will be available for review and as such will likely = generate feedback from new stakeholders, this initial major version is = being released as a “draft” v1.0 with the expectation of = cycles of new feedback and revision before a “final” v1.0 is = released.=

The CybOX v1.0 (Draft) XML schemas include a = significant number of changes from v0.7 to improve:=

·       Clarity, = documentation, and descriptive formality for reference and = implementation by other standards and users.=

·       Consistency, = simplicity, and efficiency.=

·       Alignment (as = appropriate) to existing normative references.=

·       Expressiveness of the = schema to better support the broad set of use cases it targets (malware = characterization, indicator and incident data sharing, event management, = etc.) including the addition of an initial set of network-related = defined objects.=

Summary = of changes from CybOX_v0.7 to CybOX_v1.0_(Draft):=

·        = Refinement of namespaces and schema = locations for better effectiveness and flexibility going forward.=

·        = Normalized all content according to an = established set of naming conventions.=

·        = Fully annotated all language items = (types, attributes, elements, etc.).=

·        = Moved several commonly leveraged types = out of the core schema and into common_types.=

·        = Achieved full typing of entire schema = structure such that all attributes and elements are definitively = typed.=

·        = Changed all identifiers from ID and IDREF = types to be QNames enabling globally unique identifiers and flexibility = for domain-specific users of CybOX to define their own identifier syntax = locally.=

·        = Reordered attributes and elements in = numerous types to better reflect common usage and priority.=

·        = Added major_version and minor_version = attributes for core schema.=

·        = Added capability to characterize source = of overall observable package data and for individual observables.=

·        = Modified the logical composition = structure such that any such compositions are now contained within a = Observable_Composition element providing improved simplicity and = modularity.=

·        = Removed the Delta element from = ObservableType and relocated the appropriate portions (Change, Trend, = and Frequency) to appropriate locations under Stateful_Measure and = Event.=

·        = Added a Domain_Specific_Object_Attributes = field to Object utilizing an abstract type that will allow = domain-specific use cases to add in their own domain-specific attributes = for Objects.=

·        = Added a Tool-Specific_Data field to = ToolInformationType utilizing an abstract type that will allow addition = of tool-specific data.=

·        = Added an Indicators field to = MeasureSourceType utilizing an abstract type that will allow = characterizing differing formats or standards of indicators that may = have led to the identification of the observable data.=

·        = Enhanced the Hash structure to capture = full fuzzy hashes in addition to simple hashes=

·        = Added a new ExtractedFeaturesType that = can be used to adorn differing objects (e.g., files, memory, etc.) to = capture extracted strings, imports, functions and code snippets=

·        = Added a ByteRunsType to enable capture of = byte runs within various objects.=

·        = Added object_reference attribute to = DefinedObjectType to better support referencing of independently defined = Objects from within another Object definition.=

·        = Added a generic DataSegmentType to = provide a relatively abstract way of characterizing data segments that = may be written/read/transmitted or otherwise utilized in actions or = defined in objects.=

·        Added several new = defined object schemas (API, Code, Device, DNS_Record, Network_Flow, = Network_Packet, Network_Route_Entry, Network_Subnet, = Unix_Network_Route_Entry) including an initial set of network-centric = defined objects.

·        = Modified every defined object schema with = added annotations as well as minor and in some cases substantive changes = to fix errors, improve consistency and alignment with existing normative = references, and to improve expressiveness in support of the targeted use = cases.=

Detailed changes from CybOX_v0.7 to = CybOX_v1.0_(Draft):=

The level of changes within v1.0 (Draft) in = the core schema, common_types and the defined object schemas is too = great to list every change in these release notes. Detailed difference = reports are available for each individual schema at:http://cybox.mitre.org/XMLSchema/release_notes/cybox_v1.0= (draft)_diff_reports.zip

 =

 =

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

Sean Barnum=

Cyber Security Principal=

The MITRE Corporation=

 =

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

 

------=_NextPart_001_0043_01CD1C28.B47EA280-- ------=_NextPart_000_0042_01CD1C28.B47EA280 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYNDCCBS0w ggMVoAMCAQICEEw6UhQhT9OgRBVHf7KQ+1AwDQYJKoZIhvcNAQELBQAwKTEnMCUGA1UEAxMeTUlU UkUgQ29ycG9yYXRpb24gUEUgUm9vdCBDQS0xMB4XDTExMDQyNjE5NDU0NVoXDTIxMDQyNjE5NDgy MlowKTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUEUgUm9vdCBDQS0xMIICIjANBgkqhkiG 9w0BAQEFAAOCAg8AMIICCgKCAgEAtp8hR0hRq3im+Alwfb5ZHGP5k2OSY2TlVHYHIMUDH3MfW7b6 8lB3j3MwAMsxGK1ke/t6O4K0t9wRH4QDgOQ1CthmOGZW7xiN81h0vP1Yf14SNugUa7ZvH9KP3iXs y8QnOHal1bKf0Pa9KXib58qUuwfaZSCTW5P2ekqd8z4TETvfBWvPgDxyxnVsiAO6yL9WaRpMiSVM hYLWy3KRuU/gue0bVEi+qdg+hENh1NSNXpoqseS262nq5cx5wybR/PF0YstQ9NNlYDM5cLECKYHH zD6cXKJozuFXriswlE8rdna7VaxyZrfgC0ueEIY/tsj/65IyUhyPBwO0ZpW+Ls9Cd4Y+ERSu5mR5 Fd8w42eVzuosmk3s3AxrKC+Z4tXYkjaiWUduIegAiST1vJBwkS53vR+zrBX3Ep56l7MFVvW/GcsZ 9wUT2HG65JOeiVc2YzCEqLgQ3ZCBHn09oBag2lnMac+E2sKm9aKL3xzHs6cyD8qCJK9O8QLCqo3C mzASlOwtTFiLYgpPW/MSmgYOt9JrwHAzk97DHFKTFttjrXGMmhMVzadt1EjMn1Wv8t5WLBI0qSoX /MYi2CaeiDsEiWRu9Nmpu3pmi8m7tIR9csdbAVPks2soNMWOopGEpFQSDvU1+m77v2jIKQKYxYmN 2zUOJ4TJFL1osnZ/71MmLCDVd+ECAwEAAaNRME8wCwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMB Af8wHQYDVR0OBBYEFFuHfZ/+bL4C6fPgKTqKVCUsnzgvMBAGCSsGAQQBgjcVAQQDAgEAMA0GCSqG SIb3DQEBCwUAA4ICAQAy78sXsP/eqHH8/uOYyxQ6TBDhkCBxNoy8MF2c9UDns5ADL1qyxPAlpDBs L+2h1Zzt3FvPjg0SoRE/9juyG1qxMzhlv0jdQx12tESdo3uBb61b1uuc4H/VxCJWDI4KZL/B53EI 8HGPjUBdLADgOmG99uffm5uarSkjtIX//Bz3U6QfzTPlVWFi4SmzRI2mp16GQ8RPuJ/WMloaAn8X H6EjS2oLjGZC8Pw8/C46W48NvZ1JZTrZvYZr7GmuvmplYK68SZv/T5Su+FlLRTy9uNXQLHtm6jKv nDH2yB66zTwfaDpnjILnrC2O7ANRVZc0KywiKiW3nB7Joq74/XVuMI1PiSByt2Qu+RIS/WAI5wMi bTmwSiBxQZqvuth+dXoakJyOP2Wg5jvL55v9RLZhDqMtRI5ovnOFvTgNJQqNPSekGtA+m6Ctl/vh kSg65FFCMhaSkn7vY2Il+R8HouWJN8wTaudeexnyHcD+Mlt8QaB5CErpDjeeGZfQ0FcYm+6TtlMz Dw5eFhT/J6QrABCxfgLkVFHurMcQD4JkmXXkq5bP+GNkY0Uy2LMbw/UD94OEV1LpfAqUkT+mu5Yb vxg+elFtsad+Ix8owW372xynIADh9q1bHm+j1OHPJmGALWK9miRpC4t3isfu3ZB0QpI/e2Po6MED 393Jb0YbzrcElFv6ZDCCBhYwggP+oAMCAQICChrDbcgAAgAAN/wwDQYJKoZIhvcNAQEFBQAwUDET MBEGCgmSJomT8ixkARkWA09SRzEVMBMGCgmSJomT8ixkARkWBU1JVFJFMSIwIAYDVQQDExlNSVRS RSBDb3Jwb3JhdGlvbiBQRSBDQS0xMB4XDTEyMDMxMjE1MTgyN1oXDTE1MDMxMjE1MTgyN1owSjEL MAkGA1UEBhMCVVMxDjAMBgNVBAoTBU1JVFJFMQ8wDQYDVQQLEwZQZW9wbGUxGjAYBgNVBAMTEUJh cm51bS5TZWFuLjMxNTQzMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA9/I6RU7OcouL 6lcEJMAg8G3myNbQu84QnflS8p3PWOjgC6P50RDqGX5UxelDqMQPN5IsNYRXVY9/b7yN/RSH4goI JfYKMitndKuCKz1q38Nh0YycEm5x2t/IN/60b01T1uOmhZfptLDoDzj0UQZwMQ19mhM/ldsrC8bR GGuHXdQVaSyXygfhzNhqC06vZo5fvCBUJ6z7JtVrfRTHdudg19JYK+gds9p+Lvp/DOEXQmgpfpMl jfNKMnrG+kPMMngrIJUsF5lcbhHuc5mO+O8eR8FxM2KF7gfKVmUmZxs7Y6uLenVJVEmllP0XgUu1 sv3bClFgUo5x5Aq6rXshtHuVuQIDAQABo4IB9jCCAfIwKAYDVR0lBCEwHwYIKwYBBQUHAwQGCSsG AQQBcwIBBwYIKwYBBQUHAwIwHQYDVR0OBBYEFDvU1Ph/OVxGkxRmwvRx1TBf5PKqMA4GA1UdDwEB /wQEAwIGwDAcBgNVHREEFTATgRFzYmFybnVtQG1pdHJlLm9yZzAfBgNVHSMEGDAWgBRpZyAh1EjB 0BsGbvMIKOI6gn1BMTBJBgNVHR8EQjBAMD6gPKA6hjhodHRwOi8vcGtpLm1pdHJlLm9yZy9NSVRS RSUyMENvcnBvcmF0aW9uJTIwUEUlMjBDQS0xLmNybDB/BggrBgEFBQcBAQRzMHEwRwYIKwYBBQUH MAKGO2h0dHA6Ly9wa2kubWl0cmUub3JnL01JVFJFJTIwQ29ycG9yYXRpb24lMjBQRSUyMENBLTEo MikuY3J0MCYGCCsGAQUFBzABhhpodHRwOi8vb2NzcC5taXRyZS5vcmcvb2NzcDA+BgkrBgEEAYI3 FQcEMTAvBicrBgEEAYI3FQiDrqwjho6WV4GNiT2CpKsShb6uAYE2g9KXfYeg+0kCAWQCAQcwFgYD VR0gBA8wDTALBgkrBgEEAXMCAQgwNAYJKwYBBAGCNxUKBCcwJTAKBggrBgEFBQcDBDALBgkrBgEE AXMCAQcwCgYIKwYBBQUHAwIwDQYJKoZIhvcNAQEFBQADggIBAC2wqKo7QWQxIqnEKRznPrAQ5vQ9 X5JhB5keH8KMWu1W5n1RuSZH+3TYp4xccdYh+rV5b5+cJcWEYhtYpZriWm4kMHPaB6gKO9rbVfF9 R8Wp8sXvCKogbNhdkZwvXW4QymB1ASlMzDI1cCV8mzYgbIhWaCbV1zZBUVgOGa4LZIgdbdmgo5r/ O2gmnSftTYiE/tQ+DBs/25Bw/jC5HOiMXJqr+JctzJTqpEVLa7GKHnXWGuzGEPYkKBplxIyhz3Mv qc/yuKM7tZzAr8Qn5qf7VI9O2xp56QLjT2+mySOUR6Vml860FMpjjgZNMxAqOJt7OgY0PoUU9d18 yw1wiKSt0LUQoMcVvp7FifBjtBCG1sB/VOzxNvcNm6lO6EO23pvcjt6+WCG1X3pgnZ5UEohsM3c0 oLzYiuSYeVf85IO2yh9fWLWw2RGkf2szck1Xg0DsAQ54/YlZYyehELh43KbS3lpnTt8UlO7C0TMT 7JQwz4fTQg1a0e9rRPFnNDUG2fS2k3tz9IYILDB3F8uiZzzXptEzaYqzIqe5CK8ZGJQcw+w/CBen 6i+MV/y7yJmhio43Y1x9hIqoynqoSMV3CKYCoOwCvFUAGsNllDpExsQZoXrdd5gcuglqbh3t8wOM jtXDSQllQ/hXDZJf8rnH0wGx3K+WA+LKNvKqNCw9spEtsfG0MIIGYjCCBEqgAwIBAgIKFJcW0gAA AAAABDANBgkqhkiG9w0BAQsFADApMScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQRSBSb290 IENBLTEwHhcNMTEwNjE0MTc0NDQ0WhcNMTcwNjE0MTc1NDQ0WjBQMRMwEQYKCZImiZPyLGQBGRYD T1JHMRUwEwYKCZImiZPyLGQBGRYFTUlUUkUxIjAgBgNVBAMTGU1JVFJFIENvcnBvcmF0aW9uIFBF IENBLTEwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDSxK9RXieqdTz4JWRkRMs/EOuF 0P0S9SbspadLJkx/LDDnaAwmAnqfqm1n7/p82oVjy1yCye3SZu4Yp7fmDIAtWbkHvYOfxHkRv1ho /fhaNN0YRkd65oJJz2ngEbNZxdIiCoialQfX/iWU7ApQ+ovKbFV60v5E0p2mPncs20NYRfsaetdh nBZbFD9flDcXwJqSvGGGBfm7ifFCR1LrtEcNKjMwf7YEWZO0Vk3ZyhVq+k7JNLEbKv0OfBz8DU8G iGU+j88QlrgGW8PLkwNk7nsS/DJp8aLudTuVqIE2CA9mqn5QjU/EZYNHGzSfCr+/usUmbojyVSJu khhrAXspRAMz+Cia3yi3q3w8TnAljXWN1dhx1iuUv5GxyzMjfqK1tMuCUU2XzGNNqoVa1mqolBiy DTCOr9d/IC0YHYMBSpQ+xi0x9zjXKt4FmQmkEAZgF4hsZZqcJYL/iCQiwiz8fEyVPZuvoWvdEXOo zFYCpmkT0MZCJwyIux0Z6vJp6VLtN/6rZgc2y54HlTrp3ifazmpsfrk3NdHxlZTZug9kjEI+vEoy p/79nAPyTWQQ1MEP0ErCWav80/HOi0MLx/7lIUfvVOjkOFgFb+iDvR4T3RAQrnEpgTO+fc7Jyzh9 LpFDqm0slwDP4Hj9cC3IzdED5BU43PGAe+HoZ8OD/1ovVgwo/wIDAQABo4IBYzCCAV8wEAYJKwYB BAGCNxUBBAMCAQIwIwYJKwYBBAGCNxUCBBYEFFCiOtgZb+Zdflkw5sC2y01sUQaVMB0GA1UdDgQW BBRpZyAh1EjB0BsGbvMIKOI6gn1BMTAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTALBgNVHQ8E BAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAfBgNVHSMEGDAWgBRbh32f/my+Aunz4Ck6ilQlLJ84LzBQ BgNVHR8ESTBHMEWgQ6BBhj9odHRwOi8vcGtpLm1pdHJlLm9yZy9NSVRSRSUyMENvcnBvcmF0aW9u JTIwUEUlMjBSb290JTIwQ0EtMS5jcmwwWwYIKwYBBQUHAQEETzBNMEsGCCsGAQUFBzAChj9odHRw Oi8vcGtpLm1pdHJlLm9yZy9NSVRSRSUyMENvcnBvcmF0aW9uJTIwUEUlMjBSb290JTIwQ0EtMS5j cnQwDQYJKoZIhvcNAQELBQADggIBAHnDPfdYKxqNOtAYXMyyel83Vs8cCDAQZhSuIB0c6GkGoEdF rmWH9pwi42V96rCp7TvbNNKNJXbVHfJUAp+uqw663DL/sXXff9ZFxPxKOdPnpA8cKM7RBH9e437N w3d28A7PaGbP6tXmSqhXAhYZ4U12y1U5cOf2G/phUoAAMlnVJdfmXzMazvLo2SIeixAJyCze6rHQ TFQ/N+gAjbVuRJ+Hs8FEKVzMSwqlNoupe2ELqL4dMAKT6P08sAfxm2SrRlQvcWPYvqM/1C10bgc2 tdu+WGzRuP5Wx9Yr15KO9SW4z7fn2RVEXQgoDDno5vCIcfUPuKB5n+Kt9eBCitsgSD9yYsNUN9LE VIvjAb8MV2LWLfge1bumo6g7QMRa4Fgifw5siGwi7V2EaJQo6UAIVvxKKFC7W4p6CkrY2ga1d7GI Q0DPiWZOezOakJVAxL5gf+3WdNt0igKc/yLfbdHn6hCd1KPgDqkSKr8zWOZI/jiDBW957xAmaO6Q dGQDBZrQHWpIVwQGzF5bGrqms2kq49l3t7KmBu0C/9tExqKAmlf4Y5lfQGdCbKQpAq712DVQHYuD XmVQEAc2vlJ1C5hS3Iw9DwBWTfJ4vyB48buhBhbIhPiFta5OizXlKcsIi99ikA1yiZx/DBtjaw4J U6qJzWUFB2ecyGCNPtNbYjURA0A9MIIGfzCCBGegAwIBAgIKGsNq2wACAAA3+jANBgkqhkiG9w0B AQUFADBQMRMwEQYKCZImiZPyLGQBGRYDT1JHMRUwEwYKCZImiZPyLGQBGRYFTUlUUkUxIjAgBgNV BAMTGU1JVFJFIENvcnBvcmF0aW9uIFBFIENBLTEwHhcNMTIwMzEyMTUxODI3WhcNMTUwMzEyMTUx ODI3WjBKMQswCQYDVQQGEwJVUzEOMAwGA1UEChMFTUlUUkUxDzANBgNVBAsTBlBlb3BsZTEaMBgG A1UEAxMRQmFybnVtLlNlYW4uMzE1NDMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCW InZvCSslmSfSyhTVVSqnokCDajlsCNZHfUlkwkV1++2O71BYvMpjFHWR2XFIx963Hl63lFZzzVci OjIwLb1c/0YXhFfUdAvrbpjlu+ttlO05OEUW0h+5HO+qaebJPamxA00w0bokquRcPxUvwa3jiyL0 WfCwE3+/b5PCOW2xh7FXFKv262FnKIwxnQGXqkiXRP5D/SmdtcZSzxHkDThrhaiHPhJJhZ4XxwBk aGcAlMg8YH6uxshXm8e6c7XUu7gB5p+XThS0dqXujpQp/UQDp5t079+UrDcrpjfDBXIt9qCzLn26 uV5a4cD4xRKwA32f1cXFtiKXM0wYgUM3fEPDAgMBAAGjggJfMIICWzATBgNVHSUEDDAKBggrBgEF BQcDBDCBlAYJKoZIhvcNAQkPBIGGMIGDMA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DBAICAIAw BwYFKw4DAgcwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBLTALBglghkgBZQME ARYwCwYJYIZIAWUDBAEZMAsGCWCGSAFlAwQBAjALBglghkgBZQMEAQUwHQYDVR0OBBYEFIrbKa+E Rxo2/Sth2C6jZqZqvRE7MA4GA1UdDwEB/wQEAwIFIDAcBgNVHREEFTATgRFzYmFybnVtQG1pdHJl Lm9yZzAfBgNVHSMEGDAWgBRpZyAh1EjB0BsGbvMIKOI6gn1BMTBJBgNVHR8EQjBAMD6gPKA6hjho dHRwOi8vcGtpLm1pdHJlLm9yZy9NSVRSRSUyMENvcnBvcmF0aW9uJTIwUEUlMjBDQS0xLmNybDB/ BggrBgEFBQcBAQRzMHEwRwYIKwYBBQUHMAKGO2h0dHA6Ly9wa2kubWl0cmUub3JnL01JVFJFJTIw Q29ycG9yYXRpb24lMjBQRSUyMENBLTEoMikuY3J0MCYGCCsGAQUFBzABhhpodHRwOi8vb2NzcC5t aXRyZS5vcmcvb2NzcDA+BgkrBgEEAYI3FQcEMTAvBicrBgEEAYI3FQiDrqwjho6WV4GNiT2CpKsS hb6uAYE2hquSaISo7EUCAWQCAQ8wFgYDVR0gBA8wDTALBgkrBgEEAXMCAQgwGwYJKwYBBAGCNxUK BA4wDDAKBggrBgEFBQcDBDANBgkqhkiG9w0BAQUFAAOCAgEAGmmL43yA+J5lEockM1cxSoyxfSES HUGLVJyrhObbdFD4yO3jf0R4lHLuJlhp1486d9LRZAyzAnl9q8Zf3Tx1rl1kEd3pw0wMuO+ATscc rArEW/rJxjz6zTrNO3PFkFuOEdmKpHaRiFpuSX602INiBEBPluei3uZlWxHW9VqC7hz2diQpOlzS jtPMbL3o7ACjWaq7sQ0xB4rZ6oWyqOZEfHWQA1b7nFgL4nEbmEHNdU4jAjcxkROku4O04205kb5n Loveoz3TSQNt8zalFayZAjt+JEcKuG1f5cyhYI6QwvkS/3M+CjJezuNaSmno29Lm+ToZnwUm4nIB YkBx4r9ZDU2W8029tr5og00A5MGo1LK+unWtHBa7zuPblfSiYgXIHWU+OKrSFaA935Yb4fLXFe9S BmApBr1gohHYos1hct5q90WPufSKIQ9WT+vJYXvW3FpseO4ZLKVnJsO7gVoQEEnWJUwyABBPQrii F0gh++ApKZJROTuR36PsEEx4duI6U4VXMCiIcnEjvNR8Mt5Q/Vp4W4Mp5fCv+QzYkqq9EWD7QuUW Yul6R8Hf7ZTxbUk0NfJgu8escLrgQSwMdP/kE/09vJAAslQBkNnIS7iIhWt4l5XQJBrJc+6popRE R8ykWf25e4CliaUgbAl1tBQKivQ3tlX99WykI2XK3sTk9nsxggMjMIIDHwIBATBeMFAxEzARBgoJ kiaJk/IsZAEZFgNPUkcxFTATBgoJkiaJk/IsZAEZFgVNSVRSRTEiMCAGA1UEAxMZTUlUUkUgQ29y cG9yYXRpb24gUEUgQ0EtMQIKGsNtyAACAAA3/DAJBgUrDgMCGgUAoIIBmjAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjA0MTcwMzI5MDFaMCMGCSqGSIb3DQEJBDEW BBRIEWxaq8SsiK51pgSGmMtoDmdlFDBbBgkqhkiG9w0BCQ8xTjBMMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMC GjBtBgkrBgEEAYI3EAQxYDBeMFAxEzARBgoJkiaJk/IsZAEZFgNPUkcxFTATBgoJkiaJk/IsZAEZ FgVNSVRSRTEiMCAGA1UEAxMZTUlUUkUgQ29ycG9yYXRpb24gUEUgQ0EtMQIKGsNq2wACAAA3+jBv BgsqhkiG9w0BCRACCzFgoF4wUDETMBEGCgmSJomT8ixkARkWA09SRzEVMBMGCgmSJomT8ixkARkW BU1JVFJFMSIwIAYDVQQDExlNSVRSRSBDb3Jwb3JhdGlvbiBQRSBDQS0xAgoaw2rbAAIAADf6MA0G CSqGSIb3DQEBAQUABIIBAM0n/4kGaa/qg7LhY4bjMLmA0s4gxQF622KO3ag4dA6D8NtdImIK+jz6 JqjS3rR+Uu6dO4ZxLhKYJEbHPDDQMAjDHb0ZxrmbDblDxNj7kVEhX9R9aHCFo60AiTiPSxRF0Qdk uBc/QAPZu42LJsay18/areDOCeVu56t+1unqgQqsyBQOTIy4JdqbkYnW8MtcDtDbAJEOb23tbJAb mkcT/+5R5M/I+9f6mhxglIZBnADkwhpl7TzAC8e6stfZoIhL9Q0gjmaW9fpzyxEXqs/dPDioiHG9 NfXOTif6p//AfIkCXZ+spc5AJK1DCU/8eiun2RWORuU3aJq8lDzkxeyLtcsAAAAAAAA= ------=_NextPart_000_0042_01CD1C28.B47EA280-- From osantos@cisco.com Mon Apr 16 20:32:20 2012 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 6515B21F84D2; Mon, 16 Apr 2012 20:32:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZVPfuWXnesrD; Mon, 16 Apr 2012 20:32:11 -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 8FB3321F84D3; Mon, 16 Apr 2012 20:32:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=osantos@cisco.com; l=57863; q=dns/txt; s=iport; t=1334633530; x=1335843130; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=lBTF+/eOqv3KsCIZK70mE6lc+i4ha8Un3HWPizcP+10=; b=c/VxN7hXVItb/deW1Mpi0AaFaKfkdDOvfxTQrrav89jnZKDOMJ297uay Mplgjwpb5FTr9Dg2yLpnS56Tq5c8Q6FJU8FDT+I/UA4+uaWIswoPoF62e DgMnGvLaI5qGnxQHbr4mfxtZYD/jYwsGJss4BvuneMxiSEu9NJaiVUW93 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAOzjjE+tJV2b/2dsb2JhbABBA4JGpWUBiQqBB4IJAQEBBAEBAQ8BBwILBgMlGQQHDgICAQgRBAEBCwYQAQYBBgEaBgYfCQgCBAESCBqHXgMLC5lkliQNiVMEijODaYJGYwSIWo4kiiEGgxSBaYMFgT4 X-IronPort-AV: E=Sophos;i="4.75,432,1330905600"; d="scan'208,217";a="75243610" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-4.cisco.com with ESMTP; 17 Apr 2012 03:32:09 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q3H3W9pT030236; Tue, 17 Apr 2012 03:32:09 GMT Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 16 Apr 2012 22:32:09 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD1C4A.AB41D122" Date: Mon, 16 Apr 2012 22:32:05 -0500 Message-ID: <953A2E460DBE7C43AC13E30B87C5B4FF080A1C00@XMB-RCD-106.cisco.com> In-Reply-To: <7F48813B48558A4BB5CB7BB714E5B5A9171B16@IMCMBX03.MITRE.ORG> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe website Thread-Index: AQHNHC91EoahZz2AEEqd+yKyGmroMJaeWIaQgAAEUcA= References: <7F48813B48558A4BB5CB7BB714E5B5A91706E3@IMCMBX03.MITRE.ORG> <870A23D4-BA94-4431-B613-F3D7734B8DB5@c3isecurity.com> <953A2E460DBE7C43AC13E30B87C5B4FF080A1BAD@XMB-RCD-106.cisco.com> <7F48813B48558A4BB5CB7BB714E5B5A9171B16@IMCMBX03.MITRE.ORG> From: "Omar Santos (osantos)" To: "Barnum, Sean D." , "Luis Nunez" X-OriginalArrivalTime: 17 Apr 2012 03:32:09.0724 (UTC) FILETIME=[ABB07BC0:01CD1C4A] Cc: idxwg@nicwg.org, mile@ietf.org, dallendoug@gmail.com, sacm@ietf.org, m-terada@ipa.go.jp Subject: Re: [mile] [sacm] CybOX v1.0 (Draft) is now released and live onthe website 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, 17 Apr 2012 03:32:20 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD1C4A.AB41D122 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for the clarification Sean. It does make sense.. =20 Regards, Omar=20 =20 From: Barnum, Sean D. [mailto:sbarnum@mitre.org]=20 Sent: Monday, April 16, 2012 11:29 PM To: Omar Santos (osantos); Luis Nunez Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; m-terada@ipa.go.jp Subject: RE: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe website =20 Thanks Omar. =20 To answer your question, first let me point out to other readers that the two entries that Omar is quoting here exist as values in an enumeration called EventTypeEnum which as its name implies contains a list of different labels for grouping types (or classes) of events to be used as low-granularity buckets for characterizing and classifying events. Other entries in this enumeration include things like "File Ops (CRUD)", "Process Mgt", "Authorization (ACL)", etc. =20 The "Packet Traffic" value is intended to characterize events dealing with network packet traffic as its name implies. The "Data Flow" value is intended to characterize events dealing with forms of data flow at a higher level of abstraction than just packet traffic. The relationship between these two values could be viewed as "Packet Traffic" being a more detailed form of "Data Flow" just as the values "App Layer Traffic" and "HTTP Layer Traffic", also in this enumeration, could be other levels in this same abstraction stack. The idea behind the varying levels of abstraction is to leave buckets large enough to capture a wide variety of potential event types (e.g. data flow events other than obvious things like packet traffic) but also enable the use of smaller more specific buckets when they are appropriate and commonly used. =20 Does this make sense?=20 =20 sean =20 From: Omar Santos (osantos) [mailto:osantos@cisco.com]=20 Sent: Monday, April 16, 2012 8:17 PM To: Luis Nunez; Barnum, Sean D. Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; m-terada@ipa.go.jp Subject: RE: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe website =20 I echo Luis' comments. It is good to see the inclusion of network objects. Quick question to the team related to your netflow comment. =20 I am looking at: http://cybox.mitre.org/XMLSchema/cybox_core_v1.0%28draft%29.xsd =20 ... and it looks that we renamed it to "Data Flow"? =20 Specifies the class of events dealing with data flow. =20 =20 What is the difference between that and "Packet Traffic"? =20 Specifies the class of events dealing with packet traffic. =20 =20 =20 =20 Regards, Omar Santos Incident Manager, PSIRT Security Research and Operations Cisco Systems, Inc. Email: os@cisco.com Phone: +1 919 392 8635 PGP Key: 0x3AF27EDC Cisco.com - http://www.cisco.com Cisco Security Advisories and Notices - http://www.cisco.com/go/psirt This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message. For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html =20 From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Luis Nunez Sent: Monday, April 16, 2012 6:44 PM To: Barnum, Sean D. Cc: idxwg@nicwg.org; mile@ietf.org; Doug Wilson (dallendoug@gmail.com); sacm@ietf.org; IPA-Masato Terada (m-terada@ipa.go.jp) Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe website =20 I like the inclusion of the network-centric objects. IPFIX (netflow) will add an additional perspective from an incident information sharing standpoint. =20 =20 -ln =20 On Apr 16, 2012, at 4:04 PM, Barnum, Sean D. wrote: =20 Hey everyone, =20 I just wanted to let you all know that CybOX v1.0 (Draft) content is now live on the website. http://cybox.mitre.org The release notes are provided inline below. The key items of note are: * The release of two formal specifications for the CybOX language (one for the core language and one for the defined objects) * The XML Schema has gone through extensive improvements for expressiveness, clarity, consistency, efficiency, alignment to existing normative references and documentation. * This release includes an initial set of language utilities: a draft Snort -> CybOX transform, a draft OpenIOC -> CybOX transform, and a set of Python bindings for the CybOX language. * The website now includes a small set of content examples. This set will grow going forward. This release involved a lot of hard work from a diverse group of people. Thank you all for your contributions and effort. We could not have done it without you. We look forward to everyone's feedback and collaboration as we continue to improve and mature the CybOX language. =20 Sean Barnum =20 =20 =20 CybOX v1.0 (Draft) Release Notes The Version 1.0 (Draft) release of Cyber Observable eXpression (CybOX(tm)) is intended as a draft release of an initial major version of the CybOX Language that could be utilized for practical operational use and integration into other standards efforts. This release consists of three primary components: a pair of formal language specifications for the core language content and defined objects content, a set of language implementation XML schemas (core, common_types, and ~70 defined object schemas), and a small initial set of language utilities including an initial draft Snort->CybOX transform, an initial draft OpenIOC->CybOX transform and a set of CybOX language Python bindings. Recognizing that this is the first time that the formal language specifications will be available for review and as such will likely generate feedback from new stakeholders, this initial major version is being released as a "draft" v1.0 with the expectation of cycles of new feedback and revision before a "final" v1.0 is released. The CybOX v1.0 (Draft) XML schemas include a significant number of changes from v0.7 to improve: * Clarity, documentation, and descriptive formality for reference and implementation by other standards and users. * Consistency, simplicity, and efficiency. * Alignment (as appropriate) to existing normative references. * Expressiveness of the schema to better support the broad set of use cases it targets (malware characterization, indicator and incident data sharing, event management, etc.) including the addition of an initial set of network-related defined objects. Summary of changes from CybOX_v0.7 to CybOX_v1.0_(Draft): * Refinement of namespaces and schema locations for better effectiveness and flexibility going forward. * Normalized all content according to an established set of naming conventions. * Fully annotated all language items (types, attributes, elements, etc.). * Moved several commonly leveraged types out of the core schema and into common_types. * Achieved full typing of entire schema structure such that all attributes and elements are definitively typed. * Changed all identifiers from ID and IDREF types to be QNames enabling globally unique identifiers and flexibility for domain-specific users of CybOX to define their own identifier syntax locally. * Reordered attributes and elements in numerous types to better reflect common usage and priority. * Added major_version and minor_version attributes for core schema. * Added capability to characterize source of overall observable package data and for individual observables. * Modified the logical composition structure such that any such compositions are now contained within a Observable_Composition element providing improved simplicity and modularity. * Removed the Delta element from ObservableType and relocated the appropriate portions (Change, Trend, and Frequency) to appropriate locations under Stateful_Measure and Event. * Added a Domain_Specific_Object_Attributes field to Object utilizing an abstract type that will allow domain-specific use cases to add in their own domain-specific attributes for Objects. * Added a Tool-Specific_Data field to ToolInformationType utilizing an abstract type that will allow addition of tool-specific data. * Added an Indicators field to MeasureSourceType utilizing an abstract type that will allow characterizing differing formats or standards of indicators that may have led to the identification of the observable data. * Enhanced the Hash structure to capture full fuzzy hashes in addition to simple hashes * Added a new ExtractedFeaturesType that can be used to adorn differing objects (e.g., files, memory, etc.) to capture extracted strings, imports, functions and code snippets * Added a ByteRunsType to enable capture of byte runs within various objects. * Added object_reference attribute to DefinedObjectType to better support referencing of independently defined Objects from within another Object definition. * Added a generic DataSegmentType to provide a relatively abstract way of characterizing data segments that may be written/read/transmitted or otherwise utilized in actions or defined in objects. * Added several new defined object schemas (API, Code, Device, DNS_Record, Network_Flow, Network_Packet, Network_Route_Entry, Network_Subnet, Unix_Network_Route_Entry) including an initial set of network-centric defined objects. * Modified every defined object schema with added annotations as well as minor and in some cases substantive changes to fix errors, improve consistency and alignment with existing normative references, and to improve expressiveness in support of the targeted use cases. Detailed changes from CybOX_v0.7 to CybOX_v1.0_(Draft): The level of changes within v1.0 (Draft) in the core schema, common_types and the defined object schemas is too great to list every change in these release notes. Detailed difference reports are available for each individual schema at:http://cybox.mitre.org/XMLSchema/release_notes/cybox_v1.0(draft)_diff _reports.zip =20 =20 =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Sean Barnum Cyber Security Principal The MITRE Corporation Email: sbarnum@mitre.org =20 _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile =20 ------_=_NextPart_001_01CD1C4A.AB41D122 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks for the clarification Sean. It does make = sense..

 

Regards,

Omar

 

From:= = Barnum, Sean D. [mailto:sbarnum@mitre.org]
Sent: Monday, = April 16, 2012 11:29 PM
To: Omar Santos (osantos); Luis = Nunez
Cc: idxwg@nicwg.org; mile@ietf.org; = dallendoug@gmail.com; sacm@ietf.org; = m-terada@ipa.go.jp
Subject: RE: [sacm] [mile] CybOX v1.0 = (Draft) is now released and live onthe = website

 

Thanks Omar.

 

To answer your question, first let me point out to other readers that = the two entries that Omar is quoting here exist as values in an = enumeration called EventTypeEnum which as its name implies contains a = list of different labels for grouping types (or classes) of events to be = used as low-granularity buckets for characterizing and classifying = events.

Other entries in this enumeration include things like “File Ops = (CRUD)”, “Process Mgt”, “Authorization = (ACL)”, etc.

 

The “Packet Traffic” value is intended to characterize = events dealing with network packet traffic as its name = implies.

The “Data Flow” value is intended to characterize events = dealing with forms of data flow at a higher level of abstraction than = just packet traffic. The relationship between these two values could be = viewed as “Packet Traffic” being a more detailed form of = “Data Flow” just as the values “App Layer = Traffic” and “HTTP Layer Traffic”, also in this = enumeration, could be other levels in this same abstraction = stack.

The idea behind the varying levels of abstraction is to leave =  buckets large enough to capture a wide variety of potential event = types (e.g. data flow events other than obvious things like packet = traffic) but also enable the use of smaller more specific buckets when = they are appropriate and commonly used.

 

Does this make sense?

 

sean

 

From:= = Omar Santos (osantos) [mailto:osantos@cisco.com]=
Sent: Monday, April 16, 2012 8:17 PM
To: Luis = Nunez; Barnum, Sean D.
Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; m-terada@ipa.go.jp
Subject:<= /b> RE: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe = website

 

I echo Luis’ comments. It is good to see the inclusion of = network objects. Quick question to the team related to your netflow = comment.

 

I am looking at:

= http://cybox.mitre.org/XMLSchema/cybox_core_v1.0%28draft%29.xsd<= /o:p>

 

… and it looks that we renamed it to “Data = Flow”?

 

<xs:enumeration = value=3D"Data Flow">

   = <xs:annotation>

        = <xs:documentation>Specifies the class of events dealing with data = flow.</xs:documentation>

   = </xs:annotation>

</xs:enumeration>

 

 

What is the difference between that and “Packet = Traffic”?

 

<xs:enumeration value=3D"Packet =
Traffic">
   =
<xs:annotation>
     =
<xs:documentation>Specifies the class of events dealing with =
packet traffic.</xs:documentation>
   =
</xs:annotation>
</xs:enumeration>

 

 

 

 

Regards,

Omar Santos
Incident Manager, = PSIRT
Security Research and Operations
Cisco Systems, = Inc.
Email: os@cisco.com
Phone: +1 919 392 = 8635
PGP Key: 0x3AF27EDC

Cisco.com - http://www.cisco.com
Cisco Security = Advisories and Notices - http://www.cisco.com/go/psirt<= br>
This email may contain confidential and privileged material for = the sole
use of the intended recipient. Any review, use, distribution = or
disclosure by others is strictly prohibited. If you are not the = intended
recipient (or authorized to receive for the recipient), = please contact
the sender by reply email and delete all copies of = this message.

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html=

 

From:= = sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.= org] On Behalf Of Luis Nunez
Sent: Monday, April = 16, 2012 6:44 PM
To: Barnum, Sean D.
Cc: idxwg@nicwg.org; mile@ietf.org; Doug Wilson (dallendoug@gmail.com); sacm@ietf.org; IPA-Masato Terada (m-terada@ipa.go.jp)
Subject:= Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe = website

 

I like the inclusion of the network-centric = objects.  IPFIX (netflow)  will add an additional perspective = from an incident information sharing standpoint. =  

 

-ln

 

On Apr 16, 2012, at 4:04 = PM, Barnum, Sean D. wrote:

 

Hey = everyone,

 =

I just = wanted to let you all know that CybOX v1.0 (Draft) content is now live = on the website. http://cybox.mitre.org

The = release notes are provided inline = below.

The key = items of note are:

·        The = release of two formal specifications for the CybOX language (one for the = core language and one for the defined = objects)

·        The XML = Schema has gone through extensive improvements for expressiveness, = clarity, consistency, efficiency, alignment to existing normative = references and documentation.

·        This = release includes an initial set of language utilities: a draft Snort = -> CybOX transform, a draft OpenIOC -> CybOX transform, and a set = of Python bindings for the CybOX language.

·        The = website now includes a small set of content examples. This set will grow = going forward.

This = release involved a lot of hard work from a diverse group of people. = Thank you all for your contributions and effort. We could not have done = it without you.

We look = forward to everyone’s feedback and collaboration as we continue to = improve and mature the CybOX = language.

 =

Sean = Barnum

 =

 =

 =

CybOX v1.0 (Draft) Release = Notes

The Version 1.0 (Draft) release of Cyber = Observable eXpression (CybOX™) is intended as a draft release of an initial major version of = the CybOX Language that could be utilized for practical operational use = and integration into other standards efforts. This release consists of = three primary components: a pair of formal language specifications for = the core language content and defined objects content, a set of language = implementation XML schemas (core, common_types, and ~70 defined object = schemas), and a small initial set of language utilities including an = initial draft Snort->CybOX transform, an initial draft = OpenIOC->CybOX transform and a set of CybOX language Python bindings. = Recognizing that this is the first time that the formal language = specifications will be available for review and as such will likely = generate feedback from new stakeholders, this initial major version is = being released as a “draft” v1.0 with the expectation of = cycles of new feedback and revision before a “final” v1.0 is = released.=

The CybOX v1.0 (Draft) XML schemas include a = significant number of changes from v0.7 to improve:=

·       Clarity, = documentation, and descriptive formality for reference and = implementation by other standards and users.=

·       Consistency, = simplicity, and efficiency.=

·       Alignment (as = appropriate) to existing normative references.=

·       Expressiveness of the = schema to better support the broad set of use cases it targets (malware = characterization, indicator and incident data sharing, event management, = etc.) including the addition of an initial set of network-related = defined objects.=

Summary = of changes from CybOX_v0.7 to CybOX_v1.0_(Draft):=

·         = Refinement of namespaces and schema = locations for better effectiveness and flexibility going forward.=

·         = Normalized all content according to an = established set of naming conventions.=

·         = Fully annotated all language items = (types, attributes, elements, etc.).=

·         = Moved several commonly leveraged types = out of the core schema and into common_types.=

·         = Achieved full typing of entire schema = structure such that all attributes and elements are definitively = typed.=

·         = Changed all identifiers from ID and IDREF = types to be QNames enabling globally unique identifiers and flexibility = for domain-specific users of CybOX to define their own identifier syntax = locally.=

·         = Reordered attributes and elements in = numerous types to better reflect common usage and priority.=

·         = Added major_version and minor_version = attributes for core schema.=

·         = Added capability to characterize source = of overall observable package data and for individual observables.=

·         = Modified the logical composition = structure such that any such compositions are now contained within a = Observable_Composition element providing improved simplicity and = modularity.=

·         = Removed the Delta element from = ObservableType and relocated the appropriate portions (Change, Trend, = and Frequency) to appropriate locations under Stateful_Measure and = Event.=

·         = Added a Domain_Specific_Object_Attributes = field to Object utilizing an abstract type that will allow = domain-specific use cases to add in their own domain-specific attributes = for Objects.=

·         = Added a Tool-Specific_Data field to = ToolInformationType utilizing an abstract type that will allow addition = of tool-specific data.=

·         = Added an Indicators field to = MeasureSourceType utilizing an abstract type that will allow = characterizing differing formats or standards of indicators that may = have led to the identification of the observable data.=

·         = Enhanced the Hash structure to capture = full fuzzy hashes in addition to simple hashes=

·         = Added a new ExtractedFeaturesType that = can be used to adorn differing objects (e.g., files, memory, etc.) to = capture extracted strings, imports, functions and code snippets=

·         = Added a ByteRunsType to enable capture of = byte runs within various objects.=

·         = Added object_reference attribute to = DefinedObjectType to better support referencing of independently defined = Objects from within another Object definition.=

·         = Added a generic DataSegmentType to = provide a relatively abstract way of characterizing data segments that = may be written/read/transmitted or otherwise utilized in actions or = defined in objects.=

·        Added several new = defined object schemas (API, Code, Device, DNS_Record, Network_Flow, = Network_Packet, Network_Route_Entry, Network_Subnet, = Unix_Network_Route_Entry) including an initial set of network-centric = defined objects.

·         = Modified every defined object schema with = added annotations as well as minor and in some cases substantive changes = to fix errors, improve consistency and alignment with existing normative = references, and to improve expressiveness in support of the targeted use = cases.=

Detailed changes from CybOX_v0.7 to = CybOX_v1.0_(Draft):=

The level of changes within v1.0 (Draft) in = the core schema, common_types and the defined object schemas is too = great to list every change in these release notes. Detailed difference = reports are available for each individual schema at:http://cybox.mitre.org/XMLSchema/release_notes/cybox_v1.0= (draft)_diff_reports.zip

 =

 =

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

Sean Barnum=

Cyber Security Principal=

The MITRE Corporation=

 =

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

 

------_=_NextPart_001_01CD1C4A.AB41D122-- From osantos@cisco.com Mon Apr 16 20:57:25 2012 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 B8A9911E8099; Mon, 16 Apr 2012 20:57:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dz98tcGQkW03; Mon, 16 Apr 2012 20:57:20 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 04CCF11E8081; Mon, 16 Apr 2012 20:57:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=osantos@cisco.com; l=81388; q=dns/txt; s=iport; t=1334635040; x=1335844640; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=VPVQvi+cR/8wAHuajOtt5x6iB4Lp73HzGwekOEcR6Fs=; b=R8wDoHFM2BbdkvvXIp6b2szzDR6FGJCLcxWR0JixU6+LURph1MWhjjvK IlineKRyw/A1mE1L0bjiC6P7Lohz6uTTmjSGy04Bx2d+WdknE55hukU11 citmI91qHuuJoGR14Z6+Xq37rahwtxgtgZgSpffXYso2vAHFwJx0DK9Oz 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYFAIvojE+tJXG9/2dsb2JhbABBA4JGgyCiRQGIEHqBB4IJAQEBBAEBAQ8BBwIHBAYDJRkEBw4CAgEIEQQBAQsGEAEGAQICAgEBGQYGHwkIAgQBEggah14DCwuZZ40QiRUNiVMEijODaYIRNWMEiFqOJIohBoMUgWmDBYE+ X-IronPort-AV: E=Sophos;i="4.75,432,1330905600"; d="scan'208,217";a="75235173" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-7.cisco.com with ESMTP; 17 Apr 2012 03:57:19 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id q3H3vJ2G009732; Tue, 17 Apr 2012 03:57:19 GMT Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 16 Apr 2012 22:57:19 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD1C4E.2F4B01A2" Date: Mon, 16 Apr 2012 22:57:15 -0500 Message-ID: <953A2E460DBE7C43AC13E30B87C5B4FF080A1C09@XMB-RCD-106.cisco.com> In-Reply-To: <69CE2DCD9DAC3D48B830E0723141170B02A39BD2@ZAU1UG-0308.DHSNET.DS1.DHS> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe website Thread-Index: AQHNHC91EoahZz2AEEqd+yKyGmroMJaeWIaQgAAIZb+AAAIPgA== References: <7F48813B48558A4BB5CB7BB714E5B5A9171B16@IMCMBX03.MITRE.ORG> <69CE2DCD9DAC3D48B830E0723141170B02A39BD2@ZAU1UG-0308.DHSNET.DS1.DHS> From: "Omar Santos (osantos)" To: "Millar, Thomas" , , X-OriginalArrivalTime: 17 Apr 2012 03:57:19.0370 (UTC) FILETIME=[2F822EA0:01CD1C4E] Cc: idxwg@nicwg.org, mile@ietf.org, dallendoug@gmail.com, sacm@ietf.org, m-terada@ipa.go.jp Subject: Re: [mile] [sacm] CybOX v1.0 (Draft) is now released and live onthe website 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, 17 Apr 2012 03:57:25 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD1C4E.2F4B01A2 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBiZWxpZXZlIHRoYXQgd2hhdCBTZWFuIGlzIHNheWluZyBpcyB0aGF0IOKAnGRhdGEgZmxvd+KA nSBpcyBqdXN0IGEgdmFsdWUgdGhhdCBpcyBtZWFudCBmb3IgdXBwZXIgbGF5ZXIgcHJvdG9jb2xz LiBCdXQsIHlvdSBoYXZlIGEgZ29vZCBwb2ludC4gVHJhZGl0aW9uYWxseSwgYSDigJxmbG934oCd IGluIOKAnE5ldGZsb3figJ0gaXMgYmFzZWQgb24gYSBzZXQgb2YgNSBhbmQgdXAgdG8gNyBJUCBw YWNrZXQgYXR0cmlidXRlczoNCg0KIA0KDQotIElQIHNvdXJjZSBhZGRyZXNzDQoNCi0gSVAgZGVz dGluYXRpb24gYWRkcmVzcw0KDQotIFNvdXJjZSBwb3J0DQoNCi0gRGVzdGluYXRpb24gcG9ydA0K DQotIExheWVyIDMgcHJvdG9jb2wgdHlwZQ0KDQotIENsYXNzIG9mIFNlcnZpY2UNCg0KLSBSb3V0 ZXIgb3Igc3dpdGNoIGludGVyZmFjZQ0KDQogDQoNCkFsdGhvdWdoLCB0aGVyZSBpcyBhIGxvdCBt b3JlIHN1cHBvcnQgd2l0aCBOZXRmbG93IHZlcnNpb24gOToNCg0KaHR0cDovL3d3dy5jaXNjby5j b20vZW4vVVMvdGVjaG5vbG9naWVzL3RrNjQ4L3RrMzYyL3RlY2hub2xvZ2llc193aGl0ZV9wYXBl cjA5MTg2YTAwODAwYTNkYjlfcHM2NjAxX1Byb2R1Y3RzX1doaXRlX1BhcGVyLmh0bWwNCg0KIA0K DQogDQoNCiANCg0KUmVnYXJkcywNCg0KT21hciANCg0KIA0KDQpGcm9tOiBNaWxsYXIsIFRob21h cyBbbWFpbHRvOlRob21hcy5NaWxsYXJAaHEuZGhzLmdvdl0gDQpTZW50OiBNb25kYXksIEFwcmls IDE2LCAyMDEyIDExOjQ2IFBNDQpUbzogc2Jhcm51bUBtaXRyZS5vcmc7IE9tYXIgU2FudG9zIChv c2FudG9zKTsgbG51bmV6QGMzaXNlY3VyaXR5LmNvbQ0KQ2M6IGlkeHdnQG5pY3dnLm9yZzsgbWls ZUBpZXRmLm9yZzsgZGFsbGVuZG91Z0BnbWFpbC5jb207IHNhY21AaWV0Zi5vcmc7IG0tdGVyYWRh QGlwYS5nby5qcA0KU3ViamVjdDogUmU6IFtzYWNtXSBbbWlsZV0gQ3liT1ggdjEuMCAoRHJhZnQp IGlzIG5vdyByZWxlYXNlZCBhbmQgbGl2ZSBvbnRoZSB3ZWJzaXRlDQoNCiANCg0KSWYgImRhdGEg ZmxvdyIgaXMgYSBldXBoZW1pc20gZm9yICJuZXRmbG93IiBpcyB0aGVyZSBhbnkgcmVhc29uIG5v dCB0byBjYWxsIGl0IHRoYXQ/DQoNClRvbSBNaWxsYXIgDQpodHRwOi8vd3d3LnVzLWNlcnQuZ292 LyANCi0tLS0tLS0tLS0tLS0tLS0tLSANCk1pc3NpdCBtZSBSdWJ1cyBmcnV0aWNvc3VzOiANCjIw MiA2MzEgMTkxNSANCg0KIA0KDQpGcm9tOiBCYXJudW0sIFNlYW4gRC4gW21haWx0bzpzYmFybnVt QG1pdHJlLm9yZ10gDQpTZW50OiBNb25kYXksIEFwcmlsIDE2LCAyMDEyIDExOjI5IFBNDQpUbzog T21hciBTYW50b3MgKG9zYW50b3MpIDxvc2FudG9zQGNpc2NvLmNvbT47IEx1aXMgTnVuZXogPGxu dW5lekBjM2lzZWN1cml0eS5jb20+IA0KQ2M6IGlkeHdnQG5pY3dnLm9yZyA8aWR4d2dAbmljd2cu b3JnPjsgbWlsZUBpZXRmLm9yZyA8bWlsZUBpZXRmLm9yZz47IGRhbGxlbmRvdWdAZ21haWwuY29t IDxkYWxsZW5kb3VnQGdtYWlsLmNvbT47IHNhY21AaWV0Zi5vcmcgPHNhY21AaWV0Zi5vcmc+OyBt LXRlcmFkYUBpcGEuZ28uanAgPG0tdGVyYWRhQGlwYS5nby5qcD4gDQpTdWJqZWN0OiBSZTogW3Nh Y21dIFttaWxlXSBDeWJPWCB2MS4wIChEcmFmdCkgaXMgbm93IHJlbGVhc2VkIGFuZCBsaXZlIG9u dGhlIHdlYnNpdGUgDQogDQoNClRoYW5rcyBPbWFyLg0KDQogDQoNClRvIGFuc3dlciB5b3VyIHF1 ZXN0aW9uLCBmaXJzdCBsZXQgbWUgcG9pbnQgb3V0IHRvIG90aGVyIHJlYWRlcnMgdGhhdCB0aGUg dHdvIGVudHJpZXMgdGhhdCBPbWFyIGlzIHF1b3RpbmcgaGVyZSBleGlzdCBhcyB2YWx1ZXMgaW4g YW4gZW51bWVyYXRpb24gY2FsbGVkIEV2ZW50VHlwZUVudW0gd2hpY2ggYXMgaXRzIG5hbWUgaW1w bGllcyBjb250YWlucyBhIGxpc3Qgb2YgZGlmZmVyZW50IGxhYmVscyBmb3IgZ3JvdXBpbmcgdHlw ZXMgKG9yIGNsYXNzZXMpIG9mIGV2ZW50cyB0byBiZSB1c2VkIGFzIGxvdy1ncmFudWxhcml0eSBi dWNrZXRzIGZvciBjaGFyYWN0ZXJpemluZyBhbmQgY2xhc3NpZnlpbmcgZXZlbnRzLg0KDQpPdGhl ciBlbnRyaWVzIGluIHRoaXMgZW51bWVyYXRpb24gaW5jbHVkZSB0aGluZ3MgbGlrZSDigJxGaWxl IE9wcyAoQ1JVRCnigJ0sIOKAnFByb2Nlc3MgTWd04oCdLCDigJxBdXRob3JpemF0aW9uIChBQ0wp 4oCdLCBldGMuDQoNCiANCg0KVGhlIOKAnFBhY2tldCBUcmFmZmlj4oCdIHZhbHVlIGlzIGludGVu ZGVkIHRvIGNoYXJhY3Rlcml6ZSBldmVudHMgZGVhbGluZyB3aXRoIG5ldHdvcmsgcGFja2V0IHRy YWZmaWMgYXMgaXRzIG5hbWUgaW1wbGllcy4NCg0KVGhlIOKAnERhdGEgRmxvd+KAnSB2YWx1ZSBp cyBpbnRlbmRlZCB0byBjaGFyYWN0ZXJpemUgZXZlbnRzIGRlYWxpbmcgd2l0aCBmb3JtcyBvZiBk YXRhIGZsb3cgYXQgYSBoaWdoZXIgbGV2ZWwgb2YgYWJzdHJhY3Rpb24gdGhhbiBqdXN0IHBhY2tl dCB0cmFmZmljLiBUaGUgcmVsYXRpb25zaGlwIGJldHdlZW4gdGhlc2UgdHdvIHZhbHVlcyBjb3Vs ZCBiZSB2aWV3ZWQgYXMg4oCcUGFja2V0IFRyYWZmaWPigJ0gYmVpbmcgYSBtb3JlIGRldGFpbGVk IGZvcm0gb2Yg4oCcRGF0YSBGbG934oCdIGp1c3QgYXMgdGhlIHZhbHVlcyDigJxBcHAgTGF5ZXIg VHJhZmZpY+KAnSBhbmQg4oCcSFRUUCBMYXllciBUcmFmZmlj4oCdLCBhbHNvIGluIHRoaXMgZW51 bWVyYXRpb24sIGNvdWxkIGJlIG90aGVyIGxldmVscyBpbiB0aGlzIHNhbWUgYWJzdHJhY3Rpb24g c3RhY2suDQoNClRoZSBpZGVhIGJlaGluZCB0aGUgdmFyeWluZyBsZXZlbHMgb2YgYWJzdHJhY3Rp b24gaXMgdG8gbGVhdmUgIGJ1Y2tldHMgbGFyZ2UgZW5vdWdoIHRvIGNhcHR1cmUgYSB3aWRlIHZh cmlldHkgb2YgcG90ZW50aWFsIGV2ZW50IHR5cGVzIChlLmcuIGRhdGEgZmxvdyBldmVudHMgb3Ro ZXIgdGhhbiBvYnZpb3VzIHRoaW5ncyBsaWtlIHBhY2tldCB0cmFmZmljKSBidXQgYWxzbyBlbmFi bGUgdGhlIHVzZSBvZiBzbWFsbGVyIG1vcmUgc3BlY2lmaWMgYnVja2V0cyB3aGVuIHRoZXkgYXJl IGFwcHJvcHJpYXRlIGFuZCBjb21tb25seSB1c2VkLg0KDQogDQoNCkRvZXMgdGhpcyBtYWtlIHNl bnNlPyANCg0KIA0KDQpzZWFuDQoNCiANCg0KRnJvbTogT21hciBTYW50b3MgKG9zYW50b3MpIFtt YWlsdG86b3NhbnRvc0BjaXNjby5jb21dIA0KU2VudDogTW9uZGF5LCBBcHJpbCAxNiwgMjAxMiA4 OjE3IFBNDQpUbzogTHVpcyBOdW5lejsgQmFybnVtLCBTZWFuIEQuDQpDYzogaWR4d2dAbmljd2cu b3JnOyBtaWxlQGlldGYub3JnOyBkYWxsZW5kb3VnQGdtYWlsLmNvbTsgc2FjbUBpZXRmLm9yZzsg bS10ZXJhZGFAaXBhLmdvLmpwDQpTdWJqZWN0OiBSRTogW3NhY21dIFttaWxlXSBDeWJPWCB2MS4w IChEcmFmdCkgaXMgbm93IHJlbGVhc2VkIGFuZCBsaXZlIG9udGhlIHdlYnNpdGUNCg0KIA0KDQpJ IGVjaG8gTHVpc+KAmSBjb21tZW50cy4gSXQgaXMgZ29vZCB0byBzZWUgdGhlIGluY2x1c2lvbiBv ZiBuZXR3b3JrIG9iamVjdHMuIFF1aWNrIHF1ZXN0aW9uIHRvIHRoZSB0ZWFtIHJlbGF0ZWQgdG8g eW91ciBuZXRmbG93IGNvbW1lbnQuDQoNCiANCg0KSSBhbSBsb29raW5nIGF0Og0KDQpodHRwOi8v Y3lib3gubWl0cmUub3JnL1hNTFNjaGVtYS9jeWJveF9jb3JlX3YxLjAlMjhkcmFmdCUyOS54c2QN Cg0KIA0KDQrigKYgYW5kIGl0IGxvb2tzIHRoYXQgd2UgcmVuYW1lZCBpdCB0byDigJxEYXRhIEZs b3figJ0/DQoNCiANCg0KPHhzOmVudW1lcmF0aW9uIHZhbHVlPSJEYXRhIEZsb3ciPg0KDQogICA8 eHM6YW5ub3RhdGlvbj4NCg0KICAgICAgICA8eHM6ZG9jdW1lbnRhdGlvbj5TcGVjaWZpZXMgdGhl IGNsYXNzIG9mIGV2ZW50cyBkZWFsaW5nIHdpdGggZGF0YSBmbG93LjwveHM6ZG9jdW1lbnRhdGlv bj4NCg0KICAgPC94czphbm5vdGF0aW9uPg0KDQo8L3hzOmVudW1lcmF0aW9uPg0KDQogDQoNCiAN Cg0KV2hhdCBpcyB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIHRoYXQgYW5kIOKAnFBhY2tldCBUcmFm Zmlj4oCdPw0KDQogDQoNCjx4czplbnVtZXJhdGlvbiB2YWx1ZT0iUGFja2V0IFRyYWZmaWMiPg0K ICAgPHhzOmFubm90YXRpb24+DQogICAgIDx4czpkb2N1bWVudGF0aW9uPlNwZWNpZmllcyB0aGUg Y2xhc3Mgb2YgZXZlbnRzIGRlYWxpbmcgd2l0aCBwYWNrZXQgdHJhZmZpYy48L3hzOmRvY3VtZW50 YXRpb24+DQogICA8L3hzOmFubm90YXRpb24+DQo8L3hzOmVudW1lcmF0aW9uPg0KDQogDQoNCiAN Cg0KIA0KDQogDQoNClJlZ2FyZHMsDQoNCk9tYXIgU2FudG9zDQpJbmNpZGVudCBNYW5hZ2VyLCBQ U0lSVA0KU2VjdXJpdHkgUmVzZWFyY2ggYW5kIE9wZXJhdGlvbnMNCkNpc2NvIFN5c3RlbXMsIElu Yy4NCkVtYWlsOiBvc0BjaXNjby5jb20NClBob25lOiArMSA5MTkgMzkyIDg2MzUNClBHUCBLZXk6 IDB4M0FGMjdFREMNCg0KQ2lzY28uY29tIC0gaHR0cDovL3d3dy5jaXNjby5jb20NCkNpc2NvIFNl Y3VyaXR5IEFkdmlzb3JpZXMgYW5kIE5vdGljZXMgLSBodHRwOi8vd3d3LmNpc2NvLmNvbS9nby9w c2lydA0KDQpUaGlzIGVtYWlsIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdl ZCBtYXRlcmlhbCBmb3IgdGhlIHNvbGUNCnVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LiBB bnkgcmV2aWV3LCB1c2UsIGRpc3RyaWJ1dGlvbiBvcg0KZGlzY2xvc3VyZSBieSBvdGhlcnMgaXMg c3RyaWN0bHkgcHJvaGliaXRlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkDQpyZWNpcGll bnQgKG9yIGF1dGhvcml6ZWQgdG8gcmVjZWl2ZSBmb3IgdGhlIHJlY2lwaWVudCksIHBsZWFzZSBj b250YWN0DQp0aGUgc2VuZGVyIGJ5IHJlcGx5IGVtYWlsIGFuZCBkZWxldGUgYWxsIGNvcGllcyBv ZiB0aGlzIG1lc3NhZ2UuDQoNCkZvciBjb3Jwb3JhdGUgbGVnYWwgaW5mb3JtYXRpb24gZ28gdG86 DQpodHRwOi8vd3d3LmNpc2NvLmNvbS93ZWIvYWJvdXQvZG9pbmdfYnVzaW5lc3MvbGVnYWwvY3Jp L2luZGV4Lmh0bWwNCg0KIA0KDQpGcm9tOiBzYWNtLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpz YWNtLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBMdWlzIE51bmV6DQpTZW50OiBNb25k YXksIEFwcmlsIDE2LCAyMDEyIDY6NDQgUE0NClRvOiBCYXJudW0sIFNlYW4gRC4NCkNjOiBpZHh3 Z0BuaWN3Zy5vcmc7IG1pbGVAaWV0Zi5vcmc7IERvdWcgV2lsc29uIChkYWxsZW5kb3VnQGdtYWls LmNvbSk7IHNhY21AaWV0Zi5vcmc7IElQQS1NYXNhdG8gVGVyYWRhIChtLXRlcmFkYUBpcGEuZ28u anApDQpTdWJqZWN0OiBSZTogW3NhY21dIFttaWxlXSBDeWJPWCB2MS4wIChEcmFmdCkgaXMgbm93 IHJlbGVhc2VkIGFuZCBsaXZlIG9udGhlIHdlYnNpdGUNCg0KIA0KDQpJIGxpa2UgdGhlIGluY2x1 c2lvbiBvZiB0aGUgbmV0d29yay1jZW50cmljIG9iamVjdHMuICBJUEZJWCAobmV0ZmxvdykgIHdp bGwgYWRkIGFuIGFkZGl0aW9uYWwgcGVyc3BlY3RpdmUgZnJvbSBhbiBpbmNpZGVudCBpbmZvcm1h dGlvbiBzaGFyaW5nIHN0YW5kcG9pbnQuICANCg0KIA0KDQotbG4NCg0KIA0KDQpPbiBBcHIgMTYs IDIwMTIsIGF0IDQ6MDQgUE0sIEJhcm51bSwgU2VhbiBELiB3cm90ZToNCg0KIA0KDQpIZXkgZXZl cnlvbmUsDQoNCiANCg0KSSBqdXN0IHdhbnRlZCB0byBsZXQgeW91IGFsbCBrbm93IHRoYXQgQ3li T1ggdjEuMCAoRHJhZnQpIGNvbnRlbnQgaXMgbm93IGxpdmUgb24gdGhlIHdlYnNpdGUuIGh0dHA6 Ly9jeWJveC5taXRyZS5vcmcNCg0KVGhlIHJlbGVhc2Ugbm90ZXMgYXJlIHByb3ZpZGVkIGlubGlu ZSBiZWxvdy4NCg0KVGhlIGtleSBpdGVtcyBvZiBub3RlIGFyZToNCg0KwrcgICAgICAgIFRoZSBy ZWxlYXNlIG9mIHR3byBmb3JtYWwgc3BlY2lmaWNhdGlvbnMgZm9yIHRoZSBDeWJPWCBsYW5ndWFn ZSAob25lIGZvciB0aGUgY29yZSBsYW5ndWFnZSBhbmQgb25lIGZvciB0aGUgZGVmaW5lZCBvYmpl Y3RzKQ0KDQrCtyAgICAgICAgVGhlIFhNTCBTY2hlbWEgaGFzIGdvbmUgdGhyb3VnaCBleHRlbnNp dmUgaW1wcm92ZW1lbnRzIGZvciBleHByZXNzaXZlbmVzcywgY2xhcml0eSwgY29uc2lzdGVuY3ks IGVmZmljaWVuY3ksIGFsaWdubWVudCB0byBleGlzdGluZyBub3JtYXRpdmUgcmVmZXJlbmNlcyBh bmQgZG9jdW1lbnRhdGlvbi4NCg0KwrcgICAgICAgIFRoaXMgcmVsZWFzZSBpbmNsdWRlcyBhbiBp bml0aWFsIHNldCBvZiBsYW5ndWFnZSB1dGlsaXRpZXM6IGEgZHJhZnQgU25vcnQgLT4gQ3liT1gg dHJhbnNmb3JtLCBhIGRyYWZ0IE9wZW5JT0MgLT4gQ3liT1ggdHJhbnNmb3JtLCBhbmQgYSBzZXQg b2YgUHl0aG9uIGJpbmRpbmdzIGZvciB0aGUgQ3liT1ggbGFuZ3VhZ2UuDQoNCsK3ICAgICAgICBU aGUgd2Vic2l0ZSBub3cgaW5jbHVkZXMgYSBzbWFsbCBzZXQgb2YgY29udGVudCBleGFtcGxlcy4g VGhpcyBzZXQgd2lsbCBncm93IGdvaW5nIGZvcndhcmQuDQoNClRoaXMgcmVsZWFzZSBpbnZvbHZl ZCBhIGxvdCBvZiBoYXJkIHdvcmsgZnJvbSBhIGRpdmVyc2UgZ3JvdXAgb2YgcGVvcGxlLiBUaGFu ayB5b3UgYWxsIGZvciB5b3VyIGNvbnRyaWJ1dGlvbnMgYW5kIGVmZm9ydC4gV2UgY291bGQgbm90 IGhhdmUgZG9uZSBpdCB3aXRob3V0IHlvdS4NCg0KV2UgbG9vayBmb3J3YXJkIHRvIGV2ZXJ5b25l 4oCZcyBmZWVkYmFjayBhbmQgY29sbGFib3JhdGlvbiBhcyB3ZSBjb250aW51ZSB0byBpbXByb3Zl IGFuZCBtYXR1cmUgdGhlIEN5Yk9YIGxhbmd1YWdlLg0KDQogDQoNClNlYW4gQmFybnVtDQoNCiAN Cg0KIA0KDQogDQoNCkN5Yk9YIHYxLjAgKERyYWZ0KSBSZWxlYXNlIE5vdGVzDQoNClRoZSBWZXJz aW9uIDEuMCAoRHJhZnQpIHJlbGVhc2Ugb2YgQ3liZXIgT2JzZXJ2YWJsZSBlWHByZXNzaW9uIChD eWJPWOKEoikgaXMgaW50ZW5kZWQgYXMgYSBkcmFmdCByZWxlYXNlIG9mIGFuIGluaXRpYWwgbWFq b3IgdmVyc2lvbiBvZiB0aGUgQ3liT1ggTGFuZ3VhZ2UgdGhhdCBjb3VsZCBiZSB1dGlsaXplZCBm b3IgcHJhY3RpY2FsIG9wZXJhdGlvbmFsIHVzZSBhbmQgaW50ZWdyYXRpb24gaW50byBvdGhlciBz dGFuZGFyZHMgZWZmb3J0cy4gVGhpcyByZWxlYXNlIGNvbnNpc3RzIG9mIHRocmVlIHByaW1hcnkg Y29tcG9uZW50czogYSBwYWlyIG9mIGZvcm1hbCBsYW5ndWFnZSBzcGVjaWZpY2F0aW9ucyBmb3Ig dGhlIGNvcmUgbGFuZ3VhZ2UgY29udGVudCBhbmQgZGVmaW5lZCBvYmplY3RzIGNvbnRlbnQsIGEg c2V0IG9mIGxhbmd1YWdlIGltcGxlbWVudGF0aW9uIFhNTCBzY2hlbWFzIChjb3JlLCBjb21tb25f dHlwZXMsIGFuZCB+NzAgZGVmaW5lZCBvYmplY3Qgc2NoZW1hcyksIGFuZCBhIHNtYWxsIGluaXRp YWwgc2V0IG9mIGxhbmd1YWdlIHV0aWxpdGllcyBpbmNsdWRpbmcgYW4gaW5pdGlhbCBkcmFmdCBT bm9ydC0+Q3liT1ggdHJhbnNmb3JtLCBhbiBpbml0aWFsIGRyYWZ0IE9wZW5JT0MtPkN5Yk9YIHRy YW5zZm9ybSBhbmQgYSBzZXQgb2YgQ3liT1ggbGFuZ3VhZ2UgUHl0aG9uIGJpbmRpbmdzLiBSZWNv Z25pemluZyB0aGF0IHRoaXMgaXMgdGhlIGZpcnN0IHRpbWUgdGhhdCB0aGUgZm9ybWFsIGxhbmd1 YWdlIHNwZWNpZmljYXRpb25zIHdpbGwgYmUgYXZhaWxhYmxlIGZvciByZXZpZXcgYW5kIGFzIHN1 Y2ggd2lsbCBsaWtlbHkgZ2VuZXJhdGUgZmVlZGJhY2sgZnJvbSBuZXcgc3Rha2Vob2xkZXJzLCB0 aGlzIGluaXRpYWwgbWFqb3IgdmVyc2lvbiBpcyBiZWluZyByZWxlYXNlZCBhcyBhIOKAnGRyYWZ0 4oCdIHYxLjAgd2l0aCB0aGUgZXhwZWN0YXRpb24gb2YgY3ljbGVzIG9mIG5ldyBmZWVkYmFjayBh bmQgcmV2aXNpb24gYmVmb3JlIGEg4oCcZmluYWzigJ0gdjEuMCBpcyByZWxlYXNlZC4NCg0KVGhl IEN5Yk9YIHYxLjAgKERyYWZ0KSBYTUwgc2NoZW1hcyBpbmNsdWRlIGEgc2lnbmlmaWNhbnQgbnVt YmVyIG9mIGNoYW5nZXMgZnJvbSB2MC43IHRvIGltcHJvdmU6DQoNCsK3ICAgICAgIENsYXJpdHks IGRvY3VtZW50YXRpb24sIGFuZCBkZXNjcmlwdGl2ZSBmb3JtYWxpdHkgZm9yIHJlZmVyZW5jZSBh bmQgaW1wbGVtZW50YXRpb24gYnkgb3RoZXIgc3RhbmRhcmRzIGFuZCB1c2Vycy4NCg0KwrcgICAg ICAgQ29uc2lzdGVuY3ksIHNpbXBsaWNpdHksIGFuZCBlZmZpY2llbmN5Lg0KDQrCtyAgICAgICBB bGlnbm1lbnQgKGFzIGFwcHJvcHJpYXRlKSB0byBleGlzdGluZyBub3JtYXRpdmUgcmVmZXJlbmNl cy4NCg0KwrcgICAgICAgRXhwcmVzc2l2ZW5lc3Mgb2YgdGhlIHNjaGVtYSB0byBiZXR0ZXIgc3Vw cG9ydCB0aGUgYnJvYWQgc2V0IG9mIHVzZSBjYXNlcyBpdCB0YXJnZXRzIChtYWx3YXJlIGNoYXJh Y3Rlcml6YXRpb24sIGluZGljYXRvciBhbmQgaW5jaWRlbnQgZGF0YSBzaGFyaW5nLCBldmVudCBt YW5hZ2VtZW50LCBldGMuKSBpbmNsdWRpbmcgdGhlIGFkZGl0aW9uIG9mIGFuIGluaXRpYWwgc2V0 IG9mIG5ldHdvcmstcmVsYXRlZCBkZWZpbmVkIG9iamVjdHMuDQoNClN1bW1hcnkgb2YgY2hhbmdl cyBmcm9tIEN5Yk9YX3YwLjcgdG8gQ3liT1hfdjEuMF8oRHJhZnQpOg0KDQrCtyAgICAgICAgIFJl ZmluZW1lbnQgb2YgbmFtZXNwYWNlcyBhbmQgc2NoZW1hIGxvY2F0aW9ucyBmb3IgYmV0dGVyIGVm ZmVjdGl2ZW5lc3MgYW5kIGZsZXhpYmlsaXR5IGdvaW5nIGZvcndhcmQuDQoNCsK3ICAgICAgICAg Tm9ybWFsaXplZCBhbGwgY29udGVudCBhY2NvcmRpbmcgdG8gYW4gZXN0YWJsaXNoZWQgc2V0IG9m IG5hbWluZyBjb252ZW50aW9ucy4NCg0KwrcgICAgICAgICBGdWxseSBhbm5vdGF0ZWQgYWxsIGxh bmd1YWdlIGl0ZW1zICh0eXBlcywgYXR0cmlidXRlcywgZWxlbWVudHMsIGV0Yy4pLg0KDQrCtyAg ICAgICAgIE1vdmVkIHNldmVyYWwgY29tbW9ubHkgbGV2ZXJhZ2VkIHR5cGVzIG91dCBvZiB0aGUg Y29yZSBzY2hlbWEgYW5kIGludG8gY29tbW9uX3R5cGVzLg0KDQrCtyAgICAgICAgIEFjaGlldmVk IGZ1bGwgdHlwaW5nIG9mIGVudGlyZSBzY2hlbWEgc3RydWN0dXJlIHN1Y2ggdGhhdCBhbGwgYXR0 cmlidXRlcyBhbmQgZWxlbWVudHMgYXJlIGRlZmluaXRpdmVseSB0eXBlZC4NCg0KwrcgICAgICAg ICBDaGFuZ2VkIGFsbCBpZGVudGlmaWVycyBmcm9tIElEIGFuZCBJRFJFRiB0eXBlcyB0byBiZSBR TmFtZXMgZW5hYmxpbmcgZ2xvYmFsbHkgdW5pcXVlIGlkZW50aWZpZXJzIGFuZCBmbGV4aWJpbGl0 eSBmb3IgZG9tYWluLXNwZWNpZmljIHVzZXJzIG9mIEN5Yk9YIHRvIGRlZmluZSB0aGVpciBvd24g aWRlbnRpZmllciBzeW50YXggbG9jYWxseS4NCg0KwrcgICAgICAgICBSZW9yZGVyZWQgYXR0cmli dXRlcyBhbmQgZWxlbWVudHMgaW4gbnVtZXJvdXMgdHlwZXMgdG8gYmV0dGVyIHJlZmxlY3QgY29t bW9uIHVzYWdlIGFuZCBwcmlvcml0eS4NCg0KwrcgICAgICAgICBBZGRlZCBtYWpvcl92ZXJzaW9u IGFuZCBtaW5vcl92ZXJzaW9uIGF0dHJpYnV0ZXMgZm9yIGNvcmUgc2NoZW1hLg0KDQrCtyAgICAg ICAgIEFkZGVkIGNhcGFiaWxpdHkgdG8gY2hhcmFjdGVyaXplIHNvdXJjZSBvZiBvdmVyYWxsIG9i c2VydmFibGUgcGFja2FnZSBkYXRhIGFuZCBmb3IgaW5kaXZpZHVhbCBvYnNlcnZhYmxlcy4NCg0K wrcgICAgICAgICBNb2RpZmllZCB0aGUgbG9naWNhbCBjb21wb3NpdGlvbiBzdHJ1Y3R1cmUgc3Vj aCB0aGF0IGFueSBzdWNoIGNvbXBvc2l0aW9ucyBhcmUgbm93IGNvbnRhaW5lZCB3aXRoaW4gYSBP YnNlcnZhYmxlX0NvbXBvc2l0aW9uIGVsZW1lbnQgcHJvdmlkaW5nIGltcHJvdmVkIHNpbXBsaWNp dHkgYW5kIG1vZHVsYXJpdHkuDQoNCsK3ICAgICAgICAgUmVtb3ZlZCB0aGUgRGVsdGEgZWxlbWVu dCBmcm9tIE9ic2VydmFibGVUeXBlIGFuZCByZWxvY2F0ZWQgdGhlIGFwcHJvcHJpYXRlIHBvcnRp b25zIChDaGFuZ2UsIFRyZW5kLCBhbmQgRnJlcXVlbmN5KSB0byBhcHByb3ByaWF0ZSBsb2NhdGlv bnMgdW5kZXIgU3RhdGVmdWxfTWVhc3VyZSBhbmQgRXZlbnQuDQoNCsK3ICAgICAgICAgQWRkZWQg YSBEb21haW5fU3BlY2lmaWNfT2JqZWN0X0F0dHJpYnV0ZXMgZmllbGQgdG8gT2JqZWN0IHV0aWxp emluZyBhbiBhYnN0cmFjdCB0eXBlIHRoYXQgd2lsbCBhbGxvdyBkb21haW4tc3BlY2lmaWMgdXNl IGNhc2VzIHRvIGFkZCBpbiB0aGVpciBvd24gZG9tYWluLXNwZWNpZmljIGF0dHJpYnV0ZXMgZm9y IE9iamVjdHMuDQoNCsK3ICAgICAgICAgQWRkZWQgYSBUb29sLVNwZWNpZmljX0RhdGEgZmllbGQg dG8gVG9vbEluZm9ybWF0aW9uVHlwZSB1dGlsaXppbmcgYW4gYWJzdHJhY3QgdHlwZSB0aGF0IHdp bGwgYWxsb3cgYWRkaXRpb24gb2YgdG9vbC1zcGVjaWZpYyBkYXRhLg0KDQrCtyAgICAgICAgIEFk ZGVkIGFuIEluZGljYXRvcnMgZmllbGQgdG8gTWVhc3VyZVNvdXJjZVR5cGUgdXRpbGl6aW5nIGFu IGFic3RyYWN0IHR5cGUgdGhhdCB3aWxsIGFsbG93IGNoYXJhY3Rlcml6aW5nIGRpZmZlcmluZyBm b3JtYXRzIG9yIHN0YW5kYXJkcyBvZiBpbmRpY2F0b3JzIHRoYXQgbWF5IGhhdmUgbGVkIHRvIHRo ZSBpZGVudGlmaWNhdGlvbiBvZiB0aGUgb2JzZXJ2YWJsZSBkYXRhLg0KDQrCtyAgICAgICAgIEVu aGFuY2VkIHRoZSBIYXNoIHN0cnVjdHVyZSB0byBjYXB0dXJlIGZ1bGwgZnV6enkgaGFzaGVzIGlu IGFkZGl0aW9uIHRvIHNpbXBsZSBoYXNoZXMNCg0KwrcgICAgICAgICBBZGRlZCBhIG5ldyBFeHRy YWN0ZWRGZWF0dXJlc1R5cGUgdGhhdCBjYW4gYmUgdXNlZCB0byBhZG9ybiBkaWZmZXJpbmcgb2Jq ZWN0cyAoZS5nLiwgZmlsZXMsIG1lbW9yeSwgZXRjLikgdG8gY2FwdHVyZSBleHRyYWN0ZWQgc3Ry aW5ncywgaW1wb3J0cywgZnVuY3Rpb25zIGFuZCBjb2RlIHNuaXBwZXRzDQoNCsK3ICAgICAgICAg QWRkZWQgYSBCeXRlUnVuc1R5cGUgdG8gZW5hYmxlIGNhcHR1cmUgb2YgYnl0ZSBydW5zIHdpdGhp biB2YXJpb3VzIG9iamVjdHMuDQoNCsK3ICAgICAgICAgQWRkZWQgb2JqZWN0X3JlZmVyZW5jZSBh dHRyaWJ1dGUgdG8gRGVmaW5lZE9iamVjdFR5cGUgdG8gYmV0dGVyIHN1cHBvcnQgcmVmZXJlbmNp bmcgb2YgaW5kZXBlbmRlbnRseSBkZWZpbmVkIE9iamVjdHMgZnJvbSB3aXRoaW4gYW5vdGhlciBP YmplY3QgZGVmaW5pdGlvbi4NCg0KwrcgICAgICAgICBBZGRlZCBhIGdlbmVyaWMgRGF0YVNlZ21l bnRUeXBlIHRvIHByb3ZpZGUgYSByZWxhdGl2ZWx5IGFic3RyYWN0IHdheSBvZiBjaGFyYWN0ZXJp emluZyBkYXRhIHNlZ21lbnRzIHRoYXQgbWF5IGJlIHdyaXR0ZW4vcmVhZC90cmFuc21pdHRlZCBv ciBvdGhlcndpc2UgdXRpbGl6ZWQgaW4gYWN0aW9ucyBvciBkZWZpbmVkIGluIG9iamVjdHMuDQoN CsK3ICAgICAgICBBZGRlZCBzZXZlcmFsIG5ldyBkZWZpbmVkIG9iamVjdCBzY2hlbWFzIChBUEks IENvZGUsIERldmljZSwgRE5TX1JlY29yZCwgTmV0d29ya19GbG93LCBOZXR3b3JrX1BhY2tldCwg TmV0d29ya19Sb3V0ZV9FbnRyeSwgTmV0d29ya19TdWJuZXQsIFVuaXhfTmV0d29ya19Sb3V0ZV9F bnRyeSkgaW5jbHVkaW5nIGFuIGluaXRpYWwgc2V0IG9mIG5ldHdvcmstY2VudHJpYyBkZWZpbmVk IG9iamVjdHMuDQoNCsK3ICAgICAgICAgTW9kaWZpZWQgZXZlcnkgZGVmaW5lZCBvYmplY3Qgc2No ZW1hIHdpdGggYWRkZWQgYW5ub3RhdGlvbnMgYXMgd2VsbCBhcyBtaW5vciBhbmQgaW4gc29tZSBj YXNlcyBzdWJzdGFudGl2ZSBjaGFuZ2VzIHRvIGZpeCBlcnJvcnMsIGltcHJvdmUgY29uc2lzdGVu Y3kgYW5kIGFsaWdubWVudCB3aXRoIGV4aXN0aW5nIG5vcm1hdGl2ZSByZWZlcmVuY2VzLCBhbmQg dG8gaW1wcm92ZSBleHByZXNzaXZlbmVzcyBpbiBzdXBwb3J0IG9mIHRoZSB0YXJnZXRlZCB1c2Ug Y2FzZXMuDQoNCkRldGFpbGVkIGNoYW5nZXMgZnJvbSBDeWJPWF92MC43IHRvIEN5Yk9YX3YxLjBf KERyYWZ0KToNCg0KVGhlIGxldmVsIG9mIGNoYW5nZXMgd2l0aGluIHYxLjAgKERyYWZ0KSBpbiB0 aGUgY29yZSBzY2hlbWEsIGNvbW1vbl90eXBlcyBhbmQgdGhlIGRlZmluZWQgb2JqZWN0IHNjaGVt YXMgaXMgdG9vIGdyZWF0IHRvIGxpc3QgZXZlcnkgY2hhbmdlIGluIHRoZXNlIHJlbGVhc2Ugbm90 ZXMuIERldGFpbGVkIGRpZmZlcmVuY2UgcmVwb3J0cyBhcmUgYXZhaWxhYmxlIGZvciBlYWNoIGlu ZGl2aWR1YWwgc2NoZW1hIGF0Omh0dHA6Ly9jeWJveC5taXRyZS5vcmcvWE1MU2NoZW1hL3JlbGVh c2Vfbm90ZXMvY3lib3hfdjEuMChkcmFmdClfZGlmZl9yZXBvcnRzLnppcCA8aHR0cDovL2N5Ym94 Lm1pdHJlLm9yZy9YTUxTY2hlbWEvcmVsZWFzZV9ub3Rlcy9jeWJveF92MS4wKGRyYWZ0KV9kaWZm X3JlcG9ydHMuemlwPiANCg0KIA0KDQogDQoNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09DQoNClNlYW4gQmFybnVtDQoNCkN5YmVyIFNlY3VyaXR5IFByaW5j aXBhbA0KDQpUaGUgTUlUUkUgQ29ycG9yYXRpb24NCg0KRW1haWw6IHNiYXJudW1AbWl0cmUub3Jn DQoNCiANCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cm1pbGUgbWFpbGluZyBsaXN0DQptaWxlQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL21pbGUNCg0KIA0KDQo= ------_=_NextPart_001_01CD1C4E.2F4B01A2 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PGJhc2UgaHJlZj0ieC1tc2c6 Ly8yMDEyLyI+PHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEg NiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FtYnJpYTsNCglw YW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KcC5N c29UaXRsZSwgbGkuTXNvVGl0bGUsIGRpdi5Nc29UaXRsZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6 MTA7DQoJbXNvLXN0eWxlLWxpbms6IlRpdGxlIENoYXIiOw0KCW1zby1tYXJnaW4tdG9wLWFsdDph dXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJ bWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFBy ZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5Nc29B Y2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGlu Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1p bHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlz dFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0 Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4w cHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLkhUTUxQ cmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFy IjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9y bWF0dGVkIjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uVGl0bGVDaGFyDQoJ e21zby1zdHlsZS1uYW1lOiJUaXRsZSBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6MTA7DQoJ bXNvLXN0eWxlLWxpbms6VGl0bGU7DQoJZm9udC1mYW1pbHk6IkNhbWJyaWEiLCJzZXJpZiI7DQoJ Y29sb3I6IzE3MzY1RDsNCglsZXR0ZXItc3BhY2luZzouMjVwdDt9DQpzcGFuLmFwcGxlLXN0eWxl LXNwYW4NCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtc3R5bGUtc3Bhbjt9DQpzcGFuLmFwcGxlLWNv bnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0K c3Bhbi5FbWFpbFN0eWxlMjQNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxT dHlsZTI1DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyNg0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNv LXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIs InNhbnMtc2VyaWYiO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41 aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNl Y3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBs aXN0IGwwDQoJe21zby1saXN0LWlkOjExMjU2NTYwMjA7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRz Oi04MTgwMjAxOTY7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4w aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDkN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDoxMzM1MjMxNTMx Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxMTczMTQ4NDMyO30NCkBsaXN0IGwxOmxldmVsMQ0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K CW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDE6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw0 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2 ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpT eW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0Kb2wNCgl7bWFy Z2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNw aWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBk YXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPjwvaGVhZD48Ym9k eSBsYW5nPUVOLVVTIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+PGRpdiBjbGFzcz1Xb3JkU2VjdGlv bjE+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SSBiZWxpZXZlIHRo YXQgd2hhdCBTZWFuIGlzIHNheWluZyBpcyB0aGF0IOKAnGRhdGEgZmxvd+KAnSBpcyBqdXN0IGEg dmFsdWUgdGhhdCBpcyBtZWFudCBmb3IgdXBwZXIgbGF5ZXIgcHJvdG9jb2xzLiBCdXQsIHlvdSBo YXZlIGEgZ29vZCBwb2ludC4gVHJhZGl0aW9uYWxseSwgYSDigJxmbG934oCdIGluIOKAnE5ldGZs b3figJ0gaXMgYmFzZWQgb24gYSBzZXQgb2YgNSBhbmQgdXAgdG8gNyBJUCBwYWNrZXQgYXR0cmli dXRlczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29s b3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPi0gSVAgc291cmNlIGFkZHJlc3M8bzpwPjwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+LSBJUCBk ZXN0aW5hdGlvbiBhZGRyZXNzPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPi0gU291cmNlIHBvcnQ8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+LSBEZXN0aW5hdGlv biBwb3J0PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2Nv bG9yOiMxRjQ5N0QnPi0gTGF5ZXIgMyBwcm90b2NvbCB0eXBlPG86cD48L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPi0gQ2xhc3Mgb2YgU2Vy dmljZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xv cjojMUY0OTdEJz4tIFJvdXRlciBvciBzd2l0Y2ggaW50ZXJmYWNlPG86cD48L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdE Jz5BbHRob3VnaCwgdGhlcmUgaXMgYSBsb3QgbW9yZSBzdXBwb3J0IHdpdGggTmV0ZmxvdyB2ZXJz aW9uIDk6PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48YSBocmVmPSJo dHRwOi8vd3d3LmNpc2NvLmNvbS9lbi9VUy90ZWNobm9sb2dpZXMvdGs2NDgvdGszNjIvdGVjaG5v bG9naWVzX3doaXRlX3BhcGVyMDkxODZhMDA4MDBhM2RiOV9wczY2MDFfUHJvZHVjdHNfV2hpdGVf UGFwZXIuaHRtbCI+aHR0cDovL3d3dy5jaXNjby5jb20vZW4vVVMvdGVjaG5vbG9naWVzL3RrNjQ4 L3RrMzYyL3RlY2hub2xvZ2llc193aGl0ZV9wYXBlcjA5MTg2YTAwODAwYTNkYjlfcHM2NjAxX1By b2R1Y3RzX1doaXRlX1BhcGVyLmh0bWw8L2E+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjojMUY0 OTdEJz5SZWdhcmRzLDxicj48YnI+T21hciA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPjxkaXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj QjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4nPjxwIGNsYXNzPU1zb05vcm1h bD48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwi c2Fucy1zZXJpZiInPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPiBNaWxsYXIsIFRob21hcyBbbWFp bHRvOlRob21hcy5NaWxsYXJAaHEuZGhzLmdvdl0gPGJyPjxiPlNlbnQ6PC9iPiBNb25kYXksIEFw cmlsIDE2LCAyMDEyIDExOjQ2IFBNPGJyPjxiPlRvOjwvYj4gc2Jhcm51bUBtaXRyZS5vcmc7IE9t YXIgU2FudG9zIChvc2FudG9zKTsgbG51bmV6QGMzaXNlY3VyaXR5LmNvbTxicj48Yj5DYzo8L2I+ IGlkeHdnQG5pY3dnLm9yZzsgbWlsZUBpZXRmLm9yZzsgZGFsbGVuZG91Z0BnbWFpbC5jb207IHNh Y21AaWV0Zi5vcmc7IG0tdGVyYWRhQGlwYS5nby5qcDxicj48Yj5TdWJqZWN0OjwvYj4gUmU6IFtz YWNtXSBbbWlsZV0gQ3liT1ggdjEuMCAoRHJhZnQpIGlzIG5vdyByZWxlYXNlZCBhbmQgbGl2ZSBv bnRoZSB3ZWJzaXRlPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1z b05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjojMUY0OTdEJz5JZiAmcXVvdDtkYXRhIGZsb3cmcXVvdDsgaXMgYSBldXBoZW1pc20gZm9y ICZxdW90O25ldGZsb3cmcXVvdDsgaXMgdGhlcmUgYW55IHJlYXNvbiBub3QgdG8gY2FsbCBpdCB0 aGF0Pzxicj48YnI+VG9tIE1pbGxhciA8YnI+PGEgaHJlZj0iaHR0cDovL3d3dy51cy1jZXJ0Lmdv di8iPmh0dHA6Ly93d3cudXMtY2VydC5nb3YvPC9hPiA8YnI+LS0tLS0tLS0tLS0tLS0tLS0tIDxi cj5NaXNzaXQgbWUgUnVidXMgZnJ1dGljb3N1czogPGJyPjIwMiA2MzEgMTkxNSA8YnI+PC9zcGFu Pjxicj4mbmJzcDs8bzpwPjwvbzpwPjwvcD48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbic+PHAgY2xh c3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJvbTwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz46IEJhcm51bSwg U2VhbiBELiA8YSBocmVmPSJtYWlsdG86W21haWx0bzpzYmFybnVtQG1pdHJlLm9yZ10iPlttYWls dG86c2Jhcm51bUBtaXRyZS5vcmddPC9hPiA8YnI+PGI+U2VudDwvYj46IE1vbmRheSwgQXByaWwg MTYsIDIwMTIgMTE6MjkgUE08YnI+PGI+VG88L2I+OiBPbWFyIFNhbnRvcyAob3NhbnRvcykgJmx0 OzxhIGhyZWY9Im1haWx0bzpvc2FudG9zQGNpc2NvLmNvbSI+b3NhbnRvc0BjaXNjby5jb208L2E+ Jmd0OzsgTHVpcyBOdW5leiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxudW5lekBjM2lzZWN1cml0eS5j b20iPmxudW5lekBjM2lzZWN1cml0eS5jb208L2E+Jmd0OyA8YnI+PGI+Q2M8L2I+OiA8YSBocmVm PSJtYWlsdG86aWR4d2dAbmljd2cub3JnIj5pZHh3Z0BuaWN3Zy5vcmc8L2E+ICZsdDs8YSBocmVm PSJtYWlsdG86aWR4d2dAbmljd2cub3JnIj5pZHh3Z0BuaWN3Zy5vcmc8L2E+Jmd0OzsgPGEgaHJl Zj0ibWFpbHRvOm1pbGVAaWV0Zi5vcmciPm1pbGVAaWV0Zi5vcmc8L2E+ICZsdDs8YSBocmVmPSJt YWlsdG86bWlsZUBpZXRmLm9yZyI+bWlsZUBpZXRmLm9yZzwvYT4mZ3Q7OyA8YSBocmVmPSJtYWls dG86ZGFsbGVuZG91Z0BnbWFpbC5jb20iPmRhbGxlbmRvdWdAZ21haWwuY29tPC9hPiAmbHQ7PGEg aHJlZj0ibWFpbHRvOmRhbGxlbmRvdWdAZ21haWwuY29tIj5kYWxsZW5kb3VnQGdtYWlsLmNvbTwv YT4mZ3Q7OyA8YSBocmVmPSJtYWlsdG86c2FjbUBpZXRmLm9yZyI+c2FjbUBpZXRmLm9yZzwvYT4g Jmx0OzxhIGhyZWY9Im1haWx0bzpzYWNtQGlldGYub3JnIj5zYWNtQGlldGYub3JnPC9hPiZndDs7 IDxhIGhyZWY9Im1haWx0bzptLXRlcmFkYUBpcGEuZ28uanAiPm0tdGVyYWRhQGlwYS5nby5qcDwv YT4gJmx0OzxhIGhyZWY9Im1haWx0bzptLXRlcmFkYUBpcGEuZ28uanAiPm0tdGVyYWRhQGlwYS5n by5qcDwvYT4mZ3Q7IDxicj48Yj5TdWJqZWN0PC9iPjogUmU6IFtzYWNtXSBbbWlsZV0gQ3liT1gg djEuMCAoRHJhZnQpIGlzIG5vdyByZWxlYXNlZCBhbmQgbGl2ZSBvbnRoZSB3ZWJzaXRlIDxicj48 L3NwYW4+Jm5ic3A7PG86cD48L286cD48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7Y29sb3I6IzFGNDk3RCc+VGhhbmtzIE9tYXIuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5UbyBhbnN3 ZXIgeW91ciBxdWVzdGlvbiwgZmlyc3QgbGV0IG1lIHBvaW50IG91dCB0byBvdGhlciByZWFkZXJz IHRoYXQgdGhlIHR3byBlbnRyaWVzIHRoYXQgT21hciBpcyBxdW90aW5nIGhlcmUgZXhpc3QgYXMg dmFsdWVzIGluIGFuIGVudW1lcmF0aW9uIGNhbGxlZCBFdmVudFR5cGVFbnVtIHdoaWNoIGFzIGl0 cyBuYW1lIGltcGxpZXMgY29udGFpbnMgYSBsaXN0IG9mIGRpZmZlcmVudCBsYWJlbHMgZm9yIGdy b3VwaW5nIHR5cGVzIChvciBjbGFzc2VzKSBvZiBldmVudHMgdG8gYmUgdXNlZCBhcyBsb3ctZ3Jh bnVsYXJpdHkgYnVja2V0cyBmb3IgY2hhcmFjdGVyaXppbmcgYW5kIGNsYXNzaWZ5aW5nIGV2ZW50 cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6 IzFGNDk3RCc+T3RoZXIgZW50cmllcyBpbiB0aGlzIGVudW1lcmF0aW9uIGluY2x1ZGUgdGhpbmdz IGxpa2Ug4oCcRmlsZSBPcHMgKENSVUQp4oCdLCDigJxQcm9jZXNzIE1ndOKAnSwg4oCcQXV0aG9y aXphdGlvbiAoQUNMKeKAnSwgZXRjLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+VGhlIOKAnFBhY2tldCBU cmFmZmlj4oCdIHZhbHVlIGlzIGludGVuZGVkIHRvIGNoYXJhY3Rlcml6ZSBldmVudHMgZGVhbGlu ZyB3aXRoIG5ldHdvcmsgcGFja2V0IHRyYWZmaWMgYXMgaXRzIG5hbWUgaW1wbGllcy48bzpwPjwv bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+ VGhlIOKAnERhdGEgRmxvd+KAnSB2YWx1ZSBpcyBpbnRlbmRlZCB0byBjaGFyYWN0ZXJpemUgZXZl bnRzIGRlYWxpbmcgd2l0aCBmb3JtcyBvZiBkYXRhIGZsb3cgYXQgYSBoaWdoZXIgbGV2ZWwgb2Yg YWJzdHJhY3Rpb24gdGhhbiBqdXN0IHBhY2tldCB0cmFmZmljLiBUaGUgcmVsYXRpb25zaGlwIGJl dHdlZW4gdGhlc2UgdHdvIHZhbHVlcyBjb3VsZCBiZSB2aWV3ZWQgYXMg4oCcUGFja2V0IFRyYWZm aWPigJ0gYmVpbmcgYSBtb3JlIGRldGFpbGVkIGZvcm0gb2Yg4oCcRGF0YSBGbG934oCdIGp1c3Qg YXMgdGhlIHZhbHVlcyDigJxBcHAgTGF5ZXIgVHJhZmZpY+KAnSBhbmQg4oCcSFRUUCBMYXllciBU cmFmZmlj4oCdLCBhbHNvIGluIHRoaXMgZW51bWVyYXRpb24sIGNvdWxkIGJlIG90aGVyIGxldmVs cyBpbiB0aGlzIHNhbWUgYWJzdHJhY3Rpb24gc3RhY2suPG86cD48L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlRoZSBpZGVhIGJlaGluZCB0 aGUgdmFyeWluZyBsZXZlbHMgb2YgYWJzdHJhY3Rpb24gaXMgdG8gbGVhdmUgJm5ic3A7YnVja2V0 cyBsYXJnZSBlbm91Z2ggdG8gY2FwdHVyZSBhIHdpZGUgdmFyaWV0eSBvZiBwb3RlbnRpYWwgZXZl bnQgdHlwZXMgKGUuZy4gZGF0YSBmbG93IGV2ZW50cyBvdGhlciB0aGFuIG9idmlvdXMgdGhpbmdz IGxpa2UgcGFja2V0IHRyYWZmaWMpIGJ1dCBhbHNvIGVuYWJsZSB0aGUgdXNlIG9mIHNtYWxsZXIg bW9yZSBzcGVjaWZpYyBidWNrZXRzIHdoZW4gdGhleSBhcmUgYXBwcm9wcmlhdGUgYW5kIGNvbW1v bmx5IHVzZWQuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5Eb2VzIHRoaXMgbWFrZSBzZW5zZT8gPG86cD48 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0Qn PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjojMUY0OTdEJz5zZWFuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2 PjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtw YWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluJz48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdp bi1sZWZ0Oi41aW4nPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+IE9tYXIgU2Fu dG9zIChvc2FudG9zKSA8YSBocmVmPSJtYWlsdG86W21haWx0bzpvc2FudG9zQGNpc2NvLmNvbV0i PlttYWlsdG86b3NhbnRvc0BjaXNjby5jb21dPC9hPiA8YnI+PGI+U2VudDo8L2I+IE1vbmRheSwg QXByaWwgMTYsIDIwMTIgODoxNyBQTTxicj48Yj5Ubzo8L2I+IEx1aXMgTnVuZXo7IEJhcm51bSwg U2VhbiBELjxicj48Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzppZHh3Z0BuaWN3Zy5vcmciPmlk eHdnQG5pY3dnLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzptaWxlQGlldGYub3JnIj5taWxlQGll dGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOmRhbGxlbmRvdWdAZ21haWwuY29tIj5kYWxsZW5k b3VnQGdtYWlsLmNvbTwvYT47IDxhIGhyZWY9Im1haWx0bzpzYWNtQGlldGYub3JnIj5zYWNtQGll dGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOm0tdGVyYWRhQGlwYS5nby5qcCI+bS10ZXJhZGFA aXBhLmdvLmpwPC9hPjxicj48Yj5TdWJqZWN0OjwvYj4gUkU6IFtzYWNtXSBbbWlsZV0gQ3liT1gg djEuMCAoRHJhZnQpIGlzIG5vdyByZWxlYXNlZCBhbmQgbGl2ZSBvbnRoZSB3ZWJzaXRlPG86cD48 L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFy Z2luLWxlZnQ6LjVpbic+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSdtYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkkgZWNobyBMdWlz 4oCZIGNvbW1lbnRzLiBJdCBpcyBnb29kIHRvIHNlZSB0aGUgaW5jbHVzaW9uIG9mIG5ldHdvcmsg b2JqZWN0cy4gUXVpY2sgcXVlc3Rpb24gdG8gdGhlIHRlYW0gcmVsYXRlZCB0byB5b3VyIG5ldGZs b3cgY29tbWVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSdtYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4n PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SSBhbSBsb29raW5nIGF0OjxvOnA+PC9vOnA+PC9zcGFu PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 Y29sb3I6IzFGNDk3RCc+PGEgaHJlZj0iaHR0cDovL2N5Ym94Lm1pdHJlLm9yZy9YTUxTY2hlbWEv Y3lib3hfY29yZV92MS4wJTI4ZHJhZnQlMjkueHNkIj5odHRwOi8vY3lib3gubWl0cmUub3JnL1hN TFNjaGVtYS9jeWJveF9jb3JlX3YxLjAlMjhkcmFmdCUyOS54c2Q8L2E+PG86cD48L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm Ijtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPuKA piBhbmQgaXQgbG9va3MgdGhhdCB3ZSByZW5hbWVkIGl0IHRvIOKAnERhdGEgRmxvd+KAnT88bzpw PjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDou NWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZsdDt4czplbnVtZXJh dGlvbiB2YWx1ZT0mcXVvdDtEYXRhIEZsb3cmcXVvdDsmZ3Q7PG86cD48L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jm5ic3A7Jm5ic3A7 ICZsdDt4czphbm5vdGF0aW9uJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmbHQ7eHM6ZG9jdW1lbnRhdGlvbiZndDtTcGVjaWZpZXMgdGhlIGNs YXNzIG9mIGV2ZW50cyBkZWFsaW5nIHdpdGggZGF0YSBmbG93LiZsdDsveHM6ZG9jdW1lbnRhdGlv biZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJn aW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToi Q291cmllciBOZXciJz4mbmJzcDsmbmJzcDsgJmx0Oy94czphbm5vdGF0aW9uJmd0OzxvOnA+PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4n PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIn PiZsdDsveHM6ZW51bWVyYXRpb24mZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6 LjVpbic+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5XaGF0IGlzIHRoZSBkaWZmZXJlbmNlIGJldHdl ZW4gdGhhdCBhbmQg4oCcUGFja2V0IFRyYWZmaWPigJ0/PG86cD48L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjoj MUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHByZSBzdHlsZT0nbWFyZ2luLWxl ZnQ6LjVpbic+Jmx0O3hzOmVudW1lcmF0aW9uIHZhbHVlPSZxdW90O1BhY2tldCBUcmFmZmljJnF1 b3Q7Jmd0OzxvOnA+PC9vOnA+PC9wcmU+PHByZSBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+Jm5i c3A7Jm5ic3A7ICZsdDt4czphbm5vdGF0aW9uJmd0OzxvOnA+PC9vOnA+PC9wcmU+PHByZSBzdHls ZT0nbWFyZ2luLWxlZnQ6LjVpbic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDt4czpkb2N1 bWVudGF0aW9uJmd0O1NwZWNpZmllcyB0aGUgY2xhc3Mgb2YgZXZlbnRzIGRlYWxpbmcgd2l0aCBw YWNrZXQgdHJhZmZpYy4mbHQ7L3hzOmRvY3VtZW50YXRpb24mZ3Q7PG86cD48L286cD48L3ByZT48 cHJlIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz4mbmJzcDsmbmJzcDsgJmx0Oy94czphbm5vdGF0 aW9uJmd0OzxvOnA+PC9vOnA+PC9wcmU+PHByZSBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+Jmx0 Oy94czplbnVtZXJhdGlvbiZndDs8bzpwPjwvbzpwPjwvcHJlPjxwIGNsYXNzPU1zb05vcm1hbCBz dHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDou NWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6 IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBz dHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1s ZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyI7Y29sb3I6IzFGNDk3RCc+UmVnYXJkcyw8YnI+PGJyPk9tYXIgU2FudG9zPGJyPklu Y2lkZW50IE1hbmFnZXIsIFBTSVJUPGJyPlNlY3VyaXR5IFJlc2VhcmNoIGFuZCBPcGVyYXRpb25z PGJyPkNpc2NvIFN5c3RlbXMsIEluYy48YnI+RW1haWw6IDxhIGhyZWY9Im1haWx0bzpvc0BjaXNj by5jb20iPm9zQGNpc2NvLmNvbTwvYT48YnI+UGhvbmU6ICsxIDkxOSAzOTIgODYzNTxicj5QR1Ag S2V5OiAweDNBRjI3RURDPGJyPjxicj5DaXNjby5jb20gLSA8YSBocmVmPSJodHRwOi8vd3d3LmNp c2NvLmNvbSI+aHR0cDovL3d3dy5jaXNjby5jb208L2E+PGJyPkNpc2NvIFNlY3VyaXR5IEFkdmlz b3JpZXMgYW5kIE5vdGljZXMgLSA8YSBocmVmPSJodHRwOi8vd3d3LmNpc2NvLmNvbS9nby9wc2ly dCI+aHR0cDovL3d3dy5jaXNjby5jb20vZ28vcHNpcnQ8L2E+PGJyPjxicj5UaGlzIGVtYWlsIG1h eSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBmb3IgdGhlIHNv bGU8YnI+dXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQuIEFueSByZXZpZXcsIHVzZSwgZGlz dHJpYnV0aW9uIG9yPGJyPmRpc2Nsb3N1cmUgYnkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0 ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZDxicj5yZWNpcGllbnQgKG9yIGF1dGhvcml6 ZWQgdG8gcmVjZWl2ZSBmb3IgdGhlIHJlY2lwaWVudCksIHBsZWFzZSBjb250YWN0PGJyPnRoZSBz ZW5kZXIgYnkgcmVwbHkgZW1haWwgYW5kIGRlbGV0ZSBhbGwgY29waWVzIG9mIHRoaXMgbWVzc2Fn ZS48YnI+PGJyPkZvciBjb3Jwb3JhdGUgbGVnYWwgaW5mb3JtYXRpb24gZ28gdG86PGJyPjxhIGhy ZWY9Imh0dHA6Ly93d3cuY2lzY28uY29tL3dlYi9hYm91dC9kb2luZ19idXNpbmVzcy9sZWdhbC9j cmkvaW5kZXguaHRtbCI+aHR0cDovL3d3dy5jaXNjby5jb20vd2ViL2Fib3V0L2RvaW5nX2J1c2lu ZXNzL2xlZ2FsL2NyaS9pbmRleC5odG1sPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48 cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6 IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXY+PGRpdiBzdHlsZT0nYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGlu IDBpbiAwaW4nPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PGI+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4gPGEgaHJlZj0ibWFpbHRvOnNhY20tYm91 bmNlc0BpZXRmLm9yZyI+c2FjbS1ib3VuY2VzQGlldGYub3JnPC9hPiA8YSBocmVmPSJtYWlsdG86 W21haWx0bzpzYWNtLWJvdW5jZXNAaWV0Zi5vcmddIj5bbWFpbHRvOnNhY20tYm91bmNlc0BpZXRm Lm9yZ108L2E+IDxiPk9uIEJlaGFsZiBPZiA8L2I+THVpcyBOdW5lejxicj48Yj5TZW50OjwvYj4g TW9uZGF5LCBBcHJpbCAxNiwgMjAxMiA2OjQ0IFBNPGJyPjxiPlRvOjwvYj4gQmFybnVtLCBTZWFu IEQuPGJyPjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOmlkeHdnQG5pY3dnLm9yZyI+aWR4d2dA bmljd2cub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOm1pbGVAaWV0Zi5vcmciPm1pbGVAaWV0Zi5v cmc8L2E+OyBEb3VnIFdpbHNvbiAoPGEgaHJlZj0ibWFpbHRvOmRhbGxlbmRvdWdAZ21haWwuY29t Ij5kYWxsZW5kb3VnQGdtYWlsLmNvbTwvYT4pOyA8YSBocmVmPSJtYWlsdG86c2FjbUBpZXRmLm9y ZyI+c2FjbUBpZXRmLm9yZzwvYT47IElQQS1NYXNhdG8gVGVyYWRhICg8YSBocmVmPSJtYWlsdG86 bS10ZXJhZGFAaXBhLmdvLmpwIj5tLXRlcmFkYUBpcGEuZ28uanA8L2E+KTxicj48Yj5TdWJqZWN0 OjwvYj4gUmU6IFtzYWNtXSBbbWlsZV0gQ3liT1ggdjEuMCAoRHJhZnQpIGlzIG5vdyByZWxlYXNl ZCBhbmQgbGl2ZSBvbnRoZSB3ZWJzaXRlPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2 PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PG86cD4mbmJzcDs8 L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz5JIGxp a2UgdGhlIGluY2x1c2lvbiBvZiB0aGUgbmV0d29yay1jZW50cmljIG9iamVjdHMuICZuYnNwO0lQ RklYIChuZXRmbG93KSAmbmJzcDt3aWxsIGFkZCBhbiBhZGRpdGlvbmFsIHBlcnNwZWN0aXZlIGZy b20gYW4gaW5jaWRlbnQgaW5mb3JtYXRpb24gc2hhcmluZyBzdGFuZHBvaW50LiAmbmJzcDs8bzpw PjwvbzpwPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVp bic+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9J21hcmdpbi1sZWZ0Oi41aW4nPi1sbjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48bzpwPiZuYnNwOzwvbzpwPjwv cD48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz5P biBBcHIgMTYsIDIwMTIsIGF0IDQ6MDQgUE0sIEJhcm51bSwgU2VhbiBELiB3cm90ZTo8bzpwPjwv bzpwPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFs dDowaW47bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjEyLjBwdDttYXJnaW4tbGVmdDou NWluJz48bzpwPiZuYnNwOzwvbzpwPjwvcD48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSdtYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz5IZXkgZXZlcnlvbmUsPG86cD48L286cD48 L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVm dDouNWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPkkganVz dCB3YW50ZWQgdG8gbGV0IHlvdSBhbGwga25vdyB0aGF0IEN5Yk9YIHYxLjAgKERyYWZ0KSBjb250 ZW50IGlzIG5vdyBsaXZlIG9uIHRoZSB3ZWJzaXRlLjxzcGFuIGNsYXNzPWFwcGxlLWNvbnZlcnRl ZC1zcGFjZT4mbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cDovL2N5Ym94Lm1pdHJlLm9yZyI+aHR0 cDovL2N5Ym94Lm1pdHJlLm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPlRoZSBy ZWxlYXNlIG5vdGVzIGFyZSBwcm92aWRlZCBpbmxpbmUgYmVsb3cuPG86cD48L286cD48L3NwYW4+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWlu Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiJz5UaGUga2V5IGl0ZW1zIG9mIG5vdGUgYXJlOjxvOnA+PC9vOnA+PC9zcGFuPjwv cD48L2Rpdj48ZGl2IHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48cCBjbGFzcz1Nc29Ob3JtYWwg c3R5bGU9J21hcmdpbi1sZWZ0Oi41aW47dGV4dC1pbmRlbnQ6LS4yNWluO2xpbmUtaGVpZ2h0OjEy Ljc1cHQnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbCc+ wrc8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo3LjBwdCc+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNl PiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+VGhlIHJlbGVhc2Ugb2YgdHdvIGZvcm1hbCBz cGVjaWZpY2F0aW9ucyBmb3IgdGhlIEN5Yk9YIGxhbmd1YWdlIChvbmUgZm9yIHRoZSBjb3JlIGxh bmd1YWdlIGFuZCBvbmUgZm9yIHRoZSBkZWZpbmVkIG9iamVjdHMpPG86cD48L286cD48L3NwYW4+ PC9wPjwvZGl2PjxkaXYgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxwIGNsYXNzPU1zb05vcm1h bCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbjt0ZXh0LWluZGVudDotLjI1aW47bGluZS1oZWlnaHQ6 MTIuNzVwdCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9s Jz7Ctzwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjcuMHB0Jz4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz1hcHBsZS1jb252ZXJ0ZWQtc3Bh Y2U+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz5UaGUgWE1MIFNjaGVtYSBoYXMgZ29uZSB0 aHJvdWdoIGV4dGVuc2l2ZSBpbXByb3ZlbWVudHMgZm9yIGV4cHJlc3NpdmVuZXNzLCBjbGFyaXR5 LCBjb25zaXN0ZW5jeSwgZWZmaWNpZW5jeSwgYWxpZ25tZW50IHRvIGV4aXN0aW5nIG5vcm1hdGl2 ZSByZWZlcmVuY2VzIGFuZCBkb2N1bWVudGF0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rp dj48ZGl2IHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9 J21hcmdpbi1sZWZ0Oi41aW47dGV4dC1pbmRlbnQ6LS4yNWluO2xpbmUtaGVpZ2h0OjEyLjc1cHQn PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbCc+wrc8L3Nw YW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo3LjBwdCc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNw Ozwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+VGhpcyByZWxlYXNlIGluY2x1ZGVzIGFuIGluaXRpYWwg c2V0IG9mIGxhbmd1YWdlIHV0aWxpdGllczogYSBkcmFmdCBTbm9ydCAtJmd0OyBDeWJPWCB0cmFu c2Zvcm0sIGEgZHJhZnQgT3BlbklPQyAtJmd0OyBDeWJPWCB0cmFuc2Zvcm0sIGFuZCBhIHNldCBv ZiBQeXRob24gYmluZGluZ3MgZm9yIHRoZSBDeWJPWCBsYW5ndWFnZS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaCBzdHlsZT0nbXNvLW1hcmdpbi10 b3AtYWx0OjBpbjttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206MTAuMHB0O21hcmdpbi1s ZWZ0OjEuMGluO3RleHQtaW5kZW50Oi0uMjVpbjtsaW5lLWhlaWdodDoxMi43NXB0Jz48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpTeW1ib2wnPsK3PC9zcGFuPjxzcGFu IHN0eWxlPSdmb250LXNpemU6Ny4wcHQnPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOzxzcGFuIGNsYXNzPWFwcGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8L3NwYW4+ PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiInPlRoZSB3ZWJzaXRlIG5vdyBpbmNsdWRlcyBhIHNtYWxsIHNldCBvZiBj b250ZW50IGV4YW1wbGVzLiBUaGlzIHNldCB3aWxsIGdyb3cgZ29pbmcgZm9yd2FyZC48bzpwPjwv bzpwPjwvc3Bhbj48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0 Oi41aW4nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiInPlRoaXMgcmVsZWFzZSBpbnZvbHZlZCBhIGxvdCBvZiBoYXJkIHdvcmsg ZnJvbSBhIGRpdmVyc2UgZ3JvdXAgb2YgcGVvcGxlLiBUaGFuayB5b3UgYWxsIGZvciB5b3VyIGNv bnRyaWJ1dGlvbnMgYW5kIGVmZm9ydC4gV2UgY291bGQgbm90IGhhdmUgZG9uZSBpdCB3aXRob3V0 IHlvdS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwg c3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPldlIGxvb2sgZm9yd2FyZCB0byBldmVy eW9uZeKAmXMgZmVlZGJhY2sgYW5kIGNvbGxhYm9yYXRpb24gYXMgd2UgY29udGludWUgdG8gaW1w cm92ZSBhbmQgbWF0dXJlIHRoZSBDeWJPWCBsYW5ndWFnZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiInPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+U2VhbiBCYXJudW08bzpw PjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21h cmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm Iic+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+PC9kaXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWJvdHRvbTpzb2xp ZCAjNEY4MUJEIDEuMHB0O3BhZGRpbmc6MGluIDBpbiA0LjBwdCAwaW47Ym9yZGVyLXdpZHRoOmlu aXRpYWw7Ym9yZGVyLWNvbG9yOmluaXRpYWwnPjxwIGNsYXNzPU1zb1RpdGxlIHN0eWxlPSdtc28t bWFyZ2luLXRvcC1hbHQ6MGluO21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbToxNS4wcHQ7 bWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToyNi4wcHQ7Zm9udC1mYW1p bHk6IkNhbWJyaWEiLCJzZXJpZiI7Y29sb3I6IzE3MzY1RDtsZXR0ZXItc3BhY2luZzouMjVwdCc+ Q3liT1ggdjEuMCAoRHJhZnQpIFJlbGVhc2UgTm90ZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPlRoZSBW ZXJzaW9uIDEuMCAoRHJhZnQpIHJlbGVhc2Ugb2YgQ3liZXIgT2JzZXJ2YWJsZSBlWHByZXNzaW9u IChDeWJPWOKEoik8c3BhbiBjbGFzcz1hcHBsZS1jb252ZXJ0ZWQtc3BhY2U+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+Jm5i c3A7PC9zcGFuPjwvc3Bhbj5pcyBpbnRlbmRlZCBhcyBhIGRyYWZ0IHJlbGVhc2Ugb2YgYW4gaW5p dGlhbCBtYWpvciB2ZXJzaW9uIG9mIHRoZSBDeWJPWCBMYW5ndWFnZSB0aGF0IGNvdWxkIGJlIHV0 aWxpemVkIGZvciBwcmFjdGljYWwgb3BlcmF0aW9uYWwgdXNlIGFuZCBpbnRlZ3JhdGlvbiBpbnRv IG90aGVyIHN0YW5kYXJkcyBlZmZvcnRzLiBUaGlzIHJlbGVhc2UgY29uc2lzdHMgb2YgdGhyZWUg cHJpbWFyeSBjb21wb25lbnRzOiBhIHBhaXIgb2YgZm9ybWFsIGxhbmd1YWdlIHNwZWNpZmljYXRp b25zIGZvciB0aGUgY29yZSBsYW5ndWFnZSBjb250ZW50IGFuZCBkZWZpbmVkIG9iamVjdHMgY29u dGVudCwgYSBzZXQgb2YgbGFuZ3VhZ2UgaW1wbGVtZW50YXRpb24gWE1MIHNjaGVtYXMgKGNvcmUs IGNvbW1vbl90eXBlcywgYW5kIH43MCBkZWZpbmVkIG9iamVjdCBzY2hlbWFzKSwgYW5kIGEgc21h bGwgaW5pdGlhbCBzZXQgb2YgbGFuZ3VhZ2UgdXRpbGl0aWVzIGluY2x1ZGluZyBhbiBpbml0aWFs IGRyYWZ0IFNub3J0LSZndDtDeWJPWCB0cmFuc2Zvcm0sIGFuIGluaXRpYWwgZHJhZnQgT3BlbklP Qy0mZ3Q7Q3liT1ggdHJhbnNmb3JtIGFuZCBhIHNldCBvZiBDeWJPWCBsYW5ndWFnZSBQeXRob24g YmluZGluZ3MuIFJlY29nbml6aW5nIHRoYXQgdGhpcyBpcyB0aGUgZmlyc3QgdGltZSB0aGF0IHRo ZSBmb3JtYWwgbGFuZ3VhZ2Ugc3BlY2lmaWNhdGlvbnMgd2lsbCBiZSBhdmFpbGFibGUgZm9yIHJl dmlldyBhbmQgYXMgc3VjaCB3aWxsIGxpa2VseSBnZW5lcmF0ZSBmZWVkYmFjayBmcm9tIG5ldyBz dGFrZWhvbGRlcnMsIHRoaXMgaW5pdGlhbCBtYWpvciB2ZXJzaW9uIGlzIGJlaW5nIHJlbGVhc2Vk IGFzIGEg4oCcZHJhZnTigJ0gdjEuMCB3aXRoIHRoZSBleHBlY3RhdGlvbiBvZiBjeWNsZXMgb2Yg bmV3IGZlZWRiYWNrIGFuZCByZXZpc2lvbiBiZWZvcmUgYSDigJxmaW5hbOKAnSB2MS4wIGlzIHJl bGVhc2VkLjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiInPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+VGhlIEN5Yk9YIHYxLjAgKERyYWZ0 KSBYTUwgc2NoZW1hcyBpbmNsdWRlIGEgc2lnbmlmaWNhbnQgbnVtYmVyIG9mIGNoYW5nZXMgZnJv bSB2MC43IHRvIGltcHJvdmU6PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2Pjxk aXYgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFy Z2luLWxlZnQ6LjVpbjt0ZXh0LWluZGVudDotLjI1aW4nPjxzcGFuIHN0eWxlPSdmb250LWZhbWls eTpTeW1ib2wnPsK3PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6Ny4wcHQnPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPWFwcGxlLWNvbnZlcnRlZC1z cGFjZT4mbmJzcDs8L3NwYW4+PC9zcGFuPkNsYXJpdHksIGRvY3VtZW50YXRpb24sIGFuZCBkZXNj cmlwdGl2ZSBmb3JtYWxpdHkgZm9yIHJlZmVyZW5jZSBhbmQgaW1wbGVtZW50YXRpb24gYnkgb3Ro ZXIgc3RhbmRhcmRzIGFuZCB1c2Vycy48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9k aXY+PGRpdiBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSdtYXJnaW4tbGVmdDouNWluO3RleHQtaW5kZW50Oi0uMjVpbic+PHNwYW4gc3R5bGU9J2ZvbnQt ZmFtaWx5OlN5bWJvbCc+wrc8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo3LjBwdCc+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9YXBwbGUtY29udmVy dGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj48L3NwYW4+Q29uc2lzdGVuY3ksIHNpbXBsaWNpdHksIGFu ZCBlZmZpY2llbmN5LjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiInPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2IHN0 eWxlPSdtYXJnaW4tbGVmdDouNWluJz48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1s ZWZ0Oi41aW47dGV4dC1pbmRlbnQ6LS4yNWluJz48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6U3lt Ym9sJz7Ctzwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjcuMHB0Jz4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz1hcHBsZS1jb252ZXJ0ZWQtc3BhY2U+ Jm5ic3A7PC9zcGFuPjwvc3Bhbj5BbGlnbm1lbnQgKGFzIGFwcHJvcHJpYXRlKSB0byBleGlzdGlu ZyBub3JtYXRpdmUgcmVmZXJlbmNlcy48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9k aXY+PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OjBp bjttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206MTAuMHB0O21hcmdpbi1sZWZ0OjEuMGlu O3RleHQtaW5kZW50Oi0uMjVpbic+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OlN5bWJvbCc+wrc8 L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo3LjBwdCc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwv c3Bhbj48L3NwYW4+RXhwcmVzc2l2ZW5lc3Mgb2YgdGhlIHNjaGVtYSB0byBiZXR0ZXIgc3VwcG9y dCB0aGUgYnJvYWQgc2V0IG9mIHVzZSBjYXNlcyBpdCB0YXJnZXRzIChtYWx3YXJlIGNoYXJhY3Rl cml6YXRpb24sIGluZGljYXRvciBhbmQgaW5jaWRlbnQgZGF0YSBzaGFyaW5nLCBldmVudCBtYW5h Z2VtZW50LCBldGMuKSBpbmNsdWRpbmcgdGhlIGFkZGl0aW9uIG9mIGFuIGluaXRpYWwgc2V0IG9m IG5ldHdvcmstcmVsYXRlZCBkZWZpbmVkIG9iamVjdHMuPHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+PG86cD48L286cD48L3Nw YW4+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz5T dW1tYXJ5IG9mIGNoYW5nZXMgZnJvbSBDeWJPWF92MC43IHRvIEN5Yk9YX3YxLjBfKERyYWZ0KTo8 c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSdtYXJnaW4tbGVmdDoxLjBpbjt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDEgbGV2 ZWwxIGxmbzInPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OlN5bWJvbCc+PHNwYW4gc3R5bGU9J21zby1saXN0Oklnbm9yZSc+wrc8 c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwh W2VuZGlmXT5SZWZpbmVtZW50IG9mIG5hbWVzcGFjZXMgYW5kIHNjaGVtYSBsb2NhdGlvbnMgZm9y IGJldHRlciBlZmZlY3RpdmVuZXNzIGFuZCBmbGV4aWJpbGl0eSBnb2luZyBmb3J3YXJkLjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiInPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdp bi1sZWZ0OjEuMGluO3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMSBsZXZlbDEgbGZvMic+ PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6U3ltYm9sJz48c3BhbiBzdHlsZT0nbXNvLWxpc3Q6SWdub3JlJz7CtzxzcGFuIHN0eWxl PSdmb250OjcuMHB0ICJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPk5v cm1hbGl6ZWQgYWxsIGNvbnRlbnQgYWNjb3JkaW5nIHRvIGFuIGVzdGFibGlzaGVkIHNldCBvZiBu YW1pbmcgY29udmVudGlvbnMuPHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6MS4waW47dGV4dC1pbmRlbnQ6LS4yNWluO21z by1saXN0OmwxIGxldmVsMSBsZm8yJz48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTeW1ib2wnPjxzcGFuIHN0eWxlPSdtc28tbGlz dDpJZ25vcmUnPsK3PHNwYW4gc3R5bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiInPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PC9z cGFuPjwvc3Bhbj48IVtlbmRpZl0+RnVsbHkgYW5ub3RhdGVkIGFsbCBsYW5ndWFnZSBpdGVtcyAo dHlwZXMsIGF0dHJpYnV0ZXMsIGVsZW1lbnRzLCBldGMuKS48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz48bzpwPjwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDoxLjBpbjt0ZXh0 LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzInPjwhW2lmICFzdXBwb3J0TGlz dHNdPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbCc+PHNw YW4gc3R5bGU9J21zby1saXN0Oklnbm9yZSc+wrc8c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGlt ZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5Nb3ZlZCBzZXZlcmFsIGNvbW1v bmx5IGxldmVyYWdlZCB0eXBlcyBvdXQgb2YgdGhlIGNvcmUgc2NoZW1hIGFuZCBpbnRvIGNvbW1v bl90eXBlcy48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs IHN0eWxlPSdtYXJnaW4tbGVmdDoxLjBpbjt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDEg bGV2ZWwxIGxmbzInPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbCc+PHNwYW4gc3R5bGU9J21zby1saXN0Oklnbm9yZSc+ wrc8c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PC9zcGFu PjwhW2VuZGlmXT5BY2hpZXZlZCBmdWxsIHR5cGluZyBvZiBlbnRpcmUgc2NoZW1hIHN0cnVjdHVy ZSBzdWNoIHRoYXQgYWxsIGF0dHJpYnV0ZXMgYW5kIGVsZW1lbnRzIGFyZSBkZWZpbml0aXZlbHkg dHlwZWQuPHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIic+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBz dHlsZT0nbWFyZ2luLWxlZnQ6MS4waW47dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwxIGxl dmVsMSBsZm8yJz48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTpTeW1ib2wnPjxzcGFuIHN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPsK3 PHNwYW4gc3R5bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PC9zcGFuPjwvc3Bhbj48 IVtlbmRpZl0+Q2hhbmdlZCBhbGwgaWRlbnRpZmllcnMgZnJvbSBJRCBhbmQgSURSRUYgdHlwZXMg dG8gYmUgUU5hbWVzIGVuYWJsaW5nIGdsb2JhbGx5IHVuaXF1ZSBpZGVudGlmaWVycyBhbmQgZmxl eGliaWxpdHkgZm9yIGRvbWFpbi1zcGVjaWZpYyB1c2VycyBvZiBDeWJPWCB0byBkZWZpbmUgdGhl aXIgb3duIGlkZW50aWZpZXIgc3ludGF4IGxvY2FsbHkuPHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+PG86cD48L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6MS4waW47dGV4dC1p bmRlbnQ6LS4yNWluO21zby1saXN0OmwxIGxldmVsMSBsZm8yJz48IVtpZiAhc3VwcG9ydExpc3Rz XT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTeW1ib2wnPjxzcGFu IHN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPsK3PHNwYW4gc3R5bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVz IE5ldyBSb21hbiInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyA8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+UmVvcmRlcmVkIGF0dHJpYnV0ZXMg YW5kIGVsZW1lbnRzIGluIG51bWVyb3VzIHR5cGVzIHRvIGJldHRlciByZWZsZWN0IGNvbW1vbiB1 c2FnZSBhbmQgcHJpb3JpdHkuPHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6MS4waW47dGV4dC1pbmRlbnQ6LS4yNWluO21z by1saXN0OmwxIGxldmVsMSBsZm8yJz48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTeW1ib2wnPjxzcGFuIHN0eWxlPSdtc28tbGlz dDpJZ25vcmUnPsK3PHNwYW4gc3R5bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiInPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PC9z cGFuPjwvc3Bhbj48IVtlbmRpZl0+QWRkZWQgbWFqb3JfdmVyc2lvbiBhbmQgbWlub3JfdmVyc2lv biBhdHRyaWJ1dGVzIGZvciBjb3JlIHNjaGVtYS48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDoxLjBpbjt0ZXh0LWluZGVu dDotLjI1aW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzInPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbCc+PHNwYW4gc3R5 bGU9J21zby1saXN0Oklnbm9yZSc+wrc8c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGltZXMgTmV3 IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5BZGRlZCBjYXBhYmlsaXR5IHRvIGNoYXJh Y3Rlcml6ZSBzb3VyY2Ugb2Ygb3ZlcmFsbCBvYnNlcnZhYmxlIHBhY2thZ2UgZGF0YSBhbmQgZm9y IGluZGl2aWR1YWwgb2JzZXJ2YWJsZXMuPHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+PG86cD48L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6MS4waW47dGV4dC1pbmRlbnQ6LS4y NWluO21zby1saXN0OmwxIGxldmVsMSBsZm8yJz48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTeW1ib2wnPjxzcGFuIHN0eWxlPSdt c28tbGlzdDpJZ25vcmUnPsK3PHNwYW4gc3R5bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBSb21h biInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3Nw YW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+TW9kaWZpZWQgdGhlIGxvZ2ljYWwgY29tcG9zaXRp b24gc3RydWN0dXJlIHN1Y2ggdGhhdCBhbnkgc3VjaCBjb21wb3NpdGlvbnMgYXJlIG5vdyBjb250 YWluZWQgd2l0aGluIGEgT2JzZXJ2YWJsZV9Db21wb3NpdGlvbiBlbGVtZW50IHByb3ZpZGluZyBp bXByb3ZlZCBzaW1wbGljaXR5IGFuZCBtb2R1bGFyaXR5LjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0OjEuMGluO3RleHQt aW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMSBsZXZlbDEgbGZvMic+PCFbaWYgIXN1cHBvcnRMaXN0 c10+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sJz48c3Bh biBzdHlsZT0nbXNvLWxpc3Q6SWdub3JlJz7CtzxzcGFuIHN0eWxlPSdmb250OjcuMHB0ICJUaW1l cyBOZXcgUm9tYW4iJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPlJlbW92ZWQgdGhlIERlbHRhIGVs ZW1lbnQgZnJvbSBPYnNlcnZhYmxlVHlwZSBhbmQgcmVsb2NhdGVkIHRoZSBhcHByb3ByaWF0ZSBw b3J0aW9ucyAoQ2hhbmdlLCBUcmVuZCwgYW5kIEZyZXF1ZW5jeSkgdG8gYXBwcm9wcmlhdGUgbG9j YXRpb25zIHVuZGVyIFN0YXRlZnVsX01lYXN1cmUgYW5kIEV2ZW50LjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0OjEuMGlu O3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMSBsZXZlbDEgbGZvMic+PCFbaWYgIXN1cHBv cnRMaXN0c10+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9s Jz48c3BhbiBzdHlsZT0nbXNvLWxpc3Q6SWdub3JlJz7CtzxzcGFuIHN0eWxlPSdmb250OjcuMHB0 ICJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPkFkZGVkIGEgRG9tYWlu X1NwZWNpZmljX09iamVjdF9BdHRyaWJ1dGVzIGZpZWxkIHRvIE9iamVjdCB1dGlsaXppbmcgYW4g YWJzdHJhY3QgdHlwZSB0aGF0IHdpbGwgYWxsb3cgZG9tYWluLXNwZWNpZmljIHVzZSBjYXNlcyB0 byBhZGQgaW4gdGhlaXIgb3duIGRvbWFpbi1zcGVjaWZpYyBhdHRyaWJ1dGVzIGZvciBPYmplY3Rz LjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiInPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9 J21hcmdpbi1sZWZ0OjEuMGluO3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMSBsZXZlbDEg bGZvMic+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6U3ltYm9sJz48c3BhbiBzdHlsZT0nbXNvLWxpc3Q6SWdub3JlJz7CtzxzcGFu IHN0eWxlPSdmb250OjcuMHB0ICJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5k aWZdPkFkZGVkIGEgVG9vbC1TcGVjaWZpY19EYXRhIGZpZWxkIHRvIFRvb2xJbmZvcm1hdGlvblR5 cGUgdXRpbGl6aW5nIGFuIGFic3RyYWN0IHR5cGUgdGhhdCB3aWxsIGFsbG93IGFkZGl0aW9uIG9m IHRvb2wtc3BlY2lmaWMgZGF0YS48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDoxLjBpbjt0ZXh0LWluZGVudDotLjI1aW47 bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzInPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbCc+PHNwYW4gc3R5bGU9J21zby1s aXN0Oklnbm9yZSc+wrc8c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGltZXMgTmV3IFJvbWFuIic+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48 L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5BZGRlZCBhbiBJbmRpY2F0b3JzIGZpZWxkIHRvIE1lYXN1 cmVTb3VyY2VUeXBlIHV0aWxpemluZyBhbiBhYnN0cmFjdCB0eXBlIHRoYXQgd2lsbCBhbGxvdyBj aGFyYWN0ZXJpemluZyBkaWZmZXJpbmcgZm9ybWF0cyBvciBzdGFuZGFyZHMgb2YgaW5kaWNhdG9y cyB0aGF0IG1heSBoYXZlIGxlZCB0byB0aGUgaWRlbnRpZmljYXRpb24gb2YgdGhlIG9ic2VydmFi bGUgZGF0YS48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs IHN0eWxlPSdtYXJnaW4tbGVmdDoxLjBpbjt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDEg bGV2ZWwxIGxmbzInPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbCc+PHNwYW4gc3R5bGU9J21zby1saXN0Oklnbm9yZSc+ wrc8c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PC9zcGFu PjwhW2VuZGlmXT5FbmhhbmNlZCB0aGUgSGFzaCBzdHJ1Y3R1cmUgdG8gY2FwdHVyZSBmdWxsIGZ1 enp5IGhhc2hlcyBpbiBhZGRpdGlvbiB0byBzaW1wbGUgaGFzaGVzPHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+PG86cD48L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6MS4waW47 dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwxIGxldmVsMSBsZm8yJz48IVtpZiAhc3VwcG9y dExpc3RzXT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTeW1ib2wn PjxzcGFuIHN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPsK3PHNwYW4gc3R5bGU9J2ZvbnQ6Ny4wcHQg IlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyA8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+QWRkZWQgYSBuZXcgRXh0 cmFjdGVkRmVhdHVyZXNUeXBlIHRoYXQgY2FuIGJlIHVzZWQgdG8gYWRvcm4gZGlmZmVyaW5nIG9i amVjdHMgKGUuZy4sIGZpbGVzLCBtZW1vcnksIGV0Yy4pIHRvIGNhcHR1cmUgZXh0cmFjdGVkIHN0 cmluZ3MsIGltcG9ydHMsIGZ1bmN0aW9ucyBhbmQgY29kZSBzbmlwcGV0czxzcGFuIHN0eWxlPSdm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0OjEu MGluO3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMSBsZXZlbDEgbGZvMic+PCFbaWYgIXN1 cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U3lt Ym9sJz48c3BhbiBzdHlsZT0nbXNvLWxpc3Q6SWdub3JlJz7CtzxzcGFuIHN0eWxlPSdmb250Ojcu MHB0ICJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPkFkZGVkIGEgQnl0 ZVJ1bnNUeXBlIHRvIGVuYWJsZSBjYXB0dXJlIG9mIGJ5dGUgcnVucyB3aXRoaW4gdmFyaW91cyBv YmplY3RzLjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiInPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwg c3R5bGU9J21hcmdpbi1sZWZ0OjEuMGluO3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMSBs ZXZlbDEgbGZvMic+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sJz48c3BhbiBzdHlsZT0nbXNvLWxpc3Q6SWdub3JlJz7C tzxzcGFuIHN0eWxlPSdmb250OjcuMHB0ICJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48L3NwYW4+ PCFbZW5kaWZdPkFkZGVkIG9iamVjdF9yZWZlcmVuY2UgYXR0cmlidXRlIHRvIERlZmluZWRPYmpl Y3RUeXBlIHRvIGJldHRlciBzdXBwb3J0IHJlZmVyZW5jaW5nIG9mIGluZGVwZW5kZW50bHkgZGVm aW5lZCBPYmplY3RzIGZyb20gd2l0aGluIGFub3RoZXIgT2JqZWN0IGRlZmluaXRpb24uPHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm Iic+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2lu LWxlZnQ6MS4waW47dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwxIGxldmVsMSBsZm8yJz48 IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTpTeW1ib2wnPjxzcGFuIHN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPsK3PHNwYW4gc3R5bGU9 J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+QWRk ZWQgYSBnZW5lcmljIERhdGFTZWdtZW50VHlwZSB0byBwcm92aWRlIGEgcmVsYXRpdmVseSBhYnN0 cmFjdCB3YXkgb2YgY2hhcmFjdGVyaXppbmcgZGF0YSBzZWdtZW50cyB0aGF0IG1heSBiZSB3cml0 dGVuL3JlYWQvdHJhbnNtaXR0ZWQgb3Igb3RoZXJ3aXNlIHV0aWxpemVkIGluIGFjdGlvbnMgb3Ig ZGVmaW5lZCBpbiBvYmplY3RzLjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48ZGl2IHN0 eWxlPSdtYXJnaW4tbGVmdDouNWluJz48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1s ZWZ0Oi41aW47dGV4dC1pbmRlbnQ6LS4yNWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTpTeW1ib2wnPsK3PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6Ny4w cHQnPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNz PWFwcGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8L3NwYW4+PC9zcGFuPkFkZGVkIHNldmVyYWwg bmV3IGRlZmluZWQgb2JqZWN0IHNjaGVtYXMgKEFQSSwgQ29kZSwgRGV2aWNlLCBETlNfUmVjb3Jk LCBOZXR3b3JrX0Zsb3csIE5ldHdvcmtfUGFja2V0LCBOZXR3b3JrX1JvdXRlX0VudHJ5LCBOZXR3 b3JrX1N1Ym5ldCwgVW5peF9OZXR3b3JrX1JvdXRlX0VudHJ5KSBpbmNsdWRpbmcgYW4gaW5pdGlh bCBzZXQgb2YgbmV0d29yay1jZW50cmljIGRlZmluZWQgb2JqZWN0cy48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdCc+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05v cm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6MS4waW47dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0 OmwwIGxldmVsMSBsZm80Jz48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTpTeW1ib2wnPjxzcGFuIHN0eWxlPSdtc28tbGlzdDpJZ25v cmUnPsK3PHNwYW4gc3R5bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PC9zcGFuPjwv c3Bhbj48IVtlbmRpZl0+TW9kaWZpZWQgZXZlcnkgZGVmaW5lZCBvYmplY3Qgc2NoZW1hIHdpdGgg YWRkZWQgYW5ub3RhdGlvbnMgYXMgd2VsbCBhcyBtaW5vciBhbmQgaW4gc29tZSBjYXNlcyBzdWJz dGFudGl2ZSBjaGFuZ2VzIHRvIGZpeCBlcnJvcnMsIGltcHJvdmUgY29uc2lzdGVuY3kgYW5kIGFs aWdubWVudCB3aXRoIGV4aXN0aW5nIG5vcm1hdGl2ZSByZWZlcmVuY2VzLCBhbmQgdG8gaW1wcm92 ZSBleHByZXNzaXZlbmVzcyBpbiBzdXBwb3J0IG9mIHRoZSB0YXJnZXRlZCB1c2UgY2FzZXMuPHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIic+PG86cD48L286cD48L3NwYW4+PC9wPjxkaXYgc3R5bGU9J21hcmdpbi1sZWZ0Oi4yNWlu Jz48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPkRldGFpbGVkIGNo YW5nZXMgZnJvbSBDeWJPWF92MC43IHRvIEN5Yk9YX3YxLjBfKERyYWZ0KTo8c3BhbiBzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz48bzpw PjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21h cmdpbi1sZWZ0Oi41aW4nPlRoZSBsZXZlbCBvZiBjaGFuZ2VzIHdpdGhpbiB2MS4wIChEcmFmdCkg aW4gdGhlIGNvcmUgc2NoZW1hLCBjb21tb25fdHlwZXMgYW5kIHRoZSBkZWZpbmVkIG9iamVjdCBz Y2hlbWFzIGlzIHRvbyBncmVhdCB0byBsaXN0IGV2ZXJ5IGNoYW5nZSBpbiB0aGVzZSByZWxlYXNl IG5vdGVzLiBEZXRhaWxlZCBkaWZmZXJlbmNlIHJlcG9ydHMgYXJlIGF2YWlsYWJsZSBmb3IgZWFj aCBpbmRpdmlkdWFsIHNjaGVtYSBhdDo8c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz48YSBocmVmPSJodHRwOi8vY3lib3gubWl0 cmUub3JnL1hNTFNjaGVtYS9yZWxlYXNlX25vdGVzL2N5Ym94X3YxLjAoZHJhZnQpX2RpZmZfcmVw b3J0cy56aXAiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLCJzZXJpZiInPmh0dHA6Ly9jeWJveC5taXRyZS5vcmcvWE1MU2NoZW1hL3Jl bGVhc2Vfbm90ZXMvY3lib3hfdjEuMChkcmFmdClfZGlmZl9yZXBvcnRzLnppcDwvc3Bhbj48L2E+ PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSdtYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiInPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2IHN0eWxlPSdtYXJn aW4tbGVmdDouNWluJz48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4n PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT08L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2 PjxkaXYgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0n bWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5TZWFuIEJhcm51bTwvc3Bh bj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdiBzdHlsZT0nbWFyZ2lu LWxlZnQ6LjVpbic+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkN5YmVyIFNlY3VyaXR5IFByaW5jaXBhbDwvc3Bhbj48c3Bh biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdiBzdHlsZT0nbWFyZ2luLWxlZnQ6 LjVpbic+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O2NvbG9yOiMxRjQ5N0QnPlRoZSBNSVRSRSBDb3Jwb3JhdGlvbjwvc3Bhbj48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz48bzpw PjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdiBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PHAg Y2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMx RjQ5N0QnPkVtYWlsOjxzcGFuIGNsYXNzPWFwcGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8L3Nw YW4+PGEgaHJlZj0ibWFpbHRvOnNiYXJudW1AbWl0cmUub3JnIj5zYmFybnVtQG1pdHJlLm9yZzwv YT48L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIic+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4t bGVmdDouNWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseToiSGVs dmV0aWNhIiwic2Fucy1zZXJpZiInPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPm1pbGUgbWFpbGluZyBsaXN0PGJyPjxhIGhyZWY9Im1haWx0bzptaWxl QGlldGYub3JnIj5taWxlQGlldGYub3JnPC9hPjxicj48YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL21pbGUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbWlsZTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PHAgY2xh c3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48bzpwPiZuYnNwOzwvbzpwPjwv cD48L2Rpdj48L2Rpdj48L2JvZHk+PC9odG1sPg== ------_=_NextPart_001_01CD1C4E.2F4B01A2-- From sbarnum@mitre.org Mon Apr 16 21:52:36 2012 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 613A621F8474; Mon, 16 Apr 2012 21:52:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NrbD2vEs1Vc4; Mon, 16 Apr 2012 21:52:31 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id E828121F84E4; Mon, 16 Apr 2012 21:52:29 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 5F05921B0E73; Tue, 17 Apr 2012 00:52:29 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 43B2521B0E63; Tue, 17 Apr 2012 00:52:29 -0400 (EDT) Received: from IMCMBX03.MITRE.ORG ([169.254.3.179]) by IMCCAS02.MITRE.ORG ([129.83.29.79]) with mapi id 14.02.0283.003; Tue, 17 Apr 2012 00:52:28 -0400 From: "Barnum, Sean D." To: "Millar, Thomas" , "osantos@cisco.com" , "lnunez@c3isecurity.com" Thread-Topic: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe website Thread-Index: AQHNHC91EoahZz2AEEqd+yKyGmroMJaeWIaQgAAIZb+AAA8foA== Date: Tue, 17 Apr 2012 04:52:27 +0000 Message-ID: <7F48813B48558A4BB5CB7BB714E5B5A9171B7C@IMCMBX03.MITRE.ORG> References: <7F48813B48558A4BB5CB7BB714E5B5A9171B16@IMCMBX03.MITRE.ORG> <69CE2DCD9DAC3D48B830E0723141170B02A39BD2@ZAU1UG-0308.DHSNET.DS1.DHS> In-Reply-To: <69CE2DCD9DAC3D48B830E0723141170B02A39BD2@ZAU1UG-0308.DHSNET.DS1.DHS> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.31.136.182] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_005F_01CD1C34.59077330" MIME-Version: 1.0 Cc: "idxwg@nicwg.org" , "mile@ietf.org" , "dallendoug@gmail.com" , "sacm@ietf.org" , "m-terada@ipa.go.jp" Subject: Re: [mile] [sacm] CybOX v1.0 (Draft) is now released and live onthe website 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, 17 Apr 2012 04:52:36 -0000 ------=_NextPart_000_005F_01CD1C34.59077330 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0060_01CD1C34.59077330" ------=_NextPart_001_0060_01CD1C34.59077330 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable It is not a euphemism for netflow. It is about all kinds of data flow not just network-related. It could be about ETL within a database or datawarehouse. It could be about data flow within an information system (perhaps = observable within an application log). It could be about data flow related to all sorts of forms of message = passing. It could be about data flow within data-driven reactive programming = software architectures. Etc., Etc. =E2=80=9CData Flow=E2=80=9D is a fairly abstract bucket acting as a = classifier for a broad range of potential event types.=20 Of course, we will seek to offer relevant lower abstraction buckets = within this broad bucket (e.g. =E2=80=9CPacket Traffic=E2=80=9D) to = offer more specific characterization where we have a clear understanding = of the sub-bucket but it is still useful to have the broader bucket = available to catch the things we do not have more specific sub-buckets = defined for yet. =20 Does that help clarify? =20 sean =20 From: Millar, Thomas [mailto:Thomas.Millar@hq.dhs.gov]=20 Sent: Monday, April 16, 2012 11:46 PM To: Barnum, Sean D.; osantos@cisco.com; lnunez@c3isecurity.com Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; = m-terada@ipa.go.jp Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live = onthe website =20 If "data flow" is a euphemism for "netflow" is there any reason not to = call it that? Tom Millar=20 http://www.us-cert.gov/=20 ------------------=20 Missit me Rubus fruticosus:=20 202 631 1915=20 =20 From: Barnum, Sean D. [mailto:sbarnum@mitre.org]=20 Sent: Monday, April 16, 2012 11:29 PM To: Omar Santos (osantos) ; Luis Nunez = =20 Cc: idxwg@nicwg.org ; mile@ietf.org ; = dallendoug@gmail.com ; sacm@ietf.org = ; m-terada@ipa.go.jp =20 Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live = onthe website=20 =20 Thanks Omar. =20 To answer your question, first let me point out to other readers that = the two entries that Omar is quoting here exist as values in an = enumeration called EventTypeEnum which as its name implies contains a = list of different labels for grouping types (or classes) of events to be = used as low-granularity buckets for characterizing and classifying = events. Other entries in this enumeration include things like =E2=80=9CFile Ops = (CRUD)=E2=80=9D, =E2=80=9CProcess Mgt=E2=80=9D, =E2=80=9CAuthorization = (ACL)=E2=80=9D, etc. =20 The =E2=80=9CPacket Traffic=E2=80=9D value is intended to characterize = events dealing with network packet traffic as its name implies. The =E2=80=9CData Flow=E2=80=9D value is intended to characterize events = dealing with forms of data flow at a higher level of abstraction than = just packet traffic. The relationship between these two values could be = viewed as =E2=80=9CPacket Traffic=E2=80=9D being a more detailed form of = =E2=80=9CData Flow=E2=80=9D just as the values =E2=80=9CApp Layer = Traffic=E2=80=9D and =E2=80=9CHTTP Layer Traffic=E2=80=9D, also in this = enumeration, could be other levels in this same abstraction stack. The idea behind the varying levels of abstraction is to leave buckets = large enough to capture a wide variety of potential event types (e.g. = data flow events other than obvious things like packet traffic) but also = enable the use of smaller more specific buckets when they are = appropriate and commonly used. =20 Does this make sense?=20 =20 sean =20 From: Omar Santos (osantos) [mailto:osantos@cisco.com]=20 Sent: Monday, April 16, 2012 8:17 PM To: Luis Nunez; Barnum, Sean D. Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; = m-terada@ipa.go.jp Subject: RE: [sacm] [mile] CybOX v1.0 (Draft) is now released and live = onthe website =20 I echo Luis=E2=80=99 comments. It is good to see the inclusion of = network objects. Quick question to the team related to your netflow = comment. =20 I am looking at: http://cybox.mitre.org/XMLSchema/cybox_core_v1.0%28draft%29.xsd =20 =E2=80=A6 and it looks that we renamed it to =E2=80=9CData = Flow=E2=80=9D? =20 Specifies the class of events dealing with = data flow. =20 =20 What is the difference between that and =E2=80=9CPacket = Traffic=E2=80=9D? =20 Specifies the class of events dealing with packet = traffic. =20 =20 =20 =20 Regards, Omar Santos Incident Manager, PSIRT Security Research and Operations Cisco Systems, Inc. Email: os@cisco.com Phone: +1 919 392 8635 PGP Key: 0x3AF27EDC Cisco.com - http://www.cisco.com Cisco Security Advisories and Notices - http://www.cisco.com/go/psirt This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message. For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html =20 From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of = Luis Nunez Sent: Monday, April 16, 2012 6:44 PM To: Barnum, Sean D. Cc: idxwg@nicwg.org; mile@ietf.org; Doug Wilson (dallendoug@gmail.com); = sacm@ietf.org; IPA-Masato Terada (m-terada@ipa.go.jp) Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live = onthe website =20 I like the inclusion of the network-centric objects. IPFIX (netflow) = will add an additional perspective from an incident information sharing = standpoint. =20 =20 -ln =20 On Apr 16, 2012, at 4:04 PM, Barnum, Sean D. wrote: =20 Hey everyone, =20 I just wanted to let you all know that CybOX v1.0 (Draft) content is now = live on the website. http://cybox.mitre.org The release notes are provided inline below. The key items of note are: =C2=B7 The release of two formal specifications for the CybOX = language (one for the core language and one for the defined objects) =C2=B7 The XML Schema has gone through extensive improvements for = expressiveness, clarity, consistency, efficiency, alignment to existing = normative references and documentation. =C2=B7 This release includes an initial set of language = utilities: a draft Snort -> CybOX transform, a draft OpenIOC -> CybOX = transform, and a set of Python bindings for the CybOX language. =C2=B7 The website now includes a small set of content examples. = This set will grow going forward. This release involved a lot of hard work from a diverse group of people. = Thank you all for your contributions and effort. We could not have done = it without you. We look forward to everyone=E2=80=99s feedback and collaboration as we = continue to improve and mature the CybOX language. =20 Sean Barnum =20 =20 =20 CybOX v1.0 (Draft) Release Notes The Version 1.0 (Draft) release of Cyber Observable eXpression = (CybOX=E2=84=A2) is intended as a draft release of an initial major = version of the CybOX Language that could be utilized for practical = operational use and integration into other standards efforts. This = release consists of three primary components: a pair of formal language = specifications for the core language content and defined objects = content, a set of language implementation XML schemas (core, = common_types, and ~70 defined object schemas), and a small initial set = of language utilities including an initial draft Snort->CybOX transform, = an initial draft OpenIOC->CybOX transform and a set of CybOX language = Python bindings. Recognizing that this is the first time that the formal = language specifications will be available for review and as such will = likely generate feedback from new stakeholders, this initial major = version is being released as a =E2=80=9Cdraft=E2=80=9D v1.0 with the = expectation of cycles of new feedback and revision before a = =E2=80=9Cfinal=E2=80=9D v1.0 is released. The CybOX v1.0 (Draft) XML schemas include a significant number of = changes from v0.7 to improve: =C2=B7 Clarity, documentation, and descriptive formality for = reference and implementation by other standards and users. =C2=B7 Consistency, simplicity, and efficiency. =C2=B7 Alignment (as appropriate) to existing normative = references. =C2=B7 Expressiveness of the schema to better support the broad = set of use cases it targets (malware characterization, indicator and = incident data sharing, event management, etc.) including the addition of = an initial set of network-related defined objects. Summary of changes from CybOX_v0.7 to CybOX_v1.0_(Draft): =C2=B7 Refinement of namespaces and schema locations for better = effectiveness and flexibility going forward. =C2=B7 Normalized all content according to an established set of = naming conventions. =C2=B7 Fully annotated all language items (types, attributes, = elements, etc.). =C2=B7 Moved several commonly leveraged types out of the core = schema and into common_types. =C2=B7 Achieved full typing of entire schema structure such that = all attributes and elements are definitively typed. =C2=B7 Changed all identifiers from ID and IDREF types to be = QNames enabling globally unique identifiers and flexibility for = domain-specific users of CybOX to define their own identifier syntax = locally. =C2=B7 Reordered attributes and elements in numerous types to = better reflect common usage and priority. =C2=B7 Added major_version and minor_version attributes for core = schema. =C2=B7 Added capability to characterize source of overall = observable package data and for individual observables. =C2=B7 Modified the logical composition structure such that any = such compositions are now contained within a Observable_Composition = element providing improved simplicity and modularity. =C2=B7 Removed the Delta element from ObservableType and = relocated the appropriate portions (Change, Trend, and Frequency) to = appropriate locations under Stateful_Measure and Event. =C2=B7 Added a Domain_Specific_Object_Attributes field to Object = utilizing an abstract type that will allow domain-specific use cases to = add in their own domain-specific attributes for Objects. =C2=B7 Added a Tool-Specific_Data field to ToolInformationType = utilizing an abstract type that will allow addition of tool-specific = data. =C2=B7 Added an Indicators field to MeasureSourceType utilizing = an abstract type that will allow characterizing differing formats or = standards of indicators that may have led to the identification of the = observable data. =C2=B7 Enhanced the Hash structure to capture full fuzzy hashes = in addition to simple hashes =C2=B7 Added a new ExtractedFeaturesType that can be used to = adorn differing objects (e.g., files, memory, etc.) to capture extracted = strings, imports, functions and code snippets =C2=B7 Added a ByteRunsType to enable capture of byte runs within = various objects. =C2=B7 Added object_reference attribute to DefinedObjectType to = better support referencing of independently defined Objects from within = another Object definition. =C2=B7 Added a generic DataSegmentType to provide a relatively = abstract way of characterizing data segments that may be = written/read/transmitted or otherwise utilized in actions or defined in = objects. =C2=B7 Added several new defined object schemas (API, Code, = Device, DNS_Record, Network_Flow, Network_Packet, Network_Route_Entry, = Network_Subnet, Unix_Network_Route_Entry) including an initial set of = network-centric defined objects. =C2=B7 Modified every defined object schema with added = annotations as well as minor and in some cases substantive changes to = fix errors, improve consistency and alignment with existing normative = references, and to improve expressiveness in support of the targeted use = cases. Detailed changes from CybOX_v0.7 to CybOX_v1.0_(Draft): The level of changes within v1.0 (Draft) in the core schema, = common_types and the defined object schemas is too great to list every = change in these release notes. Detailed difference reports are available = for each individual schema at: = = http://cybox.mitre.org/XMLSchema/release_notes/cybox_v1.0(draft)_diff_rep= orts.zip =20 =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Sean Barnum Cyber Security Principal The MITRE Corporation Email: sbarnum@mitre.org =20 _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile =20 ------=_NextPart_001_0060_01CD1C34.59077330 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

It is not a euphemism for netflow.

It is about all kinds of data flow not just = network-related.

It could be about ETL within a database or = datawarehouse.

It could be about data flow within an information system (perhaps = observable within an application log).

It could be about data flow related to all sorts of forms of message = passing.

It could be about data flow within data-driven reactive programming = software architectures.

Etc., Etc.

=E2=80=9CData Flow=E2=80=9D is a fairly abstract bucket acting as a = classifier for a broad range of potential event types. =

Of course, we will seek to offer relevant lower abstraction buckets = within this broad bucket (e.g. =E2=80=9CPacket Traffic=E2=80=9D) to = offer more specific characterization where we have a clear understanding = of the sub-bucket but it is still useful to have the broader bucket = available to catch the things we do not have more specific sub-buckets = defined for yet.

 

Does that help clarify?

 

sean

 

From:= = Millar, Thomas [mailto:Thomas.Millar@hq.dhs.gov]
Sent: = Monday, April 16, 2012 11:46 PM
To: Barnum, Sean D.; = osantos@cisco.com; lnunez@c3isecurity.com
Cc: idxwg@nicwg.org; = mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; = m-terada@ipa.go.jp
Subject: Re: [sacm] [mile] CybOX v1.0 = (Draft) is now released and live onthe = website

 

If "data flow" is a euphemism for "netflow" is = there any reason not to call it that?

Tom Millar
http://www.us-cert.gov/ =
------------------
Missit me Rubus fruticosus:
202 631 1915 =

 

From<= /b>: = Barnum, Sean D. [mailto:sbarnum@mitre.org]=
Sent: Monday, April 16, 2012 11:29 PM
To: Omar = Santos (osantos) <osantos@cisco.com>; Luis Nunez = <lnunez@c3isecurity.com> =
Cc: idxwg@nicwg.org = <idxwg@nicwg.org>; mile@ietf.org <mile@ietf.org>; dallendoug@gmail.com <dallendoug@gmail.com>; sacm@ietf.org <sacm@ietf.org>; m-terada@ipa.go.jp <m-terada@ipa.go.jp> =
Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released = and live onthe website
 

Thanks Omar.

 

To answer your question, first let me point out to other readers that = the two entries that Omar is quoting here exist as values in an = enumeration called EventTypeEnum which as its name implies contains a = list of different labels for grouping types (or classes) of events to be = used as low-granularity buckets for characterizing and classifying = events.

Other entries in this enumeration include things like =E2=80=9CFile = Ops (CRUD)=E2=80=9D, =E2=80=9CProcess Mgt=E2=80=9D, = =E2=80=9CAuthorization (ACL)=E2=80=9D, etc.

 

The =E2=80=9CPacket Traffic=E2=80=9D value is intended to = characterize events dealing with network packet traffic as its name = implies.

The =E2=80=9CData Flow=E2=80=9D value is intended to characterize = events dealing with forms of data flow at a higher level of abstraction = than just packet traffic. The relationship between these two values = could be viewed as =E2=80=9CPacket Traffic=E2=80=9D being a more = detailed form of =E2=80=9CData Flow=E2=80=9D just as the values = =E2=80=9CApp Layer Traffic=E2=80=9D and =E2=80=9CHTTP Layer = Traffic=E2=80=9D, also in this enumeration, could be other levels in = this same abstraction stack.

The idea behind the varying levels of abstraction is to leave =  buckets large enough to capture a wide variety of potential event = types (e.g. data flow events other than obvious things like packet = traffic) but also enable the use of smaller more specific buckets when = they are appropriate and commonly used.

 

Does this make sense?

 

sean

 

From:= = Omar Santos (osantos) [mailto:osantos@cisco.com]=
Sent: Monday, April 16, 2012 8:17 PM
To: Luis = Nunez; Barnum, Sean D.
Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; m-terada@ipa.go.jp
Subject:<= /b> RE: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe = website

 

I echo Luis=E2=80=99 comments. It is good to see the inclusion of = network objects. Quick question to the team related to your netflow = comment.

 

I am looking at:

= http://cybox.mitre.org/XMLSchema/cybox_core_v1.0%28draft%29.xsd<= /o:p>

 

=E2=80=A6 and it looks that we renamed it to =E2=80=9CData = Flow=E2=80=9D?

 

<xs:enumeration = value=3D"Data Flow">

   = <xs:annotation>

        = <xs:documentation>Specifies the class of events dealing with data = flow.</xs:documentation>

   = </xs:annotation>

</xs:enumeration>

 

 

What is the difference between that and =E2=80=9CPacket = Traffic=E2=80=9D?

 

<xs:enumeration value=3D"Packet =
Traffic">
   =
<xs:annotation>
     =
<xs:documentation>Specifies the class of events dealing with =
packet traffic.</xs:documentation>
   =
</xs:annotation>
</xs:enumeration>

 

 

 

 

Regards,

Omar Santos
Incident Manager, = PSIRT
Security Research and Operations
Cisco Systems, = Inc.
Email: os@cisco.com
Phone: +1 919 392 = 8635
PGP Key: 0x3AF27EDC

Cisco.com - http://www.cisco.com
Cisco Security = Advisories and Notices - http://www.cisco.com/go/psirt<= br>
This email may contain confidential and privileged material for = the sole
use of the intended recipient. Any review, use, distribution = or
disclosure by others is strictly prohibited. If you are not the = intended
recipient (or authorized to receive for the recipient), = please contact
the sender by reply email and delete all copies of = this message.

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html=

 

From:= = sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.= org] On Behalf Of Luis Nunez
Sent: Monday, April = 16, 2012 6:44 PM
To: Barnum, Sean D.
Cc: idxwg@nicwg.org; mile@ietf.org; Doug Wilson (dallendoug@gmail.com); sacm@ietf.org; IPA-Masato Terada (m-terada@ipa.go.jp)
Subject:= Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe = website

 

I like the inclusion of the network-centric = objects.  IPFIX (netflow)  will add an additional perspective = from an incident information sharing standpoint. =  

 

-ln

 

On Apr 16, 2012, at 4:04 = PM, Barnum, Sean D. wrote:

 

Hey = everyone,

 =

I just = wanted to let you all know that CybOX v1.0 (Draft) content is now live = on the website. http://cybox.mitre.org

The = release notes are provided inline = below.

The key = items of note are:

=C2=B7        The = release of two formal specifications for the CybOX language (one for the = core language and one for the defined = objects)

=C2=B7        The XML = Schema has gone through extensive improvements for expressiveness, = clarity, consistency, efficiency, alignment to existing normative = references and documentation.

=C2=B7        This = release includes an initial set of language utilities: a draft Snort = -> CybOX transform, a draft OpenIOC -> CybOX transform, and a set = of Python bindings for the CybOX language.

=C2=B7        The = website now includes a small set of content examples. This set will grow = going forward.

This = release involved a lot of hard work from a diverse group of people. = Thank you all for your contributions and effort. We could not have done = it without you.

We look = forward to everyone=E2=80=99s feedback and collaboration as we continue = to improve and mature the CybOX = language.

 =

Sean = Barnum

 =

 =

 =

CybOX v1.0 (Draft) Release = Notes

The Version 1.0 (Draft) release of Cyber = Observable eXpression (CybOX=E2=84=A2) is intended as a draft release of an initial major version of = the CybOX Language that could be utilized for practical operational use = and integration into other standards efforts. This release consists of = three primary components: a pair of formal language specifications for = the core language content and defined objects content, a set of language = implementation XML schemas (core, common_types, and ~70 defined object = schemas), and a small initial set of language utilities including an = initial draft Snort->CybOX transform, an initial draft = OpenIOC->CybOX transform and a set of CybOX language Python bindings. = Recognizing that this is the first time that the formal language = specifications will be available for review and as such will likely = generate feedback from new stakeholders, this initial major version is = being released as a =E2=80=9Cdraft=E2=80=9D v1.0 with the expectation of = cycles of new feedback and revision before a =E2=80=9Cfinal=E2=80=9D = v1.0 is released.=

The CybOX v1.0 (Draft) XML schemas include a = significant number of changes from v0.7 to improve:=

=C2=B7       Clarity, = documentation, and descriptive formality for reference and = implementation by other standards and users.=

=C2=B7       Consistency, = simplicity, and efficiency.=

=C2=B7       Alignment (as = appropriate) to existing normative references.=

=C2=B7       Expressiveness of the = schema to better support the broad set of use cases it targets (malware = characterization, indicator and incident data sharing, event management, = etc.) including the addition of an initial set of network-related = defined objects.=

Summary = of changes from CybOX_v0.7 to CybOX_v1.0_(Draft):=

=C2=B7        = Refinement of namespaces and schema = locations for better effectiveness and flexibility going forward.=

=C2=B7        = Normalized all content according to an = established set of naming conventions.=

=C2=B7        = Fully annotated all language items = (types, attributes, elements, etc.).=

=C2=B7        = Moved several commonly leveraged types = out of the core schema and into common_types.=

=C2=B7        = Achieved full typing of entire schema = structure such that all attributes and elements are definitively = typed.=

=C2=B7        = Changed all identifiers from ID and IDREF = types to be QNames enabling globally unique identifiers and flexibility = for domain-specific users of CybOX to define their own identifier syntax = locally.=

=C2=B7        = Reordered attributes and elements in = numerous types to better reflect common usage and priority.=

=C2=B7        = Added major_version and minor_version = attributes for core schema.=

=C2=B7        = Added capability to characterize source = of overall observable package data and for individual observables.=

=C2=B7        = Modified the logical composition = structure such that any such compositions are now contained within a = Observable_Composition element providing improved simplicity and = modularity.=

=C2=B7        = Removed the Delta element from = ObservableType and relocated the appropriate portions (Change, Trend, = and Frequency) to appropriate locations under Stateful_Measure and = Event.=

=C2=B7        = Added a Domain_Specific_Object_Attributes = field to Object utilizing an abstract type that will allow = domain-specific use cases to add in their own domain-specific attributes = for Objects.=

=C2=B7        = Added a Tool-Specific_Data field to = ToolInformationType utilizing an abstract type that will allow addition = of tool-specific data.=

=C2=B7        = Added an Indicators field to = MeasureSourceType utilizing an abstract type that will allow = characterizing differing formats or standards of indicators that may = have led to the identification of the observable data.=

=C2=B7        = Enhanced the Hash structure to capture = full fuzzy hashes in addition to simple hashes=

=C2=B7        = Added a new ExtractedFeaturesType that = can be used to adorn differing objects (e.g., files, memory, etc.) to = capture extracted strings, imports, functions and code snippets=

=C2=B7        = Added a ByteRunsType to enable capture of = byte runs within various objects.=

=C2=B7        = Added object_reference attribute to = DefinedObjectType to better support referencing of independently defined = Objects from within another Object definition.=

=C2=B7        = Added a generic DataSegmentType to = provide a relatively abstract way of characterizing data segments that = may be written/read/transmitted or otherwise utilized in actions or = defined in objects.=

=C2=B7        Added several new = defined object schemas (API, Code, Device, DNS_Record, Network_Flow, = Network_Packet, Network_Route_Entry, Network_Subnet, = Unix_Network_Route_Entry) including an initial set of network-centric = defined objects.

=C2=B7        = Modified every defined object schema with = added annotations as well as minor and in some cases substantive changes = to fix errors, improve consistency and alignment with existing normative = references, and to improve expressiveness in support of the targeted use = cases.=

Detailed changes from CybOX_v0.7 to = CybOX_v1.0_(Draft):=

The level of changes within v1.0 (Draft) in = the core schema, common_types and the defined object schemas is too = great to list every change in these release notes. Detailed difference = reports are available for each individual schema at:http://cybox.mitre.org/XMLSchema/release_notes/cybox_v1.0= (draft)_diff_reports.zip

 =

 =

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

Sean Barnum=

Cyber Security Principal=

The MITRE Corporation=

 =

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

 

------=_NextPart_001_0060_01CD1C34.59077330-- ------=_NextPart_000_005F_01CD1C34.59077330 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYNDCCBS0w ggMVoAMCAQICEEw6UhQhT9OgRBVHf7KQ+1AwDQYJKoZIhvcNAQELBQAwKTEnMCUGA1UEAxMeTUlU UkUgQ29ycG9yYXRpb24gUEUgUm9vdCBDQS0xMB4XDTExMDQyNjE5NDU0NVoXDTIxMDQyNjE5NDgy MlowKTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUEUgUm9vdCBDQS0xMIICIjANBgkqhkiG 9w0BAQEFAAOCAg8AMIICCgKCAgEAtp8hR0hRq3im+Alwfb5ZHGP5k2OSY2TlVHYHIMUDH3MfW7b6 8lB3j3MwAMsxGK1ke/t6O4K0t9wRH4QDgOQ1CthmOGZW7xiN81h0vP1Yf14SNugUa7ZvH9KP3iXs y8QnOHal1bKf0Pa9KXib58qUuwfaZSCTW5P2ekqd8z4TETvfBWvPgDxyxnVsiAO6yL9WaRpMiSVM hYLWy3KRuU/gue0bVEi+qdg+hENh1NSNXpoqseS262nq5cx5wybR/PF0YstQ9NNlYDM5cLECKYHH zD6cXKJozuFXriswlE8rdna7VaxyZrfgC0ueEIY/tsj/65IyUhyPBwO0ZpW+Ls9Cd4Y+ERSu5mR5 Fd8w42eVzuosmk3s3AxrKC+Z4tXYkjaiWUduIegAiST1vJBwkS53vR+zrBX3Ep56l7MFVvW/GcsZ 9wUT2HG65JOeiVc2YzCEqLgQ3ZCBHn09oBag2lnMac+E2sKm9aKL3xzHs6cyD8qCJK9O8QLCqo3C mzASlOwtTFiLYgpPW/MSmgYOt9JrwHAzk97DHFKTFttjrXGMmhMVzadt1EjMn1Wv8t5WLBI0qSoX /MYi2CaeiDsEiWRu9Nmpu3pmi8m7tIR9csdbAVPks2soNMWOopGEpFQSDvU1+m77v2jIKQKYxYmN 2zUOJ4TJFL1osnZ/71MmLCDVd+ECAwEAAaNRME8wCwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMB Af8wHQYDVR0OBBYEFFuHfZ/+bL4C6fPgKTqKVCUsnzgvMBAGCSsGAQQBgjcVAQQDAgEAMA0GCSqG SIb3DQEBCwUAA4ICAQAy78sXsP/eqHH8/uOYyxQ6TBDhkCBxNoy8MF2c9UDns5ADL1qyxPAlpDBs L+2h1Zzt3FvPjg0SoRE/9juyG1qxMzhlv0jdQx12tESdo3uBb61b1uuc4H/VxCJWDI4KZL/B53EI 8HGPjUBdLADgOmG99uffm5uarSkjtIX//Bz3U6QfzTPlVWFi4SmzRI2mp16GQ8RPuJ/WMloaAn8X H6EjS2oLjGZC8Pw8/C46W48NvZ1JZTrZvYZr7GmuvmplYK68SZv/T5Su+FlLRTy9uNXQLHtm6jKv nDH2yB66zTwfaDpnjILnrC2O7ANRVZc0KywiKiW3nB7Joq74/XVuMI1PiSByt2Qu+RIS/WAI5wMi bTmwSiBxQZqvuth+dXoakJyOP2Wg5jvL55v9RLZhDqMtRI5ovnOFvTgNJQqNPSekGtA+m6Ctl/vh kSg65FFCMhaSkn7vY2Il+R8HouWJN8wTaudeexnyHcD+Mlt8QaB5CErpDjeeGZfQ0FcYm+6TtlMz Dw5eFhT/J6QrABCxfgLkVFHurMcQD4JkmXXkq5bP+GNkY0Uy2LMbw/UD94OEV1LpfAqUkT+mu5Yb vxg+elFtsad+Ix8owW372xynIADh9q1bHm+j1OHPJmGALWK9miRpC4t3isfu3ZB0QpI/e2Po6MED 393Jb0YbzrcElFv6ZDCCBhYwggP+oAMCAQICChrDbcgAAgAAN/wwDQYJKoZIhvcNAQEFBQAwUDET MBEGCgmSJomT8ixkARkWA09SRzEVMBMGCgmSJomT8ixkARkWBU1JVFJFMSIwIAYDVQQDExlNSVRS RSBDb3Jwb3JhdGlvbiBQRSBDQS0xMB4XDTEyMDMxMjE1MTgyN1oXDTE1MDMxMjE1MTgyN1owSjEL MAkGA1UEBhMCVVMxDjAMBgNVBAoTBU1JVFJFMQ8wDQYDVQQLEwZQZW9wbGUxGjAYBgNVBAMTEUJh cm51bS5TZWFuLjMxNTQzMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA9/I6RU7OcouL 6lcEJMAg8G3myNbQu84QnflS8p3PWOjgC6P50RDqGX5UxelDqMQPN5IsNYRXVY9/b7yN/RSH4goI JfYKMitndKuCKz1q38Nh0YycEm5x2t/IN/60b01T1uOmhZfptLDoDzj0UQZwMQ19mhM/ldsrC8bR GGuHXdQVaSyXygfhzNhqC06vZo5fvCBUJ6z7JtVrfRTHdudg19JYK+gds9p+Lvp/DOEXQmgpfpMl jfNKMnrG+kPMMngrIJUsF5lcbhHuc5mO+O8eR8FxM2KF7gfKVmUmZxs7Y6uLenVJVEmllP0XgUu1 sv3bClFgUo5x5Aq6rXshtHuVuQIDAQABo4IB9jCCAfIwKAYDVR0lBCEwHwYIKwYBBQUHAwQGCSsG AQQBcwIBBwYIKwYBBQUHAwIwHQYDVR0OBBYEFDvU1Ph/OVxGkxRmwvRx1TBf5PKqMA4GA1UdDwEB /wQEAwIGwDAcBgNVHREEFTATgRFzYmFybnVtQG1pdHJlLm9yZzAfBgNVHSMEGDAWgBRpZyAh1EjB 0BsGbvMIKOI6gn1BMTBJBgNVHR8EQjBAMD6gPKA6hjhodHRwOi8vcGtpLm1pdHJlLm9yZy9NSVRS RSUyMENvcnBvcmF0aW9uJTIwUEUlMjBDQS0xLmNybDB/BggrBgEFBQcBAQRzMHEwRwYIKwYBBQUH MAKGO2h0dHA6Ly9wa2kubWl0cmUub3JnL01JVFJFJTIwQ29ycG9yYXRpb24lMjBQRSUyMENBLTEo MikuY3J0MCYGCCsGAQUFBzABhhpodHRwOi8vb2NzcC5taXRyZS5vcmcvb2NzcDA+BgkrBgEEAYI3 FQcEMTAvBicrBgEEAYI3FQiDrqwjho6WV4GNiT2CpKsShb6uAYE2g9KXfYeg+0kCAWQCAQcwFgYD VR0gBA8wDTALBgkrBgEEAXMCAQgwNAYJKwYBBAGCNxUKBCcwJTAKBggrBgEFBQcDBDALBgkrBgEE AXMCAQcwCgYIKwYBBQUHAwIwDQYJKoZIhvcNAQEFBQADggIBAC2wqKo7QWQxIqnEKRznPrAQ5vQ9 X5JhB5keH8KMWu1W5n1RuSZH+3TYp4xccdYh+rV5b5+cJcWEYhtYpZriWm4kMHPaB6gKO9rbVfF9 R8Wp8sXvCKogbNhdkZwvXW4QymB1ASlMzDI1cCV8mzYgbIhWaCbV1zZBUVgOGa4LZIgdbdmgo5r/ O2gmnSftTYiE/tQ+DBs/25Bw/jC5HOiMXJqr+JctzJTqpEVLa7GKHnXWGuzGEPYkKBplxIyhz3Mv qc/yuKM7tZzAr8Qn5qf7VI9O2xp56QLjT2+mySOUR6Vml860FMpjjgZNMxAqOJt7OgY0PoUU9d18 yw1wiKSt0LUQoMcVvp7FifBjtBCG1sB/VOzxNvcNm6lO6EO23pvcjt6+WCG1X3pgnZ5UEohsM3c0 oLzYiuSYeVf85IO2yh9fWLWw2RGkf2szck1Xg0DsAQ54/YlZYyehELh43KbS3lpnTt8UlO7C0TMT 7JQwz4fTQg1a0e9rRPFnNDUG2fS2k3tz9IYILDB3F8uiZzzXptEzaYqzIqe5CK8ZGJQcw+w/CBen 6i+MV/y7yJmhio43Y1x9hIqoynqoSMV3CKYCoOwCvFUAGsNllDpExsQZoXrdd5gcuglqbh3t8wOM jtXDSQllQ/hXDZJf8rnH0wGx3K+WA+LKNvKqNCw9spEtsfG0MIIGYjCCBEqgAwIBAgIKFJcW0gAA AAAABDANBgkqhkiG9w0BAQsFADApMScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQRSBSb290 IENBLTEwHhcNMTEwNjE0MTc0NDQ0WhcNMTcwNjE0MTc1NDQ0WjBQMRMwEQYKCZImiZPyLGQBGRYD T1JHMRUwEwYKCZImiZPyLGQBGRYFTUlUUkUxIjAgBgNVBAMTGU1JVFJFIENvcnBvcmF0aW9uIFBF IENBLTEwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDSxK9RXieqdTz4JWRkRMs/EOuF 0P0S9SbspadLJkx/LDDnaAwmAnqfqm1n7/p82oVjy1yCye3SZu4Yp7fmDIAtWbkHvYOfxHkRv1ho /fhaNN0YRkd65oJJz2ngEbNZxdIiCoialQfX/iWU7ApQ+ovKbFV60v5E0p2mPncs20NYRfsaetdh nBZbFD9flDcXwJqSvGGGBfm7ifFCR1LrtEcNKjMwf7YEWZO0Vk3ZyhVq+k7JNLEbKv0OfBz8DU8G iGU+j88QlrgGW8PLkwNk7nsS/DJp8aLudTuVqIE2CA9mqn5QjU/EZYNHGzSfCr+/usUmbojyVSJu khhrAXspRAMz+Cia3yi3q3w8TnAljXWN1dhx1iuUv5GxyzMjfqK1tMuCUU2XzGNNqoVa1mqolBiy DTCOr9d/IC0YHYMBSpQ+xi0x9zjXKt4FmQmkEAZgF4hsZZqcJYL/iCQiwiz8fEyVPZuvoWvdEXOo zFYCpmkT0MZCJwyIux0Z6vJp6VLtN/6rZgc2y54HlTrp3ifazmpsfrk3NdHxlZTZug9kjEI+vEoy p/79nAPyTWQQ1MEP0ErCWav80/HOi0MLx/7lIUfvVOjkOFgFb+iDvR4T3RAQrnEpgTO+fc7Jyzh9 LpFDqm0slwDP4Hj9cC3IzdED5BU43PGAe+HoZ8OD/1ovVgwo/wIDAQABo4IBYzCCAV8wEAYJKwYB BAGCNxUBBAMCAQIwIwYJKwYBBAGCNxUCBBYEFFCiOtgZb+Zdflkw5sC2y01sUQaVMB0GA1UdDgQW BBRpZyAh1EjB0BsGbvMIKOI6gn1BMTAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTALBgNVHQ8E BAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAfBgNVHSMEGDAWgBRbh32f/my+Aunz4Ck6ilQlLJ84LzBQ BgNVHR8ESTBHMEWgQ6BBhj9odHRwOi8vcGtpLm1pdHJlLm9yZy9NSVRSRSUyMENvcnBvcmF0aW9u JTIwUEUlMjBSb290JTIwQ0EtMS5jcmwwWwYIKwYBBQUHAQEETzBNMEsGCCsGAQUFBzAChj9odHRw Oi8vcGtpLm1pdHJlLm9yZy9NSVRSRSUyMENvcnBvcmF0aW9uJTIwUEUlMjBSb290JTIwQ0EtMS5j cnQwDQYJKoZIhvcNAQELBQADggIBAHnDPfdYKxqNOtAYXMyyel83Vs8cCDAQZhSuIB0c6GkGoEdF rmWH9pwi42V96rCp7TvbNNKNJXbVHfJUAp+uqw663DL/sXXff9ZFxPxKOdPnpA8cKM7RBH9e437N w3d28A7PaGbP6tXmSqhXAhYZ4U12y1U5cOf2G/phUoAAMlnVJdfmXzMazvLo2SIeixAJyCze6rHQ TFQ/N+gAjbVuRJ+Hs8FEKVzMSwqlNoupe2ELqL4dMAKT6P08sAfxm2SrRlQvcWPYvqM/1C10bgc2 tdu+WGzRuP5Wx9Yr15KO9SW4z7fn2RVEXQgoDDno5vCIcfUPuKB5n+Kt9eBCitsgSD9yYsNUN9LE VIvjAb8MV2LWLfge1bumo6g7QMRa4Fgifw5siGwi7V2EaJQo6UAIVvxKKFC7W4p6CkrY2ga1d7GI Q0DPiWZOezOakJVAxL5gf+3WdNt0igKc/yLfbdHn6hCd1KPgDqkSKr8zWOZI/jiDBW957xAmaO6Q dGQDBZrQHWpIVwQGzF5bGrqms2kq49l3t7KmBu0C/9tExqKAmlf4Y5lfQGdCbKQpAq712DVQHYuD XmVQEAc2vlJ1C5hS3Iw9DwBWTfJ4vyB48buhBhbIhPiFta5OizXlKcsIi99ikA1yiZx/DBtjaw4J U6qJzWUFB2ecyGCNPtNbYjURA0A9MIIGfzCCBGegAwIBAgIKGsNq2wACAAA3+jANBgkqhkiG9w0B AQUFADBQMRMwEQYKCZImiZPyLGQBGRYDT1JHMRUwEwYKCZImiZPyLGQBGRYFTUlUUkUxIjAgBgNV BAMTGU1JVFJFIENvcnBvcmF0aW9uIFBFIENBLTEwHhcNMTIwMzEyMTUxODI3WhcNMTUwMzEyMTUx ODI3WjBKMQswCQYDVQQGEwJVUzEOMAwGA1UEChMFTUlUUkUxDzANBgNVBAsTBlBlb3BsZTEaMBgG A1UEAxMRQmFybnVtLlNlYW4uMzE1NDMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCW InZvCSslmSfSyhTVVSqnokCDajlsCNZHfUlkwkV1++2O71BYvMpjFHWR2XFIx963Hl63lFZzzVci OjIwLb1c/0YXhFfUdAvrbpjlu+ttlO05OEUW0h+5HO+qaebJPamxA00w0bokquRcPxUvwa3jiyL0 WfCwE3+/b5PCOW2xh7FXFKv262FnKIwxnQGXqkiXRP5D/SmdtcZSzxHkDThrhaiHPhJJhZ4XxwBk aGcAlMg8YH6uxshXm8e6c7XUu7gB5p+XThS0dqXujpQp/UQDp5t079+UrDcrpjfDBXIt9qCzLn26 uV5a4cD4xRKwA32f1cXFtiKXM0wYgUM3fEPDAgMBAAGjggJfMIICWzATBgNVHSUEDDAKBggrBgEF BQcDBDCBlAYJKoZIhvcNAQkPBIGGMIGDMA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DBAICAIAw BwYFKw4DAgcwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBLTALBglghkgBZQME ARYwCwYJYIZIAWUDBAEZMAsGCWCGSAFlAwQBAjALBglghkgBZQMEAQUwHQYDVR0OBBYEFIrbKa+E Rxo2/Sth2C6jZqZqvRE7MA4GA1UdDwEB/wQEAwIFIDAcBgNVHREEFTATgRFzYmFybnVtQG1pdHJl Lm9yZzAfBgNVHSMEGDAWgBRpZyAh1EjB0BsGbvMIKOI6gn1BMTBJBgNVHR8EQjBAMD6gPKA6hjho dHRwOi8vcGtpLm1pdHJlLm9yZy9NSVRSRSUyMENvcnBvcmF0aW9uJTIwUEUlMjBDQS0xLmNybDB/ BggrBgEFBQcBAQRzMHEwRwYIKwYBBQUHMAKGO2h0dHA6Ly9wa2kubWl0cmUub3JnL01JVFJFJTIw Q29ycG9yYXRpb24lMjBQRSUyMENBLTEoMikuY3J0MCYGCCsGAQUFBzABhhpodHRwOi8vb2NzcC5t aXRyZS5vcmcvb2NzcDA+BgkrBgEEAYI3FQcEMTAvBicrBgEEAYI3FQiDrqwjho6WV4GNiT2CpKsS hb6uAYE2hquSaISo7EUCAWQCAQ8wFgYDVR0gBA8wDTALBgkrBgEEAXMCAQgwGwYJKwYBBAGCNxUK BA4wDDAKBggrBgEFBQcDBDANBgkqhkiG9w0BAQUFAAOCAgEAGmmL43yA+J5lEockM1cxSoyxfSES HUGLVJyrhObbdFD4yO3jf0R4lHLuJlhp1486d9LRZAyzAnl9q8Zf3Tx1rl1kEd3pw0wMuO+ATscc rArEW/rJxjz6zTrNO3PFkFuOEdmKpHaRiFpuSX602INiBEBPluei3uZlWxHW9VqC7hz2diQpOlzS jtPMbL3o7ACjWaq7sQ0xB4rZ6oWyqOZEfHWQA1b7nFgL4nEbmEHNdU4jAjcxkROku4O04205kb5n Loveoz3TSQNt8zalFayZAjt+JEcKuG1f5cyhYI6QwvkS/3M+CjJezuNaSmno29Lm+ToZnwUm4nIB YkBx4r9ZDU2W8029tr5og00A5MGo1LK+unWtHBa7zuPblfSiYgXIHWU+OKrSFaA935Yb4fLXFe9S BmApBr1gohHYos1hct5q90WPufSKIQ9WT+vJYXvW3FpseO4ZLKVnJsO7gVoQEEnWJUwyABBPQrii F0gh++ApKZJROTuR36PsEEx4duI6U4VXMCiIcnEjvNR8Mt5Q/Vp4W4Mp5fCv+QzYkqq9EWD7QuUW Yul6R8Hf7ZTxbUk0NfJgu8escLrgQSwMdP/kE/09vJAAslQBkNnIS7iIhWt4l5XQJBrJc+6popRE R8ykWf25e4CliaUgbAl1tBQKivQ3tlX99WykI2XK3sTk9nsxggMjMIIDHwIBATBeMFAxEzARBgoJ kiaJk/IsZAEZFgNPUkcxFTATBgoJkiaJk/IsZAEZFgVNSVRSRTEiMCAGA1UEAxMZTUlUUkUgQ29y cG9yYXRpb24gUEUgQ0EtMQIKGsNtyAACAAA3/DAJBgUrDgMCGgUAoIIBmjAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjA0MTcwNDUyMjJaMCMGCSqGSIb3DQEJBDEW BBQ2/2p5eyn1OdOJf+igIyphE3O8wzBbBgkqhkiG9w0BCQ8xTjBMMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMC GjBtBgkrBgEEAYI3EAQxYDBeMFAxEzARBgoJkiaJk/IsZAEZFgNPUkcxFTATBgoJkiaJk/IsZAEZ FgVNSVRSRTEiMCAGA1UEAxMZTUlUUkUgQ29ycG9yYXRpb24gUEUgQ0EtMQIKGsNq2wACAAA3+jBv BgsqhkiG9w0BCRACCzFgoF4wUDETMBEGCgmSJomT8ixkARkWA09SRzEVMBMGCgmSJomT8ixkARkW BU1JVFJFMSIwIAYDVQQDExlNSVRSRSBDb3Jwb3JhdGlvbiBQRSBDQS0xAgoaw2rbAAIAADf6MA0G CSqGSIb3DQEBAQUABIIBAFuRmex2OLXGWaQKy8DpGgjhNbykeWhN8CUZYbL2wPL6w9j8nVmR8ftP guYaRc/cu3Kleh1HP9gDuKoQin2mksbV/cpXnjDnt3KXbaEHg/HaPjjFwH1NNwd930xuwfefDEbv XnYZg5pO6pUEXmaqSWsW+p60kCZl0rwnehAaz53emrDcDuIE971bQzAZPiUt/aBpimATcY/+sQmM SEJ7Onz19i0f97ZyOQ6aOH0pDpwRzFb2LCAZXS0V28WJdeOCFrnIEprA1ezUwuH30xtW6wj/UJnX Ti8GNA+YzOcH3PnyskowNQyjdgHC9dOs9SdsvfoyFykQQWhOLL/SSnLkHfgAAAAAAAA= ------=_NextPart_000_005F_01CD1C34.59077330-- From sbarnum@mitre.org Mon Apr 16 22:09:42 2012 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 B430121F8609; Mon, 16 Apr 2012 22:09:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QUmy0LAOHoPn; Mon, 16 Apr 2012 22:09:37 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 22ACF21F8608; Mon, 16 Apr 2012 22:09:37 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 85F9F21B0E86; Tue, 17 Apr 2012 01:09:36 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 6112321B0E73; Tue, 17 Apr 2012 01:09:36 -0400 (EDT) Received: from IMCMBX03.MITRE.ORG ([169.254.3.179]) by IMCCAS01.MITRE.ORG ([129.83.29.78]) with mapi id 14.02.0283.003; Tue, 17 Apr 2012 01:09:35 -0400 From: "Barnum, Sean D." To: "Omar Santos (osantos)" , "Millar, Thomas" , "lnunez@c3isecurity.com" Thread-Topic: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe website Thread-Index: AQHNHC91EoahZz2AEEqd+yKyGmroMJaeWIaQgAAIZb+AAAIPgIAAEJ3A Date: Tue, 17 Apr 2012 05:09:35 +0000 Message-ID: <7F48813B48558A4BB5CB7BB714E5B5A9171BA1@IMCMBX03.MITRE.ORG> References: <7F48813B48558A4BB5CB7BB714E5B5A9171B16@IMCMBX03.MITRE.ORG> <69CE2DCD9DAC3D48B830E0723141170B02A39BD2@ZAU1UG-0308.DHSNET.DS1.DHS> <953A2E460DBE7C43AC13E30B87C5B4FF080A1C09@XMB-RCD-106.cisco.com> In-Reply-To: <953A2E460DBE7C43AC13E30B87C5B4FF080A1C09@XMB-RCD-106.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.31.136.182] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0066_01CD1C36.BDA3E920" MIME-Version: 1.0 Cc: "idxwg@nicwg.org" , "mile@ietf.org" , "dallendoug@gmail.com" , "sacm@ietf.org" , "m-terada@ipa.go.jp" Subject: Re: [mile] [sacm] CybOX v1.0 (Draft) is now released and live onthe website 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, 17 Apr 2012 05:09:42 -0000 ------=_NextPart_000_0066_01CD1C36.BDA3E920 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0067_01CD1C36.BDA3E920" ------=_NextPart_001_0067_01CD1C36.BDA3E920 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable =E2=80=9Cupper layer=E2=80=9D? Yes, as in higher abstraction. Just =E2=80=9Cprotocols=E2=80=9D? No. =20 You guys have been looking at this through the lens of network flow = which if fine for thinking about that perspective but it is important to = also realize that the EventTypeEnum and its =E2=80=9CData Flow=E2=80=9D = value go far beyond network-related scope. It is about a lot of other types of potential data flows (as I just = outlined in a response to Tom) that have nothing to do with network = flow. =20 Thanks for your response though. This is the kind of discussions that we = hope to have a lot more of among the various supported communities. =20 =20 BTW, you may have noticed that the Network_Flow object within CybOX v1.0 = (Draft) supports expression of netflow within several of the most common = formats including Netflow9 (as well as IPFIX as Luis pointed out, = Netflow5 and SiLK as well as bi-directional flow in YAF). The common = 5-tuple or 7-tuple (you describe) (in our case it is an 8-tuple as we = broke the router interface out into both ingress and egress J) shared by = pretty much all of the netflow approaches has been broken out into a = shared Network_Flow_Label structure. The various context-dependent = portions of the independent approaches are then captured within optional = structures dedicated to each of them. We hope that eventually the = community can work to come together towards a single overall common = expressive structure for netflow that meets the needs of all. We hope = that CybOX and its use can even help that sort of maturation and = normalization. But since no such universal structure exists today, we = decided to enable optional expression of the most common individual = formats within a single netflow object to serve the large majority of = relevant users, maintain flexibility and enable discussions and analysis = of netflow within a common package. We look forward to continuing discussions with the community to validate = or invalidate this approach and to refine and mature going forward. =20 Sean=20 =20 From: Omar Santos (osantos) [mailto:osantos@cisco.com]=20 Sent: Monday, April 16, 2012 11:57 PM To: Millar, Thomas; Barnum, Sean D.; lnunez@c3isecurity.com Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; = m-terada@ipa.go.jp Subject: RE: [sacm] [mile] CybOX v1.0 (Draft) is now released and live = onthe website =20 I believe that what Sean is saying is that =E2=80=9Cdata flow=E2=80=9D = is just a value that is meant for upper layer protocols. But, you have a = good point. Traditionally, a =E2=80=9Cflow=E2=80=9D in = =E2=80=9CNetflow=E2=80=9D is based on a set of 5 and up to 7 IP packet = attributes: =20 - IP source address - IP destination address - Source port - Destination port - Layer 3 protocol type - Class of Service - Router or switch interface =20 Although, there is a lot more support with Netflow version 9: http://www.cisco.com/en/US/technologies/tk648/tk362/technologies_white_pa= per09186a00800a3db9_ps6601_Products_White_Paper.html =20 =20 =20 Regards, Omar=20 =20 From: Millar, Thomas [mailto:Thomas.Millar@hq.dhs.gov]=20 Sent: Monday, April 16, 2012 11:46 PM To: sbarnum@mitre.org; Omar Santos (osantos); lnunez@c3isecurity.com Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; = m-terada@ipa.go.jp Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live = onthe website =20 If "data flow" is a euphemism for "netflow" is there any reason not to = call it that? Tom Millar=20 http://www.us-cert.gov/=20 ------------------=20 Missit me Rubus fruticosus:=20 202 631 1915=20 =20 From: Barnum, Sean D. [mailto:sbarnum@mitre.org]=20 Sent: Monday, April 16, 2012 11:29 PM To: Omar Santos (osantos) ; Luis Nunez = =20 Cc: idxwg@nicwg.org ; mile@ietf.org ; = dallendoug@gmail.com ; sacm@ietf.org = ; m-terada@ipa.go.jp =20 Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live = onthe website=20 =20 Thanks Omar. =20 To answer your question, first let me point out to other readers that = the two entries that Omar is quoting here exist as values in an = enumeration called EventTypeEnum which as its name implies contains a = list of different labels for grouping types (or classes) of events to be = used as low-granularity buckets for characterizing and classifying = events. Other entries in this enumeration include things like =E2=80=9CFile Ops = (CRUD)=E2=80=9D, =E2=80=9CProcess Mgt=E2=80=9D, =E2=80=9CAuthorization = (ACL)=E2=80=9D, etc. =20 The =E2=80=9CPacket Traffic=E2=80=9D value is intended to characterize = events dealing with network packet traffic as its name implies. The =E2=80=9CData Flow=E2=80=9D value is intended to characterize events = dealing with forms of data flow at a higher level of abstraction than = just packet traffic. The relationship between these two values could be = viewed as =E2=80=9CPacket Traffic=E2=80=9D being a more detailed form of = =E2=80=9CData Flow=E2=80=9D just as the values =E2=80=9CApp Layer = Traffic=E2=80=9D and =E2=80=9CHTTP Layer Traffic=E2=80=9D, also in this = enumeration, could be other levels in this same abstraction stack. The idea behind the varying levels of abstraction is to leave buckets = large enough to capture a wide variety of potential event types (e.g. = data flow events other than obvious things like packet traffic) but also = enable the use of smaller more specific buckets when they are = appropriate and commonly used. =20 Does this make sense?=20 =20 sean =20 From: Omar Santos (osantos) [mailto:osantos@cisco.com]=20 Sent: Monday, April 16, 2012 8:17 PM To: Luis Nunez; Barnum, Sean D. Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; = m-terada@ipa.go.jp Subject: RE: [sacm] [mile] CybOX v1.0 (Draft) is now released and live = onthe website =20 I echo Luis=E2=80=99 comments. It is good to see the inclusion of = network objects. Quick question to the team related to your netflow = comment. =20 I am looking at: http://cybox.mitre.org/XMLSchema/cybox_core_v1.0%28draft%29.xsd =20 =E2=80=A6 and it looks that we renamed it to =E2=80=9CData = Flow=E2=80=9D? =20 Specifies the class of events dealing with = data flow. =20 =20 What is the difference between that and =E2=80=9CPacket = Traffic=E2=80=9D? =20 Specifies the class of events dealing with packet = traffic. =20 =20 =20 =20 Regards, Omar Santos Incident Manager, PSIRT Security Research and Operations Cisco Systems, Inc. Email: os@cisco.com Phone: +1 919 392 8635 PGP Key: 0x3AF27EDC Cisco.com - http://www.cisco.com Cisco Security Advisories and Notices - http://www.cisco.com/go/psirt This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message. For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html =20 From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of = Luis Nunez Sent: Monday, April 16, 2012 6:44 PM To: Barnum, Sean D. Cc: idxwg@nicwg.org; mile@ietf.org; Doug Wilson (dallendoug@gmail.com); = sacm@ietf.org; IPA-Masato Terada (m-terada@ipa.go.jp) Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live = onthe website =20 I like the inclusion of the network-centric objects. IPFIX (netflow) = will add an additional perspective from an incident information sharing = standpoint. =20 =20 -ln =20 On Apr 16, 2012, at 4:04 PM, Barnum, Sean D. wrote: =20 Hey everyone, =20 I just wanted to let you all know that CybOX v1.0 (Draft) content is now = live on the website. http://cybox.mitre.org The release notes are provided inline below. The key items of note are: =C2=B7 The release of two formal specifications for the CybOX = language (one for the core language and one for the defined objects) =C2=B7 The XML Schema has gone through extensive improvements for = expressiveness, clarity, consistency, efficiency, alignment to existing = normative references and documentation. =C2=B7 This release includes an initial set of language = utilities: a draft Snort -> CybOX transform, a draft OpenIOC -> CybOX = transform, and a set of Python bindings for the CybOX language. =C2=B7 The website now includes a small set of content examples. = This set will grow going forward. This release involved a lot of hard work from a diverse group of people. = Thank you all for your contributions and effort. We could not have done = it without you. We look forward to everyone=E2=80=99s feedback and collaboration as we = continue to improve and mature the CybOX language. =20 Sean Barnum =20 =20 =20 CybOX v1.0 (Draft) Release Notes The Version 1.0 (Draft) release of Cyber Observable eXpression = (CybOX=E2=84=A2) is intended as a draft release of an initial major = version of the CybOX Language that could be utilized for practical = operational use and integration into other standards efforts. This = release consists of three primary components: a pair of formal language = specifications for the core language content and defined objects = content, a set of language implementation XML schemas (core, = common_types, and ~70 defined object schemas), and a small initial set = of language utilities including an initial draft Snort->CybOX transform, = an initial draft OpenIOC->CybOX transform and a set of CybOX language = Python bindings. Recognizing that this is the first time that the formal = language specifications will be available for review and as such will = likely generate feedback from new stakeholders, this initial major = version is being released as a =E2=80=9Cdraft=E2=80=9D v1.0 with the = expectation of cycles of new feedback and revision before a = =E2=80=9Cfinal=E2=80=9D v1.0 is released. The CybOX v1.0 (Draft) XML schemas include a significant number of = changes from v0.7 to improve: =C2=B7 Clarity, documentation, and descriptive formality for = reference and implementation by other standards and users. =C2=B7 Consistency, simplicity, and efficiency. =C2=B7 Alignment (as appropriate) to existing normative = references. =C2=B7 Expressiveness of the schema to better support the broad = set of use cases it targets (malware characterization, indicator and = incident data sharing, event management, etc.) including the addition of = an initial set of network-related defined objects. Summary of changes from CybOX_v0.7 to CybOX_v1.0_(Draft): =C2=B7 Refinement of namespaces and schema locations for better = effectiveness and flexibility going forward. =C2=B7 Normalized all content according to an established set of = naming conventions. =C2=B7 Fully annotated all language items (types, attributes, = elements, etc.). =C2=B7 Moved several commonly leveraged types out of the core = schema and into common_types. =C2=B7 Achieved full typing of entire schema structure such that = all attributes and elements are definitively typed. =C2=B7 Changed all identifiers from ID and IDREF types to be = QNames enabling globally unique identifiers and flexibility for = domain-specific users of CybOX to define their own identifier syntax = locally. =C2=B7 Reordered attributes and elements in numerous types to = better reflect common usage and priority. =C2=B7 Added major_version and minor_version attributes for core = schema. =C2=B7 Added capability to characterize source of overall = observable package data and for individual observables. =C2=B7 Modified the logical composition structure such that any = such compositions are now contained within a Observable_Composition = element providing improved simplicity and modularity. =C2=B7 Removed the Delta element from ObservableType and = relocated the appropriate portions (Change, Trend, and Frequency) to = appropriate locations under Stateful_Measure and Event. =C2=B7 Added a Domain_Specific_Object_Attributes field to Object = utilizing an abstract type that will allow domain-specific use cases to = add in their own domain-specific attributes for Objects. =C2=B7 Added a Tool-Specific_Data field to ToolInformationType = utilizing an abstract type that will allow addition of tool-specific = data. =C2=B7 Added an Indicators field to MeasureSourceType utilizing = an abstract type that will allow characterizing differing formats or = standards of indicators that may have led to the identification of the = observable data. =C2=B7 Enhanced the Hash structure to capture full fuzzy hashes = in addition to simple hashes =C2=B7 Added a new ExtractedFeaturesType that can be used to = adorn differing objects (e.g., files, memory, etc.) to capture extracted = strings, imports, functions and code snippets =C2=B7 Added a ByteRunsType to enable capture of byte runs within = various objects. =C2=B7 Added object_reference attribute to DefinedObjectType to = better support referencing of independently defined Objects from within = another Object definition. =C2=B7 Added a generic DataSegmentType to provide a relatively = abstract way of characterizing data segments that may be = written/read/transmitted or otherwise utilized in actions or defined in = objects. =C2=B7 Added several new defined object schemas (API, Code, = Device, DNS_Record, Network_Flow, Network_Packet, Network_Route_Entry, = Network_Subnet, Unix_Network_Route_Entry) including an initial set of = network-centric defined objects. =C2=B7 Modified every defined object schema with added = annotations as well as minor and in some cases substantive changes to = fix errors, improve consistency and alignment with existing normative = references, and to improve expressiveness in support of the targeted use = cases. Detailed changes from CybOX_v0.7 to CybOX_v1.0_(Draft): The level of changes within v1.0 (Draft) in the core schema, = common_types and the defined object schemas is too great to list every = change in these release notes. Detailed difference reports are available = for each individual schema at: = = http://cybox.mitre.org/XMLSchema/release_notes/cybox_v1.0(draft)_diff_rep= orts.zip =20 =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Sean Barnum Cyber Security Principal The MITRE Corporation Email: sbarnum@mitre.org =20 _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile =20 ------=_NextPart_001_0067_01CD1C36.BDA3E920 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

=E2=80=9Cupper layer=E2=80=9D? Yes, as in higher = abstraction.

Just =E2=80=9Cprotocols=E2=80=9D? No.

 

You guys have been looking at this through the lens of network flow = which if fine for thinking about that perspective but it is important to = also realize that the EventTypeEnum and its =E2=80=9CData Flow=E2=80=9D = value go far beyond network-related scope.

It is about a lot of other types of potential data flows (as I just = outlined in a response to Tom) that have nothing to do with network = flow.

 

Thanks for your response though. This is the kind of discussions that = we hope to have a lot more of among the various supported = communities.

 

 

BTW, you may have noticed that the Network_Flow object within CybOX = v1.0 (Draft) supports expression of netflow within several of the most = common formats including Netflow9 (as well as IPFIX as Luis pointed out, = Netflow5 and SiLK as well as bi-directional flow in YAF). The common = 5-tuple or 7-tuple (you describe) (in our case it is an 8-tuple as we = broke the router interface out into both ingress and egress J) shared by pretty much all of the netflow approaches has been broken = out into a shared Network_Flow_Label structure. The various = context-dependent portions of the independent approaches are then = captured within optional structures dedicated to each of them. We hope = that eventually the community can work to come together towards a single = overall common expressive structure for netflow that meets the needs of = all. We hope that CybOX and its use can even help that sort of = maturation and normalization. But since no such universal structure = exists today, we decided to enable optional expression of the most = common individual formats within a single netflow object to serve the = large majority of relevant users, maintain flexibility and enable = discussions and analysis of netflow within a common = package.

We look forward to continuing discussions with the community to = validate or invalidate this approach and to refine and mature going = forward.

 

Sean

 

From:= = Omar Santos (osantos) [mailto:osantos@cisco.com]
Sent: = Monday, April 16, 2012 11:57 PM
To: Millar, Thomas; Barnum, = Sean D.; lnunez@c3isecurity.com
Cc: idxwg@nicwg.org; = mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; = m-terada@ipa.go.jp
Subject: RE: [sacm] [mile] CybOX v1.0 = (Draft) is now released and live onthe = website

 

I believe that what Sean is saying is that =E2=80=9Cdata = flow=E2=80=9D is just a value that is meant for upper layer protocols. = But, you have a good point. Traditionally, a =E2=80=9Cflow=E2=80=9D in = =E2=80=9CNetflow=E2=80=9D is based on a set of 5 and up to 7 IP packet = attributes:

 

- IP source address

- IP destination address

- Source port

- Destination port

- Layer 3 protocol type

- Class of Service

- Router or switch interface

 

Although, there is a lot more support with Netflow version = 9:

http://www.= cisco.com/en/US/technologies/tk648/tk362/technologies_white_paper09186a00= 800a3db9_ps6601_Products_White_Paper.html

 

 

 

Regards,

Omar

 

From:= = Millar, Thomas [mailto:Thomas.Millar@h= q.dhs.gov]
Sent: Monday, April 16, 2012 11:46 = PM
To: sbarnum@mitre.org; Omar Santos = (osantos); lnunez@c3isecurity.com
C= c: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; m-terada@ipa.go.jp
Subject:<= /b> Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe = website

 

If "data flow" is a euphemism for "netflow" is = there any reason not to call it that?

Tom Millar
http://www.us-cert.gov/ =
------------------
Missit me Rubus fruticosus:
202 631 1915 =

 

From<= /b>: = Barnum, Sean D. [mailto:sbarnum@mitre.org]=
Sent: Monday, April 16, 2012 11:29 PM
To: Omar = Santos (osantos) <osantos@cisco.com>; Luis Nunez = <lnunez@c3isecurity.com> =
Cc: idxwg@nicwg.org = <idxwg@nicwg.org>; mile@ietf.org <mile@ietf.org>; dallendoug@gmail.com <dallendoug@gmail.com>; sacm@ietf.org <sacm@ietf.org>; m-terada@ipa.go.jp <m-terada@ipa.go.jp> =
Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released = and live onthe website
 

Thanks Omar.

 

To answer your question, first let me point out to other readers that = the two entries that Omar is quoting here exist as values in an = enumeration called EventTypeEnum which as its name implies contains a = list of different labels for grouping types (or classes) of events to be = used as low-granularity buckets for characterizing and classifying = events.

Other entries in this enumeration include things like =E2=80=9CFile = Ops (CRUD)=E2=80=9D, =E2=80=9CProcess Mgt=E2=80=9D, = =E2=80=9CAuthorization (ACL)=E2=80=9D, etc.

 

The =E2=80=9CPacket Traffic=E2=80=9D value is intended to = characterize events dealing with network packet traffic as its name = implies.

The =E2=80=9CData Flow=E2=80=9D value is intended to characterize = events dealing with forms of data flow at a higher level of abstraction = than just packet traffic. The relationship between these two values = could be viewed as =E2=80=9CPacket Traffic=E2=80=9D being a more = detailed form of =E2=80=9CData Flow=E2=80=9D just as the values = =E2=80=9CApp Layer Traffic=E2=80=9D and =E2=80=9CHTTP Layer = Traffic=E2=80=9D, also in this enumeration, could be other levels in = this same abstraction stack.

The idea behind the varying levels of abstraction is to leave =  buckets large enough to capture a wide variety of potential event = types (e.g. data flow events other than obvious things like packet = traffic) but also enable the use of smaller more specific buckets when = they are appropriate and commonly used.

 

Does this make sense?

 

sean

 

From:= = Omar Santos (osantos) [mailto:osantos@cisco.com]=
Sent: Monday, April 16, 2012 8:17 PM
To: Luis = Nunez; Barnum, Sean D.
Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; m-terada@ipa.go.jp
Subject:<= /b> RE: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe = website

 

I echo Luis=E2=80=99 comments. It is good to see the inclusion of = network objects. Quick question to the team related to your netflow = comment.

 

I am looking at:

= http://cybox.mitre.org/XMLSchema/cybox_core_v1.0%28draft%29.xsd<= /o:p>

 

=E2=80=A6 and it looks that we renamed it to =E2=80=9CData = Flow=E2=80=9D?

 

<xs:enumeration = value=3D"Data Flow">

   = <xs:annotation>

        = <xs:documentation>Specifies the class of events dealing with data = flow.</xs:documentation>

   = </xs:annotation>

</xs:enumeration>

 

 

What is the difference between that and =E2=80=9CPacket = Traffic=E2=80=9D?

 

<xs:enumeration value=3D"Packet =
Traffic">
   =
<xs:annotation>
     =
<xs:documentation>Specifies the class of events dealing with =
packet traffic.</xs:documentation>
   =
</xs:annotation>
</xs:enumeration>

 

 

 

 

Regards,

Omar Santos
Incident Manager, = PSIRT
Security Research and Operations
Cisco Systems, = Inc.
Email: os@cisco.com
Phone: +1 919 392 = 8635
PGP Key: 0x3AF27EDC

Cisco.com - http://www.cisco.com
Cisco Security = Advisories and Notices - http://www.cisco.com/go/psirt<= br>
This email may contain confidential and privileged material for = the sole
use of the intended recipient. Any review, use, distribution = or
disclosure by others is strictly prohibited. If you are not the = intended
recipient (or authorized to receive for the recipient), = please contact
the sender by reply email and delete all copies of = this message.

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html=

 

From:= = sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.= org] On Behalf Of Luis Nunez
Sent: Monday, April = 16, 2012 6:44 PM
To: Barnum, Sean D.
Cc: idxwg@nicwg.org; mile@ietf.org; Doug Wilson (dallendoug@gmail.com); sacm@ietf.org; IPA-Masato Terada (m-terada@ipa.go.jp)
Subject:= Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe = website

 

I like the inclusion of the network-centric = objects.  IPFIX (netflow)  will add an additional perspective = from an incident information sharing standpoint. =  

 

-ln

 

On Apr 16, 2012, at 4:04 = PM, Barnum, Sean D. wrote:

 

Hey = everyone,

 =

I just = wanted to let you all know that CybOX v1.0 (Draft) content is now live = on the website. http://cybox.mitre.org

The = release notes are provided inline = below.

The key = items of note are:

=C2=B7        The = release of two formal specifications for the CybOX language (one for the = core language and one for the defined = objects)

=C2=B7        The XML = Schema has gone through extensive improvements for expressiveness, = clarity, consistency, efficiency, alignment to existing normative = references and documentation.

=C2=B7        This = release includes an initial set of language utilities: a draft Snort = -> CybOX transform, a draft OpenIOC -> CybOX transform, and a set = of Python bindings for the CybOX language.

=C2=B7        The = website now includes a small set of content examples. This set will grow = going forward.

This = release involved a lot of hard work from a diverse group of people. = Thank you all for your contributions and effort. We could not have done = it without you.

We look = forward to everyone=E2=80=99s feedback and collaboration as we continue = to improve and mature the CybOX = language.

 =

Sean = Barnum

 =

 =

 =

CybOX v1.0 (Draft) Release = Notes

The Version 1.0 (Draft) release of Cyber = Observable eXpression (CybOX=E2=84=A2) is intended as a draft release of an initial major version of = the CybOX Language that could be utilized for practical operational use = and integration into other standards efforts. This release consists of = three primary components: a pair of formal language specifications for = the core language content and defined objects content, a set of language = implementation XML schemas (core, common_types, and ~70 defined object = schemas), and a small initial set of language utilities including an = initial draft Snort->CybOX transform, an initial draft = OpenIOC->CybOX transform and a set of CybOX language Python bindings. = Recognizing that this is the first time that the formal language = specifications will be available for review and as such will likely = generate feedback from new stakeholders, this initial major version is = being released as a =E2=80=9Cdraft=E2=80=9D v1.0 with the expectation of = cycles of new feedback and revision before a =E2=80=9Cfinal=E2=80=9D = v1.0 is released.=

The CybOX v1.0 (Draft) XML schemas include a = significant number of changes from v0.7 to improve:=

=C2=B7       Clarity, = documentation, and descriptive formality for reference and = implementation by other standards and users.=

=C2=B7       Consistency, = simplicity, and efficiency.=

=C2=B7       Alignment (as = appropriate) to existing normative references.=

=C2=B7       Expressiveness of the = schema to better support the broad set of use cases it targets (malware = characterization, indicator and incident data sharing, event management, = etc.) including the addition of an initial set of network-related = defined objects.=

Summary = of changes from CybOX_v0.7 to CybOX_v1.0_(Draft):=

=C2=B7        = Refinement of namespaces and schema = locations for better effectiveness and flexibility going forward.=

=C2=B7        = Normalized all content according to an = established set of naming conventions.=

=C2=B7        = Fully annotated all language items = (types, attributes, elements, etc.).=

=C2=B7        = Moved several commonly leveraged types = out of the core schema and into common_types.=

=C2=B7        = Achieved full typing of entire schema = structure such that all attributes and elements are definitively = typed.=

=C2=B7        = Changed all identifiers from ID and IDREF = types to be QNames enabling globally unique identifiers and flexibility = for domain-specific users of CybOX to define their own identifier syntax = locally.=

=C2=B7        = Reordered attributes and elements in = numerous types to better reflect common usage and priority.=

=C2=B7        = Added major_version and minor_version = attributes for core schema.=

=C2=B7        = Added capability to characterize source = of overall observable package data and for individual observables.=

=C2=B7        = Modified the logical composition = structure such that any such compositions are now contained within a = Observable_Composition element providing improved simplicity and = modularity.=

=C2=B7        = Removed the Delta element from = ObservableType and relocated the appropriate portions (Change, Trend, = and Frequency) to appropriate locations under Stateful_Measure and = Event.=

=C2=B7        = Added a Domain_Specific_Object_Attributes = field to Object utilizing an abstract type that will allow = domain-specific use cases to add in their own domain-specific attributes = for Objects.=

=C2=B7        = Added a Tool-Specific_Data field to = ToolInformationType utilizing an abstract type that will allow addition = of tool-specific data.=

=C2=B7        = Added an Indicators field to = MeasureSourceType utilizing an abstract type that will allow = characterizing differing formats or standards of indicators that may = have led to the identification of the observable data.=

=C2=B7        = Enhanced the Hash structure to capture = full fuzzy hashes in addition to simple hashes=

=C2=B7        = Added a new ExtractedFeaturesType that = can be used to adorn differing objects (e.g., files, memory, etc.) to = capture extracted strings, imports, functions and code snippets=

=C2=B7        = Added a ByteRunsType to enable capture of = byte runs within various objects.=

=C2=B7        = Added object_reference attribute to = DefinedObjectType to better support referencing of independently defined = Objects from within another Object definition.=

=C2=B7        = Added a generic DataSegmentType to = provide a relatively abstract way of characterizing data segments that = may be written/read/transmitted or otherwise utilized in actions or = defined in objects.=

=C2=B7        Added several new = defined object schemas (API, Code, Device, DNS_Record, Network_Flow, = Network_Packet, Network_Route_Entry, Network_Subnet, = Unix_Network_Route_Entry) including an initial set of network-centric = defined objects.

=C2=B7        = Modified every defined object schema with = added annotations as well as minor and in some cases substantive changes = to fix errors, improve consistency and alignment with existing normative = references, and to improve expressiveness in support of the targeted use = cases.=

Detailed changes from CybOX_v0.7 to = CybOX_v1.0_(Draft):=

The level of changes within v1.0 (Draft) in = the core schema, common_types and the defined object schemas is too = great to list every change in these release notes. Detailed difference = reports are available for each individual schema at:http://cybox.mitre.org/XMLSchema/release_notes/cybox_v1.0= (draft)_diff_reports.zip

 =

 =

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

Sean Barnum=

Cyber Security Principal=

The MITRE Corporation=

 =

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

 

------=_NextPart_001_0067_01CD1C36.BDA3E920-- ------=_NextPart_000_0066_01CD1C36.BDA3E920 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYNDCCBS0w ggMVoAMCAQICEEw6UhQhT9OgRBVHf7KQ+1AwDQYJKoZIhvcNAQELBQAwKTEnMCUGA1UEAxMeTUlU UkUgQ29ycG9yYXRpb24gUEUgUm9vdCBDQS0xMB4XDTExMDQyNjE5NDU0NVoXDTIxMDQyNjE5NDgy MlowKTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUEUgUm9vdCBDQS0xMIICIjANBgkqhkiG 9w0BAQEFAAOCAg8AMIICCgKCAgEAtp8hR0hRq3im+Alwfb5ZHGP5k2OSY2TlVHYHIMUDH3MfW7b6 8lB3j3MwAMsxGK1ke/t6O4K0t9wRH4QDgOQ1CthmOGZW7xiN81h0vP1Yf14SNugUa7ZvH9KP3iXs y8QnOHal1bKf0Pa9KXib58qUuwfaZSCTW5P2ekqd8z4TETvfBWvPgDxyxnVsiAO6yL9WaRpMiSVM hYLWy3KRuU/gue0bVEi+qdg+hENh1NSNXpoqseS262nq5cx5wybR/PF0YstQ9NNlYDM5cLECKYHH zD6cXKJozuFXriswlE8rdna7VaxyZrfgC0ueEIY/tsj/65IyUhyPBwO0ZpW+Ls9Cd4Y+ERSu5mR5 Fd8w42eVzuosmk3s3AxrKC+Z4tXYkjaiWUduIegAiST1vJBwkS53vR+zrBX3Ep56l7MFVvW/GcsZ 9wUT2HG65JOeiVc2YzCEqLgQ3ZCBHn09oBag2lnMac+E2sKm9aKL3xzHs6cyD8qCJK9O8QLCqo3C mzASlOwtTFiLYgpPW/MSmgYOt9JrwHAzk97DHFKTFttjrXGMmhMVzadt1EjMn1Wv8t5WLBI0qSoX /MYi2CaeiDsEiWRu9Nmpu3pmi8m7tIR9csdbAVPks2soNMWOopGEpFQSDvU1+m77v2jIKQKYxYmN 2zUOJ4TJFL1osnZ/71MmLCDVd+ECAwEAAaNRME8wCwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMB Af8wHQYDVR0OBBYEFFuHfZ/+bL4C6fPgKTqKVCUsnzgvMBAGCSsGAQQBgjcVAQQDAgEAMA0GCSqG SIb3DQEBCwUAA4ICAQAy78sXsP/eqHH8/uOYyxQ6TBDhkCBxNoy8MF2c9UDns5ADL1qyxPAlpDBs L+2h1Zzt3FvPjg0SoRE/9juyG1qxMzhlv0jdQx12tESdo3uBb61b1uuc4H/VxCJWDI4KZL/B53EI 8HGPjUBdLADgOmG99uffm5uarSkjtIX//Bz3U6QfzTPlVWFi4SmzRI2mp16GQ8RPuJ/WMloaAn8X H6EjS2oLjGZC8Pw8/C46W48NvZ1JZTrZvYZr7GmuvmplYK68SZv/T5Su+FlLRTy9uNXQLHtm6jKv nDH2yB66zTwfaDpnjILnrC2O7ANRVZc0KywiKiW3nB7Joq74/XVuMI1PiSByt2Qu+RIS/WAI5wMi bTmwSiBxQZqvuth+dXoakJyOP2Wg5jvL55v9RLZhDqMtRI5ovnOFvTgNJQqNPSekGtA+m6Ctl/vh kSg65FFCMhaSkn7vY2Il+R8HouWJN8wTaudeexnyHcD+Mlt8QaB5CErpDjeeGZfQ0FcYm+6TtlMz Dw5eFhT/J6QrABCxfgLkVFHurMcQD4JkmXXkq5bP+GNkY0Uy2LMbw/UD94OEV1LpfAqUkT+mu5Yb vxg+elFtsad+Ix8owW372xynIADh9q1bHm+j1OHPJmGALWK9miRpC4t3isfu3ZB0QpI/e2Po6MED 393Jb0YbzrcElFv6ZDCCBhYwggP+oAMCAQICChrDbcgAAgAAN/wwDQYJKoZIhvcNAQEFBQAwUDET MBEGCgmSJomT8ixkARkWA09SRzEVMBMGCgmSJomT8ixkARkWBU1JVFJFMSIwIAYDVQQDExlNSVRS RSBDb3Jwb3JhdGlvbiBQRSBDQS0xMB4XDTEyMDMxMjE1MTgyN1oXDTE1MDMxMjE1MTgyN1owSjEL MAkGA1UEBhMCVVMxDjAMBgNVBAoTBU1JVFJFMQ8wDQYDVQQLEwZQZW9wbGUxGjAYBgNVBAMTEUJh cm51bS5TZWFuLjMxNTQzMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA9/I6RU7OcouL 6lcEJMAg8G3myNbQu84QnflS8p3PWOjgC6P50RDqGX5UxelDqMQPN5IsNYRXVY9/b7yN/RSH4goI JfYKMitndKuCKz1q38Nh0YycEm5x2t/IN/60b01T1uOmhZfptLDoDzj0UQZwMQ19mhM/ldsrC8bR GGuHXdQVaSyXygfhzNhqC06vZo5fvCBUJ6z7JtVrfRTHdudg19JYK+gds9p+Lvp/DOEXQmgpfpMl jfNKMnrG+kPMMngrIJUsF5lcbhHuc5mO+O8eR8FxM2KF7gfKVmUmZxs7Y6uLenVJVEmllP0XgUu1 sv3bClFgUo5x5Aq6rXshtHuVuQIDAQABo4IB9jCCAfIwKAYDVR0lBCEwHwYIKwYBBQUHAwQGCSsG AQQBcwIBBwYIKwYBBQUHAwIwHQYDVR0OBBYEFDvU1Ph/OVxGkxRmwvRx1TBf5PKqMA4GA1UdDwEB /wQEAwIGwDAcBgNVHREEFTATgRFzYmFybnVtQG1pdHJlLm9yZzAfBgNVHSMEGDAWgBRpZyAh1EjB 0BsGbvMIKOI6gn1BMTBJBgNVHR8EQjBAMD6gPKA6hjhodHRwOi8vcGtpLm1pdHJlLm9yZy9NSVRS RSUyMENvcnBvcmF0aW9uJTIwUEUlMjBDQS0xLmNybDB/BggrBgEFBQcBAQRzMHEwRwYIKwYBBQUH MAKGO2h0dHA6Ly9wa2kubWl0cmUub3JnL01JVFJFJTIwQ29ycG9yYXRpb24lMjBQRSUyMENBLTEo MikuY3J0MCYGCCsGAQUFBzABhhpodHRwOi8vb2NzcC5taXRyZS5vcmcvb2NzcDA+BgkrBgEEAYI3 FQcEMTAvBicrBgEEAYI3FQiDrqwjho6WV4GNiT2CpKsShb6uAYE2g9KXfYeg+0kCAWQCAQcwFgYD VR0gBA8wDTALBgkrBgEEAXMCAQgwNAYJKwYBBAGCNxUKBCcwJTAKBggrBgEFBQcDBDALBgkrBgEE AXMCAQcwCgYIKwYBBQUHAwIwDQYJKoZIhvcNAQEFBQADggIBAC2wqKo7QWQxIqnEKRznPrAQ5vQ9 X5JhB5keH8KMWu1W5n1RuSZH+3TYp4xccdYh+rV5b5+cJcWEYhtYpZriWm4kMHPaB6gKO9rbVfF9 R8Wp8sXvCKogbNhdkZwvXW4QymB1ASlMzDI1cCV8mzYgbIhWaCbV1zZBUVgOGa4LZIgdbdmgo5r/ O2gmnSftTYiE/tQ+DBs/25Bw/jC5HOiMXJqr+JctzJTqpEVLa7GKHnXWGuzGEPYkKBplxIyhz3Mv qc/yuKM7tZzAr8Qn5qf7VI9O2xp56QLjT2+mySOUR6Vml860FMpjjgZNMxAqOJt7OgY0PoUU9d18 yw1wiKSt0LUQoMcVvp7FifBjtBCG1sB/VOzxNvcNm6lO6EO23pvcjt6+WCG1X3pgnZ5UEohsM3c0 oLzYiuSYeVf85IO2yh9fWLWw2RGkf2szck1Xg0DsAQ54/YlZYyehELh43KbS3lpnTt8UlO7C0TMT 7JQwz4fTQg1a0e9rRPFnNDUG2fS2k3tz9IYILDB3F8uiZzzXptEzaYqzIqe5CK8ZGJQcw+w/CBen 6i+MV/y7yJmhio43Y1x9hIqoynqoSMV3CKYCoOwCvFUAGsNllDpExsQZoXrdd5gcuglqbh3t8wOM jtXDSQllQ/hXDZJf8rnH0wGx3K+WA+LKNvKqNCw9spEtsfG0MIIGYjCCBEqgAwIBAgIKFJcW0gAA AAAABDANBgkqhkiG9w0BAQsFADApMScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQRSBSb290 IENBLTEwHhcNMTEwNjE0MTc0NDQ0WhcNMTcwNjE0MTc1NDQ0WjBQMRMwEQYKCZImiZPyLGQBGRYD T1JHMRUwEwYKCZImiZPyLGQBGRYFTUlUUkUxIjAgBgNVBAMTGU1JVFJFIENvcnBvcmF0aW9uIFBF IENBLTEwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDSxK9RXieqdTz4JWRkRMs/EOuF 0P0S9SbspadLJkx/LDDnaAwmAnqfqm1n7/p82oVjy1yCye3SZu4Yp7fmDIAtWbkHvYOfxHkRv1ho /fhaNN0YRkd65oJJz2ngEbNZxdIiCoialQfX/iWU7ApQ+ovKbFV60v5E0p2mPncs20NYRfsaetdh nBZbFD9flDcXwJqSvGGGBfm7ifFCR1LrtEcNKjMwf7YEWZO0Vk3ZyhVq+k7JNLEbKv0OfBz8DU8G iGU+j88QlrgGW8PLkwNk7nsS/DJp8aLudTuVqIE2CA9mqn5QjU/EZYNHGzSfCr+/usUmbojyVSJu khhrAXspRAMz+Cia3yi3q3w8TnAljXWN1dhx1iuUv5GxyzMjfqK1tMuCUU2XzGNNqoVa1mqolBiy DTCOr9d/IC0YHYMBSpQ+xi0x9zjXKt4FmQmkEAZgF4hsZZqcJYL/iCQiwiz8fEyVPZuvoWvdEXOo zFYCpmkT0MZCJwyIux0Z6vJp6VLtN/6rZgc2y54HlTrp3ifazmpsfrk3NdHxlZTZug9kjEI+vEoy p/79nAPyTWQQ1MEP0ErCWav80/HOi0MLx/7lIUfvVOjkOFgFb+iDvR4T3RAQrnEpgTO+fc7Jyzh9 LpFDqm0slwDP4Hj9cC3IzdED5BU43PGAe+HoZ8OD/1ovVgwo/wIDAQABo4IBYzCCAV8wEAYJKwYB BAGCNxUBBAMCAQIwIwYJKwYBBAGCNxUCBBYEFFCiOtgZb+Zdflkw5sC2y01sUQaVMB0GA1UdDgQW BBRpZyAh1EjB0BsGbvMIKOI6gn1BMTAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTALBgNVHQ8E BAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAfBgNVHSMEGDAWgBRbh32f/my+Aunz4Ck6ilQlLJ84LzBQ BgNVHR8ESTBHMEWgQ6BBhj9odHRwOi8vcGtpLm1pdHJlLm9yZy9NSVRSRSUyMENvcnBvcmF0aW9u JTIwUEUlMjBSb290JTIwQ0EtMS5jcmwwWwYIKwYBBQUHAQEETzBNMEsGCCsGAQUFBzAChj9odHRw Oi8vcGtpLm1pdHJlLm9yZy9NSVRSRSUyMENvcnBvcmF0aW9uJTIwUEUlMjBSb290JTIwQ0EtMS5j cnQwDQYJKoZIhvcNAQELBQADggIBAHnDPfdYKxqNOtAYXMyyel83Vs8cCDAQZhSuIB0c6GkGoEdF rmWH9pwi42V96rCp7TvbNNKNJXbVHfJUAp+uqw663DL/sXXff9ZFxPxKOdPnpA8cKM7RBH9e437N w3d28A7PaGbP6tXmSqhXAhYZ4U12y1U5cOf2G/phUoAAMlnVJdfmXzMazvLo2SIeixAJyCze6rHQ TFQ/N+gAjbVuRJ+Hs8FEKVzMSwqlNoupe2ELqL4dMAKT6P08sAfxm2SrRlQvcWPYvqM/1C10bgc2 tdu+WGzRuP5Wx9Yr15KO9SW4z7fn2RVEXQgoDDno5vCIcfUPuKB5n+Kt9eBCitsgSD9yYsNUN9LE VIvjAb8MV2LWLfge1bumo6g7QMRa4Fgifw5siGwi7V2EaJQo6UAIVvxKKFC7W4p6CkrY2ga1d7GI Q0DPiWZOezOakJVAxL5gf+3WdNt0igKc/yLfbdHn6hCd1KPgDqkSKr8zWOZI/jiDBW957xAmaO6Q dGQDBZrQHWpIVwQGzF5bGrqms2kq49l3t7KmBu0C/9tExqKAmlf4Y5lfQGdCbKQpAq712DVQHYuD XmVQEAc2vlJ1C5hS3Iw9DwBWTfJ4vyB48buhBhbIhPiFta5OizXlKcsIi99ikA1yiZx/DBtjaw4J U6qJzWUFB2ecyGCNPtNbYjURA0A9MIIGfzCCBGegAwIBAgIKGsNq2wACAAA3+jANBgkqhkiG9w0B AQUFADBQMRMwEQYKCZImiZPyLGQBGRYDT1JHMRUwEwYKCZImiZPyLGQBGRYFTUlUUkUxIjAgBgNV BAMTGU1JVFJFIENvcnBvcmF0aW9uIFBFIENBLTEwHhcNMTIwMzEyMTUxODI3WhcNMTUwMzEyMTUx ODI3WjBKMQswCQYDVQQGEwJVUzEOMAwGA1UEChMFTUlUUkUxDzANBgNVBAsTBlBlb3BsZTEaMBgG A1UEAxMRQmFybnVtLlNlYW4uMzE1NDMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCW InZvCSslmSfSyhTVVSqnokCDajlsCNZHfUlkwkV1++2O71BYvMpjFHWR2XFIx963Hl63lFZzzVci OjIwLb1c/0YXhFfUdAvrbpjlu+ttlO05OEUW0h+5HO+qaebJPamxA00w0bokquRcPxUvwa3jiyL0 WfCwE3+/b5PCOW2xh7FXFKv262FnKIwxnQGXqkiXRP5D/SmdtcZSzxHkDThrhaiHPhJJhZ4XxwBk aGcAlMg8YH6uxshXm8e6c7XUu7gB5p+XThS0dqXujpQp/UQDp5t079+UrDcrpjfDBXIt9qCzLn26 uV5a4cD4xRKwA32f1cXFtiKXM0wYgUM3fEPDAgMBAAGjggJfMIICWzATBgNVHSUEDDAKBggrBgEF BQcDBDCBlAYJKoZIhvcNAQkPBIGGMIGDMA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DBAICAIAw BwYFKw4DAgcwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBLTALBglghkgBZQME ARYwCwYJYIZIAWUDBAEZMAsGCWCGSAFlAwQBAjALBglghkgBZQMEAQUwHQYDVR0OBBYEFIrbKa+E Rxo2/Sth2C6jZqZqvRE7MA4GA1UdDwEB/wQEAwIFIDAcBgNVHREEFTATgRFzYmFybnVtQG1pdHJl Lm9yZzAfBgNVHSMEGDAWgBRpZyAh1EjB0BsGbvMIKOI6gn1BMTBJBgNVHR8EQjBAMD6gPKA6hjho dHRwOi8vcGtpLm1pdHJlLm9yZy9NSVRSRSUyMENvcnBvcmF0aW9uJTIwUEUlMjBDQS0xLmNybDB/ BggrBgEFBQcBAQRzMHEwRwYIKwYBBQUHMAKGO2h0dHA6Ly9wa2kubWl0cmUub3JnL01JVFJFJTIw Q29ycG9yYXRpb24lMjBQRSUyMENBLTEoMikuY3J0MCYGCCsGAQUFBzABhhpodHRwOi8vb2NzcC5t aXRyZS5vcmcvb2NzcDA+BgkrBgEEAYI3FQcEMTAvBicrBgEEAYI3FQiDrqwjho6WV4GNiT2CpKsS hb6uAYE2hquSaISo7EUCAWQCAQ8wFgYDVR0gBA8wDTALBgkrBgEEAXMCAQgwGwYJKwYBBAGCNxUK BA4wDDAKBggrBgEFBQcDBDANBgkqhkiG9w0BAQUFAAOCAgEAGmmL43yA+J5lEockM1cxSoyxfSES HUGLVJyrhObbdFD4yO3jf0R4lHLuJlhp1486d9LRZAyzAnl9q8Zf3Tx1rl1kEd3pw0wMuO+ATscc rArEW/rJxjz6zTrNO3PFkFuOEdmKpHaRiFpuSX602INiBEBPluei3uZlWxHW9VqC7hz2diQpOlzS jtPMbL3o7ACjWaq7sQ0xB4rZ6oWyqOZEfHWQA1b7nFgL4nEbmEHNdU4jAjcxkROku4O04205kb5n Loveoz3TSQNt8zalFayZAjt+JEcKuG1f5cyhYI6QwvkS/3M+CjJezuNaSmno29Lm+ToZnwUm4nIB YkBx4r9ZDU2W8029tr5og00A5MGo1LK+unWtHBa7zuPblfSiYgXIHWU+OKrSFaA935Yb4fLXFe9S BmApBr1gohHYos1hct5q90WPufSKIQ9WT+vJYXvW3FpseO4ZLKVnJsO7gVoQEEnWJUwyABBPQrii F0gh++ApKZJROTuR36PsEEx4duI6U4VXMCiIcnEjvNR8Mt5Q/Vp4W4Mp5fCv+QzYkqq9EWD7QuUW Yul6R8Hf7ZTxbUk0NfJgu8escLrgQSwMdP/kE/09vJAAslQBkNnIS7iIhWt4l5XQJBrJc+6popRE R8ykWf25e4CliaUgbAl1tBQKivQ3tlX99WykI2XK3sTk9nsxggMjMIIDHwIBATBeMFAxEzARBgoJ kiaJk/IsZAEZFgNPUkcxFTATBgoJkiaJk/IsZAEZFgVNSVRSRTEiMCAGA1UEAxMZTUlUUkUgQ29y cG9yYXRpb24gUEUgQ0EtMQIKGsNtyAACAAA3/DAJBgUrDgMCGgUAoIIBmjAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjA0MTcwNTA5MjlaMCMGCSqGSIb3DQEJBDEW BBREg80x8Kq4xX6tAXXPcXA3qysGCjBbBgkqhkiG9w0BCQ8xTjBMMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMC GjBtBgkrBgEEAYI3EAQxYDBeMFAxEzARBgoJkiaJk/IsZAEZFgNPUkcxFTATBgoJkiaJk/IsZAEZ FgVNSVRSRTEiMCAGA1UEAxMZTUlUUkUgQ29ycG9yYXRpb24gUEUgQ0EtMQIKGsNq2wACAAA3+jBv BgsqhkiG9w0BCRACCzFgoF4wUDETMBEGCgmSJomT8ixkARkWA09SRzEVMBMGCgmSJomT8ixkARkW BU1JVFJFMSIwIAYDVQQDExlNSVRSRSBDb3Jwb3JhdGlvbiBQRSBDQS0xAgoaw2rbAAIAADf6MA0G CSqGSIb3DQEBAQUABIIBANSPnLRCB76drdbzpsfRkzWha2MfStbrkWgCRFbDym4CjVePieriBPiG 1yUBPnwSLsJtViEcZJiUIk+uBGp82c9oJk7z2Jl9wfUhmKoeOIldSS2su5zUvxV+OwN7TFEwGlCd 5rE5gHad6SWC0Jglkrm2JggVVNcH/upYE/h4JTw/IqATqndCYPPgrr0d0eWphLH8ZeVOvc8tvLMr 09bNroKp5D5U11ZJPm0YqoYZaVWi0Be2LvAalb0z37rpC4KVFATKOS3YHXaYypKXbF/DrhWuLB6P G3P4pPGkL1stheCIdaUnly9Jg6uMK0GtJzk1PiRKk9VOPuuZBpkxehTQ5BAAAAAAAAA= ------=_NextPart_000_0066_01CD1C36.BDA3E920-- From osantos@cisco.com Mon Apr 16 17:17:25 2012 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 03A1411E807F; Mon, 16 Apr 2012 17:17:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PjgnrFtHmExG; Mon, 16 Apr 2012 17:17:20 -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 2506821F84A2; Mon, 16 Apr 2012 17:17:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=osantos@cisco.com; l=41127; q=dns/txt; s=iport; t=1334621840; x=1335831440; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=ypZ6lme6HmCN6JHwsR+BqGNRaeoiVOhJKgFPBN+LceA=; b=bGuD8JNBLgVhii5+ixwbOUGgp+JIyjAZQLoAzr1slfQ/+gqx7/Jq0zck lsMeRyjOPm6rkBTTG/VehzXI6CcUM7hXHqin5/KJy2cjXhUVvOvuXPW7I YfXDpwUb5OuCFy3vz1oFukQWaKsayvGIz9tTWGO0sP/5oIOqWdwiqew1/ 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFALO1jE+tJV2a/2dsb2JhbABBA4JGpzEBiQqBB4IJAQEBBAEBAQ8BCQsGAyUZCw4CAgEIDgMEAQELBhABBgEGARoGBh8JCAEBBBMIGodeAwsLmVSWGg2JUwSKM4NpgkZjBIhajiSKIQaDFIFpgwWBPg X-IronPort-AV: E=Sophos;i="4.75,432,1330905600"; d="scan'208,217";a="75211974" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP; 17 Apr 2012 00:17:19 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q3H0HJY1018618; Tue, 17 Apr 2012 00:17:19 GMT Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 16 Apr 2012 19:17:19 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD1C2F.7366A01F" Date: Mon, 16 Apr 2012 19:17:15 -0500 Message-ID: <953A2E460DBE7C43AC13E30B87C5B4FF080A1BAD@XMB-RCD-106.cisco.com> In-Reply-To: <870A23D4-BA94-4431-B613-F3D7734B8DB5@c3isecurity.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe website Thread-Index: Ac0cIoKxjmCQPFiRSeqrlJRFEHgaVQADFK2A References: <7F48813B48558A4BB5CB7BB714E5B5A91706E3@IMCMBX03.MITRE.ORG> <870A23D4-BA94-4431-B613-F3D7734B8DB5@c3isecurity.com> From: "Omar Santos (osantos)" To: "Luis Nunez" , "Barnum, Sean D." X-OriginalArrivalTime: 17 Apr 2012 00:17:19.0412 (UTC) FILETIME=[73B86F40:01CD1C2F] X-Mailman-Approved-At: Mon, 16 Apr 2012 23:14:37 -0700 Cc: idxwg@nicwg.org, mile@ietf.org, dallendoug@gmail.com, sacm@ietf.org, m-terada@ipa.go.jp Subject: Re: [mile] [sacm] CybOX v1.0 (Draft) is now released and live onthe website 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, 17 Apr 2012 00:17:25 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD1C2F.7366A01F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I echo Luis' comments. It is good to see the inclusion of network objects. Quick question to the team related to your netflow comment. =20 I am looking at: http://cybox.mitre.org/XMLSchema/cybox_core_v1.0%28draft%29.xsd =20 ... and it looks that we renamed it to "Data Flow"? =20 Specifies the class of events dealing with data flow. =20 =20 What is the difference between that and "Packet Traffic"? =20 Specifies the class of events dealing with packet traffic. =20 =20 =20 =20 Regards, Omar Santos Incident Manager, PSIRT Security Research and Operations Cisco Systems, Inc. Email: os@cisco.com Phone: +1 919 392 8635 PGP Key: 0x3AF27EDC Cisco.com - http://www.cisco.com Cisco Security Advisories and Notices - http://www.cisco.com/go/psirt This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message. For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html =20 From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Luis Nunez Sent: Monday, April 16, 2012 6:44 PM To: Barnum, Sean D. Cc: idxwg@nicwg.org; mile@ietf.org; Doug Wilson (dallendoug@gmail.com); sacm@ietf.org; IPA-Masato Terada (m-terada@ipa.go.jp) Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe website =20 I like the inclusion of the network-centric objects. IPFIX (netflow) will add an additional perspective from an incident information sharing standpoint. =20 =20 -ln =20 On Apr 16, 2012, at 4:04 PM, Barnum, Sean D. wrote: Hey everyone, =20 I just wanted to let you all know that CybOX v1.0 (Draft) content is now live on the website. http://cybox.mitre.org The release notes are provided inline below. The key items of note are: * The release of two formal specifications for the CybOX language (one for the core language and one for the defined objects) * The XML Schema has gone through extensive improvements for expressiveness, clarity, consistency, efficiency, alignment to existing normative references and documentation. * This release includes an initial set of language utilities: a draft Snort -> CybOX transform, a draft OpenIOC -> CybOX transform, and a set of Python bindings for the CybOX language. * The website now includes a small set of content examples. This set will grow going forward. This release involved a lot of hard work from a diverse group of people. Thank you all for your contributions and effort. We could not have done it without you. We look forward to everyone's feedback and collaboration as we continue to improve and mature the CybOX language. =20 Sean Barnum =20 =20 =20 CybOX v1.0 (Draft) Release Notes The Version 1.0 (Draft) release of Cyber Observable eXpression (CybOX(tm)) is intended as a draft release of an initial major version of the CybOX Language that could be utilized for practical operational use and integration into other standards efforts. This release consists of three primary components: a pair of formal language specifications for the core language content and defined objects content, a set of language implementation XML schemas (core, common_types, and ~70 defined object schemas), and a small initial set of language utilities including an initial draft Snort->CybOX transform, an initial draft OpenIOC->CybOX transform and a set of CybOX language Python bindings. Recognizing that this is the first time that the formal language specifications will be available for review and as such will likely generate feedback from new stakeholders, this initial major version is being released as a "draft" v1.0 with the expectation of cycles of new feedback and revision before a "final" v1.0 is released. The CybOX v1.0 (Draft) XML schemas include a significant number of changes from v0.7 to improve: * Clarity, documentation, and descriptive formality for reference and implementation by other standards and users. * Consistency, simplicity, and efficiency. * Alignment (as appropriate) to existing normative references. * Expressiveness of the schema to better support the broad set of use cases it targets (malware characterization, indicator and incident data sharing, event management, etc.) including the addition of an initial set of network-related defined objects. Summary of changes from CybOX_v0.7 to CybOX_v1.0_(Draft): * Refinement of namespaces and schema locations for better effectiveness and flexibility going forward. * Normalized all content according to an established set of naming conventions. * Fully annotated all language items (types, attributes, elements, etc.). * Moved several commonly leveraged types out of the core schema and into common_types. * Achieved full typing of entire schema structure such that all attributes and elements are definitively typed. * Changed all identifiers from ID and IDREF types to be QNames enabling globally unique identifiers and flexibility for domain-specific users of CybOX to define their own identifier syntax locally. * Reordered attributes and elements in numerous types to better reflect common usage and priority. * Added major_version and minor_version attributes for core schema. * Added capability to characterize source of overall observable package data and for individual observables. * Modified the logical composition structure such that any such compositions are now contained within a Observable_Composition element providing improved simplicity and modularity. * Removed the Delta element from ObservableType and relocated the appropriate portions (Change, Trend, and Frequency) to appropriate locations under Stateful_Measure and Event. * Added a Domain_Specific_Object_Attributes field to Object utilizing an abstract type that will allow domain-specific use cases to add in their own domain-specific attributes for Objects. * Added a Tool-Specific_Data field to ToolInformationType utilizing an abstract type that will allow addition of tool-specific data. * Added an Indicators field to MeasureSourceType utilizing an abstract type that will allow characterizing differing formats or standards of indicators that may have led to the identification of the observable data. * Enhanced the Hash structure to capture full fuzzy hashes in addition to simple hashes * Added a new ExtractedFeaturesType that can be used to adorn differing objects (e.g., files, memory, etc.) to capture extracted strings, imports, functions and code snippets * Added a ByteRunsType to enable capture of byte runs within various objects. * Added object_reference attribute to DefinedObjectType to better support referencing of independently defined Objects from within another Object definition. * Added a generic DataSegmentType to provide a relatively abstract way of characterizing data segments that may be written/read/transmitted or otherwise utilized in actions or defined in objects. * Added several new defined object schemas (API, Code, Device, DNS_Record, Network_Flow, Network_Packet, Network_Route_Entry, Network_Subnet, Unix_Network_Route_Entry) including an initial set of network-centric defined objects. * Modified every defined object schema with added annotations as well as minor and in some cases substantive changes to fix errors, improve consistency and alignment with existing normative references, and to improve expressiveness in support of the targeted use cases. Detailed changes from CybOX_v0.7 to CybOX_v1.0_(Draft): The level of changes within v1.0 (Draft) in the core schema, common_types and the defined object schemas is too great to list every change in these release notes. Detailed difference reports are available for each individual schema at:http://cybox.mitre.org/XMLSchema/release_notes/cybox_v1.0(draft)_diff _reports.zip =20 =20 =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Sean Barnum Cyber Security Principal The MITRE Corporation Email: sbarnum@mitre.org =20 _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile =20 ------_=_NextPart_001_01CD1C2F.7366A01F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I echo Luis’ comments. It is good to see the inclusion of = network objects. Quick question to the team related to your netflow = comment.

 

I am looking at:

= http://cybox.mitre.org/XMLSchema/cybox_core_v1.0%28draft%29.xsd<= /o:p>

 

… and it looks that we renamed it to “Data = Flow”?

 

<xs:enumeration = value=3D"Data Flow">

   <xs:annotation>

        = <xs:documentation>Specifies the class of events dealing with data = flow.</xs:documentation>

   </xs:annotation>

</xs:enumeration>

 

 

What is the difference between that and “Packet = Traffic”?

 

<xs:enumeration =
value=3D"Packet Traffic">
   =
<xs:annotation>
     =
<xs:documentation>Specifies the class of events dealing with =
packet =
traffic.</xs:documentation>
   =
</xs:annotation>
</xs:enumeration><=
/o:p>

 

 

 

 

Regards,

Omar Santos
Incident Manager, = PSIRT
Security Research and Operations
Cisco Systems, = Inc.
Email: os@cisco.com
Phone: +1 919 392 8635
PGP Key: = 0x3AF27EDC

Cisco.com - http://www.cisco.com
Cisco Security = Advisories and Notices - http://www.cisco.com/go/psirt

This email = may contain confidential and privileged material for the sole
use of = the intended recipient. Any review, use, distribution or
disclosure = by others is strictly prohibited. If you are not the = intended
recipient (or authorized to receive for the recipient), = please contact
the sender by reply email and delete all copies of = this message.

For corporate legal information go = to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html=

 

From:= = sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of = Luis Nunez
Sent: Monday, April 16, 2012 6:44 = PM
To: Barnum, Sean D.
Cc: idxwg@nicwg.org; = mile@ietf.org; Doug Wilson (dallendoug@gmail.com); sacm@ietf.org; = IPA-Masato Terada (m-terada@ipa.go.jp)
Subject: Re: [sacm] = [mile] CybOX v1.0 (Draft) is now released and live onthe = website

 

I like the = inclusion of the network-centric objects.  IPFIX (netflow) =  will add an additional perspective from an incident information = sharing standpoint.  

 

-ln

 

On = Apr 16, 2012, at 4:04 PM, Barnum, Sean D. wrote:



Hey = everyone,

 =

I just = wanted to let you all know that CybOX v1.0 (Draft) content is now live = on the website. http://cybox.mitre.org

The = release notes are provided inline = below.

The key = items of note are:

·        The = release of two formal specifications for the CybOX language (one for the = core language and one for the defined = objects)

·        The XML = Schema has gone through extensive improvements for expressiveness, = clarity, consistency, efficiency, alignment to existing normative = references and documentation.

·        This = release includes an initial set of language utilities: a draft Snort = -> CybOX transform, a draft OpenIOC -> CybOX transform, and a set = of Python bindings for the CybOX language.

·        The = website now includes a small set of content examples. This set will grow = going forward.

This = release involved a lot of hard work from a diverse group of people. = Thank you all for your contributions and effort. We could not have done = it without you.

We look = forward to everyone’s feedback and collaboration as we continue to = improve and mature the CybOX = language.

 =

Sean = Barnum

 =

 =

 =

CybOX v1.0 (Draft) Release = Notes

The Version = 1.0 (Draft) release of Cyber Observable eXpression (CybOX™) is intended as a draft release of an initial major version of = the CybOX Language that could be utilized for practical operational use = and integration into other standards efforts. This release consists of = three primary components: a pair of formal language specifications for = the core language content and defined objects content, a set of language = implementation XML schemas (core, common_types, and ~70 defined object = schemas), and a small initial set of language utilities including an = initial draft Snort->CybOX transform, an initial draft = OpenIOC->CybOX transform and a set of CybOX language Python bindings. = Recognizing that this is the first time that the formal language = specifications will be available for review and as such will likely = generate feedback from new stakeholders, this initial major version is = being released as a “draft” v1.0 with the expectation of = cycles of new feedback and revision before a “final” v1.0 is = released.=

The CybOX v1.0 (Draft) XML = schemas include a significant number of changes from v0.7 to = improve:=

·       Clarity, = documentation, and descriptive formality for reference and = implementation by other standards and users.=

·       Consistency, = simplicity, and efficiency.=

·       Alignment (as = appropriate) to existing normative references.=

·       Expressiveness of the = schema to better support the broad set of use cases it targets (malware = characterization, indicator and incident data sharing, event management, = etc.) including the addition of an initial set of network-related = defined objects.=

Summary of changes from CybOX_v0.7 = to CybOX_v1.0_(Draft):=

  • Refinement of = namespaces and schema locations for better effectiveness and flexibility = going forward.=
  • Normalized all content according to an established set of naming = conventions.=
  • Fully annotated all language items (types, attributes, elements, = etc.).=
  • Moved several commonly leveraged types out of the core schema and = into common_types.=
  • Achieved full typing of entire schema structure such that all = attributes and elements are definitively typed.=
  • Changed all identifiers from ID and IDREF types to be QNames = enabling globally unique identifiers and flexibility for domain-specific = users of CybOX to define their own identifier syntax locally.=
  • Reordered attributes and elements in numerous types to better = reflect common usage and priority.=
  • Added major_version and minor_version attributes for core = schema.=
  • Added capability to characterize source of overall observable = package data and for individual observables.=
  • Modified the logical composition structure such that any such = compositions are now contained within a Observable_Composition element = providing improved simplicity and modularity.=
  • Removed the Delta element from ObservableType and relocated the = appropriate portions (Change, Trend, and Frequency) to appropriate = locations under Stateful_Measure and Event.=
  • Added a Domain_Specific_Object_Attributes field to Object = utilizing an abstract type that will allow domain-specific use cases to = add in their own domain-specific attributes for Objects.=
  • Added a Tool-Specific_Data field to ToolInformationType utilizing = an abstract type that will allow addition of tool-specific data.=
  • Added an Indicators field to MeasureSourceType utilizing an = abstract type that will allow characterizing differing formats or = standards of indicators that may have led to the identification of the = observable data.=
  • Enhanced the Hash structure to capture full fuzzy hashes in = addition to simple hashes=
  • Added a new ExtractedFeaturesType that can be used to adorn = differing objects (e.g., files, memory, etc.) to capture extracted = strings, imports, functions and code snippets=
  • Added a ByteRunsType to enable capture of byte runs within various = objects.=
  • Added object_reference attribute to DefinedObjectType to better = support referencing of independently defined Objects from within another = Object definition.=
  • Added a generic DataSegmentType to provide a relatively abstract = way of characterizing data segments that may be written/read/transmitted = or otherwise utilized in actions or defined in objects.=

·        Added several new = defined object schemas (API, Code, Device, DNS_Record, Network_Flow, = Network_Packet, Network_Route_Entry, Network_Subnet, = Unix_Network_Route_Entry) including an initial set of network-centric = defined objects.

  • Modified every defined object schema = with added annotations as well as minor and in some cases substantive = changes to fix errors, improve consistency and alignment with existing = normative references, and to improve expressiveness in support of the = targeted use cases.=

Detailed changes from CybOX_v0.7 to = CybOX_v1.0_(Draft):=

The level of changes within = v1.0 (Draft) in the core schema, common_types and the defined object = schemas is too great to list every change in these release notes. = Detailed difference reports are available for each individual schema = at:http://cybox.mitre.org/XMLSchema/release_notes/cybox_v1.0= (draft)_diff_reports.zip

 =

 =

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

Sean Barnum=

Cyber Security Principal=

The MITRE Corporation=

 =

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

 

------_=_NextPart_001_01CD1C2F.7366A01F-- From Thomas.Millar@hq.dhs.gov Mon Apr 16 20:46:37 2012 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 CBC1B11E808E; Mon, 16 Apr 2012 20:46:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.098 X-Spam-Level: X-Spam-Status: No, score=-6.098 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BAD_LINEBREAK=0.5, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5S06UEq75xbz; Mon, 16 Apr 2012 20:46:31 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe003.messaging.microsoft.com [65.55.88.13]) by ietfa.amsl.com (Postfix) with ESMTP id 220C611E8081; Mon, 16 Apr 2012 20:46:30 -0700 (PDT) Received: from mail132-tx2-R.bigfish.com (10.9.14.239) by TX2EHSOBE005.bigfish.com (10.9.40.25) with Microsoft SMTP Server id 14.1.225.23; Tue, 17 Apr 2012 03:46:30 +0000 Received: from mail132-tx2 (localhost [127.0.0.1]) by mail132-tx2-R.bigfish.com (Postfix) with ESMTP id 202974C0253; Tue, 17 Apr 2012 03:46:30 +0000 (UTC) X-SpamScore: -36 X-BigFish: VPS-36(zz9371Ic89bh1431Je2eM14ffIc857h98dK62a3Izz1202hzzd0f34h1033IL8275bhf14K8275dhz2dh2a8h668h839hd25h) X-Forefront-Antispam-Report: CIP:216.81.89.167; KIP:(null); UIP:(null); IPV:NLI; H:D1IBLPRHQ102.dhs.gov; RD:none; EFVD:NLI Received: from mail132-tx2 (localhost.localdomain [127.0.0.1]) by mail132-tx2 (MessageSwitch) id 1334634385982389_7472; Tue, 17 Apr 2012 03:46:25 +0000 (UTC) Received: from TX2EHSMHS043.bigfish.com (unknown [10.9.14.245]) by mail132-tx2.bigfish.com (Postfix) with ESMTP id E759230005F; Tue, 17 Apr 2012 03:46:25 +0000 (UTC) Received: from D1IBLPRHQ102.dhs.gov (216.81.89.167) by TX2EHSMHS043.bigfish.com (10.9.99.143) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 17 Apr 2012 03:46:25 +0000 Received: from D1IBLPRHQ107.dhs.gov (192.168.49.137) by D1IBLPRHQ102.dhs.gov (10.84.128.101) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 16 Apr 2012 23:48:07 -0400 Received: from D1ABLPRHQ101.DSA.DHS (10.16.146.31) by D1IBLPRHQ107.dhs.gov (10.84.132.102) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 16 Apr 2012 23:50:44 -0400 Received: from ZAS1UG-0360.DHSNET.DS1.DHS (10.79.65.245) by D1ABLPRHQ101.DSA.DHS (10.16.146.31) with Microsoft SMTP Server id 14.1.355.2; Mon, 16 Apr 2012 23:46:22 -0400 Received: from ZAU1UG-0308.DHSNET.DS1.DHS ([10.79.65.209]) by ZAS1UG-0360.DHSNET.DS1.DHS with Microsoft SMTPSVC(6.0.3790.4675); Mon, 16 Apr 2012 23:46:19 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD1C4C.A5E487EB" Date: Mon, 16 Apr 2012 23:46:18 -0400 Message-ID: <69CE2DCD9DAC3D48B830E0723141170B02A39BD2@ZAU1UG-0308.DHSNET.DS1.DHS> In-Reply-To: <7F48813B48558A4BB5CB7BB714E5B5A9171B16@IMCMBX03.MITRE.ORG> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe website Thread-Index: AQHNHC91EoahZz2AEEqd+yKyGmroMJaeWIaQgAAIZb8= From: "Millar, Thomas" To: , , X-OriginalArrivalTime: 17 Apr 2012 03:46:19.0393 (UTC) FILETIME=[A621AF10:01CD1C4C] X-OriginatorOrg: hq.dhs.gov X-Mailman-Approved-At: Mon, 16 Apr 2012 23:14:37 -0700 Cc: idxwg@nicwg.org, mile@ietf.org, dallendoug@gmail.com, sacm@ietf.org, m-terada@ipa.go.jp Subject: Re: [mile] [sacm] CybOX v1.0 (Draft) is now released and live onthe website 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, 17 Apr 2012 03:53:38 -0000 ------_=_NextPart_001_01CD1C4C.A5E487EB Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SWYgImRhdGEgZmxvdyIgaXMgYSBldXBoZW1pc20gZm9yICJuZXRmbG93IiBpcyB0aGVyZSBhbnkg cmVhc29uIG5vdCB0byBjYWxsIGl0IHRoYXQ/DQoNClRvbSBNaWxsYXIgDQpodHRwOi8vd3d3LnVz LWNlcnQuZ292LyANCi0tLS0tLS0tLS0tLS0tLS0tLSANCk1pc3NpdCBtZSBSdWJ1cyBmcnV0aWNv c3VzOiANCjIwMiA2MzEgMTkxNSANCg0KIA0KDQpGcm9tOiBCYXJudW0sIFNlYW4gRC4gW21haWx0 bzpzYmFybnVtQG1pdHJlLm9yZ10gDQpTZW50OiBNb25kYXksIEFwcmlsIDE2LCAyMDEyIDExOjI5 IFBNDQpUbzogT21hciBTYW50b3MgKG9zYW50b3MpIDxvc2FudG9zQGNpc2NvLmNvbT47IEx1aXMg TnVuZXogPGxudW5lekBjM2lzZWN1cml0eS5jb20+IA0KQ2M6IGlkeHdnQG5pY3dnLm9yZyA8aWR4 d2dAbmljd2cub3JnPjsgbWlsZUBpZXRmLm9yZyA8bWlsZUBpZXRmLm9yZz47IGRhbGxlbmRvdWdA Z21haWwuY29tIDxkYWxsZW5kb3VnQGdtYWlsLmNvbT47IHNhY21AaWV0Zi5vcmcgPHNhY21AaWV0 Zi5vcmc+OyBtLXRlcmFkYUBpcGEuZ28uanAgPG0tdGVyYWRhQGlwYS5nby5qcD4gDQpTdWJqZWN0 OiBSZTogW3NhY21dIFttaWxlXSBDeWJPWCB2MS4wIChEcmFmdCkgaXMgbm93IHJlbGVhc2VkIGFu ZCBsaXZlIG9udGhlIHdlYnNpdGUgDQogDQoNCg0KVGhhbmtzIE9tYXIuDQoNCiANCg0KVG8gYW5z d2VyIHlvdXIgcXVlc3Rpb24sIGZpcnN0IGxldCBtZSBwb2ludCBvdXQgdG8gb3RoZXIgcmVhZGVy cyB0aGF0IHRoZSB0d28gZW50cmllcyB0aGF0IE9tYXIgaXMgcXVvdGluZyBoZXJlIGV4aXN0IGFz IHZhbHVlcyBpbiBhbiBlbnVtZXJhdGlvbiBjYWxsZWQgRXZlbnRUeXBlRW51bSB3aGljaCBhcyBp dHMgbmFtZSBpbXBsaWVzIGNvbnRhaW5zIGEgbGlzdCBvZiBkaWZmZXJlbnQgbGFiZWxzIGZvciBn cm91cGluZyB0eXBlcyAob3IgY2xhc3Nlcykgb2YgZXZlbnRzIHRvIGJlIHVzZWQgYXMgbG93LWdy YW51bGFyaXR5IGJ1Y2tldHMgZm9yIGNoYXJhY3Rlcml6aW5nIGFuZCBjbGFzc2lmeWluZyBldmVu dHMuDQoNCk90aGVyIGVudHJpZXMgaW4gdGhpcyBlbnVtZXJhdGlvbiBpbmNsdWRlIHRoaW5ncyBs aWtlIOKAnEZpbGUgT3BzIChDUlVEKeKAnSwg4oCcUHJvY2VzcyBNZ3TigJ0sIOKAnEF1dGhvcml6 YXRpb24gKEFDTCnigJ0sIGV0Yy4NCg0KIA0KDQpUaGUg4oCcUGFja2V0IFRyYWZmaWPigJ0gdmFs dWUgaXMgaW50ZW5kZWQgdG8gY2hhcmFjdGVyaXplIGV2ZW50cyBkZWFsaW5nIHdpdGggbmV0d29y ayBwYWNrZXQgdHJhZmZpYyBhcyBpdHMgbmFtZSBpbXBsaWVzLg0KDQpUaGUg4oCcRGF0YSBGbG93 4oCdIHZhbHVlIGlzIGludGVuZGVkIHRvIGNoYXJhY3Rlcml6ZSBldmVudHMgZGVhbGluZyB3aXRo IGZvcm1zIG9mIGRhdGEgZmxvdyBhdCBhIGhpZ2hlciBsZXZlbCBvZiBhYnN0cmFjdGlvbiB0aGFu IGp1c3QgcGFja2V0IHRyYWZmaWMuIFRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiB0aGVzZSB0d28g dmFsdWVzIGNvdWxkIGJlIHZpZXdlZCBhcyDigJxQYWNrZXQgVHJhZmZpY+KAnSBiZWluZyBhIG1v cmUgZGV0YWlsZWQgZm9ybSBvZiDigJxEYXRhIEZsb3figJ0ganVzdCBhcyB0aGUgdmFsdWVzIOKA nEFwcCBMYXllciBUcmFmZmlj4oCdIGFuZCDigJxIVFRQIExheWVyIFRyYWZmaWPigJ0sIGFsc28g aW4gdGhpcyBlbnVtZXJhdGlvbiwgY291bGQgYmUgb3RoZXIgbGV2ZWxzIGluIHRoaXMgc2FtZSBh YnN0cmFjdGlvbiBzdGFjay4NCg0KVGhlIGlkZWEgYmVoaW5kIHRoZSB2YXJ5aW5nIGxldmVscyBv ZiBhYnN0cmFjdGlvbiBpcyB0byBsZWF2ZSAgYnVja2V0cyBsYXJnZSBlbm91Z2ggdG8gY2FwdHVy ZSBhIHdpZGUgdmFyaWV0eSBvZiBwb3RlbnRpYWwgZXZlbnQgdHlwZXMgKGUuZy4gZGF0YSBmbG93 IGV2ZW50cyBvdGhlciB0aGFuIG9idmlvdXMgdGhpbmdzIGxpa2UgcGFja2V0IHRyYWZmaWMpIGJ1 dCBhbHNvIGVuYWJsZSB0aGUgdXNlIG9mIHNtYWxsZXIgbW9yZSBzcGVjaWZpYyBidWNrZXRzIHdo ZW4gdGhleSBhcmUgYXBwcm9wcmlhdGUgYW5kIGNvbW1vbmx5IHVzZWQuDQoNCiANCg0KRG9lcyB0 aGlzIG1ha2Ugc2Vuc2U/IA0KDQogDQoNCnNlYW4NCg0KIA0KDQpGcm9tOiBPbWFyIFNhbnRvcyAo b3NhbnRvcykgW21haWx0bzpvc2FudG9zQGNpc2NvLmNvbV0gDQpTZW50OiBNb25kYXksIEFwcmls IDE2LCAyMDEyIDg6MTcgUE0NClRvOiBMdWlzIE51bmV6OyBCYXJudW0sIFNlYW4gRC4NCkNjOiBp ZHh3Z0BuaWN3Zy5vcmc7IG1pbGVAaWV0Zi5vcmc7IGRhbGxlbmRvdWdAZ21haWwuY29tOyBzYWNt QGlldGYub3JnOyBtLXRlcmFkYUBpcGEuZ28uanANClN1YmplY3Q6IFJFOiBbc2FjbV0gW21pbGVd IEN5Yk9YIHYxLjAgKERyYWZ0KSBpcyBub3cgcmVsZWFzZWQgYW5kIGxpdmUgb250aGUgd2Vic2l0 ZQ0KDQogDQoNCkkgZWNobyBMdWlz4oCZIGNvbW1lbnRzLiBJdCBpcyBnb29kIHRvIHNlZSB0aGUg aW5jbHVzaW9uIG9mIG5ldHdvcmsgb2JqZWN0cy4gUXVpY2sgcXVlc3Rpb24gdG8gdGhlIHRlYW0g cmVsYXRlZCB0byB5b3VyIG5ldGZsb3cgY29tbWVudC4NCg0KIA0KDQpJIGFtIGxvb2tpbmcgYXQ6 DQoNCmh0dHA6Ly9jeWJveC5taXRyZS5vcmcvWE1MU2NoZW1hL2N5Ym94X2NvcmVfdjEuMCUyOGRy YWZ0JTI5LnhzZA0KDQogDQoNCuKApiBhbmQgaXQgbG9va3MgdGhhdCB3ZSByZW5hbWVkIGl0IHRv IOKAnERhdGEgRmxvd+KAnT8NCg0KIA0KDQo8eHM6ZW51bWVyYXRpb24gdmFsdWU9IkRhdGEgRmxv dyI+DQoNCiAgIDx4czphbm5vdGF0aW9uPg0KDQogICAgICAgIDx4czpkb2N1bWVudGF0aW9uPlNw ZWNpZmllcyB0aGUgY2xhc3Mgb2YgZXZlbnRzIGRlYWxpbmcgd2l0aCBkYXRhIGZsb3cuPC94czpk b2N1bWVudGF0aW9uPg0KDQogICA8L3hzOmFubm90YXRpb24+DQoNCjwveHM6ZW51bWVyYXRpb24+ DQoNCiANCg0KIA0KDQpXaGF0IGlzIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gdGhhdCBhbmQg4oCc UGFja2V0IFRyYWZmaWPigJ0/DQoNCiANCg0KPHhzOmVudW1lcmF0aW9uIHZhbHVlPSJQYWNrZXQg VHJhZmZpYyI+DQogICA8eHM6YW5ub3RhdGlvbj4NCiAgICAgPHhzOmRvY3VtZW50YXRpb24+U3Bl Y2lmaWVzIHRoZSBjbGFzcyBvZiBldmVudHMgZGVhbGluZyB3aXRoIHBhY2tldCB0cmFmZmljLjwv eHM6ZG9jdW1lbnRhdGlvbj4NCiAgIDwveHM6YW5ub3RhdGlvbj4NCjwveHM6ZW51bWVyYXRpb24+ DQoNCiANCg0KIA0KDQogDQoNCiANCg0KUmVnYXJkcywNCg0KT21hciBTYW50b3MNCkluY2lkZW50 IE1hbmFnZXIsIFBTSVJUDQpTZWN1cml0eSBSZXNlYXJjaCBhbmQgT3BlcmF0aW9ucw0KQ2lzY28g U3lzdGVtcywgSW5jLg0KRW1haWw6IG9zQGNpc2NvLmNvbQ0KUGhvbmU6ICsxIDkxOSAzOTIgODYz NQ0KUEdQIEtleTogMHgzQUYyN0VEQw0KDQpDaXNjby5jb20gLSBodHRwOi8vd3d3LmNpc2NvLmNv bQ0KQ2lzY28gU2VjdXJpdHkgQWR2aXNvcmllcyBhbmQgTm90aWNlcyAtIGh0dHA6Ly93d3cuY2lz Y28uY29tL2dvL3BzaXJ0DQoNClRoaXMgZW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFu ZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0aGUgc29sZQ0KdXNlIG9mIHRoZSBpbnRlbmRlZCBy ZWNpcGllbnQuIEFueSByZXZpZXcsIHVzZSwgZGlzdHJpYnV0aW9uIG9yDQpkaXNjbG9zdXJlIGJ5 IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5k ZWQNCnJlY2lwaWVudCAob3IgYXV0aG9yaXplZCB0byByZWNlaXZlIGZvciB0aGUgcmVjaXBpZW50 KSwgcGxlYXNlIGNvbnRhY3QNCnRoZSBzZW5kZXIgYnkgcmVwbHkgZW1haWwgYW5kIGRlbGV0ZSBh bGwgY29waWVzIG9mIHRoaXMgbWVzc2FnZS4NCg0KRm9yIGNvcnBvcmF0ZSBsZWdhbCBpbmZvcm1h dGlvbiBnbyB0bzoNCmh0dHA6Ly93d3cuY2lzY28uY29tL3dlYi9hYm91dC9kb2luZ19idXNpbmVz cy9sZWdhbC9jcmkvaW5kZXguaHRtbA0KDQogDQoNCkZyb206IHNhY20tYm91bmNlc0BpZXRmLm9y ZyBbbWFpbHRvOnNhY20tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEx1aXMgTnVuZXoN ClNlbnQ6IE1vbmRheSwgQXByaWwgMTYsIDIwMTIgNjo0NCBQTQ0KVG86IEJhcm51bSwgU2VhbiBE Lg0KQ2M6IGlkeHdnQG5pY3dnLm9yZzsgbWlsZUBpZXRmLm9yZzsgRG91ZyBXaWxzb24gKGRhbGxl bmRvdWdAZ21haWwuY29tKTsgc2FjbUBpZXRmLm9yZzsgSVBBLU1hc2F0byBUZXJhZGEgKG0tdGVy YWRhQGlwYS5nby5qcCkNClN1YmplY3Q6IFJlOiBbc2FjbV0gW21pbGVdIEN5Yk9YIHYxLjAgKERy YWZ0KSBpcyBub3cgcmVsZWFzZWQgYW5kIGxpdmUgb250aGUgd2Vic2l0ZQ0KDQogDQoNCkkgbGlr ZSB0aGUgaW5jbHVzaW9uIG9mIHRoZSBuZXR3b3JrLWNlbnRyaWMgb2JqZWN0cy4gIElQRklYIChu ZXRmbG93KSAgd2lsbCBhZGQgYW4gYWRkaXRpb25hbCBwZXJzcGVjdGl2ZSBmcm9tIGFuIGluY2lk ZW50IGluZm9ybWF0aW9uIHNoYXJpbmcgc3RhbmRwb2ludC4gIA0KDQogDQoNCi1sbg0KDQogDQoN Ck9uIEFwciAxNiwgMjAxMiwgYXQgNDowNCBQTSwgQmFybnVtLCBTZWFuIEQuIHdyb3RlOg0KDQog DQoNCkhleSBldmVyeW9uZSwNCg0KIA0KDQpJIGp1c3Qgd2FudGVkIHRvIGxldCB5b3UgYWxsIGtu b3cgdGhhdCBDeWJPWCB2MS4wIChEcmFmdCkgY29udGVudCBpcyBub3cgbGl2ZSBvbiB0aGUgd2Vi c2l0ZS4gaHR0cDovL2N5Ym94Lm1pdHJlLm9yZw0KDQpUaGUgcmVsZWFzZSBub3RlcyBhcmUgcHJv dmlkZWQgaW5saW5lIGJlbG93Lg0KDQpUaGUga2V5IGl0ZW1zIG9mIG5vdGUgYXJlOg0KDQrCtyAg ICAgICAgVGhlIHJlbGVhc2Ugb2YgdHdvIGZvcm1hbCBzcGVjaWZpY2F0aW9ucyBmb3IgdGhlIEN5 Yk9YIGxhbmd1YWdlIChvbmUgZm9yIHRoZSBjb3JlIGxhbmd1YWdlIGFuZCBvbmUgZm9yIHRoZSBk ZWZpbmVkIG9iamVjdHMpDQoNCsK3ICAgICAgICBUaGUgWE1MIFNjaGVtYSBoYXMgZ29uZSB0aHJv dWdoIGV4dGVuc2l2ZSBpbXByb3ZlbWVudHMgZm9yIGV4cHJlc3NpdmVuZXNzLCBjbGFyaXR5LCBj b25zaXN0ZW5jeSwgZWZmaWNpZW5jeSwgYWxpZ25tZW50IHRvIGV4aXN0aW5nIG5vcm1hdGl2ZSBy ZWZlcmVuY2VzIGFuZCBkb2N1bWVudGF0aW9uLg0KDQrCtyAgICAgICAgVGhpcyByZWxlYXNlIGlu Y2x1ZGVzIGFuIGluaXRpYWwgc2V0IG9mIGxhbmd1YWdlIHV0aWxpdGllczogYSBkcmFmdCBTbm9y dCAtPiBDeWJPWCB0cmFuc2Zvcm0sIGEgZHJhZnQgT3BlbklPQyAtPiBDeWJPWCB0cmFuc2Zvcm0s IGFuZCBhIHNldCBvZiBQeXRob24gYmluZGluZ3MgZm9yIHRoZSBDeWJPWCBsYW5ndWFnZS4NCg0K wrcgICAgICAgIFRoZSB3ZWJzaXRlIG5vdyBpbmNsdWRlcyBhIHNtYWxsIHNldCBvZiBjb250ZW50 IGV4YW1wbGVzLiBUaGlzIHNldCB3aWxsIGdyb3cgZ29pbmcgZm9yd2FyZC4NCg0KVGhpcyByZWxl YXNlIGludm9sdmVkIGEgbG90IG9mIGhhcmQgd29yayBmcm9tIGEgZGl2ZXJzZSBncm91cCBvZiBw ZW9wbGUuIFRoYW5rIHlvdSBhbGwgZm9yIHlvdXIgY29udHJpYnV0aW9ucyBhbmQgZWZmb3J0LiBX ZSBjb3VsZCBub3QgaGF2ZSBkb25lIGl0IHdpdGhvdXQgeW91Lg0KDQpXZSBsb29rIGZvcndhcmQg dG8gZXZlcnlvbmXigJlzIGZlZWRiYWNrIGFuZCBjb2xsYWJvcmF0aW9uIGFzIHdlIGNvbnRpbnVl IHRvIGltcHJvdmUgYW5kIG1hdHVyZSB0aGUgQ3liT1ggbGFuZ3VhZ2UuDQoNCiANCg0KU2VhbiBC YXJudW0NCg0KIA0KDQogDQoNCiANCg0KQ3liT1ggdjEuMCAoRHJhZnQpIFJlbGVhc2UgTm90ZXMN Cg0KVGhlIFZlcnNpb24gMS4wIChEcmFmdCkgcmVsZWFzZSBvZiBDeWJlciBPYnNlcnZhYmxlIGVY cHJlc3Npb24gKEN5Yk9Y4oSiKSBpcyBpbnRlbmRlZCBhcyBhIGRyYWZ0IHJlbGVhc2Ugb2YgYW4g aW5pdGlhbCBtYWpvciB2ZXJzaW9uIG9mIHRoZSBDeWJPWCBMYW5ndWFnZSB0aGF0IGNvdWxkIGJl IHV0aWxpemVkIGZvciBwcmFjdGljYWwgb3BlcmF0aW9uYWwgdXNlIGFuZCBpbnRlZ3JhdGlvbiBp bnRvIG90aGVyIHN0YW5kYXJkcyBlZmZvcnRzLiBUaGlzIHJlbGVhc2UgY29uc2lzdHMgb2YgdGhy ZWUgcHJpbWFyeSBjb21wb25lbnRzOiBhIHBhaXIgb2YgZm9ybWFsIGxhbmd1YWdlIHNwZWNpZmlj YXRpb25zIGZvciB0aGUgY29yZSBsYW5ndWFnZSBjb250ZW50IGFuZCBkZWZpbmVkIG9iamVjdHMg Y29udGVudCwgYSBzZXQgb2YgbGFuZ3VhZ2UgaW1wbGVtZW50YXRpb24gWE1MIHNjaGVtYXMgKGNv cmUsIGNvbW1vbl90eXBlcywgYW5kIH43MCBkZWZpbmVkIG9iamVjdCBzY2hlbWFzKSwgYW5kIGEg c21hbGwgaW5pdGlhbCBzZXQgb2YgbGFuZ3VhZ2UgdXRpbGl0aWVzIGluY2x1ZGluZyBhbiBpbml0 aWFsIGRyYWZ0IFNub3J0LT5DeWJPWCB0cmFuc2Zvcm0sIGFuIGluaXRpYWwgZHJhZnQgT3BlbklP Qy0+Q3liT1ggdHJhbnNmb3JtIGFuZCBhIHNldCBvZiBDeWJPWCBsYW5ndWFnZSBQeXRob24gYmlu ZGluZ3MuIFJlY29nbml6aW5nIHRoYXQgdGhpcyBpcyB0aGUgZmlyc3QgdGltZSB0aGF0IHRoZSBm b3JtYWwgbGFuZ3VhZ2Ugc3BlY2lmaWNhdGlvbnMgd2lsbCBiZSBhdmFpbGFibGUgZm9yIHJldmll dyBhbmQgYXMgc3VjaCB3aWxsIGxpa2VseSBnZW5lcmF0ZSBmZWVkYmFjayBmcm9tIG5ldyBzdGFr ZWhvbGRlcnMsIHRoaXMgaW5pdGlhbCBtYWpvciB2ZXJzaW9uIGlzIGJlaW5nIHJlbGVhc2VkIGFz IGEg4oCcZHJhZnTigJ0gdjEuMCB3aXRoIHRoZSBleHBlY3RhdGlvbiBvZiBjeWNsZXMgb2YgbmV3 IGZlZWRiYWNrIGFuZCByZXZpc2lvbiBiZWZvcmUgYSDigJxmaW5hbOKAnSB2MS4wIGlzIHJlbGVh c2VkLg0KDQpUaGUgQ3liT1ggdjEuMCAoRHJhZnQpIFhNTCBzY2hlbWFzIGluY2x1ZGUgYSBzaWdu aWZpY2FudCBudW1iZXIgb2YgY2hhbmdlcyBmcm9tIHYwLjcgdG8gaW1wcm92ZToNCg0KwrcgICAg ICAgQ2xhcml0eSwgZG9jdW1lbnRhdGlvbiwgYW5kIGRlc2NyaXB0aXZlIGZvcm1hbGl0eSBmb3Ig cmVmZXJlbmNlIGFuZCBpbXBsZW1lbnRhdGlvbiBieSBvdGhlciBzdGFuZGFyZHMgYW5kIHVzZXJz Lg0KDQrCtyAgICAgICBDb25zaXN0ZW5jeSwgc2ltcGxpY2l0eSwgYW5kIGVmZmljaWVuY3kuDQoN CsK3ICAgICAgIEFsaWdubWVudCAoYXMgYXBwcm9wcmlhdGUpIHRvIGV4aXN0aW5nIG5vcm1hdGl2 ZSByZWZlcmVuY2VzLg0KDQrCtyAgICAgICBFeHByZXNzaXZlbmVzcyBvZiB0aGUgc2NoZW1hIHRv IGJldHRlciBzdXBwb3J0IHRoZSBicm9hZCBzZXQgb2YgdXNlIGNhc2VzIGl0IHRhcmdldHMgKG1h bHdhcmUgY2hhcmFjdGVyaXphdGlvbiwgaW5kaWNhdG9yIGFuZCBpbmNpZGVudCBkYXRhIHNoYXJp bmcsIGV2ZW50IG1hbmFnZW1lbnQsIGV0Yy4pIGluY2x1ZGluZyB0aGUgYWRkaXRpb24gb2YgYW4g aW5pdGlhbCBzZXQgb2YgbmV0d29yay1yZWxhdGVkIGRlZmluZWQgb2JqZWN0cy4NCg0KU3VtbWFy eSBvZiBjaGFuZ2VzIGZyb20gQ3liT1hfdjAuNyB0byBDeWJPWF92MS4wXyhEcmFmdCk6DQoNCsK3 ICAgICAgICBSZWZpbmVtZW50IG9mIG5hbWVzcGFjZXMgYW5kIHNjaGVtYSBsb2NhdGlvbnMgZm9y IGJldHRlciBlZmZlY3RpdmVuZXNzIGFuZCBmbGV4aWJpbGl0eSBnb2luZyBmb3J3YXJkLg0KDQrC tyAgICAgICAgTm9ybWFsaXplZCBhbGwgY29udGVudCBhY2NvcmRpbmcgdG8gYW4gZXN0YWJsaXNo ZWQgc2V0IG9mIG5hbWluZyBjb252ZW50aW9ucy4NCg0KwrcgICAgICAgIEZ1bGx5IGFubm90YXRl ZCBhbGwgbGFuZ3VhZ2UgaXRlbXMgKHR5cGVzLCBhdHRyaWJ1dGVzLCBlbGVtZW50cywgZXRjLiku DQoNCsK3ICAgICAgICBNb3ZlZCBzZXZlcmFsIGNvbW1vbmx5IGxldmVyYWdlZCB0eXBlcyBvdXQg b2YgdGhlIGNvcmUgc2NoZW1hIGFuZCBpbnRvIGNvbW1vbl90eXBlcy4NCg0KwrcgICAgICAgIEFj aGlldmVkIGZ1bGwgdHlwaW5nIG9mIGVudGlyZSBzY2hlbWEgc3RydWN0dXJlIHN1Y2ggdGhhdCBh bGwgYXR0cmlidXRlcyBhbmQgZWxlbWVudHMgYXJlIGRlZmluaXRpdmVseSB0eXBlZC4NCg0Kwrcg ICAgICAgIENoYW5nZWQgYWxsIGlkZW50aWZpZXJzIGZyb20gSUQgYW5kIElEUkVGIHR5cGVzIHRv IGJlIFFOYW1lcyBlbmFibGluZyBnbG9iYWxseSB1bmlxdWUgaWRlbnRpZmllcnMgYW5kIGZsZXhp YmlsaXR5IGZvciBkb21haW4tc3BlY2lmaWMgdXNlcnMgb2YgQ3liT1ggdG8gZGVmaW5lIHRoZWly IG93biBpZGVudGlmaWVyIHN5bnRheCBsb2NhbGx5Lg0KDQrCtyAgICAgICAgUmVvcmRlcmVkIGF0 dHJpYnV0ZXMgYW5kIGVsZW1lbnRzIGluIG51bWVyb3VzIHR5cGVzIHRvIGJldHRlciByZWZsZWN0 IGNvbW1vbiB1c2FnZSBhbmQgcHJpb3JpdHkuDQoNCsK3ICAgICAgICBBZGRlZCBtYWpvcl92ZXJz aW9uIGFuZCBtaW5vcl92ZXJzaW9uIGF0dHJpYnV0ZXMgZm9yIGNvcmUgc2NoZW1hLg0KDQrCtyAg ICAgICAgQWRkZWQgY2FwYWJpbGl0eSB0byBjaGFyYWN0ZXJpemUgc291cmNlIG9mIG92ZXJhbGwg b2JzZXJ2YWJsZSBwYWNrYWdlIGRhdGEgYW5kIGZvciBpbmRpdmlkdWFsIG9ic2VydmFibGVzLg0K DQrCtyAgICAgICAgTW9kaWZpZWQgdGhlIGxvZ2ljYWwgY29tcG9zaXRpb24gc3RydWN0dXJlIHN1 Y2ggdGhhdCBhbnkgc3VjaCBjb21wb3NpdGlvbnMgYXJlIG5vdyBjb250YWluZWQgd2l0aGluIGEg T2JzZXJ2YWJsZV9Db21wb3NpdGlvbiBlbGVtZW50IHByb3ZpZGluZyBpbXByb3ZlZCBzaW1wbGlj aXR5IGFuZCBtb2R1bGFyaXR5Lg0KDQrCtyAgICAgICAgUmVtb3ZlZCB0aGUgRGVsdGEgZWxlbWVu dCBmcm9tIE9ic2VydmFibGVUeXBlIGFuZCByZWxvY2F0ZWQgdGhlIGFwcHJvcHJpYXRlIHBvcnRp b25zIChDaGFuZ2UsIFRyZW5kLCBhbmQgRnJlcXVlbmN5KSB0byBhcHByb3ByaWF0ZSBsb2NhdGlv bnMgdW5kZXIgU3RhdGVmdWxfTWVhc3VyZSBhbmQgRXZlbnQuDQoNCsK3ICAgICAgICBBZGRlZCBh IERvbWFpbl9TcGVjaWZpY19PYmplY3RfQXR0cmlidXRlcyBmaWVsZCB0byBPYmplY3QgdXRpbGl6 aW5nIGFuIGFic3RyYWN0IHR5cGUgdGhhdCB3aWxsIGFsbG93IGRvbWFpbi1zcGVjaWZpYyB1c2Ug Y2FzZXMgdG8gYWRkIGluIHRoZWlyIG93biBkb21haW4tc3BlY2lmaWMgYXR0cmlidXRlcyBmb3Ig T2JqZWN0cy4NCg0KwrcgICAgICAgIEFkZGVkIGEgVG9vbC1TcGVjaWZpY19EYXRhIGZpZWxkIHRv IFRvb2xJbmZvcm1hdGlvblR5cGUgdXRpbGl6aW5nIGFuIGFic3RyYWN0IHR5cGUgdGhhdCB3aWxs IGFsbG93IGFkZGl0aW9uIG9mIHRvb2wtc3BlY2lmaWMgZGF0YS4NCg0KwrcgICAgICAgIEFkZGVk IGFuIEluZGljYXRvcnMgZmllbGQgdG8gTWVhc3VyZVNvdXJjZVR5cGUgdXRpbGl6aW5nIGFuIGFi c3RyYWN0IHR5cGUgdGhhdCB3aWxsIGFsbG93IGNoYXJhY3Rlcml6aW5nIGRpZmZlcmluZyBmb3Jt YXRzIG9yIHN0YW5kYXJkcyBvZiBpbmRpY2F0b3JzIHRoYXQgbWF5IGhhdmUgbGVkIHRvIHRoZSBp ZGVudGlmaWNhdGlvbiBvZiB0aGUgb2JzZXJ2YWJsZSBkYXRhLg0KDQrCtyAgICAgICAgRW5oYW5j ZWQgdGhlIEhhc2ggc3RydWN0dXJlIHRvIGNhcHR1cmUgZnVsbCBmdXp6eSBoYXNoZXMgaW4gYWRk aXRpb24gdG8gc2ltcGxlIGhhc2hlcw0KDQrCtyAgICAgICAgQWRkZWQgYSBuZXcgRXh0cmFjdGVk RmVhdHVyZXNUeXBlIHRoYXQgY2FuIGJlIHVzZWQgdG8gYWRvcm4gZGlmZmVyaW5nIG9iamVjdHMg KGUuZy4sIGZpbGVzLCBtZW1vcnksIGV0Yy4pIHRvIGNhcHR1cmUgZXh0cmFjdGVkIHN0cmluZ3Ms IGltcG9ydHMsIGZ1bmN0aW9ucyBhbmQgY29kZSBzbmlwcGV0cw0KDQrCtyAgICAgICAgQWRkZWQg YSBCeXRlUnVuc1R5cGUgdG8gZW5hYmxlIGNhcHR1cmUgb2YgYnl0ZSBydW5zIHdpdGhpbiB2YXJp b3VzIG9iamVjdHMuDQoNCsK3ICAgICAgICBBZGRlZCBvYmplY3RfcmVmZXJlbmNlIGF0dHJpYnV0 ZSB0byBEZWZpbmVkT2JqZWN0VHlwZSB0byBiZXR0ZXIgc3VwcG9ydCByZWZlcmVuY2luZyBvZiBp bmRlcGVuZGVudGx5IGRlZmluZWQgT2JqZWN0cyBmcm9tIHdpdGhpbiBhbm90aGVyIE9iamVjdCBk ZWZpbml0aW9uLg0KDQrCtyAgICAgICAgQWRkZWQgYSBnZW5lcmljIERhdGFTZWdtZW50VHlwZSB0 byBwcm92aWRlIGEgcmVsYXRpdmVseSBhYnN0cmFjdCB3YXkgb2YgY2hhcmFjdGVyaXppbmcgZGF0 YSBzZWdtZW50cyB0aGF0IG1heSBiZSB3cml0dGVuL3JlYWQvdHJhbnNtaXR0ZWQgb3Igb3RoZXJ3 aXNlIHV0aWxpemVkIGluIGFjdGlvbnMgb3IgZGVmaW5lZCBpbiBvYmplY3RzLg0KDQrCtyAgICAg ICAgQWRkZWQgc2V2ZXJhbCBuZXcgZGVmaW5lZCBvYmplY3Qgc2NoZW1hcyAoQVBJLCBDb2RlLCBE ZXZpY2UsIEROU19SZWNvcmQsIE5ldHdvcmtfRmxvdywgTmV0d29ya19QYWNrZXQsIE5ldHdvcmtf Um91dGVfRW50cnksIE5ldHdvcmtfU3VibmV0LCBVbml4X05ldHdvcmtfUm91dGVfRW50cnkpIGlu Y2x1ZGluZyBhbiBpbml0aWFsIHNldCBvZiBuZXR3b3JrLWNlbnRyaWMgZGVmaW5lZCBvYmplY3Rz Lg0KDQrCtyAgICAgICAgTW9kaWZpZWQgZXZlcnkgZGVmaW5lZCBvYmplY3Qgc2NoZW1hIHdpdGgg YWRkZWQgYW5ub3RhdGlvbnMgYXMgd2VsbCBhcyBtaW5vciBhbmQgaW4gc29tZSBjYXNlcyBzdWJz dGFudGl2ZSBjaGFuZ2VzIHRvIGZpeCBlcnJvcnMsIGltcHJvdmUgY29uc2lzdGVuY3kgYW5kIGFs aWdubWVudCB3aXRoIGV4aXN0aW5nIG5vcm1hdGl2ZSByZWZlcmVuY2VzLCBhbmQgdG8gaW1wcm92 ZSBleHByZXNzaXZlbmVzcyBpbiBzdXBwb3J0IG9mIHRoZSB0YXJnZXRlZCB1c2UgY2FzZXMuDQoN CkRldGFpbGVkIGNoYW5nZXMgZnJvbSBDeWJPWF92MC43IHRvIEN5Yk9YX3YxLjBfKERyYWZ0KToN Cg0KVGhlIGxldmVsIG9mIGNoYW5nZXMgd2l0aGluIHYxLjAgKERyYWZ0KSBpbiB0aGUgY29yZSBz Y2hlbWEsIGNvbW1vbl90eXBlcyBhbmQgdGhlIGRlZmluZWQgb2JqZWN0IHNjaGVtYXMgaXMgdG9v IGdyZWF0IHRvIGxpc3QgZXZlcnkgY2hhbmdlIGluIHRoZXNlIHJlbGVhc2Ugbm90ZXMuIERldGFp bGVkIGRpZmZlcmVuY2UgcmVwb3J0cyBhcmUgYXZhaWxhYmxlIGZvciBlYWNoIGluZGl2aWR1YWwg c2NoZW1hIGF0Omh0dHA6Ly9jeWJveC5taXRyZS5vcmcvWE1MU2NoZW1hL3JlbGVhc2Vfbm90ZXMv Y3lib3hfdjEuMChkcmFmdClfZGlmZl9yZXBvcnRzLnppcCA8aHR0cDovL2N5Ym94Lm1pdHJlLm9y Zy9YTUxTY2hlbWEvcmVsZWFzZV9ub3Rlcy9jeWJveF92MS4wKGRyYWZ0KV9kaWZmX3JlcG9ydHMu emlwPiANCg0KIA0KDQogDQoNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09DQoNClNlYW4gQmFybnVtDQoNCkN5YmVyIFNlY3VyaXR5IFByaW5jaXBhbA0KDQpU aGUgTUlUUkUgQ29ycG9yYXRpb24NCg0KRW1haWw6IHNiYXJudW1AbWl0cmUub3JnDQoNCiANCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1pbGUgbWFp bGluZyBsaXN0DQptaWxlQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL21pbGUNCg0KIA0KDQo= ------_=_NextPart_001_01CD1C4C.A5E487EB Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXVzLWFzY2lpIj48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250 ZW50PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PGJhc2UgaHJlZj0ieC1t c2c6Ly8yMDEyLyI+PHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZh Y2UNCgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIg MTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FtYnJpYTsN CglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9 DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2 Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0K cC5Nc29UaXRsZSwgbGkuTXNvVGl0bGUsIGRpdi5Nc29UaXRsZQ0KCXttc28tc3R5bGUtcHJpb3Jp dHk6MTA7DQoJbXNvLXN0eWxlLWxpbms6IlRpdGxlIENoYXIiOw0KCW1zby1tYXJnaW4tdG9wLWFs dDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1M IFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5N c29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFw aA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJ bWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4t bGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5h bWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyI7fQ0Kc3Bhbi5UaXRsZUNoYXINCgl7bXNvLXN0eWxlLW5hbWU6IlRpdGxlIENoYXIiOw0K CW1zby1zdHlsZS1wcmlvcml0eToxMDsNCgltc28tc3R5bGUtbGluazpUaXRsZTsNCglmb250LWZh bWlseToiQ2FtYnJpYSIsInNlcmlmIjsNCgljb2xvcjojMTczNjVEOw0KCWxldHRlci1zcGFjaW5n Oi4yNXB0O30NCnNwYW4uYXBwbGUtc3R5bGUtc3Bhbg0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1z dHlsZS1zcGFuO30NCnNwYW4uYXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1l OmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkVtYWlsU3R5bGUyNA0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNv bG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjUNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjoj MUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEu MGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGww DQoJe21zby1saXN0LWlkOjExMjU2NTYwMjA7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi04MTgw MjAxOTY7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDpcRjBCNzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGww OmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ6XEYwQjc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpcRjBCNzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0OlxGMEI3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoy LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ6XEYwQjc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw2 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpcRjBC NzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0OlxGMEI3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ6XEYwQjc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg bDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDpcRjBCNzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1p ZDoxMzM1MjMxNTMxOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxMTczMTQ4NDMyO30NCkBsaXN0 IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ6XEYwQjc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0OlxGMEI3Ow0KCW1z by1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6XEYwQjc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDpcRjBCNzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZl bDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0OlxG MEI3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6XEYwQjc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDpcRjBCNzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMTpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0OlxGMEI3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsOQ0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6XEYwQjc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDINCgl7bXNvLWxpc3QtaWQ6MTMzNTc2OTM5OTsN Cgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTIwMTEyNzI4OTI7fQ0KQGxpc3QgbDI6bGV2ZWwxDQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpcRjBCNzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6XEYwQjc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDI6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDpcRjBCNzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjps ZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 OlxGMEI3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsNQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6XEYwQjc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpcRjBCNzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4w aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMjpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0OlxGMEI3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsOA0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6XEYwQjc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpcRjBCNzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpAbGlzdCBsMw0KCXttc28tbGlzdC1pZDoxNTAxNTAzMTc2Ow0KCW1zby1saXN0LXRl bXBsYXRlLWlkczoxMzQ1NjEwNDUyO30NCkBsaXN0IGwzOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6XEYwQjc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0OlxGMEI3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwz OmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ6XEYwQjc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw0DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpcRjBCNzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0OlxGMEI3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoy LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGwzOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ6XEYwQjc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw3 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpcRjBC NzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDgNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0OlxGMEI3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ6XEYwQjc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0Kb2wNCgl7 bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPjwvaGVhZD48 Ym9keSBsYW5nPUVOLVVTIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+PGZvbnQgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPg0KSWYgJnF1b3Q7ZGF0YSBmbG93JnF1b3Q7IGlzIGEg ZXVwaGVtaXNtIGZvciAmcXVvdDtuZXRmbG93JnF1b3Q7IGlzIHRoZXJlIGFueSByZWFzb24gbm90 IHRvIGNhbGwgaXQgdGhhdD88YnI+DTxicj5Ub20gTWlsbGFyDTxicj5odHRwOi8vd3d3LnVzLWNl cnQuZ292Lw08YnI+LS0tLS0tLS0tLS0tLS0tLS0tDTxicj5NaXNzaXQgbWUgUnVidXMgZnJ1dGlj b3N1czoNPGJyPjIwMiA2MzEgMTkxNQ08YnI+PC9mb250Pjxicj4mbmJzcDs8YnI+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzoz LjBwdCAwaW4gMGluIDBpbiI+DQo8Zm9udCBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+DQo8Yj5Gcm9t PC9iPjogQmFybnVtLCBTZWFuIEQuIFttYWlsdG86c2Jhcm51bUBtaXRyZS5vcmddDTxicj48Yj5T ZW50PC9iPjogTW9uZGF5LCBBcHJpbCAxNiwgMjAxMiAxMToyOSBQTTxicj48Yj5UbzwvYj46IE9t YXIgU2FudG9zIChvc2FudG9zKSAmbHQ7b3NhbnRvc0BjaXNjby5jb20mZ3Q7OyBMdWlzIE51bmV6 ICZsdDtsbnVuZXpAYzNpc2VjdXJpdHkuY29tJmd0Ow08YnI+PGI+Q2M8L2I+OiBpZHh3Z0BuaWN3 Zy5vcmcgJmx0O2lkeHdnQG5pY3dnLm9yZyZndDs7IG1pbGVAaWV0Zi5vcmcgJmx0O21pbGVAaWV0 Zi5vcmcmZ3Q7OyBkYWxsZW5kb3VnQGdtYWlsLmNvbSAmbHQ7ZGFsbGVuZG91Z0BnbWFpbC5jb20m Z3Q7OyBzYWNtQGlldGYub3JnICZsdDtzYWNtQGlldGYub3JnJmd0OzsgbS10ZXJhZGFAaXBhLmdv LmpwICZsdDttLXRlcmFkYUBpcGEuZ28uanAmZ3Q7DTxicj48Yj5TdWJqZWN0PC9iPjogUmU6IFtz YWNtXSBbbWlsZV0gQ3liT1ggdjEuMCAoRHJhZnQpIGlzIG5vdyByZWxlYXNlZCBhbmQgbGl2ZSBv bnRoZSB3ZWJzaXRlDTxicj48L2ZvbnQ+Jm5ic3A7PGJyPjwvZGl2Pg0KPGRpdiBjbGFzcz1Xb3Jk U2VjdGlvbjE+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+VGhhbmtz IE9tYXIuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2Nv bG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5UbyBhbnN3ZXIgeW91ciBxdWVzdGlvbiwgZmlyc3Qg bGV0IG1lIHBvaW50IG91dCB0byBvdGhlciByZWFkZXJzIHRoYXQgdGhlIHR3byBlbnRyaWVzIHRo YXQgT21hciBpcyBxdW90aW5nIGhlcmUgZXhpc3QgYXMgdmFsdWVzIGluIGFuIGVudW1lcmF0aW9u IGNhbGxlZCBFdmVudFR5cGVFbnVtIHdoaWNoIGFzIGl0cyBuYW1lIGltcGxpZXMgY29udGFpbnMg YSBsaXN0IG9mIGRpZmZlcmVudCBsYWJlbHMgZm9yIGdyb3VwaW5nIHR5cGVzIChvciBjbGFzc2Vz KSBvZiBldmVudHMgdG8gYmUgdXNlZCBhcyBsb3ctZ3JhbnVsYXJpdHkgYnVja2V0cyBmb3IgY2hh cmFjdGVyaXppbmcgYW5kIGNsYXNzaWZ5aW5nIGV2ZW50cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+T3RoZXIgZW50cmllcyBp biB0aGlzIGVudW1lcmF0aW9uIGluY2x1ZGUgdGhpbmdzIGxpa2UgJiM4MjIwO0ZpbGUgT3BzIChD UlVEKSYjODIyMTssICYjODIyMDtQcm9jZXNzIE1ndCYjODIyMTssICYjODIyMDtBdXRob3JpemF0 aW9uIChBQ0wpJiM4MjIxOywgZXRjLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+VGhlICYjODIyMDtQYWNr ZXQgVHJhZmZpYyYjODIyMTsgdmFsdWUgaXMgaW50ZW5kZWQgdG8gY2hhcmFjdGVyaXplIGV2ZW50 cyBkZWFsaW5nIHdpdGggbmV0d29yayBwYWNrZXQgdHJhZmZpYyBhcyBpdHMgbmFtZSBpbXBsaWVz LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjoj MUY0OTdEJz5UaGUgJiM4MjIwO0RhdGEgRmxvdyYjODIyMTsgdmFsdWUgaXMgaW50ZW5kZWQgdG8g Y2hhcmFjdGVyaXplIGV2ZW50cyBkZWFsaW5nIHdpdGggZm9ybXMgb2YgZGF0YSBmbG93IGF0IGEg aGlnaGVyIGxldmVsIG9mIGFic3RyYWN0aW9uIHRoYW4ganVzdCBwYWNrZXQgdHJhZmZpYy4gVGhl IHJlbGF0aW9uc2hpcCBiZXR3ZWVuIHRoZXNlIHR3byB2YWx1ZXMgY291bGQgYmUgdmlld2VkIGFz ICYjODIyMDtQYWNrZXQgVHJhZmZpYyYjODIyMTsgYmVpbmcgYSBtb3JlIGRldGFpbGVkIGZvcm0g b2YgJiM4MjIwO0RhdGEgRmxvdyYjODIyMTsganVzdCBhcyB0aGUgdmFsdWVzICYjODIyMDtBcHAg TGF5ZXIgVHJhZmZpYyYjODIyMTsgYW5kICYjODIyMDtIVFRQIExheWVyIFRyYWZmaWMmIzgyMjE7 LCBhbHNvIGluIHRoaXMgZW51bWVyYXRpb24sIGNvdWxkIGJlIG90aGVyIGxldmVscyBpbiB0aGlz IHNhbWUgYWJzdHJhY3Rpb24gc3RhY2suPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlRoZSBpZGVhIGJlaGluZCB0aGUgdmFyeWlu ZyBsZXZlbHMgb2YgYWJzdHJhY3Rpb24gaXMgdG8gbGVhdmUgJm5ic3A7YnVja2V0cyBsYXJnZSBl bm91Z2ggdG8gY2FwdHVyZSBhIHdpZGUgdmFyaWV0eSBvZiBwb3RlbnRpYWwgZXZlbnQgdHlwZXMg KGUuZy4gZGF0YSBmbG93IGV2ZW50cyBvdGhlciB0aGFuIG9idmlvdXMgdGhpbmdzIGxpa2UgcGFj a2V0IHRyYWZmaWMpIGJ1dCBhbHNvIGVuYWJsZSB0aGUgdXNlIG9mIHNtYWxsZXIgbW9yZSBzcGVj aWZpYyBidWNrZXRzIHdoZW4gdGhleSBhcmUgYXBwcm9wcmlhdGUgYW5kIGNvbW1vbmx5IHVzZWQu PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMx RjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjtjb2xvcjojMUY0OTdEJz5Eb2VzIHRoaXMgbWFrZSBzZW5zZT8gPG86cD48L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0 OTdEJz5zZWFuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2PjxkaXYgc3R5 bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu MHB0IDBpbiAwaW4gMGluJz48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41 aW4nPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEi LCJzYW5zLXNlcmlmIic+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+IE9tYXIgU2FudG9zIChvc2Fu dG9zKSBbbWFpbHRvOm9zYW50b3NAY2lzY28uY29tXSA8YnI+PGI+U2VudDo8L2I+IE1vbmRheSwg QXByaWwgMTYsIDIwMTIgODoxNyBQTTxicj48Yj5Ubzo8L2I+IEx1aXMgTnVuZXo7IEJhcm51bSwg U2VhbiBELjxicj48Yj5DYzo8L2I+IGlkeHdnQG5pY3dnLm9yZzsgbWlsZUBpZXRmLm9yZzsgZGFs bGVuZG91Z0BnbWFpbC5jb207IHNhY21AaWV0Zi5vcmc7IG0tdGVyYWRhQGlwYS5nby5qcDxicj48 Yj5TdWJqZWN0OjwvYj4gUkU6IFtzYWNtXSBbbWlsZV0gQ3liT1ggdjEuMCAoRHJhZnQpIGlzIG5v dyByZWxlYXNlZCBhbmQgbGl2ZSBvbnRoZSB3ZWJzaXRlPG86cD48L286cD48L3NwYW4+PC9wPjwv ZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PG86 cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDou NWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkkgZWNobyBMdWlzJiM4MjE3OyBjb21tZW50cy4g SXQgaXMgZ29vZCB0byBzZWUgdGhlIGluY2x1c2lvbiBvZiBuZXR3b3JrIG9iamVjdHMuIFF1aWNr IHF1ZXN0aW9uIHRvIHRoZSB0ZWFtIHJlbGF0ZWQgdG8geW91ciBuZXRmbG93IGNvbW1lbnQuPG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6 LjVpbic+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9y OiMxRjQ5N0QnPkkgYW0gbG9va2luZyBhdDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0Qn PjxhIGhyZWY9Imh0dHA6Ly9jeWJveC5taXRyZS5vcmcvWE1MU2NoZW1hL2N5Ym94X2NvcmVfdjEu MCUyOGRyYWZ0JTI5LnhzZCI+aHR0cDovL2N5Ym94Lm1pdHJlLm9yZy9YTUxTY2hlbWEvY3lib3hf Y29yZV92MS4wJTI4ZHJhZnQlMjkueHNkPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3 RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0n bWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4mIzgyMzA7IGFuZCBpdCBs b29rcyB0aGF0IHdlIHJlbmFtZWQgaXQgdG8gJiM4MjIwO0RhdGEgRmxvdyYjODIyMTs/PG86cD48 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVp bic+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz4mbHQ7eHM6ZW51bWVyYXRp b24gdmFsdWU9JnF1b3Q7RGF0YSBGbG93JnF1b3Q7Jmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZuYnNwOyZuYnNwOyAm bHQ7eHM6YW5ub3RhdGlvbiZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseToiQ291cmllciBOZXciJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJmx0O3hzOmRvY3VtZW50YXRpb24mZ3Q7U3BlY2lmaWVzIHRoZSBjbGFz cyBvZiBldmVudHMgZGVhbGluZyB3aXRoIGRhdGEgZmxvdy4mbHQ7L3hzOmRvY3VtZW50YXRpb24m Z3Q7PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2lu LWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3Iic+Jm5ic3A7Jm5ic3A7ICZsdDsveHM6YW5ub3RhdGlvbiZndDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz4m bHQ7L3hzOmVudW1lcmF0aW9uJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41 aW4nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+V2hhdCBpcyB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVu IHRoYXQgYW5kICYjODIyMDtQYWNrZXQgVHJhZmZpYyYjODIyMTs/PG86cD48L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHByZSBzdHlsZT0nbWFy Z2luLWxlZnQ6LjVpbic+Jmx0O3hzOmVudW1lcmF0aW9uIHZhbHVlPSZxdW90O1BhY2tldCBUcmFm ZmljJnF1b3Q7Jmd0OzxvOnA+PC9vOnA+PC9wcmU+PHByZSBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVp bic+Jm5ic3A7Jm5ic3A7ICZsdDt4czphbm5vdGF0aW9uJmd0OzxvOnA+PC9vOnA+PC9wcmU+PHBy ZSBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDt4 czpkb2N1bWVudGF0aW9uJmd0O1NwZWNpZmllcyB0aGUgY2xhc3Mgb2YgZXZlbnRzIGRlYWxpbmcg d2l0aCBwYWNrZXQgdHJhZmZpYy4mbHQ7L3hzOmRvY3VtZW50YXRpb24mZ3Q7PG86cD48L286cD48 L3ByZT48cHJlIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz4mbmJzcDsmbmJzcDsgJmx0Oy94czph bm5vdGF0aW9uJmd0OzxvOnA+PC9vOnA+PC9wcmU+PHByZSBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVp bic+Jmx0Oy94czplbnVtZXJhdGlvbiZndDs8bzpwPjwvbzpwPjwvcHJlPjxwIGNsYXNzPU1zb05v cm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4t bGVmdDouNWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21h cmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyI7Y29sb3I6IzFGNDk3RCc+UmVnYXJkcyw8YnI+PGJyPk9tYXIgU2FudG9z PGJyPkluY2lkZW50IE1hbmFnZXIsIFBTSVJUPGJyPlNlY3VyaXR5IFJlc2VhcmNoIGFuZCBPcGVy YXRpb25zPGJyPkNpc2NvIFN5c3RlbXMsIEluYy48YnI+RW1haWw6IDxhIGhyZWY9Im1haWx0bzpv c0BjaXNjby5jb20iPm9zQGNpc2NvLmNvbTwvYT48YnI+UGhvbmU6ICsxIDkxOSAzOTIgODYzNTxi cj5QR1AgS2V5OiAweDNBRjI3RURDPGJyPjxicj5DaXNjby5jb20gLSA8YSBocmVmPSJodHRwOi8v d3d3LmNpc2NvLmNvbSI+aHR0cDovL3d3dy5jaXNjby5jb208L2E+PGJyPkNpc2NvIFNlY3VyaXR5 IEFkdmlzb3JpZXMgYW5kIE5vdGljZXMgLSA8YSBocmVmPSJodHRwOi8vd3d3LmNpc2NvLmNvbS9n by9wc2lydCI+aHR0cDovL3d3dy5jaXNjby5jb20vZ28vcHNpcnQ8L2E+PGJyPjxicj5UaGlzIGVt YWlsIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBmb3Ig dGhlIHNvbGU8YnI+dXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQuIEFueSByZXZpZXcsIHVz ZSwgZGlzdHJpYnV0aW9uIG9yPGJyPmRpc2Nsb3N1cmUgYnkgb3RoZXJzIGlzIHN0cmljdGx5IHBy b2hpYml0ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZDxicj5yZWNpcGllbnQgKG9yIGF1 dGhvcml6ZWQgdG8gcmVjZWl2ZSBmb3IgdGhlIHJlY2lwaWVudCksIHBsZWFzZSBjb250YWN0PGJy PnRoZSBzZW5kZXIgYnkgcmVwbHkgZW1haWwgYW5kIGRlbGV0ZSBhbGwgY29waWVzIG9mIHRoaXMg bWVzc2FnZS48YnI+PGJyPkZvciBjb3Jwb3JhdGUgbGVnYWwgaW5mb3JtYXRpb24gZ28gdG86PGJy PjxhIGhyZWY9Imh0dHA6Ly93d3cuY2lzY28uY29tL3dlYi9hYm91dC9kb2luZ19idXNpbmVzcy9s ZWdhbC9jcmkvaW5kZXguaHRtbCI+aHR0cDovL3d3dy5jaXNjby5jb20vd2ViL2Fib3V0L2RvaW5n X2J1c2luZXNzL2xlZ2FsL2NyaS9pbmRleC5odG1sPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXY+PGRpdiBzdHls ZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4w cHQgMGluIDBpbiAwaW4nPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVp bic+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIs InNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4gPGEgaHJlZj0ibWFpbHRvOnNh Y20tYm91bmNlc0BpZXRmLm9yZyI+c2FjbS1ib3VuY2VzQGlldGYub3JnPC9hPiA8YSBocmVmPSJt YWlsdG86W21haWx0bzpzYWNtLWJvdW5jZXNAaWV0Zi5vcmddIj5bbWFpbHRvOnNhY20tYm91bmNl c0BpZXRmLm9yZ108L2E+IDxiPk9uIEJlaGFsZiBPZiA8L2I+THVpcyBOdW5lejxicj48Yj5TZW50 OjwvYj4gTW9uZGF5LCBBcHJpbCAxNiwgMjAxMiA2OjQ0IFBNPGJyPjxiPlRvOjwvYj4gQmFybnVt LCBTZWFuIEQuPGJyPjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOmlkeHdnQG5pY3dnLm9yZyI+ aWR4d2dAbmljd2cub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOm1pbGVAaWV0Zi5vcmciPm1pbGVA aWV0Zi5vcmc8L2E+OyBEb3VnIFdpbHNvbiAoPGEgaHJlZj0ibWFpbHRvOmRhbGxlbmRvdWdAZ21h aWwuY29tIj5kYWxsZW5kb3VnQGdtYWlsLmNvbTwvYT4pOyA8YSBocmVmPSJtYWlsdG86c2FjbUBp ZXRmLm9yZyI+c2FjbUBpZXRmLm9yZzwvYT47IElQQS1NYXNhdG8gVGVyYWRhICg8YSBocmVmPSJt YWlsdG86bS10ZXJhZGFAaXBhLmdvLmpwIj5tLXRlcmFkYUBpcGEuZ28uanA8L2E+KTxicj48Yj5T dWJqZWN0OjwvYj4gUmU6IFtzYWNtXSBbbWlsZV0gQ3liT1ggdjEuMCAoRHJhZnQpIGlzIG5vdyBy ZWxlYXNlZCBhbmQgbGl2ZSBvbnRoZSB3ZWJzaXRlPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2 PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PG86cD4m bmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWlu Jz5JIGxpa2UgdGhlIGluY2x1c2lvbiBvZiB0aGUgbmV0d29yay1jZW50cmljIG9iamVjdHMuICZu YnNwO0lQRklYIChuZXRmbG93KSAmbmJzcDt3aWxsIGFkZCBhbiBhZGRpdGlvbmFsIHBlcnNwZWN0 aXZlIGZyb20gYW4gaW5jaWRlbnQgaW5mb3JtYXRpb24gc2hhcmluZyBzdGFuZHBvaW50LiAmbmJz cDs8bzpwPjwvbzpwPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxl ZnQ6LjVpbic+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPi1sbjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48bzpwPiZuYnNwOzwv bzpwPjwvcD48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDou NWluJz5PbiBBcHIgMTYsIDIwMTIsIGF0IDQ6MDQgUE0sIEJhcm51bSwgU2VhbiBELiB3cm90ZTo8 bzpwPjwvbzpwPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4t dG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjEyLjBwdDttYXJnaW4t bGVmdDouNWluJz48bzpwPiZuYnNwOzwvbzpwPjwvcD48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz5IZXkgZXZlcnlvbmUsPG86cD48 L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJn aW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiIn PkkganVzdCB3YW50ZWQgdG8gbGV0IHlvdSBhbGwga25vdyB0aGF0IEN5Yk9YIHYxLjAgKERyYWZ0 KSBjb250ZW50IGlzIG5vdyBsaXZlIG9uIHRoZSB3ZWJzaXRlLjxzcGFuIGNsYXNzPWFwcGxlLWNv bnZlcnRlZC1zcGFjZT4mbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cDovL2N5Ym94Lm1pdHJlLm9y ZyI+aHR0cDovL2N5Ym94Lm1pdHJlLm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiIn PlRoZSByZWxlYXNlIG5vdGVzIGFyZSBwcm92aWRlZCBpbmxpbmUgYmVsb3cuPG86cD48L286cD48 L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVm dDouNWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiJz5UaGUga2V5IGl0ZW1zIG9mIG5vdGUgYXJlOjxvOnA+PC9vOnA+PC9z cGFuPjwvcD48L2Rpdj48ZGl2IHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48cCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW47dGV4dC1pbmRlbnQ6LS4yNWluO2xpbmUtaGVp Z2h0OjEyLjc1cHQnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OlN5 bWJvbCc+Jm1pZGRvdDs8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo3LjBwdCc+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9YXBwbGUtY29u dmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+VGhlIHJlbGVhc2Ugb2Yg dHdvIGZvcm1hbCBzcGVjaWZpY2F0aW9ucyBmb3IgdGhlIEN5Yk9YIGxhbmd1YWdlIChvbmUgZm9y IHRoZSBjb3JlIGxhbmd1YWdlIGFuZCBvbmUgZm9yIHRoZSBkZWZpbmVkIG9iamVjdHMpPG86cD48 L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXYgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxwIGNs YXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbjt0ZXh0LWluZGVudDotLjI1aW47 bGluZS1oZWlnaHQ6MTIuNzVwdCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6U3ltYm9sJz4mbWlkZG90Ozwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjcuMHB0 Jz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz1h cHBsZS1jb252ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz5UaGUgWE1M IFNjaGVtYSBoYXMgZ29uZSB0aHJvdWdoIGV4dGVuc2l2ZSBpbXByb3ZlbWVudHMgZm9yIGV4cHJl c3NpdmVuZXNzLCBjbGFyaXR5LCBjb25zaXN0ZW5jeSwgZWZmaWNpZW5jeSwgYWxpZ25tZW50IHRv IGV4aXN0aW5nIG5vcm1hdGl2ZSByZWZlcmVuY2VzIGFuZCBkb2N1bWVudGF0aW9uLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2IHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48cCBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW47dGV4dC1pbmRlbnQ6LS4yNWluO2xp bmUtaGVpZ2h0OjEyLjc1cHQnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OlN5bWJvbCc+Jm1pZGRvdDs8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo3LjBwdCc+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9YXBw bGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+VGhpcyByZWxl YXNlIGluY2x1ZGVzIGFuIGluaXRpYWwgc2V0IG9mIGxhbmd1YWdlIHV0aWxpdGllczogYSBkcmFm dCBTbm9ydCAtJmd0OyBDeWJPWCB0cmFuc2Zvcm0sIGEgZHJhZnQgT3BlbklPQyAtJmd0OyBDeWJP WCB0cmFuc2Zvcm0sIGFuZCBhIHNldCBvZiBQeXRob24gYmluZGluZ3MgZm9yIHRoZSBDeWJPWCBs YW5ndWFnZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTGlzdFBhcmFn cmFwaCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OjBpbjttYXJnaW4tcmlnaHQ6MGluO21hcmdp bi1ib3R0b206MTAuMHB0O21hcmdpbi1sZWZ0OjEuMGluO3RleHQtaW5kZW50Oi0uMjVpbjtsaW5l LWhlaWdodDoxMi43NXB0Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTpTeW1ib2wnPiZtaWRkb3Q7PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6Ny4wcHQnPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPWFwcGxl LWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPlRoZSB3ZWJzaXRl IG5vdyBpbmNsdWRlcyBhIHNtYWxsIHNldCBvZiBjb250ZW50IGV4YW1wbGVzLiBUaGlzIHNldCB3 aWxsIGdyb3cgZ29pbmcgZm9yd2FyZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPlRoaXMgcmVsZWFz ZSBpbnZvbHZlZCBhIGxvdCBvZiBoYXJkIHdvcmsgZnJvbSBhIGRpdmVyc2UgZ3JvdXAgb2YgcGVv cGxlLiBUaGFuayB5b3UgYWxsIGZvciB5b3VyIGNvbnRyaWJ1dGlvbnMgYW5kIGVmZm9ydC4gV2Ug Y291bGQgbm90IGhhdmUgZG9uZSBpdCB3aXRob3V0IHlvdS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiInPldlIGxvb2sgZm9yd2FyZCB0byBldmVyeW9uZSYjODIxNztzIGZlZWRiYWNrIGFuZCBj b2xsYWJvcmF0aW9uIGFzIHdlIGNvbnRpbnVlIHRvIGltcHJvdmUgYW5kIG1hdHVyZSB0aGUgQ3li T1ggbGFuZ3VhZ2UuPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1s ZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiInPlNlYW4gQmFybnVtPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2 PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Jz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6 LjVpbic+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIic+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXYgc3R5 bGU9J2JvcmRlcjpub25lO2JvcmRlci1ib3R0b206c29saWQgIzRGODFCRCAxLjBwdDtwYWRkaW5n OjBpbiAwaW4gNC4wcHQgMGluO2JvcmRlci13aWR0aDppbml0aWFsO2JvcmRlci1jb2xvcjppbml0 aWFsJz48cCBjbGFzcz1Nc29UaXRsZSBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OjBpbjttYXJn aW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206MTUuMHB0O21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MjYuMHB0O2ZvbnQtZmFtaWx5OiJDYW1icmlhIiwic2VyaWYiO2Nv bG9yOiMxNzM2NUQ7bGV0dGVyLXNwYWNpbmc6LjI1cHQnPkN5Yk9YIHYxLjAgKERyYWZ0KSBSZWxl YXNlIE5vdGVzPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz5UaGUgVmVyc2lvbiAxLjAgKERyYWZ0KSByZWxl YXNlIG9mIEN5YmVyIE9ic2VydmFibGUgZVhwcmVzc2lvbiAoQ3liT1gmIzg0ODI7KTxzcGFuIGNs YXNzPWFwcGxlLWNvbnZlcnRlZC1zcGFjZT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz4mbmJzcDs8L3NwYW4+PC9zcGFuPmlz IGludGVuZGVkIGFzIGEgZHJhZnQgcmVsZWFzZSBvZiBhbiBpbml0aWFsIG1ham9yIHZlcnNpb24g b2YgdGhlIEN5Yk9YIExhbmd1YWdlIHRoYXQgY291bGQgYmUgdXRpbGl6ZWQgZm9yIHByYWN0aWNh bCBvcGVyYXRpb25hbCB1c2UgYW5kIGludGVncmF0aW9uIGludG8gb3RoZXIgc3RhbmRhcmRzIGVm Zm9ydHMuIFRoaXMgcmVsZWFzZSBjb25zaXN0cyBvZiB0aHJlZSBwcmltYXJ5IGNvbXBvbmVudHM6 IGEgcGFpciBvZiBmb3JtYWwgbGFuZ3VhZ2Ugc3BlY2lmaWNhdGlvbnMgZm9yIHRoZSBjb3JlIGxh bmd1YWdlIGNvbnRlbnQgYW5kIGRlZmluZWQgb2JqZWN0cyBjb250ZW50LCBhIHNldCBvZiBsYW5n dWFnZSBpbXBsZW1lbnRhdGlvbiBYTUwgc2NoZW1hcyAoY29yZSwgY29tbW9uX3R5cGVzLCBhbmQg fjcwIGRlZmluZWQgb2JqZWN0IHNjaGVtYXMpLCBhbmQgYSBzbWFsbCBpbml0aWFsIHNldCBvZiBs YW5ndWFnZSB1dGlsaXRpZXMgaW5jbHVkaW5nIGFuIGluaXRpYWwgZHJhZnQgU25vcnQtJmd0O0N5 Yk9YIHRyYW5zZm9ybSwgYW4gaW5pdGlhbCBkcmFmdCBPcGVuSU9DLSZndDtDeWJPWCB0cmFuc2Zv cm0gYW5kIGEgc2V0IG9mIEN5Yk9YIGxhbmd1YWdlIFB5dGhvbiBiaW5kaW5ncy4gUmVjb2duaXpp bmcgdGhhdCB0aGlzIGlzIHRoZSBmaXJzdCB0aW1lIHRoYXQgdGhlIGZvcm1hbCBsYW5ndWFnZSBz cGVjaWZpY2F0aW9ucyB3aWxsIGJlIGF2YWlsYWJsZSBmb3IgcmV2aWV3IGFuZCBhcyBzdWNoIHdp bGwgbGlrZWx5IGdlbmVyYXRlIGZlZWRiYWNrIGZyb20gbmV3IHN0YWtlaG9sZGVycywgdGhpcyBp bml0aWFsIG1ham9yIHZlcnNpb24gaXMgYmVpbmcgcmVsZWFzZWQgYXMgYSAmIzgyMjA7ZHJhZnQm IzgyMjE7IHYxLjAgd2l0aCB0aGUgZXhwZWN0YXRpb24gb2YgY3ljbGVzIG9mIG5ldyBmZWVkYmFj ayBhbmQgcmV2aXNpb24gYmVmb3JlIGEgJiM4MjIwO2ZpbmFsJiM4MjIxOyB2MS4wIGlzIHJlbGVh c2VkLjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiInPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+VGhlIEN5Yk9YIHYxLjAgKERyYWZ0KSBY TUwgc2NoZW1hcyBpbmNsdWRlIGEgc2lnbmlmaWNhbnQgbnVtYmVyIG9mIGNoYW5nZXMgZnJvbSB2 MC43IHRvIGltcHJvdmU6PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXYg c3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2lu LWxlZnQ6LjVpbjt0ZXh0LWluZGVudDotLjI1aW4nPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseTpT eW1ib2wnPiZtaWRkb3Q7PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6Ny4wcHQnPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPWFwcGxlLWNvbnZlcnRl ZC1zcGFjZT4mbmJzcDs8L3NwYW4+PC9zcGFuPkNsYXJpdHksIGRvY3VtZW50YXRpb24sIGFuZCBk ZXNjcmlwdGl2ZSBmb3JtYWxpdHkgZm9yIHJlZmVyZW5jZSBhbmQgaW1wbGVtZW50YXRpb24gYnkg b3RoZXIgc3RhbmRhcmRzIGFuZCB1c2Vycy48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PC9kaXY+PGRpdiBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PHAgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSdtYXJnaW4tbGVmdDouNWluO3RleHQtaW5kZW50Oi0uMjVpbic+PHNwYW4gc3R5bGU9J2Zv bnQtZmFtaWx5OlN5bWJvbCc+Jm1pZGRvdDs8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo3 LjBwdCc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9YXBw bGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj48L3NwYW4+Q29uc2lzdGVuY3ksIHNpbXBs aWNpdHksIGFuZCBlZmZpY2llbmN5LjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rp dj48ZGl2IHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9 J21hcmdpbi1sZWZ0Oi41aW47dGV4dC1pbmRlbnQ6LS4yNWluJz48c3BhbiBzdHlsZT0nZm9udC1m YW1pbHk6U3ltYm9sJz4mbWlkZG90Ozwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjcuMHB0 Jz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz1hcHBsZS1j b252ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9zcGFuPjwvc3Bhbj5BbGlnbm1lbnQgKGFzIGFwcHJvcHJp YXRlKSB0byBleGlzdGluZyBub3JtYXRpdmUgcmVmZXJlbmNlcy48c3BhbiBzdHlsZT0nZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaCBzdHlsZT0nbXNvLW1h cmdpbi10b3AtYWx0OjBpbjttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206MTAuMHB0O21h cmdpbi1sZWZ0OjEuMGluO3RleHQtaW5kZW50Oi0uMjVpbic+PHNwYW4gc3R5bGU9J2ZvbnQtZmFt aWx5OlN5bWJvbCc+Jm1pZGRvdDs8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo3LjBwdCc+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9YXBwbGUtY29u dmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj48L3NwYW4+RXhwcmVzc2l2ZW5lc3Mgb2YgdGhlIHNj aGVtYSB0byBiZXR0ZXIgc3VwcG9ydCB0aGUgYnJvYWQgc2V0IG9mIHVzZSBjYXNlcyBpdCB0YXJn ZXRzIChtYWx3YXJlIGNoYXJhY3Rlcml6YXRpb24sIGluZGljYXRvciBhbmQgaW5jaWRlbnQgZGF0 YSBzaGFyaW5nLCBldmVudCBtYW5hZ2VtZW50LCBldGMuKSBpbmNsdWRpbmcgdGhlIGFkZGl0aW9u IG9mIGFuIGluaXRpYWwgc2V0IG9mIG5ldHdvcmstcmVsYXRlZCBkZWZpbmVkIG9iamVjdHMuPHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIic+PG86cD48L286cD48L3NwYW4+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSdtYXJnaW4tbGVmdDouNWluJz5TdW1tYXJ5IG9mIGNoYW5nZXMgZnJvbSBDeWJPWF92MC43IHRv IEN5Yk9YX3YxLjBfKERyYWZ0KTo8c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+ PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDoxLjBpbjt0ZXh0LWluZGVudDot LjI1aW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzMnPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbCc+PHNwYW4gc3R5bGU9 J21zby1saXN0Oklnbm9yZSc+Jm1pZGRvdDs8c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGltZXMg TmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwv c3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5SZWZpbmVtZW50IG9mIG5hbWVzcGFjZXMgYW5k IHNjaGVtYSBsb2NhdGlvbnMgZm9yIGJldHRlciBlZmZlY3RpdmVuZXNzIGFuZCBmbGV4aWJpbGl0 eSBnb2luZyBmb3J3YXJkLjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0OjEuMGluO3RleHQtaW5kZW50Oi0uMjVpbjttc28t bGlzdDpsMSBsZXZlbDEgbGZvMyc+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sJz48c3BhbiBzdHlsZT0nbXNvLWxpc3Q6 SWdub3JlJz4mbWlkZG90OzxzcGFuIHN0eWxlPSdmb250OjcuMHB0ICJUaW1lcyBOZXcgUm9tYW4i Jz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bh bj48L3NwYW4+PCFbZW5kaWZdPk5vcm1hbGl6ZWQgYWxsIGNvbnRlbnQgYWNjb3JkaW5nIHRvIGFu IGVzdGFibGlzaGVkIHNldCBvZiBuYW1pbmcgY29udmVudGlvbnMuPHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+PG86cD48L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6MS4waW47 dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwxIGxldmVsMSBsZm8zJz48IVtpZiAhc3VwcG9y dExpc3RzXT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTeW1ib2wn PjxzcGFuIHN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPiZtaWRkb3Q7PHNwYW4gc3R5bGU9J2ZvbnQ6 Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyA8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+RnVsbHkgYW5ub3RhdGVk IGFsbCBsYW5ndWFnZSBpdGVtcyAodHlwZXMsIGF0dHJpYnV0ZXMsIGVsZW1lbnRzLCBldGMuKS48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdt YXJnaW4tbGVmdDoxLjBpbjt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxm bzMnPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OlN5bWJvbCc+PHNwYW4gc3R5bGU9J21zby1saXN0Oklnbm9yZSc+Jm1pZGRvdDs8 c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlm XT5Nb3ZlZCBzZXZlcmFsIGNvbW1vbmx5IGxldmVyYWdlZCB0eXBlcyBvdXQgb2YgdGhlIGNvcmUg c2NoZW1hIGFuZCBpbnRvIGNvbW1vbl90eXBlcy48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDoxLjBpbjt0ZXh0LWluZGVu dDotLjI1aW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzMnPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbCc+PHNwYW4gc3R5 bGU9J21zby1saXN0Oklnbm9yZSc+Jm1pZGRvdDs8c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGlt ZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5BY2hpZXZlZCBmdWxsIHR5cGluZyBvZiBl bnRpcmUgc2NoZW1hIHN0cnVjdHVyZSBzdWNoIHRoYXQgYWxsIGF0dHJpYnV0ZXMgYW5kIGVsZW1l bnRzIGFyZSBkZWZpbml0aXZlbHkgdHlwZWQuPHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+PG86cD48L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6MS4waW47dGV4dC1pbmRlbnQ6 LS4yNWluO21zby1saXN0OmwxIGxldmVsMSBsZm8zJz48IVtpZiAhc3VwcG9ydExpc3RzXT48c3Bh biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTeW1ib2wnPjxzcGFuIHN0eWxl PSdtc28tbGlzdDpJZ25vcmUnPiZtaWRkb3Q7PHNwYW4gc3R5bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVz IE5ldyBSb21hbiInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8 L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+Q2hhbmdlZCBhbGwgaWRlbnRpZmllcnMgZnJv bSBJRCBhbmQgSURSRUYgdHlwZXMgdG8gYmUgUU5hbWVzIGVuYWJsaW5nIGdsb2JhbGx5IHVuaXF1 ZSBpZGVudGlmaWVycyBhbmQgZmxleGliaWxpdHkgZm9yIGRvbWFpbi1zcGVjaWZpYyB1c2VycyBv ZiBDeWJPWCB0byBkZWZpbmUgdGhlaXIgb3duIGlkZW50aWZpZXIgc3ludGF4IGxvY2FsbHkuPHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIic+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFy Z2luLWxlZnQ6MS4waW47dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwxIGxldmVsMSBsZm8z Jz48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTpTeW1ib2wnPjxzcGFuIHN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPiZtaWRkb3Q7PHNw YW4gc3R5bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+ UmVvcmRlcmVkIGF0dHJpYnV0ZXMgYW5kIGVsZW1lbnRzIGluIG51bWVyb3VzIHR5cGVzIHRvIGJl dHRlciByZWZsZWN0IGNvbW1vbiB1c2FnZSBhbmQgcHJpb3JpdHkuPHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+PG86cD48L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6MS4waW47 dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwxIGxldmVsMSBsZm8zJz48IVtpZiAhc3VwcG9y dExpc3RzXT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTeW1ib2wn PjxzcGFuIHN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPiZtaWRkb3Q7PHNwYW4gc3R5bGU9J2ZvbnQ6 Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyA8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+QWRkZWQgbWFqb3JfdmVy c2lvbiBhbmQgbWlub3JfdmVyc2lvbiBhdHRyaWJ1dGVzIGZvciBjb3JlIHNjaGVtYS48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Jz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4t bGVmdDoxLjBpbjt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzMnPjwh W2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OlN5bWJvbCc+PHNwYW4gc3R5bGU9J21zby1saXN0Oklnbm9yZSc+Jm1pZGRvdDs8c3BhbiBz dHlsZT0nZm9udDo3LjBwdCAiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5BZGRl ZCBjYXBhYmlsaXR5IHRvIGNoYXJhY3Rlcml6ZSBzb3VyY2Ugb2Ygb3ZlcmFsbCBvYnNlcnZhYmxl IHBhY2thZ2UgZGF0YSBhbmQgZm9yIGluZGl2aWR1YWwgb2JzZXJ2YWJsZXMuPHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+PG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6 MS4waW47dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwxIGxldmVsMSBsZm8zJz48IVtpZiAh c3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpT eW1ib2wnPjxzcGFuIHN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPiZtaWRkb3Q7PHNwYW4gc3R5bGU9 J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+TW9kaWZpZWQg dGhlIGxvZ2ljYWwgY29tcG9zaXRpb24gc3RydWN0dXJlIHN1Y2ggdGhhdCBhbnkgc3VjaCBjb21w b3NpdGlvbnMgYXJlIG5vdyBjb250YWluZWQgd2l0aGluIGEgT2JzZXJ2YWJsZV9Db21wb3NpdGlv biBlbGVtZW50IHByb3ZpZGluZyBpbXByb3ZlZCBzaW1wbGljaXR5IGFuZCBtb2R1bGFyaXR5Ljxz cGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiInPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21h cmdpbi1sZWZ0OjEuMGluO3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMSBsZXZlbDEgbGZv Myc+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6U3ltYm9sJz48c3BhbiBzdHlsZT0nbXNvLWxpc3Q6SWdub3JlJz4mbWlkZG90Ozxz cGFuIHN0eWxlPSdmb250OjcuMHB0ICJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZd PlJlbW92ZWQgdGhlIERlbHRhIGVsZW1lbnQgZnJvbSBPYnNlcnZhYmxlVHlwZSBhbmQgcmVsb2Nh dGVkIHRoZSBhcHByb3ByaWF0ZSBwb3J0aW9ucyAoQ2hhbmdlLCBUcmVuZCwgYW5kIEZyZXF1ZW5j eSkgdG8gYXBwcm9wcmlhdGUgbG9jYXRpb25zIHVuZGVyIFN0YXRlZnVsX01lYXN1cmUgYW5kIEV2 ZW50LjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiInPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9J21hcmdpbi1sZWZ0OjEuMGluO3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMSBsZXZl bDEgbGZvMyc+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6U3ltYm9sJz48c3BhbiBzdHlsZT0nbXNvLWxpc3Q6SWdub3JlJz4mbWlk ZG90OzxzcGFuIHN0eWxlPSdmb250OjcuMHB0ICJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFb ZW5kaWZdPkFkZGVkIGEgRG9tYWluX1NwZWNpZmljX09iamVjdF9BdHRyaWJ1dGVzIGZpZWxkIHRv IE9iamVjdCB1dGlsaXppbmcgYW4gYWJzdHJhY3QgdHlwZSB0aGF0IHdpbGwgYWxsb3cgZG9tYWlu LXNwZWNpZmljIHVzZSBjYXNlcyB0byBhZGQgaW4gdGhlaXIgb3duIGRvbWFpbi1zcGVjaWZpYyBh dHRyaWJ1dGVzIGZvciBPYmplY3RzLjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0OjEuMGluO3RleHQtaW5kZW50Oi0uMjVp bjttc28tbGlzdDpsMSBsZXZlbDEgbGZvMyc+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sJz48c3BhbiBzdHlsZT0nbXNv LWxpc3Q6SWdub3JlJz4mbWlkZG90OzxzcGFuIHN0eWxlPSdmb250OjcuMHB0ICJUaW1lcyBOZXcg Um9tYW4iJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFu Pjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPkFkZGVkIGEgVG9vbC1TcGVjaWZpY19EYXRhIGZpZWxk IHRvIFRvb2xJbmZvcm1hdGlvblR5cGUgdXRpbGl6aW5nIGFuIGFic3RyYWN0IHR5cGUgdGhhdCB3 aWxsIGFsbG93IGFkZGl0aW9uIG9mIHRvb2wtc3BlY2lmaWMgZGF0YS48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz48bzpwPjwv bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDoxLjBp bjt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzMnPjwhW2lmICFzdXBw b3J0TGlzdHNdPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJv bCc+PHNwYW4gc3R5bGU9J21zby1saXN0Oklnbm9yZSc+Jm1pZGRvdDs8c3BhbiBzdHlsZT0nZm9u dDo3LjBwdCAiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5BZGRlZCBhbiBJbmRp Y2F0b3JzIGZpZWxkIHRvIE1lYXN1cmVTb3VyY2VUeXBlIHV0aWxpemluZyBhbiBhYnN0cmFjdCB0 eXBlIHRoYXQgd2lsbCBhbGxvdyBjaGFyYWN0ZXJpemluZyBkaWZmZXJpbmcgZm9ybWF0cyBvciBz dGFuZGFyZHMgb2YgaW5kaWNhdG9ycyB0aGF0IG1heSBoYXZlIGxlZCB0byB0aGUgaWRlbnRpZmlj YXRpb24gb2YgdGhlIG9ic2VydmFibGUgZGF0YS48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDoxLjBpbjt0ZXh0LWluZGVu dDotLjI1aW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzMnPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbCc+PHNwYW4gc3R5 bGU9J21zby1saXN0Oklnbm9yZSc+Jm1pZGRvdDs8c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGlt ZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5FbmhhbmNlZCB0aGUgSGFzaCBzdHJ1Y3R1 cmUgdG8gY2FwdHVyZSBmdWxsIGZ1enp5IGhhc2hlcyBpbiBhZGRpdGlvbiB0byBzaW1wbGUgaGFz aGVzPHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIic+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHls ZT0nbWFyZ2luLWxlZnQ6MS4waW47dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwxIGxldmVs MSBsZm8zJz48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTpTeW1ib2wnPjxzcGFuIHN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPiZtaWRk b3Q7PHNwYW4gc3R5bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtl bmRpZl0+QWRkZWQgYSBuZXcgRXh0cmFjdGVkRmVhdHVyZXNUeXBlIHRoYXQgY2FuIGJlIHVzZWQg dG8gYWRvcm4gZGlmZmVyaW5nIG9iamVjdHMgKGUuZy4sIGZpbGVzLCBtZW1vcnksIGV0Yy4pIHRv IGNhcHR1cmUgZXh0cmFjdGVkIHN0cmluZ3MsIGltcG9ydHMsIGZ1bmN0aW9ucyBhbmQgY29kZSBz bmlwcGV0czxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiInPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwg c3R5bGU9J21hcmdpbi1sZWZ0OjEuMGluO3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMSBs ZXZlbDEgbGZvMyc+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sJz48c3BhbiBzdHlsZT0nbXNvLWxpc3Q6SWdub3JlJz4m bWlkZG90OzxzcGFuIHN0eWxlPSdmb250OjcuMHB0ICJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48L3NwYW4+ PCFbZW5kaWZdPkFkZGVkIGEgQnl0ZVJ1bnNUeXBlIHRvIGVuYWJsZSBjYXB0dXJlIG9mIGJ5dGUg cnVucyB3aXRoaW4gdmFyaW91cyBvYmplY3RzLjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0OjEuMGluO3RleHQtaW5kZW50 Oi0uMjVpbjttc28tbGlzdDpsMSBsZXZlbDEgbGZvMyc+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sJz48c3BhbiBzdHls ZT0nbXNvLWxpc3Q6SWdub3JlJz4mbWlkZG90OzxzcGFuIHN0eWxlPSdmb250OjcuMHB0ICJUaW1l cyBOZXcgUm9tYW4iJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg PC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPkFkZGVkIG9iamVjdF9yZWZlcmVuY2UgYXR0 cmlidXRlIHRvIERlZmluZWRPYmplY3RUeXBlIHRvIGJldHRlciBzdXBwb3J0IHJlZmVyZW5jaW5n IG9mIGluZGVwZW5kZW50bHkgZGVmaW5lZCBPYmplY3RzIGZyb20gd2l0aGluIGFub3RoZXIgT2Jq ZWN0IGRlZmluaXRpb24uPHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6MS4waW47dGV4dC1pbmRlbnQ6LS4yNWluO21zby1s aXN0OmwxIGxldmVsMSBsZm8zJz48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTeW1ib2wnPjxzcGFuIHN0eWxlPSdtc28tbGlzdDpJ Z25vcmUnPiZtaWRkb3Q7PHNwYW4gc3R5bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiIn PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PC9zcGFu Pjwvc3Bhbj48IVtlbmRpZl0+QWRkZWQgYSBnZW5lcmljIERhdGFTZWdtZW50VHlwZSB0byBwcm92 aWRlIGEgcmVsYXRpdmVseSBhYnN0cmFjdCB3YXkgb2YgY2hhcmFjdGVyaXppbmcgZGF0YSBzZWdt ZW50cyB0aGF0IG1heSBiZSB3cml0dGVuL3JlYWQvdHJhbnNtaXR0ZWQgb3Igb3RoZXJ3aXNlIHV0 aWxpemVkIGluIGFjdGlvbnMgb3IgZGVmaW5lZCBpbiBvYmplY3RzLjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD48ZGl2IHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48cCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW47dGV4dC1pbmRlbnQ6LS4yNWluJz48c3BhbiBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTeW1ib2wnPiZtaWRkb3Q7PC9zcGFu PjxzcGFuIHN0eWxlPSdmb250LXNpemU6Ny4wcHQnPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPWFwcGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8 L3NwYW4+PC9zcGFuPkFkZGVkIHNldmVyYWwgbmV3IGRlZmluZWQgb2JqZWN0IHNjaGVtYXMgKEFQ SSwgQ29kZSwgRGV2aWNlLCBETlNfUmVjb3JkLCBOZXR3b3JrX0Zsb3csIE5ldHdvcmtfUGFja2V0 LCBOZXR3b3JrX1JvdXRlX0VudHJ5LCBOZXR3b3JrX1N1Ym5ldCwgVW5peF9OZXR3b3JrX1JvdXRl X0VudHJ5KSBpbmNsdWRpbmcgYW4gaW5pdGlhbCBzZXQgb2YgbmV0d29yay1jZW50cmljIGRlZmlu ZWQgb2JqZWN0cy48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdCc+PG86cD48L286cD48L3Nw YW4+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6MS4waW47 dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm82Jz48IVtpZiAhc3VwcG9y dExpc3RzXT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTeW1ib2wn PjxzcGFuIHN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPiZtaWRkb3Q7PHNwYW4gc3R5bGU9J2ZvbnQ6 Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyA8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+TW9kaWZpZWQgZXZlcnkg ZGVmaW5lZCBvYmplY3Qgc2NoZW1hIHdpdGggYWRkZWQgYW5ub3RhdGlvbnMgYXMgd2VsbCBhcyBt aW5vciBhbmQgaW4gc29tZSBjYXNlcyBzdWJzdGFudGl2ZSBjaGFuZ2VzIHRvIGZpeCBlcnJvcnMs IGltcHJvdmUgY29uc2lzdGVuY3kgYW5kIGFsaWdubWVudCB3aXRoIGV4aXN0aW5nIG5vcm1hdGl2 ZSByZWZlcmVuY2VzLCBhbmQgdG8gaW1wcm92ZSBleHByZXNzaXZlbmVzcyBpbiBzdXBwb3J0IG9m IHRoZSB0YXJnZXRlZCB1c2UgY2FzZXMuPHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+PG86cD48L286cD48L3NwYW4+PC9wPjxk aXYgc3R5bGU9J21hcmdpbi1sZWZ0Oi4yNWluJz48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21h cmdpbi1sZWZ0Oi41aW4nPkRldGFpbGVkIGNoYW5nZXMgZnJvbSBDeWJPWF92MC43IHRvIEN5Yk9Y X3YxLjBfKERyYWZ0KTo8c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPlRoZSBsZXZlbCBvZiBj aGFuZ2VzIHdpdGhpbiB2MS4wIChEcmFmdCkgaW4gdGhlIGNvcmUgc2NoZW1hLCBjb21tb25fdHlw ZXMgYW5kIHRoZSBkZWZpbmVkIG9iamVjdCBzY2hlbWFzIGlzIHRvbyBncmVhdCB0byBsaXN0IGV2 ZXJ5IGNoYW5nZSBpbiB0aGVzZSByZWxlYXNlIG5vdGVzLiBEZXRhaWxlZCBkaWZmZXJlbmNlIHJl cG9ydHMgYXJlIGF2YWlsYWJsZSBmb3IgZWFjaCBpbmRpdmlkdWFsIHNjaGVtYSBhdDo8c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Jz48YSBocmVmPSJodHRwOi8vY3lib3gubWl0cmUub3JnL1hNTFNjaGVtYS9yZWxlYXNlX25vdGVz L2N5Ym94X3YxLjAoZHJhZnQpX2RpZmZfcmVwb3J0cy56aXAiPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTIuMHB0O2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiInPmh0dHA6Ly9j eWJveC5taXRyZS5vcmcvWE1MU2NoZW1hL3JlbGVhc2Vfbm90ZXMvY3lib3hfdjEuMChkcmFmdClf ZGlmZl9yZXBvcnRzLnppcDwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2Pjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwg c3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD48L2Rpdj48ZGl2IHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48cCBjbGFzcz1Nc29Ob3Jt YWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08L3NwYW4+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+ PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXYgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4n PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xv cjojMUY0OTdEJz5TZWFuIEJhcm51bTwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PC9kaXY+PGRpdiBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PHAgY2xhc3M9TXNvTm9ybWFs IHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkN5YmVyIFNl Y3VyaXR5IFByaW5jaXBhbDwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9k aXY+PGRpdiBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSdtYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlRoZSBNSVRSRSBDb3Jw b3JhdGlvbjwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdiBz dHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4t bGVmdDouNWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkVtYWlsOjxzcGFuIGNsYXNzPWFwcGxl LWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnNiYXJudW1AbWl0 cmUub3JnIj5zYmFybnVtQG1pdHJlLm9yZzwvYT48L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+PG86cD48L286cD48 L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVm dDouNWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PHAgY2xh c3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEzLjVwdDtmb250LWZhbWlseToiSGVsdmV0aWNhIiwic2Fucy1zZXJpZiInPl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPm1pbGUgbWFpbGluZyBs aXN0PGJyPjxhIGhyZWY9Im1haWx0bzptaWxlQGlldGYub3JnIj5taWxlQGlldGYub3JnPC9hPjxi cj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21pbGUiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWlsZTwvYT48bzpwPjwvbzpwPjwv c3Bhbj48L3A+PC9kaXY+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVm dDouNWluJz48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48L2Rpdj48L2JvZHk+PC9odG1sPg== ------_=_NextPart_001_01CD1C4C.A5E487EB-- From kathleen.moriarty@emc.com Tue Apr 17 00:48:15 2012 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 F2E5221F849A; Tue, 17 Apr 2012 00:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.432 X-Spam-Level: X-Spam-Status: No, score=-10.432 tagged_above=-999 required=5 tests=[AWL=0.167, 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 awkiAScuy4v2; Tue, 17 Apr 2012 00:48:10 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 63B6D21F8498; Tue, 17 Apr 2012 00:48:09 -0700 (PDT) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q3H7m6mS018734 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Apr 2012 03:48:06 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.130]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Tue, 17 Apr 2012 03:47:51 -0400 Received: from mxhub14.corp.emc.com (mxhub14.corp.emc.com [128.222.70.235]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q3H7lo7u019192; Tue, 17 Apr 2012 03:47:50 -0400 Received: from mx06a.corp.emc.com ([169.254.1.106]) by mxhub14.corp.emc.com ([128.222.70.235]) with mapi; Tue, 17 Apr 2012 03:47:49 -0400 From: To: , Date: Tue, 17 Apr 2012 03:47:49 -0400 Thread-Topic: [mile] CybOX v1.0 (Draft) is now released and live on the website Thread-Index: Ac0cIooXr4s/7oQ8SPiJ2GBnx2iBMgAStEiR Message-ID: References: <7F48813B48558A4BB5CB7BB714E5B5A91706E3@IMCMBX03.MITRE.ORG>, <870A23D4-BA94-4431-B613-F3D7734B8DB5@c3isecurity.com> In-Reply-To: <870A23D4-BA94-4431-B613-F3D7734B8DB5@c3isecurity.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: mile@ietf.org, dallendoug@gmail.com, sacm@ietf.org, m-terada@ipa.go.jp Subject: Re: [mile] CybOX v1.0 (Draft) is now released and live on the website 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, 17 Apr 2012 07:48:15 -0000 Thank you for sharing the publication of the CybOX specification to the MIT= RE site, Sean. =20 As an FYI to those who are not familiar with IODEF, I just want to clarify = that incident descriptions via IODEF already can include network-centric ob= jects (NetFlow data was specifically considered for this representation) in= the IODEF flow class. If there is something missing, please post to the M= ILE mailing list and we will track that for possible revision in IODEF to t= he guidance document. If CybOX gets submitted to the IETF or another standards body, then we will= be able to consider the intersection and how CybOX might be incorporated i= n IODEF.=20 Thank you, Kathleen ________________________________________ From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of Luis Nunez= [lnunez@c3isecurity.com] Sent: Monday, April 16, 2012 6:44 PM To: Barnum, Sean D. Cc: idxwg@nicwg.org; mile@ietf.org; Doug Wilson (dallendoug@gmail.com); sac= m@ietf.org; IPA-Masato Terada (m-terada@ipa.go.jp) Subject: Re: [mile] CybOX v1.0 (Draft) is now released and live on the web= site I like the inclusion of the network-centric objects. IPFIX (netflow) will= add an additional perspective from an incident information sharing standpo= int. -ln On Apr 16, 2012, at 4:04 PM, Barnum, Sean D. wrote: Hey everyone, I just wanted to let you all know that CybOX v1.0 (Draft) content is now li= ve on the website. http://cybox.mitre.org The release notes are provided inline below. The key items of note are: =95 The release of two formal specifications for the CybOX language = (one for the core language and one for the defined objects) =95 The XML Schema has gone through extensive improvements for expre= ssiveness, clarity, consistency, efficiency, alignment to existing normativ= e references and documentation. =95 This release includes an initial set of language utilities: a dr= aft Snort -> CybOX transform, a draft OpenIOC -> CybOX transform, and a set= of Python bindings for the CybOX language. =95 The website now includes a small set of content examples. This s= et will grow going forward. This release involved a lot of hard work from a diverse group of people. Th= ank you all for your contributions and effort. We could not have done it wi= thout you. We look forward to everyone=92s feedback and collaboration as we continue t= o improve and mature the CybOX language. Sean Barnum CybOX v1.0 (Draft) Release Notes The Version 1.0 (Draft) release of Cyber Observable eXpression (CybOX=99) i= s intended as a draft release of an initial major version of the CybOX Lang= uage that could be utilized for practical operational use and integration i= nto other standards efforts. This release consists of three primary compone= nts: a pair of formal language specifications for the core language content= and defined objects content, a set of language implementation XML schemas = (core, common_types, and ~70 defined object schemas), and a small initial s= et of language utilities including an initial draft Snort->CybOX transform,= an initial draft OpenIOC->CybOX transform and a set of CybOX language Pyth= on bindings. Recognizing that this is the first time that the formal langua= ge specifications will be available for review and as such will likely gene= rate feedback from new stakeholders, this initial major version is being re= leased as a =93draft=94 v1.0 with the expectation of cycles of new feedback= and revision before a =93final=94 v1.0 is released. The CybOX v1.0 (Draft) XML schemas include a significant number of changes = from v0.7 to improve: =95 Clarity, documentation, and descriptive formality for reference a= nd implementation by other standards and users. =95 Consistency, simplicity, and efficiency. =95 Alignment (as appropriate) to existing normative references. =95 Expressiveness of the schema to better support the broad set of u= se cases it targets (malware characterization, indicator and incident data = sharing, event management, etc.) including the addition of an initial set o= f network-related defined objects. Summary of changes from CybOX_v0.7 to CybOX_v1.0_(Draft): * Refinement of namespaces and schema locations for better effectiveness= and flexibility going forward. * Normalized all content according to an established set of naming conve= ntions. * Fully annotated all language items (types, attributes, elements, etc.)= . * Moved several commonly leveraged types out of the core schema and into= common_types. * Achieved full typing of entire schema structure such that all attribut= es and elements are definitively typed. * Changed all identifiers from ID and IDREF types to be QNames enabling = globally unique identifiers and flexibility for domain-specific users of Cy= bOX to define their own identifier syntax locally. * Reordered attributes and elements in numerous types to better reflect = common usage and priority. * Added major_version and minor_version attributes for core schema. * Added capability to characterize source of overall observable package = data and for individual observables. * Modified the logical composition structure such that any such composit= ions are now contained within a Observable_Composition element providing im= proved simplicity and modularity. * Removed the Delta element from ObservableType and relocated the approp= riate portions (Change, Trend, and Frequency) to appropriate locations unde= r Stateful_Measure and Event. * Added a Domain_Specific_Object_Attributes field to Object utilizing an= abstract type that will allow domain-specific use cases to add in their ow= n domain-specific attributes for Objects. * Added a Tool-Specific_Data field to ToolInformationType utilizing an a= bstract type that will allow addition of tool-specific data. * Added an Indicators field to MeasureSourceType utilizing an abstract t= ype that will allow characterizing differing formats or standards of indica= tors that may have led to the identification of the observable data. * Enhanced the Hash structure to capture full fuzzy hashes in addition t= o simple hashes * Added a new ExtractedFeaturesType that can be used to adorn differing = objects (e.g., files, memory, etc.) to capture extracted strings, imports, = functions and code snippets * Added a ByteRunsType to enable capture of byte runs within various obj= ects. * Added object_reference attribute to DefinedObjectType to better suppor= t referencing of independently defined Objects from within another Object d= efinition. * Added a generic DataSegmentType to provide a relatively abstract way o= f characterizing data segments that may be written/read/transmitted or othe= rwise utilized in actions or defined in objects. =95 Added several new defined object schemas (API, Code, Device, DNS= _Record, Network_Flow, Network_Packet, Network_Route_Entry, Network_Subnet,= Unix_Network_Route_Entry) including an initial set of network-centric defi= ned objects. * Modified every defined object schema with added annotations as well as= minor and in some cases substantive changes to fix errors, improve consist= ency and alignment with existing normative references, and to improve expre= ssiveness in support of the targeted use cases. Detailed changes from CybOX_v0.7 to CybOX_v1.0_(Draft): The level of changes within v1.0 (Draft) in the core schema, common_types a= nd the defined object schemas is too great to list every change in these re= lease notes. Detailed difference reports are available for each individual = schema at:http://cybox.mitre.org/XMLSchema/release_notes/cybox_v1.0(draft)_= diff_reports.zip =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Sean Barnum Cyber Security Principal The MITRE Corporation Email: sbarnum@mitre.org _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile From michael.hammer@yaanatech.com Tue Apr 17 06:17:49 2012 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 1718821F857D; Tue, 17 Apr 2012 06:17:49 -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=[AWL=-0.001, 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 VRWeXZnIpaJA; Tue, 17 Apr 2012 06:17:43 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id AF53221F841D; Tue, 17 Apr 2012 06:17:43 -0700 (PDT) Received: from EX2K10MB1.corp.yaanatech.com ([fe80::5568:c31d:f64a:f66a]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Tue, 17 Apr 2012 06:17:43 -0700 From: Michael Hammer To: "sbarnum@mitre.org" , "osantos@cisco.com" , "Thomas.Millar@hq.dhs.gov" , "lnunez@c3isecurity.com" Thread-Topic: [mile] [sacm] CybOX v1.0 (Draft) is now released and live onthe website Thread-Index: AQHNHFhQtpFrr+nGFkWqCWY68NIgupae/ygA Date: Tue, 17 Apr 2012 13:17:42 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB389FC37@EX2K10MB1.corp.yaanatech.com> References: <7F48813B48558A4BB5CB7BB714E5B5A9171B16@IMCMBX03.MITRE.ORG> <69CE2DCD9DAC3D48B830E0723141170B02A39BD2@ZAU1UG-0308.DHSNET.DS1.DHS> <953A2E460DBE7C43AC13E30B87C5B4FF080A1C09@XMB-RCD-106.cisco.com> <7F48813B48558A4BB5CB7BB714E5B5A9171BA1@IMCMBX03.MITRE.ORG> In-Reply-To: <7F48813B48558A4BB5CB7BB714E5B5A9171BA1@IMCMBX03.MITRE.ORG> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.88.19] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0008_01CD1C7A.EFE93B80" MIME-Version: 1.0 Cc: "idxwg@nicwg.org" , "mile@ietf.org" , "dallendoug@gmail.com" , "sacm@ietf.org" , "m-terada@ipa.go.jp" Subject: Re: [mile] [sacm] CybOX v1.0 (Draft) is now released and live onthe website 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, 17 Apr 2012 13:17:49 -0000 ------=_NextPart_000_0008_01CD1C7A.EFE93B80 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0009_01CD1C7A.EFE93B80" ------=_NextPart_001_0009_01CD1C7A.EFE93B80 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Sean, =20 Does the overlap between the various objects present a problem? =20 If there are one or more objects that could carry the same data, then = human nature means that probability-wise someone will choose data flow = instead of Netflow. That is the underlying principle in Murphy=E2=80=99s Law, where you try = to design it so that there is only one way to do it, and thus private = Murphy won=E2=80=99t do it the =E2=80=9Cwrong=E2=80=9D way. =20 Just wondering if these should be mutually exclusive sets. And designed = as such. Might improve interoperability. (And avoid discussions like this in = future.) J =20 Mike =20 =20 From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of = Barnum, Sean D. Sent: Tuesday, April 17, 2012 1:10 AM To: Omar Santos (osantos); Millar, Thomas; lnunez@c3isecurity.com Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; = m-terada@ipa.go.jp Subject: Re: [mile] [sacm] CybOX v1.0 (Draft) is now released and live = onthe website =20 =E2=80=9Cupper layer=E2=80=9D? Yes, as in higher abstraction. Just =E2=80=9Cprotocols=E2=80=9D? No. =20 You guys have been looking at this through the lens of network flow = which if fine for thinking about that perspective but it is important to = also realize that the EventTypeEnum and its =E2=80=9CData Flow=E2=80=9D = value go far beyond network-related scope. It is about a lot of other types of potential data flows (as I just = outlined in a response to Tom) that have nothing to do with network = flow. =20 Thanks for your response though. This is the kind of discussions that we = hope to have a lot more of among the various supported communities. =20 =20 BTW, you may have noticed that the Network_Flow object within CybOX v1.0 = (Draft) supports expression of netflow within several of the most common = formats including Netflow9 (as well as IPFIX as Luis pointed out, = Netflow5 and SiLK as well as bi-directional flow in YAF). The common = 5-tuple or 7-tuple (you describe) (in our case it is an 8-tuple as we = broke the router interface out into both ingress and egress J) shared by = pretty much all of the netflow approaches has been broken out into a = shared Network_Flow_Label structure. The various context-dependent = portions of the independent approaches are then captured within optional = structures dedicated to each of them. We hope that eventually the = community can work to come together towards a single overall common = expressive structure for netflow that meets the needs of all. We hope = that CybOX and its use can even help that sort of maturation and = normalization. But since no such universal structure exists today, we = decided to enable optional expression of the most common individual = formats within a single netflow object to serve the large majority of = relevant users, maintain flexibility and enable discussions and analysis = of netflow within a common package. We look forward to continuing discussions with the community to validate = or invalidate this approach and to refine and mature going forward. =20 Sean=20 =20 From: Omar Santos (osantos) [mailto:osantos@cisco.com]=20 Sent: Monday, April 16, 2012 11:57 PM To: Millar, Thomas; Barnum, Sean D.; lnunez@c3isecurity.com Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; = m-terada@ipa.go.jp Subject: RE: [sacm] [mile] CybOX v1.0 (Draft) is now released and live = onthe website =20 I believe that what Sean is saying is that =E2=80=9Cdata flow=E2=80=9D = is just a value that is meant for upper layer protocols. But, you have a = good point. Traditionally, a =E2=80=9Cflow=E2=80=9D in = =E2=80=9CNetflow=E2=80=9D is based on a set of 5 and up to 7 IP packet = attributes: =20 - IP source address - IP destination address - Source port - Destination port - Layer 3 protocol type - Class of Service - Router or switch interface =20 Although, there is a lot more support with Netflow version 9: http://www.cisco.com/en/US/technologies/tk648/tk362/technologies_white_pa= per09186a00800a3db9_ps6601_Products_White_Paper.html =20 =20 =20 Regards, Omar=20 =20 From: Millar, Thomas [mailto:Thomas.Millar@hq.dhs.gov]=20 Sent: Monday, April 16, 2012 11:46 PM To: sbarnum@mitre.org; Omar Santos (osantos); lnunez@c3isecurity.com Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; = m-terada@ipa.go.jp Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live = onthe website =20 If "data flow" is a euphemism for "netflow" is there any reason not to = call it that? Tom Millar=20 http://www.us-cert.gov/=20 ------------------=20 Missit me Rubus fruticosus:=20 202 631 1915=20 =20 From: Barnum, Sean D. [mailto:sbarnum@mitre.org]=20 Sent: Monday, April 16, 2012 11:29 PM To: Omar Santos (osantos) ; Luis Nunez = =20 Cc: idxwg@nicwg.org ; mile@ietf.org ; = dallendoug@gmail.com ; sacm@ietf.org = ; m-terada@ipa.go.jp =20 Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live = onthe website=20 =20 Thanks Omar. =20 To answer your question, first let me point out to other readers that = the two entries that Omar is quoting here exist as values in an = enumeration called EventTypeEnum which as its name implies contains a = list of different labels for grouping types (or classes) of events to be = used as low-granularity buckets for characterizing and classifying = events. Other entries in this enumeration include things like =E2=80=9CFile Ops = (CRUD)=E2=80=9D, =E2=80=9CProcess Mgt=E2=80=9D, =E2=80=9CAuthorization = (ACL)=E2=80=9D, etc. =20 The =E2=80=9CPacket Traffic=E2=80=9D value is intended to characterize = events dealing with network packet traffic as its name implies. The =E2=80=9CData Flow=E2=80=9D value is intended to characterize events = dealing with forms of data flow at a higher level of abstraction than = just packet traffic. The relationship between these two values could be = viewed as =E2=80=9CPacket Traffic=E2=80=9D being a more detailed form of = =E2=80=9CData Flow=E2=80=9D just as the values =E2=80=9CApp Layer = Traffic=E2=80=9D and =E2=80=9CHTTP Layer Traffic=E2=80=9D, also in this = enumeration, could be other levels in this same abstraction stack. The idea behind the varying levels of abstraction is to leave buckets = large enough to capture a wide variety of potential event types (e.g. = data flow events other than obvious things like packet traffic) but also = enable the use of smaller more specific buckets when they are = appropriate and commonly used. =20 Does this make sense?=20 =20 sean =20 From: Omar Santos (osantos) [mailto:osantos@cisco.com]=20 Sent: Monday, April 16, 2012 8:17 PM To: Luis Nunez; Barnum, Sean D. Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; = m-terada@ipa.go.jp Subject: RE: [sacm] [mile] CybOX v1.0 (Draft) is now released and live = onthe website =20 I echo Luis=E2=80=99 comments. It is good to see the inclusion of = network objects. Quick question to the team related to your netflow = comment. =20 I am looking at: http://cybox.mitre.org/XMLSchema/cybox_core_v1.0%28draft%29.xsd =20 =E2=80=A6 and it looks that we renamed it to =E2=80=9CData = Flow=E2=80=9D? =20 Specifies the class of events dealing with = data flow. =20 =20 What is the difference between that and =E2=80=9CPacket = Traffic=E2=80=9D? =20 Specifies the class of events dealing with packet = traffic. =20 =20 =20 =20 Regards, Omar Santos Incident Manager, PSIRT Security Research and Operations Cisco Systems, Inc. Email: os@cisco.com Phone: +1 919 392 8635 PGP Key: 0x3AF27EDC Cisco.com - http://www.cisco.com Cisco Security Advisories and Notices - http://www.cisco.com/go/psirt This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message. For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html =20 From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of = Luis Nunez Sent: Monday, April 16, 2012 6:44 PM To: Barnum, Sean D. Cc: idxwg@nicwg.org; mile@ietf.org; Doug Wilson (dallendoug@gmail.com); = sacm@ietf.org; IPA-Masato Terada (m-terada@ipa.go.jp) Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live = onthe website =20 I like the inclusion of the network-centric objects. IPFIX (netflow) = will add an additional perspective from an incident information sharing = standpoint. =20 =20 -ln =20 On Apr 16, 2012, at 4:04 PM, Barnum, Sean D. wrote: =20 Hey everyone, =20 I just wanted to let you all know that CybOX v1.0 (Draft) content is now = live on the website. http://cybox.mitre.org The release notes are provided inline below. The key items of note are: =C2=B7 The release of two formal specifications for the CybOX = language (one for the core language and one for the defined objects) =C2=B7 The XML Schema has gone through extensive improvements for = expressiveness, clarity, consistency, efficiency, alignment to existing = normative references and documentation. =C2=B7 This release includes an initial set of language = utilities: a draft Snort -> CybOX transform, a draft OpenIOC -> CybOX = transform, and a set of Python bindings for the CybOX language. =C2=B7 The website now includes a small set of content examples. = This set will grow going forward. This release involved a lot of hard work from a diverse group of people. = Thank you all for your contributions and effort. We could not have done = it without you. We look forward to everyone=E2=80=99s feedback and collaboration as we = continue to improve and mature the CybOX language. =20 Sean Barnum =20 =20 =20 CybOX v1.0 (Draft) Release Notes The Version 1.0 (Draft) release of Cyber Observable eXpression = (CybOX=E2=84=A2) is intended as a draft release of an initial major = version of the CybOX Language that could be utilized for practical = operational use and integration into other standards efforts. This = release consists of three primary components: a pair of formal language = specifications for the core language content and defined objects = content, a set of language implementation XML schemas (core, = common_types, and ~70 defined object schemas), and a small initial set = of language utilities including an initial draft Snort->CybOX transform, = an initial draft OpenIOC->CybOX transform and a set of CybOX language = Python bindings. Recognizing that this is the first time that the formal = language specifications will be available for review and as such will = likely generate feedback from new stakeholders, this initial major = version is being released as a =E2=80=9Cdraft=E2=80=9D v1.0 with the = expectation of cycles of new feedback and revision before a = =E2=80=9Cfinal=E2=80=9D v1.0 is released. The CybOX v1.0 (Draft) XML schemas include a significant number of = changes from v0.7 to improve: =C2=B7 Clarity, documentation, and descriptive formality for = reference and implementation by other standards and users. =C2=B7 Consistency, simplicity, and efficiency. =C2=B7 Alignment (as appropriate) to existing normative = references. =C2=B7 Expressiveness of the schema to better support the broad = set of use cases it targets (malware characterization, indicator and = incident data sharing, event management, etc.) including the addition of = an initial set of network-related defined objects. Summary of changes from CybOX_v0.7 to CybOX_v1.0_(Draft): =C2=B7 Refinement of namespaces and schema locations for better = effectiveness and flexibility going forward. =C2=B7 Normalized all content according to an established set of = naming conventions. =C2=B7 Fully annotated all language items (types, attributes, = elements, etc.). =C2=B7 Moved several commonly leveraged types out of the core = schema and into common_types. =C2=B7 Achieved full typing of entire schema structure such that = all attributes and elements are definitively typed. =C2=B7 Changed all identifiers from ID and IDREF types to be = QNames enabling globally unique identifiers and flexibility for = domain-specific users of CybOX to define their own identifier syntax = locally. =C2=B7 Reordered attributes and elements in numerous types to = better reflect common usage and priority. =C2=B7 Added major_version and minor_version attributes for core = schema. =C2=B7 Added capability to characterize source of overall = observable package data and for individual observables. =C2=B7 Modified the logical composition structure such that any = such compositions are now contained within a Observable_Composition = element providing improved simplicity and modularity. =C2=B7 Removed the Delta element from ObservableType and relocated = the appropriate portions (Change, Trend, and Frequency) to appropriate = locations under Stateful_Measure and Event. =C2=B7 Added a Domain_Specific_Object_Attributes field to Object = utilizing an abstract type that will allow domain-specific use cases to = add in their own domain-specific attributes for Objects. =C2=B7 Added a Tool-Specific_Data field to ToolInformationType = utilizing an abstract type that will allow addition of tool-specific = data. =C2=B7 Added an Indicators field to MeasureSourceType utilizing an = abstract type that will allow characterizing differing formats or = standards of indicators that may have led to the identification of the = observable data. =C2=B7 Enhanced the Hash structure to capture full fuzzy hashes in = addition to simple hashes =C2=B7 Added a new ExtractedFeaturesType that can be used to adorn = differing objects (e.g., files, memory, etc.) to capture extracted = strings, imports, functions and code snippets =C2=B7 Added a ByteRunsType to enable capture of byte runs within = various objects. =C2=B7 Added object_reference attribute to DefinedObjectType to = better support referencing of independently defined Objects from within = another Object definition. =C2=B7 Added a generic DataSegmentType to provide a relatively = abstract way of characterizing data segments that may be = written/read/transmitted or otherwise utilized in actions or defined in = objects. =C2=B7 Added several new defined object schemas (API, Code, = Device, DNS_Record, Network_Flow, Network_Packet, Network_Route_Entry, = Network_Subnet, Unix_Network_Route_Entry) including an initial set of = network-centric defined objects. =C2=B7 Modified every defined object schema with added annotations = as well as minor and in some cases substantive changes to fix errors, = improve consistency and alignment with existing normative references, = and to improve expressiveness in support of the targeted use cases. Detailed changes from CybOX_v0.7 to CybOX_v1.0_(Draft): The level of changes within v1.0 (Draft) in the core schema, = common_types and the defined object schemas is too great to list every = change in these release notes. Detailed difference reports are available = for each individual schema at: = = http://cybox.mitre.org/XMLSchema/release_notes/cybox_v1.0(draft)_diff_rep= orts.zip =20 =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Sean Barnum Cyber Security Principal The MITRE Corporation Email: sbarnum@mitre.org =20 _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile =20 ------=_NextPart_001_0009_01CD1C7A.EFE93B80 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Sean,

 

Does the overlap between the various objects present a = problem?

 

If there are one or more objects that could carry the same data, then = human nature means that probability-wise someone will choose data flow = instead of Netflow.

That is the underlying principle in Murphy=E2=80=99s Law, where you = try to design it so that there is only one way to do it, and thus = private Murphy won=E2=80=99t do it the =E2=80=9Cwrong=E2=80=9D = way.

 

Just wondering if these should be mutually exclusive sets.=C2=A0 And = designed as such.

Might improve interoperability.=C2=A0 (And avoid discussions like = this in future.)=C2=A0 J

 

Mike

 

 

From:= = mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of = Barnum, Sean D.
Sent: Tuesday, April 17, 2012 1:10 = AM
To: Omar Santos (osantos); Millar, Thomas; = lnunez@c3isecurity.com
Cc: idxwg@nicwg.org; mile@ietf.org; = dallendoug@gmail.com; sacm@ietf.org; = m-terada@ipa.go.jp
Subject: Re: [mile] [sacm] CybOX v1.0 = (Draft) is now released and live onthe = website

 

=E2=80=9Cupper layer=E2=80=9D? Yes, as in higher = abstraction.

Just =E2=80=9Cprotocols=E2=80=9D? No.

 

You guys have been looking at this through the lens of network flow = which if fine for thinking about that perspective but it is important to = also realize that the EventTypeEnum and its =E2=80=9CData Flow=E2=80=9D = value go far beyond network-related scope.

It is about a lot of other types of potential data flows (as I just = outlined in a response to Tom) that have nothing to do with network = flow.

 

Thanks for your response though. This is the kind of discussions that = we hope to have a lot more of among the various supported = communities.

 

 

BTW, you may have noticed that the Network_Flow object within CybOX = v1.0 (Draft) supports expression of netflow within several of the most = common formats including Netflow9 (as well as IPFIX as Luis pointed out, = Netflow5 and SiLK as well as bi-directional flow in YAF). The common = 5-tuple or 7-tuple (you describe) (in our case it is an 8-tuple as we = broke the router interface out into both ingress and egress J) shared by pretty much all of the netflow approaches has been broken = out into a shared Network_Flow_Label structure. The various = context-dependent portions of the independent approaches are then = captured within optional structures dedicated to each of them. We hope = that eventually the community can work to come together towards a single = overall common expressive structure for netflow that meets the needs of = all. We hope that CybOX and its use can even help that sort of = maturation and normalization. But since no such universal structure = exists today, we decided to enable optional expression of the most = common individual formats within a single netflow object to serve the = large majority of relevant users, maintain flexibility and enable = discussions and analysis of netflow within a common = package.

We look forward to continuing discussions with the community to = validate or invalidate this approach and to refine and mature going = forward.

 

Sean

 

From:= = Omar Santos (osantos) [mailto:osantos@cisco.com]=
Sent: Monday, April 16, 2012 11:57 PM
To: Millar, = Thomas; Barnum, Sean D.; lnunez@c3isecurity.com
C= c: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; m-terada@ipa.go.jp
Subject:<= /b> RE: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe = website

 

I believe that what Sean is saying is that =E2=80=9Cdata = flow=E2=80=9D is just a value that is meant for upper layer protocols. = But, you have a good point. Traditionally, a =E2=80=9Cflow=E2=80=9D in = =E2=80=9CNetflow=E2=80=9D is based on a set of 5 and up to 7 IP packet = attributes:

 

- IP source address

- IP destination address

- Source port

- Destination port

- Layer 3 protocol type

- Class of Service

- Router or switch interface

 

Although, there is a lot more support with Netflow version = 9:

http://www.= cisco.com/en/US/technologies/tk648/tk362/technologies_white_paper09186a00= 800a3db9_ps6601_Products_White_Paper.html

 

 

 

Regards,

Omar

 

From:= = Millar, Thomas [mailto:Thomas.Millar@h= q.dhs.gov]
Sent: Monday, April 16, 2012 11:46 = PM
To: sbarnum@mitre.org; Omar Santos = (osantos); lnunez@c3isecurity.com
C= c: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; m-terada@ipa.go.jp
Subject:<= /b> Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe = website

 

If "data flow" is a euphemism for "netflow" is = there any reason not to call it that?

Tom Millar
http://www.us-cert.gov/ =
------------------
Missit me Rubus fruticosus:
202 631 1915 =

 

From<= /b>: = Barnum, Sean D. [mailto:sbarnum@mitre.org]=
Sent: Monday, April 16, 2012 11:29 PM
To: Omar = Santos (osantos) <osantos@cisco.com>; Luis Nunez = <lnunez@c3isecurity.com> =
Cc: idxwg@nicwg.org = <idxwg@nicwg.org>; mile@ietf.org <mile@ietf.org>; dallendoug@gmail.com <dallendoug@gmail.com>; sacm@ietf.org <sacm@ietf.org>; m-terada@ipa.go.jp <m-terada@ipa.go.jp> =
Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released = and live onthe website
 

Thanks Omar.

 

To answer your question, first let me point out to other readers that = the two entries that Omar is quoting here exist as values in an = enumeration called EventTypeEnum which as its name implies contains a = list of different labels for grouping types (or classes) of events to be = used as low-granularity buckets for characterizing and classifying = events.

Other entries in this enumeration include things like =E2=80=9CFile = Ops (CRUD)=E2=80=9D, =E2=80=9CProcess Mgt=E2=80=9D, = =E2=80=9CAuthorization (ACL)=E2=80=9D, etc.

 

The =E2=80=9CPacket Traffic=E2=80=9D value is intended to = characterize events dealing with network packet traffic as its name = implies.

The =E2=80=9CData Flow=E2=80=9D value is intended to characterize = events dealing with forms of data flow at a higher level of abstraction = than just packet traffic. The relationship between these two values = could be viewed as =E2=80=9CPacket Traffic=E2=80=9D being a more = detailed form of =E2=80=9CData Flow=E2=80=9D just as the values = =E2=80=9CApp Layer Traffic=E2=80=9D and =E2=80=9CHTTP Layer = Traffic=E2=80=9D, also in this enumeration, could be other levels in = this same abstraction stack.

The idea behind the varying levels of abstraction is to leave =  buckets large enough to capture a wide variety of potential event = types (e.g. data flow events other than obvious things like packet = traffic) but also enable the use of smaller more specific buckets when = they are appropriate and commonly used.

 

Does this make sense?

 

sean

 

From:= = Omar Santos (osantos) [mailto:osantos@cisco.com]=
Sent: Monday, April 16, 2012 8:17 PM
To: Luis = Nunez; Barnum, Sean D.
Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; m-terada@ipa.go.jp
Subject:<= /b> RE: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe = website

 

I echo Luis=E2=80=99 comments. It is good to see the inclusion of = network objects. Quick question to the team related to your netflow = comment.

 

I am looking at:

= http://cybox.mitre.org/XMLSchema/cybox_core_v1.0%28draft%29.xsd<= /o:p>

 

=E2=80=A6 and it looks that we renamed it to =E2=80=9CData = Flow=E2=80=9D?

 

<xs:enumeration = value=3D"Data Flow">

   = <xs:annotation>

        = <xs:documentation>Specifies the class of events dealing with data = flow.</xs:documentation>

   = </xs:annotation>

</xs:enumeration>

 

 

What is the difference between that and =E2=80=9CPacket = Traffic=E2=80=9D?

 

<xs:enumeration value=3D"Packet =
Traffic">
   =
<xs:annotation>
     =
<xs:documentation>Specifies the class of events dealing with =
packet traffic.</xs:documentation>
   =
</xs:annotation>
</xs:enumeration>

 

 

 

 

Regards,

Omar Santos
Incident Manager, = PSIRT
Security Research and Operations
Cisco Systems, = Inc.
Email: os@cisco.com
Phone: +1 919 392 = 8635
PGP Key: 0x3AF27EDC

Cisco.com - http://www.cisco.com
Cisco Security = Advisories and Notices - http://www.cisco.com/go/psirt<= br>
This email may contain confidential and privileged material for = the sole
use of the intended recipient. Any review, use, distribution = or
disclosure by others is strictly prohibited. If you are not the = intended
recipient (or authorized to receive for the recipient), = please contact
the sender by reply email and delete all copies of = this message.

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html=

 

From:= = sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.= org] On Behalf Of Luis Nunez
Sent: Monday, April = 16, 2012 6:44 PM
To: Barnum, Sean D.
Cc: idxwg@nicwg.org; mile@ietf.org; Doug Wilson (dallendoug@gmail.com); sacm@ietf.org; IPA-Masato Terada (m-terada@ipa.go.jp)
Subject:= Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe = website

 

I like the inclusion of the network-centric = objects.  IPFIX (netflow)  will add an additional perspective = from an incident information sharing standpoint. =  

 

-ln

 

On Apr 16, 2012, at 4:04 = PM, Barnum, Sean D. wrote:

 

Hey = everyone,

 =

I just = wanted to let you all know that CybOX v1.0 (Draft) content is now live = on the website. http://cybox.mitre.org

The = release notes are provided inline = below.

The key = items of note are:

=C2=B7        The = release of two formal specifications for the CybOX language (one for the = core language and one for the defined = objects)

=C2=B7        The XML = Schema has gone through extensive improvements for expressiveness, = clarity, consistency, efficiency, alignment to existing normative = references and documentation.

=C2=B7        This = release includes an initial set of language utilities: a draft Snort = -> CybOX transform, a draft OpenIOC -> CybOX transform, and a set = of Python bindings for the CybOX language.

=C2=B7        The = website now includes a small set of content examples. This set will grow = going forward.

This = release involved a lot of hard work from a diverse group of people. = Thank you all for your contributions and effort. We could not have done = it without you.

We look = forward to everyone=E2=80=99s feedback and collaboration as we continue = to improve and mature the CybOX = language.

 =

Sean = Barnum

 =

 =

 =

CybOX v1.0 (Draft) Release = Notes

The Version 1.0 (Draft) release of Cyber = Observable eXpression (CybOX=E2=84=A2) is intended as a draft release of an initial major version of = the CybOX Language that could be utilized for practical operational use = and integration into other standards efforts. This release consists of = three primary components: a pair of formal language specifications for = the core language content and defined objects content, a set of language = implementation XML schemas (core, common_types, and ~70 defined object = schemas), and a small initial set of language utilities including an = initial draft Snort->CybOX transform, an initial draft = OpenIOC->CybOX transform and a set of CybOX language Python bindings. = Recognizing that this is the first time that the formal language = specifications will be available for review and as such will likely = generate feedback from new stakeholders, this initial major version is = being released as a =E2=80=9Cdraft=E2=80=9D v1.0 with the expectation of = cycles of new feedback and revision before a =E2=80=9Cfinal=E2=80=9D = v1.0 is released.=

The CybOX v1.0 (Draft) XML schemas include a = significant number of changes from v0.7 to improve:=

=C2=B7       Clarity, = documentation, and descriptive formality for reference and = implementation by other standards and users.=

=C2=B7       Consistency, = simplicity, and efficiency.=

=C2=B7       Alignment (as = appropriate) to existing normative references.=

=C2=B7       Expressiveness of the = schema to better support the broad set of use cases it targets (malware = characterization, indicator and incident data sharing, event management, = etc.) including the addition of an initial set of network-related = defined objects.=

Summary = of changes from CybOX_v0.7 to CybOX_v1.0_(Draft):=

=C2=B7       = Refinement of namespaces and schema = locations for better effectiveness and flexibility going forward.=

=C2=B7       = Normalized all content according to an = established set of naming conventions.=

=C2=B7       = Fully annotated all language items = (types, attributes, elements, etc.).=

=C2=B7       = Moved several commonly leveraged types = out of the core schema and into common_types.=

=C2=B7       = Achieved full typing of entire schema = structure such that all attributes and elements are definitively = typed.=

=C2=B7       = Changed all identifiers from ID and IDREF = types to be QNames enabling globally unique identifiers and flexibility = for domain-specific users of CybOX to define their own identifier syntax = locally.=

=C2=B7       = Reordered attributes and elements in = numerous types to better reflect common usage and priority.=

=C2=B7       = Added major_version and minor_version = attributes for core schema.=

=C2=B7       = Added capability to characterize source = of overall observable package data and for individual observables.=

=C2=B7       = Modified the logical composition = structure such that any such compositions are now contained within a = Observable_Composition element providing improved simplicity and = modularity.=

=C2=B7       = Removed the Delta element from = ObservableType and relocated the appropriate portions (Change, Trend, = and Frequency) to appropriate locations under Stateful_Measure and = Event.=

=C2=B7       = Added a Domain_Specific_Object_Attributes = field to Object utilizing an abstract type that will allow = domain-specific use cases to add in their own domain-specific attributes = for Objects.=

=C2=B7       = Added a Tool-Specific_Data field to = ToolInformationType utilizing an abstract type that will allow addition = of tool-specific data.=

=C2=B7       = Added an Indicators field to = MeasureSourceType utilizing an abstract type that will allow = characterizing differing formats or standards of indicators that may = have led to the identification of the observable data.=

=C2=B7       = Enhanced the Hash structure to capture = full fuzzy hashes in addition to simple hashes=

=C2=B7       = Added a new ExtractedFeaturesType that = can be used to adorn differing objects (e.g., files, memory, etc.) to = capture extracted strings, imports, functions and code snippets=

=C2=B7       = Added a ByteRunsType to enable capture of = byte runs within various objects.=

=C2=B7       = Added object_reference attribute to = DefinedObjectType to better support referencing of independently defined = Objects from within another Object definition.=

=C2=B7       = Added a generic DataSegmentType to = provide a relatively abstract way of characterizing data segments that = may be written/read/transmitted or otherwise utilized in actions or = defined in objects.=

=C2=B7        Added several new = defined object schemas (API, Code, Device, DNS_Record, Network_Flow, = Network_Packet, Network_Route_Entry, Network_Subnet, = Unix_Network_Route_Entry) including an initial set of network-centric = defined objects.

=C2=B7       = Modified every defined object schema with = added annotations as well as minor and in some cases substantive changes = to fix errors, improve consistency and alignment with existing normative = references, and to improve expressiveness in support of the targeted use = cases.=

Detailed changes from CybOX_v0.7 to = CybOX_v1.0_(Draft):=

The level of changes within v1.0 (Draft) in = the core schema, common_types and the defined object schemas is too = great to list every change in these release notes. Detailed difference = reports are available for each individual schema at:http://cybox.mitre.org/XMLSchema/release_notes/cybox_v1.0= (draft)_diff_reports.zip

 =

 =

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

Sean Barnum=

Cyber Security Principal=

The MITRE Corporation=

 =

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

 

------=_NextPart_001_0009_01CD1C7A.EFE93B80-- ------=_NextPart_000_0008_01CD1C7A.EFE93B80 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP6zCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggTXMIIDv6ADAgECAhBcX1ns/Jl/DtI19/BXCcuBMA0G CSqGSIb3DQEBBQUAMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMwHhcNMTIwNDAzMDAwMDAwWhcNMTMwNDAzMjM1OTU5WjCCAR4xFzAVBgNVBAoTDlZl cmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13 d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChj KTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNDAyBgNVBAsTK0RpZ2l0YWwgSUQg Q2xhc3MgMSAtIE1pY3Jvc29mdCBGdWxsIFNlcnZpY2UxFzAVBgNVBAMUDk1pY2hhZWwgSGFtbWVy MSswKQYJKoZIhvcNAQkBFhxtaWNoYWVsLmhhbW1lckB5YWFuYXRlY2guY29tMIGfMA0GCSqGSIb3 DQEBAQUAA4GNADCBiQKBgQDoKTk9rP/4lG6CLqIR4++IFTuOSLF6bmhDr6eiSahqU0VNP+H/LbiD MAZsK9GQoBYPKQdKzy/gM+fl3Gm6VOdjKl8M3GB6LGgAK8d3ETN5dyKe5CAG7EEbKg9wxHWcuXW7 KYd052ven5Ec+Xj++v3HsE423O5q2mNh1Q8FNsnlXQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYD VR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2ln bi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYD VR0fBEkwRzBFoEOgQYY/aHR0cDovL2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20v SW5kQzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQA8rhDezFsw7OlR3+mZOZ39 SCKWNJ4gMlQEe31NNtvs6BUzE1uN+fJeZrJ5zjTdJWeG1NgVugcuzQfdv/m5BYbhgJvNfW6ElqZh cye6imOUx8diekkeHXKYSLnEvCdJItXsC1h/huIT9e83WksM92qI/TFyCq6u39cGf9PaBYbcKcZk jHjNi3SPnGifMC6opGiiyK/vB1lituoBRcJ13Y7XoXA8T0kSR8Dtmqvo1JudcFAbS1srytG1QX1H XTsPkTDKHlwv2ZfmCSKK3sWHDrZfpRglxvcX2OwibcKVkKBJRRw36UuJOIj/u0WYABcYtusAb2+0 nqoGmOEYARnrseTZMIIG7jCCBdagAwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUF ADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZv ciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQ cmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkw NDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP 6bGNQU4099oL42r6ZYggCxET6ZvgSU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYH r54UGAdPWr2f0jGyVBlzRmoZQhHsEnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50 ABMN0Ibak2f4MwOuGjxraXj2wCyO4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yx BF6+wbaULZeQLSfSux7pg2qE9sSyriMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ 6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CG SAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYI KwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6Al hiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYI KwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQ UjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1Ud EQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EI Qf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4 BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkx RTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZ gbWpBbVSOOk5hIls5DSoWufYbAlMJBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v 8dKBl8pUWkO/N4t6jhmND0OojPKvYLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM6 1a4ScAjr+zvid+zoK2Q1ds262uDRyxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/ XLJtSd5lUkL7DojS7Uodv0vj+Mxy+kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4 VRaMxmgD5yKocwuxvKDaUljdCg5/wYIxggS4MIIEtAIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTsw OQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykw OTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI19/BXCcuBMAkGBSsO AwIaBQCgggMbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQx NzEzMTc0MFowIwYJKoZIhvcNAQkEMRYEFBZsUOv3kF07vy/7lcmeU0rTodRRMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIIBAwYJKwYB BAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMCEFxfWez8mX8O0jX38FcJy4EwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkG A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24u Y29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5W ZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI1 9/BXCcuBMA0GCSqGSIb3DQEBAQUABIGACyUMz/RhCT/mblPhXxQNht28dXyXT/KeiY3RQVJoCCd0 7dFhulig1VpN2JoFxtyPUKeFxqcSBpJJrw6wHEyHyxIoxQBcso4H7oMbFOHNAVWutoReJsmZgUEp cFHqWfLt8L9Ca3EUV2Q5rk3Kx2j6g0dAj7od4Yq2aPrGJZx2mpoAAAAAAAA= ------=_NextPart_000_0008_01CD1C7A.EFE93B80-- From kathleen.moriarty@emc.com Tue Apr 17 07:09:09 2012 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 60D1311E8081; Tue, 17 Apr 2012 07:09:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.46 X-Spam-Level: X-Spam-Status: No, score=-10.46 tagged_above=-999 required=5 tests=[AWL=0.139, 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 yljXePelEjBL; Tue, 17 Apr 2012 07:09:09 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id E7E1421F8621; Tue, 17 Apr 2012 07:09:08 -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 q3HE8vpC028336 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Apr 2012 10:09:02 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd03.lss.emc.com [10.254.221.145]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Tue, 17 Apr 2012 10:08:41 -0400 Received: from mxhub29.corp.emc.com (mxhub29.corp.emc.com [128.222.70.169]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q3HE8eJQ024240; Tue, 17 Apr 2012 10:08:41 -0400 Received: from mx06a.corp.emc.com ([169.254.1.106]) by mxhub29.corp.emc.com ([128.222.70.169]) with mapi; Tue, 17 Apr 2012 10:08:39 -0400 From: To: Date: Tue, 17 Apr 2012 10:07:52 -0400 Thread-Topic: [mile] [sacm] CybOX v1.0 (Draft) is now released and live onthe website Thread-Index: AQHNHFhQtpFrr+nGFkWqCWY68NIgupae/ygAgAAIhWOAAAaXXg== Message-ID: References: <7F48813B48558A4BB5CB7BB714E5B5A9171B16@IMCMBX03.MITRE.ORG> <69CE2DCD9DAC3D48B830E0723141170B02A39BD2@ZAU1UG-0308.DHSNET.DS1.DHS> <953A2E460DBE7C43AC13E30B87C5B4FF080A1C09@XMB-RCD-106.cisco.com> <7F48813B48558A4BB5CB7BB714E5B5A9171BA1@IMCMBX03.MITRE.ORG>, <00C069FD01E0324C9FFCADF539701DB389FC37@EX2K10MB1.corp.yaanatech.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: mile@ietf.org, sacm@ietf.org, m-terada@ipa.go.jp Subject: Re: [mile] [sacm] CybOX v1.0 (Draft) is now released and live onthe website 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, 17 Apr 2012 14:09:09 -0000 SGkgTWlrZSwNCg0KQXJlIHlvdSBzdWdnZXN0aW5nIHRvIGp1c3QgaW5jbHVkZSB0aGUgTmV0Q29u ZiBzY2hlbWEgYW5kIGFsbG93IHRoYXQgdG8gZXZvbHZlIGFuZCBwdWxsIGl0IGluIHdoZXJlIGFw cHJvcHJpYXRlPyAgVGhhdCBtYWtlcyBzZW5zZSB0byBtZS4uLiAgRm9yIElPREVGLCByaWdodCBu b3cgeW91IHdvdWxkIHVzZSB0aGUgRmxvdyBjbGFzcyBhbmQgY291bGQgb3B0aW9uYWxseSB1c2Ug TmV0Q29uZiB1c2luZyB0aGUgQWRkaXRpb25hbERhdGEgdG8gaW5jbHVkZSBhbm90aGVyIHNjaGVt YS4gIEFsdGhvdWdoIHdlIGRvbid0IGhhdmUgTmV0Q29uZiBpbiB0aGUgU0NJIGRyYWZ0LCB0aGF0 IHJhaXNlcyBhIGdvb2QgcG9pbnQgZm9yIE1JTEUgdG8gY29uc2lkZXIgKGlmIHRoZXJlIGlzIGEg Z2FwIGluIHNjaGVtYSBvciBndWlkYW5jZSkuICBPciB0byBpbmNsdWRlIHRoaXMgaW4gdGhlIElP REVGIGd1aWRhbmNlIGRvY3VtZW50IHNvIHdlIGhhdmUgYW4gYWdyZWVkIHdheSB0byBoYW5kbGUg dGhpcyB1c2UgY2FzZSBjb25zaXN0ZW50bHkgYmV0d2VlbiBpbXBsZW1lbnRhdGlvbnMuICBTQUNN IGlzIHRoaW5raW5nIGFib3V0IHRoZSByZWxhdGlvbnNoaXBzIGJldHdlZW4gbWFuYWdlbWVudCBw cm90b2NvbHMgYW5kIHNlY3VyaXR5IGF1dG9tYXRpb24gc3BlY2lmaWNhdGlvbnMgaW4gdGhlIGJh c2UgdXNlIGNhc2UsIHNvIHRoYXQgc2hvdWxkIGhlbHAgaW4gdGhhdCBzcGFjZS4NCg0KVW5kZXJz dGFuZGluZyB0aGUgdXNlIGNhc2VzIGZvciBDeWJPWCBhbmQgZmxvd3MgbWF5IGhlbHAgdG8gdW5k ZXJzdGFuZCB3aHkgd2UgbWF5IG5lZWQgdGhlIHJlcHJlc2VudGF0aW9uIGRpcmVjdGx5IGluIHRo ZSBzcGVjaWZpY2F0aW9uIGFzIG9wcG9zZWQgdG8gcmVmZXJlbmNpbmcgTmV0Q29uZi4gU2Vhbj8N Cg0KVGhhbmtzLA0KS2F0aGxlZW4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCkZyb206IG1pbGUtYm91bmNlc0BpZXRmLm9yZyBbbWlsZS1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgTWljaGFlbCBIYW1tZXIgW21pY2hhZWwuaGFtbWVyQHlhYW5hdGVjaC5j b21dDQpTZW50OiBUdWVzZGF5LCBBcHJpbCAxNywgMjAxMiA5OjE3IEFNDQpUbzogc2Jhcm51bUBt aXRyZS5vcmc7IG9zYW50b3NAY2lzY28uY29tOyBUaG9tYXMuTWlsbGFyQGhxLmRocy5nb3Y7IGxu dW5lekBjM2lzZWN1cml0eS5jb20NCkNjOiBpZHh3Z0BuaWN3Zy5vcmc7IG1pbGVAaWV0Zi5vcmc7 IGRhbGxlbmRvdWdAZ21haWwuY29tOyBzYWNtQGlldGYub3JnOyBtLXRlcmFkYUBpcGEuZ28uanAN ClN1YmplY3Q6IFJlOiBbbWlsZV0gW3NhY21dIEN5Yk9YIHYxLjAgKERyYWZ0KSBpcyBub3cgcmVs ZWFzZWQgYW5kIGxpdmUgb250aGUgd2Vic2l0ZQ0KDQpTZWFuLA0KDQpEb2VzIHRoZSBvdmVybGFw IGJldHdlZW4gdGhlIHZhcmlvdXMgb2JqZWN0cyBwcmVzZW50IGEgcHJvYmxlbT8NCg0KSWYgdGhl cmUgYXJlIG9uZSBvciBtb3JlIG9iamVjdHMgdGhhdCBjb3VsZCBjYXJyeSB0aGUgc2FtZSBkYXRh LCB0aGVuIGh1bWFuIG5hdHVyZSBtZWFucyB0aGF0IHByb2JhYmlsaXR5LXdpc2Ugc29tZW9uZSB3 aWxsIGNob29zZSBkYXRhIGZsb3cgaW5zdGVhZCBvZiBOZXRmbG93Lg0KVGhhdCBpcyB0aGUgdW5k ZXJseWluZyBwcmluY2lwbGUgaW4gTXVycGh54oCZcyBMYXcsIHdoZXJlIHlvdSB0cnkgdG8gZGVz aWduIGl0IHNvIHRoYXQgdGhlcmUgaXMgb25seSBvbmUgd2F5IHRvIGRvIGl0LCBhbmQgdGh1cyBw cml2YXRlIE11cnBoeSB3b27igJl0IGRvIGl0IHRoZSDigJx3cm9uZ+KAnSB3YXkuDQoNCkp1c3Qg d29uZGVyaW5nIGlmIHRoZXNlIHNob3VsZCBiZSBtdXR1YWxseSBleGNsdXNpdmUgc2V0cy4gIEFu ZCBkZXNpZ25lZCBhcyBzdWNoLg0KTWlnaHQgaW1wcm92ZSBpbnRlcm9wZXJhYmlsaXR5LiAgKEFu ZCBhdm9pZCBkaXNjdXNzaW9ucyBsaWtlIHRoaXMgaW4gZnV0dXJlLikgIOKYug0KDQpNaWtlDQoN Cg0KRnJvbTogbWlsZS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bWlsZS1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgQmFybnVtLCBTZWFuIEQuDQpTZW50OiBUdWVzZGF5LCBBcHJpbCAx NywgMjAxMiAxOjEwIEFNDQpUbzogT21hciBTYW50b3MgKG9zYW50b3MpOyBNaWxsYXIsIFRob21h czsgbG51bmV6QGMzaXNlY3VyaXR5LmNvbQ0KQ2M6IGlkeHdnQG5pY3dnLm9yZzsgbWlsZUBpZXRm Lm9yZzsgZGFsbGVuZG91Z0BnbWFpbC5jb207IHNhY21AaWV0Zi5vcmc7IG0tdGVyYWRhQGlwYS5n by5qcA0KU3ViamVjdDogUmU6IFttaWxlXSBbc2FjbV0gQ3liT1ggdjEuMCAoRHJhZnQpIGlzIG5v dyByZWxlYXNlZCBhbmQgbGl2ZSBvbnRoZSB3ZWJzaXRlDQoNCuKAnHVwcGVyIGxheWVy4oCdPyBZ ZXMsIGFzIGluIGhpZ2hlciBhYnN0cmFjdGlvbi4NCkp1c3Qg4oCccHJvdG9jb2xz4oCdPyBOby4N Cg0KWW91IGd1eXMgaGF2ZSBiZWVuIGxvb2tpbmcgYXQgdGhpcyB0aHJvdWdoIHRoZSBsZW5zIG9m IG5ldHdvcmsgZmxvdyB3aGljaCBpZiBmaW5lIGZvciB0aGlua2luZyBhYm91dCB0aGF0IHBlcnNw ZWN0aXZlIGJ1dCBpdCBpcyBpbXBvcnRhbnQgdG8gYWxzbyByZWFsaXplIHRoYXQgdGhlIEV2ZW50 VHlwZUVudW0gYW5kIGl0cyDigJxEYXRhIEZsb3figJ0gdmFsdWUgZ28gZmFyIGJleW9uZCBuZXR3 b3JrLXJlbGF0ZWQgc2NvcGUuDQpJdCBpcyBhYm91dCBhIGxvdCBvZiBvdGhlciB0eXBlcyBvZiBw b3RlbnRpYWwgZGF0YSBmbG93cyAoYXMgSSBqdXN0IG91dGxpbmVkIGluIGEgcmVzcG9uc2UgdG8g VG9tKSB0aGF0IGhhdmUgbm90aGluZyB0byBkbyB3aXRoIG5ldHdvcmsgZmxvdy4NCg0KVGhhbmtz IGZvciB5b3VyIHJlc3BvbnNlIHRob3VnaC4gVGhpcyBpcyB0aGUga2luZCBvZiBkaXNjdXNzaW9u cyB0aGF0IHdlIGhvcGUgdG8gaGF2ZSBhIGxvdCBtb3JlIG9mIGFtb25nIHRoZSB2YXJpb3VzIHN1 cHBvcnRlZCBjb21tdW5pdGllcy4NCg0KDQpCVFcsIHlvdSBtYXkgaGF2ZSBub3RpY2VkIHRoYXQg dGhlIE5ldHdvcmtfRmxvdyBvYmplY3Qgd2l0aGluIEN5Yk9YIHYxLjAgKERyYWZ0KSBzdXBwb3J0 cyBleHByZXNzaW9uIG9mIG5ldGZsb3cgd2l0aGluIHNldmVyYWwgb2YgdGhlIG1vc3QgY29tbW9u IGZvcm1hdHMgaW5jbHVkaW5nIE5ldGZsb3c5IChhcyB3ZWxsIGFzIElQRklYIGFzIEx1aXMgcG9p bnRlZCBvdXQsIE5ldGZsb3c1IGFuZCBTaUxLIGFzIHdlbGwgYXMgYmktZGlyZWN0aW9uYWwgZmxv dyBpbiBZQUYpLiBUaGUgY29tbW9uIDUtdHVwbGUgb3IgNy10dXBsZSAoeW91IGRlc2NyaWJlKSAo aW4gb3VyIGNhc2UgaXQgaXMgYW4gOC10dXBsZSBhcyB3ZSBicm9rZSB0aGUgcm91dGVyIGludGVy ZmFjZSBvdXQgaW50byBib3RoIGluZ3Jlc3MgYW5kIGVncmVzcyDimLopIHNoYXJlZCBieSBwcmV0 dHkgbXVjaCBhbGwgb2YgdGhlIG5ldGZsb3cgYXBwcm9hY2hlcyBoYXMgYmVlbiBicm9rZW4gb3V0 IGludG8gYSBzaGFyZWQgTmV0d29ya19GbG93X0xhYmVsIHN0cnVjdHVyZS4gVGhlIHZhcmlvdXMg Y29udGV4dC1kZXBlbmRlbnQgcG9ydGlvbnMgb2YgdGhlIGluZGVwZW5kZW50IGFwcHJvYWNoZXMg YXJlIHRoZW4gY2FwdHVyZWQgd2l0aGluIG9wdGlvbmFsIHN0cnVjdHVyZXMgZGVkaWNhdGVkIHRv IGVhY2ggb2YgdGhlbS4gV2UgaG9wZSB0aGF0IGV2ZW50dWFsbHkgdGhlIGNvbW11bml0eSBjYW4g d29yayB0byBjb21lIHRvZ2V0aGVyIHRvd2FyZHMgYSBzaW5nbGUgb3ZlcmFsbCBjb21tb24gZXhw cmVzc2l2ZSBzdHJ1Y3R1cmUgZm9yIG5ldGZsb3cgdGhhdCBtZWV0cyB0aGUgbmVlZHMgb2YgYWxs LiBXZSBob3BlIHRoYXQgQ3liT1ggYW5kIGl0cyB1c2UgY2FuIGV2ZW4gaGVscCB0aGF0IHNvcnQg b2YgbWF0dXJhdGlvbiBhbmQgbm9ybWFsaXphdGlvbi4gQnV0IHNpbmNlIG5vIHN1Y2ggdW5pdmVy c2FsIHN0cnVjdHVyZSBleGlzdHMgdG9kYXksIHdlIGRlY2lkZWQgdG8gZW5hYmxlIG9wdGlvbmFs IGV4cHJlc3Npb24gb2YgdGhlIG1vc3QgY29tbW9uIGluZGl2aWR1YWwgZm9ybWF0cyB3aXRoaW4g YSBzaW5nbGUgbmV0ZmxvdyBvYmplY3QgdG8gc2VydmUgdGhlIGxhcmdlIG1ham9yaXR5IG9mIHJl bGV2YW50IHVzZXJzLCBtYWludGFpbiBmbGV4aWJpbGl0eSBhbmQgZW5hYmxlIGRpc2N1c3Npb25z IGFuZCBhbmFseXNpcyBvZiBuZXRmbG93IHdpdGhpbiBhIGNvbW1vbiBwYWNrYWdlLg0KV2UgbG9v ayBmb3J3YXJkIHRvIGNvbnRpbnVpbmcgZGlzY3Vzc2lvbnMgd2l0aCB0aGUgY29tbXVuaXR5IHRv IHZhbGlkYXRlIG9yIGludmFsaWRhdGUgdGhpcyBhcHByb2FjaCBhbmQgdG8gcmVmaW5lIGFuZCBt YXR1cmUgZ29pbmcgZm9yd2FyZC4NCg0KU2Vhbg0KDQpGcm9tOiBPbWFyIFNhbnRvcyAob3NhbnRv cykgW21haWx0bzpvc2FudG9zQGNpc2NvLmNvbV08bWFpbHRvOlttYWlsdG86b3NhbnRvc0BjaXNj by5jb21dPg0KU2VudDogTW9uZGF5LCBBcHJpbCAxNiwgMjAxMiAxMTo1NyBQTQ0KVG86IE1pbGxh ciwgVGhvbWFzOyBCYXJudW0sIFNlYW4gRC47IGxudW5lekBjM2lzZWN1cml0eS5jb208bWFpbHRv OmxudW5lekBjM2lzZWN1cml0eS5jb20+DQpDYzogaWR4d2dAbmljd2cub3JnPG1haWx0bzppZHh3 Z0BuaWN3Zy5vcmc+OyBtaWxlQGlldGYub3JnPG1haWx0bzptaWxlQGlldGYub3JnPjsgZGFsbGVu ZG91Z0BnbWFpbC5jb208bWFpbHRvOmRhbGxlbmRvdWdAZ21haWwuY29tPjsgc2FjbUBpZXRmLm9y ZzxtYWlsdG86c2FjbUBpZXRmLm9yZz47IG0tdGVyYWRhQGlwYS5nby5qcDxtYWlsdG86bS10ZXJh ZGFAaXBhLmdvLmpwPg0KU3ViamVjdDogUkU6IFtzYWNtXSBbbWlsZV0gQ3liT1ggdjEuMCAoRHJh ZnQpIGlzIG5vdyByZWxlYXNlZCBhbmQgbGl2ZSBvbnRoZSB3ZWJzaXRlDQoNCkkgYmVsaWV2ZSB0 aGF0IHdoYXQgU2VhbiBpcyBzYXlpbmcgaXMgdGhhdCDigJxkYXRhIGZsb3figJ0gaXMganVzdCBh IHZhbHVlIHRoYXQgaXMgbWVhbnQgZm9yIHVwcGVyIGxheWVyIHByb3RvY29scy4gQnV0LCB5b3Ug aGF2ZSBhIGdvb2QgcG9pbnQuIFRyYWRpdGlvbmFsbHksIGEg4oCcZmxvd+KAnSBpbiDigJxOZXRm bG934oCdIGlzIGJhc2VkIG9uIGEgc2V0IG9mIDUgYW5kIHVwIHRvIDcgSVAgcGFja2V0IGF0dHJp YnV0ZXM6DQoNCi0gSVAgc291cmNlIGFkZHJlc3MNCi0gSVAgZGVzdGluYXRpb24gYWRkcmVzcw0K LSBTb3VyY2UgcG9ydA0KLSBEZXN0aW5hdGlvbiBwb3J0DQotIExheWVyIDMgcHJvdG9jb2wgdHlw ZQ0KLSBDbGFzcyBvZiBTZXJ2aWNlDQotIFJvdXRlciBvciBzd2l0Y2ggaW50ZXJmYWNlDQoNCkFs dGhvdWdoLCB0aGVyZSBpcyBhIGxvdCBtb3JlIHN1cHBvcnQgd2l0aCBOZXRmbG93IHZlcnNpb24g OToNCmh0dHA6Ly93d3cuY2lzY28uY29tL2VuL1VTL3RlY2hub2xvZ2llcy90azY0OC90azM2Mi90 ZWNobm9sb2dpZXNfd2hpdGVfcGFwZXIwOTE4NmEwMDgwMGEzZGI5X3BzNjYwMV9Qcm9kdWN0c19X aGl0ZV9QYXBlci5odG1sDQoNCg0KDQpSZWdhcmRzLA0KDQpPbWFyDQoNCkZyb206IE1pbGxhciwg VGhvbWFzIFttYWlsdG86VGhvbWFzLk1pbGxhckBocS5kaHMuZ292XTxtYWlsdG86W21haWx0bzpU aG9tYXMuTWlsbGFyQGhxLmRocy5nb3ZdPg0KU2VudDogTW9uZGF5LCBBcHJpbCAxNiwgMjAxMiAx MTo0NiBQTQ0KVG86IHNiYXJudW1AbWl0cmUub3JnPG1haWx0bzpzYmFybnVtQG1pdHJlLm9yZz47 IE9tYXIgU2FudG9zIChvc2FudG9zKTsgbG51bmV6QGMzaXNlY3VyaXR5LmNvbTxtYWlsdG86bG51 bmV6QGMzaXNlY3VyaXR5LmNvbT4NCkNjOiBpZHh3Z0BuaWN3Zy5vcmc8bWFpbHRvOmlkeHdnQG5p Y3dnLm9yZz47IG1pbGVAaWV0Zi5vcmc8bWFpbHRvOm1pbGVAaWV0Zi5vcmc+OyBkYWxsZW5kb3Vn QGdtYWlsLmNvbTxtYWlsdG86ZGFsbGVuZG91Z0BnbWFpbC5jb20+OyBzYWNtQGlldGYub3JnPG1h aWx0bzpzYWNtQGlldGYub3JnPjsgbS10ZXJhZGFAaXBhLmdvLmpwPG1haWx0bzptLXRlcmFkYUBp cGEuZ28uanA+DQpTdWJqZWN0OiBSZTogW3NhY21dIFttaWxlXSBDeWJPWCB2MS4wIChEcmFmdCkg aXMgbm93IHJlbGVhc2VkIGFuZCBsaXZlIG9udGhlIHdlYnNpdGUNCg0KSWYgImRhdGEgZmxvdyIg aXMgYSBldXBoZW1pc20gZm9yICJuZXRmbG93IiBpcyB0aGVyZSBhbnkgcmVhc29uIG5vdCB0byBj YWxsIGl0IHRoYXQ/DQoNClRvbSBNaWxsYXINCmh0dHA6Ly93d3cudXMtY2VydC5nb3YvDQotLS0t LS0tLS0tLS0tLS0tLS0NCk1pc3NpdCBtZSBSdWJ1cyBmcnV0aWNvc3VzOg0KMjAyIDYzMSAxOTE1 DQoNCg0KRnJvbTogQmFybnVtLCBTZWFuIEQuIFttYWlsdG86c2Jhcm51bUBtaXRyZS5vcmddPG1h aWx0bzpbbWFpbHRvOnNiYXJudW1AbWl0cmUub3JnXT4NClNlbnQ6IE1vbmRheSwgQXByaWwgMTYs IDIwMTIgMTE6MjkgUE0NClRvOiBPbWFyIFNhbnRvcyAob3NhbnRvcykgPG9zYW50b3NAY2lzY28u Y29tPG1haWx0bzpvc2FudG9zQGNpc2NvLmNvbT4+OyBMdWlzIE51bmV6IDxsbnVuZXpAYzNpc2Vj dXJpdHkuY29tPG1haWx0bzpsbnVuZXpAYzNpc2VjdXJpdHkuY29tPj4NCkNjOiBpZHh3Z0BuaWN3 Zy5vcmc8bWFpbHRvOmlkeHdnQG5pY3dnLm9yZz4gPGlkeHdnQG5pY3dnLm9yZzxtYWlsdG86aWR4 d2dAbmljd2cub3JnPj47IG1pbGVAaWV0Zi5vcmc8bWFpbHRvOm1pbGVAaWV0Zi5vcmc+IDxtaWxl QGlldGYub3JnPG1haWx0bzptaWxlQGlldGYub3JnPj47IGRhbGxlbmRvdWdAZ21haWwuY29tPG1h aWx0bzpkYWxsZW5kb3VnQGdtYWlsLmNvbT4gPGRhbGxlbmRvdWdAZ21haWwuY29tPG1haWx0bzpk YWxsZW5kb3VnQGdtYWlsLmNvbT4+OyBzYWNtQGlldGYub3JnPG1haWx0bzpzYWNtQGlldGYub3Jn PiA8c2FjbUBpZXRmLm9yZzxtYWlsdG86c2FjbUBpZXRmLm9yZz4+OyBtLXRlcmFkYUBpcGEuZ28u anA8bWFpbHRvOm0tdGVyYWRhQGlwYS5nby5qcD4gPG0tdGVyYWRhQGlwYS5nby5qcDxtYWlsdG86 bS10ZXJhZGFAaXBhLmdvLmpwPj4NClN1YmplY3Q6IFJlOiBbc2FjbV0gW21pbGVdIEN5Yk9YIHYx LjAgKERyYWZ0KSBpcyBub3cgcmVsZWFzZWQgYW5kIGxpdmUgb250aGUgd2Vic2l0ZQ0KDQpUaGFu a3MgT21hci4NCg0KVG8gYW5zd2VyIHlvdXIgcXVlc3Rpb24sIGZpcnN0IGxldCBtZSBwb2ludCBv dXQgdG8gb3RoZXIgcmVhZGVycyB0aGF0IHRoZSB0d28gZW50cmllcyB0aGF0IE9tYXIgaXMgcXVv dGluZyBoZXJlIGV4aXN0IGFzIHZhbHVlcyBpbiBhbiBlbnVtZXJhdGlvbiBjYWxsZWQgRXZlbnRU eXBlRW51bSB3aGljaCBhcyBpdHMgbmFtZSBpbXBsaWVzIGNvbnRhaW5zIGEgbGlzdCBvZiBkaWZm ZXJlbnQgbGFiZWxzIGZvciBncm91cGluZyB0eXBlcyAob3IgY2xhc3Nlcykgb2YgZXZlbnRzIHRv IGJlIHVzZWQgYXMgbG93LWdyYW51bGFyaXR5IGJ1Y2tldHMgZm9yIGNoYXJhY3Rlcml6aW5nIGFu ZCBjbGFzc2lmeWluZyBldmVudHMuDQpPdGhlciBlbnRyaWVzIGluIHRoaXMgZW51bWVyYXRpb24g aW5jbHVkZSB0aGluZ3MgbGlrZSDigJxGaWxlIE9wcyAoQ1JVRCnigJ0sIOKAnFByb2Nlc3MgTWd0 4oCdLCDigJxBdXRob3JpemF0aW9uIChBQ0wp4oCdLCBldGMuDQoNClRoZSDigJxQYWNrZXQgVHJh ZmZpY+KAnSB2YWx1ZSBpcyBpbnRlbmRlZCB0byBjaGFyYWN0ZXJpemUgZXZlbnRzIGRlYWxpbmcg d2l0aCBuZXR3b3JrIHBhY2tldCB0cmFmZmljIGFzIGl0cyBuYW1lIGltcGxpZXMuDQpUaGUg4oCc RGF0YSBGbG934oCdIHZhbHVlIGlzIGludGVuZGVkIHRvIGNoYXJhY3Rlcml6ZSBldmVudHMgZGVh bGluZyB3aXRoIGZvcm1zIG9mIGRhdGEgZmxvdyBhdCBhIGhpZ2hlciBsZXZlbCBvZiBhYnN0cmFj dGlvbiB0aGFuIGp1c3QgcGFja2V0IHRyYWZmaWMuIFRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiB0 aGVzZSB0d28gdmFsdWVzIGNvdWxkIGJlIHZpZXdlZCBhcyDigJxQYWNrZXQgVHJhZmZpY+KAnSBi ZWluZyBhIG1vcmUgZGV0YWlsZWQgZm9ybSBvZiDigJxEYXRhIEZsb3figJ0ganVzdCBhcyB0aGUg dmFsdWVzIOKAnEFwcCBMYXllciBUcmFmZmlj4oCdIGFuZCDigJxIVFRQIExheWVyIFRyYWZmaWPi gJ0sIGFsc28gaW4gdGhpcyBlbnVtZXJhdGlvbiwgY291bGQgYmUgb3RoZXIgbGV2ZWxzIGluIHRo aXMgc2FtZSBhYnN0cmFjdGlvbiBzdGFjay4NClRoZSBpZGVhIGJlaGluZCB0aGUgdmFyeWluZyBs ZXZlbHMgb2YgYWJzdHJhY3Rpb24gaXMgdG8gbGVhdmUgIGJ1Y2tldHMgbGFyZ2UgZW5vdWdoIHRv IGNhcHR1cmUgYSB3aWRlIHZhcmlldHkgb2YgcG90ZW50aWFsIGV2ZW50IHR5cGVzIChlLmcuIGRh dGEgZmxvdyBldmVudHMgb3RoZXIgdGhhbiBvYnZpb3VzIHRoaW5ncyBsaWtlIHBhY2tldCB0cmFm ZmljKSBidXQgYWxzbyBlbmFibGUgdGhlIHVzZSBvZiBzbWFsbGVyIG1vcmUgc3BlY2lmaWMgYnVj a2V0cyB3aGVuIHRoZXkgYXJlIGFwcHJvcHJpYXRlIGFuZCBjb21tb25seSB1c2VkLg0KDQpEb2Vz IHRoaXMgbWFrZSBzZW5zZT8NCg0Kc2Vhbg0KDQpGcm9tOiBPbWFyIFNhbnRvcyAob3NhbnRvcykg W21haWx0bzpvc2FudG9zQGNpc2NvLmNvbV08bWFpbHRvOlttYWlsdG86b3NhbnRvc0BjaXNjby5j b21dPg0KU2VudDogTW9uZGF5LCBBcHJpbCAxNiwgMjAxMiA4OjE3IFBNDQpUbzogTHVpcyBOdW5l ejsgQmFybnVtLCBTZWFuIEQuDQpDYzogaWR4d2dAbmljd2cub3JnPG1haWx0bzppZHh3Z0BuaWN3 Zy5vcmc+OyBtaWxlQGlldGYub3JnPG1haWx0bzptaWxlQGlldGYub3JnPjsgZGFsbGVuZG91Z0Bn bWFpbC5jb208bWFpbHRvOmRhbGxlbmRvdWdAZ21haWwuY29tPjsgc2FjbUBpZXRmLm9yZzxtYWls dG86c2FjbUBpZXRmLm9yZz47IG0tdGVyYWRhQGlwYS5nby5qcDxtYWlsdG86bS10ZXJhZGFAaXBh LmdvLmpwPg0KU3ViamVjdDogUkU6IFtzYWNtXSBbbWlsZV0gQ3liT1ggdjEuMCAoRHJhZnQpIGlz IG5vdyByZWxlYXNlZCBhbmQgbGl2ZSBvbnRoZSB3ZWJzaXRlDQoNCkkgZWNobyBMdWlz4oCZIGNv bW1lbnRzLiBJdCBpcyBnb29kIHRvIHNlZSB0aGUgaW5jbHVzaW9uIG9mIG5ldHdvcmsgb2JqZWN0 cy4gUXVpY2sgcXVlc3Rpb24gdG8gdGhlIHRlYW0gcmVsYXRlZCB0byB5b3VyIG5ldGZsb3cgY29t bWVudC4NCg0KSSBhbSBsb29raW5nIGF0Og0KaHR0cDovL2N5Ym94Lm1pdHJlLm9yZy9YTUxTY2hl bWEvY3lib3hfY29yZV92MS4wJTI4ZHJhZnQlMjkueHNkDQoNCuKApiBhbmQgaXQgbG9va3MgdGhh dCB3ZSByZW5hbWVkIGl0IHRvIOKAnERhdGEgRmxvd+KAnT8NCg0KPHhzOmVudW1lcmF0aW9uIHZh bHVlPSJEYXRhIEZsb3ciPg0KICAgPHhzOmFubm90YXRpb24+DQogICAgICAgIDx4czpkb2N1bWVu dGF0aW9uPlNwZWNpZmllcyB0aGUgY2xhc3Mgb2YgZXZlbnRzIGRlYWxpbmcgd2l0aCBkYXRhIGZs b3cuPC94czpkb2N1bWVudGF0aW9uPg0KICAgPC94czphbm5vdGF0aW9uPg0KPC94czplbnVtZXJh dGlvbj4NCg0KDQpXaGF0IGlzIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gdGhhdCBhbmQg4oCcUGFj a2V0IFRyYWZmaWPigJ0/DQoNCg0KPHhzOmVudW1lcmF0aW9uIHZhbHVlPSJQYWNrZXQgVHJhZmZp YyI+DQoNCiAgIDx4czphbm5vdGF0aW9uPg0KDQogICAgIDx4czpkb2N1bWVudGF0aW9uPlNwZWNp ZmllcyB0aGUgY2xhc3Mgb2YgZXZlbnRzIGRlYWxpbmcgd2l0aCBwYWNrZXQgdHJhZmZpYy48L3hz OmRvY3VtZW50YXRpb24+DQoNCiAgIDwveHM6YW5ub3RhdGlvbj4NCg0KPC94czplbnVtZXJhdGlv bj4NCg0KDQoNCg0KUmVnYXJkcywNCg0KT21hciBTYW50b3MNCkluY2lkZW50IE1hbmFnZXIsIFBT SVJUDQpTZWN1cml0eSBSZXNlYXJjaCBhbmQgT3BlcmF0aW9ucw0KQ2lzY28gU3lzdGVtcywgSW5j Lg0KRW1haWw6IG9zQGNpc2NvLmNvbTxtYWlsdG86b3NAY2lzY28uY29tPg0KUGhvbmU6ICsxIDkx OSAzOTIgODYzNQ0KUEdQIEtleTogMHgzQUYyN0VEQw0KDQpDaXNjby5jb20gLSBodHRwOi8vd3d3 LmNpc2NvLmNvbQ0KQ2lzY28gU2VjdXJpdHkgQWR2aXNvcmllcyBhbmQgTm90aWNlcyAtIGh0dHA6 Ly93d3cuY2lzY28uY29tL2dvL3BzaXJ0DQoNClRoaXMgZW1haWwgbWF5IGNvbnRhaW4gY29uZmlk ZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0aGUgc29sZQ0KdXNlIG9mIHRoZSBp bnRlbmRlZCByZWNpcGllbnQuIEFueSByZXZpZXcsIHVzZSwgZGlzdHJpYnV0aW9uIG9yDQpkaXNj bG9zdXJlIGJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5b3UgYXJlIG5vdCB0 aGUgaW50ZW5kZWQNCnJlY2lwaWVudCAob3IgYXV0aG9yaXplZCB0byByZWNlaXZlIGZvciB0aGUg cmVjaXBpZW50KSwgcGxlYXNlIGNvbnRhY3QNCnRoZSBzZW5kZXIgYnkgcmVwbHkgZW1haWwgYW5k IGRlbGV0ZSBhbGwgY29waWVzIG9mIHRoaXMgbWVzc2FnZS4NCg0KRm9yIGNvcnBvcmF0ZSBsZWdh bCBpbmZvcm1hdGlvbiBnbyB0bzoNCmh0dHA6Ly93d3cuY2lzY28uY29tL3dlYi9hYm91dC9kb2lu Z19idXNpbmVzcy9sZWdhbC9jcmkvaW5kZXguaHRtbA0KDQpGcm9tOiBzYWNtLWJvdW5jZXNAaWV0 Zi5vcmc8bWFpbHRvOnNhY20tYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzpzYWNtLWJvdW5jZXNA aWV0Zi5vcmddPG1haWx0bzpbbWFpbHRvOnNhY20tYm91bmNlc0BpZXRmLm9yZ10+IE9uIEJlaGFs ZiBPZiBMdWlzIE51bmV6DQpTZW50OiBNb25kYXksIEFwcmlsIDE2LCAyMDEyIDY6NDQgUE0NClRv OiBCYXJudW0sIFNlYW4gRC4NCkNjOiBpZHh3Z0BuaWN3Zy5vcmc8bWFpbHRvOmlkeHdnQG5pY3dn Lm9yZz47IG1pbGVAaWV0Zi5vcmc8bWFpbHRvOm1pbGVAaWV0Zi5vcmc+OyBEb3VnIFdpbHNvbiAo ZGFsbGVuZG91Z0BnbWFpbC5jb208bWFpbHRvOmRhbGxlbmRvdWdAZ21haWwuY29tPik7IHNhY21A aWV0Zi5vcmc8bWFpbHRvOnNhY21AaWV0Zi5vcmc+OyBJUEEtTWFzYXRvIFRlcmFkYSAobS10ZXJh ZGFAaXBhLmdvLmpwPG1haWx0bzptLXRlcmFkYUBpcGEuZ28uanA+KQ0KU3ViamVjdDogUmU6IFtz YWNtXSBbbWlsZV0gQ3liT1ggdjEuMCAoRHJhZnQpIGlzIG5vdyByZWxlYXNlZCBhbmQgbGl2ZSBv bnRoZSB3ZWJzaXRlDQoNCkkgbGlrZSB0aGUgaW5jbHVzaW9uIG9mIHRoZSBuZXR3b3JrLWNlbnRy aWMgb2JqZWN0cy4gIElQRklYIChuZXRmbG93KSAgd2lsbCBhZGQgYW4gYWRkaXRpb25hbCBwZXJz cGVjdGl2ZSBmcm9tIGFuIGluY2lkZW50IGluZm9ybWF0aW9uIHNoYXJpbmcgc3RhbmRwb2ludC4N Cg0KLWxuDQoNCk9uIEFwciAxNiwgMjAxMiwgYXQgNDowNCBQTSwgQmFybnVtLCBTZWFuIEQuIHdy b3RlOg0KDQpIZXkgZXZlcnlvbmUsDQoNCkkganVzdCB3YW50ZWQgdG8gbGV0IHlvdSBhbGwga25v dyB0aGF0IEN5Yk9YIHYxLjAgKERyYWZ0KSBjb250ZW50IGlzIG5vdyBsaXZlIG9uIHRoZSB3ZWJz aXRlLiBodHRwOi8vY3lib3gubWl0cmUub3JnDQpUaGUgcmVsZWFzZSBub3RlcyBhcmUgcHJvdmlk ZWQgaW5saW5lIGJlbG93Lg0KVGhlIGtleSBpdGVtcyBvZiBub3RlIGFyZToNCuKAoiAgICAgICAg VGhlIHJlbGVhc2Ugb2YgdHdvIGZvcm1hbCBzcGVjaWZpY2F0aW9ucyBmb3IgdGhlIEN5Yk9YIGxh bmd1YWdlIChvbmUgZm9yIHRoZSBjb3JlIGxhbmd1YWdlIGFuZCBvbmUgZm9yIHRoZSBkZWZpbmVk IG9iamVjdHMpDQrigKIgICAgICAgIFRoZSBYTUwgU2NoZW1hIGhhcyBnb25lIHRocm91Z2ggZXh0 ZW5zaXZlIGltcHJvdmVtZW50cyBmb3IgZXhwcmVzc2l2ZW5lc3MsIGNsYXJpdHksIGNvbnNpc3Rl bmN5LCBlZmZpY2llbmN5LCBhbGlnbm1lbnQgdG8gZXhpc3Rpbmcgbm9ybWF0aXZlIHJlZmVyZW5j ZXMgYW5kIGRvY3VtZW50YXRpb24uDQrigKIgICAgICAgIFRoaXMgcmVsZWFzZSBpbmNsdWRlcyBh biBpbml0aWFsIHNldCBvZiBsYW5ndWFnZSB1dGlsaXRpZXM6IGEgZHJhZnQgU25vcnQgLT4gQ3li T1ggdHJhbnNmb3JtLCBhIGRyYWZ0IE9wZW5JT0MgLT4gQ3liT1ggdHJhbnNmb3JtLCBhbmQgYSBz ZXQgb2YgUHl0aG9uIGJpbmRpbmdzIGZvciB0aGUgQ3liT1ggbGFuZ3VhZ2UuDQoNCuKAoiAgICAg ICAgVGhlIHdlYnNpdGUgbm93IGluY2x1ZGVzIGEgc21hbGwgc2V0IG9mIGNvbnRlbnQgZXhhbXBs ZXMuIFRoaXMgc2V0IHdpbGwgZ3JvdyBnb2luZyBmb3J3YXJkLg0KVGhpcyByZWxlYXNlIGludm9s dmVkIGEgbG90IG9mIGhhcmQgd29yayBmcm9tIGEgZGl2ZXJzZSBncm91cCBvZiBwZW9wbGUuIFRo YW5rIHlvdSBhbGwgZm9yIHlvdXIgY29udHJpYnV0aW9ucyBhbmQgZWZmb3J0LiBXZSBjb3VsZCBu b3QgaGF2ZSBkb25lIGl0IHdpdGhvdXQgeW91Lg0KV2UgbG9vayBmb3J3YXJkIHRvIGV2ZXJ5b25l 4oCZcyBmZWVkYmFjayBhbmQgY29sbGFib3JhdGlvbiBhcyB3ZSBjb250aW51ZSB0byBpbXByb3Zl IGFuZCBtYXR1cmUgdGhlIEN5Yk9YIGxhbmd1YWdlLg0KDQpTZWFuIEJhcm51bQ0KDQoNCg0KDQpD eWJPWCB2MS4wIChEcmFmdCkgUmVsZWFzZSBOb3Rlcw0KVGhlIFZlcnNpb24gMS4wIChEcmFmdCkg cmVsZWFzZSBvZiBDeWJlciBPYnNlcnZhYmxlIGVYcHJlc3Npb24gKEN5Yk9Y4oSiKSBpcyBpbnRl bmRlZCBhcyBhIGRyYWZ0IHJlbGVhc2Ugb2YgYW4gaW5pdGlhbCBtYWpvciB2ZXJzaW9uIG9mIHRo ZSBDeWJPWCBMYW5ndWFnZSB0aGF0IGNvdWxkIGJlIHV0aWxpemVkIGZvciBwcmFjdGljYWwgb3Bl cmF0aW9uYWwgdXNlIGFuZCBpbnRlZ3JhdGlvbiBpbnRvIG90aGVyIHN0YW5kYXJkcyBlZmZvcnRz LiBUaGlzIHJlbGVhc2UgY29uc2lzdHMgb2YgdGhyZWUgcHJpbWFyeSBjb21wb25lbnRzOiBhIHBh aXIgb2YgZm9ybWFsIGxhbmd1YWdlIHNwZWNpZmljYXRpb25zIGZvciB0aGUgY29yZSBsYW5ndWFn ZSBjb250ZW50IGFuZCBkZWZpbmVkIG9iamVjdHMgY29udGVudCwgYSBzZXQgb2YgbGFuZ3VhZ2Ug aW1wbGVtZW50YXRpb24gWE1MIHNjaGVtYXMgKGNvcmUsIGNvbW1vbl90eXBlcywgYW5kIH43MCBk ZWZpbmVkIG9iamVjdCBzY2hlbWFzKSwgYW5kIGEgc21hbGwgaW5pdGlhbCBzZXQgb2YgbGFuZ3Vh Z2UgdXRpbGl0aWVzIGluY2x1ZGluZyBhbiBpbml0aWFsIGRyYWZ0IFNub3J0LT5DeWJPWCB0cmFu c2Zvcm0sIGFuIGluaXRpYWwgZHJhZnQgT3BlbklPQy0+Q3liT1ggdHJhbnNmb3JtIGFuZCBhIHNl dCBvZiBDeWJPWCBsYW5ndWFnZSBQeXRob24gYmluZGluZ3MuIFJlY29nbml6aW5nIHRoYXQgdGhp cyBpcyB0aGUgZmlyc3QgdGltZSB0aGF0IHRoZSBmb3JtYWwgbGFuZ3VhZ2Ugc3BlY2lmaWNhdGlv bnMgd2lsbCBiZSBhdmFpbGFibGUgZm9yIHJldmlldyBhbmQgYXMgc3VjaCB3aWxsIGxpa2VseSBn ZW5lcmF0ZSBmZWVkYmFjayBmcm9tIG5ldyBzdGFrZWhvbGRlcnMsIHRoaXMgaW5pdGlhbCBtYWpv ciB2ZXJzaW9uIGlzIGJlaW5nIHJlbGVhc2VkIGFzIGEg4oCcZHJhZnTigJ0gdjEuMCB3aXRoIHRo ZSBleHBlY3RhdGlvbiBvZiBjeWNsZXMgb2YgbmV3IGZlZWRiYWNrIGFuZCByZXZpc2lvbiBiZWZv cmUgYSDigJxmaW5hbOKAnSB2MS4wIGlzIHJlbGVhc2VkLg0KVGhlIEN5Yk9YIHYxLjAgKERyYWZ0 KSBYTUwgc2NoZW1hcyBpbmNsdWRlIGEgc2lnbmlmaWNhbnQgbnVtYmVyIG9mIGNoYW5nZXMgZnJv bSB2MC43IHRvIGltcHJvdmU6DQrigKIgICAgICAgQ2xhcml0eSwgZG9jdW1lbnRhdGlvbiwgYW5k IGRlc2NyaXB0aXZlIGZvcm1hbGl0eSBmb3IgcmVmZXJlbmNlIGFuZCBpbXBsZW1lbnRhdGlvbiBi eSBvdGhlciBzdGFuZGFyZHMgYW5kIHVzZXJzLg0K4oCiICAgICAgIENvbnNpc3RlbmN5LCBzaW1w bGljaXR5LCBhbmQgZWZmaWNpZW5jeS4NCuKAoiAgICAgICBBbGlnbm1lbnQgKGFzIGFwcHJvcHJp YXRlKSB0byBleGlzdGluZyBub3JtYXRpdmUgcmVmZXJlbmNlcy4NCg0K4oCiICAgICAgIEV4cHJl c3NpdmVuZXNzIG9mIHRoZSBzY2hlbWEgdG8gYmV0dGVyIHN1cHBvcnQgdGhlIGJyb2FkIHNldCBv ZiB1c2UgY2FzZXMgaXQgdGFyZ2V0cyAobWFsd2FyZSBjaGFyYWN0ZXJpemF0aW9uLCBpbmRpY2F0 b3IgYW5kIGluY2lkZW50IGRhdGEgc2hhcmluZywgZXZlbnQgbWFuYWdlbWVudCwgZXRjLikgaW5j bHVkaW5nIHRoZSBhZGRpdGlvbiBvZiBhbiBpbml0aWFsIHNldCBvZiBuZXR3b3JrLXJlbGF0ZWQg ZGVmaW5lZCBvYmplY3RzLg0KU3VtbWFyeSBvZiBjaGFuZ2VzIGZyb20gQ3liT1hfdjAuNyB0byBD eWJPWF92MS4wXyhEcmFmdCk6DQrCtyAgICAgICBSZWZpbmVtZW50IG9mIG5hbWVzcGFjZXMgYW5k IHNjaGVtYSBsb2NhdGlvbnMgZm9yIGJldHRlciBlZmZlY3RpdmVuZXNzIGFuZCBmbGV4aWJpbGl0 eSBnb2luZyBmb3J3YXJkLg0KwrcgICAgICAgTm9ybWFsaXplZCBhbGwgY29udGVudCBhY2NvcmRp bmcgdG8gYW4gZXN0YWJsaXNoZWQgc2V0IG9mIG5hbWluZyBjb252ZW50aW9ucy4NCsK3ICAgICAg IEZ1bGx5IGFubm90YXRlZCBhbGwgbGFuZ3VhZ2UgaXRlbXMgKHR5cGVzLCBhdHRyaWJ1dGVzLCBl bGVtZW50cywgZXRjLikuDQrCtyAgICAgICBNb3ZlZCBzZXZlcmFsIGNvbW1vbmx5IGxldmVyYWdl ZCB0eXBlcyBvdXQgb2YgdGhlIGNvcmUgc2NoZW1hIGFuZCBpbnRvIGNvbW1vbl90eXBlcy4NCsK3 ICAgICAgIEFjaGlldmVkIGZ1bGwgdHlwaW5nIG9mIGVudGlyZSBzY2hlbWEgc3RydWN0dXJlIHN1 Y2ggdGhhdCBhbGwgYXR0cmlidXRlcyBhbmQgZWxlbWVudHMgYXJlIGRlZmluaXRpdmVseSB0eXBl ZC4NCsK3ICAgICAgIENoYW5nZWQgYWxsIGlkZW50aWZpZXJzIGZyb20gSUQgYW5kIElEUkVGIHR5 cGVzIHRvIGJlIFFOYW1lcyBlbmFibGluZyBnbG9iYWxseSB1bmlxdWUgaWRlbnRpZmllcnMgYW5k IGZsZXhpYmlsaXR5IGZvciBkb21haW4tc3BlY2lmaWMgdXNlcnMgb2YgQ3liT1ggdG8gZGVmaW5l IHRoZWlyIG93biBpZGVudGlmaWVyIHN5bnRheCBsb2NhbGx5Lg0KwrcgICAgICAgUmVvcmRlcmVk IGF0dHJpYnV0ZXMgYW5kIGVsZW1lbnRzIGluIG51bWVyb3VzIHR5cGVzIHRvIGJldHRlciByZWZs ZWN0IGNvbW1vbiB1c2FnZSBhbmQgcHJpb3JpdHkuDQrCtyAgICAgICBBZGRlZCBtYWpvcl92ZXJz aW9uIGFuZCBtaW5vcl92ZXJzaW9uIGF0dHJpYnV0ZXMgZm9yIGNvcmUgc2NoZW1hLg0KwrcgICAg ICAgQWRkZWQgY2FwYWJpbGl0eSB0byBjaGFyYWN0ZXJpemUgc291cmNlIG9mIG92ZXJhbGwgb2Jz ZXJ2YWJsZSBwYWNrYWdlIGRhdGEgYW5kIGZvciBpbmRpdmlkdWFsIG9ic2VydmFibGVzLg0Kwrcg ICAgICAgTW9kaWZpZWQgdGhlIGxvZ2ljYWwgY29tcG9zaXRpb24gc3RydWN0dXJlIHN1Y2ggdGhh dCBhbnkgc3VjaCBjb21wb3NpdGlvbnMgYXJlIG5vdyBjb250YWluZWQgd2l0aGluIGEgT2JzZXJ2 YWJsZV9Db21wb3NpdGlvbiBlbGVtZW50IHByb3ZpZGluZyBpbXByb3ZlZCBzaW1wbGljaXR5IGFu ZCBtb2R1bGFyaXR5Lg0KwrcgICAgICAgUmVtb3ZlZCB0aGUgRGVsdGEgZWxlbWVudCBmcm9tIE9i c2VydmFibGVUeXBlIGFuZCByZWxvY2F0ZWQgdGhlIGFwcHJvcHJpYXRlIHBvcnRpb25zIChDaGFu Z2UsIFRyZW5kLCBhbmQgRnJlcXVlbmN5KSB0byBhcHByb3ByaWF0ZSBsb2NhdGlvbnMgdW5kZXIg U3RhdGVmdWxfTWVhc3VyZSBhbmQgRXZlbnQuDQrCtyAgICAgICBBZGRlZCBhIERvbWFpbl9TcGVj aWZpY19PYmplY3RfQXR0cmlidXRlcyBmaWVsZCB0byBPYmplY3QgdXRpbGl6aW5nIGFuIGFic3Ry YWN0IHR5cGUgdGhhdCB3aWxsIGFsbG93IGRvbWFpbi1zcGVjaWZpYyB1c2UgY2FzZXMgdG8gYWRk IGluIHRoZWlyIG93biBkb21haW4tc3BlY2lmaWMgYXR0cmlidXRlcyBmb3IgT2JqZWN0cy4NCsK3 ICAgICAgIEFkZGVkIGEgVG9vbC1TcGVjaWZpY19EYXRhIGZpZWxkIHRvIFRvb2xJbmZvcm1hdGlv blR5cGUgdXRpbGl6aW5nIGFuIGFic3RyYWN0IHR5cGUgdGhhdCB3aWxsIGFsbG93IGFkZGl0aW9u IG9mIHRvb2wtc3BlY2lmaWMgZGF0YS4NCsK3ICAgICAgIEFkZGVkIGFuIEluZGljYXRvcnMgZmll bGQgdG8gTWVhc3VyZVNvdXJjZVR5cGUgdXRpbGl6aW5nIGFuIGFic3RyYWN0IHR5cGUgdGhhdCB3 aWxsIGFsbG93IGNoYXJhY3Rlcml6aW5nIGRpZmZlcmluZyBmb3JtYXRzIG9yIHN0YW5kYXJkcyBv ZiBpbmRpY2F0b3JzIHRoYXQgbWF5IGhhdmUgbGVkIHRvIHRoZSBpZGVudGlmaWNhdGlvbiBvZiB0 aGUgb2JzZXJ2YWJsZSBkYXRhLg0KwrcgICAgICAgRW5oYW5jZWQgdGhlIEhhc2ggc3RydWN0dXJl IHRvIGNhcHR1cmUgZnVsbCBmdXp6eSBoYXNoZXMgaW4gYWRkaXRpb24gdG8gc2ltcGxlIGhhc2hl cw0KwrcgICAgICAgQWRkZWQgYSBuZXcgRXh0cmFjdGVkRmVhdHVyZXNUeXBlIHRoYXQgY2FuIGJl IHVzZWQgdG8gYWRvcm4gZGlmZmVyaW5nIG9iamVjdHMgKGUuZy4sIGZpbGVzLCBtZW1vcnksIGV0 Yy4pIHRvIGNhcHR1cmUgZXh0cmFjdGVkIHN0cmluZ3MsIGltcG9ydHMsIGZ1bmN0aW9ucyBhbmQg Y29kZSBzbmlwcGV0cw0KwrcgICAgICAgQWRkZWQgYSBCeXRlUnVuc1R5cGUgdG8gZW5hYmxlIGNh cHR1cmUgb2YgYnl0ZSBydW5zIHdpdGhpbiB2YXJpb3VzIG9iamVjdHMuDQrCtyAgICAgICBBZGRl ZCBvYmplY3RfcmVmZXJlbmNlIGF0dHJpYnV0ZSB0byBEZWZpbmVkT2JqZWN0VHlwZSB0byBiZXR0 ZXIgc3VwcG9ydCByZWZlcmVuY2luZyBvZiBpbmRlcGVuZGVudGx5IGRlZmluZWQgT2JqZWN0cyBm cm9tIHdpdGhpbiBhbm90aGVyIE9iamVjdCBkZWZpbml0aW9uLg0KwrcgICAgICAgQWRkZWQgYSBn ZW5lcmljIERhdGFTZWdtZW50VHlwZSB0byBwcm92aWRlIGEgcmVsYXRpdmVseSBhYnN0cmFjdCB3 YXkgb2YgY2hhcmFjdGVyaXppbmcgZGF0YSBzZWdtZW50cyB0aGF0IG1heSBiZSB3cml0dGVuL3Jl YWQvdHJhbnNtaXR0ZWQgb3Igb3RoZXJ3aXNlIHV0aWxpemVkIGluIGFjdGlvbnMgb3IgZGVmaW5l ZCBpbiBvYmplY3RzLg0K4oCiICAgICAgICBBZGRlZCBzZXZlcmFsIG5ldyBkZWZpbmVkIG9iamVj dCBzY2hlbWFzIChBUEksIENvZGUsIERldmljZSwgRE5TX1JlY29yZCwgTmV0d29ya19GbG93LCBO ZXR3b3JrX1BhY2tldCwgTmV0d29ya19Sb3V0ZV9FbnRyeSwgTmV0d29ya19TdWJuZXQsIFVuaXhf TmV0d29ya19Sb3V0ZV9FbnRyeSkgaW5jbHVkaW5nIGFuIGluaXRpYWwgc2V0IG9mIG5ldHdvcmst Y2VudHJpYyBkZWZpbmVkIG9iamVjdHMuDQrCtyAgICAgICBNb2RpZmllZCBldmVyeSBkZWZpbmVk IG9iamVjdCBzY2hlbWEgd2l0aCBhZGRlZCBhbm5vdGF0aW9ucyBhcyB3ZWxsIGFzIG1pbm9yIGFu ZCBpbiBzb21lIGNhc2VzIHN1YnN0YW50aXZlIGNoYW5nZXMgdG8gZml4IGVycm9ycywgaW1wcm92 ZSBjb25zaXN0ZW5jeSBhbmQgYWxpZ25tZW50IHdpdGggZXhpc3Rpbmcgbm9ybWF0aXZlIHJlZmVy ZW5jZXMsIGFuZCB0byBpbXByb3ZlIGV4cHJlc3NpdmVuZXNzIGluIHN1cHBvcnQgb2YgdGhlIHRh cmdldGVkIHVzZSBjYXNlcy4NCkRldGFpbGVkIGNoYW5nZXMgZnJvbSBDeWJPWF92MC43IHRvIEN5 Yk9YX3YxLjBfKERyYWZ0KToNClRoZSBsZXZlbCBvZiBjaGFuZ2VzIHdpdGhpbiB2MS4wIChEcmFm dCkgaW4gdGhlIGNvcmUgc2NoZW1hLCBjb21tb25fdHlwZXMgYW5kIHRoZSBkZWZpbmVkIG9iamVj dCBzY2hlbWFzIGlzIHRvbyBncmVhdCB0byBsaXN0IGV2ZXJ5IGNoYW5nZSBpbiB0aGVzZSByZWxl YXNlIG5vdGVzLiBEZXRhaWxlZCBkaWZmZXJlbmNlIHJlcG9ydHMgYXJlIGF2YWlsYWJsZSBmb3Ig ZWFjaCBpbmRpdmlkdWFsIHNjaGVtYSBhdDpodHRwOi8vY3lib3gubWl0cmUub3JnL1hNTFNjaGVt YS9yZWxlYXNlX25vdGVzL2N5Ym94X3YxLjAoZHJhZnQpX2RpZmZfcmVwb3J0cy56aXANCg0KDQo9 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KU2VhbiBCYXJu dW0NCkN5YmVyIFNlY3VyaXR5IFByaW5jaXBhbA0KVGhlIE1JVFJFIENvcnBvcmF0aW9uDQpFbWFp bDogc2Jhcm51bUBtaXRyZS5vcmc8bWFpbHRvOnNiYXJudW1AbWl0cmUub3JnPg0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbWlsZSBtYWlsaW5nIGxp c3QNCm1pbGVAaWV0Zi5vcmc8bWFpbHRvOm1pbGVAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL21pbGUNCg0K From michael.hammer@yaanatech.com Tue Apr 17 07:50:39 2012 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 0A3DD11E80A3; Tue, 17 Apr 2012 07:50:39 -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=[AWL=0.000, 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 8bfb7T1r+CKd; Tue, 17 Apr 2012 07:50:33 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id C8D4311E80A2; Tue, 17 Apr 2012 07:50:33 -0700 (PDT) Received: from EX2K10MB1.corp.yaanatech.com ([fe80::5568:c31d:f64a:f66a]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Tue, 17 Apr 2012 07:50:33 -0700 From: Michael Hammer To: "kathleen.moriarty@emc.com" , "sbarnum@mitre.org" , "osantos@cisco.com" , "Thomas.Millar@hq.dhs.gov" , "lnunez@c3isecurity.com" Thread-Topic: [mile] [sacm] CybOX v1.0 (Draft) is now released and live onthe website Thread-Index: AQHNHFhQtpFrr+nGFkWqCWY68NIgupae/ygAgAAIhWOAAA7hYA== Date: Tue, 17 Apr 2012 14:50:32 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB389FDB7@EX2K10MB1.corp.yaanatech.com> References: <7F48813B48558A4BB5CB7BB714E5B5A9171B16@IMCMBX03.MITRE.ORG> <69CE2DCD9DAC3D48B830E0723141170B02A39BD2@ZAU1UG-0308.DHSNET.DS1.DHS> <953A2E460DBE7C43AC13E30B87C5B4FF080A1C09@XMB-RCD-106.cisco.com> <7F48813B48558A4BB5CB7BB714E5B5A9171BA1@IMCMBX03.MITRE.ORG>, <00C069FD01E0324C9FFCADF539701DB389FC37@EX2K10MB1.corp.yaanatech.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.88.19] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0029_01CD1C87.E844FB50" MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 17 Apr 2012 08:22:36 -0700 Cc: "idxwg@nicwg.org" , "mile@ietf.org" , "dallendoug@gmail.com" , "sacm@ietf.org" , "m-terada@ipa.go.jp" Subject: Re: [mile] [sacm] CybOX v1.0 (Draft) is now released and live onthe website 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, 17 Apr 2012 14:50:39 -0000 ------=_NextPart_000_0029_01CD1C87.E844FB50 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Kathleen, Not sure of the way forward, but comparing data sets could help produce = a more uniform, normalized one. I'm still trying to absorb this. Great work by the way. I did a scan of the words flow, network, and packet to see how often and = where they appeared. It seems that flow is the odd one, while network and packet seem scoped = to the whole protocol stack with parallel elements in different parts of = the core doc. So, I didn't see the low level (L1-L3) versus high level (L4-L7) = distinction there. The network protocol list seems to cover all layers. BTW, wondering if the non-exhaustive protocol list is intended to be = extended in the future to call out others at some point. Also, agree discussion is good one to have. Helps me to understand = better. Mike -----Original Message----- From: kathleen.moriarty@emc.com [mailto:kathleen.moriarty@emc.com]=20 Sent: Tuesday, April 17, 2012 10:01 AM To: Michael Hammer; sbarnum@mitre.org; osantos@cisco.com; = Thomas.Millar@hq.dhs.gov; lnunez@c3isecurity.com Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; = m-terada@ipa.go.jp Subject: RE: [mile] [sacm] CybOX v1.0 (Draft) is now released and live = onthe website Hi Mike, Are you suggesting to just include the NetConf schema and allow that to = evolve and pull it in where appropriate? That makes sense to me... For = IODEF, right now you would use the Flow class and could optionally use = NetConf using the AdditionalData to include another schema. Although we = don't have NetConf in the SCI draft, that raises a good point for MILE = to consider (if there is a gap in schema or guidance). Or to include = this in the IODEF guidance document so we have an agreed way to handle = this use case consistently between implementations. SACM is thinking = about the relationships between management protocols and security = automation specifications in the base use case, so that should help in = that space. Understanding the use cases for CybOX and flows may help to understand = why we may need the representation directly in the specification as = opposed to referencing NetConf. Sean? Thanks, Kathleen ________________________________________ From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of Michael = Hammer [michael.hammer@yaanatech.com] Sent: Tuesday, April 17, 2012 9:17 AM To: sbarnum@mitre.org; osantos@cisco.com; Thomas.Millar@hq.dhs.gov; = lnunez@c3isecurity.com Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; = m-terada@ipa.go.jp Subject: Re: [mile] [sacm] CybOX v1.0 (Draft) is now released and live = onthe website Sean, Does the overlap between the various objects present a problem? If there are one or more objects that could carry the same data, then = human nature means that probability-wise someone will choose data flow = instead of Netflow. That is the underlying principle in Murphy=E2=80=99s Law, where you try = to design it so that there is only one way to do it, and thus private = Murphy won=E2=80=99t do it the =E2=80=9Cwrong=E2=80=9D way. Just wondering if these should be mutually exclusive sets. And designed = as such. Might improve interoperability. (And avoid discussions like this in = future.) =E2=98=BA Mike From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of = Barnum, Sean D. Sent: Tuesday, April 17, 2012 1:10 AM To: Omar Santos (osantos); Millar, Thomas; lnunez@c3isecurity.com Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; = m-terada@ipa.go.jp Subject: Re: [mile] [sacm] CybOX v1.0 (Draft) is now released and live = onthe website =E2=80=9Cupper layer=E2=80=9D? Yes, as in higher abstraction. Just =E2=80=9Cprotocols=E2=80=9D? No. You guys have been looking at this through the lens of network flow = which if fine for thinking about that perspective but it is important to = also realize that the EventTypeEnum and its =E2=80=9CData Flow=E2=80=9D = value go far beyond network-related scope. It is about a lot of other types of potential data flows (as I just = outlined in a response to Tom) that have nothing to do with network = flow. Thanks for your response though. This is the kind of discussions that we = hope to have a lot more of among the various supported communities. BTW, you may have noticed that the Network_Flow object within CybOX v1.0 = (Draft) supports expression of netflow within several of the most common = formats including Netflow9 (as well as IPFIX as Luis pointed out, = Netflow5 and SiLK as well as bi-directional flow in YAF). The common = 5-tuple or 7-tuple (you describe) (in our case it is an 8-tuple as we = broke the router interface out into both ingress and egress =E2=98=BA) = shared by pretty much all of the netflow approaches has been broken out = into a shared Network_Flow_Label structure. The various = context-dependent portions of the independent approaches are then = captured within optional structures dedicated to each of them. We hope = that eventually the community can work to come together towards a single = overall common expressive structure for netflow that meets the needs of = all. We hope that CybOX and its use can even help that sort of = maturation and normalization. But since no such universal structure = exists today, we decided to enable optional expression of the most = common individual formats within a single netflow object to serve the = large majority of relevant users, maintain flexibility and enable = discussions and analysis of netflow within a common package. We look forward to continuing discussions with the community to validate = or invalidate this approach and to refine and mature going forward. Sean From: Omar Santos (osantos) = [mailto:osantos@cisco.com] Sent: Monday, April 16, 2012 11:57 PM To: Millar, Thomas; Barnum, Sean D.; = lnunez@c3isecurity.com Cc: idxwg@nicwg.org; = mile@ietf.org; = dallendoug@gmail.com; = sacm@ietf.org; = m-terada@ipa.go.jp Subject: RE: [sacm] [mile] CybOX v1.0 (Draft) is now released and live = onthe website I believe that what Sean is saying is that =E2=80=9Cdata flow=E2=80=9D = is just a value that is meant for upper layer protocols. But, you have a = good point. Traditionally, a =E2=80=9Cflow=E2=80=9D in = =E2=80=9CNetflow=E2=80=9D is based on a set of 5 and up to 7 IP packet = attributes: - IP source address - IP destination address - Source port - Destination port - Layer 3 protocol type - Class of Service - Router or switch interface Although, there is a lot more support with Netflow version 9: http://www.cisco.com/en/US/technologies/tk648/tk362/technologies_white_pa= per09186a00800a3db9_ps6601_Products_White_Paper.html Regards, Omar From: Millar, Thomas = [mailto:Thomas.Millar@hq.dhs.gov] Sent: Monday, April 16, 2012 11:46 PM To: sbarnum@mitre.org; Omar Santos (osantos); = lnunez@c3isecurity.com Cc: idxwg@nicwg.org; = mile@ietf.org; = dallendoug@gmail.com; = sacm@ietf.org; = m-terada@ipa.go.jp Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live = onthe website If "data flow" is a euphemism for "netflow" is there any reason not to = call it that? Tom Millar http://www.us-cert.gov/ ------------------ Missit me Rubus fruticosus: 202 631 1915 From: Barnum, Sean D. = [mailto:sbarnum@mitre.org] Sent: Monday, April 16, 2012 11:29 PM To: Omar Santos (osantos) >; = Luis Nunez > Cc: idxwg@nicwg.org = >; = mile@ietf.org = >; = dallendoug@gmail.com = >; = sacm@ietf.org = >; = m-terada@ipa.go.jp = > Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live = onthe website Thanks Omar. To answer your question, first let me point out to other readers that = the two entries that Omar is quoting here exist as values in an = enumeration called EventTypeEnum which as its name implies contains a = list of different labels for grouping types (or classes) of events to be = used as low-granularity buckets for characterizing and classifying = events. Other entries in this enumeration include things like =E2=80=9CFile Ops = (CRUD)=E2=80=9D, =E2=80=9CProcess Mgt=E2=80=9D, =E2=80=9CAuthorization = (ACL)=E2=80=9D, etc. The =E2=80=9CPacket Traffic=E2=80=9D value is intended to characterize = events dealing with network packet traffic as its name implies. The =E2=80=9CData Flow=E2=80=9D value is intended to characterize events = dealing with forms of data flow at a higher level of abstraction than = just packet traffic. The relationship between these two values could be = viewed as =E2=80=9CPacket Traffic=E2=80=9D being a more detailed form of = =E2=80=9CData Flow=E2=80=9D just as the values =E2=80=9CApp Layer = Traffic=E2=80=9D and =E2=80=9CHTTP Layer Traffic=E2=80=9D, also in this = enumeration, could be other levels in this same abstraction stack. The idea behind the varying levels of abstraction is to leave buckets = large enough to capture a wide variety of potential event types (e.g. = data flow events other than obvious things like packet traffic) but also = enable the use of smaller more specific buckets when they are = appropriate and commonly used. Does this make sense? sean From: Omar Santos (osantos) = [mailto:osantos@cisco.com] Sent: Monday, April 16, 2012 8:17 PM To: Luis Nunez; Barnum, Sean D. Cc: idxwg@nicwg.org; = mile@ietf.org; = dallendoug@gmail.com; = sacm@ietf.org; = m-terada@ipa.go.jp Subject: RE: [sacm] [mile] CybOX v1.0 (Draft) is now released and live = onthe website I echo Luis=E2=80=99 comments. It is good to see the inclusion of = network objects. Quick question to the team related to your netflow = comment. I am looking at: http://cybox.mitre.org/XMLSchema/cybox_core_v1.0%28draft%29.xsd =E2=80=A6 and it looks that we renamed it to =E2=80=9CData = Flow=E2=80=9D? Specifies the class of events dealing with = data flow. What is the difference between that and =E2=80=9CPacket = Traffic=E2=80=9D? Specifies the class of events dealing with packet = traffic. Regards, Omar Santos Incident Manager, PSIRT Security Research and Operations Cisco Systems, Inc. Email: os@cisco.com Phone: +1 919 392 8635 PGP Key: 0x3AF27EDC Cisco.com - http://www.cisco.com Cisco Security Advisories and Notices - http://www.cisco.com/go/psirt This email may contain confidential and privileged material for the sole = use of the intended recipient. Any review, use, distribution or = disclosure by others is strictly prohibited. If you are not the intended = recipient (or authorized to receive for the recipient), please contact = the sender by reply email and delete all copies of this message. For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From: sacm-bounces@ietf.org = [mailto:sacm-bounces@ietf.org] On = Behalf Of Luis Nunez Sent: Monday, April 16, 2012 6:44 PM To: Barnum, Sean D. Cc: idxwg@nicwg.org; = mile@ietf.org; Doug Wilson = (dallendoug@gmail.com); = sacm@ietf.org; IPA-Masato Terada = (m-terada@ipa.go.jp) Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live = onthe website I like the inclusion of the network-centric objects. IPFIX (netflow) = will add an additional perspective from an incident information sharing = standpoint. -ln On Apr 16, 2012, at 4:04 PM, Barnum, Sean D. wrote: Hey everyone, I just wanted to let you all know that CybOX v1.0 (Draft) content is now = live on the website. http://cybox.mitre.org The release notes are = provided inline below. The key items of note are: =E2=80=A2 The release of two formal specifications for the CybOX = language (one for the core language and one for the defined objects) =E2=80=A2 The XML Schema has gone through extensive improvements = for expressiveness, clarity, consistency, efficiency, alignment to = existing normative references and documentation. =E2=80=A2 This release includes an initial set of language = utilities: a draft Snort -> CybOX transform, a draft OpenIOC -> CybOX = transform, and a set of Python bindings for the CybOX language. =E2=80=A2 The website now includes a small set of content = examples. This set will grow going forward. This release involved a lot of hard work from a diverse group of people. = Thank you all for your contributions and effort. We could not have done = it without you. We look forward to everyone=E2=80=99s feedback and collaboration as we = continue to improve and mature the CybOX language. Sean Barnum CybOX v1.0 (Draft) Release Notes The Version 1.0 (Draft) release of Cyber Observable eXpression = (CybOX=E2=84=A2) is intended as a draft release of an initial major = version of the CybOX Language that could be utilized for practical = operational use and integration into other standards efforts. This = release consists of three primary components: a pair of formal language = specifications for the core language content and defined objects = content, a set of language implementation XML schemas (core, = common_types, and ~70 defined object schemas), and a small initial set = of language utilities including an initial draft Snort->CybOX transform, = an initial draft OpenIOC->CybOX transform and a set of CybOX language = Python bindings. Recognizing that this is the first time that the formal = language specifications will be available for review and as such will = likely generate feedback from new stakeholders, this initial major = version is being released as a =E2=80=9Cdraft=E2=80=9D v1.0 with the = expectation of cycles of new feedback and revision before a = =E2=80=9Cfinal=E2=80=9D v1.0 is released. The CybOX v1.0 (Draft) XML schemas include a significant number of = changes from v0.7 to improve: =E2=80=A2 Clarity, documentation, and descriptive formality for = reference and implementation by other standards and users. =E2=80=A2 Consistency, simplicity, and efficiency. =E2=80=A2 Alignment (as appropriate) to existing normative = references. =E2=80=A2 Expressiveness of the schema to better support the broad = set of use cases it targets (malware characterization, indicator and = incident data sharing, event management, etc.) including the addition of = an initial set of network-related defined objects. Summary of changes from CybOX_v0.7 to CybOX_v1.0_(Draft): =C2=B7 Refinement of namespaces and schema locations for better = effectiveness and flexibility going forward. =C2=B7 Normalized all content according to an established set of = naming conventions. =C2=B7 Fully annotated all language items (types, attributes, = elements, etc.). =C2=B7 Moved several commonly leveraged types out of the core = schema and into common_types. =C2=B7 Achieved full typing of entire schema structure such that = all attributes and elements are definitively typed. =C2=B7 Changed all identifiers from ID and IDREF types to be = QNames enabling globally unique identifiers and flexibility for = domain-specific users of CybOX to define their own identifier syntax = locally. =C2=B7 Reordered attributes and elements in numerous types to = better reflect common usage and priority. =C2=B7 Added major_version and minor_version attributes for core = schema. =C2=B7 Added capability to characterize source of overall = observable package data and for individual observables. =C2=B7 Modified the logical composition structure such that any = such compositions are now contained within a Observable_Composition = element providing improved simplicity and modularity. =C2=B7 Removed the Delta element from ObservableType and relocated = the appropriate portions (Change, Trend, and Frequency) to appropriate = locations under Stateful_Measure and Event. =C2=B7 Added a Domain_Specific_Object_Attributes field to Object = utilizing an abstract type that will allow domain-specific use cases to = add in their own domain-specific attributes for Objects. =C2=B7 Added a Tool-Specific_Data field to ToolInformationType = utilizing an abstract type that will allow addition of tool-specific = data. =C2=B7 Added an Indicators field to MeasureSourceType utilizing an = abstract type that will allow characterizing differing formats or = standards of indicators that may have led to the identification of the = observable data. =C2=B7 Enhanced the Hash structure to capture full fuzzy hashes in = addition to simple hashes =C2=B7 Added a new ExtractedFeaturesType that can be used to adorn = differing objects (e.g., files, memory, etc.) to capture extracted = strings, imports, functions and code snippets =C2=B7 Added a ByteRunsType to enable capture of byte runs within = various objects. =C2=B7 Added object_reference attribute to DefinedObjectType to = better support referencing of independently defined Objects from within = another Object definition. =C2=B7 Added a generic DataSegmentType to provide a relatively = abstract way of characterizing data segments that may be = written/read/transmitted or otherwise utilized in actions or defined in = objects. =E2=80=A2 Added several new defined object schemas (API, Code, = Device, DNS_Record, Network_Flow, Network_Packet, Network_Route_Entry, = Network_Subnet, Unix_Network_Route_Entry) including an initial set of = network-centric defined objects. =C2=B7 Modified every defined object schema with added annotations = as well as minor and in some cases substantive changes to fix errors, = improve consistency and alignment with existing normative references, = and to improve expressiveness in support of the targeted use cases. Detailed changes from CybOX_v0.7 to CybOX_v1.0_(Draft): The level of changes within v1.0 (Draft) in the core schema, = common_types and the defined object schemas is too great to list every = change in these release notes. Detailed difference reports are available = for each individual schema = at:http://cybox.mitre.org/XMLSchema/release_notes/cybox_v1.0(draft)_diff_= reports.zip =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Sean Barnum Cyber Security Principal The MITRE Corporation Email: sbarnum@mitre.org _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile ------=_NextPart_000_0029_01CD1C87.E844FB50 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP6zCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggTXMIIDv6ADAgECAhBcX1ns/Jl/DtI19/BXCcuBMA0G CSqGSIb3DQEBBQUAMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMwHhcNMTIwNDAzMDAwMDAwWhcNMTMwNDAzMjM1OTU5WjCCAR4xFzAVBgNVBAoTDlZl cmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13 d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChj KTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNDAyBgNVBAsTK0RpZ2l0YWwgSUQg Q2xhc3MgMSAtIE1pY3Jvc29mdCBGdWxsIFNlcnZpY2UxFzAVBgNVBAMUDk1pY2hhZWwgSGFtbWVy MSswKQYJKoZIhvcNAQkBFhxtaWNoYWVsLmhhbW1lckB5YWFuYXRlY2guY29tMIGfMA0GCSqGSIb3 DQEBAQUAA4GNADCBiQKBgQDoKTk9rP/4lG6CLqIR4++IFTuOSLF6bmhDr6eiSahqU0VNP+H/LbiD MAZsK9GQoBYPKQdKzy/gM+fl3Gm6VOdjKl8M3GB6LGgAK8d3ETN5dyKe5CAG7EEbKg9wxHWcuXW7 KYd052ven5Ec+Xj++v3HsE423O5q2mNh1Q8FNsnlXQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYD VR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2ln bi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYD VR0fBEkwRzBFoEOgQYY/aHR0cDovL2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20v SW5kQzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQA8rhDezFsw7OlR3+mZOZ39 SCKWNJ4gMlQEe31NNtvs6BUzE1uN+fJeZrJ5zjTdJWeG1NgVugcuzQfdv/m5BYbhgJvNfW6ElqZh cye6imOUx8diekkeHXKYSLnEvCdJItXsC1h/huIT9e83WksM92qI/TFyCq6u39cGf9PaBYbcKcZk jHjNi3SPnGifMC6opGiiyK/vB1lituoBRcJ13Y7XoXA8T0kSR8Dtmqvo1JudcFAbS1srytG1QX1H XTsPkTDKHlwv2ZfmCSKK3sWHDrZfpRglxvcX2OwibcKVkKBJRRw36UuJOIj/u0WYABcYtusAb2+0 nqoGmOEYARnrseTZMIIG7jCCBdagAwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUF ADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZv ciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQ cmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkw NDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP 6bGNQU4099oL42r6ZYggCxET6ZvgSU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYH r54UGAdPWr2f0jGyVBlzRmoZQhHsEnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50 ABMN0Ibak2f4MwOuGjxraXj2wCyO4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yx BF6+wbaULZeQLSfSux7pg2qE9sSyriMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ 6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CG SAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYI KwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6Al hiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYI KwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQ UjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1Ud EQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EI Qf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4 BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkx RTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZ gbWpBbVSOOk5hIls5DSoWufYbAlMJBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v 8dKBl8pUWkO/N4t6jhmND0OojPKvYLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM6 1a4ScAjr+zvid+zoK2Q1ds262uDRyxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/ XLJtSd5lUkL7DojS7Uodv0vj+Mxy+kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4 VRaMxmgD5yKocwuxvKDaUljdCg5/wYIxggS4MIIEtAIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTsw OQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykw OTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI19/BXCcuBMAkGBSsO AwIaBQCgggMbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQx NzE0NTAzMFowIwYJKoZIhvcNAQkEMRYEFIcWIjUG99t0AcZtLuUzvqfOue7EMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIIBAwYJKwYB BAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMCEFxfWez8mX8O0jX38FcJy4EwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkG A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24u Y29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5W ZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI1 9/BXCcuBMA0GCSqGSIb3DQEBAQUABIGAXmyAZl2LQ8G3vaY1OnQCALvIIPfAh5XiZ5q/YFRiOL3l QPddwTYg/DNMc35q/B1ZS/8tRpCmVHpR4fVvW6zQfuw9Rj1vuNJ0AcKtLiv56y46pGXg+Ow35AM7 n031+h4en0+txrWdq2zazySDwowEVQNxZEVGiY9Z6u5A0digmBMAAAAAAAA= ------=_NextPart_000_0029_01CD1C87.E844FB50-- From michael.hammer@yaanatech.com Tue Apr 17 08:25:03 2012 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 6932511E809D for ; Tue, 17 Apr 2012 08:25:03 -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=[AWL=0.000, 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 Q3qP3OtCqsV8 for ; Tue, 17 Apr 2012 08:24:58 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 3646311E8080 for ; Tue, 17 Apr 2012 08:24:58 -0700 (PDT) Received: from EX2K10MB1.corp.yaanatech.com ([fe80::5568:c31d:f64a:f66a]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Tue, 17 Apr 2012 08:24:58 -0700 From: Michael Hammer To: "mile@ietf.org" Thread-Topic: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe website Thread-Index: AQHNHKoMfTftTf+gHUmgkwlV5OTpPpafIs/A Date: Tue, 17 Apr 2012 15:24:57 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB389FE86@EX2K10MB1.corp.yaanatech.com> References: <7F48813B48558A4BB5CB7BB714E5B5A9171B16@IMCMBX03.MITRE.ORG> <69CE2DCD9DAC3D48B830E0723141170B02A39BD2@ZAU1UG-0308.DHSNET.DS1.DHS> <953A2E460DBE7C43AC13E30B87C5B4FF080A1C09@XMB-RCD-106.cisco.com> <7F48813B48558A4BB5CB7BB714E5B5A9171BA1@IMCMBX03.MITRE.ORG>, <00C069FD01E0324C9FFCADF539701DB389FC37@EX2K10MB1.corp.yaanatech.com> <00C069FD01E0324C9FFCADF539701DB389FDB7@EX2K10MB1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB389FDB7@EX2K10MB1.corp.yaanatech.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.88.19] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0036_01CD1C8C.B6ECE4F0" MIME-Version: 1.0 Subject: [mile] FW: [sacm] CybOX v1.0 (Draft) is now released and live onthe website 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, 17 Apr 2012 15:25:03 -0000 ------=_NextPart_000_0036_01CD1C8C.B6ECE4F0 Content-Type: multipart/mixed; boundary="----=_NextPart_001_0037_01CD1C8C.B6ECE4F0" ------=_NextPart_001_0037_01CD1C8C.B6ECE4F0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Re-posting. Was informed this didn't make it to mile list. Mike -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of = Michael Hammer Sent: Tuesday, April 17, 2012 10:51 AM To: kathleen.moriarty@emc.com; sbarnum@mitre.org; osantos@cisco.com; = Thomas.Millar@hq.dhs.gov; lnunez@c3isecurity.com Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; = m-terada@ipa.go.jp Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live = onthe website Kathleen, Not sure of the way forward, but comparing data sets could help produce = a more uniform, normalized one. I'm still trying to absorb this. Great work by the way. I did a scan of the words flow, network, and packet to see how often and = where they appeared. It seems that flow is the odd one, while network and packet seem scoped = to the whole protocol stack with parallel elements in different parts of = the core doc. So, I didn't see the low level (L1-L3) versus high level (L4-L7) = distinction there. The network protocol list seems to cover all layers. BTW, wondering if the non-exhaustive protocol list is intended to be = extended in the future to call out others at some point. Also, agree discussion is good one to have. Helps me to understand = better. Mike -----Original Message----- From: kathleen.moriarty@emc.com [mailto:kathleen.moriarty@emc.com]=20 Sent: Tuesday, April 17, 2012 10:01 AM To: Michael Hammer; sbarnum@mitre.org; osantos@cisco.com; = Thomas.Millar@hq.dhs.gov; lnunez@c3isecurity.com Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; = m-terada@ipa.go.jp Subject: RE: [mile] [sacm] CybOX v1.0 (Draft) is now released and live = onthe website Hi Mike, Are you suggesting to just include the NetConf schema and allow that to = evolve and pull it in where appropriate? That makes sense to me... For = IODEF, right now you would use the Flow class and could optionally use = NetConf using the AdditionalData to include another schema. Although we = don't have NetConf in the SCI draft, that raises a good point for MILE = to consider (if there is a gap in schema or guidance). Or to include = this in the IODEF guidance document so we have an agreed way to handle = this use case consistently between implementations. SACM is thinking = about the relationships between management protocols and security = automation specifications in the base use case, so that should help in = that space. Understanding the use cases for CybOX and flows may help to understand = why we may need the representation directly in the specification as = opposed to referencing NetConf. Sean? Thanks, Kathleen ________________________________________ From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of Michael = Hammer [michael.hammer@yaanatech.com] Sent: Tuesday, April 17, 2012 9:17 AM To: sbarnum@mitre.org; osantos@cisco.com; Thomas.Millar@hq.dhs.gov; = lnunez@c3isecurity.com Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; = m-terada@ipa.go.jp Subject: Re: [mile] [sacm] CybOX v1.0 (Draft) is now released and live = onthe website Sean, Does the overlap between the various objects present a problem? If there are one or more objects that could carry the same data, then = human nature means that probability-wise someone will choose data flow = instead of Netflow. That is the underlying principle in Murphy=E2=80=99s Law, where you try = to design it so that there is only one way to do it, and thus private = Murphy won=E2=80=99t do it the =E2=80=9Cwrong=E2=80=9D way. Just wondering if these should be mutually exclusive sets. And designed = as such. Might improve interoperability. (And avoid discussions like this in = future.) =E2=98=BA Mike From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of = Barnum, Sean D. Sent: Tuesday, April 17, 2012 1:10 AM To: Omar Santos (osantos); Millar, Thomas; lnunez@c3isecurity.com Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; = m-terada@ipa.go.jp Subject: Re: [mile] [sacm] CybOX v1.0 (Draft) is now released and live = onthe website =E2=80=9Cupper layer=E2=80=9D? Yes, as in higher abstraction. Just =E2=80=9Cprotocols=E2=80=9D? No. You guys have been looking at this through the lens of network flow = which if fine for thinking about that perspective but it is important to = also realize that the EventTypeEnum and its =E2=80=9CData Flow=E2=80=9D = value go far beyond network-related scope. It is about a lot of other types of potential data flows (as I just = outlined in a response to Tom) that have nothing to do with network = flow. Thanks for your response though. This is the kind of discussions that we = hope to have a lot more of among the various supported communities. BTW, you may have noticed that the Network_Flow object within CybOX v1.0 = (Draft) supports expression of netflow within several of the most common = formats including Netflow9 (as well as IPFIX as Luis pointed out, = Netflow5 and SiLK as well as bi-directional flow in YAF). The common = 5-tuple or 7-tuple (you describe) (in our case it is an 8-tuple as we = broke the router interface out into both ingress and egress =E2=98=BA) = shared by pretty much all of the netflow approaches has been broken out = into a shared Network_Flow_Label structure. The various = context-dependent portions of the independent approaches are then = captured within optional structures dedicated to each of them. We hope = that eventually the community can work to come together towards a single = overall common expressive structure for netflow that meets the needs of = all. We hope that CybOX and its use can even help that sort of = maturation and normalization. But since no such universal structure = exists today, we decided to enable optional expression of the most = common individual formats within a single netflow object to serve the = large majority of relevant users, maintain flexibility and enable = discussions and analysis of netflow within a common package. We look forward to continuing discussions with the community to validate = or invalidate this approach and to refine and mature going forward. Sean From: Omar Santos (osantos) = [mailto:osantos@cisco.com] Sent: Monday, April 16, 2012 11:57 PM To: Millar, Thomas; Barnum, Sean D.; = lnunez@c3isecurity.com Cc: idxwg@nicwg.org; = mile@ietf.org; = dallendoug@gmail.com; = sacm@ietf.org; = m-terada@ipa.go.jp Subject: RE: [sacm] [mile] CybOX v1.0 (Draft) is now released and live = onthe website I believe that what Sean is saying is that =E2=80=9Cdata flow=E2=80=9D = is just a value that is meant for upper layer protocols. But, you have a = good point. Traditionally, a =E2=80=9Cflow=E2=80=9D in = =E2=80=9CNetflow=E2=80=9D is based on a set of 5 and up to 7 IP packet = attributes: - IP source address - IP destination address - Source port - Destination port - Layer 3 protocol type - Class of Service - Router or switch interface Although, there is a lot more support with Netflow version 9: http://www.cisco.com/en/US/technologies/tk648/tk362/technologies_white_pa= per09186a00800a3db9_ps6601_Products_White_Paper.html Regards, Omar From: Millar, Thomas = [mailto:Thomas.Millar@hq.dhs.gov] Sent: Monday, April 16, 2012 11:46 PM To: sbarnum@mitre.org; Omar Santos (osantos); = lnunez@c3isecurity.com Cc: idxwg@nicwg.org; = mile@ietf.org; = dallendoug@gmail.com; = sacm@ietf.org; = m-terada@ipa.go.jp Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live = onthe website If "data flow" is a euphemism for "netflow" is there any reason not to = call it that? Tom Millar http://www.us-cert.gov/ ------------------ Missit me Rubus fruticosus: 202 631 1915 From: Barnum, Sean D. = [mailto:sbarnum@mitre.org] Sent: Monday, April 16, 2012 11:29 PM To: Omar Santos (osantos) >; = Luis Nunez > Cc: idxwg@nicwg.org = >; = mile@ietf.org = >; = dallendoug@gmail.com = >; = sacm@ietf.org = >; = m-terada@ipa.go.jp = > Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live = onthe website Thanks Omar. To answer your question, first let me point out to other readers that = the two entries that Omar is quoting here exist as values in an = enumeration called EventTypeEnum which as its name implies contains a = list of different labels for grouping types (or classes) of events to be = used as low-granularity buckets for characterizing and classifying = events. Other entries in this enumeration include things like =E2=80=9CFile Ops = (CRUD)=E2=80=9D, =E2=80=9CProcess Mgt=E2=80=9D, =E2=80=9CAuthorization = (ACL)=E2=80=9D, etc. The =E2=80=9CPacket Traffic=E2=80=9D value is intended to characterize = events dealing with network packet traffic as its name implies. The =E2=80=9CData Flow=E2=80=9D value is intended to characterize events = dealing with forms of data flow at a higher level of abstraction than = just packet traffic. The relationship between these two values could be = viewed as =E2=80=9CPacket Traffic=E2=80=9D being a more detailed form of = =E2=80=9CData Flow=E2=80=9D just as the values =E2=80=9CApp Layer = Traffic=E2=80=9D and =E2=80=9CHTTP Layer Traffic=E2=80=9D, also in this = enumeration, could be other levels in this same abstraction stack. The idea behind the varying levels of abstraction is to leave buckets = large enough to capture a wide variety of potential event types (e.g. = data flow events other than obvious things like packet traffic) but also = enable the use of smaller more specific buckets when they are = appropriate and commonly used. Does this make sense? sean From: Omar Santos (osantos) = [mailto:osantos@cisco.com] Sent: Monday, April 16, 2012 8:17 PM To: Luis Nunez; Barnum, Sean D. Cc: idxwg@nicwg.org; = mile@ietf.org; = dallendoug@gmail.com; = sacm@ietf.org; = m-terada@ipa.go.jp Subject: RE: [sacm] [mile] CybOX v1.0 (Draft) is now released and live = onthe website I echo Luis=E2=80=99 comments. It is good to see the inclusion of = network objects. Quick question to the team related to your netflow = comment. I am looking at: http://cybox.mitre.org/XMLSchema/cybox_core_v1.0%28draft%29.xsd =E2=80=A6 and it looks that we renamed it to =E2=80=9CData = Flow=E2=80=9D? Specifies the class of events dealing with = data flow. What is the difference between that and =E2=80=9CPacket = Traffic=E2=80=9D? Specifies the class of events dealing with packet = traffic. Regards, Omar Santos Incident Manager, PSIRT Security Research and Operations Cisco Systems, Inc. Email: os@cisco.com Phone: +1 919 392 8635 PGP Key: 0x3AF27EDC Cisco.com - http://www.cisco.com Cisco Security Advisories and Notices - http://www.cisco.com/go/psirt This email may contain confidential and privileged material for the sole = use of the intended recipient. Any review, use, distribution or = disclosure by others is strictly prohibited. If you are not the intended = recipient (or authorized to receive for the recipient), please contact = the sender by reply email and delete all copies of this message. For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From: sacm-bounces@ietf.org = [mailto:sacm-bounces@ietf.org] On = Behalf Of Luis Nunez Sent: Monday, April 16, 2012 6:44 PM To: Barnum, Sean D. Cc: idxwg@nicwg.org; = mile@ietf.org; Doug Wilson = (dallendoug@gmail.com); = sacm@ietf.org; IPA-Masato Terada = (m-terada@ipa.go.jp) Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live = onthe website I like the inclusion of the network-centric objects. IPFIX (netflow) = will add an additional perspective from an incident information sharing = standpoint. -ln On Apr 16, 2012, at 4:04 PM, Barnum, Sean D. wrote: Hey everyone, I just wanted to let you all know that CybOX v1.0 (Draft) content is now = live on the website. http://cybox.mitre.org The release notes are = provided inline below. The key items of note are: =E2=80=A2 The release of two formal specifications for the CybOX = language (one for the core language and one for the defined objects) =E2=80=A2 The XML Schema has gone through extensive improvements = for expressiveness, clarity, consistency, efficiency, alignment to = existing normative references and documentation. =E2=80=A2 This release includes an initial set of language = utilities: a draft Snort -> CybOX transform, a draft OpenIOC -> CybOX = transform, and a set of Python bindings for the CybOX language. =E2=80=A2 The website now includes a small set of content = examples. This set will grow going forward. This release involved a lot of hard work from a diverse group of people. = Thank you all for your contributions and effort. We could not have done = it without you. We look forward to everyone=E2=80=99s feedback and collaboration as we = continue to improve and mature the CybOX language. Sean Barnum CybOX v1.0 (Draft) Release Notes The Version 1.0 (Draft) release of Cyber Observable eXpression = (CybOX=E2=84=A2) is intended as a draft release of an initial major = version of the CybOX Language that could be utilized for practical = operational use and integration into other standards efforts. This = release consists of three primary components: a pair of formal language = specifications for the core language content and defined objects = content, a set of language implementation XML schemas (core, = common_types, and ~70 defined object schemas), and a small initial set = of language utilities including an initial draft Snort->CybOX transform, = an initial draft OpenIOC->CybOX transform and a set of CybOX language = Python bindings. Recognizing that this is the first time that the formal = language specifications will be available for review and as such will = likely generate feedback from new stakeholders, this initial major = version is being released as a =E2=80=9Cdraft=E2=80=9D v1.0 with the = expectation of cycles of new feedback and revision before a = =E2=80=9Cfinal=E2=80=9D v1.0 is released. The CybOX v1.0 (Draft) XML schemas include a significant number of = changes from v0.7 to improve: =E2=80=A2 Clarity, documentation, and descriptive formality for = reference and implementation by other standards and users. =E2=80=A2 Consistency, simplicity, and efficiency. =E2=80=A2 Alignment (as appropriate) to existing normative = references. =E2=80=A2 Expressiveness of the schema to better support the broad = set of use cases it targets (malware characterization, indicator and = incident data sharing, event management, etc.) including the addition of = an initial set of network-related defined objects. Summary of changes from CybOX_v0.7 to CybOX_v1.0_(Draft): =C2=B7 Refinement of namespaces and schema locations for better = effectiveness and flexibility going forward. =C2=B7 Normalized all content according to an established set of = naming conventions. =C2=B7 Fully annotated all language items (types, attributes, = elements, etc.). =C2=B7 Moved several commonly leveraged types out of the core = schema and into common_types. =C2=B7 Achieved full typing of entire schema structure such that = all attributes and elements are definitively typed. =C2=B7 Changed all identifiers from ID and IDREF types to be = QNames enabling globally unique identifiers and flexibility for = domain-specific users of CybOX to define their own identifier syntax = locally. =C2=B7 Reordered attributes and elements in numerous types to = better reflect common usage and priority. =C2=B7 Added major_version and minor_version attributes for core = schema. =C2=B7 Added capability to characterize source of overall = observable package data and for individual observables. =C2=B7 Modified the logical composition structure such that any = such compositions are now contained within a Observable_Composition = element providing improved simplicity and modularity. =C2=B7 Removed the Delta element from ObservableType and relocated = the appropriate portions (Change, Trend, and Frequency) to appropriate = locations under Stateful_Measure and Event. =C2=B7 Added a Domain_Specific_Object_Attributes field to Object = utilizing an abstract type that will allow domain-specific use cases to = add in their own domain-specific attributes for Objects. =C2=B7 Added a Tool-Specific_Data field to ToolInformationType = utilizing an abstract type that will allow addition of tool-specific = data. =C2=B7 Added an Indicators field to MeasureSourceType utilizing an = abstract type that will allow characterizing differing formats or = standards of indicators that may have led to the identification of the = observable data. =C2=B7 Enhanced the Hash structure to capture full fuzzy hashes in = addition to simple hashes =C2=B7 Added a new ExtractedFeaturesType that can be used to adorn = differing objects (e.g., files, memory, etc.) to capture extracted = strings, imports, functions and code snippets =C2=B7 Added a ByteRunsType to enable capture of byte runs within = various objects. =C2=B7 Added object_reference attribute to DefinedObjectType to = better support referencing of independently defined Objects from within = another Object definition. =C2=B7 Added a generic DataSegmentType to provide a relatively = abstract way of characterizing data segments that may be = written/read/transmitted or otherwise utilized in actions or defined in = objects. =E2=80=A2 Added several new defined object schemas (API, Code, = Device, DNS_Record, Network_Flow, Network_Packet, Network_Route_Entry, = Network_Subnet, Unix_Network_Route_Entry) including an initial set of = network-centric defined objects. =C2=B7 Modified every defined object schema with added annotations = as well as minor and in some cases substantive changes to fix errors, = improve consistency and alignment with existing normative references, = and to improve expressiveness in support of the targeted use cases. Detailed changes from CybOX_v0.7 to CybOX_v1.0_(Draft): The level of changes within v1.0 (Draft) in the core schema, = common_types and the defined object schemas is too great to list every = change in these release notes. Detailed difference reports are available = for each individual schema = at:http://cybox.mitre.org/XMLSchema/release_notes/cybox_v1.0(draft)_diff_= reports.zip =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Sean Barnum Cyber Security Principal The MITRE Corporation Email: sbarnum@mitre.org _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile ------=_NextPart_001_0037_01CD1C8C.B6ECE4F0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-ID: <1B9F303BA6868B469202FEDDD332B80C@corp.yaanatech.com> Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP6zCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggTXMIIDv6ADAgECAhBcX1ns/Jl/DtI19/BXCcuBMA0G CSqGSIb3DQEBBQUAMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMwHhcNMTIwNDAzMDAwMDAwWhcNMTMwNDAzMjM1OTU5WjCCAR4xFzAVBgNVBAoTDlZl cmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13 d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChj KTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNDAyBgNVBAsTK0RpZ2l0YWwgSUQg Q2xhc3MgMSAtIE1pY3Jvc29mdCBGdWxsIFNlcnZpY2UxFzAVBgNVBAMUDk1pY2hhZWwgSGFtbWVy MSswKQYJKoZIhvcNAQkBFhxtaWNoYWVsLmhhbW1lckB5YWFuYXRlY2guY29tMIGfMA0GCSqGSIb3 DQEBAQUAA4GNADCBiQKBgQDoKTk9rP/4lG6CLqIR4++IFTuOSLF6bmhDr6eiSahqU0VNP+H/LbiD MAZsK9GQoBYPKQdKzy/gM+fl3Gm6VOdjKl8M3GB6LGgAK8d3ETN5dyKe5CAG7EEbKg9wxHWcuXW7 KYd052ven5Ec+Xj++v3HsE423O5q2mNh1Q8FNsnlXQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYD VR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2ln bi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYD VR0fBEkwRzBFoEOgQYY/aHR0cDovL2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20v SW5kQzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQA8rhDezFsw7OlR3+mZOZ39 SCKWNJ4gMlQEe31NNtvs6BUzE1uN+fJeZrJ5zjTdJWeG1NgVugcuzQfdv/m5BYbhgJvNfW6ElqZh cye6imOUx8diekkeHXKYSLnEvCdJItXsC1h/huIT9e83WksM92qI/TFyCq6u39cGf9PaBYbcKcZk jHjNi3SPnGifMC6opGiiyK/vB1lituoBRcJ13Y7XoXA8T0kSR8Dtmqvo1JudcFAbS1srytG1QX1H XTsPkTDKHlwv2ZfmCSKK3sWHDrZfpRglxvcX2OwibcKVkKBJRRw36UuJOIj/u0WYABcYtusAb2+0 nqoGmOEYARnrseTZMIIG7jCCBdagAwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUF ADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZv ciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQ cmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkw NDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP 6bGNQU4099oL42r6ZYggCxET6ZvgSU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYH r54UGAdPWr2f0jGyVBlzRmoZQhHsEnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50 ABMN0Ibak2f4MwOuGjxraXj2wCyO4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yx BF6+wbaULZeQLSfSux7pg2qE9sSyriMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ 6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CG SAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYI KwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6Al hiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYI KwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQ UjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1Ud EQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EI Qf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4 BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkx RTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZ gbWpBbVSOOk5hIls5DSoWufYbAlMJBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v 8dKBl8pUWkO/N4t6jhmND0OojPKvYLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM6 1a4ScAjr+zvid+zoK2Q1ds262uDRyxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/ XLJtSd5lUkL7DojS7Uodv0vj+Mxy+kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4 VRaMxmgD5yKocwuxvKDaUljdCg5/wYIxggS4MIIEtAIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTsw OQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykw OTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI19/BXCcuBMAkGBSsO AwIaBQCgggMbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQx NzE0NTAzMFowIwYJKoZIhvcNAQkEMRYEFIcWIjUG99t0AcZtLuUzvqfOue7EMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIIBAwYJKwYB BAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMCEFxfWez8mX8O0jX38FcJy4EwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkG A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24u Y29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5W ZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI1 9/BXCcuBMA0GCSqGSIb3DQEBAQUABIGAXmyAZl2LQ8G3vaY1OnQCALvIIPfAh5XiZ5q/YFRiOL3l QPddwTYg/DNMc35q/B1ZS/8tRpCmVHpR4fVvW6zQfuw9Rj1vuNJ0AcKtLiv56y46pGXg+Ow35AM7 n031+h4en0+txrWdq2zazySDwowEVQNxZEVGiY9Z6u5A0digmBMAAAAAAAA= ------=_NextPart_001_0037_01CD1C8C.B6ECE4F0 Content-Type: text/plain; name="ATT00001.txt" Content-Transfer-Encoding: 7bit Content-ID: <9D3185270EB8DA46A5482869016F34A2@corp.yaanatech.com> Content-Disposition: attachment; filename="ATT00001.txt" _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm ------=_NextPart_001_0037_01CD1C8C.B6ECE4F0-- ------=_NextPart_000_0036_01CD1C8C.B6ECE4F0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP6zCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggTXMIIDv6ADAgECAhBcX1ns/Jl/DtI19/BXCcuBMA0G CSqGSIb3DQEBBQUAMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMwHhcNMTIwNDAzMDAwMDAwWhcNMTMwNDAzMjM1OTU5WjCCAR4xFzAVBgNVBAoTDlZl cmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13 d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChj KTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNDAyBgNVBAsTK0RpZ2l0YWwgSUQg Q2xhc3MgMSAtIE1pY3Jvc29mdCBGdWxsIFNlcnZpY2UxFzAVBgNVBAMUDk1pY2hhZWwgSGFtbWVy MSswKQYJKoZIhvcNAQkBFhxtaWNoYWVsLmhhbW1lckB5YWFuYXRlY2guY29tMIGfMA0GCSqGSIb3 DQEBAQUAA4GNADCBiQKBgQDoKTk9rP/4lG6CLqIR4++IFTuOSLF6bmhDr6eiSahqU0VNP+H/LbiD MAZsK9GQoBYPKQdKzy/gM+fl3Gm6VOdjKl8M3GB6LGgAK8d3ETN5dyKe5CAG7EEbKg9wxHWcuXW7 KYd052ven5Ec+Xj++v3HsE423O5q2mNh1Q8FNsnlXQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYD VR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2ln bi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYD VR0fBEkwRzBFoEOgQYY/aHR0cDovL2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20v SW5kQzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQA8rhDezFsw7OlR3+mZOZ39 SCKWNJ4gMlQEe31NNtvs6BUzE1uN+fJeZrJ5zjTdJWeG1NgVugcuzQfdv/m5BYbhgJvNfW6ElqZh cye6imOUx8diekkeHXKYSLnEvCdJItXsC1h/huIT9e83WksM92qI/TFyCq6u39cGf9PaBYbcKcZk jHjNi3SPnGifMC6opGiiyK/vB1lituoBRcJ13Y7XoXA8T0kSR8Dtmqvo1JudcFAbS1srytG1QX1H XTsPkTDKHlwv2ZfmCSKK3sWHDrZfpRglxvcX2OwibcKVkKBJRRw36UuJOIj/u0WYABcYtusAb2+0 nqoGmOEYARnrseTZMIIG7jCCBdagAwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUF ADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZv ciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQ cmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkw NDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP 6bGNQU4099oL42r6ZYggCxET6ZvgSU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYH r54UGAdPWr2f0jGyVBlzRmoZQhHsEnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50 ABMN0Ibak2f4MwOuGjxraXj2wCyO4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yx BF6+wbaULZeQLSfSux7pg2qE9sSyriMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ 6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CG SAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYI KwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6Al hiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYI KwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQ UjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1Ud EQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EI Qf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4 BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkx RTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZ gbWpBbVSOOk5hIls5DSoWufYbAlMJBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v 8dKBl8pUWkO/N4t6jhmND0OojPKvYLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM6 1a4ScAjr+zvid+zoK2Q1ds262uDRyxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/ XLJtSd5lUkL7DojS7Uodv0vj+Mxy+kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4 VRaMxmgD5yKocwuxvKDaUljdCg5/wYIxggS4MIIEtAIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTsw OQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykw OTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI19/BXCcuBMAkGBSsO AwIaBQCgggMbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQx NzE1MjQ1NVowIwYJKoZIhvcNAQkEMRYEFDBTA0HWHExg3W0xaViYVcKjQvDkMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIIBAwYJKwYB BAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMCEFxfWez8mX8O0jX38FcJy4EwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkG A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24u Y29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5W ZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI1 9/BXCcuBMA0GCSqGSIb3DQEBAQUABIGATOiFrNR+lzxhhcOoGwmwQKwWdLu+jD+DCTV3cFFGNdVK p1MshnwFkk5ADoWm22dbhbJOGopvPyspzWNoESnlonEbVyDR/XtgVOkNjhBzzVX5gkXgHml4KMbD OHLCq9hU6YcsZs2w1Kp4HVN+WY/x026kl4JlY+sXs3Z4FFlSc8QAAAAAAAA= ------=_NextPart_000_0036_01CD1C8C.B6ECE4F0-- From sbarnum@mitre.org Tue Apr 17 12:02:40 2012 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 951B821F854B; Tue, 17 Apr 2012 12:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MXW1fRzVR2re; Tue, 17 Apr 2012 12:02:35 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id DA1E221F8548; Tue, 17 Apr 2012 12:02:34 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 4322421B112F; Tue, 17 Apr 2012 15:02:34 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 34C8521B112C; Tue, 17 Apr 2012 15:02:34 -0400 (EDT) Received: from IMCMBX03.MITRE.ORG ([169.254.3.179]) by IMCCAS01.MITRE.ORG ([129.83.29.78]) with mapi id 14.02.0283.003; Tue, 17 Apr 2012 15:02:33 -0400 From: "Barnum, Sean D." To: Michael Hammer , "osantos@cisco.com" , "Thomas.Millar@hq.dhs.gov" , "lnunez@c3isecurity.com" Thread-Topic: [mile] [sacm] CybOX v1.0 (Draft) is now released and live onthe website Thread-Index: AQHNHJx9CTO+wm8DM0KsuNMXzL3C5ZafV3hg Date: Tue, 17 Apr 2012 19:02:32 +0000 Message-ID: <7F48813B48558A4BB5CB7BB714E5B5A9173046@IMCMBX03.MITRE.ORG> References: <7F48813B48558A4BB5CB7BB714E5B5A9171B16@IMCMBX03.MITRE.ORG> <69CE2DCD9DAC3D48B830E0723141170B02A39BD2@ZAU1UG-0308.DHSNET.DS1.DHS> <953A2E460DBE7C43AC13E30B87C5B4FF080A1C09@XMB-RCD-106.cisco.com> <7F48813B48558A4BB5CB7BB714E5B5A9171BA1@IMCMBX03.MITRE.ORG> <00C069FD01E0324C9FFCADF539701DB389FC37@EX2K10MB1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB389FC37@EX2K10MB1.corp.yaanatech.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.31.135.134] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_003E_01CD1CAB.18E81260" MIME-Version: 1.0 Cc: "idxwg@nicwg.org" , "mile@ietf.org" , "dallendoug@gmail.com" , "sacm@ietf.org" , "m-terada@ipa.go.jp" Subject: Re: [mile] [sacm] CybOX v1.0 (Draft) is now released and live onthe website 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, 17 Apr 2012 19:02:40 -0000 ------=_NextPart_000_003E_01CD1CAB.18E81260 Content-Type: multipart/alternative; boundary="----=_NextPart_001_003F_01CD1CAB.18E81260" ------=_NextPart_001_003F_01CD1CAB.18E81260 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Mike, =20 Just to clarify, all of our discussion so far about =E2=80=9CData = Flow=E2=80=9D and netflow were all in regards to an enumeration called = EventTypeEnum that simply lets you tag a cyber observable event with a = type label. It is metadata for an event description. The only object we have been talking about in any detail so far was the = Network_Flow object. These two topics are totally independent of each = other. There is no Data_Flow object. The abstraction overlap we have been discussing is only in the metadata = tag applied to an event to characterize what type/class of event it is. =20 The defined objects themselves (including Network_Flow) have been = designed to avoid, as much as possible, overlap of the type you = describe. The approach we have taken is that where there is common structure and = meaning relevant to multiple different types of objects, the structure = for that commonality is broken out into its own object (e.g. Address, = URI, Port, Account, Process, etc.). Content based on this common object structure can be embedded within a = leveraging object (via direct use of the object type) if the content is = directly relevant only within the context of that object or as an = independent object and associated to any number of other objects to = which it is relevant utilizing relationships. We make no guarantees that we have managed to implement this approach = flawlessly but we believe that it yields a good balance of consistency, = efficiency and flexibility. It also allows easy modular use of only what = is relevant within a given context and enables extension and evolution = to easily occur in a localized fashion rather than having to extend and = modify one monolithic structure standard. =20 Does that make sense? =20 sean =20 From: Michael Hammer [mailto:michael.hammer@yaanatech.com]=20 Sent: Tuesday, April 17, 2012 9:18 AM To: Barnum, Sean D.; osantos@cisco.com; Thomas.Millar@hq.dhs.gov; = lnunez@c3isecurity.com Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; = m-terada@ipa.go.jp Subject: RE: [mile] [sacm] CybOX v1.0 (Draft) is now released and live = onthe website =20 Sean, =20 Does the overlap between the various objects present a problem? =20 If there are one or more objects that could carry the same data, then = human nature means that probability-wise someone will choose data flow = instead of Netflow. That is the underlying principle in Murphy=E2=80=99s Law, where you try = to design it so that there is only one way to do it, and thus private = Murphy won=E2=80=99t do it the =E2=80=9Cwrong=E2=80=9D way. =20 Just wondering if these should be mutually exclusive sets. And designed = as such. Might improve interoperability. (And avoid discussions like this in = future.) J =20 Mike =20 =20 From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of = Barnum, Sean D. Sent: Tuesday, April 17, 2012 1:10 AM To: Omar Santos (osantos); Millar, Thomas; lnunez@c3isecurity.com Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; = m-terada@ipa.go.jp Subject: Re: [mile] [sacm] CybOX v1.0 (Draft) is now released and live = onthe website =20 =E2=80=9Cupper layer=E2=80=9D? Yes, as in higher abstraction. Just =E2=80=9Cprotocols=E2=80=9D? No. =20 You guys have been looking at this through the lens of network flow = which if fine for thinking about that perspective but it is important to = also realize that the EventTypeEnum and its =E2=80=9CData Flow=E2=80=9D = value go far beyond network-related scope. It is about a lot of other types of potential data flows (as I just = outlined in a response to Tom) that have nothing to do with network = flow. =20 Thanks for your response though. This is the kind of discussions that we = hope to have a lot more of among the various supported communities. =20 =20 BTW, you may have noticed that the Network_Flow object within CybOX v1.0 = (Draft) supports expression of netflow within several of the most common = formats including Netflow9 (as well as IPFIX as Luis pointed out, = Netflow5 and SiLK as well as bi-directional flow in YAF). The common = 5-tuple or 7-tuple (you describe) (in our case it is an 8-tuple as we = broke the router interface out into both ingress and egress J) shared by = pretty much all of the netflow approaches has been broken out into a = shared Network_Flow_Label structure. The various context-dependent = portions of the independent approaches are then captured within optional = structures dedicated to each of them. We hope that eventually the = community can work to come together towards a single overall common = expressive structure for netflow that meets the needs of all. We hope = that CybOX and its use can even help that sort of maturation and = normalization. But since no such universal structure exists today, we = decided to enable optional expression of the most common individual = formats within a single netflow object to serve the large majority of = relevant users, maintain flexibility and enable discussions and analysis = of netflow within a common package. We look forward to continuing discussions with the community to validate = or invalidate this approach and to refine and mature going forward. =20 Sean=20 =20 From: Omar Santos (osantos) [mailto:osantos@cisco.com]=20 Sent: Monday, April 16, 2012 11:57 PM To: Millar, Thomas; Barnum, Sean D.; lnunez@c3isecurity.com Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; = m-terada@ipa.go.jp Subject: RE: [sacm] [mile] CybOX v1.0 (Draft) is now released and live = onthe website =20 I believe that what Sean is saying is that =E2=80=9Cdata flow=E2=80=9D = is just a value that is meant for upper layer protocols. But, you have a = good point. Traditionally, a =E2=80=9Cflow=E2=80=9D in = =E2=80=9CNetflow=E2=80=9D is based on a set of 5 and up to 7 IP packet = attributes: =20 - IP source address - IP destination address - Source port - Destination port - Layer 3 protocol type - Class of Service - Router or switch interface =20 Although, there is a lot more support with Netflow version 9: http://www.cisco.com/en/US/technologies/tk648/tk362/technologies_white_pa= per09186a00800a3db9_ps6601_Products_White_Paper.html =20 =20 =20 Regards, Omar=20 =20 From: Millar, Thomas [mailto:Thomas.Millar@hq.dhs.gov]=20 Sent: Monday, April 16, 2012 11:46 PM To: sbarnum@mitre.org; Omar Santos (osantos); lnunez@c3isecurity.com Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; = m-terada@ipa.go.jp Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live = onthe website =20 If "data flow" is a euphemism for "netflow" is there any reason not to = call it that? Tom Millar=20 http://www.us-cert.gov/=20 ------------------=20 Missit me Rubus fruticosus:=20 202 631 1915=20 =20 From: Barnum, Sean D. [mailto:sbarnum@mitre.org]=20 Sent: Monday, April 16, 2012 11:29 PM To: Omar Santos (osantos) ; Luis Nunez = =20 Cc: idxwg@nicwg.org ; mile@ietf.org ; = dallendoug@gmail.com ; sacm@ietf.org = ; m-terada@ipa.go.jp =20 Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live = onthe website=20 =20 Thanks Omar. =20 To answer your question, first let me point out to other readers that = the two entries that Omar is quoting here exist as values in an = enumeration called EventTypeEnum which as its name implies contains a = list of different labels for grouping types (or classes) of events to be = used as low-granularity buckets for characterizing and classifying = events. Other entries in this enumeration include things like =E2=80=9CFile Ops = (CRUD)=E2=80=9D, =E2=80=9CProcess Mgt=E2=80=9D, =E2=80=9CAuthorization = (ACL)=E2=80=9D, etc. =20 The =E2=80=9CPacket Traffic=E2=80=9D value is intended to characterize = events dealing with network packet traffic as its name implies. The =E2=80=9CData Flow=E2=80=9D value is intended to characterize events = dealing with forms of data flow at a higher level of abstraction than = just packet traffic. The relationship between these two values could be = viewed as =E2=80=9CPacket Traffic=E2=80=9D being a more detailed form of = =E2=80=9CData Flow=E2=80=9D just as the values =E2=80=9CApp Layer = Traffic=E2=80=9D and =E2=80=9CHTTP Layer Traffic=E2=80=9D, also in this = enumeration, could be other levels in this same abstraction stack. The idea behind the varying levels of abstraction is to leave buckets = large enough to capture a wide variety of potential event types (e.g. = data flow events other than obvious things like packet traffic) but also = enable the use of smaller more specific buckets when they are = appropriate and commonly used. =20 Does this make sense?=20 =20 sean =20 From: Omar Santos (osantos) [mailto:osantos@cisco.com]=20 Sent: Monday, April 16, 2012 8:17 PM To: Luis Nunez; Barnum, Sean D. Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; = m-terada@ipa.go.jp Subject: RE: [sacm] [mile] CybOX v1.0 (Draft) is now released and live = onthe website =20 I echo Luis=E2=80=99 comments. It is good to see the inclusion of = network objects. Quick question to the team related to your netflow = comment. =20 I am looking at: http://cybox.mitre.org/XMLSchema/cybox_core_v1.0%28draft%29.xsd =20 =E2=80=A6 and it looks that we renamed it to =E2=80=9CData = Flow=E2=80=9D? =20 Specifies the class of events dealing with = data flow. =20 =20 What is the difference between that and =E2=80=9CPacket = Traffic=E2=80=9D? =20 Specifies the class of events dealing with packet = traffic. =20 =20 =20 =20 Regards, Omar Santos Incident Manager, PSIRT Security Research and Operations Cisco Systems, Inc. Email: os@cisco.com Phone: +1 919 392 8635 PGP Key: 0x3AF27EDC Cisco.com - http://www.cisco.com Cisco Security Advisories and Notices - http://www.cisco.com/go/psirt This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message. For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html =20 From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of = Luis Nunez Sent: Monday, April 16, 2012 6:44 PM To: Barnum, Sean D. Cc: idxwg@nicwg.org; mile@ietf.org; Doug Wilson (dallendoug@gmail.com); = sacm@ietf.org; IPA-Masato Terada (m-terada@ipa.go.jp) Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live = onthe website =20 I like the inclusion of the network-centric objects. IPFIX (netflow) = will add an additional perspective from an incident information sharing = standpoint. =20 =20 -ln =20 On Apr 16, 2012, at 4:04 PM, Barnum, Sean D. wrote: =20 Hey everyone, =20 I just wanted to let you all know that CybOX v1.0 (Draft) content is now = live on the website. http://cybox.mitre.org The release notes are provided inline below. The key items of note are: =C2=B7 The release of two formal specifications for the CybOX = language (one for the core language and one for the defined objects) =C2=B7 The XML Schema has gone through extensive improvements for = expressiveness, clarity, consistency, efficiency, alignment to existing = normative references and documentation. =C2=B7 This release includes an initial set of language = utilities: a draft Snort -> CybOX transform, a draft OpenIOC -> CybOX = transform, and a set of Python bindings for the CybOX language. =C2=B7 The website now includes a small set of content examples. = This set will grow going forward. This release involved a lot of hard work from a diverse group of people. = Thank you all for your contributions and effort. We could not have done = it without you. We look forward to everyone=E2=80=99s feedback and collaboration as we = continue to improve and mature the CybOX language. =20 Sean Barnum =20 =20 =20 CybOX v1.0 (Draft) Release Notes The Version 1.0 (Draft) release of Cyber Observable eXpression = (CybOX=E2=84=A2) is intended as a draft release of an initial major = version of the CybOX Language that could be utilized for practical = operational use and integration into other standards efforts. This = release consists of three primary components: a pair of formal language = specifications for the core language content and defined objects = content, a set of language implementation XML schemas (core, = common_types, and ~70 defined object schemas), and a small initial set = of language utilities including an initial draft Snort->CybOX transform, = an initial draft OpenIOC->CybOX transform and a set of CybOX language = Python bindings. Recognizing that this is the first time that the formal = language specifications will be available for review and as such will = likely generate feedback from new stakeholders, this initial major = version is being released as a =E2=80=9Cdraft=E2=80=9D v1.0 with the = expectation of cycles of new feedback and revision before a = =E2=80=9Cfinal=E2=80=9D v1.0 is released. The CybOX v1.0 (Draft) XML schemas include a significant number of = changes from v0.7 to improve: =C2=B7 Clarity, documentation, and descriptive formality for = reference and implementation by other standards and users. =C2=B7 Consistency, simplicity, and efficiency. =C2=B7 Alignment (as appropriate) to existing normative = references. =C2=B7 Expressiveness of the schema to better support the broad = set of use cases it targets (malware characterization, indicator and = incident data sharing, event management, etc.) including the addition of = an initial set of network-related defined objects. Summary of changes from CybOX_v0.7 to CybOX_v1.0_(Draft): =C2=B7 Refinement of namespaces and schema locations for better = effectiveness and flexibility going forward. =C2=B7 Normalized all content according to an established set of = naming conventions. =C2=B7 Fully annotated all language items (types, attributes, = elements, etc.). =C2=B7 Moved several commonly leveraged types out of the core = schema and into common_types. =C2=B7 Achieved full typing of entire schema structure such that = all attributes and elements are definitively typed. =C2=B7 Changed all identifiers from ID and IDREF types to be = QNames enabling globally unique identifiers and flexibility for = domain-specific users of CybOX to define their own identifier syntax = locally. =C2=B7 Reordered attributes and elements in numerous types to = better reflect common usage and priority. =C2=B7 Added major_version and minor_version attributes for core = schema. =C2=B7 Added capability to characterize source of overall = observable package data and for individual observables. =C2=B7 Modified the logical composition structure such that any = such compositions are now contained within a Observable_Composition = element providing improved simplicity and modularity. =C2=B7 Removed the Delta element from ObservableType and = relocated the appropriate portions (Change, Trend, and Frequency) to = appropriate locations under Stateful_Measure and Event. =C2=B7 Added a Domain_Specific_Object_Attributes field to Object = utilizing an abstract type that will allow domain-specific use cases to = add in their own domain-specific attributes for Objects. =C2=B7 Added a Tool-Specific_Data field to ToolInformationType = utilizing an abstract type that will allow addition of tool-specific = data. =C2=B7 Added an Indicators field to MeasureSourceType utilizing = an abstract type that will allow characterizing differing formats or = standards of indicators that may have led to the identification of the = observable data. =C2=B7 Enhanced the Hash structure to capture full fuzzy hashes = in addition to simple hashes =C2=B7 Added a new ExtractedFeaturesType that can be used to = adorn differing objects (e.g., files, memory, etc.) to capture extracted = strings, imports, functions and code snippets =C2=B7 Added a ByteRunsType to enable capture of byte runs within = various objects. =C2=B7 Added object_reference attribute to DefinedObjectType to = better support referencing of independently defined Objects from within = another Object definition. =C2=B7 Added a generic DataSegmentType to provide a relatively = abstract way of characterizing data segments that may be = written/read/transmitted or otherwise utilized in actions or defined in = objects. =C2=B7 Added several new defined object schemas (API, Code, = Device, DNS_Record, Network_Flow, Network_Packet, Network_Route_Entry, = Network_Subnet, Unix_Network_Route_Entry) including an initial set of = network-centric defined objects. =C2=B7 Modified every defined object schema with added = annotations as well as minor and in some cases substantive changes to = fix errors, improve consistency and alignment with existing normative = references, and to improve expressiveness in support of the targeted use = cases. Detailed changes from CybOX_v0.7 to CybOX_v1.0_(Draft): The level of changes within v1.0 (Draft) in the core schema, = common_types and the defined object schemas is too great to list every = change in these release notes. Detailed difference reports are available = for each individual schema at: = = http://cybox.mitre.org/XMLSchema/release_notes/cybox_v1.0(draft)_diff_rep= orts.zip =20 =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Sean Barnum Cyber Security Principal The MITRE Corporation Email: sbarnum@mitre.org =20 _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile =20 ------=_NextPart_001_003F_01CD1CAB.18E81260 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Mike,

 

Just to clarify, all of our discussion so far about =E2=80=9CData = Flow=E2=80=9D and netflow were all in regards to an enumeration called = EventTypeEnum that simply lets you tag a cyber observable event with a = type label. It is metadata for an event = description.

The only object we have been talking about in any detail so far was = the Network_Flow object. These two topics are totally independent of = each other. There is no Data_Flow object.

The abstraction overlap we have been discussing is only in the = metadata tag applied to an event to characterize what type/class of = event it is.

 

The defined objects themselves (including Network_Flow) have been = designed to avoid, as much as possible, overlap of the type you = describe.

The approach we have taken is that where there is common structure = and meaning relevant to multiple different types of objects, the = structure for that commonality is broken out into its own object (e.g. = Address, URI, Port, Account, Process, etc.).

Content based on this common object structure can be embedded within = a leveraging object (via direct use of the object type) if the content = is directly relevant only within the context of that object or as an = independent object and associated to any number of other objects to = which it is relevant utilizing relationships.

We make no guarantees that we have managed to implement this approach = flawlessly but we believe that it yields a good balance of consistency, = efficiency and flexibility. It also allows easy modular use of only what = is relevant within a given context and enables extension and evolution = to easily occur in a localized fashion rather than having to extend and = modify one monolithic structure standard.

 

Does that make sense?

 

sean

 

From:= = Michael Hammer [mailto:michael.hammer@yaanatech.com]
Sent: = Tuesday, April 17, 2012 9:18 AM
To: Barnum, Sean D.; = osantos@cisco.com; Thomas.Millar@hq.dhs.gov; = lnunez@c3isecurity.com
Cc: idxwg@nicwg.org; mile@ietf.org; = dallendoug@gmail.com; sacm@ietf.org; = m-terada@ipa.go.jp
Subject: RE: [mile] [sacm] CybOX v1.0 = (Draft) is now released and live onthe = website

 

Sean,

 

Does the overlap between the various objects present a = problem?

 

If there are one or more objects that could carry the same data, then = human nature means that probability-wise someone will choose data flow = instead of Netflow.

That is the underlying principle in Murphy=E2=80=99s Law, where you = try to design it so that there is only one way to do it, and thus = private Murphy won=E2=80=99t do it the =E2=80=9Cwrong=E2=80=9D = way.

 

Just wondering if these should be mutually exclusive sets.  And = designed as such.

Might improve interoperability.  (And avoid discussions like = this in future.)  J

 

Mike

 

 

From:= = mile-bounces@ietf.org [mailto:mile-bounces@ietf.= org] On Behalf Of Barnum, Sean D.
Sent: Tuesday, = April 17, 2012 1:10 AM
To: Omar Santos (osantos); Millar, = Thomas; lnunez@c3isecurity.com
C= c: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; m-terada@ipa.go.jp
Subject:<= /b> Re: [mile] [sacm] CybOX v1.0 (Draft) is now released and live onthe = website

 

=E2=80=9Cupper layer=E2=80=9D? Yes, as in higher = abstraction.

Just =E2=80=9Cprotocols=E2=80=9D? No.

 

You guys have been looking at this through the lens of network flow = which if fine for thinking about that perspective but it is important to = also realize that the EventTypeEnum and its =E2=80=9CData Flow=E2=80=9D = value go far beyond network-related scope.

It is about a lot of other types of potential data flows (as I just = outlined in a response to Tom) that have nothing to do with network = flow.

 

Thanks for your response though. This is the kind of discussions that = we hope to have a lot more of among the various supported = communities.

 

 

BTW, you may have noticed that the Network_Flow object within CybOX = v1.0 (Draft) supports expression of netflow within several of the most = common formats including Netflow9 (as well as IPFIX as Luis pointed out, = Netflow5 and SiLK as well as bi-directional flow in YAF). The common = 5-tuple or 7-tuple (you describe) (in our case it is an 8-tuple as we = broke the router interface out into both ingress and egress J) shared by pretty much all of the netflow approaches has been broken = out into a shared Network_Flow_Label structure. The various = context-dependent portions of the independent approaches are then = captured within optional structures dedicated to each of them. We hope = that eventually the community can work to come together towards a single = overall common expressive structure for netflow that meets the needs of = all. We hope that CybOX and its use can even help that sort of = maturation and normalization. But since no such universal structure = exists today, we decided to enable optional expression of the most = common individual formats within a single netflow object to serve the = large majority of relevant users, maintain flexibility and enable = discussions and analysis of netflow within a common = package.

We look forward to continuing discussions with the community to = validate or invalidate this approach and to refine and mature going = forward.

 

Sean

 

From:= = Omar Santos (osantos) [mailto:osantos@cisco.com]=
Sent: Monday, April 16, 2012 11:57 PM
To: Millar, = Thomas; Barnum, Sean D.; lnunez@c3isecurity.com
C= c: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; m-terada@ipa.go.jp
Subject:<= /b> RE: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe = website

 

I believe that what Sean is saying is that =E2=80=9Cdata = flow=E2=80=9D is just a value that is meant for upper layer protocols. = But, you have a good point. Traditionally, a =E2=80=9Cflow=E2=80=9D in = =E2=80=9CNetflow=E2=80=9D is based on a set of 5 and up to 7 IP packet = attributes:

 

- IP source address

- IP destination address

- Source port

- Destination port

- Layer 3 protocol type

- Class of Service

- Router or switch interface

 

Although, there is a lot more support with Netflow version = 9:

http://www.= cisco.com/en/US/technologies/tk648/tk362/technologies_white_paper09186a00= 800a3db9_ps6601_Products_White_Paper.html

 

 

 

Regards,

Omar

 

From:= = Millar, Thomas [mailto:Thomas.Millar@h= q.dhs.gov]
Sent: Monday, April 16, 2012 11:46 = PM
To: sbarnum@mitre.org; Omar Santos = (osantos); lnunez@c3isecurity.com
C= c: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; m-terada@ipa.go.jp
Subject:<= /b> Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe = website

 

If "data flow" is a euphemism for "netflow" is = there any reason not to call it that?

Tom Millar
http://www.us-cert.gov/ =
------------------
Missit me Rubus fruticosus:
202 631 1915 =

 

From<= /b>: = Barnum, Sean D. [mailto:sbarnum@mitre.org]=
Sent: Monday, April 16, 2012 11:29 PM
To: Omar = Santos (osantos) <osantos@cisco.com>; Luis Nunez = <lnunez@c3isecurity.com> =
Cc: idxwg@nicwg.org = <idxwg@nicwg.org>; mile@ietf.org <mile@ietf.org>; dallendoug@gmail.com <dallendoug@gmail.com>; sacm@ietf.org <sacm@ietf.org>; m-terada@ipa.go.jp <m-terada@ipa.go.jp> =
Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released = and live onthe website
 

Thanks Omar.

 

To answer your question, first let me point out to other readers that = the two entries that Omar is quoting here exist as values in an = enumeration called EventTypeEnum which as its name implies contains a = list of different labels for grouping types (or classes) of events to be = used as low-granularity buckets for characterizing and classifying = events.

Other entries in this enumeration include things like =E2=80=9CFile = Ops (CRUD)=E2=80=9D, =E2=80=9CProcess Mgt=E2=80=9D, = =E2=80=9CAuthorization (ACL)=E2=80=9D, etc.

 

The =E2=80=9CPacket Traffic=E2=80=9D value is intended to = characterize events dealing with network packet traffic as its name = implies.

The =E2=80=9CData Flow=E2=80=9D value is intended to characterize = events dealing with forms of data flow at a higher level of abstraction = than just packet traffic. The relationship between these two values = could be viewed as =E2=80=9CPacket Traffic=E2=80=9D being a more = detailed form of =E2=80=9CData Flow=E2=80=9D just as the values = =E2=80=9CApp Layer Traffic=E2=80=9D and =E2=80=9CHTTP Layer = Traffic=E2=80=9D, also in this enumeration, could be other levels in = this same abstraction stack.

The idea behind the varying levels of abstraction is to leave =  buckets large enough to capture a wide variety of potential event = types (e.g. data flow events other than obvious things like packet = traffic) but also enable the use of smaller more specific buckets when = they are appropriate and commonly used.

 

Does this make sense?

 

sean

 

From:= = Omar Santos (osantos) [mailto:osantos@cisco.com]=
Sent: Monday, April 16, 2012 8:17 PM
To: Luis = Nunez; Barnum, Sean D.
Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; m-terada@ipa.go.jp
Subject:<= /b> RE: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe = website

 

I echo Luis=E2=80=99 comments. It is good to see the inclusion of = network objects. Quick question to the team related to your netflow = comment.

 

I am looking at:

= http://cybox.mitre.org/XMLSchema/cybox_core_v1.0%28draft%29.xsd<= /o:p>

 

=E2=80=A6 and it looks that we renamed it to =E2=80=9CData = Flow=E2=80=9D?

 

<xs:enumeration = value=3D"Data Flow">

   = <xs:annotation>

        = <xs:documentation>Specifies the class of events dealing with data = flow.</xs:documentation>

   = </xs:annotation>

</xs:enumeration>

 

 

What is the difference between that and =E2=80=9CPacket = Traffic=E2=80=9D?

 

<xs:enumeration value=3D"Packet =
Traffic">
   =
<xs:annotation>
     =
<xs:documentation>Specifies the class of events dealing with =
packet traffic.</xs:documentation>
   =
</xs:annotation>
</xs:enumeration>

 

 

 

 

Regards,

Omar Santos
Incident Manager, = PSIRT
Security Research and Operations
Cisco Systems, = Inc.
Email: os@cisco.com
Phone: +1 919 392 = 8635
PGP Key: 0x3AF27EDC

Cisco.com - http://www.cisco.com
Cisco Security = Advisories and Notices - http://www.cisco.com/go/psirt<= br>
This email may contain confidential and privileged material for = the sole
use of the intended recipient. Any review, use, distribution = or
disclosure by others is strictly prohibited. If you are not the = intended
recipient (or authorized to receive for the recipient), = please contact
the sender by reply email and delete all copies of = this message.

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html=

 

From:= = sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.= org] On Behalf Of Luis Nunez
Sent: Monday, April = 16, 2012 6:44 PM
To: Barnum, Sean D.
Cc: idxwg@nicwg.org; mile@ietf.org; Doug Wilson (dallendoug@gmail.com); sacm@ietf.org; IPA-Masato Terada (m-terada@ipa.go.jp)
Subject:= Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe = website

 

I like the inclusion of the network-centric = objects.  IPFIX (netflow)  will add an additional perspective = from an incident information sharing standpoint. =  

 

-ln

 

On Apr 16, 2012, at 4:04 = PM, Barnum, Sean D. wrote:

 

Hey = everyone,

 =

I just = wanted to let you all know that CybOX v1.0 (Draft) content is now live = on the website. http://cybox.mitre.org

The = release notes are provided inline = below.

The key = items of note are:

=C2=B7        The = release of two formal specifications for the CybOX language (one for the = core language and one for the defined = objects)

=C2=B7        The XML = Schema has gone through extensive improvements for expressiveness, = clarity, consistency, efficiency, alignment to existing normative = references and documentation.

=C2=B7        This = release includes an initial set of language utilities: a draft Snort = -> CybOX transform, a draft OpenIOC -> CybOX transform, and a set = of Python bindings for the CybOX language.

=C2=B7        The = website now includes a small set of content examples. This set will grow = going forward.

This = release involved a lot of hard work from a diverse group of people. = Thank you all for your contributions and effort. We could not have done = it without you.

We look = forward to everyone=E2=80=99s feedback and collaboration as we continue = to improve and mature the CybOX = language.

 =

Sean = Barnum

 =

 =

 =

CybOX v1.0 (Draft) Release = Notes

The Version 1.0 (Draft) release of Cyber = Observable eXpression (CybOX=E2=84=A2) is intended as a draft release of an initial major version of = the CybOX Language that could be utilized for practical operational use = and integration into other standards efforts. This release consists of = three primary components: a pair of formal language specifications for = the core language content and defined objects content, a set of language = implementation XML schemas (core, common_types, and ~70 defined object = schemas), and a small initial set of language utilities including an = initial draft Snort->CybOX transform, an initial draft = OpenIOC->CybOX transform and a set of CybOX language Python bindings. = Recognizing that this is the first time that the formal language = specifications will be available for review and as such will likely = generate feedback from new stakeholders, this initial major version is = being released as a =E2=80=9Cdraft=E2=80=9D v1.0 with the expectation of = cycles of new feedback and revision before a =E2=80=9Cfinal=E2=80=9D = v1.0 is released.=

The CybOX v1.0 (Draft) XML schemas include a = significant number of changes from v0.7 to improve:=

=C2=B7       Clarity, = documentation, and descriptive formality for reference and = implementation by other standards and users.=

=C2=B7       Consistency, = simplicity, and efficiency.=

=C2=B7       Alignment (as = appropriate) to existing normative references.=

=C2=B7       Expressiveness of the = schema to better support the broad set of use cases it targets (malware = characterization, indicator and incident data sharing, event management, = etc.) including the addition of an initial set of network-related = defined objects.=

Summary = of changes from CybOX_v0.7 to CybOX_v1.0_(Draft):=

=C2=B7        = Refinement of namespaces and schema = locations for better effectiveness and flexibility going forward.=

=C2=B7        = Normalized all content according to an = established set of naming conventions.=

=C2=B7        = Fully annotated all language items = (types, attributes, elements, etc.).=

=C2=B7        = Moved several commonly leveraged types = out of the core schema and into common_types.=

=C2=B7        = Achieved full typing of entire schema = structure such that all attributes and elements are definitively = typed.=

=C2=B7        = Changed all identifiers from ID and IDREF = types to be QNames enabling globally unique identifiers and flexibility = for domain-specific users of CybOX to define their own identifier syntax = locally.=

=C2=B7        = Reordered attributes and elements in = numerous types to better reflect common usage and priority.=

=C2=B7        = Added major_version and minor_version = attributes for core schema.=

=C2=B7        = Added capability to characterize source = of overall observable package data and for individual observables.=

=C2=B7        = Modified the logical composition = structure such that any such compositions are now contained within a = Observable_Composition element providing improved simplicity and = modularity.=

=C2=B7        = Removed the Delta element from = ObservableType and relocated the appropriate portions (Change, Trend, = and Frequency) to appropriate locations under Stateful_Measure and = Event.=

=C2=B7        = Added a Domain_Specific_Object_Attributes = field to Object utilizing an abstract type that will allow = domain-specific use cases to add in their own domain-specific attributes = for Objects.=

=C2=B7        = Added a Tool-Specific_Data field to = ToolInformationType utilizing an abstract type that will allow addition = of tool-specific data.=

=C2=B7        = Added an Indicators field to = MeasureSourceType utilizing an abstract type that will allow = characterizing differing formats or standards of indicators that may = have led to the identification of the observable data.=

=C2=B7        = Enhanced the Hash structure to capture = full fuzzy hashes in addition to simple hashes=

=C2=B7        = Added a new ExtractedFeaturesType that = can be used to adorn differing objects (e.g., files, memory, etc.) to = capture extracted strings, imports, functions and code snippets=

=C2=B7        = Added a ByteRunsType to enable capture of = byte runs within various objects.=

=C2=B7        = Added object_reference attribute to = DefinedObjectType to better support referencing of independently defined = Objects from within another Object definition.=

=C2=B7        = Added a generic DataSegmentType to = provide a relatively abstract way of characterizing data segments that = may be written/read/transmitted or otherwise utilized in actions or = defined in objects.=

=C2=B7        Added several new = defined object schemas (API, Code, Device, DNS_Record, Network_Flow, = Network_Packet, Network_Route_Entry, Network_Subnet, = Unix_Network_Route_Entry) including an initial set of network-centric = defined objects.

=C2=B7        = Modified every defined object schema with = added annotations as well as minor and in some cases substantive changes = to fix errors, improve consistency and alignment with existing normative = references, and to improve expressiveness in support of the targeted use = cases.=

Detailed changes from CybOX_v0.7 to = CybOX_v1.0_(Draft):=

The level of changes within v1.0 (Draft) in = the core schema, common_types and the defined object schemas is too = great to list every change in these release notes. Detailed difference = reports are available for each individual schema at:http://cybox.mitre.org/XMLSchema/release_notes/cybox_v1.0= (draft)_diff_reports.zip

 =

 =

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

Sean Barnum=

Cyber Security Principal=

The MITRE Corporation=

 =

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

 

------=_NextPart_001_003F_01CD1CAB.18E81260-- ------=_NextPart_000_003E_01CD1CAB.18E81260 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYNDCCBS0w ggMVoAMCAQICEEw6UhQhT9OgRBVHf7KQ+1AwDQYJKoZIhvcNAQELBQAwKTEnMCUGA1UEAxMeTUlU UkUgQ29ycG9yYXRpb24gUEUgUm9vdCBDQS0xMB4XDTExMDQyNjE5NDU0NVoXDTIxMDQyNjE5NDgy MlowKTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUEUgUm9vdCBDQS0xMIICIjANBgkqhkiG 9w0BAQEFAAOCAg8AMIICCgKCAgEAtp8hR0hRq3im+Alwfb5ZHGP5k2OSY2TlVHYHIMUDH3MfW7b6 8lB3j3MwAMsxGK1ke/t6O4K0t9wRH4QDgOQ1CthmOGZW7xiN81h0vP1Yf14SNugUa7ZvH9KP3iXs y8QnOHal1bKf0Pa9KXib58qUuwfaZSCTW5P2ekqd8z4TETvfBWvPgDxyxnVsiAO6yL9WaRpMiSVM hYLWy3KRuU/gue0bVEi+qdg+hENh1NSNXpoqseS262nq5cx5wybR/PF0YstQ9NNlYDM5cLECKYHH zD6cXKJozuFXriswlE8rdna7VaxyZrfgC0ueEIY/tsj/65IyUhyPBwO0ZpW+Ls9Cd4Y+ERSu5mR5 Fd8w42eVzuosmk3s3AxrKC+Z4tXYkjaiWUduIegAiST1vJBwkS53vR+zrBX3Ep56l7MFVvW/GcsZ 9wUT2HG65JOeiVc2YzCEqLgQ3ZCBHn09oBag2lnMac+E2sKm9aKL3xzHs6cyD8qCJK9O8QLCqo3C mzASlOwtTFiLYgpPW/MSmgYOt9JrwHAzk97DHFKTFttjrXGMmhMVzadt1EjMn1Wv8t5WLBI0qSoX /MYi2CaeiDsEiWRu9Nmpu3pmi8m7tIR9csdbAVPks2soNMWOopGEpFQSDvU1+m77v2jIKQKYxYmN 2zUOJ4TJFL1osnZ/71MmLCDVd+ECAwEAAaNRME8wCwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMB Af8wHQYDVR0OBBYEFFuHfZ/+bL4C6fPgKTqKVCUsnzgvMBAGCSsGAQQBgjcVAQQDAgEAMA0GCSqG SIb3DQEBCwUAA4ICAQAy78sXsP/eqHH8/uOYyxQ6TBDhkCBxNoy8MF2c9UDns5ADL1qyxPAlpDBs L+2h1Zzt3FvPjg0SoRE/9juyG1qxMzhlv0jdQx12tESdo3uBb61b1uuc4H/VxCJWDI4KZL/B53EI 8HGPjUBdLADgOmG99uffm5uarSkjtIX//Bz3U6QfzTPlVWFi4SmzRI2mp16GQ8RPuJ/WMloaAn8X H6EjS2oLjGZC8Pw8/C46W48NvZ1JZTrZvYZr7GmuvmplYK68SZv/T5Su+FlLRTy9uNXQLHtm6jKv nDH2yB66zTwfaDpnjILnrC2O7ANRVZc0KywiKiW3nB7Joq74/XVuMI1PiSByt2Qu+RIS/WAI5wMi bTmwSiBxQZqvuth+dXoakJyOP2Wg5jvL55v9RLZhDqMtRI5ovnOFvTgNJQqNPSekGtA+m6Ctl/vh kSg65FFCMhaSkn7vY2Il+R8HouWJN8wTaudeexnyHcD+Mlt8QaB5CErpDjeeGZfQ0FcYm+6TtlMz Dw5eFhT/J6QrABCxfgLkVFHurMcQD4JkmXXkq5bP+GNkY0Uy2LMbw/UD94OEV1LpfAqUkT+mu5Yb vxg+elFtsad+Ix8owW372xynIADh9q1bHm+j1OHPJmGALWK9miRpC4t3isfu3ZB0QpI/e2Po6MED 393Jb0YbzrcElFv6ZDCCBhYwggP+oAMCAQICChrDbcgAAgAAN/wwDQYJKoZIhvcNAQEFBQAwUDET MBEGCgmSJomT8ixkARkWA09SRzEVMBMGCgmSJomT8ixkARkWBU1JVFJFMSIwIAYDVQQDExlNSVRS RSBDb3Jwb3JhdGlvbiBQRSBDQS0xMB4XDTEyMDMxMjE1MTgyN1oXDTE1MDMxMjE1MTgyN1owSjEL MAkGA1UEBhMCVVMxDjAMBgNVBAoTBU1JVFJFMQ8wDQYDVQQLEwZQZW9wbGUxGjAYBgNVBAMTEUJh cm51bS5TZWFuLjMxNTQzMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA9/I6RU7OcouL 6lcEJMAg8G3myNbQu84QnflS8p3PWOjgC6P50RDqGX5UxelDqMQPN5IsNYRXVY9/b7yN/RSH4goI JfYKMitndKuCKz1q38Nh0YycEm5x2t/IN/60b01T1uOmhZfptLDoDzj0UQZwMQ19mhM/ldsrC8bR GGuHXdQVaSyXygfhzNhqC06vZo5fvCBUJ6z7JtVrfRTHdudg19JYK+gds9p+Lvp/DOEXQmgpfpMl jfNKMnrG+kPMMngrIJUsF5lcbhHuc5mO+O8eR8FxM2KF7gfKVmUmZxs7Y6uLenVJVEmllP0XgUu1 sv3bClFgUo5x5Aq6rXshtHuVuQIDAQABo4IB9jCCAfIwKAYDVR0lBCEwHwYIKwYBBQUHAwQGCSsG AQQBcwIBBwYIKwYBBQUHAwIwHQYDVR0OBBYEFDvU1Ph/OVxGkxRmwvRx1TBf5PKqMA4GA1UdDwEB /wQEAwIGwDAcBgNVHREEFTATgRFzYmFybnVtQG1pdHJlLm9yZzAfBgNVHSMEGDAWgBRpZyAh1EjB 0BsGbvMIKOI6gn1BMTBJBgNVHR8EQjBAMD6gPKA6hjhodHRwOi8vcGtpLm1pdHJlLm9yZy9NSVRS RSUyMENvcnBvcmF0aW9uJTIwUEUlMjBDQS0xLmNybDB/BggrBgEFBQcBAQRzMHEwRwYIKwYBBQUH MAKGO2h0dHA6Ly9wa2kubWl0cmUub3JnL01JVFJFJTIwQ29ycG9yYXRpb24lMjBQRSUyMENBLTEo MikuY3J0MCYGCCsGAQUFBzABhhpodHRwOi8vb2NzcC5taXRyZS5vcmcvb2NzcDA+BgkrBgEEAYI3 FQcEMTAvBicrBgEEAYI3FQiDrqwjho6WV4GNiT2CpKsShb6uAYE2g9KXfYeg+0kCAWQCAQcwFgYD VR0gBA8wDTALBgkrBgEEAXMCAQgwNAYJKwYBBAGCNxUKBCcwJTAKBggrBgEFBQcDBDALBgkrBgEE AXMCAQcwCgYIKwYBBQUHAwIwDQYJKoZIhvcNAQEFBQADggIBAC2wqKo7QWQxIqnEKRznPrAQ5vQ9 X5JhB5keH8KMWu1W5n1RuSZH+3TYp4xccdYh+rV5b5+cJcWEYhtYpZriWm4kMHPaB6gKO9rbVfF9 R8Wp8sXvCKogbNhdkZwvXW4QymB1ASlMzDI1cCV8mzYgbIhWaCbV1zZBUVgOGa4LZIgdbdmgo5r/ O2gmnSftTYiE/tQ+DBs/25Bw/jC5HOiMXJqr+JctzJTqpEVLa7GKHnXWGuzGEPYkKBplxIyhz3Mv qc/yuKM7tZzAr8Qn5qf7VI9O2xp56QLjT2+mySOUR6Vml860FMpjjgZNMxAqOJt7OgY0PoUU9d18 yw1wiKSt0LUQoMcVvp7FifBjtBCG1sB/VOzxNvcNm6lO6EO23pvcjt6+WCG1X3pgnZ5UEohsM3c0 oLzYiuSYeVf85IO2yh9fWLWw2RGkf2szck1Xg0DsAQ54/YlZYyehELh43KbS3lpnTt8UlO7C0TMT 7JQwz4fTQg1a0e9rRPFnNDUG2fS2k3tz9IYILDB3F8uiZzzXptEzaYqzIqe5CK8ZGJQcw+w/CBen 6i+MV/y7yJmhio43Y1x9hIqoynqoSMV3CKYCoOwCvFUAGsNllDpExsQZoXrdd5gcuglqbh3t8wOM jtXDSQllQ/hXDZJf8rnH0wGx3K+WA+LKNvKqNCw9spEtsfG0MIIGYjCCBEqgAwIBAgIKFJcW0gAA AAAABDANBgkqhkiG9w0BAQsFADApMScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQRSBSb290 IENBLTEwHhcNMTEwNjE0MTc0NDQ0WhcNMTcwNjE0MTc1NDQ0WjBQMRMwEQYKCZImiZPyLGQBGRYD T1JHMRUwEwYKCZImiZPyLGQBGRYFTUlUUkUxIjAgBgNVBAMTGU1JVFJFIENvcnBvcmF0aW9uIFBF IENBLTEwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDSxK9RXieqdTz4JWRkRMs/EOuF 0P0S9SbspadLJkx/LDDnaAwmAnqfqm1n7/p82oVjy1yCye3SZu4Yp7fmDIAtWbkHvYOfxHkRv1ho /fhaNN0YRkd65oJJz2ngEbNZxdIiCoialQfX/iWU7ApQ+ovKbFV60v5E0p2mPncs20NYRfsaetdh nBZbFD9flDcXwJqSvGGGBfm7ifFCR1LrtEcNKjMwf7YEWZO0Vk3ZyhVq+k7JNLEbKv0OfBz8DU8G iGU+j88QlrgGW8PLkwNk7nsS/DJp8aLudTuVqIE2CA9mqn5QjU/EZYNHGzSfCr+/usUmbojyVSJu khhrAXspRAMz+Cia3yi3q3w8TnAljXWN1dhx1iuUv5GxyzMjfqK1tMuCUU2XzGNNqoVa1mqolBiy DTCOr9d/IC0YHYMBSpQ+xi0x9zjXKt4FmQmkEAZgF4hsZZqcJYL/iCQiwiz8fEyVPZuvoWvdEXOo zFYCpmkT0MZCJwyIux0Z6vJp6VLtN/6rZgc2y54HlTrp3ifazmpsfrk3NdHxlZTZug9kjEI+vEoy p/79nAPyTWQQ1MEP0ErCWav80/HOi0MLx/7lIUfvVOjkOFgFb+iDvR4T3RAQrnEpgTO+fc7Jyzh9 LpFDqm0slwDP4Hj9cC3IzdED5BU43PGAe+HoZ8OD/1ovVgwo/wIDAQABo4IBYzCCAV8wEAYJKwYB BAGCNxUBBAMCAQIwIwYJKwYBBAGCNxUCBBYEFFCiOtgZb+Zdflkw5sC2y01sUQaVMB0GA1UdDgQW BBRpZyAh1EjB0BsGbvMIKOI6gn1BMTAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTALBgNVHQ8E BAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAfBgNVHSMEGDAWgBRbh32f/my+Aunz4Ck6ilQlLJ84LzBQ BgNVHR8ESTBHMEWgQ6BBhj9odHRwOi8vcGtpLm1pdHJlLm9yZy9NSVRSRSUyMENvcnBvcmF0aW9u JTIwUEUlMjBSb290JTIwQ0EtMS5jcmwwWwYIKwYBBQUHAQEETzBNMEsGCCsGAQUFBzAChj9odHRw Oi8vcGtpLm1pdHJlLm9yZy9NSVRSRSUyMENvcnBvcmF0aW9uJTIwUEUlMjBSb290JTIwQ0EtMS5j cnQwDQYJKoZIhvcNAQELBQADggIBAHnDPfdYKxqNOtAYXMyyel83Vs8cCDAQZhSuIB0c6GkGoEdF rmWH9pwi42V96rCp7TvbNNKNJXbVHfJUAp+uqw663DL/sXXff9ZFxPxKOdPnpA8cKM7RBH9e437N w3d28A7PaGbP6tXmSqhXAhYZ4U12y1U5cOf2G/phUoAAMlnVJdfmXzMazvLo2SIeixAJyCze6rHQ TFQ/N+gAjbVuRJ+Hs8FEKVzMSwqlNoupe2ELqL4dMAKT6P08sAfxm2SrRlQvcWPYvqM/1C10bgc2 tdu+WGzRuP5Wx9Yr15KO9SW4z7fn2RVEXQgoDDno5vCIcfUPuKB5n+Kt9eBCitsgSD9yYsNUN9LE VIvjAb8MV2LWLfge1bumo6g7QMRa4Fgifw5siGwi7V2EaJQo6UAIVvxKKFC7W4p6CkrY2ga1d7GI Q0DPiWZOezOakJVAxL5gf+3WdNt0igKc/yLfbdHn6hCd1KPgDqkSKr8zWOZI/jiDBW957xAmaO6Q dGQDBZrQHWpIVwQGzF5bGrqms2kq49l3t7KmBu0C/9tExqKAmlf4Y5lfQGdCbKQpAq712DVQHYuD XmVQEAc2vlJ1C5hS3Iw9DwBWTfJ4vyB48buhBhbIhPiFta5OizXlKcsIi99ikA1yiZx/DBtjaw4J U6qJzWUFB2ecyGCNPtNbYjURA0A9MIIGfzCCBGegAwIBAgIKGsNq2wACAAA3+jANBgkqhkiG9w0B AQUFADBQMRMwEQYKCZImiZPyLGQBGRYDT1JHMRUwEwYKCZImiZPyLGQBGRYFTUlUUkUxIjAgBgNV BAMTGU1JVFJFIENvcnBvcmF0aW9uIFBFIENBLTEwHhcNMTIwMzEyMTUxODI3WhcNMTUwMzEyMTUx ODI3WjBKMQswCQYDVQQGEwJVUzEOMAwGA1UEChMFTUlUUkUxDzANBgNVBAsTBlBlb3BsZTEaMBgG A1UEAxMRQmFybnVtLlNlYW4uMzE1NDMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCW InZvCSslmSfSyhTVVSqnokCDajlsCNZHfUlkwkV1++2O71BYvMpjFHWR2XFIx963Hl63lFZzzVci OjIwLb1c/0YXhFfUdAvrbpjlu+ttlO05OEUW0h+5HO+qaebJPamxA00w0bokquRcPxUvwa3jiyL0 WfCwE3+/b5PCOW2xh7FXFKv262FnKIwxnQGXqkiXRP5D/SmdtcZSzxHkDThrhaiHPhJJhZ4XxwBk aGcAlMg8YH6uxshXm8e6c7XUu7gB5p+XThS0dqXujpQp/UQDp5t079+UrDcrpjfDBXIt9qCzLn26 uV5a4cD4xRKwA32f1cXFtiKXM0wYgUM3fEPDAgMBAAGjggJfMIICWzATBgNVHSUEDDAKBggrBgEF BQcDBDCBlAYJKoZIhvcNAQkPBIGGMIGDMA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DBAICAIAw BwYFKw4DAgcwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBLTALBglghkgBZQME ARYwCwYJYIZIAWUDBAEZMAsGCWCGSAFlAwQBAjALBglghkgBZQMEAQUwHQYDVR0OBBYEFIrbKa+E Rxo2/Sth2C6jZqZqvRE7MA4GA1UdDwEB/wQEAwIFIDAcBgNVHREEFTATgRFzYmFybnVtQG1pdHJl Lm9yZzAfBgNVHSMEGDAWgBRpZyAh1EjB0BsGbvMIKOI6gn1BMTBJBgNVHR8EQjBAMD6gPKA6hjho dHRwOi8vcGtpLm1pdHJlLm9yZy9NSVRSRSUyMENvcnBvcmF0aW9uJTIwUEUlMjBDQS0xLmNybDB/ BggrBgEFBQcBAQRzMHEwRwYIKwYBBQUHMAKGO2h0dHA6Ly9wa2kubWl0cmUub3JnL01JVFJFJTIw Q29ycG9yYXRpb24lMjBQRSUyMENBLTEoMikuY3J0MCYGCCsGAQUFBzABhhpodHRwOi8vb2NzcC5t aXRyZS5vcmcvb2NzcDA+BgkrBgEEAYI3FQcEMTAvBicrBgEEAYI3FQiDrqwjho6WV4GNiT2CpKsS hb6uAYE2hquSaISo7EUCAWQCAQ8wFgYDVR0gBA8wDTALBgkrBgEEAXMCAQgwGwYJKwYBBAGCNxUK BA4wDDAKBggrBgEFBQcDBDANBgkqhkiG9w0BAQUFAAOCAgEAGmmL43yA+J5lEockM1cxSoyxfSES HUGLVJyrhObbdFD4yO3jf0R4lHLuJlhp1486d9LRZAyzAnl9q8Zf3Tx1rl1kEd3pw0wMuO+ATscc rArEW/rJxjz6zTrNO3PFkFuOEdmKpHaRiFpuSX602INiBEBPluei3uZlWxHW9VqC7hz2diQpOlzS jtPMbL3o7ACjWaq7sQ0xB4rZ6oWyqOZEfHWQA1b7nFgL4nEbmEHNdU4jAjcxkROku4O04205kb5n Loveoz3TSQNt8zalFayZAjt+JEcKuG1f5cyhYI6QwvkS/3M+CjJezuNaSmno29Lm+ToZnwUm4nIB YkBx4r9ZDU2W8029tr5og00A5MGo1LK+unWtHBa7zuPblfSiYgXIHWU+OKrSFaA935Yb4fLXFe9S BmApBr1gohHYos1hct5q90WPufSKIQ9WT+vJYXvW3FpseO4ZLKVnJsO7gVoQEEnWJUwyABBPQrii F0gh++ApKZJROTuR36PsEEx4duI6U4VXMCiIcnEjvNR8Mt5Q/Vp4W4Mp5fCv+QzYkqq9EWD7QuUW Yul6R8Hf7ZTxbUk0NfJgu8escLrgQSwMdP/kE/09vJAAslQBkNnIS7iIhWt4l5XQJBrJc+6popRE R8ykWf25e4CliaUgbAl1tBQKivQ3tlX99WykI2XK3sTk9nsxggMjMIIDHwIBATBeMFAxEzARBgoJ kiaJk/IsZAEZFgNPUkcxFTATBgoJkiaJk/IsZAEZFgVNSVRSRTEiMCAGA1UEAxMZTUlUUkUgQ29y cG9yYXRpb24gUEUgQ0EtMQIKGsNtyAACAAA3/DAJBgUrDgMCGgUAoIIBmjAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjA0MTcxOTAyMjRaMCMGCSqGSIb3DQEJBDEW BBSETqhvdjq0Lmg5AqxlbOVlHGuAQDBbBgkqhkiG9w0BCQ8xTjBMMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMC GjBtBgkrBgEEAYI3EAQxYDBeMFAxEzARBgoJkiaJk/IsZAEZFgNPUkcxFTATBgoJkiaJk/IsZAEZ FgVNSVRSRTEiMCAGA1UEAxMZTUlUUkUgQ29ycG9yYXRpb24gUEUgQ0EtMQIKGsNq2wACAAA3+jBv BgsqhkiG9w0BCRACCzFgoF4wUDETMBEGCgmSJomT8ixkARkWA09SRzEVMBMGCgmSJomT8ixkARkW BU1JVFJFMSIwIAYDVQQDExlNSVRSRSBDb3Jwb3JhdGlvbiBQRSBDQS0xAgoaw2rbAAIAADf6MA0G CSqGSIb3DQEBAQUABIIBAHTascEWL/C70gb9NVZtM5TeerT9f/HSMKuHM2b7AeWbS0t58u6VSG4z 8tIf+O7P1rXGWgPKAemrgSUy4Ulg9pIr+L8qwKSC46n7fk8ZR0MCC3iHfZpnP9q5Shvx2eyH1mMb 7XjMG4FcYVYcYaQsN8EU5uRvV8/xLTsr1NgvUSAoy2k6rEFuPtJOzjsavxj8g9qMYQMvcBGypaYf Boww+EOxlnxp5HidNd/zlDL7WlzphVFY2GU8ruu81zeRu5G4SfHA/lG6feB36VKXmlsZsS6Yyw+P gudvT4iCQWFpwhRCgW8oPAPD0Svu/5dTzhlFfAtKANIHtq5eArXQ8mEnkoMAAAAAAAA= ------=_NextPart_000_003E_01CD1CAB.18E81260-- From michael.hammer@yaanatech.com Tue Apr 17 12:28:18 2012 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 ED4F511E80D5; Tue, 17 Apr 2012 12:28:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.665 X-Spam-Level: X-Spam-Status: No, score=-2.665 tagged_above=-999 required=5 tests=[AWL=-0.067, 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 F2IvgeJximOr; Tue, 17 Apr 2012 12:28:13 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 87E4D11E80A0; Tue, 17 Apr 2012 12:28:13 -0700 (PDT) Received: from EX2K10MB1.corp.yaanatech.com ([fe80::5568:c31d:f64a:f66a]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Tue, 17 Apr 2012 12:28:13 -0700 From: Michael Hammer To: "Barnum, Sean D." , "osantos@cisco.com" , "Thomas.Millar@hq.dhs.gov" , "lnunez@c3isecurity.com" Thread-Topic: [mile] [sacm] CybOX v1.0 (Draft) is now released and live onthe website Thread-Index: AQHNHFhQtpFrr+nGFkWqCWY68NIgupae/ygAgADWyAD//48qoA== Date: Tue, 17 Apr 2012 19:28:12 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB38A0193@EX2K10MB1.corp.yaanatech.com> References: <7F48813B48558A4BB5CB7BB714E5B5A9171B16@IMCMBX03.MITRE.ORG> <69CE2DCD9DAC3D48B830E0723141170B02A39BD2@ZAU1UG-0308.DHSNET.DS1.DHS> <953A2E460DBE7C43AC13E30B87C5B4FF080A1C09@XMB-RCD-106.cisco.com> <7F48813B48558A4BB5CB7BB714E5B5A9171BA1@IMCMBX03.MITRE.ORG> <00C069FD01E0324C9FFCADF539701DB389FC37@EX2K10MB1.corp.yaanatech.com> <7F48813B48558A4BB5CB7BB714E5B5A9173046@IMCMBX03.MITRE.ORG> In-Reply-To: <7F48813B48558A4BB5CB7BB714E5B5A9173046@IMCMBX03.MITRE.ORG> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.88.19] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0156_01CD1CAE.B1C9C4D0" MIME-Version: 1.0 Cc: "idxwg@nicwg.org" , "mile@ietf.org" , "dallendoug@gmail.com" , "sacm@ietf.org" , "m-terada@ipa.go.jp" Subject: Re: [mile] [sacm] CybOX v1.0 (Draft) is now released and live onthe website 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, 17 Apr 2012 19:28:19 -0000 ------=_NextPart_000_0156_01CD1CAE.B1C9C4D0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0157_01CD1CAE.B1C9C4D0" ------=_NextPart_001_0157_01CD1CAE.B1C9C4D0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Sean, =20 What you say makes sense. But, if you will bear with me. (Still = learning this.) =20 If one used Packet Traffic event type always instead of Data Flow event = type, would some distinction be lost? Or, put another way, since the packet stuff seems to cover most = network-based events, does Data Flow involve something that is not on = the wire? (Such as an inter-process communication that doesn=E2=80=99t go through = a protocol stack.) =20 Mike =20 =20 From: Barnum, Sean D. [mailto:sbarnum@mitre.org]=20 Sent: Tuesday, April 17, 2012 3:03 PM To: Michael Hammer; osantos@cisco.com; Thomas.Millar@hq.dhs.gov; = lnunez@c3isecurity.com Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; = m-terada@ipa.go.jp Subject: RE: [mile] [sacm] CybOX v1.0 (Draft) is now released and live = onthe website =20 Mike, =20 Just to clarify, all of our discussion so far about =E2=80=9CData = Flow=E2=80=9D and netflow were all in regards to an enumeration called = EventTypeEnum that simply lets you tag a cyber observable event with a = type label. It is metadata for an event description. The only object we have been talking about in any detail so far was the = Network_Flow object. These two topics are totally independent of each = other. There is no Data_Flow object. The abstraction overlap we have been discussing is only in the metadata = tag applied to an event to characterize what type/class of event it is. =20 The defined objects themselves (including Network_Flow) have been = designed to avoid, as much as possible, overlap of the type you = describe. The approach we have taken is that where there is common structure and = meaning relevant to multiple different types of objects, the structure = for that commonality is broken out into its own object (e.g. Address, = URI, Port, Account, Process, etc.). Content based on this common object structure can be embedded within a = leveraging object (via direct use of the object type) if the content is = directly relevant only within the context of that object or as an = independent object and associated to any number of other objects to = which it is relevant utilizing relationships. We make no guarantees that we have managed to implement this approach = flawlessly but we believe that it yields a good balance of consistency, = efficiency and flexibility. It also allows easy modular use of only what = is relevant within a given context and enables extension and evolution = to easily occur in a localized fashion rather than having to extend and = modify one monolithic structure standard. =20 Does that make sense? =20 sean =20 From: Michael Hammer [mailto:michael.hammer@yaanatech.com]=20 Sent: Tuesday, April 17, 2012 9:18 AM To: Barnum, Sean D.; osantos@cisco.com; Thomas.Millar@hq.dhs.gov; = lnunez@c3isecurity.com Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; = m-terada@ipa.go.jp Subject: RE: [mile] [sacm] CybOX v1.0 (Draft) is now released and live = onthe website =20 Sean, =20 Does the overlap between the various objects present a problem? =20 If there are one or more objects that could carry the same data, then = human nature means that probability-wise someone will choose data flow = instead of Netflow. That is the underlying principle in Murphy=E2=80=99s Law, where you try = to design it so that there is only one way to do it, and thus private = Murphy won=E2=80=99t do it the =E2=80=9Cwrong=E2=80=9D way. =20 Just wondering if these should be mutually exclusive sets. And designed = as such. Might improve interoperability. (And avoid discussions like this in = future.) J =20 Mike =20 =20 From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of = Barnum, Sean D. Sent: Tuesday, April 17, 2012 1:10 AM To: Omar Santos (osantos); Millar, Thomas; lnunez@c3isecurity.com Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; = m-terada@ipa.go.jp Subject: Re: [mile] [sacm] CybOX v1.0 (Draft) is now released and live = onthe website =20 =E2=80=9Cupper layer=E2=80=9D? Yes, as in higher abstraction. Just =E2=80=9Cprotocols=E2=80=9D? No. =20 You guys have been looking at this through the lens of network flow = which if fine for thinking about that perspective but it is important to = also realize that the EventTypeEnum and its =E2=80=9CData Flow=E2=80=9D = value go far beyond network-related scope. It is about a lot of other types of potential data flows (as I just = outlined in a response to Tom) that have nothing to do with network = flow. =20 Thanks for your response though. This is the kind of discussions that we = hope to have a lot more of among the various supported communities. =20 =20 BTW, you may have noticed that the Network_Flow object within CybOX v1.0 = (Draft) supports expression of netflow within several of the most common = formats including Netflow9 (as well as IPFIX as Luis pointed out, = Netflow5 and SiLK as well as bi-directional flow in YAF). The common = 5-tuple or 7-tuple (you describe) (in our case it is an 8-tuple as we = broke the router interface out into both ingress and egress J) shared by = pretty much all of the netflow approaches has been broken out into a = shared Network_Flow_Label structure. The various context-dependent = portions of the independent approaches are then captured within optional = structures dedicated to each of them. We hope that eventually the = community can work to come together towards a single overall common = expressive structure for netflow that meets the needs of all. We hope = that CybOX and its use can even help that sort of maturation and = normalization. But since no such universal structure exists today, we = decided to enable optional expression of the most common individual = formats within a single netflow object to serve the large majority of = relevant users, maintain flexibility and enable discussions and analysis = of netflow within a common package. We look forward to continuing discussions with the community to validate = or invalidate this approach and to refine and mature going forward. =20 Sean=20 =20 From: Omar Santos (osantos) [mailto:osantos@cisco.com]=20 Sent: Monday, April 16, 2012 11:57 PM To: Millar, Thomas; Barnum, Sean D.; lnunez@c3isecurity.com Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; = m-terada@ipa.go.jp Subject: RE: [sacm] [mile] CybOX v1.0 (Draft) is now released and live = onthe website =20 I believe that what Sean is saying is that =E2=80=9Cdata flow=E2=80=9D = is just a value that is meant for upper layer protocols. But, you have a = good point. Traditionally, a =E2=80=9Cflow=E2=80=9D in = =E2=80=9CNetflow=E2=80=9D is based on a set of 5 and up to 7 IP packet = attributes: =20 - IP source address - IP destination address - Source port - Destination port - Layer 3 protocol type - Class of Service - Router or switch interface =20 Although, there is a lot more support with Netflow version 9: http://www.cisco.com/en/US/technologies/tk648/tk362/technologies_white_pa= per09186a00800a3db9_ps6601_Products_White_Paper.html =20 =20 =20 Regards, Omar=20 =20 From: Millar, Thomas [mailto:Thomas.Millar@hq.dhs.gov]=20 Sent: Monday, April 16, 2012 11:46 PM To: sbarnum@mitre.org; Omar Santos (osantos); lnunez@c3isecurity.com Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; = m-terada@ipa.go.jp Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live = onthe website =20 If "data flow" is a euphemism for "netflow" is there any reason not to = call it that? Tom Millar=20 http://www.us-cert.gov/=20 ------------------=20 Missit me Rubus fruticosus:=20 202 631 1915=20 =20 From: Barnum, Sean D. [mailto:sbarnum@mitre.org]=20 Sent: Monday, April 16, 2012 11:29 PM To: Omar Santos (osantos) ; Luis Nunez = =20 Cc: idxwg@nicwg.org ; mile@ietf.org ; = dallendoug@gmail.com ; sacm@ietf.org = ; m-terada@ipa.go.jp =20 Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live = onthe website=20 =20 Thanks Omar. =20 To answer your question, first let me point out to other readers that = the two entries that Omar is quoting here exist as values in an = enumeration called EventTypeEnum which as its name implies contains a = list of different labels for grouping types (or classes) of events to be = used as low-granularity buckets for characterizing and classifying = events. Other entries in this enumeration include things like =E2=80=9CFile Ops = (CRUD)=E2=80=9D, =E2=80=9CProcess Mgt=E2=80=9D, =E2=80=9CAuthorization = (ACL)=E2=80=9D, etc. =20 The =E2=80=9CPacket Traffic=E2=80=9D value is intended to characterize = events dealing with network packet traffic as its name implies. The =E2=80=9CData Flow=E2=80=9D value is intended to characterize events = dealing with forms of data flow at a higher level of abstraction than = just packet traffic. The relationship between these two values could be = viewed as =E2=80=9CPacket Traffic=E2=80=9D being a more detailed form of = =E2=80=9CData Flow=E2=80=9D just as the values =E2=80=9CApp Layer = Traffic=E2=80=9D and =E2=80=9CHTTP Layer Traffic=E2=80=9D, also in this = enumeration, could be other levels in this same abstraction stack. The idea behind the varying levels of abstraction is to leave buckets = large enough to capture a wide variety of potential event types (e.g. = data flow events other than obvious things like packet traffic) but also = enable the use of smaller more specific buckets when they are = appropriate and commonly used. =20 Does this make sense?=20 =20 sean =20 From: Omar Santos (osantos) [mailto:osantos@cisco.com]=20 Sent: Monday, April 16, 2012 8:17 PM To: Luis Nunez; Barnum, Sean D. Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; = m-terada@ipa.go.jp Subject: RE: [sacm] [mile] CybOX v1.0 (Draft) is now released and live = onthe website =20 I echo Luis=E2=80=99 comments. It is good to see the inclusion of = network objects. Quick question to the team related to your netflow = comment. =20 I am looking at: http://cybox.mitre.org/XMLSchema/cybox_core_v1.0%28draft%29.xsd =20 =E2=80=A6 and it looks that we renamed it to =E2=80=9CData = Flow=E2=80=9D? =20 Specifies the class of events dealing with = data flow. =20 =20 What is the difference between that and =E2=80=9CPacket = Traffic=E2=80=9D? =20 Specifies the class of events dealing with packet = traffic. =20 =20 =20 =20 Regards, Omar Santos Incident Manager, PSIRT Security Research and Operations Cisco Systems, Inc. Email: os@cisco.com Phone: +1 919 392 8635 PGP Key: 0x3AF27EDC Cisco.com - http://www.cisco.com Cisco Security Advisories and Notices - http://www.cisco.com/go/psirt This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message. For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html =20 From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of = Luis Nunez Sent: Monday, April 16, 2012 6:44 PM To: Barnum, Sean D. Cc: idxwg@nicwg.org; mile@ietf.org; Doug Wilson (dallendoug@gmail.com); = sacm@ietf.org; IPA-Masato Terada (m-terada@ipa.go.jp) Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live = onthe website =20 I like the inclusion of the network-centric objects. IPFIX (netflow) = will add an additional perspective from an incident information sharing = standpoint. =20 =20 -ln =20 On Apr 16, 2012, at 4:04 PM, Barnum, Sean D. wrote: =20 Hey everyone, =20 I just wanted to let you all know that CybOX v1.0 (Draft) content is now = live on the website. http://cybox.mitre.org The release notes are provided inline below. The key items of note are: =C2=B7 The release of two formal specifications for the CybOX = language (one for the core language and one for the defined objects) =C2=B7 The XML Schema has gone through extensive improvements for = expressiveness, clarity, consistency, efficiency, alignment to existing = normative references and documentation. =C2=B7 This release includes an initial set of language = utilities: a draft Snort -> CybOX transform, a draft OpenIOC -> CybOX = transform, and a set of Python bindings for the CybOX language. =C2=B7 The website now includes a small set of content examples. = This set will grow going forward. This release involved a lot of hard work from a diverse group of people. = Thank you all for your contributions and effort. We could not have done = it without you. We look forward to everyone=E2=80=99s feedback and collaboration as we = continue to improve and mature the CybOX language. =20 Sean Barnum =20 =20 =20 CybOX v1.0 (Draft) Release Notes The Version 1.0 (Draft) release of Cyber Observable eXpression = (CybOX=E2=84=A2) is intended as a draft release of an initial major = version of the CybOX Language that could be utilized for practical = operational use and integration into other standards efforts. This = release consists of three primary components: a pair of formal language = specifications for the core language content and defined objects = content, a set of language implementation XML schemas (core, = common_types, and ~70 defined object schemas), and a small initial set = of language utilities including an initial draft Snort->CybOX transform, = an initial draft OpenIOC->CybOX transform and a set of CybOX language = Python bindings. Recognizing that this is the first time that the formal = language specifications will be available for review and as such will = likely generate feedback from new stakeholders, this initial major = version is being released as a =E2=80=9Cdraft=E2=80=9D v1.0 with the = expectation of cycles of new feedback and revision before a = =E2=80=9Cfinal=E2=80=9D v1.0 is released. The CybOX v1.0 (Draft) XML schemas include a significant number of = changes from v0.7 to improve: =C2=B7 Clarity, documentation, and descriptive formality for = reference and implementation by other standards and users. =C2=B7 Consistency, simplicity, and efficiency. =C2=B7 Alignment (as appropriate) to existing normative = references. =C2=B7 Expressiveness of the schema to better support the broad = set of use cases it targets (malware characterization, indicator and = incident data sharing, event management, etc.) including the addition of = an initial set of network-related defined objects. Summary of changes from CybOX_v0.7 to CybOX_v1.0_(Draft): =C2=B7 Refinement of namespaces and schema locations for better = effectiveness and flexibility going forward. =C2=B7 Normalized all content according to an established set of = naming conventions. =C2=B7 Fully annotated all language items (types, attributes, = elements, etc.). =C2=B7 Moved several commonly leveraged types out of the core = schema and into common_types. =C2=B7 Achieved full typing of entire schema structure such that = all attributes and elements are definitively typed. =C2=B7 Changed all identifiers from ID and IDREF types to be = QNames enabling globally unique identifiers and flexibility for = domain-specific users of CybOX to define their own identifier syntax = locally. =C2=B7 Reordered attributes and elements in numerous types to = better reflect common usage and priority. =C2=B7 Added major_version and minor_version attributes for core = schema. =C2=B7 Added capability to characterize source of overall = observable package data and for individual observables. =C2=B7 Modified the logical composition structure such that any = such compositions are now contained within a Observable_Composition = element providing improved simplicity and modularity. =C2=B7 Removed the Delta element from ObservableType and relocated = the appropriate portions (Change, Trend, and Frequency) to appropriate = locations under Stateful_Measure and Event. =C2=B7 Added a Domain_Specific_Object_Attributes field to Object = utilizing an abstract type that will allow domain-specific use cases to = add in their own domain-specific attributes for Objects. =C2=B7 Added a Tool-Specific_Data field to ToolInformationType = utilizing an abstract type that will allow addition of tool-specific = data. =C2=B7 Added an Indicators field to MeasureSourceType utilizing an = abstract type that will allow characterizing differing formats or = standards of indicators that may have led to the identification of the = observable data. =C2=B7 Enhanced the Hash structure to capture full fuzzy hashes in = addition to simple hashes =C2=B7 Added a new ExtractedFeaturesType that can be used to adorn = differing objects (e.g., files, memory, etc.) to capture extracted = strings, imports, functions and code snippets =C2=B7 Added a ByteRunsType to enable capture of byte runs within = various objects. =C2=B7 Added object_reference attribute to DefinedObjectType to = better support referencing of independently defined Objects from within = another Object definition. =C2=B7 Added a generic DataSegmentType to provide a relatively = abstract way of characterizing data segments that may be = written/read/transmitted or otherwise utilized in actions or defined in = objects. =C2=B7 Added several new defined object schemas (API, Code, = Device, DNS_Record, Network_Flow, Network_Packet, Network_Route_Entry, = Network_Subnet, Unix_Network_Route_Entry) including an initial set of = network-centric defined objects. =C2=B7 Modified every defined object schema with added annotations = as well as minor and in some cases substantive changes to fix errors, = improve consistency and alignment with existing normative references, = and to improve expressiveness in support of the targeted use cases. Detailed changes from CybOX_v0.7 to CybOX_v1.0_(Draft): The level of changes within v1.0 (Draft) in the core schema, = common_types and the defined object schemas is too great to list every = change in these release notes. Detailed difference reports are available = for each individual schema at: = = http://cybox.mitre.org/XMLSchema/release_notes/cybox_v1.0(draft)_diff_rep= orts.zip =20 =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Sean Barnum Cyber Security Principal The MITRE Corporation Email: sbarnum@mitre.org =20 _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile =20 ------=_NextPart_001_0157_01CD1CAE.B1C9C4D0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Sean,

 

What you say makes sense.=C2=A0 But, if you will bear with me.=C2=A0 = (Still learning this.)

 

If one used Packet Traffic event type always instead of Data Flow = event type, would some distinction be lost?

Or, put another way, since the packet stuff seems to cover most = network-based events, does Data Flow involve something that is not on = the wire?

(Such as an inter-process communication that doesn=E2=80=99t go = through a protocol stack.)

 

Mike

 

 

From:= = Barnum, Sean D. [mailto:sbarnum@mitre.org]
Sent: Tuesday, = April 17, 2012 3:03 PM
To: Michael Hammer; osantos@cisco.com; = Thomas.Millar@hq.dhs.gov; lnunez@c3isecurity.com
Cc: = idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; = m-terada@ipa.go.jp
Subject: RE: [mile] [sacm] CybOX v1.0 = (Draft) is now released and live onthe = website

 

Mike,

 

Just to clarify, all of our discussion so far about =E2=80=9CData = Flow=E2=80=9D and netflow were all in regards to an enumeration called = EventTypeEnum that simply lets you tag a cyber observable event with a = type label. It is metadata for an event = description.

The only object we have been talking about in any detail so far was = the Network_Flow object. These two topics are totally independent of = each other. There is no Data_Flow object.

The abstraction overlap we have been discussing is only in the = metadata tag applied to an event to characterize what type/class of = event it is.

 

The defined objects themselves (including Network_Flow) have been = designed to avoid, as much as possible, overlap of the type you = describe.

The approach we have taken is that where there is common structure = and meaning relevant to multiple different types of objects, the = structure for that commonality is broken out into its own object (e.g. = Address, URI, Port, Account, Process, etc.).

Content based on this common object structure can be embedded within = a leveraging object (via direct use of the object type) if the content = is directly relevant only within the context of that object or as an = independent object and associated to any number of other objects to = which it is relevant utilizing relationships.

We make no guarantees that we have managed to implement this approach = flawlessly but we believe that it yields a good balance of consistency, = efficiency and flexibility. It also allows easy modular use of only what = is relevant within a given context and enables extension and evolution = to easily occur in a localized fashion rather than having to extend and = modify one monolithic structure standard.

 

Does that make sense?

 

sean

 

From:= = Michael Hammer [mailto:michael.ham= mer@yaanatech.com]
Sent: Tuesday, April 17, 2012 9:18 = AM
To: Barnum, Sean D.; osantos@cisco.com; Thomas.Millar@hq.dhs.gov; = lnunez@c3isecurity.com
C= c: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; m-terada@ipa.go.jp
Subject:<= /b> RE: [mile] [sacm] CybOX v1.0 (Draft) is now released and live onthe = website

 

Sean,

 

Does the overlap between the various objects present a = problem?

 

If there are one or more objects that could carry the same data, then = human nature means that probability-wise someone will choose data flow = instead of Netflow.

That is the underlying principle in Murphy=E2=80=99s Law, where you = try to design it so that there is only one way to do it, and thus = private Murphy won=E2=80=99t do it the =E2=80=9Cwrong=E2=80=9D = way.

 

Just wondering if these should be mutually exclusive sets.  And = designed as such.

Might improve interoperability.  (And avoid discussions like = this in future.)  J

 

Mike

 

 

From:= = mile-bounces@ietf.org [mailto:mile-bounces@ietf.= org] On Behalf Of Barnum, Sean D.
Sent: Tuesday, = April 17, 2012 1:10 AM
To: Omar Santos (osantos); Millar, = Thomas; lnunez@c3isecurity.com
C= c: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; m-terada@ipa.go.jp
Subject:<= /b> Re: [mile] [sacm] CybOX v1.0 (Draft) is now released and live onthe = website

 

=E2=80=9Cupper layer=E2=80=9D? Yes, as in higher = abstraction.

Just =E2=80=9Cprotocols=E2=80=9D? No.

 

You guys have been looking at this through the lens of network flow = which if fine for thinking about that perspective but it is important to = also realize that the EventTypeEnum and its =E2=80=9CData Flow=E2=80=9D = value go far beyond network-related scope.

It is about a lot of other types of potential data flows (as I just = outlined in a response to Tom) that have nothing to do with network = flow.

 

Thanks for your response though. This is the kind of discussions that = we hope to have a lot more of among the various supported = communities.

 

 

BTW, you may have noticed that the Network_Flow object within CybOX = v1.0 (Draft) supports expression of netflow within several of the most = common formats including Netflow9 (as well as IPFIX as Luis pointed out, = Netflow5 and SiLK as well as bi-directional flow in YAF). The common = 5-tuple or 7-tuple (you describe) (in our case it is an 8-tuple as we = broke the router interface out into both ingress and egress J) shared by pretty much all of the netflow approaches has been broken = out into a shared Network_Flow_Label structure. The various = context-dependent portions of the independent approaches are then = captured within optional structures dedicated to each of them. We hope = that eventually the community can work to come together towards a single = overall common expressive structure for netflow that meets the needs of = all. We hope that CybOX and its use can even help that sort of = maturation and normalization. But since no such universal structure = exists today, we decided to enable optional expression of the most = common individual formats within a single netflow object to serve the = large majority of relevant users, maintain flexibility and enable = discussions and analysis of netflow within a common = package.

We look forward to continuing discussions with the community to = validate or invalidate this approach and to refine and mature going = forward.

 

Sean

 

From:= = Omar Santos (osantos) [mailto:osantos@cisco.com]=
Sent: Monday, April 16, 2012 11:57 PM
To: Millar, = Thomas; Barnum, Sean D.; lnunez@c3isecurity.com
C= c: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; m-terada@ipa.go.jp
Subject:<= /b> RE: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe = website

 

I believe that what Sean is saying is that =E2=80=9Cdata = flow=E2=80=9D is just a value that is meant for upper layer protocols. = But, you have a good point. Traditionally, a =E2=80=9Cflow=E2=80=9D in = =E2=80=9CNetflow=E2=80=9D is based on a set of 5 and up to 7 IP packet = attributes:

 

- IP source address

- IP destination address

- Source port

- Destination port

- Layer 3 protocol type

- Class of Service

- Router or switch interface

 

Although, there is a lot more support with Netflow version = 9:

http://www.= cisco.com/en/US/technologies/tk648/tk362/technologies_white_paper09186a00= 800a3db9_ps6601_Products_White_Paper.html

 

 

 

Regards,

Omar

 

From:= = Millar, Thomas [mailto:Thomas.Millar@h= q.dhs.gov]
Sent: Monday, April 16, 2012 11:46 = PM
To: sbarnum@mitre.org; Omar Santos = (osantos); lnunez@c3isecurity.com
C= c: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; m-terada@ipa.go.jp
Subject:<= /b> Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe = website

 

If "data flow" is a euphemism for "netflow" is = there any reason not to call it that?

Tom Millar
http://www.us-cert.gov/ =
------------------
Missit me Rubus fruticosus:
202 631 1915 =

 

From<= /b>: = Barnum, Sean D. [mailto:sbarnum@mitre.org]=
Sent: Monday, April 16, 2012 11:29 PM
To: Omar = Santos (osantos) <osantos@cisco.com>; Luis Nunez = <lnunez@c3isecurity.com> =
Cc: idxwg@nicwg.org = <idxwg@nicwg.org>; mile@ietf.org <mile@ietf.org>; dallendoug@gmail.com <dallendoug@gmail.com>; sacm@ietf.org <sacm@ietf.org>; m-terada@ipa.go.jp <m-terada@ipa.go.jp> =
Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released = and live onthe website
 

Thanks Omar.

 

To answer your question, first let me point out to other readers that = the two entries that Omar is quoting here exist as values in an = enumeration called EventTypeEnum which as its name implies contains a = list of different labels for grouping types (or classes) of events to be = used as low-granularity buckets for characterizing and classifying = events.

Other entries in this enumeration include things like =E2=80=9CFile = Ops (CRUD)=E2=80=9D, =E2=80=9CProcess Mgt=E2=80=9D, = =E2=80=9CAuthorization (ACL)=E2=80=9D, etc.

 

The =E2=80=9CPacket Traffic=E2=80=9D value is intended to = characterize events dealing with network packet traffic as its name = implies.

The =E2=80=9CData Flow=E2=80=9D value is intended to characterize = events dealing with forms of data flow at a higher level of abstraction = than just packet traffic. The relationship between these two values = could be viewed as =E2=80=9CPacket Traffic=E2=80=9D being a more = detailed form of =E2=80=9CData Flow=E2=80=9D just as the values = =E2=80=9CApp Layer Traffic=E2=80=9D and =E2=80=9CHTTP Layer = Traffic=E2=80=9D, also in this enumeration, could be other levels in = this same abstraction stack.

The idea behind the varying levels of abstraction is to leave =  buckets large enough to capture a wide variety of potential event = types (e.g. data flow events other than obvious things like packet = traffic) but also enable the use of smaller more specific buckets when = they are appropriate and commonly used.

 

Does this make sense?

 

sean

 

From:= = Omar Santos (osantos) [mailto:osantos@cisco.com]=
Sent: Monday, April 16, 2012 8:17 PM
To: Luis = Nunez; Barnum, Sean D.
Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; m-terada@ipa.go.jp
Subject:<= /b> RE: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe = website

 

I echo Luis=E2=80=99 comments. It is good to see the inclusion of = network objects. Quick question to the team related to your netflow = comment.

 

I am looking at:

= http://cybox.mitre.org/XMLSchema/cybox_core_v1.0%28draft%29.xsd<= /o:p>

 

=E2=80=A6 and it looks that we renamed it to =E2=80=9CData = Flow=E2=80=9D?

 

<xs:enumeration = value=3D"Data Flow">

   = <xs:annotation>

        = <xs:documentation>Specifies the class of events dealing with data = flow.</xs:documentation>

   = </xs:annotation>

</xs:enumeration>

 

 

What is the difference between that and =E2=80=9CPacket = Traffic=E2=80=9D?

 

<xs:enumeration value=3D"Packet =
Traffic">
   =
<xs:annotation>
     =
<xs:documentation>Specifies the class of events dealing with =
packet traffic.</xs:documentation>
   =
</xs:annotation>
</xs:enumeration>

 

 

 

 

Regards,

Omar Santos
Incident Manager, = PSIRT
Security Research and Operations
Cisco Systems, = Inc.
Email: os@cisco.com
Phone: +1 919 392 = 8635
PGP Key: 0x3AF27EDC

Cisco.com - http://www.cisco.com
Cisco Security = Advisories and Notices - http://www.cisco.com/go/psirt<= br>
This email may contain confidential and privileged material for = the sole
use of the intended recipient. Any review, use, distribution = or
disclosure by others is strictly prohibited. If you are not the = intended
recipient (or authorized to receive for the recipient), = please contact
the sender by reply email and delete all copies of = this message.

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html=

 

From:= = sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.= org] On Behalf Of Luis Nunez
Sent: Monday, April = 16, 2012 6:44 PM
To: Barnum, Sean D.
Cc: idxwg@nicwg.org; mile@ietf.org; Doug Wilson (dallendoug@gmail.com); sacm@ietf.org; IPA-Masato Terada (m-terada@ipa.go.jp)
Subject:= Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe = website

 

I like the inclusion of the network-centric = objects.  IPFIX (netflow)  will add an additional perspective = from an incident information sharing standpoint. =  

 

-ln

 

On Apr 16, 2012, at 4:04 = PM, Barnum, Sean D. wrote:

 

Hey = everyone,

 =

I just = wanted to let you all know that CybOX v1.0 (Draft) content is now live = on the website. http://cybox.mitre.org

The = release notes are provided inline = below.

The key = items of note are:

=C2=B7        The = release of two formal specifications for the CybOX language (one for the = core language and one for the defined = objects)

=C2=B7        The XML = Schema has gone through extensive improvements for expressiveness, = clarity, consistency, efficiency, alignment to existing normative = references and documentation.

=C2=B7        This = release includes an initial set of language utilities: a draft Snort = -> CybOX transform, a draft OpenIOC -> CybOX transform, and a set = of Python bindings for the CybOX language.

=C2=B7        The = website now includes a small set of content examples. This set will grow = going forward.

This = release involved a lot of hard work from a diverse group of people. = Thank you all for your contributions and effort. We could not have done = it without you.

We look = forward to everyone=E2=80=99s feedback and collaboration as we continue = to improve and mature the CybOX = language.

 =

Sean = Barnum

 =

 =

 =

CybOX v1.0 (Draft) Release = Notes

The Version 1.0 (Draft) release of Cyber = Observable eXpression (CybOX=E2=84=A2) is intended as a draft release of an initial major version of = the CybOX Language that could be utilized for practical operational use = and integration into other standards efforts. This release consists of = three primary components: a pair of formal language specifications for = the core language content and defined objects content, a set of language = implementation XML schemas (core, common_types, and ~70 defined object = schemas), and a small initial set of language utilities including an = initial draft Snort->CybOX transform, an initial draft = OpenIOC->CybOX transform and a set of CybOX language Python bindings. = Recognizing that this is the first time that the formal language = specifications will be available for review and as such will likely = generate feedback from new stakeholders, this initial major version is = being released as a =E2=80=9Cdraft=E2=80=9D v1.0 with the expectation of = cycles of new feedback and revision before a =E2=80=9Cfinal=E2=80=9D = v1.0 is released.=

The CybOX v1.0 (Draft) XML schemas include a = significant number of changes from v0.7 to improve:=

=C2=B7       Clarity, = documentation, and descriptive formality for reference and = implementation by other standards and users.=

=C2=B7       Consistency, = simplicity, and efficiency.=

=C2=B7       Alignment (as = appropriate) to existing normative references.=

=C2=B7       Expressiveness of the = schema to better support the broad set of use cases it targets (malware = characterization, indicator and incident data sharing, event management, = etc.) including the addition of an initial set of network-related = defined objects.=

Summary = of changes from CybOX_v0.7 to CybOX_v1.0_(Draft):=

=C2=B7       = Refinement of namespaces and schema = locations for better effectiveness and flexibility going forward.=

=C2=B7       = Normalized all content according to an = established set of naming conventions.=

=C2=B7       = Fully annotated all language items = (types, attributes, elements, etc.).=

=C2=B7       = Moved several commonly leveraged types = out of the core schema and into common_types.=

=C2=B7       = Achieved full typing of entire schema = structure such that all attributes and elements are definitively = typed.=

=C2=B7       = Changed all identifiers from ID and IDREF = types to be QNames enabling globally unique identifiers and flexibility = for domain-specific users of CybOX to define their own identifier syntax = locally.=

=C2=B7       = Reordered attributes and elements in = numerous types to better reflect common usage and priority.=

=C2=B7       = Added major_version and minor_version = attributes for core schema.=

=C2=B7       = Added capability to characterize source = of overall observable package data and for individual observables.=

=C2=B7       = Modified the logical composition = structure such that any such compositions are now contained within a = Observable_Composition element providing improved simplicity and = modularity.=

=C2=B7       = Removed the Delta element from = ObservableType and relocated the appropriate portions (Change, Trend, = and Frequency) to appropriate locations under Stateful_Measure and = Event.=

=C2=B7       = Added a Domain_Specific_Object_Attributes = field to Object utilizing an abstract type that will allow = domain-specific use cases to add in their own domain-specific attributes = for Objects.=

=C2=B7       = Added a Tool-Specific_Data field to = ToolInformationType utilizing an abstract type that will allow addition = of tool-specific data.=

=C2=B7       = Added an Indicators field to = MeasureSourceType utilizing an abstract type that will allow = characterizing differing formats or standards of indicators that may = have led to the identification of the observable data.=

=C2=B7       = Enhanced the Hash structure to capture = full fuzzy hashes in addition to simple hashes=

=C2=B7       = Added a new ExtractedFeaturesType that = can be used to adorn differing objects (e.g., files, memory, etc.) to = capture extracted strings, imports, functions and code snippets=

=C2=B7       = Added a ByteRunsType to enable capture of = byte runs within various objects.=

=C2=B7       = Added object_reference attribute to = DefinedObjectType to better support referencing of independently defined = Objects from within another Object definition.=

=C2=B7       = Added a generic DataSegmentType to = provide a relatively abstract way of characterizing data segments that = may be written/read/transmitted or otherwise utilized in actions or = defined in objects.=

=C2=B7        Added several new = defined object schemas (API, Code, Device, DNS_Record, Network_Flow, = Network_Packet, Network_Route_Entry, Network_Subnet, = Unix_Network_Route_Entry) including an initial set of network-centric = defined objects.

=C2=B7       = Modified every defined object schema with = added annotations as well as minor and in some cases substantive changes = to fix errors, improve consistency and alignment with existing normative = references, and to improve expressiveness in support of the targeted use = cases.=

Detailed changes from CybOX_v0.7 to = CybOX_v1.0_(Draft):=

The level of changes within v1.0 (Draft) in = the core schema, common_types and the defined object schemas is too = great to list every change in these release notes. Detailed difference = reports are available for each individual schema at:http://cybox.mitre.org/XMLSchema/release_notes/cybox_v1.0= (draft)_diff_reports.zip

 =

 =

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

Sean Barnum=

Cyber Security Principal=

The MITRE Corporation=

 =

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

 

------=_NextPart_001_0157_01CD1CAE.B1C9C4D0-- ------=_NextPart_000_0156_01CD1CAE.B1C9C4D0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP6zCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggTXMIIDv6ADAgECAhBcX1ns/Jl/DtI19/BXCcuBMA0G CSqGSIb3DQEBBQUAMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMwHhcNMTIwNDAzMDAwMDAwWhcNMTMwNDAzMjM1OTU5WjCCAR4xFzAVBgNVBAoTDlZl cmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13 d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChj KTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNDAyBgNVBAsTK0RpZ2l0YWwgSUQg Q2xhc3MgMSAtIE1pY3Jvc29mdCBGdWxsIFNlcnZpY2UxFzAVBgNVBAMUDk1pY2hhZWwgSGFtbWVy MSswKQYJKoZIhvcNAQkBFhxtaWNoYWVsLmhhbW1lckB5YWFuYXRlY2guY29tMIGfMA0GCSqGSIb3 DQEBAQUAA4GNADCBiQKBgQDoKTk9rP/4lG6CLqIR4++IFTuOSLF6bmhDr6eiSahqU0VNP+H/LbiD MAZsK9GQoBYPKQdKzy/gM+fl3Gm6VOdjKl8M3GB6LGgAK8d3ETN5dyKe5CAG7EEbKg9wxHWcuXW7 KYd052ven5Ec+Xj++v3HsE423O5q2mNh1Q8FNsnlXQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYD VR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2ln bi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYD VR0fBEkwRzBFoEOgQYY/aHR0cDovL2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20v SW5kQzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQA8rhDezFsw7OlR3+mZOZ39 SCKWNJ4gMlQEe31NNtvs6BUzE1uN+fJeZrJ5zjTdJWeG1NgVugcuzQfdv/m5BYbhgJvNfW6ElqZh cye6imOUx8diekkeHXKYSLnEvCdJItXsC1h/huIT9e83WksM92qI/TFyCq6u39cGf9PaBYbcKcZk jHjNi3SPnGifMC6opGiiyK/vB1lituoBRcJ13Y7XoXA8T0kSR8Dtmqvo1JudcFAbS1srytG1QX1H XTsPkTDKHlwv2ZfmCSKK3sWHDrZfpRglxvcX2OwibcKVkKBJRRw36UuJOIj/u0WYABcYtusAb2+0 nqoGmOEYARnrseTZMIIG7jCCBdagAwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUF ADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZv ciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQ cmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkw NDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP 6bGNQU4099oL42r6ZYggCxET6ZvgSU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYH r54UGAdPWr2f0jGyVBlzRmoZQhHsEnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50 ABMN0Ibak2f4MwOuGjxraXj2wCyO4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yx BF6+wbaULZeQLSfSux7pg2qE9sSyriMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ 6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CG SAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYI KwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6Al hiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYI KwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQ UjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1Ud EQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EI Qf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4 BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkx RTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZ gbWpBbVSOOk5hIls5DSoWufYbAlMJBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v 8dKBl8pUWkO/N4t6jhmND0OojPKvYLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM6 1a4ScAjr+zvid+zoK2Q1ds262uDRyxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/ XLJtSd5lUkL7DojS7Uodv0vj+Mxy+kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4 VRaMxmgD5yKocwuxvKDaUljdCg5/wYIxggS4MIIEtAIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTsw OQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykw OTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI19/BXCcuBMAkGBSsO AwIaBQCgggMbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQx NzE5MjgwOVowIwYJKoZIhvcNAQkEMRYEFFllKTDlV1vMktcdikuOwiuNNO2mMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIIBAwYJKwYB BAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMCEFxfWez8mX8O0jX38FcJy4EwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkG A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24u Y29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5W ZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI1 9/BXCcuBMA0GCSqGSIb3DQEBAQUABIGAorGa08RIhOHMMD15mYFNvzypXw/+FY9ysJzpzR97Pva3 b9b+gSWFRnwZYjPh8/ACjcHTly2X4+Vh/qF1YU/JDWobArBE6OLhRI2g2yW+niEX+eq60M6qKNvo +d7VhAGrg7Lc4YvCtdyz01Vi726Kjtjhg4LiRGKB/hsnsxJw+kYAAAAAAAA= ------=_NextPart_000_0156_01CD1CAE.B1C9C4D0-- From lnunez@c3isecurity.com Tue Apr 17 12:49:08 2012 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 96C5C21F846D for ; Tue, 17 Apr 2012 12:49:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 OUtifujhtAIv for ; Tue, 17 Apr 2012 12:49:03 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id AFC7321F8471 for ; Tue, 17 Apr 2012 12:49:02 -0700 (PDT) Received: by ghbg16 with SMTP id g16so3780385ghb.31 for ; Tue, 17 Apr 2012 12:49:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=SfzOkeZJDHfeK7hGyn7irZfHI/IFnfQqrQtTxpZXpbI=; b=XtphQeqoQLtXO/anU7RL8ulipS9+tekJJodVDxazi1hTGxGde56R7j7KKIHCDBMmfz Ij4O9PzJkMurlTwokPkzvpJqfnUORazEJaD+LXfkla89WCiqeVfwBEawLwoaoC+LOb7l Lzq89Cq/hCQHKifLMlIv/VDH/LhYoN9Tq+b3eNd2ACsNjzA6KsocnjzhuajWPlg5C5+O IOb45tLv/fCO5Q4NMZIqIk2+Rqh6yEH76kaImjwDauDhYFBDGjbaiktLfNt9Hgl8Q+Kn xPyl4A0psA7dwz2xLQV9LRcnnp3Sua8OBtylxJR6Jz18pka+aNNrWVbXrFIeZhRSPMR7 SxBA== Received: by 10.236.125.135 with SMTP id z7mr16630602yhh.44.1334692142229; Tue, 17 Apr 2012 12:49:02 -0700 (PDT) Received: from [172.16.1.104] (cpe-066-057-025-190.nc.res.rr.com. [66.57.25.190]) by mx.google.com with ESMTPS id k35sm38719181ani.3.2012.04.17.12.48.59 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 17 Apr 2012 12:49:01 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_C592CC56-27E2-42C3-9DBB-7D60E3E22307" From: Luis Nunez In-Reply-To: <00C069FD01E0324C9FFCADF539701DB38A0193@EX2K10MB1.corp.yaanatech.com> Date: Tue, 17 Apr 2012 15:48:57 -0400 Message-Id: <7F708B86-FA77-441A-A1A0-BCC448708EC0@c3isecurity.com> References: <7F48813B48558A4BB5CB7BB714E5B5A9171B16@IMCMBX03.MITRE.ORG> <69CE2DCD9DAC3D48B830E0723141170B02A39BD2@ZAU1UG-0308.DHSNET.DS1.DHS> <953A2E460DBE7C43AC13E30B87C5B4FF080A1C09@XMB-RCD-106.cisco.com> <7F48813B48558A4BB5CB7BB714E5B5A9171BA1@IMCMBX03.MITRE.ORG> <00C069FD01E0324C9FFCADF539701DB389FC37@EX2K10MB1.corp.yaanatech.com> <7F48813B48558A4BB5CB7BB714E5B5A9173046@IMCMBX03.MITRE.ORG> <00C069FD01E0324C9FFCADF539701DB38A0193@EX2K10MB1.corp.yaanatech.com> To: Michael Hammer X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQm8UU/cDRgy8JckMEuy1uR604uLFzrULCzlmauir1jskue4mMsZN5pOll39545iRWIphzxc Cc: "Barnum, Sean D." , "sacm@ietf.org" , "dallendoug@gmail.com" , "mile@ietf.org" , "idxwg@nicwg.org" , "Thomas.Millar@hq.dhs.gov" , "m-terada@ipa.go.jp" Subject: Re: [mile] [sacm] CybOX v1.0 (Draft) is now released and live onthe website 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, 17 Apr 2012 19:49:08 -0000 --Apple-Mail=_C592CC56-27E2-42C3-9DBB-7D60E3E22307 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 The salient point is IPFIX/Netflow is about accounting details of packet = traffic summaries (who,what, where, when and how many times). The following articles could provide the basis for a use case around = leveraging IPFIX to characterize an observable for information sharing. = http://blogs.cisco.com/security/correlating-netflow-data-for-proactive-sec= urity-network-notoriety/ = http://www.cisco.com/web/about/ciscoitatwork/network_systems/network_data_= monitoring_and_reporting_web.html -ln On Apr 17, 2012, at 3:28 PM, Michael Hammer wrote: > Sean, > =20 > What you say makes sense. But, if you will bear with me. (Still = learning this.) > =20 > If one used Packet Traffic event type always instead of Data Flow = event type, would some distinction be lost? > Or, put another way, since the packet stuff seems to cover most = network-based events, does Data Flow involve something that is not on = the wire? > (Such as an inter-process communication that doesn=92t go through a = protocol stack.) > =20 > Mike > =20 > =20 > From: Barnum, Sean D. [mailto:sbarnum@mitre.org]=20 > Sent: Tuesday, April 17, 2012 3:03 PM > To: Michael Hammer; osantos@cisco.com; Thomas.Millar@hq.dhs.gov; = lnunez@c3isecurity.com > Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; = sacm@ietf.org; m-terada@ipa.go.jp > Subject: RE: [mile] [sacm] CybOX v1.0 (Draft) is now released and live = onthe website > =20 > Mike, > =20 > Just to clarify, all of our discussion so far about =93Data Flow=94 = and netflow were all in regards to an enumeration called EventTypeEnum = that simply lets you tag a cyber observable event with a type label. It = is metadata for an event description. > The only object we have been talking about in any detail so far was = the Network_Flow object. These two topics are totally independent of = each other. There is no Data_Flow object. > The abstraction overlap we have been discussing is only in the = metadata tag applied to an event to characterize what type/class of = event it is. > =20 > The defined objects themselves (including Network_Flow) have been = designed to avoid, as much as possible, overlap of the type you = describe. > The approach we have taken is that where there is common structure and = meaning relevant to multiple different types of objects, the structure = for that commonality is broken out into its own object (e.g. Address, = URI, Port, Account, Process, etc.). > Content based on this common object structure can be embedded within a = leveraging object (via direct use of the object type) if the content is = directly relevant only within the context of that object or as an = independent object and associated to any number of other objects to = which it is relevant utilizing relationships. > We make no guarantees that we have managed to implement this approach = flawlessly but we believe that it yields a good balance of consistency, = efficiency and flexibility. It also allows easy modular use of only what = is relevant within a given context and enables extension and evolution = to easily occur in a localized fashion rather than having to extend and = modify one monolithic structure standard. > =20 > Does that make sense? > =20 > sean > =20 > From: Michael Hammer [mailto:michael.hammer@yaanatech.com]=20 > Sent: Tuesday, April 17, 2012 9:18 AM > To: Barnum, Sean D.; osantos@cisco.com; Thomas.Millar@hq.dhs.gov; = lnunez@c3isecurity.com > Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; = sacm@ietf.org; m-terada@ipa.go.jp > Subject: RE: [mile] [sacm] CybOX v1.0 (Draft) is now released and live = onthe website > =20 > Sean, > =20 > Does the overlap between the various objects present a problem? > =20 > If there are one or more objects that could carry the same data, then = human nature means that probability-wise someone will choose data flow = instead of Netflow. > That is the underlying principle in Murphy=92s Law, where you try to = design it so that there is only one way to do it, and thus private = Murphy won=92t do it the =93wrong=94 way. > =20 > Just wondering if these should be mutually exclusive sets. And = designed as such. > Might improve interoperability. (And avoid discussions like this in = future.) J > =20 > Mike > =20 > =20 > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf = Of Barnum, Sean D. > Sent: Tuesday, April 17, 2012 1:10 AM > To: Omar Santos (osantos); Millar, Thomas; lnunez@c3isecurity.com > Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; = sacm@ietf.org; m-terada@ipa.go.jp > Subject: Re: [mile] [sacm] CybOX v1.0 (Draft) is now released and live = onthe website > =20 > =93upper layer=94? Yes, as in higher abstraction. > Just =93protocols=94? No. > =20 > You guys have been looking at this through the lens of network flow = which if fine for thinking about that perspective but it is important to = also realize that the EventTypeEnum and its =93Data Flow=94 value go far = beyond network-related scope. > It is about a lot of other types of potential data flows (as I just = outlined in a response to Tom) that have nothing to do with network = flow. > =20 > Thanks for your response though. This is the kind of discussions that = we hope to have a lot more of among the various supported communities. > =20 > =20 > BTW, you may have noticed that the Network_Flow object within CybOX = v1.0 (Draft) supports expression of netflow within several of the most = common formats including Netflow9 (as well as IPFIX as Luis pointed out, = Netflow5 and SiLK as well as bi-directional flow in YAF). The common = 5-tuple or 7-tuple (you describe) (in our case it is an 8-tuple as we = broke the router interface out into both ingress and egress J) shared by = pretty much all of the netflow approaches has been broken out into a = shared Network_Flow_Label structure. The various context-dependent = portions of the independent approaches are then captured within optional = structures dedicated to each of them. We hope that eventually the = community can work to come together towards a single overall common = expressive structure for netflow that meets the needs of all. We hope = that CybOX and its use can even help that sort of maturation and = normalization. But since no such universal structure exists today, we = decided to enable optional expression of the most common individual = formats within a single netflow object to serve the large majority of = relevant users, maintain flexibility and enable discussions and analysis = of netflow within a common package. > We look forward to continuing discussions with the community to = validate or invalidate this approach and to refine and mature going = forward. > =20 > Sean > =20 > From: Omar Santos (osantos) [mailto:osantos@cisco.com]=20 > Sent: Monday, April 16, 2012 11:57 PM > To: Millar, Thomas; Barnum, Sean D.; lnunez@c3isecurity.com > Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; = sacm@ietf.org; m-terada@ipa.go.jp > Subject: RE: [sacm] [mile] CybOX v1.0 (Draft) is now released and live = onthe website > =20 > I believe that what Sean is saying is that =93data flow=94 is just a = value that is meant for upper layer protocols. But, you have a good = point. Traditionally, a =93flow=94 in =93Netflow=94 is based on a set of = 5 and up to 7 IP packet attributes: > =20 > - IP source address > - IP destination address > - Source port > - Destination port > - Layer 3 protocol type > - Class of Service > - Router or switch interface > =20 > Although, there is a lot more support with Netflow version 9: > = http://www.cisco.com/en/US/technologies/tk648/tk362/technologies_white_pap= er09186a00800a3db9_ps6601_Products_White_Paper.html > =20 > =20 > =20 > Regards, >=20 > Omar > =20 > From: Millar, Thomas [mailto:Thomas.Millar@hq.dhs.gov]=20 > Sent: Monday, April 16, 2012 11:46 PM > To: sbarnum@mitre.org; Omar Santos (osantos); lnunez@c3isecurity.com > Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; = sacm@ietf.org; m-terada@ipa.go.jp > Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live = onthe website > =20 > If "data flow" is a euphemism for "netflow" is there any reason not to = call it that? >=20 > Tom Millar=20 > http://www.us-cert.gov/=20 > ------------------=20 > Missit me Rubus fruticosus:=20 > 202 631 1915=20 >=20 > =20 > From: Barnum, Sean D. [mailto:sbarnum@mitre.org]=20 > Sent: Monday, April 16, 2012 11:29 PM > To: Omar Santos (osantos) ; Luis Nunez = =20 > Cc: idxwg@nicwg.org ; mile@ietf.org ; = dallendoug@gmail.com; sacm@ietf.org = ; m-terada@ipa.go.jp =20 > Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live = onthe website=20 > =20 > Thanks Omar. > =20 > To answer your question, first let me point out to other readers that = the two entries that Omar is quoting here exist as values in an = enumeration called EventTypeEnum which as its name implies contains a = list of different labels for grouping types (or classes) of events to be = used as low-granularity buckets for characterizing and classifying = events. > Other entries in this enumeration include things like =93File Ops = (CRUD)=94, =93Process Mgt=94, =93Authorization (ACL)=94, etc. > =20 > The =93Packet Traffic=94 value is intended to characterize events = dealing with network packet traffic as its name implies. > The =93Data Flow=94 value is intended to characterize events dealing = with forms of data flow at a higher level of abstraction than just = packet traffic. The relationship between these two values could be = viewed as =93Packet Traffic=94 being a more detailed form of =93Data = Flow=94 just as the values =93App Layer Traffic=94 and =93HTTP Layer = Traffic=94, also in this enumeration, could be other levels in this same = abstraction stack. > The idea behind the varying levels of abstraction is to leave buckets = large enough to capture a wide variety of potential event types (e.g. = data flow events other than obvious things like packet traffic) but also = enable the use of smaller more specific buckets when they are = appropriate and commonly used. > =20 > Does this make sense? > =20 > sean > =20 > From: Omar Santos (osantos) [mailto:osantos@cisco.com]=20 > Sent: Monday, April 16, 2012 8:17 PM > To: Luis Nunez; Barnum, Sean D. > Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; = sacm@ietf.org; m-terada@ipa.go.jp > Subject: RE: [sacm] [mile] CybOX v1.0 (Draft) is now released and live = onthe website > =20 > I echo Luis=92 comments. It is good to see the inclusion of network = objects. Quick question to the team related to your netflow comment. > =20 > I am looking at: > http://cybox.mitre.org/XMLSchema/cybox_core_v1.0%28draft%29.xsd > =20 > =85 and it looks that we renamed it to =93Data Flow=94? > =20 > > > Specifies the class of events dealing with = data flow. > > > =20 > =20 > What is the difference between that and =93Packet Traffic=94? > =20 > > > Specifies the class of events dealing with = packet traffic. > > > =20 > =20 > =20 > =20 > Regards, >=20 > Omar Santos > Incident Manager, PSIRT > Security Research and Operations > Cisco Systems, Inc. > Email: os@cisco.com > Phone: +1 919 392 8635 > PGP Key: 0x3AF27EDC >=20 > Cisco.com - http://www.cisco.com > Cisco Security Advisories and Notices - http://www.cisco.com/go/psirt >=20 > This email may contain confidential and privileged material for the = sole > use of the intended recipient. Any review, use, distribution or > disclosure by others is strictly prohibited. If you are not the = intended > recipient (or authorized to receive for the recipient), please contact > the sender by reply email and delete all copies of this message. >=20 > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > =20 > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf = Of Luis Nunez > Sent: Monday, April 16, 2012 6:44 PM > To: Barnum, Sean D. > Cc: idxwg@nicwg.org; mile@ietf.org; Doug Wilson = (dallendoug@gmail.com); sacm@ietf.org; IPA-Masato Terada = (m-terada@ipa.go.jp) > Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live = onthe website > =20 > I like the inclusion of the network-centric objects. IPFIX (netflow) = will add an additional perspective from an incident information sharing = standpoint. =20 > =20 > -ln > =20 > On Apr 16, 2012, at 4:04 PM, Barnum, Sean D. wrote: > =20 >=20 > Hey everyone, > =20 > I just wanted to let you all know that CybOX v1.0 (Draft) content is = now live on the website. http://cybox.mitre.org > The release notes are provided inline below. > The key items of note are: > =B7 The release of two formal specifications for the CybOX = language (one for the core language and one for the defined objects) > =B7 The XML Schema has gone through extensive improvements for = expressiveness, clarity, consistency, efficiency, alignment to existing = normative references and documentation. > =B7 This release includes an initial set of language utilities: = a draft Snort -> CybOX transform, a draft OpenIOC -> CybOX transform, = and a set of Python bindings for the CybOX language. > =B7 The website now includes a small set of content examples. = This set will grow going forward. >=20 > This release involved a lot of hard work from a diverse group of = people. Thank you all for your contributions and effort. We could not = have done it without you. > We look forward to everyone=92s feedback and collaboration as we = continue to improve and mature the CybOX language. > =20 > Sean Barnum > =20 > =20 > =20 > CybOX v1.0 (Draft) Release Notes >=20 > The Version 1.0 (Draft) release of Cyber Observable eXpression = (CybOX=99) is intended as a draft release of an initial major version of = the CybOX Language that could be utilized for practical operational use = and integration into other standards efforts. This release consists of = three primary components: a pair of formal language specifications for = the core language content and defined objects content, a set of language = implementation XML schemas (core, common_types, and ~70 defined object = schemas), and a small initial set of language utilities including an = initial draft Snort->CybOX transform, an initial draft OpenIOC->CybOX = transform and a set of CybOX language Python bindings. Recognizing that = this is the first time that the formal language specifications will be = available for review and as such will likely generate feedback from new = stakeholders, this initial major version is being released as a =93draft=94= v1.0 with the expectation of cycles of new feedback and revision before = a =93final=94 v1.0 is released. > The CybOX v1.0 (Draft) XML schemas include a significant number of = changes from v0.7 to improve: > =B7 Clarity, documentation, and descriptive formality for = reference and implementation by other standards and users. > =B7 Consistency, simplicity, and efficiency. > =B7 Alignment (as appropriate) to existing normative references. > =B7 Expressiveness of the schema to better support the broad set = of use cases it targets (malware characterization, indicator and = incident data sharing, event management, etc.) including the addition of = an initial set of network-related defined objects. >=20 > Summary of changes from CybOX_v0.7 to CybOX_v1.0_(Draft): > =B7 Refinement of namespaces and schema locations for better = effectiveness and flexibility going forward. > =B7 Normalized all content according to an established set of = naming conventions. > =B7 Fully annotated all language items (types, attributes, = elements, etc.). > =B7 Moved several commonly leveraged types out of the core = schema and into common_types. > =B7 Achieved full typing of entire schema structure such that = all attributes and elements are definitively typed. > =B7 Changed all identifiers from ID and IDREF types to be QNames = enabling globally unique identifiers and flexibility for domain-specific = users of CybOX to define their own identifier syntax locally. > =B7 Reordered attributes and elements in numerous types to = better reflect common usage and priority. > =B7 Added major_version and minor_version attributes for core = schema. > =B7 Added capability to characterize source of overall = observable package data and for individual observables. > =B7 Modified the logical composition structure such that any = such compositions are now contained within a Observable_Composition = element providing improved simplicity and modularity. > =B7 Removed the Delta element from ObservableType and relocated = the appropriate portions (Change, Trend, and Frequency) to appropriate = locations under Stateful_Measure and Event. > =B7 Added a Domain_Specific_Object_Attributes field to Object = utilizing an abstract type that will allow domain-specific use cases to = add in their own domain-specific attributes for Objects. > =B7 Added a Tool-Specific_Data field to ToolInformationType = utilizing an abstract type that will allow addition of tool-specific = data. > =B7 Added an Indicators field to MeasureSourceType utilizing an = abstract type that will allow characterizing differing formats or = standards of indicators that may have led to the identification of the = observable data. > =B7 Enhanced the Hash structure to capture full fuzzy hashes in = addition to simple hashes > =B7 Added a new ExtractedFeaturesType that can be used to adorn = differing objects (e.g., files, memory, etc.) to capture extracted = strings, imports, functions and code snippets > =B7 Added a ByteRunsType to enable capture of byte runs within = various objects. > =B7 Added object_reference attribute to DefinedObjectType to = better support referencing of independently defined Objects from within = another Object definition. > =B7 Added a generic DataSegmentType to provide a relatively = abstract way of characterizing data segments that may be = written/read/transmitted or otherwise utilized in actions or defined in = objects. > =B7 Added several new defined object schemas (API, Code, = Device, DNS_Record, Network_Flow, Network_Packet, Network_Route_Entry, = Network_Subnet, Unix_Network_Route_Entry) including an initial set of = network-centric defined objects. > =B7 Modified every defined object schema with added annotations = as well as minor and in some cases substantive changes to fix errors, = improve consistency and alignment with existing normative references, = and to improve expressiveness in support of the targeted use cases. > Detailed changes from CybOX_v0.7 to CybOX_v1.0_(Draft): > The level of changes within v1.0 (Draft) in the core schema, = common_types and the defined object schemas is too great to list every = change in these release notes. Detailed difference reports are available = for each individual schema = at:http://cybox.mitre.org/XMLSchema/release_notes/cybox_v1.0(draft)_diff_r= eports.zip > =20 > =20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Sean Barnum > Cyber Security Principal > The MITRE Corporation > Email: sbarnum@mitre.org > =20 > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile --Apple-Mail=_C592CC56-27E2-42C3-9DBB-7D60E3E22307 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 The salient point is IPFIX/Netflow is about = accounting details of packet traffic summaries (who,what, where, when = and how many times).


The following = articles could provide the basis for a use case around leveraging IPFIX = to characterize an observable for information = sharing.


-ln

On= Apr 17, 2012, at 3:28 PM, Michael Hammer wrote:

What = you say makes sense.  But, if you will bear with me.  (Still = learning this.)
If = one used Packet Traffic event type always instead of Data Flow event = type, would some distinction be lost?
Or, put another way, since the = packet stuff seems to cover most network-based events, does Data Flow = involve something that is not on the wire?
(Such as an inter-process = communication that doesn=92t go through a protocol = stack.)
From: Barnum, Sean D. = [mailto:sbarnum@mitre.org] 
Sent: Tuesday, April 17, 2012 = 3:03 PM
To: Michael Hammer; osantos@cisco.com; Thomas.Millar@hq.dhs.gov; = lnunez@c3isecurity.com
Cc= : idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; m-terada@ipa.go.jp
Subject: RE: [mile] [sacm] = CybOX v1.0 (Draft) is now released and live onthe = website
Just = to clarify, all of our discussion so far about =93Data Flow=94 and = netflow were all in regards to an enumeration called EventTypeEnum that = simply lets you tag a cyber observable event with a type label. It is = metadata for an event description.
The only object we have been = talking about in any detail so far was the Network_Flow object. These = two topics are totally independent of each other. There is no Data_Flow = object.
The = abstraction overlap we have been discussing is only in the metadata tag = applied to an event to characterize what type/class of event it = is.
The = defined objects themselves (including Network_Flow) have been designed = to avoid, as much as possible, overlap of the type you = describe.
The = approach we have taken is that where there is common structure and = meaning relevant to multiple different types of objects, the structure = for that commonality is broken out into its own object (e.g. Address, = URI, Port, Account, Process, etc.).
Content based on this common = object structure can be embedded within a leveraging object (via direct = use of the object type) if the content is directly relevant only within = the context of that object or as an independent object and associated to = any number of other objects to which it is relevant utilizing = relationships.
We = make no guarantees that we have managed to implement this approach = flawlessly but we believe that it yields a good balance of consistency, = efficiency and flexibility. It also allows easy modular use of only what = is relevant within a given context and enables extension and evolution = to easily occur in a localized fashion rather than having to extend and = modify one monolithic structure standard.
Does = that make sense?
BTW, you may have noticed that = the Network_Flow object within CybOX v1.0 (Draft) supports expression of = netflow within several of the most common formats including Netflow9 (as = well as IPFIX as Luis pointed out, Netflow5 and SiLK as well as = bi-directional flow in YAF). The common 5-tuple or 7-tuple (you = describe) (in our case it is an 8-tuple as we broke the router interface = out into both ingress and egress J) shared by pretty much all of = the netflow approaches has been broken out into a shared = Network_Flow_Label structure. The various context-dependent portions of = the independent approaches are then captured within optional structures = dedicated to each of them. We hope that eventually the community can = work to come together towards a single overall common expressive = structure for netflow that meets the needs of all. We hope that CybOX = and its use can even help that sort of maturation and normalization. But = since no such universal structure exists today, we decided to enable = optional expression of the most common individual formats within a = single netflow object to serve the large majority of relevant users, = maintain flexibility and enable discussions and analysis of netflow = within a common package.
: Barnum, Sean D. [mailto:sbarnum@mitre.org] 
Sent: Monday, = April 16, 2012 11:29 PM
To: Omar Santos (osantos) <osantos@cisco.com>; Luis Nunez <lnunez@c3isecurity.com> 
Cc: idxwg@nicwg.org <idxwg@nicwg.org>; mile@ietf.org <mile@ietf.org>; dallendoug@gmail.com<dallendoug@gmail.com>; sacm@ietf.org <sacm@ietf.org>; m-terada@ipa.go.jp <m-terada@ipa.go.jp> 
Subject: Re: = [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe = website 
 <= /div>
Thanks = Omar.
To = answer your question, first let me point out to other readers that the = two entries that Omar is quoting here exist as values in an enumeration = called EventTypeEnum which as its name implies contains a list of = different labels for grouping types (or classes) of events to be used as = low-granularity buckets for characterizing and classifying = events.
Other = entries in this enumeration include things like =93File Ops (CRUD)=94, = =93Process Mgt=94, =93Authorization (ACL)=94, = etc.
The = =93Packet Traffic=94 value is intended to characterize events dealing = with network packet traffic as its name = implies.
The = =93Data Flow=94 value is intended to characterize events dealing with = forms of data flow at a higher level of abstraction than just packet = traffic. The relationship between these two values could be viewed as = =93Packet Traffic=94 being a more detailed form of =93Data Flow=94 just = as the values =93App Layer Traffic=94 and =93HTTP Layer Traffic=94, also = in this enumeration, could be other levels in this same abstraction = stack.
The = idea behind the varying levels of abstraction is to leave  buckets = large enough to capture a wide variety of potential event types (e.g. = data flow events other than obvious things like packet traffic) but also = enable the use of smaller more specific buckets when they are = appropriate and commonly used.
Does = this make sense?
From: Omar Santos (osantos) [mailto:osantos@cisco.com] 
Sent: Monday, April 16, 2012 8:17 = PM
To: Luis = Nunez; Barnum, Sean D.
Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org;  RE: [sacm] [mile] CybOX = v1.0 (Draft) is now released and live onthe = website
 
 
The release notes are provided inline =
below.
The key =
items of note are:
=B7 The =
release of two formal specifications for the CybOX language (one for the =
core language and one for the defined =
objects)
=B7 The XML =
Schema has gone through extensive improvements for expressiveness, =
clarity, consistency, efficiency, alignment to existing normative =
references and documentation.
=B7 This =
release includes an initial set of language utilities: a draft Snort =
-> CybOX transform, a draft OpenIOC -> CybOX transform, and a set =
of Python bindings for the CybOX =
language.
=B7 The =
website now includes a small set of content examples. This set will grow =
going forward.
This =
release involved a lot of hard work from a diverse group of people. =
Thank you all for your contributions and effort. We could not have done =
it without you.
We look forward to everyone=92s feedback and collaboration =
as we continue to improve and mature the CybOX =
language.
Sean =
Barnum
CybOX v1.0 (Draft) Release =
Notes
The Version =
1.0 (Draft) release of Cyber Observable eXpression (CybOX=99) is intended as a =
draft release of an initial major version of the CybOX Language that =
could be utilized for practical operational use and integration into =
other standards efforts. This release consists of three primary =
components: a pair of formal language specifications for the core =
language content and defined objects content, a set of language =
implementation XML schemas (core, common_types, and ~70 defined object =
schemas), and a small initial set of language utilities including an =
initial draft Snort->CybOX transform, an initial draft =
OpenIOC->CybOX transform and a set of CybOX language Python bindings. =
Recognizing that this is the first time that the formal language =
specifications will be available for review and as such will likely =
generate feedback from new stakeholders, this initial major version is =
being released as a =93draft=94 v1.0 with the expectation of cycles of =
new feedback and revision before a =93final=94 v1.0 is released.The CybOX v1.0 =
(Draft) XML schemas include a significant number of changes from v0.7 to =
improve:
=B7 Clarity, =
documentation, and descriptive formality for reference and =
implementation by other standards and users.
=B7 Consistency, =
simplicity, and efficiency.
=B7       Alignment (as =
appropriate) to existing normative references.=B7       Expressiveness of =
the schema to better support the broad set of use cases it targets =
(malware characterization, indicator and incident data sharing, event =
management, etc.) including the addition of an initial set of =
network-related defined objects.
Summary of changes from CybOX_v0.7 to =
CybOX_v1.0_(Draft):
       Refineme=
nt of namespaces and schema locations for better effectiveness and =
flexibility going forward.
       Normaliz=
ed all content according to an established set of naming =
conventions.
=B7 Fully =
annotated all language items (types, attributes, elements, etc.).=B7 Moved =
several commonly leveraged types out of the core schema and into =
common_types.
=B7 Achieved=
 full typing of entire schema structure such that all attributes and =
elements are definitively typed.
=B7 Changed =
all identifiers from ID and IDREF types to be QNames enabling globally =
unique identifiers and flexibility for domain-specific users of CybOX to =
define their own identifier syntax locally.
=B7 Reordere=
d attributes and elements in numerous types to better reflect common =
usage and priority.
=B7 Added =
major_version and minor_version attributes for core schema.=B7 Added =
capability to characterize source of overall observable package data and =
for individual observables.
       Modified=
 the logical composition structure such that any such compositions are =
now contained within a Observable_Composition element providing improved =
simplicity and modularity.
       Removed =
the Delta element from ObservableType and relocated the appropriate =
portions (Change, Trend, and Frequency) to appropriate locations under =
Stateful_Measure and Event.
       Added =
a Domain_Specific_Object_Attributes field to Object utilizing an =
abstract type that will allow domain-specific use cases to add in their =
own domain-specific attributes for Objects.
=B7 Added =
a Tool-Specific_Data field to ToolInformationType utilizing an abstract =
type that will allow addition of tool-specific data.=B7 Added =
an Indicators field to MeasureSourceType utilizing an abstract type that =
will allow characterizing differing formats or standards of indicators =
that may have led to the identification of the observable data.=B7 Enhanced=
 the Hash structure to capture full fuzzy hashes in addition to simple =
hashes=B7 Added =
a new ExtractedFeaturesType that can be used to adorn differing objects =
(e.g., files, memory, etc.) to capture extracted strings, imports, =
functions and code snippets
       Added =
a ByteRunsType to enable capture of byte runs within various =
objects.
=B7 Added =
object_reference attribute to DefinedObjectType to better support =
referencing of independently defined Objects from within another Object =
definition.
=B7 Added =
a generic DataSegmentType to provide a relatively abstract way of =
characterizing data segments that may be written/read/transmitted or =
otherwise utilized in actions or defined in objects.
=B7 Added several new =
defined object schemas (API, Code, Device, DNS_Record, Network_Flow, =
Network_Packet, Network_Route_Entry, Network_Subnet, =
Unix_Network_Route_Entry) including an initial set of network-centric =
defined objects.=B7 Modified=
 every defined object schema with added annotations as well as minor and =
in some cases substantive changes to fix errors, improve consistency and =
alignment with existing normative references, and to improve =
expressiveness in support of the targeted use cases.
Detailed changes from CybOX_v0.7 to =
CybOX_v1.0_(Draft):
The level of =
changes within v1.0 (Draft) in the core schema, common_types and the =
defined object schemas is too great to list every change in these =
release notes. Detailed difference reports are available for each =
individual schema at: 
Sean Barnum
Cyber Security =
Principal
The MITRE Corporation
Email: sbarnum@mitre.orgmile@ietf.org

To: Michael Hammer , "osantos@cisco.com" , "Thomas.Millar@hq.dhs.gov" ,  "lnunez@c3isecurity.com" 
Thread-Topic: [mile] [sacm] CybOX v1.0 (Draft) is now released and live onthe website
Thread-Index: AQHNHJx9CTO+wm8DM0KsuNMXzL3C5ZafV3hggABS0QD//8vnoA==
Date: Tue, 17 Apr 2012 20:47:23 +0000
Message-ID: <7F48813B48558A4BB5CB7BB714E5B5A9173115@IMCMBX03.MITRE.ORG>
References: <7F48813B48558A4BB5CB7BB714E5B5A9171B16@IMCMBX03.MITRE.ORG> <69CE2DCD9DAC3D48B830E0723141170B02A39BD2@ZAU1UG-0308.DHSNET.DS1.DHS> <953A2E460DBE7C43AC13E30B87C5B4FF080A1C09@XMB-RCD-106.cisco.com> <7F48813B48558A4BB5CB7BB714E5B5A9171BA1@IMCMBX03.MITRE.ORG> <00C069FD01E0324C9FFCADF539701DB389FC37@EX2K10MB1.corp.yaanatech.com> <7F48813B48558A4BB5CB7BB714E5B5A9173046@IMCMBX03.MITRE.ORG> <00C069FD01E0324C9FFCADF539701DB38A0193@EX2K10MB1.corp.yaanatech.com>
In-Reply-To: <00C069FD01E0324C9FFCADF539701DB38A0193@EX2K10MB1.corp.yaanatech.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [172.31.135.134]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00B5_01CD1CB9.BDEF3370"
MIME-Version: 1.0
Cc: "idxwg@nicwg.org" , "mile@ietf.org" , "dallendoug@gmail.com" , "sacm@ietf.org" , "m-terada@ipa.go.jp" 
Subject: Re: [mile] [sacm] CybOX v1.0 (Draft) is now released and live onthe website
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, 17 Apr 2012 20:47:32 -0000

------=_NextPart_000_00B5_01CD1CB9.BDEF3370
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_00B6_01CD1CB9.BDEF3370"


------=_NextPart_001_00B6_01CD1CB9.BDEF3370
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Mike,

=20

If you always utilized the most abstract label (Data Flow) to adorn =
events even when you knew the more specific type that they were and had =
a more specific label for them, then yes you would lose distinction.

Such misuse is always the potential downside of enabling flexibility =
through abstraction.

If you know that the event you are characterizing has to do with Packet =
Traffic and not just some form of more general data flow that does not =
have an appropriate associated event type label, then you should =
absolutely use Packet Traffic and not Data Flow. An event should only be =
tagged with an abstract label like Data Flow if there is not an =
appropriate more concrete label available.

=20

In answer to your second question, yes Data Flow definitely covers not =
only network-related events but also events that have nothing to do with =
the wire.

My response to Tom Millar that I sent at 12:52am this morning lists out =
several non-network related types of events that Data Flow could apply =
to.

=20

Please do not feel bad for asking these questions. They help you =
understand our approach, they help others understand our approach, they =
help us better understand the perspective of the communities we are =
targeting to support, they help us uncover issues with our approach or =
implementation, and they help us understand where we need to explain =
ourselves better.

=20

Thank you for the constructive discourse.

=20

sean

=20

From: Michael Hammer [mailto:michael.hammer@yaanatech.com]=20
Sent: Tuesday, April 17, 2012 3:28 PM
To: Barnum, Sean D.; osantos@cisco.com; Thomas.Millar@hq.dhs.gov; =
lnunez@c3isecurity.com
Cc: idxwg@nicwg.org; mile@ietf.org; sacm@ietf.org; m-terada@ipa.go.jp; =
dallendoug@gmail.com
Subject: RE: [mile] [sacm] CybOX v1.0 (Draft) is now released and live =
onthe website

=20

Sean,

=20

What you say makes sense.  But, if you will bear with me.  (Still =
learning this.)

=20

If one used Packet Traffic event type always instead of Data Flow event =
type, would some distinction be lost?

Or, put another way, since the packet stuff seems to cover most =
network-based events, does Data Flow involve something that is not on =
the wire?

(Such as an inter-process communication that doesn=E2=80=99t go through =
a protocol stack.)

=20

Mike

=20

=20

From: Barnum, Sean D. [mailto:sbarnum@mitre.org]=20
Sent: Tuesday, April 17, 2012 3:03 PM
To: Michael Hammer; osantos@cisco.com; Thomas.Millar@hq.dhs.gov; =
lnunez@c3isecurity.com
Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; =
m-terada@ipa.go.jp
Subject: RE: [mile] [sacm] CybOX v1.0 (Draft) is now released and live =
onthe website

=20

Mike,

=20

Just to clarify, all of our discussion so far about =E2=80=9CData =
Flow=E2=80=9D and netflow were all in regards to an enumeration called =
EventTypeEnum that simply lets you tag a cyber observable event with a =
type label. It is metadata for an event description.

The only object we have been talking about in any detail so far was the =
Network_Flow object. These two topics are totally independent of each =
other. There is no Data_Flow object.

The abstraction overlap we have been discussing is only in the metadata =
tag applied to an event to characterize what type/class of event it is.

=20

The defined objects themselves (including Network_Flow) have been =
designed to avoid, as much as possible, overlap of the type you =
describe.

The approach we have taken is that where there is common structure and =
meaning relevant to multiple different types of objects, the structure =
for that commonality is broken out into its own object (e.g. Address, =
URI, Port, Account, Process, etc.).

Content based on this common object structure can be embedded within a =
leveraging object (via direct use of the object type) if the content is =
directly relevant only within the context of that object or as an =
independent object and associated to any number of other objects to =
which it is relevant utilizing relationships.

We make no guarantees that we have managed to implement this approach =
flawlessly but we believe that it yields a good balance of consistency, =
efficiency and flexibility. It also allows easy modular use of only what =
is relevant within a given context and enables extension and evolution =
to easily occur in a localized fashion rather than having to extend and =
modify one monolithic structure standard.

=20

Does that make sense?

=20

sean

=20

From: Michael Hammer [mailto:michael.hammer@yaanatech.com]=20
Sent: Tuesday, April 17, 2012 9:18 AM
To: Barnum, Sean D.; osantos@cisco.com; Thomas.Millar@hq.dhs.gov; =
lnunez@c3isecurity.com
Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; =
m-terada@ipa.go.jp
Subject: RE: [mile] [sacm] CybOX v1.0 (Draft) is now released and live =
onthe website

=20

Sean,

=20

Does the overlap between the various objects present a problem?

=20

If there are one or more objects that could carry the same data, then =
human nature means that probability-wise someone will choose data flow =
instead of Netflow.

That is the underlying principle in Murphy=E2=80=99s Law, where you try =
to design it so that there is only one way to do it, and thus private =
Murphy won=E2=80=99t do it the =E2=80=9Cwrong=E2=80=9D way.

=20

Just wondering if these should be mutually exclusive sets.  And designed =
as such.

Might improve interoperability.  (And avoid discussions like this in =
future.)  J

=20

Mike

=20

=20

From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of =
Barnum, Sean D.
Sent: Tuesday, April 17, 2012 1:10 AM
To: Omar Santos (osantos); Millar, Thomas; lnunez@c3isecurity.com
Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; =
m-terada@ipa.go.jp
Subject: Re: [mile] [sacm] CybOX v1.0 (Draft) is now released and live =
onthe website

=20

=E2=80=9Cupper layer=E2=80=9D? Yes, as in higher abstraction.

Just =E2=80=9Cprotocols=E2=80=9D? No.

=20

You guys have been looking at this through the lens of network flow =
which if fine for thinking about that perspective but it is important to =
also realize that the EventTypeEnum and its =E2=80=9CData Flow=E2=80=9D =
value go far beyond network-related scope.

It is about a lot of other types of potential data flows (as I just =
outlined in a response to Tom) that have nothing to do with network =
flow.

=20

Thanks for your response though. This is the kind of discussions that we =
hope to have a lot more of among the various supported communities.

=20

=20

BTW, you may have noticed that the Network_Flow object within CybOX v1.0 =
(Draft) supports expression of netflow within several of the most common =
formats including Netflow9 (as well as IPFIX as Luis pointed out, =
Netflow5 and SiLK as well as bi-directional flow in YAF). The common =
5-tuple or 7-tuple (you describe) (in our case it is an 8-tuple as we =
broke the router interface out into both ingress and egress J) shared by =
pretty much all of the netflow approaches has been broken out into a =
shared Network_Flow_Label structure. The various context-dependent =
portions of the independent approaches are then captured within optional =
structures dedicated to each of them. We hope that eventually the =
community can work to come together towards a single overall common =
expressive structure for netflow that meets the needs of all. We hope =
that CybOX and its use can even help that sort of maturation and =
normalization. But since no such universal structure exists today, we =
decided to enable optional expression of the most common individual =
formats within a single netflow object to serve the large majority of =
relevant users, maintain flexibility and enable discussions and analysis =
of netflow within a common package.

We look forward to continuing discussions with the community to validate =
or invalidate this approach and to refine and mature going forward.

=20

Sean=20

=20

From: Omar Santos (osantos) [mailto:osantos@cisco.com]=20
Sent: Monday, April 16, 2012 11:57 PM
To: Millar, Thomas; Barnum, Sean D.; lnunez@c3isecurity.com
Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; =
m-terada@ipa.go.jp
Subject: RE: [sacm] [mile] CybOX v1.0 (Draft) is now released and live =
onthe website

=20

I believe that what Sean is saying is that =E2=80=9Cdata flow=E2=80=9D =
is just a value that is meant for upper layer protocols. But, you have a =
good point. Traditionally, a =E2=80=9Cflow=E2=80=9D in =
=E2=80=9CNetflow=E2=80=9D is based on a set of 5 and up to 7 IP packet =
attributes:

=20

- IP source address

- IP destination address

- Source port

- Destination port

- Layer 3 protocol type

- Class of Service

- Router or switch interface

=20

Although, there is a lot more support with Netflow version 9:

http://www.cisco.com/en/US/technologies/tk648/tk362/technologies_white_pa=
per09186a00800a3db9_ps6601_Products_White_Paper.html

=20

=20

=20

Regards,

Omar=20

=20

From: Millar, Thomas [mailto:Thomas.Millar@hq.dhs.gov]=20
Sent: Monday, April 16, 2012 11:46 PM
To: sbarnum@mitre.org; Omar Santos (osantos); lnunez@c3isecurity.com
Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; =
m-terada@ipa.go.jp
Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live =
onthe website

=20

If "data flow" is a euphemism for "netflow" is there any reason not to =
call it that?

Tom Millar=20
http://www.us-cert.gov/=20
------------------=20
Missit me Rubus fruticosus:=20
202 631 1915=20

=20

From: Barnum, Sean D. [mailto:sbarnum@mitre.org]=20
Sent: Monday, April 16, 2012 11:29 PM
To: Omar Santos (osantos) ; Luis Nunez =
=20
Cc: idxwg@nicwg.org ; mile@ietf.org ; =
dallendoug@gmail.com ; sacm@ietf.org =
; m-terada@ipa.go.jp =20
Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live =
onthe website=20
=20

Thanks Omar.

=20

To answer your question, first let me point out to other readers that =
the two entries that Omar is quoting here exist as values in an =
enumeration called EventTypeEnum which as its name implies contains a =
list of different labels for grouping types (or classes) of events to be =
used as low-granularity buckets for characterizing and classifying =
events.

Other entries in this enumeration include things like =E2=80=9CFile Ops =
(CRUD)=E2=80=9D, =E2=80=9CProcess Mgt=E2=80=9D, =E2=80=9CAuthorization =
(ACL)=E2=80=9D, etc.

=20

The =E2=80=9CPacket Traffic=E2=80=9D value is intended to characterize =
events dealing with network packet traffic as its name implies.

The =E2=80=9CData Flow=E2=80=9D value is intended to characterize events =
dealing with forms of data flow at a higher level of abstraction than =
just packet traffic. The relationship between these two values could be =
viewed as =E2=80=9CPacket Traffic=E2=80=9D being a more detailed form of =
=E2=80=9CData Flow=E2=80=9D just as the values =E2=80=9CApp Layer =
Traffic=E2=80=9D and =E2=80=9CHTTP Layer Traffic=E2=80=9D, also in this =
enumeration, could be other levels in this same abstraction stack.

The idea behind the varying levels of abstraction is to leave  buckets =
large enough to capture a wide variety of potential event types (e.g. =
data flow events other than obvious things like packet traffic) but also =
enable the use of smaller more specific buckets when they are =
appropriate and commonly used.

=20

Does this make sense?=20

=20

sean

=20

From: Omar Santos (osantos) [mailto:osantos@cisco.com]=20
Sent: Monday, April 16, 2012 8:17 PM
To: Luis Nunez; Barnum, Sean D.
Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; =
m-terada@ipa.go.jp
Subject: RE: [sacm] [mile] CybOX v1.0 (Draft) is now released and live =
onthe website

=20

I echo Luis=E2=80=99 comments. It is good to see the inclusion of =
network objects. Quick question to the team related to your netflow =
comment.

=20

I am looking at:

http://cybox.mitre.org/XMLSchema/cybox_core_v1.0%28draft%29.xsd

=20

=E2=80=A6 and it looks that we renamed it to =E2=80=9CData =
Flow=E2=80=9D?

=20



   

        Specifies the class of events dealing with =
data flow.

   



=20

=20

What is the difference between that and =E2=80=9CPacket =
Traffic=E2=80=9D?

=20


   
     Specifies the class of events dealing with packet =
traffic.
   


=20

=20

=20

=20

Regards,

Omar Santos
Incident Manager, PSIRT
Security Research and Operations
Cisco Systems, Inc.
Email: os@cisco.com
Phone: +1 919 392 8635
PGP Key: 0x3AF27EDC

Cisco.com - http://www.cisco.com
Cisco Security Advisories and Notices - http://www.cisco.com/go/psirt

This email may contain confidential and privileged material for the sole
use of the intended recipient. Any review, use, distribution or
disclosure by others is strictly prohibited. If you are not the intended
recipient (or authorized to receive for the recipient), please contact
the sender by reply email and delete all copies of this message.

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

=20

From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of =
Luis Nunez
Sent: Monday, April 16, 2012 6:44 PM
To: Barnum, Sean D.
Cc: idxwg@nicwg.org; mile@ietf.org; Doug Wilson (dallendoug@gmail.com); =
sacm@ietf.org; IPA-Masato Terada (m-terada@ipa.go.jp)
Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live =
onthe website

=20

I like the inclusion of the network-centric objects.  IPFIX (netflow)  =
will add an additional perspective from an incident information sharing =
standpoint. =20

=20

-ln

=20

On Apr 16, 2012, at 4:04 PM, Barnum, Sean D. wrote:

=20

Hey everyone,

=20

I just wanted to let you all know that CybOX v1.0 (Draft) content is now =
live on the website. http://cybox.mitre.org

The release notes are provided inline below.

The key items of note are:

=C2=B7        The release of two formal specifications for the CybOX =
language (one for the core language and one for the defined objects)

=C2=B7        The XML Schema has gone through extensive improvements for =
expressiveness, clarity, consistency, efficiency, alignment to existing =
normative references and documentation.

=C2=B7        This release includes an initial set of language =
utilities: a draft Snort -> CybOX transform, a draft OpenIOC -> CybOX =
transform, and a set of Python bindings for the CybOX language.

=C2=B7        The website now includes a small set of content examples. =
This set will grow going forward.

This release involved a lot of hard work from a diverse group of people. =
Thank you all for your contributions and effort. We could not have done =
it without you.

We look forward to everyone=E2=80=99s feedback and collaboration as we =
continue to improve and mature the CybOX language.

=20

Sean Barnum

=20

=20

=20

CybOX v1.0 (Draft) Release Notes

The Version 1.0 (Draft) release of Cyber Observable eXpression =
(CybOX=E2=84=A2) is intended as a draft release of an initial major =
version of the CybOX Language that could be utilized for practical =
operational use and integration into other standards efforts. This =
release consists of three primary components: a pair of formal language =
specifications for the core language content and defined objects =
content, a set of language implementation XML schemas (core, =
common_types, and ~70 defined object schemas), and a small initial set =
of language utilities including an initial draft Snort->CybOX transform, =
an initial draft OpenIOC->CybOX transform and a set of CybOX language =
Python bindings. Recognizing that this is the first time that the formal =
language specifications will be available for review and as such will =
likely generate feedback from new stakeholders, this initial major =
version is being released as a =E2=80=9Cdraft=E2=80=9D v1.0 with the =
expectation of cycles of new feedback and revision before a =
=E2=80=9Cfinal=E2=80=9D v1.0 is released.

The CybOX v1.0 (Draft) XML schemas include a significant number of =
changes from v0.7 to improve:

=C2=B7       Clarity, documentation, and descriptive formality for =
reference and implementation by other standards and users.

=C2=B7       Consistency, simplicity, and efficiency.

=C2=B7       Alignment (as appropriate) to existing normative =
references.

=C2=B7       Expressiveness of the schema to better support the broad =
set of use cases it targets (malware characterization, indicator and =
incident data sharing, event management, etc.) including the addition of =
an initial set of network-related defined objects.

Summary of changes from CybOX_v0.7 to CybOX_v1.0_(Draft):

=C2=B7        Refinement of namespaces and schema locations for better =
effectiveness and flexibility going forward.

=C2=B7        Normalized all content according to an established set of =
naming conventions.

=C2=B7        Fully annotated all language items (types, attributes, =
elements, etc.).

=C2=B7        Moved several commonly leveraged types out of the core =
schema and into common_types.

=C2=B7        Achieved full typing of entire schema structure such that =
all attributes and elements are definitively typed.

=C2=B7        Changed all identifiers from ID and IDREF types to be =
QNames enabling globally unique identifiers and flexibility for =
domain-specific users of CybOX to define their own identifier syntax =
locally.

=C2=B7        Reordered attributes and elements in numerous types to =
better reflect common usage and priority.

=C2=B7        Added major_version and minor_version attributes for core =
schema.

=C2=B7        Added capability to characterize source of overall =
observable package data and for individual observables.

=C2=B7        Modified the logical composition structure such that any =
such compositions are now contained within a Observable_Composition =
element providing improved simplicity and modularity.

=C2=B7        Removed the Delta element from ObservableType and =
relocated the appropriate portions (Change, Trend, and Frequency) to =
appropriate locations under Stateful_Measure and Event.

=C2=B7        Added a Domain_Specific_Object_Attributes field to Object =
utilizing an abstract type that will allow domain-specific use cases to =
add in their own domain-specific attributes for Objects.

=C2=B7        Added a Tool-Specific_Data field to ToolInformationType =
utilizing an abstract type that will allow addition of tool-specific =
data.

=C2=B7        Added an Indicators field to MeasureSourceType utilizing =
an abstract type that will allow characterizing differing formats or =
standards of indicators that may have led to the identification of the =
observable data.

=C2=B7        Enhanced the Hash structure to capture full fuzzy hashes =
in addition to simple hashes

=C2=B7        Added a new ExtractedFeaturesType that can be used to =
adorn differing objects (e.g., files, memory, etc.) to capture extracted =
strings, imports, functions and code snippets

=C2=B7        Added a ByteRunsType to enable capture of byte runs within =
various objects.

=C2=B7        Added object_reference attribute to DefinedObjectType to =
better support referencing of independently defined Objects from within =
another Object definition.

=C2=B7        Added a generic DataSegmentType to provide a relatively =
abstract way of characterizing data segments that may be =
written/read/transmitted or otherwise utilized in actions or defined in =
objects.

=C2=B7        Added several new defined object schemas (API, Code, =
Device, DNS_Record, Network_Flow, Network_Packet, Network_Route_Entry, =
Network_Subnet, Unix_Network_Route_Entry) including an initial set of =
network-centric defined objects.

=C2=B7        Modified every defined object schema with added =
annotations as well as minor and in some cases substantive changes to =
fix errors, improve consistency and alignment with existing normative =
references, and to improve expressiveness in support of the targeted use =
cases.

Detailed changes from CybOX_v0.7 to CybOX_v1.0_(Draft):

The level of changes within v1.0 (Draft) in the core schema, =
common_types and the defined object schemas is too great to list every =
change in these release notes. Detailed difference reports are available =
for each individual schema at: =
 =
http://cybox.mitre.org/XMLSchema/release_notes/cybox_v1.0(draft)_diff_rep=
orts.zip

=20

=20

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Sean Barnum

Cyber Security Principal

The MITRE Corporation

Email: sbarnum@mitre.org

=20

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

=20


------=_NextPart_001_00B6_01CD1CB9.BDEF3370
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable


Mike,
 
If you always =
utilized the most abstract label (Data Flow) to adorn events even when =
you knew the more specific type that they were and had a more specific =
label for them, then yes you would lose =
distinction.
Such misuse =
is always the potential downside of enabling flexibility through =
abstraction.
If you know =
that the event you are characterizing has to do with Packet Traffic and =
not just some form of more general data flow that does not have an =
appropriate associated event type label, then you should absolutely use =
Packet Traffic and not Data Flow. An event should only be tagged with an =
abstract label like Data Flow if there is not an appropriate more =
concrete label available.
 
In answer to =
your second question, yes Data Flow definitely covers not only =
network-related events but also events that have nothing to do with the =
wire.
My response =
to Tom Millar that I sent at 12:52am this morning lists out several =
non-network related types of events that Data Flow could apply =
to.
 
Please do not =
feel bad for asking these questions. They help you understand our =
approach, they help others understand our approach, they help us better =
understand the perspective of the communities we are targeting to =
support, they help us uncover issues with our approach or =
implementation, and they help us understand where we need to explain =
ourselves better.
 
Thank you for =
the constructive discourse.
 
sean
 
From:=
 =
Michael Hammer [mailto:michael.hammer@yaanatech.com] 
Sent: =
Tuesday, April 17, 2012 3:28 PM
To: Barnum, Sean D.; =
osantos@cisco.com; Thomas.Millar@hq.dhs.gov; =
lnunez@c3isecurity.com
Cc: idxwg@nicwg.org; mile@ietf.org; =
sacm@ietf.org; m-terada@ipa.go.jp; =
dallendoug@gmail.com
Subject: RE: [mile] [sacm] CybOX v1.0 =
(Draft) is now released and live onthe =
website
 
Sean,
 
What you say makes sense.  But, if you will bear with me.  =
(Still learning this.)
 
If one used Packet Traffic event type always instead of Data Flow =
event type, would some distinction be lost?
Or, put another way, since the packet stuff seems to cover most =
network-based events, does Data Flow involve something that is not on =
the wire?
(Such as an inter-process communication that doesn=E2=80=99t go =
through a protocol stack.)
 
Mike
 
 
From:=
 =
Barnum, Sean D. [mailto:sbarnum@mitre.org]=
 
Sent: Tuesday, April 17, 2012 3:03 PM
To: Michael =
Hammer; osantos@cisco.com; Thomas.Millar@hq.dhs.gov; =
lnunez@c3isecurity.com
C=
c: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; m-terada@ipa.go.jp
Subject:<=
/b> RE: [mile] [sacm] CybOX v1.0 (Draft) is now released and live onthe =
website
 
Mike,
 
Just to clarify, all of our discussion so far about =E2=80=9CData =
Flow=E2=80=9D and netflow were all in regards to an enumeration called =
EventTypeEnum that simply lets you tag a cyber observable event with a =
type label. It is metadata for an event =
description.
The only object we have been talking about in any detail so far was =
the Network_Flow object. These two topics are totally independent of =
each other. There is no Data_Flow object.
The abstraction overlap we have been discussing is only in the =
metadata tag applied to an event to characterize what type/class of =
event it is.
 
The defined objects themselves (including Network_Flow) have been =
designed to avoid, as much as possible, overlap of the type you =
describe.
The approach we have taken is that where there is common structure =
and meaning relevant to multiple different types of objects, the =
structure for that commonality is broken out into its own object (e.g. =
Address, URI, Port, Account, Process, etc.).
Content based on this common object structure can be embedded within =
a leveraging object (via direct use of the object type) if the content =
is directly relevant only within the context of that object or as an =
independent object and associated to any number of other objects to =
which it is relevant utilizing relationships.
We make no guarantees that we have managed to implement this approach =
flawlessly but we believe that it yields a good balance of consistency, =
efficiency and flexibility. It also allows easy modular use of only what =
is relevant within a given context and enables extension and evolution =
to easily occur in a localized fashion rather than having to extend and =
modify one monolithic structure standard.
 
Does that make sense?
 
sean
 
From:=
 =
Michael Hammer [mailto:michael.ham=
mer@yaanatech.com] 
Sent: Tuesday, April 17, 2012 9:18 =
AM
To: Barnum, Sean D.; osantos@cisco.com; Thomas.Millar@hq.dhs.gov; =
lnunez@c3isecurity.com
C=
c: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; m-terada@ipa.go.jp
Subject:<=
/b> RE: [mile] [sacm] CybOX v1.0 (Draft) is now released and live onthe =
website
 
Sean,
 
Does the overlap between the various objects present a =
problem?
 
If there are one or more objects that could carry the same data, then =
human nature means that probability-wise someone will choose data flow =
instead of Netflow.
That is the underlying principle in Murphy=E2=80=99s Law, where you =
try to design it so that there is only one way to do it, and thus =
private Murphy won=E2=80=99t do it the =E2=80=9Cwrong=E2=80=9D =
way.
 
Just wondering if these should be mutually exclusive sets.  And =
designed as such.
Might improve interoperability.  (And avoid discussions like =
this in future.)  J
 
Mike
 
 
From:=
 =
mile-bounces@ietf.org [mailto:mile-bounces@ietf.=
org] On Behalf Of Barnum, Sean D.
Sent: Tuesday, =
April 17, 2012 1:10 AM
To: Omar Santos (osantos); Millar, =
Thomas; lnunez@c3isecurity.com
C=
c: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; m-terada@ipa.go.jp
Subject:<=
/b> Re: [mile] [sacm] CybOX v1.0 (Draft) is now released and live onthe =
website
 
=E2=80=9Cupper layer=E2=80=9D? Yes, as in higher =
abstraction.
Just =E2=80=9Cprotocols=E2=80=9D? No.
 
You guys have been looking at this through the lens of network flow =
which if fine for thinking about that perspective but it is important to =
also realize that the EventTypeEnum and its =E2=80=9CData Flow=E2=80=9D =
value go far beyond network-related scope.
It is about a lot of other types of potential data flows (as I just =
outlined in a response to Tom) that have nothing to do with network =
flow.
 
Thanks for your response though. This is the kind of discussions that =
we hope to have a lot more of among the various supported =
communities.
 
 
BTW, you may have noticed that the Network_Flow object within CybOX =
v1.0 (Draft) supports expression of netflow within several of the most =
common formats including Netflow9 (as well as IPFIX as Luis pointed out, =
Netflow5 and SiLK as well as bi-directional flow in YAF). The common =
5-tuple or 7-tuple (you describe) (in our case it is an 8-tuple as we =
broke the router interface out into both ingress and egress J) shared by pretty much all of the netflow approaches has been broken =
out into a shared Network_Flow_Label structure. The various =
context-dependent portions of the independent approaches are then =
captured within optional structures dedicated to each of them. We hope =
that eventually the community can work to come together towards a single =
overall common expressive structure for netflow that meets the needs of =
all. We hope that CybOX and its use can even help that sort of =
maturation and normalization. But since no such universal structure =
exists today, we decided to enable optional expression of the most =
common individual formats within a single netflow object to serve the =
large majority of relevant users, maintain flexibility and enable =
discussions and analysis of netflow within a common =
package.
We look forward to continuing discussions with the community to =
validate or invalidate this approach and to refine and mature going =
forward.
 
Sean 
 
From:=
 =
Omar Santos (osantos) [mailto:osantos@cisco.com]=
 
Sent: Monday, April 16, 2012 11:57 PM
To: Millar, =
Thomas; Barnum, Sean D.; lnunez@c3isecurity.com
C=
c: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; m-terada@ipa.go.jp
Subject:<=
/b> RE: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe =
website
 
I believe that what Sean is saying is that =E2=80=9Cdata =
flow=E2=80=9D is just a value that is meant for upper layer protocols. =
But, you have a good point. Traditionally, a =E2=80=9Cflow=E2=80=9D in =
=E2=80=9CNetflow=E2=80=9D is based on a set of 5 and up to 7 IP packet =
attributes:
 
- IP source address
- IP destination address
- Source port
- Destination port
- Layer 3 protocol type
- Class of Service
- Router or switch interface
 
Although, there is a lot more support with Netflow version =
9:
http://www.=
cisco.com/en/US/technologies/tk648/tk362/technologies_white_paper09186a00=
800a3db9_ps6601_Products_White_Paper.html
 
 
 
Regards,

Omar 
 
From:=
 =
Millar, Thomas [mailto:Thomas.Millar@h=
q.dhs.gov] 
Sent: Monday, April 16, 2012 11:46 =
PM
To: sbarnum@mitre.org; Omar Santos =
(osantos); lnunez@c3isecurity.com
C=
c: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; m-terada@ipa.go.jp
Subject:<=
/b> Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe =
website
 
If "data flow" is a euphemism for "netflow" is =
there any reason not to call it that?

Tom Millar 
http://www.us-cert.gov/ =

------------------ 
Missit me Rubus fruticosus: 
202 631 1915 =


 
From<=
/b>: =
Barnum, Sean D. [mailto:sbarnum@mitre.org]=
 
Sent: Monday, April 16, 2012 11:29 PM
To: Omar =
Santos (osantos) <osantos@cisco.com>; Luis Nunez =
<lnunez@c3isecurity.com> =

Cc: idxwg@nicwg.org =
<idxwg@nicwg.org>; mile@ietf.org <mile@ietf.org>; dallendoug@gmail.com <dallendoug@gmail.com>; sacm@ietf.org <sacm@ietf.org>; m-terada@ipa.go.jp <m-terada@ipa.go.jp> =

Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released =
and live onthe website 
 
Thanks Omar.
 
To answer your question, first let me point out to other readers that =
the two entries that Omar is quoting here exist as values in an =
enumeration called EventTypeEnum which as its name implies contains a =
list of different labels for grouping types (or classes) of events to be =
used as low-granularity buckets for characterizing and classifying =
events.
Other entries in this enumeration include things like =E2=80=9CFile =
Ops (CRUD)=E2=80=9D, =E2=80=9CProcess Mgt=E2=80=9D, =
=E2=80=9CAuthorization (ACL)=E2=80=9D, etc.
 
The =E2=80=9CPacket Traffic=E2=80=9D value is intended to =
characterize events dealing with network packet traffic as its name =
implies.
The =E2=80=9CData Flow=E2=80=9D value is intended to characterize =
events dealing with forms of data flow at a higher level of abstraction =
than just packet traffic. The relationship between these two values =
could be viewed as =E2=80=9CPacket Traffic=E2=80=9D being a more =
detailed form of =E2=80=9CData Flow=E2=80=9D just as the values =
=E2=80=9CApp Layer Traffic=E2=80=9D and =E2=80=9CHTTP Layer =
Traffic=E2=80=9D, also in this enumeration, could be other levels in =
this same abstraction stack.
The idea behind the varying levels of abstraction is to leave =
 buckets large enough to capture a wide variety of potential event =
types (e.g. data flow events other than obvious things like packet =
traffic) but also enable the use of smaller more specific buckets when =
they are appropriate and commonly used.
 
Does this make sense? 
 
sean
 
From:=
 =
Omar Santos (osantos) [mailto:osantos@cisco.com]=
 
Sent: Monday, April 16, 2012 8:17 PM
To: Luis =
Nunez; Barnum, Sean D.
Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; m-terada@ipa.go.jp
Subject:<=
/b> RE: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe =
website
 
I echo Luis=E2=80=99 comments. It is good to see the inclusion of =
network objects. Quick question to the team related to your netflow =
comment.
 
I am looking at:
=
http://cybox.mitre.org/XMLSchema/cybox_core_v1.0%28draft%29.xsd<=
/o:p>
 
=E2=80=A6 and it looks that we renamed it to =E2=80=9CData =
Flow=E2=80=9D?
 
<xs:enumeration =
value=3D"Data Flow">
   =
<xs:annotation>
        =
<xs:documentation>Specifies the class of events dealing with data =
flow.</xs:documentation>
   =
</xs:annotation>
</xs:enumeration>
 
 
What is the difference between that and =E2=80=9CPacket =
Traffic=E2=80=9D?
 
<xs:enumeration value=3D"Packet =
Traffic">
   =
<xs:annotation>
     =
<xs:documentation>Specifies the class of events dealing with =
packet traffic.</xs:documentation>
   =
</xs:annotation>
</xs:enumeration>
 
 
 
 
Regards,

Omar Santos
Incident Manager, =
PSIRT
Security Research and Operations
Cisco Systems, =
Inc.
Email: os@cisco.com
Phone: +1 919 392 =
8635
PGP Key: 0x3AF27EDC

Cisco.com - http://www.cisco.com
Cisco Security =
Advisories and Notices - http://www.cisco.com/go/psirt<=
br>
This email may contain confidential and privileged material for =
the sole
use of the intended recipient. Any review, use, distribution =
or
disclosure by others is strictly prohibited. If you are not the =
intended
recipient (or authorized to receive for the recipient), =
please contact
the sender by reply email and delete all copies of =
this message.

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html=

 
From:=
 =
sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.=
org] On Behalf Of Luis Nunez
Sent: Monday, April =
16, 2012 6:44 PM
To: Barnum, Sean D.
Cc: idxwg@nicwg.org; mile@ietf.org; Doug Wilson (dallendoug@gmail.com); sacm@ietf.org; IPA-Masato Terada (m-terada@ipa.go.jp)
Subject:=
 Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe =
website
 
I like the inclusion of the network-centric =
objects.  IPFIX (netflow)  will add an additional perspective =
from an incident information sharing standpoint. =
 
 
-ln
 
On Apr 16, 2012, at 4:04 =
PM, Barnum, Sean D. wrote:
 
Hey =
everyone,
 =

I just =
wanted to let you all know that CybOX v1.0 (Draft) content is now live =
on the website. http://cybox.mitre.org
The =
release notes are provided inline =
below.
The key =
items of note are:
=C2=B7        The =
release of two formal specifications for the CybOX language (one for the =
core language and one for the defined =
objects)
=C2=B7        The XML =
Schema has gone through extensive improvements for expressiveness, =
clarity, consistency, efficiency, alignment to existing normative =
references and documentation.
=C2=B7        This =
release includes an initial set of language utilities: a draft Snort =
-> CybOX transform, a draft OpenIOC -> CybOX transform, and a set =
of Python bindings for the CybOX language.
=C2=B7        The =
website now includes a small set of content examples. This set will grow =
going forward.
This =
release involved a lot of hard work from a diverse group of people. =
Thank you all for your contributions and effort. We could not have done =
it without you.
We look =
forward to everyone=E2=80=99s feedback and collaboration as we continue =
to improve and mature the CybOX =
language.
 =

Sean =
Barnum
 =

 =

 =

CybOX v1.0 (Draft) Release =
Notes
The Version 1.0 (Draft) release of Cyber =
Observable eXpression (CybOX=E2=84=A2) is intended as a draft release of an initial major version of =
the CybOX Language that could be utilized for practical operational use =
and integration into other standards efforts. This release consists of =
three primary components: a pair of formal language specifications for =
the core language content and defined objects content, a set of language =
implementation XML schemas (core, common_types, and ~70 defined object =
schemas), and a small initial set of language utilities including an =
initial draft Snort->CybOX transform, an initial draft =
OpenIOC->CybOX transform and a set of CybOX language Python bindings. =
Recognizing that this is the first time that the formal language =
specifications will be available for review and as such will likely =
generate feedback from new stakeholders, this initial major version is =
being released as a =E2=80=9Cdraft=E2=80=9D v1.0 with the expectation of =
cycles of new feedback and revision before a =E2=80=9Cfinal=E2=80=9D =
v1.0 is released.=

The CybOX v1.0 (Draft) XML schemas include a =
significant number of changes from v0.7 to improve:=

=C2=B7       Clarity, =
documentation, and descriptive formality for reference and =
implementation by other standards and users.=

=C2=B7       Consistency, =
simplicity, and efficiency.=

=C2=B7       Alignment (as =
appropriate) to existing normative references.=

=C2=B7       Expressiveness of the =
schema to better support the broad set of use cases it targets (malware =
characterization, indicator and incident data sharing, event management, =
etc.) including the addition of an initial set of network-related =
defined objects.=

Summary =
of changes from CybOX_v0.7 to CybOX_v1.0_(Draft):=

=C2=B7        =
Refinement of namespaces and schema =
locations for better effectiveness and flexibility going forward.=

=C2=B7        =
Normalized all content according to an =
established set of naming conventions.=

=C2=B7        =
Fully annotated all language items =
(types, attributes, elements, etc.).=

=C2=B7        =
Moved several commonly leveraged types =
out of the core schema and into common_types.=

=C2=B7        =
Achieved full typing of entire schema =
structure such that all attributes and elements are definitively =
typed.=

=C2=B7        =
Changed all identifiers from ID and IDREF =
types to be QNames enabling globally unique identifiers and flexibility =
for domain-specific users of CybOX to define their own identifier syntax =
locally.=

=C2=B7        =
Reordered attributes and elements in =
numerous types to better reflect common usage and priority.=

=C2=B7        =
Added major_version and minor_version =
attributes for core schema.=

=C2=B7        =
Added capability to characterize source =
of overall observable package data and for individual observables.=

=C2=B7        =
Modified the logical composition =
structure such that any such compositions are now contained within a =
Observable_Composition element providing improved simplicity and =
modularity.=

=C2=B7        =
Removed the Delta element from =
ObservableType and relocated the appropriate portions (Change, Trend, =
and Frequency) to appropriate locations under Stateful_Measure and =
Event.=

=C2=B7        =
Added a Domain_Specific_Object_Attributes =
field to Object utilizing an abstract type that will allow =
domain-specific use cases to add in their own domain-specific attributes =
for Objects.=

=C2=B7        =
Added a Tool-Specific_Data field to =
ToolInformationType utilizing an abstract type that will allow addition =
of tool-specific data.=

=C2=B7        =
Added an Indicators field to =
MeasureSourceType utilizing an abstract type that will allow =
characterizing differing formats or standards of indicators that may =
have led to the identification of the observable data.=

=C2=B7        =
Enhanced the Hash structure to capture =
full fuzzy hashes in addition to simple hashes=

=C2=B7        =
Added a new ExtractedFeaturesType that =
can be used to adorn differing objects (e.g., files, memory, etc.) to =
capture extracted strings, imports, functions and code snippets=

=C2=B7        =
Added a ByteRunsType to enable capture of =
byte runs within various objects.=

=C2=B7        =
Added object_reference attribute to =
DefinedObjectType to better support referencing of independently defined =
Objects from within another Object definition.=

=C2=B7        =
Added a generic DataSegmentType to =
provide a relatively abstract way of characterizing data segments that =
may be written/read/transmitted or otherwise utilized in actions or =
defined in objects.=

=C2=B7        Added several new =
defined object schemas (API, Code, Device, DNS_Record, Network_Flow, =
Network_Packet, Network_Route_Entry, Network_Subnet, =
Unix_Network_Route_Entry) including an initial set of network-centric =
defined objects.
=C2=B7        =
Modified every defined object schema with =
added annotations as well as minor and in some cases substantive changes =
to fix errors, improve consistency and alignment with existing normative =
references, and to improve expressiveness in support of the targeted use =
cases.=

Detailed changes from CybOX_v0.7 to =
CybOX_v1.0_(Draft):=

The level of changes within v1.0 (Draft) in =
the core schema, common_types and the defined object schemas is too =
great to list every change in these release notes. Detailed difference =
reports are available for each individual schema at:http://cybox.mitre.org/XMLSchema/release_notes/cybox_v1.0=
(draft)_diff_reports.zip
 =

 =

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

Sean Barnum=

Cyber Security Principal=

The MITRE Corporation=

 =

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

------=_NextPart_001_00B6_01CD1CB9.BDEF3370--

------=_NextPart_000_00B5_01CD1CB9.BDEF3370
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYNDCCBS0w
ggMVoAMCAQICEEw6UhQhT9OgRBVHf7KQ+1AwDQYJKoZIhvcNAQELBQAwKTEnMCUGA1UEAxMeTUlU
UkUgQ29ycG9yYXRpb24gUEUgUm9vdCBDQS0xMB4XDTExMDQyNjE5NDU0NVoXDTIxMDQyNjE5NDgy
MlowKTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUEUgUm9vdCBDQS0xMIICIjANBgkqhkiG
9w0BAQEFAAOCAg8AMIICCgKCAgEAtp8hR0hRq3im+Alwfb5ZHGP5k2OSY2TlVHYHIMUDH3MfW7b6
8lB3j3MwAMsxGK1ke/t6O4K0t9wRH4QDgOQ1CthmOGZW7xiN81h0vP1Yf14SNugUa7ZvH9KP3iXs
y8QnOHal1bKf0Pa9KXib58qUuwfaZSCTW5P2ekqd8z4TETvfBWvPgDxyxnVsiAO6yL9WaRpMiSVM
hYLWy3KRuU/gue0bVEi+qdg+hENh1NSNXpoqseS262nq5cx5wybR/PF0YstQ9NNlYDM5cLECKYHH
zD6cXKJozuFXriswlE8rdna7VaxyZrfgC0ueEIY/tsj/65IyUhyPBwO0ZpW+Ls9Cd4Y+ERSu5mR5
Fd8w42eVzuosmk3s3AxrKC+Z4tXYkjaiWUduIegAiST1vJBwkS53vR+zrBX3Ep56l7MFVvW/GcsZ
9wUT2HG65JOeiVc2YzCEqLgQ3ZCBHn09oBag2lnMac+E2sKm9aKL3xzHs6cyD8qCJK9O8QLCqo3C
mzASlOwtTFiLYgpPW/MSmgYOt9JrwHAzk97DHFKTFttjrXGMmhMVzadt1EjMn1Wv8t5WLBI0qSoX
/MYi2CaeiDsEiWRu9Nmpu3pmi8m7tIR9csdbAVPks2soNMWOopGEpFQSDvU1+m77v2jIKQKYxYmN
2zUOJ4TJFL1osnZ/71MmLCDVd+ECAwEAAaNRME8wCwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMB
Af8wHQYDVR0OBBYEFFuHfZ/+bL4C6fPgKTqKVCUsnzgvMBAGCSsGAQQBgjcVAQQDAgEAMA0GCSqG
SIb3DQEBCwUAA4ICAQAy78sXsP/eqHH8/uOYyxQ6TBDhkCBxNoy8MF2c9UDns5ADL1qyxPAlpDBs
L+2h1Zzt3FvPjg0SoRE/9juyG1qxMzhlv0jdQx12tESdo3uBb61b1uuc4H/VxCJWDI4KZL/B53EI
8HGPjUBdLADgOmG99uffm5uarSkjtIX//Bz3U6QfzTPlVWFi4SmzRI2mp16GQ8RPuJ/WMloaAn8X
H6EjS2oLjGZC8Pw8/C46W48NvZ1JZTrZvYZr7GmuvmplYK68SZv/T5Su+FlLRTy9uNXQLHtm6jKv
nDH2yB66zTwfaDpnjILnrC2O7ANRVZc0KywiKiW3nB7Joq74/XVuMI1PiSByt2Qu+RIS/WAI5wMi
bTmwSiBxQZqvuth+dXoakJyOP2Wg5jvL55v9RLZhDqMtRI5ovnOFvTgNJQqNPSekGtA+m6Ctl/vh
kSg65FFCMhaSkn7vY2Il+R8HouWJN8wTaudeexnyHcD+Mlt8QaB5CErpDjeeGZfQ0FcYm+6TtlMz
Dw5eFhT/J6QrABCxfgLkVFHurMcQD4JkmXXkq5bP+GNkY0Uy2LMbw/UD94OEV1LpfAqUkT+mu5Yb
vxg+elFtsad+Ix8owW372xynIADh9q1bHm+j1OHPJmGALWK9miRpC4t3isfu3ZB0QpI/e2Po6MED
393Jb0YbzrcElFv6ZDCCBhYwggP+oAMCAQICChrDbcgAAgAAN/wwDQYJKoZIhvcNAQEFBQAwUDET
MBEGCgmSJomT8ixkARkWA09SRzEVMBMGCgmSJomT8ixkARkWBU1JVFJFMSIwIAYDVQQDExlNSVRS
RSBDb3Jwb3JhdGlvbiBQRSBDQS0xMB4XDTEyMDMxMjE1MTgyN1oXDTE1MDMxMjE1MTgyN1owSjEL
MAkGA1UEBhMCVVMxDjAMBgNVBAoTBU1JVFJFMQ8wDQYDVQQLEwZQZW9wbGUxGjAYBgNVBAMTEUJh
cm51bS5TZWFuLjMxNTQzMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA9/I6RU7OcouL
6lcEJMAg8G3myNbQu84QnflS8p3PWOjgC6P50RDqGX5UxelDqMQPN5IsNYRXVY9/b7yN/RSH4goI
JfYKMitndKuCKz1q38Nh0YycEm5x2t/IN/60b01T1uOmhZfptLDoDzj0UQZwMQ19mhM/ldsrC8bR
GGuHXdQVaSyXygfhzNhqC06vZo5fvCBUJ6z7JtVrfRTHdudg19JYK+gds9p+Lvp/DOEXQmgpfpMl
jfNKMnrG+kPMMngrIJUsF5lcbhHuc5mO+O8eR8FxM2KF7gfKVmUmZxs7Y6uLenVJVEmllP0XgUu1
sv3bClFgUo5x5Aq6rXshtHuVuQIDAQABo4IB9jCCAfIwKAYDVR0lBCEwHwYIKwYBBQUHAwQGCSsG
AQQBcwIBBwYIKwYBBQUHAwIwHQYDVR0OBBYEFDvU1Ph/OVxGkxRmwvRx1TBf5PKqMA4GA1UdDwEB
/wQEAwIGwDAcBgNVHREEFTATgRFzYmFybnVtQG1pdHJlLm9yZzAfBgNVHSMEGDAWgBRpZyAh1EjB
0BsGbvMIKOI6gn1BMTBJBgNVHR8EQjBAMD6gPKA6hjhodHRwOi8vcGtpLm1pdHJlLm9yZy9NSVRS
RSUyMENvcnBvcmF0aW9uJTIwUEUlMjBDQS0xLmNybDB/BggrBgEFBQcBAQRzMHEwRwYIKwYBBQUH
MAKGO2h0dHA6Ly9wa2kubWl0cmUub3JnL01JVFJFJTIwQ29ycG9yYXRpb24lMjBQRSUyMENBLTEo
MikuY3J0MCYGCCsGAQUFBzABhhpodHRwOi8vb2NzcC5taXRyZS5vcmcvb2NzcDA+BgkrBgEEAYI3
FQcEMTAvBicrBgEEAYI3FQiDrqwjho6WV4GNiT2CpKsShb6uAYE2g9KXfYeg+0kCAWQCAQcwFgYD
VR0gBA8wDTALBgkrBgEEAXMCAQgwNAYJKwYBBAGCNxUKBCcwJTAKBggrBgEFBQcDBDALBgkrBgEE
AXMCAQcwCgYIKwYBBQUHAwIwDQYJKoZIhvcNAQEFBQADggIBAC2wqKo7QWQxIqnEKRznPrAQ5vQ9
X5JhB5keH8KMWu1W5n1RuSZH+3TYp4xccdYh+rV5b5+cJcWEYhtYpZriWm4kMHPaB6gKO9rbVfF9
R8Wp8sXvCKogbNhdkZwvXW4QymB1ASlMzDI1cCV8mzYgbIhWaCbV1zZBUVgOGa4LZIgdbdmgo5r/
O2gmnSftTYiE/tQ+DBs/25Bw/jC5HOiMXJqr+JctzJTqpEVLa7GKHnXWGuzGEPYkKBplxIyhz3Mv
qc/yuKM7tZzAr8Qn5qf7VI9O2xp56QLjT2+mySOUR6Vml860FMpjjgZNMxAqOJt7OgY0PoUU9d18
yw1wiKSt0LUQoMcVvp7FifBjtBCG1sB/VOzxNvcNm6lO6EO23pvcjt6+WCG1X3pgnZ5UEohsM3c0
oLzYiuSYeVf85IO2yh9fWLWw2RGkf2szck1Xg0DsAQ54/YlZYyehELh43KbS3lpnTt8UlO7C0TMT
7JQwz4fTQg1a0e9rRPFnNDUG2fS2k3tz9IYILDB3F8uiZzzXptEzaYqzIqe5CK8ZGJQcw+w/CBen
6i+MV/y7yJmhio43Y1x9hIqoynqoSMV3CKYCoOwCvFUAGsNllDpExsQZoXrdd5gcuglqbh3t8wOM
jtXDSQllQ/hXDZJf8rnH0wGx3K+WA+LKNvKqNCw9spEtsfG0MIIGYjCCBEqgAwIBAgIKFJcW0gAA
AAAABDANBgkqhkiG9w0BAQsFADApMScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQRSBSb290
IENBLTEwHhcNMTEwNjE0MTc0NDQ0WhcNMTcwNjE0MTc1NDQ0WjBQMRMwEQYKCZImiZPyLGQBGRYD
T1JHMRUwEwYKCZImiZPyLGQBGRYFTUlUUkUxIjAgBgNVBAMTGU1JVFJFIENvcnBvcmF0aW9uIFBF
IENBLTEwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDSxK9RXieqdTz4JWRkRMs/EOuF
0P0S9SbspadLJkx/LDDnaAwmAnqfqm1n7/p82oVjy1yCye3SZu4Yp7fmDIAtWbkHvYOfxHkRv1ho
/fhaNN0YRkd65oJJz2ngEbNZxdIiCoialQfX/iWU7ApQ+ovKbFV60v5E0p2mPncs20NYRfsaetdh
nBZbFD9flDcXwJqSvGGGBfm7ifFCR1LrtEcNKjMwf7YEWZO0Vk3ZyhVq+k7JNLEbKv0OfBz8DU8G
iGU+j88QlrgGW8PLkwNk7nsS/DJp8aLudTuVqIE2CA9mqn5QjU/EZYNHGzSfCr+/usUmbojyVSJu
khhrAXspRAMz+Cia3yi3q3w8TnAljXWN1dhx1iuUv5GxyzMjfqK1tMuCUU2XzGNNqoVa1mqolBiy
DTCOr9d/IC0YHYMBSpQ+xi0x9zjXKt4FmQmkEAZgF4hsZZqcJYL/iCQiwiz8fEyVPZuvoWvdEXOo
zFYCpmkT0MZCJwyIux0Z6vJp6VLtN/6rZgc2y54HlTrp3ifazmpsfrk3NdHxlZTZug9kjEI+vEoy
p/79nAPyTWQQ1MEP0ErCWav80/HOi0MLx/7lIUfvVOjkOFgFb+iDvR4T3RAQrnEpgTO+fc7Jyzh9
LpFDqm0slwDP4Hj9cC3IzdED5BU43PGAe+HoZ8OD/1ovVgwo/wIDAQABo4IBYzCCAV8wEAYJKwYB
BAGCNxUBBAMCAQIwIwYJKwYBBAGCNxUCBBYEFFCiOtgZb+Zdflkw5sC2y01sUQaVMB0GA1UdDgQW
BBRpZyAh1EjB0BsGbvMIKOI6gn1BMTAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTALBgNVHQ8E
BAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAfBgNVHSMEGDAWgBRbh32f/my+Aunz4Ck6ilQlLJ84LzBQ
BgNVHR8ESTBHMEWgQ6BBhj9odHRwOi8vcGtpLm1pdHJlLm9yZy9NSVRSRSUyMENvcnBvcmF0aW9u
JTIwUEUlMjBSb290JTIwQ0EtMS5jcmwwWwYIKwYBBQUHAQEETzBNMEsGCCsGAQUFBzAChj9odHRw
Oi8vcGtpLm1pdHJlLm9yZy9NSVRSRSUyMENvcnBvcmF0aW9uJTIwUEUlMjBSb290JTIwQ0EtMS5j
cnQwDQYJKoZIhvcNAQELBQADggIBAHnDPfdYKxqNOtAYXMyyel83Vs8cCDAQZhSuIB0c6GkGoEdF
rmWH9pwi42V96rCp7TvbNNKNJXbVHfJUAp+uqw663DL/sXXff9ZFxPxKOdPnpA8cKM7RBH9e437N
w3d28A7PaGbP6tXmSqhXAhYZ4U12y1U5cOf2G/phUoAAMlnVJdfmXzMazvLo2SIeixAJyCze6rHQ
TFQ/N+gAjbVuRJ+Hs8FEKVzMSwqlNoupe2ELqL4dMAKT6P08sAfxm2SrRlQvcWPYvqM/1C10bgc2
tdu+WGzRuP5Wx9Yr15KO9SW4z7fn2RVEXQgoDDno5vCIcfUPuKB5n+Kt9eBCitsgSD9yYsNUN9LE
VIvjAb8MV2LWLfge1bumo6g7QMRa4Fgifw5siGwi7V2EaJQo6UAIVvxKKFC7W4p6CkrY2ga1d7GI
Q0DPiWZOezOakJVAxL5gf+3WdNt0igKc/yLfbdHn6hCd1KPgDqkSKr8zWOZI/jiDBW957xAmaO6Q
dGQDBZrQHWpIVwQGzF5bGrqms2kq49l3t7KmBu0C/9tExqKAmlf4Y5lfQGdCbKQpAq712DVQHYuD
XmVQEAc2vlJ1C5hS3Iw9DwBWTfJ4vyB48buhBhbIhPiFta5OizXlKcsIi99ikA1yiZx/DBtjaw4J
U6qJzWUFB2ecyGCNPtNbYjURA0A9MIIGfzCCBGegAwIBAgIKGsNq2wACAAA3+jANBgkqhkiG9w0B
AQUFADBQMRMwEQYKCZImiZPyLGQBGRYDT1JHMRUwEwYKCZImiZPyLGQBGRYFTUlUUkUxIjAgBgNV
BAMTGU1JVFJFIENvcnBvcmF0aW9uIFBFIENBLTEwHhcNMTIwMzEyMTUxODI3WhcNMTUwMzEyMTUx
ODI3WjBKMQswCQYDVQQGEwJVUzEOMAwGA1UEChMFTUlUUkUxDzANBgNVBAsTBlBlb3BsZTEaMBgG
A1UEAxMRQmFybnVtLlNlYW4uMzE1NDMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCW
InZvCSslmSfSyhTVVSqnokCDajlsCNZHfUlkwkV1++2O71BYvMpjFHWR2XFIx963Hl63lFZzzVci
OjIwLb1c/0YXhFfUdAvrbpjlu+ttlO05OEUW0h+5HO+qaebJPamxA00w0bokquRcPxUvwa3jiyL0
WfCwE3+/b5PCOW2xh7FXFKv262FnKIwxnQGXqkiXRP5D/SmdtcZSzxHkDThrhaiHPhJJhZ4XxwBk
aGcAlMg8YH6uxshXm8e6c7XUu7gB5p+XThS0dqXujpQp/UQDp5t079+UrDcrpjfDBXIt9qCzLn26
uV5a4cD4xRKwA32f1cXFtiKXM0wYgUM3fEPDAgMBAAGjggJfMIICWzATBgNVHSUEDDAKBggrBgEF
BQcDBDCBlAYJKoZIhvcNAQkPBIGGMIGDMA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DBAICAIAw
BwYFKw4DAgcwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBLTALBglghkgBZQME
ARYwCwYJYIZIAWUDBAEZMAsGCWCGSAFlAwQBAjALBglghkgBZQMEAQUwHQYDVR0OBBYEFIrbKa+E
Rxo2/Sth2C6jZqZqvRE7MA4GA1UdDwEB/wQEAwIFIDAcBgNVHREEFTATgRFzYmFybnVtQG1pdHJl
Lm9yZzAfBgNVHSMEGDAWgBRpZyAh1EjB0BsGbvMIKOI6gn1BMTBJBgNVHR8EQjBAMD6gPKA6hjho
dHRwOi8vcGtpLm1pdHJlLm9yZy9NSVRSRSUyMENvcnBvcmF0aW9uJTIwUEUlMjBDQS0xLmNybDB/
BggrBgEFBQcBAQRzMHEwRwYIKwYBBQUHMAKGO2h0dHA6Ly9wa2kubWl0cmUub3JnL01JVFJFJTIw
Q29ycG9yYXRpb24lMjBQRSUyMENBLTEoMikuY3J0MCYGCCsGAQUFBzABhhpodHRwOi8vb2NzcC5t
aXRyZS5vcmcvb2NzcDA+BgkrBgEEAYI3FQcEMTAvBicrBgEEAYI3FQiDrqwjho6WV4GNiT2CpKsS
hb6uAYE2hquSaISo7EUCAWQCAQ8wFgYDVR0gBA8wDTALBgkrBgEEAXMCAQgwGwYJKwYBBAGCNxUK
BA4wDDAKBggrBgEFBQcDBDANBgkqhkiG9w0BAQUFAAOCAgEAGmmL43yA+J5lEockM1cxSoyxfSES
HUGLVJyrhObbdFD4yO3jf0R4lHLuJlhp1486d9LRZAyzAnl9q8Zf3Tx1rl1kEd3pw0wMuO+ATscc
rArEW/rJxjz6zTrNO3PFkFuOEdmKpHaRiFpuSX602INiBEBPluei3uZlWxHW9VqC7hz2diQpOlzS
jtPMbL3o7ACjWaq7sQ0xB4rZ6oWyqOZEfHWQA1b7nFgL4nEbmEHNdU4jAjcxkROku4O04205kb5n
Loveoz3TSQNt8zalFayZAjt+JEcKuG1f5cyhYI6QwvkS/3M+CjJezuNaSmno29Lm+ToZnwUm4nIB
YkBx4r9ZDU2W8029tr5og00A5MGo1LK+unWtHBa7zuPblfSiYgXIHWU+OKrSFaA935Yb4fLXFe9S
BmApBr1gohHYos1hct5q90WPufSKIQ9WT+vJYXvW3FpseO4ZLKVnJsO7gVoQEEnWJUwyABBPQrii
F0gh++ApKZJROTuR36PsEEx4duI6U4VXMCiIcnEjvNR8Mt5Q/Vp4W4Mp5fCv+QzYkqq9EWD7QuUW
Yul6R8Hf7ZTxbUk0NfJgu8escLrgQSwMdP/kE/09vJAAslQBkNnIS7iIhWt4l5XQJBrJc+6popRE
R8ykWf25e4CliaUgbAl1tBQKivQ3tlX99WykI2XK3sTk9nsxggMjMIIDHwIBATBeMFAxEzARBgoJ
kiaJk/IsZAEZFgNPUkcxFTATBgoJkiaJk/IsZAEZFgVNSVRSRTEiMCAGA1UEAxMZTUlUUkUgQ29y
cG9yYXRpb24gUEUgQ0EtMQIKGsNtyAACAAA3/DAJBgUrDgMCGgUAoIIBmjAYBgkqhkiG9w0BCQMx
CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjA0MTcyMDQ3MTRaMCMGCSqGSIb3DQEJBDEW
BBTizelClN67bW00c6VOdlzZSytMWjBbBgkqhkiG9w0BCQ8xTjBMMAoGCCqGSIb3DQMHMA4GCCqG
SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMC
GjBtBgkrBgEEAYI3EAQxYDBeMFAxEzARBgoJkiaJk/IsZAEZFgNPUkcxFTATBgoJkiaJk/IsZAEZ
FgVNSVRSRTEiMCAGA1UEAxMZTUlUUkUgQ29ycG9yYXRpb24gUEUgQ0EtMQIKGsNq2wACAAA3+jBv
BgsqhkiG9w0BCRACCzFgoF4wUDETMBEGCgmSJomT8ixkARkWA09SRzEVMBMGCgmSJomT8ixkARkW
BU1JVFJFMSIwIAYDVQQDExlNSVRSRSBDb3Jwb3JhdGlvbiBQRSBDQS0xAgoaw2rbAAIAADf6MA0G
CSqGSIb3DQEBAQUABIIBAKFZgGrEcoG7ZPIGeD7eXPE2p+Mjy3jlRzl5p5ejz/AkR26jwn/+HZHN
uIaV8kU3c878UZP9AznBIUh7sdV8K/+kmB2KZxE41WBrjHpx8lZcbZOLJI0q6EX9NQpSbSrtFmV/
R7gsmiPbwIEnW9LaJyXF3PC1TgpSSmxhnP9drGtQE2ZiTRgA+6bYHoy9uXiagXrR5HMjBtVcDDzP
F1CPQyyFeC7mAkuIRRwmC1lugEFaVSxKd3fwGN8gFagl2KhiY8SlvVQV+qEE6xsT9uEM5A9WEgfS
KvfgRVWE8wuW1vX6qZnBFtP1GGpEz8nhQ9FXgE3iZk7nkGETT9XY9QCOL9MAAAAAAAA=

------=_NextPart_000_00B5_01CD1CB9.BDEF3370--

From michael.hammer@yaanatech.com  Tue Apr 17 13:51:38 2012
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 4030B11E80A0; Tue, 17 Apr 2012 13:51:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.656
X-Spam-Level: 
X-Spam-Status: No, score=-2.656 tagged_above=-999 required=5 tests=[AWL=-0.058, 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 UkPBnpFmKofq; Tue, 17 Apr 2012 13:51:30 -0700 (PDT)
Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 51DF411E80BD; Tue, 17 Apr 2012 13:51:23 -0700 (PDT)
Received: from EX2K10MB1.corp.yaanatech.com ([fe80::5568:c31d:f64a:f66a]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Tue, 17 Apr 2012 13:51:23 -0700
From: Michael Hammer 
To: "Barnum, Sean D." , "osantos@cisco.com" , "Thomas.Millar@hq.dhs.gov" ,  "lnunez@c3isecurity.com" 
Thread-Topic: [mile] [sacm] CybOX v1.0 (Draft) is now released and live onthe website
Thread-Index: AQHNHFhQtpFrr+nGFkWqCWY68NIgupae/ygAgADWyAD//48qoIAAjiKA//+LrmA=
Date: Tue, 17 Apr 2012 20:51:22 +0000
Message-ID: <00C069FD01E0324C9FFCADF539701DB38A0218@EX2K10MB1.corp.yaanatech.com>
References: <7F48813B48558A4BB5CB7BB714E5B5A9171B16@IMCMBX03.MITRE.ORG> <69CE2DCD9DAC3D48B830E0723141170B02A39BD2@ZAU1UG-0308.DHSNET.DS1.DHS> <953A2E460DBE7C43AC13E30B87C5B4FF080A1C09@XMB-RCD-106.cisco.com> <7F48813B48558A4BB5CB7BB714E5B5A9171BA1@IMCMBX03.MITRE.ORG> <00C069FD01E0324C9FFCADF539701DB389FC37@EX2K10MB1.corp.yaanatech.com> <7F48813B48558A4BB5CB7BB714E5B5A9173046@IMCMBX03.MITRE.ORG> <00C069FD01E0324C9FFCADF539701DB38A0193@EX2K10MB1.corp.yaanatech.com> <7F48813B48558A4BB5CB7BB714E5B5A9173115@IMCMBX03.MITRE.ORG>
In-Reply-To: <7F48813B48558A4BB5CB7BB714E5B5A9173115@IMCMBX03.MITRE.ORG>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.17.88.19]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0177_01CD1CBA.4FE9CE70"
MIME-Version: 1.0
Cc: "idxwg@nicwg.org" , "mile@ietf.org" , "dallendoug@gmail.com" , "sacm@ietf.org" , "m-terada@ipa.go.jp" 
Subject: Re: [mile] [sacm] CybOX v1.0 (Draft) is now released and live onthe website
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, 17 Apr 2012 20:51:38 -0000

------=_NextPart_000_0177_01CD1CBA.4FE9CE70
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0178_01CD1CBA.4FE9CE70"


------=_NextPart_001_0178_01CD1CBA.4FE9CE70
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Thanks.  Appreciated the detailed explanation.

=20

Mike

=20

=20

From: Barnum, Sean D. [mailto:sbarnum@mitre.org]=20
Sent: Tuesday, April 17, 2012 4:47 PM
To: Michael Hammer; osantos@cisco.com; Thomas.Millar@hq.dhs.gov; =
lnunez@c3isecurity.com
Cc: idxwg@nicwg.org; mile@ietf.org; sacm@ietf.org; m-terada@ipa.go.jp; =
dallendoug@gmail.com
Subject: RE: [mile] [sacm] CybOX v1.0 (Draft) is now released and live =
onthe website

=20

Mike,

=20

If you always utilized the most abstract label (Data Flow) to adorn =
events even when you knew the more specific type that they were and had =
a more specific label for them, then yes you would lose distinction.

Such misuse is always the potential downside of enabling flexibility =
through abstraction.

If you know that the event you are characterizing has to do with Packet =
Traffic and not just some form of more general data flow that does not =
have an appropriate associated event type label, then you should =
absolutely use Packet Traffic and not Data Flow. An event should only be =
tagged with an abstract label like Data Flow if there is not an =
appropriate more concrete label available.

=20

In answer to your second question, yes Data Flow definitely covers not =
only network-related events but also events that have nothing to do with =
the wire.

My response to Tom Millar that I sent at 12:52am this morning lists out =
several non-network related types of events that Data Flow could apply =
to.

=20

Please do not feel bad for asking these questions. They help you =
understand our approach, they help others understand our approach, they =
help us better understand the perspective of the communities we are =
targeting to support, they help us uncover issues with our approach or =
implementation, and they help us understand where we need to explain =
ourselves better.

=20

Thank you for the constructive discourse.

=20

sean

=20

From: Michael Hammer [mailto:michael.hammer@yaanatech.com]=20
Sent: Tuesday, April 17, 2012 3:28 PM
To: Barnum, Sean D.; osantos@cisco.com; Thomas.Millar@hq.dhs.gov; =
lnunez@c3isecurity.com
Cc: idxwg@nicwg.org; mile@ietf.org; sacm@ietf.org; m-terada@ipa.go.jp; =
dallendoug@gmail.com
Subject: RE: [mile] [sacm] CybOX v1.0 (Draft) is now released and live =
onthe website

=20

Sean,

=20

What you say makes sense.  But, if you will bear with me.  (Still =
learning this.)

=20

If one used Packet Traffic event type always instead of Data Flow event =
type, would some distinction be lost?

Or, put another way, since the packet stuff seems to cover most =
network-based events, does Data Flow involve something that is not on =
the wire?

(Such as an inter-process communication that doesn=E2=80=99t go through =
a protocol stack.)

=20

Mike

=20

=20

From: Barnum, Sean D. [mailto:sbarnum@mitre.org]=20
Sent: Tuesday, April 17, 2012 3:03 PM
To: Michael Hammer; osantos@cisco.com; Thomas.Millar@hq.dhs.gov; =
lnunez@c3isecurity.com
Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; =
m-terada@ipa.go.jp
Subject: RE: [mile] [sacm] CybOX v1.0 (Draft) is now released and live =
onthe website

=20

Mike,

=20

Just to clarify, all of our discussion so far about =E2=80=9CData =
Flow=E2=80=9D and netflow were all in regards to an enumeration called =
EventTypeEnum that simply lets you tag a cyber observable event with a =
type label. It is metadata for an event description.

The only object we have been talking about in any detail so far was the =
Network_Flow object. These two topics are totally independent of each =
other. There is no Data_Flow object.

The abstraction overlap we have been discussing is only in the metadata =
tag applied to an event to characterize what type/class of event it is.

=20

The defined objects themselves (including Network_Flow) have been =
designed to avoid, as much as possible, overlap of the type you =
describe.

The approach we have taken is that where there is common structure and =
meaning relevant to multiple different types of objects, the structure =
for that commonality is broken out into its own object (e.g. Address, =
URI, Port, Account, Process, etc.).

Content based on this common object structure can be embedded within a =
leveraging object (via direct use of the object type) if the content is =
directly relevant only within the context of that object or as an =
independent object and associated to any number of other objects to =
which it is relevant utilizing relationships.

We make no guarantees that we have managed to implement this approach =
flawlessly but we believe that it yields a good balance of consistency, =
efficiency and flexibility. It also allows easy modular use of only what =
is relevant within a given context and enables extension and evolution =
to easily occur in a localized fashion rather than having to extend and =
modify one monolithic structure standard.

=20

Does that make sense?

=20

sean

=20

From: Michael Hammer [mailto:michael.hammer@yaanatech.com]=20
Sent: Tuesday, April 17, 2012 9:18 AM
To: Barnum, Sean D.; osantos@cisco.com; Thomas.Millar@hq.dhs.gov; =
lnunez@c3isecurity.com
Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; =
m-terada@ipa.go.jp
Subject: RE: [mile] [sacm] CybOX v1.0 (Draft) is now released and live =
onthe website

=20

Sean,

=20

Does the overlap between the various objects present a problem?

=20

If there are one or more objects that could carry the same data, then =
human nature means that probability-wise someone will choose data flow =
instead of Netflow.

That is the underlying principle in Murphy=E2=80=99s Law, where you try =
to design it so that there is only one way to do it, and thus private =
Murphy won=E2=80=99t do it the =E2=80=9Cwrong=E2=80=9D way.

=20

Just wondering if these should be mutually exclusive sets.  And designed =
as such.

Might improve interoperability.  (And avoid discussions like this in =
future.)  J

=20

Mike

=20

=20

From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of =
Barnum, Sean D.
Sent: Tuesday, April 17, 2012 1:10 AM
To: Omar Santos (osantos); Millar, Thomas; lnunez@c3isecurity.com
Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; =
m-terada@ipa.go.jp
Subject: Re: [mile] [sacm] CybOX v1.0 (Draft) is now released and live =
onthe website

=20

=E2=80=9Cupper layer=E2=80=9D? Yes, as in higher abstraction.

Just =E2=80=9Cprotocols=E2=80=9D? No.

=20

You guys have been looking at this through the lens of network flow =
which if fine for thinking about that perspective but it is important to =
also realize that the EventTypeEnum and its =E2=80=9CData Flow=E2=80=9D =
value go far beyond network-related scope.

It is about a lot of other types of potential data flows (as I just =
outlined in a response to Tom) that have nothing to do with network =
flow.

=20

Thanks for your response though. This is the kind of discussions that we =
hope to have a lot more of among the various supported communities.

=20

=20

BTW, you may have noticed that the Network_Flow object within CybOX v1.0 =
(Draft) supports expression of netflow within several of the most common =
formats including Netflow9 (as well as IPFIX as Luis pointed out, =
Netflow5 and SiLK as well as bi-directional flow in YAF). The common =
5-tuple or 7-tuple (you describe) (in our case it is an 8-tuple as we =
broke the router interface out into both ingress and egress J) shared by =
pretty much all of the netflow approaches has been broken out into a =
shared Network_Flow_Label structure. The various context-dependent =
portions of the independent approaches are then captured within optional =
structures dedicated to each of them. We hope that eventually the =
community can work to come together towards a single overall common =
expressive structure for netflow that meets the needs of all. We hope =
that CybOX and its use can even help that sort of maturation and =
normalization. But since no such universal structure exists today, we =
decided to enable optional expression of the most common individual =
formats within a single netflow object to serve the large majority of =
relevant users, maintain flexibility and enable discussions and analysis =
of netflow within a common package.

We look forward to continuing discussions with the community to validate =
or invalidate this approach and to refine and mature going forward.

=20

Sean=20

=20

From: Omar Santos (osantos) [mailto:osantos@cisco.com]=20
Sent: Monday, April 16, 2012 11:57 PM
To: Millar, Thomas; Barnum, Sean D.; lnunez@c3isecurity.com
Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; =
m-terada@ipa.go.jp
Subject: RE: [sacm] [mile] CybOX v1.0 (Draft) is now released and live =
onthe website

=20

I believe that what Sean is saying is that =E2=80=9Cdata flow=E2=80=9D =
is just a value that is meant for upper layer protocols. But, you have a =
good point. Traditionally, a =E2=80=9Cflow=E2=80=9D in =
=E2=80=9CNetflow=E2=80=9D is based on a set of 5 and up to 7 IP packet =
attributes:

=20

- IP source address

- IP destination address

- Source port

- Destination port

- Layer 3 protocol type

- Class of Service

- Router or switch interface

=20

Although, there is a lot more support with Netflow version 9:

http://www.cisco.com/en/US/technologies/tk648/tk362/technologies_white_pa=
per09186a00800a3db9_ps6601_Products_White_Paper.html

=20

=20

=20

Regards,

Omar=20

=20

From: Millar, Thomas [mailto:Thomas.Millar@hq.dhs.gov]=20
Sent: Monday, April 16, 2012 11:46 PM
To: sbarnum@mitre.org; Omar Santos (osantos); lnunez@c3isecurity.com
Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; =
m-terada@ipa.go.jp
Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live =
onthe website

=20

If "data flow" is a euphemism for "netflow" is there any reason not to =
call it that?

Tom Millar=20
http://www.us-cert.gov/=20
------------------=20
Missit me Rubus fruticosus:=20
202 631 1915=20

=20

From: Barnum, Sean D. [mailto:sbarnum@mitre.org]=20
Sent: Monday, April 16, 2012 11:29 PM
To: Omar Santos (osantos) ; Luis Nunez =
=20
Cc: idxwg@nicwg.org ; mile@ietf.org ; =
dallendoug@gmail.com ; sacm@ietf.org =
; m-terada@ipa.go.jp =20
Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live =
onthe website=20
=20

Thanks Omar.

=20

To answer your question, first let me point out to other readers that =
the two entries that Omar is quoting here exist as values in an =
enumeration called EventTypeEnum which as its name implies contains a =
list of different labels for grouping types (or classes) of events to be =
used as low-granularity buckets for characterizing and classifying =
events.

Other entries in this enumeration include things like =E2=80=9CFile Ops =
(CRUD)=E2=80=9D, =E2=80=9CProcess Mgt=E2=80=9D, =E2=80=9CAuthorization =
(ACL)=E2=80=9D, etc.

=20

The =E2=80=9CPacket Traffic=E2=80=9D value is intended to characterize =
events dealing with network packet traffic as its name implies.

The =E2=80=9CData Flow=E2=80=9D value is intended to characterize events =
dealing with forms of data flow at a higher level of abstraction than =
just packet traffic. The relationship between these two values could be =
viewed as =E2=80=9CPacket Traffic=E2=80=9D being a more detailed form of =
=E2=80=9CData Flow=E2=80=9D just as the values =E2=80=9CApp Layer =
Traffic=E2=80=9D and =E2=80=9CHTTP Layer Traffic=E2=80=9D, also in this =
enumeration, could be other levels in this same abstraction stack.

The idea behind the varying levels of abstraction is to leave  buckets =
large enough to capture a wide variety of potential event types (e.g. =
data flow events other than obvious things like packet traffic) but also =
enable the use of smaller more specific buckets when they are =
appropriate and commonly used.

=20

Does this make sense?=20

=20

sean

=20

From: Omar Santos (osantos) [mailto:osantos@cisco.com]=20
Sent: Monday, April 16, 2012 8:17 PM
To: Luis Nunez; Barnum, Sean D.
Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; =
m-terada@ipa.go.jp
Subject: RE: [sacm] [mile] CybOX v1.0 (Draft) is now released and live =
onthe website

=20

I echo Luis=E2=80=99 comments. It is good to see the inclusion of =
network objects. Quick question to the team related to your netflow =
comment.

=20

I am looking at:

http://cybox.mitre.org/XMLSchema/cybox_core_v1.0%28draft%29.xsd

=20

=E2=80=A6 and it looks that we renamed it to =E2=80=9CData =
Flow=E2=80=9D?

=20



   

        Specifies the class of events dealing with =
data flow.

   



=20

=20

What is the difference between that and =E2=80=9CPacket =
Traffic=E2=80=9D?

=20


   
     Specifies the class of events dealing with packet =
traffic.
   


=20

=20

=20

=20

Regards,

Omar Santos
Incident Manager, PSIRT
Security Research and Operations
Cisco Systems, Inc.
Email: os@cisco.com
Phone: +1 919 392 8635
PGP Key: 0x3AF27EDC

Cisco.com - http://www.cisco.com
Cisco Security Advisories and Notices - http://www.cisco.com/go/psirt

This email may contain confidential and privileged material for the sole
use of the intended recipient. Any review, use, distribution or
disclosure by others is strictly prohibited. If you are not the intended
recipient (or authorized to receive for the recipient), please contact
the sender by reply email and delete all copies of this message.

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

=20

From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of =
Luis Nunez
Sent: Monday, April 16, 2012 6:44 PM
To: Barnum, Sean D.
Cc: idxwg@nicwg.org; mile@ietf.org; Doug Wilson (dallendoug@gmail.com); =
sacm@ietf.org; IPA-Masato Terada (m-terada@ipa.go.jp)
Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live =
onthe website

=20

I like the inclusion of the network-centric objects.  IPFIX (netflow)  =
will add an additional perspective from an incident information sharing =
standpoint. =20

=20

-ln

=20

On Apr 16, 2012, at 4:04 PM, Barnum, Sean D. wrote:

=20

Hey everyone,

=20

I just wanted to let you all know that CybOX v1.0 (Draft) content is now =
live on the website. http://cybox.mitre.org

The release notes are provided inline below.

The key items of note are:

=C2=B7        The release of two formal specifications for the CybOX =
language (one for the core language and one for the defined objects)

=C2=B7        The XML Schema has gone through extensive improvements for =
expressiveness, clarity, consistency, efficiency, alignment to existing =
normative references and documentation.

=C2=B7        This release includes an initial set of language =
utilities: a draft Snort -> CybOX transform, a draft OpenIOC -> CybOX =
transform, and a set of Python bindings for the CybOX language.

=C2=B7        The website now includes a small set of content examples. =
This set will grow going forward.

This release involved a lot of hard work from a diverse group of people. =
Thank you all for your contributions and effort. We could not have done =
it without you.

We look forward to everyone=E2=80=99s feedback and collaboration as we =
continue to improve and mature the CybOX language.

=20

Sean Barnum

=20

=20

=20

CybOX v1.0 (Draft) Release Notes

The Version 1.0 (Draft) release of Cyber Observable eXpression =
(CybOX=E2=84=A2) is intended as a draft release of an initial major =
version of the CybOX Language that could be utilized for practical =
operational use and integration into other standards efforts. This =
release consists of three primary components: a pair of formal language =
specifications for the core language content and defined objects =
content, a set of language implementation XML schemas (core, =
common_types, and ~70 defined object schemas), and a small initial set =
of language utilities including an initial draft Snort->CybOX transform, =
an initial draft OpenIOC->CybOX transform and a set of CybOX language =
Python bindings. Recognizing that this is the first time that the formal =
language specifications will be available for review and as such will =
likely generate feedback from new stakeholders, this initial major =
version is being released as a =E2=80=9Cdraft=E2=80=9D v1.0 with the =
expectation of cycles of new feedback and revision before a =
=E2=80=9Cfinal=E2=80=9D v1.0 is released.

The CybOX v1.0 (Draft) XML schemas include a significant number of =
changes from v0.7 to improve:

=C2=B7       Clarity, documentation, and descriptive formality for =
reference and implementation by other standards and users.

=C2=B7       Consistency, simplicity, and efficiency.

=C2=B7       Alignment (as appropriate) to existing normative =
references.

=C2=B7       Expressiveness of the schema to better support the broad =
set of use cases it targets (malware characterization, indicator and =
incident data sharing, event management, etc.) including the addition of =
an initial set of network-related defined objects.

Summary of changes from CybOX_v0.7 to CybOX_v1.0_(Draft):

=C2=B7       Refinement of namespaces and schema locations for better =
effectiveness and flexibility going forward.

=C2=B7       Normalized all content according to an established set of =
naming conventions.

=C2=B7       Fully annotated all language items (types, attributes, =
elements, etc.).

=C2=B7       Moved several commonly leveraged types out of the core =
schema and into common_types.

=C2=B7       Achieved full typing of entire schema structure such that =
all attributes and elements are definitively typed.

=C2=B7       Changed all identifiers from ID and IDREF types to be =
QNames enabling globally unique identifiers and flexibility for =
domain-specific users of CybOX to define their own identifier syntax =
locally.

=C2=B7       Reordered attributes and elements in numerous types to =
better reflect common usage and priority.

=C2=B7       Added major_version and minor_version attributes for core =
schema.

=C2=B7       Added capability to characterize source of overall =
observable package data and for individual observables.

=C2=B7       Modified the logical composition structure such that any =
such compositions are now contained within a Observable_Composition =
element providing improved simplicity and modularity.

=C2=B7       Removed the Delta element from ObservableType and relocated =
the appropriate portions (Change, Trend, and Frequency) to appropriate =
locations under Stateful_Measure and Event.

=C2=B7       Added a Domain_Specific_Object_Attributes field to Object =
utilizing an abstract type that will allow domain-specific use cases to =
add in their own domain-specific attributes for Objects.

=C2=B7       Added a Tool-Specific_Data field to ToolInformationType =
utilizing an abstract type that will allow addition of tool-specific =
data.

=C2=B7       Added an Indicators field to MeasureSourceType utilizing an =
abstract type that will allow characterizing differing formats or =
standards of indicators that may have led to the identification of the =
observable data.

=C2=B7       Enhanced the Hash structure to capture full fuzzy hashes in =
addition to simple hashes

=C2=B7       Added a new ExtractedFeaturesType that can be used to adorn =
differing objects (e.g., files, memory, etc.) to capture extracted =
strings, imports, functions and code snippets

=C2=B7       Added a ByteRunsType to enable capture of byte runs within =
various objects.

=C2=B7       Added object_reference attribute to DefinedObjectType to =
better support referencing of independently defined Objects from within =
another Object definition.

=C2=B7       Added a generic DataSegmentType to provide a relatively =
abstract way of characterizing data segments that may be =
written/read/transmitted or otherwise utilized in actions or defined in =
objects.

=C2=B7        Added several new defined object schemas (API, Code, =
Device, DNS_Record, Network_Flow, Network_Packet, Network_Route_Entry, =
Network_Subnet, Unix_Network_Route_Entry) including an initial set of =
network-centric defined objects.

=C2=B7       Modified every defined object schema with added annotations =
as well as minor and in some cases substantive changes to fix errors, =
improve consistency and alignment with existing normative references, =
and to improve expressiveness in support of the targeted use cases.

Detailed changes from CybOX_v0.7 to CybOX_v1.0_(Draft):

The level of changes within v1.0 (Draft) in the core schema, =
common_types and the defined object schemas is too great to list every =
change in these release notes. Detailed difference reports are available =
for each individual schema at: =
 =
http://cybox.mitre.org/XMLSchema/release_notes/cybox_v1.0(draft)_diff_rep=
orts.zip

=20

=20

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Sean Barnum

Cyber Security Principal

The MITRE Corporation

Email: sbarnum@mitre.org

=20

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

=20


------=_NextPart_001_0178_01CD1CBA.4FE9CE70
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable


Thanks.=C2=A0 Appreciated the detailed =
explanation.
 
Mike
 
 
From:=
 =
Barnum, Sean D. [mailto:sbarnum@mitre.org] 
Sent: Tuesday, =
April 17, 2012 4:47 PM
To: Michael Hammer; osantos@cisco.com; =
Thomas.Millar@hq.dhs.gov; lnunez@c3isecurity.com
Cc: =
idxwg@nicwg.org; mile@ietf.org; sacm@ietf.org; m-terada@ipa.go.jp; =
dallendoug@gmail.com
Subject: RE: [mile] [sacm] CybOX v1.0 =
(Draft) is now released and live onthe =
website
 
Mike,
 
If you always =
utilized the most abstract label (Data Flow) to adorn events even when =
you knew the more specific type that they were and had a more specific =
label for them, then yes you would lose =
distinction.
Such misuse =
is always the potential downside of enabling flexibility through =
abstraction.
If you know =
that the event you are characterizing has to do with Packet Traffic and =
not just some form of more general data flow that does not have an =
appropriate associated event type label, then you should absolutely use =
Packet Traffic and not Data Flow. An event should only be tagged with an =
abstract label like Data Flow if there is not an appropriate more =
concrete label available.
 
In answer to =
your second question, yes Data Flow definitely covers not only =
network-related events but also events that have nothing to do with the =
wire.
My response =
to Tom Millar that I sent at 12:52am this morning lists out several =
non-network related types of events that Data Flow could apply =
to.
 
Please do not =
feel bad for asking these questions. They help you understand our =
approach, they help others understand our approach, they help us better =
understand the perspective of the communities we are targeting to =
support, they help us uncover issues with our approach or =
implementation, and they help us understand where we need to explain =
ourselves better.
 
Thank you for =
the constructive discourse.
 
sean
 
From:=
 =
Michael Hammer [mailto:michael.ham=
mer@yaanatech.com] 
Sent: Tuesday, April 17, 2012 3:28 =
PM
To: Barnum, Sean D.; osantos@cisco.com; Thomas.Millar@hq.dhs.gov; =
lnunez@c3isecurity.com
C=
c: idxwg@nicwg.org; mile@ietf.org; sacm@ietf.org; m-terada@ipa.go.jp; dallendoug@gmail.com
Subje=
ct: RE: [mile] [sacm] CybOX v1.0 (Draft) is now released and live =
onthe website
 
Sean,
 
What you say makes sense.  But, if you will bear with me.  =
(Still learning this.)
 
If one used Packet Traffic event type always instead of Data Flow =
event type, would some distinction be lost?
Or, put another way, since the packet stuff seems to cover most =
network-based events, does Data Flow involve something that is not on =
the wire?
(Such as an inter-process communication that doesn=E2=80=99t go =
through a protocol stack.)
 
Mike
 
 
From:=
 =
Barnum, Sean D. [mailto:sbarnum@mitre.org]=
 
Sent: Tuesday, April 17, 2012 3:03 PM
To: Michael =
Hammer; osantos@cisco.com; Thomas.Millar@hq.dhs.gov; =
lnunez@c3isecurity.com
C=
c: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; m-terada@ipa.go.jp
Subject:<=
/b> RE: [mile] [sacm] CybOX v1.0 (Draft) is now released and live onthe =
website
 
Mike,
 
Just to clarify, all of our discussion so far about =E2=80=9CData =
Flow=E2=80=9D and netflow were all in regards to an enumeration called =
EventTypeEnum that simply lets you tag a cyber observable event with a =
type label. It is metadata for an event =
description.
The only object we have been talking about in any detail so far was =
the Network_Flow object. These two topics are totally independent of =
each other. There is no Data_Flow object.
The abstraction overlap we have been discussing is only in the =
metadata tag applied to an event to characterize what type/class of =
event it is.
 
The defined objects themselves (including Network_Flow) have been =
designed to avoid, as much as possible, overlap of the type you =
describe.
The approach we have taken is that where there is common structure =
and meaning relevant to multiple different types of objects, the =
structure for that commonality is broken out into its own object (e.g. =
Address, URI, Port, Account, Process, etc.).
Content based on this common object structure can be embedded within =
a leveraging object (via direct use of the object type) if the content =
is directly relevant only within the context of that object or as an =
independent object and associated to any number of other objects to =
which it is relevant utilizing relationships.
We make no guarantees that we have managed to implement this approach =
flawlessly but we believe that it yields a good balance of consistency, =
efficiency and flexibility. It also allows easy modular use of only what =
is relevant within a given context and enables extension and evolution =
to easily occur in a localized fashion rather than having to extend and =
modify one monolithic structure standard.
 
Does that make sense?
 
sean
 
From:=
 =
Michael Hammer [mailto:michael.ham=
mer@yaanatech.com] 
Sent: Tuesday, April 17, 2012 9:18 =
AM
To: Barnum, Sean D.; osantos@cisco.com; Thomas.Millar@hq.dhs.gov; =
lnunez@c3isecurity.com
C=
c: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; m-terada@ipa.go.jp
Subject:<=
/b> RE: [mile] [sacm] CybOX v1.0 (Draft) is now released and live onthe =
website
 
Sean,
 
Does the overlap between the various objects present a =
problem?
 
If there are one or more objects that could carry the same data, then =
human nature means that probability-wise someone will choose data flow =
instead of Netflow.
That is the underlying principle in Murphy=E2=80=99s Law, where you =
try to design it so that there is only one way to do it, and thus =
private Murphy won=E2=80=99t do it the =E2=80=9Cwrong=E2=80=9D =
way.
 
Just wondering if these should be mutually exclusive sets.  And =
designed as such.
Might improve interoperability.  (And avoid discussions like =
this in future.)  J
 
Mike
 
 
From:=
 =
mile-bounces@ietf.org [mailto:mile-bounces@ietf.=
org] On Behalf Of Barnum, Sean D.
Sent: Tuesday, =
April 17, 2012 1:10 AM
To: Omar Santos (osantos); Millar, =
Thomas; lnunez@c3isecurity.com
C=
c: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; m-terada@ipa.go.jp
Subject:<=
/b> Re: [mile] [sacm] CybOX v1.0 (Draft) is now released and live onthe =
website
 
=E2=80=9Cupper layer=E2=80=9D? Yes, as in higher =
abstraction.
Just =E2=80=9Cprotocols=E2=80=9D? No.
 
You guys have been looking at this through the lens of network flow =
which if fine for thinking about that perspective but it is important to =
also realize that the EventTypeEnum and its =E2=80=9CData Flow=E2=80=9D =
value go far beyond network-related scope.
It is about a lot of other types of potential data flows (as I just =
outlined in a response to Tom) that have nothing to do with network =
flow.
 
Thanks for your response though. This is the kind of discussions that =
we hope to have a lot more of among the various supported =
communities.
 
 
BTW, you may have noticed that the Network_Flow object within CybOX =
v1.0 (Draft) supports expression of netflow within several of the most =
common formats including Netflow9 (as well as IPFIX as Luis pointed out, =
Netflow5 and SiLK as well as bi-directional flow in YAF). The common =
5-tuple or 7-tuple (you describe) (in our case it is an 8-tuple as we =
broke the router interface out into both ingress and egress J) shared by pretty much all of the netflow approaches has been broken =
out into a shared Network_Flow_Label structure. The various =
context-dependent portions of the independent approaches are then =
captured within optional structures dedicated to each of them. We hope =
that eventually the community can work to come together towards a single =
overall common expressive structure for netflow that meets the needs of =
all. We hope that CybOX and its use can even help that sort of =
maturation and normalization. But since no such universal structure =
exists today, we decided to enable optional expression of the most =
common individual formats within a single netflow object to serve the =
large majority of relevant users, maintain flexibility and enable =
discussions and analysis of netflow within a common =
package.
We look forward to continuing discussions with the community to =
validate or invalidate this approach and to refine and mature going =
forward.
 
Sean 
 
From:=
 =
Omar Santos (osantos) [mailto:osantos@cisco.com]=
 
Sent: Monday, April 16, 2012 11:57 PM
To: Millar, =
Thomas; Barnum, Sean D.; lnunez@c3isecurity.com
C=
c: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; m-terada@ipa.go.jp
Subject:<=
/b> RE: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe =
website
 
I believe that what Sean is saying is that =E2=80=9Cdata =
flow=E2=80=9D is just a value that is meant for upper layer protocols. =
But, you have a good point. Traditionally, a =E2=80=9Cflow=E2=80=9D in =
=E2=80=9CNetflow=E2=80=9D is based on a set of 5 and up to 7 IP packet =
attributes:
 
- IP source address
- IP destination address
- Source port
- Destination port
- Layer 3 protocol type
- Class of Service
- Router or switch interface
 
Although, there is a lot more support with Netflow version =
9:
http://www.=
cisco.com/en/US/technologies/tk648/tk362/technologies_white_paper09186a00=
800a3db9_ps6601_Products_White_Paper.html
 
 
 
Regards,

Omar 
 
From:=
 =
Millar, Thomas [mailto:Thomas.Millar@h=
q.dhs.gov] 
Sent: Monday, April 16, 2012 11:46 =
PM
To: sbarnum@mitre.org; Omar Santos =
(osantos); lnunez@c3isecurity.com
C=
c: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; m-terada@ipa.go.jp
Subject:<=
/b> Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe =
website
 
If "data flow" is a euphemism for "netflow" is =
there any reason not to call it that?

Tom Millar 
http://www.us-cert.gov/ =

------------------ 
Missit me Rubus fruticosus: 
202 631 1915 =


 
From<=
/b>: =
Barnum, Sean D. [mailto:sbarnum@mitre.org]=
 
Sent: Monday, April 16, 2012 11:29 PM
To: Omar =
Santos (osantos) <osantos@cisco.com>; Luis Nunez =
<lnunez@c3isecurity.com> =

Cc: idxwg@nicwg.org =
<idxwg@nicwg.org>; mile@ietf.org <mile@ietf.org>; dallendoug@gmail.com <dallendoug@gmail.com>; sacm@ietf.org <sacm@ietf.org>; m-terada@ipa.go.jp <m-terada@ipa.go.jp> =

Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released =
and live onthe website 
 
Thanks Omar.
 
To answer your question, first let me point out to other readers that =
the two entries that Omar is quoting here exist as values in an =
enumeration called EventTypeEnum which as its name implies contains a =
list of different labels for grouping types (or classes) of events to be =
used as low-granularity buckets for characterizing and classifying =
events.
Other entries in this enumeration include things like =E2=80=9CFile =
Ops (CRUD)=E2=80=9D, =E2=80=9CProcess Mgt=E2=80=9D, =
=E2=80=9CAuthorization (ACL)=E2=80=9D, etc.
 
The =E2=80=9CPacket Traffic=E2=80=9D value is intended to =
characterize events dealing with network packet traffic as its name =
implies.
The =E2=80=9CData Flow=E2=80=9D value is intended to characterize =
events dealing with forms of data flow at a higher level of abstraction =
than just packet traffic. The relationship between these two values =
could be viewed as =E2=80=9CPacket Traffic=E2=80=9D being a more =
detailed form of =E2=80=9CData Flow=E2=80=9D just as the values =
=E2=80=9CApp Layer Traffic=E2=80=9D and =E2=80=9CHTTP Layer =
Traffic=E2=80=9D, also in this enumeration, could be other levels in =
this same abstraction stack.
The idea behind the varying levels of abstraction is to leave =
 buckets large enough to capture a wide variety of potential event =
types (e.g. data flow events other than obvious things like packet =
traffic) but also enable the use of smaller more specific buckets when =
they are appropriate and commonly used.
 
Does this make sense? 
 
sean
 
From:=
 =
Omar Santos (osantos) [mailto:osantos@cisco.com]=
 
Sent: Monday, April 16, 2012 8:17 PM
To: Luis =
Nunez; Barnum, Sean D.
Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; m-terada@ipa.go.jp
Subject:<=
/b> RE: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe =
website
 
I echo Luis=E2=80=99 comments. It is good to see the inclusion of =
network objects. Quick question to the team related to your netflow =
comment.
 
I am looking at:
=
http://cybox.mitre.org/XMLSchema/cybox_core_v1.0%28draft%29.xsd<=
/o:p>
 
=E2=80=A6 and it looks that we renamed it to =E2=80=9CData =
Flow=E2=80=9D?
 
<xs:enumeration =
value=3D"Data Flow">
   =
<xs:annotation>
        =
<xs:documentation>Specifies the class of events dealing with data =
flow.</xs:documentation>
   =
</xs:annotation>
</xs:enumeration>
 
 
What is the difference between that and =E2=80=9CPacket =
Traffic=E2=80=9D?
 
<xs:enumeration value=3D"Packet =
Traffic">
   =
<xs:annotation>
     =
<xs:documentation>Specifies the class of events dealing with =
packet traffic.</xs:documentation>
   =
</xs:annotation>
</xs:enumeration>
 
 
 
 
Regards,

Omar Santos
Incident Manager, =
PSIRT
Security Research and Operations
Cisco Systems, =
Inc.
Email: os@cisco.com
Phone: +1 919 392 =
8635
PGP Key: 0x3AF27EDC

Cisco.com - http://www.cisco.com
Cisco Security =
Advisories and Notices - http://www.cisco.com/go/psirt<=
br>
This email may contain confidential and privileged material for =
the sole
use of the intended recipient. Any review, use, distribution =
or
disclosure by others is strictly prohibited. If you are not the =
intended
recipient (or authorized to receive for the recipient), =
please contact
the sender by reply email and delete all copies of =
this message.

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html=

 
From:=
 =
sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.=
org] On Behalf Of Luis Nunez
Sent: Monday, April =
16, 2012 6:44 PM
To: Barnum, Sean D.
Cc: idxwg@nicwg.org; mile@ietf.org; Doug Wilson (dallendoug@gmail.com); sacm@ietf.org; IPA-Masato Terada (m-terada@ipa.go.jp)
Subject:=
 Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe =
website
 
I like the inclusion of the network-centric =
objects.  IPFIX (netflow)  will add an additional perspective =
from an incident information sharing standpoint. =
 
 
-ln
 
On Apr 16, 2012, at 4:04 =
PM, Barnum, Sean D. wrote:
 
Hey =
everyone,
 =

I just =
wanted to let you all know that CybOX v1.0 (Draft) content is now live =
on the website. http://cybox.mitre.org
The =
release notes are provided inline =
below.
The key =
items of note are:
=C2=B7        The =
release of two formal specifications for the CybOX language (one for the =
core language and one for the defined =
objects)
=C2=B7        The XML =
Schema has gone through extensive improvements for expressiveness, =
clarity, consistency, efficiency, alignment to existing normative =
references and documentation.
=C2=B7        This =
release includes an initial set of language utilities: a draft Snort =
-> CybOX transform, a draft OpenIOC -> CybOX transform, and a set =
of Python bindings for the CybOX language.
=C2=B7        The =
website now includes a small set of content examples. This set will grow =
going forward.
This =
release involved a lot of hard work from a diverse group of people. =
Thank you all for your contributions and effort. We could not have done =
it without you.
We look =
forward to everyone=E2=80=99s feedback and collaboration as we continue =
to improve and mature the CybOX =
language.
 =

Sean =
Barnum
 =

 =

 =

CybOX v1.0 (Draft) Release =
Notes
The Version 1.0 (Draft) release of Cyber =
Observable eXpression (CybOX=E2=84=A2) is intended as a draft release of an initial major version of =
the CybOX Language that could be utilized for practical operational use =
and integration into other standards efforts. This release consists of =
three primary components: a pair of formal language specifications for =
the core language content and defined objects content, a set of language =
implementation XML schemas (core, common_types, and ~70 defined object =
schemas), and a small initial set of language utilities including an =
initial draft Snort->CybOX transform, an initial draft =
OpenIOC->CybOX transform and a set of CybOX language Python bindings. =
Recognizing that this is the first time that the formal language =
specifications will be available for review and as such will likely =
generate feedback from new stakeholders, this initial major version is =
being released as a =E2=80=9Cdraft=E2=80=9D v1.0 with the expectation of =
cycles of new feedback and revision before a =E2=80=9Cfinal=E2=80=9D =
v1.0 is released.=

The CybOX v1.0 (Draft) XML schemas include a =
significant number of changes from v0.7 to improve:=

=C2=B7       Clarity, =
documentation, and descriptive formality for reference and =
implementation by other standards and users.=

=C2=B7       Consistency, =
simplicity, and efficiency.=

=C2=B7       Alignment (as =
appropriate) to existing normative references.=

=C2=B7       Expressiveness of the =
schema to better support the broad set of use cases it targets (malware =
characterization, indicator and incident data sharing, event management, =
etc.) including the addition of an initial set of network-related =
defined objects.=

Summary =
of changes from CybOX_v0.7 to CybOX_v1.0_(Draft):=

=C2=B7       =
Refinement of namespaces and schema =
locations for better effectiveness and flexibility going forward.=

=C2=B7       =
Normalized all content according to an =
established set of naming conventions.=

=C2=B7       =
Fully annotated all language items =
(types, attributes, elements, etc.).=

=C2=B7       =
Moved several commonly leveraged types =
out of the core schema and into common_types.=

=C2=B7       =
Achieved full typing of entire schema =
structure such that all attributes and elements are definitively =
typed.=

=C2=B7       =
Changed all identifiers from ID and IDREF =
types to be QNames enabling globally unique identifiers and flexibility =
for domain-specific users of CybOX to define their own identifier syntax =
locally.=

=C2=B7       =
Reordered attributes and elements in =
numerous types to better reflect common usage and priority.=

=C2=B7       =
Added major_version and minor_version =
attributes for core schema.=

=C2=B7       =
Added capability to characterize source =
of overall observable package data and for individual observables.=

=C2=B7       =
Modified the logical composition =
structure such that any such compositions are now contained within a =
Observable_Composition element providing improved simplicity and =
modularity.=

=C2=B7       =
Removed the Delta element from =
ObservableType and relocated the appropriate portions (Change, Trend, =
and Frequency) to appropriate locations under Stateful_Measure and =
Event.=

=C2=B7       =
Added a Domain_Specific_Object_Attributes =
field to Object utilizing an abstract type that will allow =
domain-specific use cases to add in their own domain-specific attributes =
for Objects.=

=C2=B7       =
Added a Tool-Specific_Data field to =
ToolInformationType utilizing an abstract type that will allow addition =
of tool-specific data.=

=C2=B7       =
Added an Indicators field to =
MeasureSourceType utilizing an abstract type that will allow =
characterizing differing formats or standards of indicators that may =
have led to the identification of the observable data.=

=C2=B7       =
Enhanced the Hash structure to capture =
full fuzzy hashes in addition to simple hashes=

=C2=B7       =
Added a new ExtractedFeaturesType that =
can be used to adorn differing objects (e.g., files, memory, etc.) to =
capture extracted strings, imports, functions and code snippets=

=C2=B7       =
Added a ByteRunsType to enable capture of =
byte runs within various objects.=

=C2=B7       =
Added object_reference attribute to =
DefinedObjectType to better support referencing of independently defined =
Objects from within another Object definition.=

=C2=B7       =
Added a generic DataSegmentType to =
provide a relatively abstract way of characterizing data segments that =
may be written/read/transmitted or otherwise utilized in actions or =
defined in objects.=

=C2=B7        Added several new =
defined object schemas (API, Code, Device, DNS_Record, Network_Flow, =
Network_Packet, Network_Route_Entry, Network_Subnet, =
Unix_Network_Route_Entry) including an initial set of network-centric =
defined objects.
=C2=B7       =
Modified every defined object schema with =
added annotations as well as minor and in some cases substantive changes =
to fix errors, improve consistency and alignment with existing normative =
references, and to improve expressiveness in support of the targeted use =
cases.=

Detailed changes from CybOX_v0.7 to =
CybOX_v1.0_(Draft):=

The level of changes within v1.0 (Draft) in =
the core schema, common_types and the defined object schemas is too =
great to list every change in these release notes. Detailed difference =
reports are available for each individual schema at:http://cybox.mitre.org/XMLSchema/release_notes/cybox_v1.0=
(draft)_diff_reports.zip
 =

 =

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

Sean Barnum=

Cyber Security Principal=

The MITRE Corporation=

 =

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

------=_NextPart_001_0178_01CD1CBA.4FE9CE70--

------=_NextPart_000_0177_01CD1CBA.4FE9CE70
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP6zCCBBow
ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV
BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow
OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5
MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g
QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO
ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk
IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp
ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd
hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj
DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU
Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF
s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D
J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez
useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg
lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8
T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6
g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE
74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggTXMIIDv6ADAgECAhBcX1ns/Jl/DtI19/BXCcuBMA0G
CSqGSIb3DQEBBQUAMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd
BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo
dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW
YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy
IENBIC0gRzMwHhcNMTIwNDAzMDAwMDAwWhcNMTMwNDAzMjM1OTU5WjCCAR4xFzAVBgNVBAoTDlZl
cmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13
d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChj
KTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNDAyBgNVBAsTK0RpZ2l0YWwgSUQg
Q2xhc3MgMSAtIE1pY3Jvc29mdCBGdWxsIFNlcnZpY2UxFzAVBgNVBAMUDk1pY2hhZWwgSGFtbWVy
MSswKQYJKoZIhvcNAQkBFhxtaWNoYWVsLmhhbW1lckB5YWFuYXRlY2guY29tMIGfMA0GCSqGSIb3
DQEBAQUAA4GNADCBiQKBgQDoKTk9rP/4lG6CLqIR4++IFTuOSLF6bmhDr6eiSahqU0VNP+H/LbiD
MAZsK9GQoBYPKQdKzy/gM+fl3Gm6VOdjKl8M3GB6LGgAK8d3ETN5dyKe5CAG7EEbKg9wxHWcuXW7
KYd052ven5Ec+Xj++v3HsE423O5q2mNh1Q8FNsnlXQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYD
VR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2ln
bi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYD
VR0fBEkwRzBFoEOgQYY/aHR0cDovL2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20v
SW5kQzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQA8rhDezFsw7OlR3+mZOZ39
SCKWNJ4gMlQEe31NNtvs6BUzE1uN+fJeZrJ5zjTdJWeG1NgVugcuzQfdv/m5BYbhgJvNfW6ElqZh
cye6imOUx8diekkeHXKYSLnEvCdJItXsC1h/huIT9e83WksM92qI/TFyCq6u39cGf9PaBYbcKcZk
jHjNi3SPnGifMC6opGiiyK/vB1lituoBRcJ13Y7XoXA8T0kSR8Dtmqvo1JudcFAbS1srytG1QX1H
XTsPkTDKHlwv2ZfmCSKK3sWHDrZfpRglxvcX2OwibcKVkKBJRRw36UuJOIj/u0WYABcYtusAb2+0
nqoGmOEYARnrseTZMIIG7jCCBdagAwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUF
ADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZv
ciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQ
cmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkw
NDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0
cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs
aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD
QSAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP
6bGNQU4099oL42r6ZYggCxET6ZvgSU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYH
r54UGAdPWr2f0jGyVBlzRmoZQhHsEnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50
ABMN0Ibak2f4MwOuGjxraXj2wCyO4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yx
BF6+wbaULZeQLSfSux7pg2qE9sSyriMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ
6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRw
Oi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CG
SAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYI
KwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6Al
hiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYI
KwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQ
UjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1Ud
EQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EI
Qf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUG
A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4
BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkx
RTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB
dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZ
gbWpBbVSOOk5hIls5DSoWufYbAlMJBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v
8dKBl8pUWkO/N4t6jhmND0OojPKvYLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM6
1a4ScAjr+zvid+zoK2Q1ds262uDRyxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/
XLJtSd5lUkL7DojS7Uodv0vj+Mxy+kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4
VRaMxmgD5yKocwuxvKDaUljdCg5/wYIxggS4MIIEtAIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAV
BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTsw
OQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykw
OTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFz
cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI19/BXCcuBMAkGBSsO
AwIaBQCgggMbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQx
NzIwNTExOVowIwYJKoZIhvcNAQkEMRYEFPLFNoYIU9Dq6iW3BE58SAKSAGRuMIGrBgkqhkiG9w0B
CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME
AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo
MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIIBAwYJKwYB
BAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd
BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo
dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW
YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy
IENBIC0gRzMCEFxfWez8mX8O0jX38FcJy4EwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkG
A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz
dCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24u
Y29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5W
ZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI1
9/BXCcuBMA0GCSqGSIb3DQEBAQUABIGAoQSRKKnuz647HvZtj0L2ZUKRq/20gwvnQdVhvF/1Srda
ZyuIPu4z/flG4rYKhgPmLLxIa+Hs5MBrZwOa7MuJtYKrDwwO8J06WFqYY51HINGxPvdMiJHLJuos
U5Is6f9b7PKappnSfH94aYvI07PLdB9d/sJ/LU1BrGeMi0c/Ne0AAAAAAAA=

------=_NextPart_000_0177_01CD1CBA.4FE9CE70--

From internet-drafts@ietf.org  Wed Apr 18 01:56:13 2012
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 D3EAF21F862F; Wed, 18 Apr 2012 01:56:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 Nl2KKu4hNFFg; Wed, 18 Apr 2012 01:56:09 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A94C21F861D; Wed, 18 Apr 2012 01:56:09 -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.00
Message-ID: <20120418085609.27302.65473.idtracker@ietfa.amsl.com>
Date: Wed, 18 Apr 2012 01:56:09 -0700
Cc: mile@ietf.org
Subject: [mile] I-D Action: draft-ietf-mile-iodef-xmlreg-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: Wed, 18 Apr 2012 08:56:14 -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=
 Working Group of the IETF.

	Title           : Expert Review for IODEF Extensions in IANA XML Registry
	Author(s)       : Brian Trammell
	Filename        : draft-ietf-mile-iodef-xmlreg-00.txt
	Pages           : 3
	Date            : 2012-04-16

   This document specifies restrictions on additions to the subset of
   the IANA XML Namespace and Schema registries, to require Expert
   Review for extensions to IODEF.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mile-iodef-xmlreg-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-mile-iodef-xmlreg-00.txt


From trammell@tik.ee.ethz.ch  Wed Apr 18 02:04:19 2012
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 ADEC421F85C6 for ; Wed, 18 Apr 2012 02:04:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7OfbvN9zr6pw for ; Wed, 18 Apr 2012 02:04:18 -0700 (PDT)
Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 9653A21F853E for ; Wed, 18 Apr 2012 02:04:18 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 00AB5D9308 for ; Wed, 18 Apr 2012 11:04:17 +0200 (MEST)
X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch
Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id geG47++M4Gi2 for ; Wed, 18 Apr 2012 11:04:17 +0200 (MEST)
Received: from public-docking-etx-r-059.ethz.ch (public-docking-etx-r-059.ethz.ch [195.176.113.59]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id B6DA8D9307 for ; Wed, 18 Apr 2012 11:04:17 +0200 (MEST)
From: Brian Trammell 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Wed, 18 Apr 2012 11:04:17 +0200
References: <20120418085609.27302.65473.idtracker@ietfa.amsl.com>
To: "" 
Message-Id: <287F0CE2-40D7-4C77-B78E-25CA2EDF9D1E@tik.ee.ethz.ch>
Mime-Version: 1.0 (Apple Message framework v1257)
X-Mailer: Apple Mail (2.1257)
Subject: [mile] Fwd:  I-D Action: draft-ietf-mile-iodef-xmlreg-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: Wed, 18 Apr 2012 09:04:19 -0000

Greetings, all,

As discussed in Paris and on the list, this separates the IODEF XML =
registry expert review from the IODEF extensions template document, to =
give this change the required Standards Track intended status while =
allowing the template to remain Informational.

As the content of this document has already been discussed, and review =
comments from its inclusion in mile-template already addressed, I'd like =
to ask for an immediate WGLC on the document.

Many thanks, best regards,

Brian (as iodef-xmlreg author)

Begin forwarded message:

> From: internet-drafts@ietf.org
> Subject: [mile] I-D Action: draft-ietf-mile-iodef-xmlreg-00.txt
> Date: April 18, 2012 10:56:09 AM GMT+02:00
> To: i-d-announce@ietf.org
> Cc: mile@ietf.org
>=20
>=20
> 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.
>=20
> 	Title           : Expert Review for IODEF Extensions in IANA XML =
Registry
> 	Author(s)       : Brian Trammell
> 	Filename        : draft-ietf-mile-iodef-xmlreg-00.txt
> 	Pages           : 3
> 	Date            : 2012-04-16
>=20
>   This document specifies restrictions on additions to the subset of
>   the IANA XML Namespace and Schema registries, to require Expert
>   Review for extensions to IODEF.
>=20
>=20
> A URL for this Internet-Draft is:
> =
http://www.ietf.org/internet-drafts/draft-ietf-mile-iodef-xmlreg-00.txt
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-mile-iodef-xmlreg-00.txt
>=20
> _______________________________________________
> mile mailing list
> mile@ietf.org
> https://www.ietf.org/mailman/listinfo/mile


From trammell@tik.ee.ethz.ch  Wed Apr 18 05:57:46 2012
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 D540F21F8575 for ; Wed, 18 Apr 2012 05:57:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xZ6hQGqj0Wj8 for ; Wed, 18 Apr 2012 05:57:42 -0700 (PDT)
Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id BD68F21F84D2 for ; Wed, 18 Apr 2012 05:57:42 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id C6D5FD9304 for ; Wed, 18 Apr 2012 14:57:41 +0200 (MEST)
X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch
Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ZsxifXt28kxJ for ; Wed, 18 Apr 2012 14:57:41 +0200 (MEST)
Received: from public-docking-etx-r-059.ethz.ch (public-docking-etx-r-059.ethz.ch [195.176.113.59]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 56CE9D9305 for ; Wed, 18 Apr 2012 14:57:41 +0200 (MEST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1257)
From: Brian Trammell 
In-Reply-To: <287F0CE2-40D7-4C77-B78E-25CA2EDF9D1E@tik.ee.ethz.ch>
Date: Wed, 18 Apr 2012 14:57:40 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20120418085609.27302.65473.idtracker@ietfa.amsl.com> <287F0CE2-40D7-4C77-B78E-25CA2EDF9D1E@tik.ee.ethz.ch>
To: "" 
X-Mailer: Apple Mail (2.1257)
Subject: [mile] WGLC on mile-template (was Re: I-D Action: draft-ietf-mile-iodef-xmlreg-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: Wed, 18 Apr 2012 12:57:46 -0000

Greetings, all,

As this document follows the removal of the XML registry review for =
IODEF extensions out of mile-template, and as mile-template was =
resubmitted before Paris as Informational, I'd like to ask for another =
WGLC on mile-template as well.

Many thanks, best regards,

Brian (as template author)


On Apr 18, 2012, at 11:04 AM, Brian Trammell wrote:

> Greetings, all,
>=20
> As discussed in Paris and on the list, this separates the IODEF XML =
registry expert review from the IODEF extensions template document, to =
give this change the required Standards Track intended status while =
allowing the template to remain Informational.
>=20
> As the content of this document has already been discussed, and review =
comments from its inclusion in mile-template already addressed, I'd like =
to ask for an immediate WGLC on the document.
>=20
> Many thanks, best regards,
>=20
> Brian (as iodef-xmlreg author)
>=20
> Begin forwarded message:
>=20
>> From: internet-drafts@ietf.org
>> Subject: [mile] I-D Action: draft-ietf-mile-iodef-xmlreg-00.txt
>> Date: April 18, 2012 10:56:09 AM GMT+02:00
>> To: i-d-announce@ietf.org
>> Cc: mile@ietf.org
>>=20
>>=20
>> 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.
>>=20
>> 	Title           : Expert Review for IODEF Extensions in IANA XML =
Registry
>> 	Author(s)       : Brian Trammell
>> 	Filename        : draft-ietf-mile-iodef-xmlreg-00.txt
>> 	Pages           : 3
>> 	Date            : 2012-04-16
>>=20
>>  This document specifies restrictions on additions to the subset of
>>  the IANA XML Namespace and Schema registries, to require Expert
>>  Review for extensions to IODEF.
>>=20
>>=20
>> A URL for this Internet-Draft is:
>> =
http://www.ietf.org/internet-drafts/draft-ietf-mile-iodef-xmlreg-00.txt
>>=20
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>=20
>> This Internet-Draft can be retrieved at:
>> =
ftp://ftp.ietf.org/internet-drafts/draft-ietf-mile-iodef-xmlreg-00.txt
>>=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 kathleen.moriarty@emc.com  Wed Apr 18 06:24:49 2012
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 203FC21F84FA for ; Wed, 18 Apr 2012 06:24:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.48
X-Spam-Level: 
X-Spam-Status: No, score=-10.48 tagged_above=-999 required=5 tests=[AWL=0.119,  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 d5htmzm3soPD for ; Wed, 18 Apr 2012 06:24:45 -0700 (PDT)
Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id F06B121F8566 for ; Wed, 18 Apr 2012 06:24:44 -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 q3IDOemA016139 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 18 Apr 2012 09:24:42 -0400
Received: from mailhub.lss.emc.com (mailhubhoprd04.lss.emc.com [10.254.222.226]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor) for ; Wed, 18 Apr 2012 09:24:25 -0400
Received: from mxhub21.corp.emc.com (mxhub21.corp.emc.com [128.222.70.133]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q3IDOPPI018723 for ; Wed, 18 Apr 2012 09:24:25 -0400
Received: from mx06a.corp.emc.com ([169.254.1.106]) by mxhub21.corp.emc.com ([128.222.70.133]) with mapi; Wed, 18 Apr 2012 09:24:16 -0400
From: 
To: 
Date: Wed, 18 Apr 2012 09:24:24 -0400
Thread-Topic: WGLC on draft-ietf-mile-template
Thread-Index: AQHNHWaScgOiCegkwUKlCWorIwe55Q==
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EMM-MHVC: 1
Subject: [mile] WGLC on draft-ietf-mile-template
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, 18 Apr 2012 13:24:49 -0000

Hello,

The Working Group Last Call (WGLC) for the mile-template document will take=
 place over the next 2 weeks, ending the morning of 2 May 2012.

Please review the document and post any questions to the MILE mailing list.
https://datatracker.ietf.org/doc/draft-ietf-mile-template/

Thank you in advance!

Best regards,
Kathleen=

From kathleen.moriarty@emc.com  Wed Apr 18 06:26:51 2012
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 957D221F858E for ; Wed, 18 Apr 2012 06:26:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.495
X-Spam-Level: 
X-Spam-Status: No, score=-10.495 tagged_above=-999 required=5 tests=[AWL=0.104, 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 u8puNYUjOm8N for ; Wed, 18 Apr 2012 06:26:47 -0700 (PDT)
Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 7F90121F8597 for ; Wed, 18 Apr 2012 06:26:47 -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 q3IDQjKd016384 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 18 Apr 2012 09:26:45 -0400
Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.129]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor) for ; Wed, 18 Apr 2012 09:26:33 -0400
Received: from mxhub15.corp.emc.com (mxhub15.corp.emc.com [128.222.70.236]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q3IDQXhL016627 for ; Wed, 18 Apr 2012 09:26:33 -0400
Received: from mx06a.corp.emc.com ([169.254.1.106]) by mxhub15.corp.emc.com ([128.222.70.236]) with mapi; Wed, 18 Apr 2012 09:26:32 -0400
From: 
To: 
Date: Wed, 18 Apr 2012 09:26:32 -0400
Thread-Topic: WGLC on draft-ietf-mile-iodef-xmlreg-00.txt
Thread-Index: AQHNHWbe0n+3SP4XhE21f+ph9oW8uw==
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EMM-MHVC: 1
Subject: [mile] WGLC on draft-ietf-mile-iodef-xmlreg-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: Wed, 18 Apr 2012 13:26:51 -0000

Hello,

The Working Group Last Call (WGLC) for the mile-iodef-xmlreg document will =
take place over the next 2 weeks, ending the morning of 2 May 2012.

Please review the document and post any questions to the MILE mailing list.
http://tools.ietf.org/id/draft-ietf-mile-iodef-xmlreg-00.txt

Thank you in advance!

Best regards,
Kathleen=

From wwwrun@rfc-editor.org  Fri Apr 20 16:19:10 2012
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 ADB4F21E8086; Fri, 20 Apr 2012 16:19:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.197
X-Spam-Level: 
X-Spam-Status: No, score=-104.197 tagged_above=-999 required=5 tests=[AWL=0.880, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4, 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 aTlyzDFJJ7wi; Fri, 20 Apr 2012 16:19:10 -0700 (PDT)
Received: from rfc-editor.org (rfcpa.amsl.com [12.22.58.47]) by ietfa.amsl.com (Postfix) with ESMTP id 1B93221E8049; Fri, 20 Apr 2012 16:19:10 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 810C6B1E003; Fri, 20 Apr 2012 16:18:00 -0700 (PDT)
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
From: rfc-editor@rfc-editor.org
Message-Id: <20120420231800.810C6B1E003@rfc-editor.org>
Date: Fri, 20 Apr 2012 16:18:00 -0700 (PDT)
Cc: mile@ietf.org, rfc-editor@rfc-editor.org
Subject: [mile] RFC 6545 on Real-time Inter-network Defense (RID)
X-BeenThere: mile@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Apr 2012 23:19:10 -0000

A new Request for Comments is now available in online RFC libraries.

        
        RFC 6545

        Title:      Real-time Inter-network Defense (RID) 
        Author:     K. Moriarty
        Status:     Standards Track
        Stream:     IETF
        Date:       April 2012
        Mailbox:    Kathleen.Moriarty@emc.com
        Pages:      84
        Characters: 203100
        Obsoletes:  RFC6045

        I-D Tag:    draft-ietf-mile-rfc6045-bis-11.txt

        URL:        http://www.rfc-editor.org/rfc/rfc6545.txt

Security incidents, such as system compromises, worms, viruses,
phishing incidents, and denial of service, typically result in the
loss of service, data, and resources both human and system.  Service
providers and Computer Security Incident Response Teams need to be
equipped and ready to assist in communicating and tracing security
incidents with tools and procedures in place before the occurrence of
an attack.  Real-time Inter-network Defense (RID) outlines a
proactive inter-network communication method to facilitate sharing
incident-handling data while integrating existing detection, tracing,
source identification, and mitigation mechanisms for a complete
incident-handling solution.  Combining these capabilities in a
communication system provides a way to achieve higher security levels
on networks.  Policy guidelines for handling incidents are
recommended and can be agreed upon by a consortium using the security
recommendations and considerations.  This document obsoletes RFC
6045.  [STANDARDS-TRACK]

This document is a product of the Managed Incident Lightweight Exchange Working Group of the IETF.

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC



From wwwrun@rfc-editor.org  Fri Apr 20 16:19:24 2012
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 4567221E804B; Fri, 20 Apr 2012 16:19:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.229
X-Spam-Level: 
X-Spam-Status: No, score=-104.229 tagged_above=-999 required=5 tests=[AWL=0.848, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4, 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 HkQR+lJgb2S1; Fri, 20 Apr 2012 16:19:23 -0700 (PDT)
Received: from rfc-editor.org (rfcpa.amsl.com [12.22.58.47]) by ietfa.amsl.com (Postfix) with ESMTP id B288D21E8054; Fri, 20 Apr 2012 16:19:23 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id ED93EB1E00F; Fri, 20 Apr 2012 16:18:13 -0700 (PDT)
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
From: rfc-editor@rfc-editor.org
Message-Id: <20120420231813.ED93EB1E00F@rfc-editor.org>
Date: Fri, 20 Apr 2012 16:18:13 -0700 (PDT)
Cc: mile@ietf.org, rfc-editor@rfc-editor.org
Subject: [mile] RFC 6546 on Transport of Real-time Inter-network Defense (RID) Messages over HTTP/TLS
X-BeenThere: mile@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Apr 2012 23:19:24 -0000

A new Request for Comments is now available in online RFC libraries.

        
        RFC 6546

        Title:      Transport of Real-time Inter-network Defense 
                    (RID) Messages over HTTP/TLS 
        Author:     B. Trammell
        Status:     Standards Track
        Stream:     IETF
        Date:       April 2012
        Mailbox:    trammell@tik.ee.ethz.ch
        Pages:      8
        Characters: 19114
        Obsoletes:  RFC6046

        I-D Tag:    draft-ietf-mile-rfc6046-bis-09.txt

        URL:        http://www.rfc-editor.org/rfc/rfc6546.txt

The Incident Object Description Exchange Format (IODEF) defines a
common XML format for document exchange, and Real-time Inter-network
Defense (RID) defines extensions to IODEF intended for the
cooperative handling of security incidents within consortia of
network operators and enterprises.  This document specifies an
application-layer protocol for RID based upon the passing of RID
messages over HTTP/TLS.  [STANDARDS-TRACK]

This document is a product of the Managed Incident Lightweight Exchange Working Group of the IETF.

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC



From david.oliva@verizon.net  Wed Apr 18 06:23:20 2012
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 C1C8E21F8566; Wed, 18 Apr 2012 06:23:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.044
X-Spam-Level: 
X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_HTML_ONLY=1.457]
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 UirEMjFPDere; Wed, 18 Apr 2012 06:23:16 -0700 (PDT)
Received: from vms173015pub.verizon.net (vms173015pub.verizon.net [206.46.173.15]) by ietfa.amsl.com (Postfix) with ESMTP id 102DB21F8532; Wed, 18 Apr 2012 06:23:16 -0700 (PDT)
Received: from vznit170060pub.verizon.net ([unknown] [192.168.1.3]) by vms173015.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0M2O00LIPFU1FEB0@vms173015.mailsrvcs.net>; Wed, 18 Apr 2012 08:22:50 -0500 (CDT)
Received: from 96.255.129.191 ([96.255.129.191]) by vznit170060 (Verizon Webmail) with HTTP; Wed, 18 Apr 2012 08:22:49 -0500 (CDT)
Date: Wed, 18 Apr 2012 08:22:49 -0500 (CDT)
From: david.oliva@verizon.net
To: lnunez@c3isecurity.com, sbarnum@mitre.org
Message-id: <10587345.1828362.1334755369596.JavaMail.root@vznit170060>
MIME-version: 1.0
Content-type: text/html; charset=UTF-8
Content-transfer-encoding: quoted-printable
X-Mailer: Verizon Webmail
X-Originating-IP: [96.255.129.191]
X-Mailman-Approved-At: Mon, 23 Apr 2012 00:34:04 -0700
Cc: idxwg@nicwg.org, mile@ietf.org, dallendoug@gmail.com, sacm@ietf.org, m-terada@ipa.go.jp
Subject: Re: [mile] [sacm] CybOX v1.0 (Draft) is now released and live on	the website
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, 18 Apr 2012 13:23:20 -0000


OUT=
STANDING!
 
Does Cybox also talk to OCI=
L, CPE, AI, and ARF (from SCAP 1.2)?
 
David Oliva=

ISSEP, CISSP, CAP, CISM, Security+, Network+
 
 
On 04/16/12, Luis Nunez<lnunez@c3isecurity.com> wr=
ote:
 
I like the inclusion of the network-centric objects. &n=
bsp;IPFIX (netflow)  will add an additional perspective from an incide=
nt information sharing standpoint.  

-ln
=

On Apr 16, 2012, at 4:04 PM, Barnum, Sean D. wrote:

Hey everyone,
 
I just wanted to let you all know that CybOX =
v1.0 (Draft) content is now live on the website. http://cybox.mitre.org=

The release notes are provided inline below.
The key items of note are:
=C2=B7      &nbs=
p; The=
 release of two formal specifications for the CybOX language (one for the c=
ore language and one for the defined objects)
=C2=B7    =
    <=
/SPAN>The XML Schema has gone through extensive improvements for exp=
ressiveness, clarity, consistency, efficiency, alignment to existing normat=
ive references and documentation.
=C2=B7      =
  This release includes an initial set of language utilities: a draft Snort =
-> CybOX transform, a draft OpenIOC -> CybOX transform, and a set of =
Python bindings for the CybOX language.
=C2=B7This =
release involved a lot of hard work from a diverse group of people. Thank y=
ou all for your contributions and effort. We could not have done it without=
 you.
We look forward to everyone=E2=80=99s feedback and co=
llaboration as we continue to improve and mature the CybOX language.
<=
DIV style=3D"MARGIN: 0in 0in 0pt; FONT-FAMILY: Calibri, sans-serif; FONT-SI=
ZE: 11pt"> 
Sean Barnum
 
 
 
CybOX v1.0 (Draft) Release Notes
The=
 Version 1.0 (Draft) release of Cyber Observable eXpression (CybOX=E2=84=A2=
) is intended as a draft=
 release of an initial major version of the CybOX Language that could be ut=
ilized for practical operational use and integration into other standards e=
fforts. This release consists of three primary components: a pair of formal=
 language specifications for the core language content and defined objects =
content, a set of language implementation XML schemas (core, common_types, =
and ~70 defined object schemas), and a small initial set of language utilit=
ies including an initial draft Snort->CybOX transform, an initial draft =
OpenIOC->CybOX transform and a set of CybOX language Python bindings. Re=
cognizing that this is the first time that the formal language specificatio=
ns will be available for review and as such will likely generate feedback f=
rom new stakeholders, this initial major version is being released as a =E2=
=80=9Cdraft=E2=80=9D v1.0 with the expectation of cycles of new feedback an=
d revision before a =E2=80=9Cfinal=E2=80=9D v1.0 is released.
<=
DIV style=3D"MARGIN: 0in 0in 0pt; FONT-FAMILY: Calibri, sans-serif; FONT-SI=
ZE: 11pt">The CybOX v1.0 (Draft) XML schemas include a significant number of ch=
anges from v0.7 to improve:
=C2=B7  &nbs=
p;    Clarity, documentation, and descriptive formality for reference =
and implementation by other standards and users.
=C2=B7       Consistency, simplicity, and efficiency.
=C2=B7       Alignment (as appro=
priate) to existing normative references.
=C2=B7       Expressiveness of =
the schema to better support the broad set of use cases it targets (malware=
 characterization, indicator and incident data sharing, event management, e=
tc.) including the addition of an initial set of network-related defined ob=
jects.
Summary of changes from CybOX_v0.7 to CybOX_v1.0_(D=
raft):
  • Refinement of namespaces and schema locations for better eff=
ectiveness and flexibility going forward.
  • Fully annotated all language items =
(types, attributes, elements, etc.).
  • Mov=
ed several commonly leveraged types out of the core schema and into common_=
types.
  • Achieved full typing of entire sc=
hema structure such that all attributes and elements are definitively typed=
.
  • Changed all identifiers from ID and ID=
REF types to be QNames enabling globally unique identifiers and flexibility=
 for domain-specific users of CybOX to define their own identifier syntax l=
ocally.
  • Reordered attributes and element=
s in numerous types to better reflect common usage and priority.
  • Added major_version and minor_version attributes f=
or core schema.
  • Added capability to char=
acterize source of overall observable package data and for individual obser=
vables.
  • Modified the logical composition=
 structure such that any such compositions are now contained within a Obser=
vable_Composition element providing improved simplicity and modularity.
  • Removed the Delta element from ObservableTy=
pe and relocated the appropriate portions (Change, Trend, and Frequency) to=
 appropriate locations under Stateful_Measure and Event.
  • Added a Domain_Specific_Object_Attributes field to Object =
utilizing an abstract type that will allow domain-specific use cases to add=
 in their own domain-specific attributes for Objects.
  • Added a Tool-Specific_Data field to ToolInformationType util=
izing an abstract type that will allow addition of tool-specific data.
  • Added an Indicators field to MeasureSourceTy=
pe utilizing an abstract type that will allow characterizing differing form=
ats or standards of indicators that may have led to the identification of t=
he observable data.
  • Enhanced the Hash st=
ructure to capture full fuzzy hashes in addition to simple hashes
  • Added a new ExtractedFeaturesType that can be use=
d to adorn differing objects (e.g., files, memory, etc.) to capture extract=
ed strings, imports, functions and code snippets
  • Added a ByteRunsType to enable capture of byte runs within various=
 objects.
  • Added object_reference attribu=
te to DefinedObjectType to better support referencing of independently defi=
ned Objects from within another Object definition.
  • Added a generic DataSegmentType to provide a relatively abstract=
 way of characterizing data segments that may be written/read/transmitted o=
r otherwise utilized in actions or defined in objects.
=C2=B7&=
nbsp;       Added s=
everal new defined object schemas (API, Code, Device, DNS_Record, Network_F=
low, Network_Packet, Network_Route_Entry, Network_Subnet, Unix_Network_Rout=
e_Entry) including an initial set of network-centric defined objects.
  • Modified every defined object schema with added annotations as wel=
l as minor and in some cases substantive changes to fix errors, improve con=
sistency and alignment with existing normative references, and to improve e=
xpressiveness in support of the targeted use cases.
Detailed changes from CybOX_v0.7 to CybOX_v1.0_(Draft):
=

The level of changes within v1.0 (Draft) in the core schema, common_=
types and the defined object schemas is too great to list every change in t=
hese release notes. Detailed difference reports are available for each indi=
vidual schema at:http://cybox.mitre.org/XMLSchema/release_note=
s/cybox_v1.0(draft)_diff_reports.zip
 
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Sean Barnu=
m
Cyber =
Security Principal
The MITRE Corporation
________________________________=
_______________
mile mailing list
mile@ietf.org
https://www.ietf.org/mailman/listinfo/mile



___________________________________=
____________
sacm mailing list
sacm@ietf.org
https://=
www.ietf.org/mailman/listinfo/sacm


From amontville@tripwire.com  Mon Apr 23 15:36:33 2012
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 3F2F921E800F for ; Mon, 23 Apr 2012 15:36:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 TrwXoXG2-dap for ; Mon, 23 Apr 2012 15:36:32 -0700 (PDT)
Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe002.messaging.microsoft.com [216.32.180.12]) by ietfa.amsl.com (Postfix) with ESMTP id B255D21E8048 for ; Mon, 23 Apr 2012 15:36:31 -0700 (PDT)
Received: from mail175-va3-R.bigfish.com (10.7.14.248) by VA3EHSOBE001.bigfish.com (10.7.40.21) with Microsoft SMTP Server id 14.1.225.23; Mon, 23 Apr 2012 22:36:30 +0000
Received: from mail175-va3 (localhost [127.0.0.1])	by mail175-va3-R.bigfish.com (Postfix) with ESMTP id 77AC618026D; Mon, 23 Apr 2012 22:36:30 +0000 (UTC)
X-SpamScore: -43
X-BigFish: VPS-43(zzbb2dI9371I1415J542Mdf9M1432N98dKzz1202hzz1033IL8275bh8275dhz2dh2a8h668h839h944he5bh)
X-Forefront-Antispam-Report: CIP:174.47.84.216; KIP:(null); UIP:(null); IPV:NLI; H:PDXHB01.tripwire.com; RD:174-47-84-216.static.twtelecom.net; EFVD:NLI
Received: from mail175-va3 (localhost.localdomain [127.0.0.1]) by mail175-va3 (MessageSwitch) id 1335220587895070_7988; Mon, 23 Apr 2012 22:36:27 +0000 (UTC)
Received: from VA3EHSMHS005.bigfish.com (unknown [10.7.14.251])	by mail175-va3.bigfish.com (Postfix) with ESMTP id CBC4E2A0058; Mon, 23 Apr 2012 22:36:27 +0000 (UTC)
Received: from PDXHB01.tripwire.com (174.47.84.216) by VA3EHSMHS005.bigfish.com (10.7.99.15) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 23 Apr 2012 22:36:24 +0000
Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 23 Apr 2012 15:46:42 -0700
Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0355.002; Mon, 23 Apr 2012 15:36:23 -0700
From: Adam Montville 
To: "Waltermire, David A." , "mile@ietf.org" 
Thread-Topic: [mile] IODEF Reference Format for Enumerations
Thread-Index: AQHNFn/rimqKx0bIq0Wznd3Jbi9osJaXhxIAgAFGmSCAEEhVgA==
Date: Mon, 23 Apr 2012 22:36:23 +0000
Message-ID: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.14.0.111121
x-originating-ip: [172.30.0.234]
x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f
Content-Type: text/plain; charset="us-ascii"
Content-ID: <9C83DF78488D854CB8E868C76746CEE4@tripwire.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: tripwire.com
Subject: Re: [mile] IODEF Reference Format for Enumerations
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, 23 Apr 2012 22:36:33 -0000

Hi David,

Sorry for dropping off the face of the planet for a while.  This may be a
useful suggestion.  I think what you're saying is that current work could
focus not on the SCI extensions specifically, but point more toward
defining how such extensions would work.  Then, opening IODEF would be
able to follow that model.

What do others on the list think of this?  I think such an approach could
work if it is limited MILE-specific documents.  If it is a generalized
approach, applicable to a wide variety of efforts in the Security Area,
then I would ask whether MILE is the right place for the work.

Regards,

Adam

On 4/13/12 7:03 AM, "Waltermire, David A." 
wrote:

>Referencing security identifiers seems like an issue that will surface in
>other efforts.  If we create an IANA registry, it would be ideal if this
>registry could support reference use cases in other models.  Although
>each model may have sligtly different reference syntax, the general
>method for defining the type and identifier based the registry could be
>the same.  Have you put any thought into how this could be accomplished?
>
>One idea would be to have the draft you are focused on define the
>mechanism for defining identifier types and then have IODEF define how to
>represent a reference using the Reference class.  Other models could
>follow suit.
>
>Sincerely,
>David Waltermire
>
>
>> -----Original Message-----
>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of
>> Adam Montville
>> Sent: Thursday, April 12, 2012 2:28 PM
>> To: Adam Montville; mile@ietf.org
>> Subject: Re: [mile] IODEF Reference Format for Enumerations
>>=20
>> All:
>>=20
>> So far, it seems as though more people are speaking up in favor of
>> Option 2.  There are also several comments expressing a desire to
>> choose either Option 1 or Option 2, but then move to Option 3 at some
>> point in the future.  I'd like to understand more about what that
>> really means - choosing one option and then moving to another.
>>=20
>> Would it make more sense to wait until IODEF is "opened" for an update
>> to address this issue?
>>=20
>> For those of you who prefer Option 1 or Option 2, but have not
>> indicated a preference with respect to later moving to Option 3, do you
>> have an opinion about such a move?
>>=20
>> David Black has put forward some additional insight where, "if Option 1
>> is chosen, the result is a common means of referencing specifications
>> between the SCI draft and the new draft on use of the IODEF reference
>> format."
>> This statement references the notion of requiring the first URL of on
>> IODEF  element (associated with the ) to be a
>> reference URI from the IANA registry established by the SCI draft.
>>=20
>> It would seem, then, that we have deterministic methods of
>> understanding what a  is, and thus how to parse it, but
>> that we have several different mechanisms by which to accomplish this.
>>=20
>> Comments? Opinions?
>>=20
>> Regards,
>>=20
>> Adam
>>=20
>> On 4/9/12 11:38 AM, "Adam Montville"  wrote:
>>=20
>> >All:
>> >
>> >There is an identified need to specify a format to include relevant
>> >enumeration values in an IODEF document.  The initial idea is to place
>> >enumeration values and their references in IODEF's Reference class.
>> >There are several ways to accomplish this goal.  I'll do my best to
>> >enumerate some options here, then I hope to hear some
>> feedback/opinions
>> >about the different approaches from the list.
>> >
>> >From the Structured Cybersecurity Information draft
>> >(draft-takahashi-mile-sci-02), we may be interested to include the
>> >following (not an inclusive list) enumerations in an IODEF document:
>> >CAPEC, CCE, CPE, CVE, CWE, IEC 19770-2.
>> >
>> >The IODEF Reference class is described in 3.9.1 of RFC 5070, where a
>> >Reference must have a ReferenceName and zero or more of URL or
>> >Description respectively.
>> >
>> >For each option described below, we can consider use of the IANA
>> registry.
>> >The registry may be used to identify the identifier category and
>> >potentially the appropriate identification format for that category.
>> >
>> >
>> >Option 1: Simple ID
>> >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> >The first option would simply embed the relevant identifier in the
>> >ReferenceName element of the Reference class.  This may look like the
>> >following:
>> >
>> >    
>> >        id
>> >        http://www.example.com/path
>> >        http://www.otherexample.com/path
>> >        Description
>> >    
>> >
>> >Using this option, a variety of specific identifier formats could be
>> >specified.  CVE, for example, would start with "CVE-" and this
>> >convention may be registered in an IANA table.
>> >
>> >No changes to IODEF are required for this option.
>> >
>> >
>> >
>> >Option 2: ID with coupled ID type
>> >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> >The second option would prepend the identifier with it's type, which
>> >may look something like the following.
>> >
>> >    
>> >        id_type:id
>> >        http://www.example.com/path
>> >        http://www.otherexample.com/path
>> >        Description
>> >    
>> >
>> >Using this option, a variety of specific identifier types could be
>> >specified, such that the identifier itself would not necessarily be
>> >constrained, nor would new identifier formats necessarily need to be
>> >specified in the future.  An IANA table may be used for this solution
>> >as well.
>> >
>> >No changes to IODEF would be required for this option.
>> >
>> >
>> >
>> >Option 3: ID with type expressed in Reference attribute
>> >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D
>> >The third option would require opening IODEF to update the Reference
>> >class with an attribute, which may look something like the following.
>> >
>> >    
>> >        id
>> >        http://www.example.com/path
>> >        http://www.otherexample.com/path
>> >        Description
>> >    
>> >
>> >
>> >
>> >Changes to IODEF are required for this option.
>> >
>> >
>> >----
>> >
>> >I look forward to fielding responses to these options, including any
>> >additional options you may see, but which are not listed.
>> >
>> >What is your solution preference?
>> >
>> >
>> >Regards,
>> >
>> >Adam W. Montville | Security and Compliance Architect
>> >
>> >Direct: 503 276-7661
>> >Mobile: 360 471-7815
>> >
>> >TRIPWIRE | Take CONTROL
>> >http://www.tripwire.com
>> >
>> >
>> >
>> >
>> >
>> >
>> >_______________________________________________
>> >mile mailing list
>> >mile@ietf.org
>> >https://www.ietf.org/mailman/listinfo/mile
>> >
>>=20
>>=20
>> _______________________________________________
>> mile mailing list
>> mile@ietf.org
>> https://www.ietf.org/mailman/listinfo/mile
>



From amontville@tripwire.com  Mon Apr 23 15:44:12 2012
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 E4F9211E808F for ; Mon, 23 Apr 2012 15:44:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.099
X-Spam-Level: 
X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=1.500,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m9qE6+Sps3XJ for ; Mon, 23 Apr 2012 15:44:06 -0700 (PDT)
Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) by ietfa.amsl.com (Postfix) with ESMTP id EE4A411E8075 for ; Mon, 23 Apr 2012 15:44:05 -0700 (PDT)
Received: from mail49-tx2-R.bigfish.com (10.9.14.242) by TX2EHSOBE009.bigfish.com (10.9.40.29) with Microsoft SMTP Server id 14.1.225.23; Mon, 23 Apr 2012 22:44:05 +0000
Received: from mail49-tx2 (localhost [127.0.0.1])	by mail49-tx2-R.bigfish.com (Postfix) with ESMTP id 3E585603B1; Mon, 23 Apr 2012 22:44:05 +0000 (UTC)
X-SpamScore: -52
X-BigFish: VPS-52(zzbb2dI9371I1415J542Mdf9M1432N98dK4015Idf7O14ffIzz1202hzz1033IL8275bh8275dhz2dh2a8h668h839h944he5bh)
X-Forefront-Antispam-Report: CIP:174.47.84.216; KIP:(null); UIP:(null); IPV:NLI; H:PDXHB01.tripwire.com; RD:174-47-84-216.static.twtelecom.net; EFVD:NLI
Received: from mail49-tx2 (localhost.localdomain [127.0.0.1]) by mail49-tx2 (MessageSwitch) id 1335221042520383_10566; Mon, 23 Apr 2012 22:44:02 +0000 (UTC)
Received: from TX2EHSMHS034.bigfish.com (unknown [10.9.14.250])	by mail49-tx2.bigfish.com (Postfix) with ESMTP id 6E3D72C008F; Mon, 23 Apr 2012 22:44:02 +0000 (UTC)
Received: from PDXHB01.tripwire.com (174.47.84.216) by TX2EHSMHS034.bigfish.com (10.9.99.134) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 23 Apr 2012 22:44:02 +0000
Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 23 Apr 2012 15:54:19 -0700
Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0355.002; Mon, 23 Apr 2012 15:44:00 -0700
From: Adam Montville 
To: Takeshi Takahashi , "kathleen.moriarty@emc.com" , "mile@ietf.org" 
Thread-Topic: [mile] IODEF Reference Format for Enumerations
Thread-Index: AQHNFn/rimqKx0bIq0Wznd3Jbi9osJaXhxIAgAACw5CABhkuAIALdSAA
Date: Mon, 23 Apr 2012 22:43:59 +0000
Message-ID: 
In-Reply-To: <001701cd1bad$5608c580$021a5080$@nict.go.jp>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.14.0.111121
x-originating-ip: [172.30.0.234]
x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f
Content-Type: text/plain; charset="us-ascii"
Content-ID: <694034A8F1EC4E478A4E729ABF83711C@tripwire.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: tripwire.com
Subject: Re: [mile] IODEF Reference Format for Enumerations
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, 23 Apr 2012 22:44:12 -0000

Take,

Do you think it would make any sense to combine the two approaches?
Option 3 could be rewritten to be more aligned with the
 example you provided.


  id
  http://www.example.com/path
  http://www.otherexample.com/path
  Description



Or, perhaps the class information could be referenced in an IANA table in
a manner consistent with Options 1 and 2...  So, if there's a registryId,
then some semantic information about the types of classes accepted by that
registryId could be discovered.

Any thoughts from the list about this general approach?

Adam

On 4/16/12 1:45 AM, "Takeshi Takahashi" 
wrote:

>Hi all,
>
>If we are going to update option 3, that would be one direction.
>
>IMHO, the option 3 is very close to the expected use of the Vulnerability
>class of SCI draft. (and some other classes as well)
>The expected usage of the Vulnerability class of current SCI draft, with
>CVE
>identifier, is as follows.
>
>VulnerabilityID=3D"CVE-2010-3654"/>
>
>The slight difference between the SCI draft and the option 3 is that the
>SCI
>draft took a semantic approach (vulnerability, attackpattern, etc.), while
>the option three takes general container approach.
>The URLs to the information of the specification (in this case CVE 1.0)
>are
>described in the IANA table in case of the SCI draft approach.
>
>I think both approach is viable, but proper description on how to choose
>either of the approaches could be helpful for readers.
>
>Thank you.
>Take
>
>> -----Original Message-----
>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of
>> kathleen.moriarty@emc.com
>> Sent: Friday, April 13, 2012 3:56 AM
>> To: amontville@tripwire.com; mile@ietf.org
>> Subject: Re: [mile] IODEF Reference Format for Enumerations
>>=20
>> Hi Adam,
>>=20
>> Thank you for running the list of options by the WG and to those
>> participating in the decision process!
>>=20
>> We have had a couple of reasons discussed to 'open' up IODEF.  If we get
>> a volunteer to help with the editing of an RFC5070 soon, then option 3
>> may be worth considering.  I would expect that a revision to RFC5070
>>would
>> take some time as the list works through issues and options.
>>=20
>> What do others think about this and Adam's other questions?
>>=20
>> Thanks,
>> Kathleen
>>=20
>> -----Original Message-----
>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of
>> Adam Montville
>> Sent: Thursday, April 12, 2012 2:28 PM
>> To: Adam Montville; mile@ietf.org
>> Subject: Re: [mile] IODEF Reference Format for Enumerations
>>=20
>> All:
>>=20
>> So far, it seems as though more people are speaking up in favor of
>>Option
>> 2.  There are also several comments expressing a desire to choose either
>> Option 1 or Option 2, but then move to Option 3 at some point in the
>future.
>> I'd like to understand more about what that really means - choosing one
>> option and then moving to another.
>>=20
>> Would it make more sense to wait until IODEF is "opened" for an update
>> to address this issue?
>>=20
>> For those of you who prefer Option 1 or Option 2, but have not indicated
>> a preference with respect to later moving to Option 3, do you have an
>> opinion about such a move?
>>=20
>> David Black has put forward some additional insight where, "if Option
>> 1 is chosen, the result is a common means of referencing specifications
>> between the SCI draft and the new draft on use of the IODEF reference
>> format."
>> This statement references the notion of requiring the first URL of on
>> IODEF  element (associated with the ) to be
>> a reference URI from the IANA registry established by the SCI draft.
>>=20
>> It would seem, then, that we have deterministic methods of understanding
>> what a  is, and thus how to parse it, but that we have
>> several different mechanisms by which to accomplish this.
>>=20
>> Comments? Opinions?
>>=20
>> Regards,
>>=20
>> Adam
>>=20
>> On 4/9/12 11:38 AM, "Adam Montville"  wrote:
>>=20
>> >All:
>> >
>> >There is an identified need to specify a format to include relevant
>> >enumeration values in an IODEF document.  The initial idea is to place
>> >enumeration values and their references in IODEF's Reference class.
>> >There are several ways to accomplish this goal.  I'll do my best to
>> >enumerate some options here, then I hope to hear some feedback/opinions
>> >about the different approaches from the list.
>> >
>> >From the Structured Cybersecurity Information draft
>> >(draft-takahashi-mile-sci-02), we may be interested to include the
>> >following (not an inclusive list) enumerations in an IODEF document:
>> >CAPEC, CCE, CPE, CVE, CWE, IEC 19770-2.
>> >
>> >The IODEF Reference class is described in 3.9.1 of RFC 5070, where a
>> >Reference must have a ReferenceName and zero or more of URL or
>> >Description respectively.
>> >
>> >For each option described below, we can consider use of the IANA
>registry.
>> >The registry may be used to identify the identifier category and
>> >potentially the appropriate identification format for that category.
>> >
>> >
>> >Option 1: Simple ID
>> >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> >The first option would simply embed the relevant identifier in the
>> >ReferenceName element of the Reference class.  This may look like the
>> >following:
>> >
>> >    
>> >        id
>> >        http://www.example.com/path
>> >        http://www.otherexample.com/path
>> >        Description
>> >    
>> >
>> >Using this option, a variety of specific identifier formats could be
>> >specified.  CVE, for example, would start with "CVE-" and this
>> >convention may be registered in an IANA table.
>> >
>> >No changes to IODEF are required for this option.
>> >
>> >
>> >
>> >Option 2: ID with coupled ID type
>> >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> >The second option would prepend the identifier with it's type, which
>> >may look something like the following.
>> >
>> >    
>> >        id_type:id
>> >        http://www.example.com/path
>> >        http://www.otherexample.com/path
>> >        Description
>> >    
>> >
>> >Using this option, a variety of specific identifier types could be
>> >specified, such that the identifier itself would not necessarily be
>> >constrained, nor would new identifier formats necessarily need to be
>> >specified in the future.  An IANA table may be used for this solution
>> >as well.
>> >
>> >No changes to IODEF would be required for this option.
>> >
>> >
>> >
>> >Option 3: ID with type expressed in Reference attribute
>> >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D
>> >The third option would require opening IODEF to update the Reference
>> >class with an attribute, which may look something like the following.
>> >
>> >    
>> >        id
>> >        http://www.example.com/path
>> >        http://www.otherexample.com/path
>> >        Description
>> >    
>> >
>> >
>> >
>> >Changes to IODEF are required for this option.
>> >
>> >
>> >----
>> >
>> >I look forward to fielding responses to these options, including any
>> >additional options you may see, but which are not listed.
>> >
>> >What is your solution preference?
>> >
>> >
>> >Regards,
>> >
>> >Adam W. Montville | Security and Compliance Architect
>> >
>> >Direct: 503 276-7661
>> >Mobile: 360 471-7815
>> >
>> >TRIPWIRE | Take CONTROL
>> >http://www.tripwire.com
>> >
>> >
>> >
>> >
>> >
>> >
>> >_______________________________________________
>> >mile mailing list
>> >mile@ietf.org
>> >https://www.ietf.org/mailman/listinfo/mile
>> >
>>=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 kathleen.moriarty@emc.com  Mon Apr 23 16:56:39 2012
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 9129621F86EA for ; Mon, 23 Apr 2012 16:56:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.516
X-Spam-Level: 
X-Spam-Status: No, score=-10.516 tagged_above=-999 required=5 tests=[AWL=0.083, 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 1pKH1u12NGWK for ; Mon, 23 Apr 2012 16:56:38 -0700 (PDT)
Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 2F0E321F86E8 for ; Mon, 23 Apr 2012 16:56:37 -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 q3NNuapt002795 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Apr 2012 19:56:37 -0400
Received: from mailhub.lss.emc.com (mailhubhoprd03.lss.emc.com [10.254.221.145]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Mon, 23 Apr 2012 19:56:16 -0400
Received: from mxhub23.corp.emc.com (mxhub23.corp.emc.com [128.222.70.135]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q3NNuFZC010974; Mon, 23 Apr 2012 19:56:16 -0400
Received: from mx06a.corp.emc.com ([169.254.1.106]) by mxhub23.corp.emc.com ([128.222.70.135]) with mapi; Mon, 23 Apr 2012 19:56:15 -0400
From: 
To: , , 
Date: Mon, 23 Apr 2012 19:56:14 -0400
Thread-Topic: [mile] IODEF Reference Format for Enumerations
Thread-Index: AQHNFn/rimqKx0bIq0Wznd3Jbi9osJaXhxIAgAACw5CABhkuAIALdSAAgAATKtA=
Message-ID: 
References: <001701cd1bad$5608c580$021a5080$@nict.go.jp> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EMM-MHVC: 1
Subject: Re: [mile] IODEF Reference Format for Enumerations
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, 23 Apr 2012 23:56:39 -0000

Take, Adam, and MILE members,

Thanks for hashing out ideas on the list.  I think we need to make sure tha=
t we have one approach for including enumerated values consistently to ensu=
re interoperability and one approach to include additional content via anot=
her XML document.  If it makes the most sense to add a field to IODEF for o=
ption 3, we should figure that out so enumerated values do not require an e=
xtension.  Or determine if either option 1 or 2 makes the most sense to hav=
e enumerated values represented in the base IODEF document.

Any other opinions?

Thank you!
Kathleen

-----Original Message-----
From: Adam Montville [mailto:amontville@tripwire.com]=20
Sent: Monday, April 23, 2012 6:44 PM
To: Takeshi Takahashi; Moriarty, Kathleen; mile@ietf.org
Subject: Re: [mile] IODEF Reference Format for Enumerations

Take,

Do you think it would make any sense to combine the two approaches?
Option 3 could be rewritten to be more aligned with the
 example you provided.


  id
  http://www.example.com/path
  http://www.otherexample.com/path
  Description



Or, perhaps the class information could be referenced in an IANA table in
a manner consistent with Options 1 and 2...  So, if there's a registryId,
then some semantic information about the types of classes accepted by that
registryId could be discovered.

Any thoughts from the list about this general approach?

Adam

On 4/16/12 1:45 AM, "Takeshi Takahashi" 
wrote:

>Hi all,
>
>If we are going to update option 3, that would be one direction.
>
>IMHO, the option 3 is very close to the expected use of the Vulnerability
>class of SCI draft. (and some other classes as well)
>The expected usage of the Vulnerability class of current SCI draft, with
>CVE
>identifier, is as follows.
>
>VulnerabilityID=3D"CVE-2010-3654"/>
>
>The slight difference between the SCI draft and the option 3 is that the
>SCI
>draft took a semantic approach (vulnerability, attackpattern, etc.), while
>the option three takes general container approach.
>The URLs to the information of the specification (in this case CVE 1.0)
>are
>described in the IANA table in case of the SCI draft approach.
>
>I think both approach is viable, but proper description on how to choose
>either of the approaches could be helpful for readers.
>
>Thank you.
>Take
>
>> -----Original Message-----
>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of
>> kathleen.moriarty@emc.com
>> Sent: Friday, April 13, 2012 3:56 AM
>> To: amontville@tripwire.com; mile@ietf.org
>> Subject: Re: [mile] IODEF Reference Format for Enumerations
>>=20
>> Hi Adam,
>>=20
>> Thank you for running the list of options by the WG and to those
>> participating in the decision process!
>>=20
>> We have had a couple of reasons discussed to 'open' up IODEF.  If we get
>> a volunteer to help with the editing of an RFC5070 soon, then option 3
>> may be worth considering.  I would expect that a revision to RFC5070
>>would
>> take some time as the list works through issues and options.
>>=20
>> What do others think about this and Adam's other questions?
>>=20
>> Thanks,
>> Kathleen
>>=20
>> -----Original Message-----
>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of
>> Adam Montville
>> Sent: Thursday, April 12, 2012 2:28 PM
>> To: Adam Montville; mile@ietf.org
>> Subject: Re: [mile] IODEF Reference Format for Enumerations
>>=20
>> All:
>>=20
>> So far, it seems as though more people are speaking up in favor of
>>Option
>> 2.  There are also several comments expressing a desire to choose either
>> Option 1 or Option 2, but then move to Option 3 at some point in the
>future.
>> I'd like to understand more about what that really means - choosing one
>> option and then moving to another.
>>=20
>> Would it make more sense to wait until IODEF is "opened" for an update
>> to address this issue?
>>=20
>> For those of you who prefer Option 1 or Option 2, but have not indicated
>> a preference with respect to later moving to Option 3, do you have an
>> opinion about such a move?
>>=20
>> David Black has put forward some additional insight where, "if Option
>> 1 is chosen, the result is a common means of referencing specifications
>> between the SCI draft and the new draft on use of the IODEF reference
>> format."
>> This statement references the notion of requiring the first URL of on
>> IODEF  element (associated with the ) to be
>> a reference URI from the IANA registry established by the SCI draft.
>>=20
>> It would seem, then, that we have deterministic methods of understanding
>> what a  is, and thus how to parse it, but that we have
>> several different mechanisms by which to accomplish this.
>>=20
>> Comments? Opinions?
>>=20
>> Regards,
>>=20
>> Adam
>>=20
>> On 4/9/12 11:38 AM, "Adam Montville"  wrote:
>>=20
>> >All:
>> >
>> >There is an identified need to specify a format to include relevant
>> >enumeration values in an IODEF document.  The initial idea is to place
>> >enumeration values and their references in IODEF's Reference class.
>> >There are several ways to accomplish this goal.  I'll do my best to
>> >enumerate some options here, then I hope to hear some feedback/opinions
>> >about the different approaches from the list.
>> >
>> >From the Structured Cybersecurity Information draft
>> >(draft-takahashi-mile-sci-02), we may be interested to include the
>> >following (not an inclusive list) enumerations in an IODEF document:
>> >CAPEC, CCE, CPE, CVE, CWE, IEC 19770-2.
>> >
>> >The IODEF Reference class is described in 3.9.1 of RFC 5070, where a
>> >Reference must have a ReferenceName and zero or more of URL or
>> >Description respectively.
>> >
>> >For each option described below, we can consider use of the IANA
>registry.
>> >The registry may be used to identify the identifier category and
>> >potentially the appropriate identification format for that category.
>> >
>> >
>> >Option 1: Simple ID
>> >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> >The first option would simply embed the relevant identifier in the
>> >ReferenceName element of the Reference class.  This may look like the
>> >following:
>> >
>> >    
>> >        id
>> >        http://www.example.com/path
>> >        http://www.otherexample.com/path
>> >        Description
>> >    
>> >
>> >Using this option, a variety of specific identifier formats could be
>> >specified.  CVE, for example, would start with "CVE-" and this
>> >convention may be registered in an IANA table.
>> >
>> >No changes to IODEF are required for this option.
>> >
>> >
>> >
>> >Option 2: ID with coupled ID type
>> >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> >The second option would prepend the identifier with it's type, which
>> >may look something like the following.
>> >
>> >    
>> >        id_type:id
>> >        http://www.example.com/path
>> >        http://www.otherexample.com/path
>> >        Description
>> >    
>> >
>> >Using this option, a variety of specific identifier types could be
>> >specified, such that the identifier itself would not necessarily be
>> >constrained, nor would new identifier formats necessarily need to be
>> >specified in the future.  An IANA table may be used for this solution
>> >as well.
>> >
>> >No changes to IODEF would be required for this option.
>> >
>> >
>> >
>> >Option 3: ID with type expressed in Reference attribute
>> >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D
>> >The third option would require opening IODEF to update the Reference
>> >class with an attribute, which may look something like the following.
>> >
>> >    
>> >        id
>> >        http://www.example.com/path
>> >        http://www.otherexample.com/path
>> >        Description
>> >    
>> >
>> >
>> >
>> >Changes to IODEF are required for this option.
>> >
>> >
>> >----
>> >
>> >I look forward to fielding responses to these options, including any
>> >additional options you may see, but which are not listed.
>> >
>> >What is your solution preference?
>> >
>> >
>> >Regards,
>> >
>> >Adam W. Montville | Security and Compliance Architect
>> >
>> >Direct: 503 276-7661
>> >Mobile: 360 471-7815
>> >
>> >TRIPWIRE | Take CONTROL
>> >http://www.tripwire.com
>> >
>> >
>> >
>> >
>> >
>> >
>> >_______________________________________________
>> >mile mailing list
>> >mile@ietf.org
>> >https://www.ietf.org/mailman/listinfo/mile
>> >
>>=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 takeshi_takahashi@nict.go.jp  Mon Apr 23 17:56:29 2012
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 AD5D921F86E1 for ; Mon, 23 Apr 2012 17:56:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.864
X-Spam-Level: 
X-Spam-Status: No, score=-0.864 tagged_above=-999 required=5 tests=[AWL=0.491,  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 SefSS0rYJQP9 for ; Mon, 23 Apr 2012 17:56:28 -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 D2DC521F86A8 for ; Mon, 23 Apr 2012 17:56:16 -0700 (PDT)
Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp  with ESMTP id q3O0u8Jl026077; Tue, 24 Apr 2012 09:56:08 +0900 (JST)
Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp  with ESMTP id q3O0u8Si027044; Tue, 24 Apr 2012 09:56:08 +0900 (JST)
Received: from takeVAIO2 (ssh.nict.go.jp [133.243.3.49]) by gw1.nict.go.jp  with ESMTP id q3O0u8XV027041; Tue, 24 Apr 2012 09:56:08 +0900 (JST)
From: "Takeshi Takahashi" 
To: "'Adam Montville'" , ,  
References: <001701cd1bad$5608c580$021a5080$@nict.go.jp> 
In-Reply-To: 
Date: Tue, 24 Apr 2012 09:56:07 +0900
Message-ID: <009601cd21b5$08697aa0$193c6fe0$@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: AQH7qlpEwLVq9NcaZT77w/hMO1S9iJZMEHSA
Content-Language: ja
Subject: Re: [mile] IODEF Reference Format for Enumerations
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, 24 Apr 2012 00:56:29 -0000

Adam,

If modifying IODEF is allowed, I do not see any point to define classes
under AdditionalData class (as SCI draft does) since it makes the XML
longer.

Since the new Option 3 and the sci draft are not that different, it would be
fine for me to combine them into one.
Sci draft defines several containers for each semantics, and positioned them
under AdditionalData class, while new Option 3 defines one container with
semantic information that requires no additionalData class.
(I wonder whether we really need the semantics or not if we use the option 3
approach, since the location of the Reference class inside IODEF document
indicates the semantics.)

If Option 3 could cover the rest of the classes including the ones that do
not have any ID yet, I think it is reasonable to merge the works into one.
I do not see any point to have two drafts for similar issues.
That will just confuse users.

The remaining issues for the SCI draft were as follows in my understanding
1. "namespace identifying specification" needs to be confirmed
2. copyright issues needs to be clarified
3. schema needs to be reviewed

The merged work will inherit the above issues, and I am happy if you could
lead the work.
How does that sound to everybody?

Sincerey,
Take


> -----Original Message-----
> From: Adam Montville [mailto:amontville@tripwire.com]
> Sent: Tuesday, April 24, 2012 7:44 AM
> To: Takeshi Takahashi; kathleen.moriarty@emc.com; mile@ietf.org
> Subject: Re: [mile] IODEF Reference Format for Enumerations
> 
> Take,
> 
> Do you think it would make any sense to combine the two approaches?
> Option 3 could be rewritten to be more aligned with the
>  example you provided.
> 
> 
>   id
>   http://www.example.com/path
>   http://www.otherexample.com/path
>   Description
> 
> 
> 
> Or, perhaps the class information could be referenced in an IANA table
> in a manner consistent with Options 1 and 2...  So, if there's a
registryId,
> then some semantic information about the types of classes accepted by
> that registryId could be discovered.
> 
> Any thoughts from the list about this general approach?
> 
> Adam
> 
> On 4/16/12 1:45 AM, "Takeshi Takahashi" 
> wrote:
> 
> >Hi all,
> >
> >If we are going to update option 3, that would be one direction.
> >
> >IMHO, the option 3 is very close to the expected use of the
> >Vulnerability class of SCI draft. (and some other classes as well) The
> >expected usage of the Vulnerability class of current SCI draft, with
> >CVE identifier, is as follows.
> >
> > SpecID="http://cve.mitre.org/cve/downloads/1.0"
> >VulnerabilityID="CVE-2010-3654"/>
> >
> >The slight difference between the SCI draft and the option 3 is that
> >the SCI draft took a semantic approach (vulnerability, attackpattern,
> >etc.), while the option three takes general container approach.
> >The URLs to the information of the specification (in this case CVE 1.0)
> >are described in the IANA table in case of the SCI draft approach.
> >
> >I think both approach is viable, but proper description on how to
> >choose either of the approaches could be helpful for readers.
> >
> >Thank you.
> >Take
> >
> >> -----Original Message-----
> >> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf
> >> Of kathleen.moriarty@emc.com
> >> Sent: Friday, April 13, 2012 3:56 AM
> >> To: amontville@tripwire.com; mile@ietf.org
> >> Subject: Re: [mile] IODEF Reference Format for Enumerations
> >>
> >> Hi Adam,
> >>
> >> Thank you for running the list of options by the WG and to those
> >> participating in the decision process!
> >>
> >> We have had a couple of reasons discussed to 'open' up IODEF.  If we
> >>get  a volunteer to help with the editing of an RFC5070 soon, then
> >>option 3  may be worth considering.  I would expect that a revision
> to
> >>RFC5070 would  take some time as the list works through issues and
> >>options.
> >>
> >> What do others think about this and Adam's other questions?
> >>
> >> Thanks,
> >> Kathleen
> >>
> >> -----Original Message-----
> >> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf
> >> Of Adam Montville
> >> Sent: Thursday, April 12, 2012 2:28 PM
> >> To: Adam Montville; mile@ietf.org
> >> Subject: Re: [mile] IODEF Reference Format for Enumerations
> >>
> >> All:
> >>
> >> So far, it seems as though more people are speaking up in favor of
> >>Option  2.  There are also several comments expressing a desire to
> >>choose either  Option 1 or Option 2, but then move to Option 3 at some
> >>point in the
> >future.
> >> I'd like to understand more about what that really means - choosing
> >> one option and then moving to another.
> >>
> >> Would it make more sense to wait until IODEF is "opened" for an
> >> update to address this issue?
> >>
> >> For those of you who prefer Option 1 or Option 2, but have not
> >> indicated a preference with respect to later moving to Option 3, do
> >> you have an opinion about such a move?
> >>
> >> David Black has put forward some additional insight where, "if Option
> >> 1 is chosen, the result is a common means of referencing
> >> specifications between the SCI draft and the new draft on use of the
> >> IODEF reference format."
> >> This statement references the notion of requiring the first URL of
> on
> >> IODEF  element (associated with the ) to
> be
> >> a reference URI from the IANA registry established by the SCI draft.
> >>
> >> It would seem, then, that we have deterministic methods of
> >> understanding what a  is, and thus how to parse it,
> >> but that we have several different mechanisms by which to accomplish
> this.
> >>
> >> Comments? Opinions?
> >>
> >> Regards,
> >>
> >> Adam
> >>
> >> On 4/9/12 11:38 AM, "Adam Montville"  wrote:
> >>
> >> >All:
> >> >
> >> >There is an identified need to specify a format to include relevant
> >> >enumeration values in an IODEF document.  The initial idea is to
> >> >place enumeration values and their references in IODEF's Reference
> class.
> >> >There are several ways to accomplish this goal.  I'll do my best to
> >> >enumerate some options here, then I hope to hear some
> >> >feedback/opinions about the different approaches from the list.
> >> >
> >> >From the Structured Cybersecurity Information draft
> >> >(draft-takahashi-mile-sci-02), we may be interested to include the
> >> >following (not an inclusive list) enumerations in an IODEF document:
> >> >CAPEC, CCE, CPE, CVE, CWE, IEC 19770-2.
> >> >
> >> >The IODEF Reference class is described in 3.9.1 of RFC 5070, where
> a
> >> >Reference must have a ReferenceName and zero or more of URL or
> >> >Description respectively.
> >> >
> >> >For each option described below, we can consider use of the IANA
> >registry.
> >> >The registry may be used to identify the identifier category and
> >> >potentially the appropriate identification format for that category.
> >> >
> >> >
> >> >Option 1: Simple ID
> >> >===================
> >> >The first option would simply embed the relevant identifier in the
> >> >ReferenceName element of the Reference class.  This may look like
> >> >the
> >> >following:
> >> >
> >> >    
> >> >        id
> >> >        http://www.example.com/path
> >> >        http://www.otherexample.com/path
> >> >        Description
> >> >    
> >> >
> >> >Using this option, a variety of specific identifier formats could
> be
> >> >specified.  CVE, for example, would start with "CVE-" and this
> >> >convention may be registered in an IANA table.
> >> >
> >> >No changes to IODEF are required for this option.
> >> >
> >> >
> >> >
> >> >Option 2: ID with coupled ID type
> >> >=================================
> >> >The second option would prepend the identifier with it's type, which
> >> >may look something like the following.
> >> >
> >> >    
> >> >        id_type:id
> >> >        http://www.example.com/path
> >> >        http://www.otherexample.com/path
> >> >        Description
> >> >    
> >> >
> >> >Using this option, a variety of specific identifier types could be
> >> >specified, such that the identifier itself would not necessarily be
> >> >constrained, nor would new identifier formats necessarily need to
> be
> >> >specified in the future.  An IANA table may be used for this
> >> >solution as well.
> >> >
> >> >No changes to IODEF would be required for this option.
> >> >
> >> >
> >> >
> >> >Option 3: ID with type expressed in Reference attribute
> >> >=======================================================
> >> >The third option would require opening IODEF to update the Reference
> >> >class with an attribute, which may look something like the following.
> >> >
> >> >    
> >> >        id
> >> >        http://www.example.com/path
> >> >        http://www.otherexample.com/path
> >> >        Description
> >> >    
> >> >
> >> >
> >> >
> >> >Changes to IODEF are required for this option.
> >> >
> >> >
> >> >----
> >> >
> >> >I look forward to fielding responses to these options, including any
> >> >additional options you may see, but which are not listed.
> >> >
> >> >What is your solution preference?
> >> >
> >> >
> >> >Regards,
> >> >
> >> >Adam W. Montville | Security and Compliance Architect
> >> >
> >> >Direct: 503 276-7661
> >> >Mobile: 360 471-7815
> >> >
> >> >TRIPWIRE | Take CONTROL
> >> >http://www.tripwire.com
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >_______________________________________________
> >> >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 takeshi_takahashi@nict.go.jp  Mon Apr 23 18:00:09 2012
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 AE40521F8707 for ; Mon, 23 Apr 2012 18:00:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.962
X-Spam-Level: 
X-Spam-Status: No, score=-0.962 tagged_above=-999 required=5 tests=[AWL=0.393,  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 7WZBBdpGgYTK for ; Mon, 23 Apr 2012 18:00:08 -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 5E52F21F870B for ; Mon, 23 Apr 2012 18:00:08 -0700 (PDT)
Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp  with ESMTP id q3O103oa026431; Tue, 24 Apr 2012 10:00:03 +0900 (JST)
Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp  with ESMTP id q3O1036w027908; Tue, 24 Apr 2012 10:00:03 +0900 (JST)
Received: from takeVAIO2 (ssh.nict.go.jp [133.243.3.49]) by gw1.nict.go.jp  with ESMTP id q3O103RP027904; Tue, 24 Apr 2012 10:00:03 +0900 (JST)
From: "Takeshi Takahashi" 
To: "'Adam Montville'" , ,  
References: <001701cd1bad$5608c580$021a5080$@nict.go.jp>  
In-Reply-To: 
Date: Tue, 24 Apr 2012 10:00:02 +0900
Message-ID: <009701cd21b5$94967d20$bdc37760$@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: AQH7qlpEwLVq9NcaZT77w/hMO1S9iJZMEHSAgAAFVeA=
Content-Language: ja
Subject: Re: [mile] IODEF Reference Format for Enumerations
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, 24 Apr 2012 01:00:09 -0000

Let me rewrite the sentence:

> If Option 3 could cover the rest of the classes including the ones that
> do not have any ID yet, I think it is reasonable to merge the works into
> one.

If Option 3 could cover all the classes (not only the vulnerability class
but also the other classes), some of which supports XML without any IDs, I
think it is reasonable to merge the works into one.
I believe the Reference class can support them with proper extension.

Sincerely,
Take



> -----Original Message-----
> From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp]
> Sent: Tuesday, April 24, 2012 9:56 AM
> To: 'Adam Montville'; 'kathleen.moriarty@emc.com'; 'mile@ietf.org'
> Subject: RE: [mile] IODEF Reference Format for Enumerations
> 
> Adam,
> 
> If modifying IODEF is allowed, I do not see any point to define classes
> under AdditionalData class (as SCI draft does) since it makes the XML
> longer.
> 
> Since the new Option 3 and the sci draft are not that different, it would
> be fine for me to combine them into one.
> Sci draft defines several containers for each semantics, and positioned
> them under AdditionalData class, while new Option 3 defines one container
> with semantic information that requires no additionalData class.
> (I wonder whether we really need the semantics or not if we use the option
> 3 approach, since the location of the Reference class inside IODEF
> document indicates the semantics.)
> 
> If Option 3 could cover the rest of the classes including the ones that
> do not have any ID yet, I think it is reasonable to merge the works into
> one.
> I do not see any point to have two drafts for similar issues.
> That will just confuse users.
> 
> The remaining issues for the SCI draft were as follows in my understanding
> 1. "namespace identifying specification" needs to be confirmed 2.
> copyright issues needs to be clarified 3. schema needs to be reviewed
> 
> The merged work will inherit the above issues, and I am happy if you could
> lead the work.
> How does that sound to everybody?
> 
> Sincerey,
> Take
> 
> 
> > -----Original Message-----
> > From: Adam Montville [mailto:amontville@tripwire.com]
> > Sent: Tuesday, April 24, 2012 7:44 AM
> > To: Takeshi Takahashi; kathleen.moriarty@emc.com; mile@ietf.org
> > Subject: Re: [mile] IODEF Reference Format for Enumerations
> >
> > Take,
> >
> > Do you think it would make any sense to combine the two approaches?
> > Option 3 could be rewritten to be more aligned with the
> >  example you provided.
> >
> > 
> >   id
> >   http://www.example.com/path
> >   http://www.otherexample.com/path
> >   Description
> > 
> >
> >
> > Or, perhaps the class information could be referenced in an IANA table
> > in a manner consistent with Options 1 and 2...  So, if there's a
> > registryId, then some semantic information about the types of classes
> > accepted by that registryId could be discovered.
> >
> > Any thoughts from the list about this general approach?
> >
> > Adam
> >
> > On 4/16/12 1:45 AM, "Takeshi Takahashi" 
> > wrote:
> >
> > >Hi all,
> > >
> > >If we are going to update option 3, that would be one direction.
> > >
> > >IMHO, the option 3 is very close to the expected use of the
> > >Vulnerability class of SCI draft. (and some other classes as well)
> > >The expected usage of the Vulnerability class of current SCI draft,
> > >with CVE identifier, is as follows.
> > >
> > > > SpecID="http://cve.mitre.org/cve/downloads/1.0"
> > >VulnerabilityID="CVE-2010-3654"/>
> > >
> > >The slight difference between the SCI draft and the option 3 is that
> > >the SCI draft took a semantic approach (vulnerability, attackpattern,
> > >etc.), while the option three takes general container approach.
> > >The URLs to the information of the specification (in this case CVE
> > >1.0) are described in the IANA table in case of the SCI draft approach.
> > >
> > >I think both approach is viable, but proper description on how to
> > >choose either of the approaches could be helpful for readers.
> > >
> > >Thank you.
> > >Take
> > >
> > >> -----Original Message-----
> > >> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On
> > >> Behalf Of kathleen.moriarty@emc.com
> > >> Sent: Friday, April 13, 2012 3:56 AM
> > >> To: amontville@tripwire.com; mile@ietf.org
> > >> Subject: Re: [mile] IODEF Reference Format for Enumerations
> > >>
> > >> Hi Adam,
> > >>
> > >> Thank you for running the list of options by the WG and to those
> > >> participating in the decision process!
> > >>
> > >> We have had a couple of reasons discussed to 'open' up IODEF.  If
> > >>we get  a volunteer to help with the editing of an RFC5070 soon,
> > >>then option 3  may be worth considering.  I would expect that a
> > >>revision
> > to
> > >>RFC5070 would  take some time as the list works through issues and
> > >>options.
> > >>
> > >> What do others think about this and Adam's other questions?
> > >>
> > >> Thanks,
> > >> Kathleen
> > >>
> > >> -----Original Message-----
> > >> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On
> > >> Behalf Of Adam Montville
> > >> Sent: Thursday, April 12, 2012 2:28 PM
> > >> To: Adam Montville; mile@ietf.org
> > >> Subject: Re: [mile] IODEF Reference Format for Enumerations
> > >>
> > >> All:
> > >>
> > >> So far, it seems as though more people are speaking up in favor of
> > >>Option  2.  There are also several comments expressing a desire to
> > >>choose either  Option 1 or Option 2, but then move to Option 3 at
> > >>some point in the
> > >future.
> > >> I'd like to understand more about what that really means - choosing
> > >> one option and then moving to another.
> > >>
> > >> Would it make more sense to wait until IODEF is "opened" for an
> > >> update to address this issue?
> > >>
> > >> For those of you who prefer Option 1 or Option 2, but have not
> > >> indicated a preference with respect to later moving to Option 3,
> do
> > >> you have an opinion about such a move?
> > >>
> > >> David Black has put forward some additional insight where, "if
> > >> Option
> > >> 1 is chosen, the result is a common means of referencing
> > >> specifications between the SCI draft and the new draft on use of
> > >> the IODEF reference format."
> > >> This statement references the notion of requiring the first URL of
> > on
> > >> IODEF  element (associated with the ) to
> > be
> > >> a reference URI from the IANA registry established by the SCI draft.
> > >>
> > >> It would seem, then, that we have deterministic methods of
> > >> understanding what a  is, and thus how to parse it,
> > >> but that we have several different mechanisms by which to
> > >> accomplish
> > this.
> > >>
> > >> Comments? Opinions?
> > >>
> > >> Regards,
> > >>
> > >> Adam
> > >>
> > >> On 4/9/12 11:38 AM, "Adam Montville" 
> wrote:
> > >>
> > >> >All:
> > >> >
> > >> >There is an identified need to specify a format to include
> > >> >relevant enumeration values in an IODEF document.  The initial
> > >> >idea is to place enumeration values and their references in
> > >> >IODEF's Reference
> > class.
> > >> >There are several ways to accomplish this goal.  I'll do my best
> > >> >to enumerate some options here, then I hope to hear some
> > >> >feedback/opinions about the different approaches from the list.
> > >> >
> > >> >From the Structured Cybersecurity Information draft
> > >> >(draft-takahashi-mile-sci-02), we may be interested to include the
> > >> >following (not an inclusive list) enumerations in an IODEF document:
> > >> >CAPEC, CCE, CPE, CVE, CWE, IEC 19770-2.
> > >> >
> > >> >The IODEF Reference class is described in 3.9.1 of RFC 5070, where
> > a
> > >> >Reference must have a ReferenceName and zero or more of URL or
> > >> >Description respectively.
> > >> >
> > >> >For each option described below, we can consider use of the IANA
> > >registry.
> > >> >The registry may be used to identify the identifier category and
> > >> >potentially the appropriate identification format for that
> category.
> > >> >
> > >> >
> > >> >Option 1: Simple ID
> > >> >===================
> > >> >The first option would simply embed the relevant identifier in the
> > >> >ReferenceName element of the Reference class.  This may look like
> > >> >the
> > >> >following:
> > >> >
> > >> >    
> > >> >        id
> > >> >        http://www.example.com/path
> > >> >        http://www.otherexample.com/path
> > >> >        Description
> > >> >    
> > >> >
> > >> >Using this option, a variety of specific identifier formats could
> > be
> > >> >specified.  CVE, for example, would start with "CVE-" and this
> > >> >convention may be registered in an IANA table.
> > >> >
> > >> >No changes to IODEF are required for this option.
> > >> >
> > >> >
> > >> >
> > >> >Option 2: ID with coupled ID type
> > >> >=================================
> > >> >The second option would prepend the identifier with it's type,
> > >> >which may look something like the following.
> > >> >
> > >> >    
> > >> >        id_type:id
> > >> >        http://www.example.com/path
> > >> >        http://www.otherexample.com/path
> > >> >        Description
> > >> >    
> > >> >
> > >> >Using this option, a variety of specific identifier types could
> be
> > >> >specified, such that the identifier itself would not necessarily
> > >> >be constrained, nor would new identifier formats necessarily need
> > >> >to
> > be
> > >> >specified in the future.  An IANA table may be used for this
> > >> >solution as well.
> > >> >
> > >> >No changes to IODEF would be required for this option.
> > >> >
> > >> >
> > >> >
> > >> >Option 3: ID with type expressed in Reference attribute
> > >> >=======================================================
> > >> >The third option would require opening IODEF to update the
> > >> >Reference class with an attribute, which may look something like
> the following.
> > >> >
> > >> >    
> > >> >        id
> > >> >        http://www.example.com/path
> > >> >        http://www.otherexample.com/path
> > >> >        Description
> > >> >    
> > >> >
> > >> >
> > >> >
> > >> >Changes to IODEF are required for this option.
> > >> >
> > >> >
> > >> >----
> > >> >
> > >> >I look forward to fielding responses to these options, including
> > >> >any additional options you may see, but which are not listed.
> > >> >
> > >> >What is your solution preference?
> > >> >
> > >> >
> > >> >Regards,
> > >> >
> > >> >Adam W. Montville | Security and Compliance Architect
> > >> >
> > >> >Direct: 503 276-7661
> > >> >Mobile: 360 471-7815
> > >> >
> > >> >TRIPWIRE | Take CONTROL
> > >> >http://www.tripwire.com
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >_______________________________________________
> > >> >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 24 06:52:39 2012
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 F186821F87A2 for ; Tue, 24 Apr 2012 06:52:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.523
X-Spam-Level: 
X-Spam-Status: No, score=-10.523 tagged_above=-999 required=5 tests=[AWL=0.076, 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 B+ajvniIcO9T for ; Tue, 24 Apr 2012 06:52:38 -0700 (PDT)
Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 1E70D21F876E for ; Tue, 24 Apr 2012 06:52:36 -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 q3ODqWLD012583 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 24 Apr 2012 09:52:34 -0400
Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.253]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor) for ; Tue, 24 Apr 2012 09:52:12 -0400
Received: from mxhub09.corp.emc.com (mxhub09.corp.emc.com [10.254.92.104]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q3ODqCnw032458 for ; Tue, 24 Apr 2012 09:52:12 -0400
Received: from mx06a.corp.emc.com ([169.254.1.106]) by mxhub09.corp.emc.com ([10.254.92.104]) with mapi; Tue, 24 Apr 2012 09:52:12 -0400
From: 
To: 
Date: Tue, 24 Apr 2012 09:52:11 -0400
Thread-Topic: IETF Document that may be of interest
Thread-Index: Ac0iIXJLh3rBOtGnQC28l0Ec5llOxg==
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EMM-MHVC: 1
Subject: [mile] IETF Document that may be of interest
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, 24 Apr 2012 13:52:40 -0000

Hello,

I read through the following individual submission and thought it would be =
of interest to those exchanging information on mail incidents.  The draft i=
ncludes a very useful section to those exchanging indicator information to =
create 'greylists' for mail abuse, including the most helpful fields from o=
perator experience in detecting and blocking traffic for mail.

The exchange of this information should be possible with IODEF + RFC5901, b=
ut I have not had the time to dig into that yet.  Another option to represe=
nt the data might be through IODEF + the proposed MARF extension.  This doc=
ument is in last call, so it should be published fairly soon as an RFC.

https://datatracker.ietf.org/doc/draft-ietf-appsawg-greylisting/?include_te=
xt=3D1

Best regards,
Kathleen

Kathleen M. Moriarty, CISSP | GRC Strategy | Office of the CTO | 617-851-58=
07 | Kathleen.Moriarty@emc.com  | EMC Corporation




From kathleen.moriarty@emc.com  Thu Apr 26 05:48:49 2012
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 8CA7021F87FD for ; Thu, 26 Apr 2012 05:48:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.53
X-Spam-Level: 
X-Spam-Status: No, score=-10.53 tagged_above=-999 required=5 tests=[AWL=0.069,  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 HR1k6GF92eHp for ; Thu, 26 Apr 2012 05:48:48 -0700 (PDT)
Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 1478F21F8731 for ; Thu, 26 Apr 2012 05:48:47 -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 q3QCmkHG010271 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Apr 2012 08:48:46 -0400
Received: from mailhub.lss.emc.com (mailhubhoprd04.lss.emc.com [10.254.222.226]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Thu, 26 Apr 2012 08:48:30 -0400
Received: from mxhub19.corp.emc.com (mxhub19.corp.emc.com [10.254.93.48]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q3QCmTXY000516; Thu, 26 Apr 2012 08:48:30 -0400
Received: from mx06a.corp.emc.com ([169.254.1.106]) by mxhub19.corp.emc.com ([10.254.93.48]) with mapi; Thu, 26 Apr 2012 08:48:30 -0400
From: 
To: , , 
Date: Thu, 26 Apr 2012 08:48:28 -0400
Thread-Topic: [mile] IODEF Reference Format for Enumerations
Thread-Index: AQH7qlpEwLVq9NcaZT77w/hMO1S9iJZMEHSAgAAFVeCAA+oOoA==
Message-ID: 
References: <001701cd1bad$5608c580$021a5080$@nict.go.jp>  <009701cd21b5$94967d20$bdc37760$@nict.go.jp>
In-Reply-To: <009701cd21b5$94967d20$bdc37760$@nict.go.jp>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EMM-MHVC: 1
Subject: Re: [mile] IODEF Reference Format for Enumerations
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, 26 Apr 2012 12:48:49 -0000

Hi Take,

Can you explain more on how you see merging the two into one document?  The=
 only concern I have is that specifying the enumerations could be done with=
out including the MITRE specifications right into the document, so we *MAY*=
 not have to worry about the normative references (but I would need to conf=
irm that).

One advantage of one document over two would be one registry page for the t=
wo IANA tables.

This approach would mean that we would plan on an IODEF revision for at lea=
st a few small things.

How do you see the approach working and what are the thoughts of others on =
the list?

Thank you,
Kathleen

-----Original Message-----
From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp]=20
Sent: Monday, April 23, 2012 9:00 PM
To: 'Adam Montville'; Moriarty, Kathleen; mile@ietf.org
Subject: RE: [mile] IODEF Reference Format for Enumerations

Let me rewrite the sentence:

> If Option 3 could cover the rest of the classes including the ones that
> do not have any ID yet, I think it is reasonable to merge the works into
> one.

If Option 3 could cover all the classes (not only the vulnerability class
but also the other classes), some of which supports XML without any IDs, I
think it is reasonable to merge the works into one.
I believe the Reference class can support them with proper extension.

Sincerely,
Take



> -----Original Message-----
> From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp]
> Sent: Tuesday, April 24, 2012 9:56 AM
> To: 'Adam Montville'; 'kathleen.moriarty@emc.com'; 'mile@ietf.org'
> Subject: RE: [mile] IODEF Reference Format for Enumerations
>=20
> Adam,
>=20
> If modifying IODEF is allowed, I do not see any point to define classes
> under AdditionalData class (as SCI draft does) since it makes the XML
> longer.
>=20
> Since the new Option 3 and the sci draft are not that different, it would
> be fine for me to combine them into one.
> Sci draft defines several containers for each semantics, and positioned
> them under AdditionalData class, while new Option 3 defines one container
> with semantic information that requires no additionalData class.
> (I wonder whether we really need the semantics or not if we use the optio=
n
> 3 approach, since the location of the Reference class inside IODEF
> document indicates the semantics.)
>=20
> If Option 3 could cover the rest of the classes including the ones that
> do not have any ID yet, I think it is reasonable to merge the works into
> one.
> I do not see any point to have two drafts for similar issues.
> That will just confuse users.
>=20
> The remaining issues for the SCI draft were as follows in my understandin=
g
> 1. "namespace identifying specification" needs to be confirmed 2.
> copyright issues needs to be clarified 3. schema needs to be reviewed
>=20
> The merged work will inherit the above issues, and I am happy if you coul=
d
> lead the work.
> How does that sound to everybody?
>=20
> Sincerey,
> Take
>=20
>=20
> > -----Original Message-----
> > From: Adam Montville [mailto:amontville@tripwire.com]
> > Sent: Tuesday, April 24, 2012 7:44 AM
> > To: Takeshi Takahashi; kathleen.moriarty@emc.com; mile@ietf.org
> > Subject: Re: [mile] IODEF Reference Format for Enumerations
> >
> > Take,
> >
> > Do you think it would make any sense to combine the two approaches?
> > Option 3 could be rewritten to be more aligned with the
> >  example you provided.
> >
> > 
> >   id
> >   http://www.example.com/path
> >   http://www.otherexample.com/path
> >   Description
> > 
> >
> >
> > Or, perhaps the class information could be referenced in an IANA table
> > in a manner consistent with Options 1 and 2...  So, if there's a
> > registryId, then some semantic information about the types of classes
> > accepted by that registryId could be discovered.
> >
> > Any thoughts from the list about this general approach?
> >
> > Adam
> >
> > On 4/16/12 1:45 AM, "Takeshi Takahashi" 
> > wrote:
> >
> > >Hi all,
> > >
> > >If we are going to update option 3, that would be one direction.
> > >
> > >IMHO, the option 3 is very close to the expected use of the
> > >Vulnerability class of SCI draft. (and some other classes as well)
> > >The expected usage of the Vulnerability class of current SCI draft,
> > >with CVE identifier, is as follows.
> > >
> > > > SpecID=3D"http://cve.mitre.org/cve/downloads/1.0"
> > >VulnerabilityID=3D"CVE-2010-3654"/>
> > >
> > >The slight difference between the SCI draft and the option 3 is that
> > >the SCI draft took a semantic approach (vulnerability, attackpattern,
> > >etc.), while the option three takes general container approach.
> > >The URLs to the information of the specification (in this case CVE
> > >1.0) are described in the IANA table in case of the SCI draft approach=
.
> > >
> > >I think both approach is viable, but proper description on how to
> > >choose either of the approaches could be helpful for readers.
> > >
> > >Thank you.
> > >Take
> > >
> > >> -----Original Message-----
> > >> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On
> > >> Behalf Of kathleen.moriarty@emc.com
> > >> Sent: Friday, April 13, 2012 3:56 AM
> > >> To: amontville@tripwire.com; mile@ietf.org
> > >> Subject: Re: [mile] IODEF Reference Format for Enumerations
> > >>
> > >> Hi Adam,
> > >>
> > >> Thank you for running the list of options by the WG and to those
> > >> participating in the decision process!
> > >>
> > >> We have had a couple of reasons discussed to 'open' up IODEF.  If
> > >>we get  a volunteer to help with the editing of an RFC5070 soon,
> > >>then option 3  may be worth considering.  I would expect that a
> > >>revision
> > to
> > >>RFC5070 would  take some time as the list works through issues and
> > >>options.
> > >>
> > >> What do others think about this and Adam's other questions?
> > >>
> > >> Thanks,
> > >> Kathleen
> > >>
> > >> -----Original Message-----
> > >> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On
> > >> Behalf Of Adam Montville
> > >> Sent: Thursday, April 12, 2012 2:28 PM
> > >> To: Adam Montville; mile@ietf.org
> > >> Subject: Re: [mile] IODEF Reference Format for Enumerations
> > >>
> > >> All:
> > >>
> > >> So far, it seems as though more people are speaking up in favor of
> > >>Option  2.  There are also several comments expressing a desire to
> > >>choose either  Option 1 or Option 2, but then move to Option 3 at
> > >>some point in the
> > >future.
> > >> I'd like to understand more about what that really means - choosing
> > >> one option and then moving to another.
> > >>
> > >> Would it make more sense to wait until IODEF is "opened" for an
> > >> update to address this issue?
> > >>
> > >> For those of you who prefer Option 1 or Option 2, but have not
> > >> indicated a preference with respect to later moving to Option 3,
> do
> > >> you have an opinion about such a move?
> > >>
> > >> David Black has put forward some additional insight where, "if
> > >> Option
> > >> 1 is chosen, the result is a common means of referencing
> > >> specifications between the SCI draft and the new draft on use of
> > >> the IODEF reference format."
> > >> This statement references the notion of requiring the first URL of
> > on
> > >> IODEF  element (associated with the ) to
> > be
> > >> a reference URI from the IANA registry established by the SCI draft.
> > >>
> > >> It would seem, then, that we have deterministic methods of
> > >> understanding what a  is, and thus how to parse it,
> > >> but that we have several different mechanisms by which to
> > >> accomplish
> > this.
> > >>
> > >> Comments? Opinions?
> > >>
> > >> Regards,
> > >>
> > >> Adam
> > >>
> > >> On 4/9/12 11:38 AM, "Adam Montville" 
> wrote:
> > >>
> > >> >All:
> > >> >
> > >> >There is an identified need to specify a format to include
> > >> >relevant enumeration values in an IODEF document.  The initial
> > >> >idea is to place enumeration values and their references in
> > >> >IODEF's Reference
> > class.
> > >> >There are several ways to accomplish this goal.  I'll do my best
> > >> >to enumerate some options here, then I hope to hear some
> > >> >feedback/opinions about the different approaches from the list.
> > >> >
> > >> >From the Structured Cybersecurity Information draft
> > >> >(draft-takahashi-mile-sci-02), we may be interested to include the
> > >> >following (not an inclusive list) enumerations in an IODEF document=
:
> > >> >CAPEC, CCE, CPE, CVE, CWE, IEC 19770-2.
> > >> >
> > >> >The IODEF Reference class is described in 3.9.1 of RFC 5070, where
> > a
> > >> >Reference must have a ReferenceName and zero or more of URL or
> > >> >Description respectively.
> > >> >
> > >> >For each option described below, we can consider use of the IANA
> > >registry.
> > >> >The registry may be used to identify the identifier category and
> > >> >potentially the appropriate identification format for that
> category.
> > >> >
> > >> >
> > >> >Option 1: Simple ID
> > >> >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > >> >The first option would simply embed the relevant identifier in the
> > >> >ReferenceName element of the Reference class.  This may look like
> > >> >the
> > >> >following:
> > >> >
> > >> >    
> > >> >        id
> > >> >        http://www.example.com/path
> > >> >        http://www.otherexample.com/path
> > >> >        Description
> > >> >    
> > >> >
> > >> >Using this option, a variety of specific identifier formats could
> > be
> > >> >specified.  CVE, for example, would start with "CVE-" and this
> > >> >convention may be registered in an IANA table.
> > >> >
> > >> >No changes to IODEF are required for this option.
> > >> >
> > >> >
> > >> >
> > >> >Option 2: ID with coupled ID type
> > >> >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > >> >The second option would prepend the identifier with it's type,
> > >> >which may look something like the following.
> > >> >
> > >> >    
> > >> >        id_type:id
> > >> >        http://www.example.com/path
> > >> >        http://www.otherexample.com/path
> > >> >        Description
> > >> >    
> > >> >
> > >> >Using this option, a variety of specific identifier types could
> be
> > >> >specified, such that the identifier itself would not necessarily
> > >> >be constrained, nor would new identifier formats necessarily need
> > >> >to
> > be
> > >> >specified in the future.  An IANA table may be used for this
> > >> >solution as well.
> > >> >
> > >> >No changes to IODEF would be required for this option.
> > >> >
> > >> >
> > >> >
> > >> >Option 3: ID with type expressed in Reference attribute
> > >> >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D
> > >> >The third option would require opening IODEF to update the
> > >> >Reference class with an attribute, which may look something like
> the following.
> > >> >
> > >> >    
> > >> >        id
> > >> >        http://www.example.com/path
> > >> >        http://www.otherexample.com/path
> > >> >        Description
> > >> >    
> > >> >
> > >> >
> > >> >
> > >> >Changes to IODEF are required for this option.
> > >> >
> > >> >
> > >> >----
> > >> >
> > >> >I look forward to fielding responses to these options, including
> > >> >any additional options you may see, but which are not listed.
> > >> >
> > >> >What is your solution preference?
> > >> >
> > >> >
> > >> >Regards,
> > >> >
> > >> >Adam W. Montville | Security and Compliance Architect
> > >> >
> > >> >Direct: 503 276-7661
> > >> >Mobile: 360 471-7815
> > >> >
> > >> >TRIPWIRE | Take CONTROL
> > >> >http://www.tripwire.com
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >_______________________________________________
> > >> >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 turners@ieca.com  Thu Apr 26 08:26:42 2012
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 C7EB321E80B2 for ; Thu, 26 Apr 2012 08:26:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.139
X-Spam-Level: 
X-Spam-Status: No, score=-102.139 tagged_above=-999 required=5 tests=[AWL=0.125, 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 dk34RxYJ9L0J for ; Thu, 26 Apr 2012 08:26:42 -0700 (PDT)
Received: from gateway15.websitewelcome.com (gateway15.websitewelcome.com [69.93.35.7]) by ietfa.amsl.com (Postfix) with ESMTP id 0876C21E8028 for ; Thu, 26 Apr 2012 08:26:41 -0700 (PDT)
Received: by gateway15.websitewelcome.com (Postfix, from userid 5007) id 67A24434C4E4F; Thu, 26 Apr 2012 10:26:41 -0500 (CDT)
Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway15.websitewelcome.com (Postfix) with ESMTP id 5CFF0434C4E1A for ; Thu, 26 Apr 2012 10:26:41 -0500 (CDT)
Received: from [96.231.123.106] (port=45617 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1SNQaf-0008I2-2d for mile@ietf.org; Thu, 26 Apr 2012 10:26:41 -0500
Message-ID: <4F996930.1000400@ieca.com>
Date: Thu, 26 Apr 2012 11:26:40 -0400
From: Sean Turner 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: mile@ietf.org
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: pool-96-231-123-106.washdc.east.verizon.net (thunderfish.local) [96.231.123.106]:45617
X-Source-Auth: sean.turner@ieca.com
X-Email-Count: 6
X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20=
Subject: [mile] early AD review of mile-iodef-xmlreg
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, 26 Apr 2012 15:26:42 -0000

Just some nits that will undoubtedly result in some extended process 
discussion with IESGers:

1) Please add "Updates: 5070" to the header.  I think that somebody will 
claim we're changing the registry in RFC 5070 hence it's updating 5070. 
  If for some reason it goes the other way and somebody argues it's not 
updating 5070, having LCed something with an updates header and then 
removing it will probably avoid the question about whether another IETF 
LC is needed.

2) Add some text to the IANA consideration section that instructs them 
to point to this document in the reference column for the 
urn:ietf:params:xml:schema:iodef-1.0 row.  I'm sure IANA do this 
regardless, but recently some IESGers have had IANA considerations on 
the brain and it's better to be explicit about it.

spt

From turners@ieca.com  Thu Apr 26 08:28:45 2012
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 B834221E80B4 for ; Thu, 26 Apr 2012 08:28:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.144
X-Spam-Level: 
X-Spam-Status: No, score=-102.144 tagged_above=-999 required=5 tests=[AWL=0.121, 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 emVCynx-s19v for ; Thu, 26 Apr 2012 08:28:45 -0700 (PDT)
Received: from gateway12.websitewelcome.com (gateway12.websitewelcome.com [67.18.88.9]) by ietfa.amsl.com (Postfix) with ESMTP id 705C721E80B3 for ; Thu, 26 Apr 2012 08:28:45 -0700 (PDT)
Received: by gateway12.websitewelcome.com (Postfix, from userid 5007) id D4B7D46522292; Thu, 26 Apr 2012 10:28:44 -0500 (CDT)
Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway12.websitewelcome.com (Postfix) with ESMTP id C6EA14652226F for ; Thu, 26 Apr 2012 10:28:44 -0500 (CDT)
Received: from [96.231.123.106] (port=45586 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1SNQce-0000Tm-Ee for mile@ietf.org; Thu, 26 Apr 2012 10:28:44 -0500
Message-ID: <4F9969AB.5010503@ieca.com>
Date: Thu, 26 Apr 2012 11:28:43 -0400
From: Sean Turner 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: mile@ietf.org
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: pool-96-231-123-106.washdc.east.verizon.net (thunderfish.local) [96.231.123.106]:45586
X-Source-Auth: sean.turner@ieca.com
X-Email-Count: 7
X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20=
Subject: [mile] 6045/6046 congrats
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, 26 Apr 2012 15:28:45 -0000

A little late, but congrats to all involved for getting this done so 
efficiently!

spt

From turners@ieca.com  Thu Apr 26 10:13:16 2012
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 E98DF21E80F6 for ; Thu, 26 Apr 2012 10:13:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.278
X-Spam-Level: 
X-Spam-Status: No, score=-102.278 tagged_above=-999 required=5 tests=[AWL=-0.013, 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 KGpQaWlrCyDe for ; Thu, 26 Apr 2012 10:13:16 -0700 (PDT)
Received: from gateway09.websitewelcome.com (gateway09.websitewelcome.com [67.18.21.24]) by ietfa.amsl.com (Postfix) with ESMTP id 48D6021E80E3 for ; Thu, 26 Apr 2012 10:13:16 -0700 (PDT)
Received: by gateway09.websitewelcome.com (Postfix, from userid 507) id A2D40472FA1C6; Thu, 26 Apr 2012 12:13:15 -0500 (CDT)
Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway09.websitewelcome.com (Postfix) with ESMTP id 937F3472FA199 for ; Thu, 26 Apr 2012 12:13:15 -0500 (CDT)
Received: from [71.191.6.129] (port=35459 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1SNSFn-0004g5-4K for mile@ietf.org; Thu, 26 Apr 2012 12:13:15 -0500
Message-ID: <4F998229.9000307@ieca.com>
Date: Thu, 26 Apr 2012 13:13:13 -0400
From: Sean Turner 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: mile@ietf.org
References: <4F996930.1000400@ieca.com>
In-Reply-To: <4F996930.1000400@ieca.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: pool-71-191-6-129.washdc.east.verizon.net (thunderfish.local) [71.191.6.129]:35459
X-Source-Auth: sean.turner@ieca.com
X-Email-Count: 7
X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20=
Subject: Re: [mile] early AD review of mile-iodef-xmlreg
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, 26 Apr 2012 17:13:17 -0000

It's also just dawned on me that adding a second expert reviewer will 
cause some interesting issues with the registry.  I've cued the IANA 
folks about this so they'll be looking for it.  Here's the issue:

Right now you get to the XML namespaces/schemas through this page:
https://www.iana.org/protocols
Jari Urpalainen is listed as the XML schema expert reviewer
to get to the iodef schema use the schema link:
https://www.iana.org/assignments/xml-registry/schema.html
so now we'll have to add the IODEF Expert Reviewer somewhere in the 
iodef row and it'll need to be clear that the reviewer is not in lieu of 
Jari it's in addition to Jari.  It'll also needs to be clear that the 
IODEF expert reviewer is only reviewing for IODEF-correctness and that 
Jari gets the last word on the XML.  Not sure if we need conflict 
resolution text.

Again, this is just a heads up - nothing to do now.  I'm sure some 
wording will be needed in the IANA considerations section, but they'll 
help write it.

spt

PS - Sorry to expose all this process gunk to the WG, but I don't want 
anybody to be surprised later on.

On 4/26/12 11:26 AM, Sean Turner wrote:
> Just some nits that will undoubtedly result in some extended process
> discussion with IESGers:
>
> 1) Please add "Updates: 5070" to the header. I think that somebody will
> claim we're changing the registry in RFC 5070 hence it's updating 5070.
> If for some reason it goes the other way and somebody argues it's not
> updating 5070, having LCed something with an updates header and then
> removing it will probably avoid the question about whether another IETF
> LC is needed.
>
> 2) Add some text to the IANA consideration section that instructs them
> to point to this document in the reference column for the
> urn:ietf:params:xml:schema:iodef-1.0 row. I'm sure IANA do this
> regardless, but recently some IESGers have had IANA considerations on
> the brain and it's better to be explicit about it.
>
> spt
> _______________________________________________
> mile mailing list
> mile@ietf.org
> https://www.ietf.org/mailman/listinfo/mile
>

From kathleen.moriarty@emc.com  Thu Apr 26 10:20:05 2012
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 1096D21E8124 for ; Thu, 26 Apr 2012 10:20:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.535
X-Spam-Level: 
X-Spam-Status: No, score=-10.535 tagged_above=-999 required=5 tests=[AWL=0.064, 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 mcjvKbJS6JgH for ; Thu, 26 Apr 2012 10:20:04 -0700 (PDT)
Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 71B6921E8127 for ; Thu, 26 Apr 2012 10:20:04 -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 q3QHK1xg027029 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Apr 2012 13:20:02 -0400
Received: from mailhub.lss.emc.com (mailhubhoprd01.lss.emc.com [10.254.221.251]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Thu, 26 Apr 2012 13:19:45 -0400
Received: from mxhub26.corp.emc.com (mxhub26.corp.emc.com [10.254.110.182]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q3QHJh4F021374; Thu, 26 Apr 2012 13:19:44 -0400
Received: from mx06a.corp.emc.com ([169.254.1.106]) by mxhub26.corp.emc.com ([10.254.110.182]) with mapi; Thu, 26 Apr 2012 13:19:43 -0400
From: 
To: , 
Date: Thu, 26 Apr 2012 13:19:42 -0400
Thread-Topic: [mile] 6045/6046 congrats
Thread-Index: Ac0jwV1NUAzuE4jWQtSdzlS8a2tBDwAD0xVw
Message-ID: 
References: <4F9969AB.5010503@ieca.com>
In-Reply-To: <4F9969AB.5010503@ieca.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EMM-MHVC: 1
Subject: Re: [mile] 6045/6046 congrats
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, 26 Apr 2012 17:20:05 -0000

Thank you, Sean and the working group for all of your hard work in reviews =
and input to improve the standards!

Best regards,
Kathleen

-----Original Message-----
From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Sea=
n Turner
Sent: Thursday, April 26, 2012 11:29 AM
To: mile@ietf.org
Subject: [mile] 6045/6046 congrats

A little late, but congrats to all involved for getting this done so=20
efficiently!

spt
_______________________________________________
mile mailing list
mile@ietf.org
https://www.ietf.org/mailman/listinfo/mile


From turners@ieca.com  Thu Apr 26 12:19:19 2012
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 6D52C21E8140 for ; Thu, 26 Apr 2012 12:19:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.277
X-Spam-Level: 
X-Spam-Status: No, score=-102.277 tagged_above=-999 required=5 tests=[AWL=-0.012, 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 V0Dx9rk4L9-e for ; Thu, 26 Apr 2012 12:19:18 -0700 (PDT)
Received: from gateway16.websitewelcome.com (gateway16.websitewelcome.com [69.56.185.3]) by ietfa.amsl.com (Postfix) with ESMTP id 9946521E8152 for ; Thu, 26 Apr 2012 12:19:18 -0700 (PDT)
Received: by gateway16.websitewelcome.com (Postfix, from userid 5007) id 1EF9243497ACF; Thu, 26 Apr 2012 14:19:18 -0500 (CDT)
Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway16.websitewelcome.com (Postfix) with ESMTP id 08C8343497A73 for ; Thu, 26 Apr 2012 14:19:18 -0500 (CDT)
Received: from [71.191.6.129] (port=37715 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1SNUDl-0007VB-Fo for mile@ietf.org; Thu, 26 Apr 2012 14:19:17 -0500
Message-ID: <4F999FB4.5070403@ieca.com>
Date: Thu, 26 Apr 2012 15:19:16 -0400
From: Sean Turner 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: mile@ietf.org
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: pool-71-191-6-129.washdc.east.verizon.net (thunderfish.local) [71.191.6.129]:37715
X-Source-Auth: sean.turner@ieca.com
X-Email-Count: 1
X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20=
Subject: [mile] early AD-review of draft-ietf-mile-template
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, 26 Apr 2012 19:19:19 -0000

Here's my early AD-review.

spt

--------------

1) s1: r/a section Appendix A/a section (Appendix A)

2) s1: r/of an Internet-Draft/for an Internet-Draft

3) s2, bullet 1: Definition of "incident": Not sure if you want to do 
this, but there's a definition in RFC 4949 (the internet security 
glossary) for incident and that points to security incident:

  $ security incident
     1. (I) A security event that involves a security violation. (See:
     CERT, security event, security intrusion, security violation.)

I think this is also pretty vague, but it might give those who need a 
clue maybe some more clue.  Basically just add an informative reference 
to RFC 4949.  Up to you.

4) s2, bullet 2: Contains the following statement:

    If, after detailed examination of the problem area and
    the IODEF specification, ...

How about we add the concept of examination *and consultation* to not so 
subtly suggest that people openly talk about their idea with this 
community (or at least somebody in the know) before embarking on doing 
an internet-draft.  So maybe:

    If, after detailed examination and consultation (possibly with the
    IODEF Expert reviewer) of the problem area and the IODEF
    specification, ...

* Trying to figure out where the IODEF expert will be listed so we can 
point to it, but we can add the pointer later.

5) s7.1:

The reference for 5226 is probably now informative?

Update the reference to 6545.

Drop reference to 3688.

6) Appendix A: I'm mildly concerned that somebody will read this and say 
"well hold on there you might be conflicting with the RFC editor's 
requirements."  I think you probably need to add some text in the intro 
that says that any rules, as specified by the RFC editor, obviously take 
precedent to anything in this draft and that the latest version of the 
RFC editor's style guide should be consulted 
(http://www.rfc-editor.org/styleguide.html) for additional instructions. 
  Might also be worth mentioning that you're not going to talk about the 
abstract, status of this memo, copy right, and author addresses sections.

7) A.4.1: Can the types be extended/updated?  If so, then should that be 
mentioned here?

8) In A.5 it's worth noting that this section is required by the RFC 
editor.  You might also be worth an informative reference to RFC 3552 - 
though some people dislike this RFC (adding this reference is up to you).

9) A.6: Isn't the point of an extension document is that something is 
*always* registered?  If it is, then isn't this section always required?

10) A.7: Worth pointing out that this is required by the RFC editor.

11) A.8: r/should/will in the following:

  Each of the examples in section
  Appendix A.9 should be verified to validate against this schema by
  automated tools.

Under what circumstance would they not be?

12) A.8 and A.9 and I guess all appendices in this draft, should we 
require that they explicitly be marked as normative parts of the document?

13) Appendix B: Should we make up something to register as opposed to 
using something real? Maybe something like lottery #?

From kathleen.moriarty@emc.com  Thu Apr 26 12:31:22 2012
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 718E521E8175 for ; Thu, 26 Apr 2012 12:31:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.539
X-Spam-Level: 
X-Spam-Status: No, score=-10.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 G+UFGxs-sh7l for ; Thu, 26 Apr 2012 12:31:21 -0700 (PDT)
Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 7156521F8764 for ; Thu, 26 Apr 2012 12:31:21 -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 q3QJVJ5d023115 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Apr 2012 15:31:19 -0400
Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.130]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Thu, 26 Apr 2012 15:31:14 -0400
Received: from mxhub08.corp.emc.com (mxhub08.corp.emc.com [128.222.70.205]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q3QJVCx3003305; Thu, 26 Apr 2012 15:31:12 -0400
Received: from mxhub39.corp.emc.com (128.222.70.106) by mxhub08.corp.emc.com (128.222.70.205) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 26 Apr 2012 15:30:25 -0400
Received: from mx06a.corp.emc.com ([169.254.1.106]) by mxhub39.corp.emc.com ([128.222.70.106]) with mapi; Thu, 26 Apr 2012 15:31:07 -0400
From: 
To: , 
Date: Thu, 26 Apr 2012 15:31:10 -0400
Thread-Topic: [mile] early AD-review of draft-ietf-mile-template
Thread-Index: Ac0j4gU5GR4ZpJXPRQuEiWvNjdmg8AAAHUZA
Message-ID: 
References: <4F999FB4.5070403@ieca.com>
In-Reply-To: <4F999FB4.5070403@ieca.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EMM-MHVC: 1
Subject: Re: [mile] early AD-review of draft-ietf-mile-template
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, 26 Apr 2012 19:31:22 -0000

Thanks, Sean!

In an attempt to help at #2, we could also consider the following definitio=
n of an incident (section 2.2.7) from early work setting the initial IODE r=
equirements.  The definition covers a security incident and an IT incident.

http://tools.ietf.org/html/rfc3067

Thanks,
Kathleen

-----Original Message-----
From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Sea=
n Turner
Sent: Thursday, April 26, 2012 3:19 PM
To: mile@ietf.org
Subject: [mile] early AD-review of draft-ietf-mile-template

Here's my early AD-review.

spt

--------------

1) s1: r/a section Appendix A/a section (Appendix A)

2) s1: r/of an Internet-Draft/for an Internet-Draft

3) s2, bullet 1: Definition of "incident": Not sure if you want to do=20
this, but there's a definition in RFC 4949 (the internet security=20
glossary) for incident and that points to security incident:

  $ security incident
     1. (I) A security event that involves a security violation. (See:
     CERT, security event, security intrusion, security violation.)

I think this is also pretty vague, but it might give those who need a=20
clue maybe some more clue.  Basically just add an informative reference=20
to RFC 4949.  Up to you.

4) s2, bullet 2: Contains the following statement:

    If, after detailed examination of the problem area and
    the IODEF specification, ...

How about we add the concept of examination *and consultation* to not so=20
subtly suggest that people openly talk about their idea with this=20
community (or at least somebody in the know) before embarking on doing=20
an internet-draft.  So maybe:

    If, after detailed examination and consultation (possibly with the
    IODEF Expert reviewer) of the problem area and the IODEF
    specification, ...

* Trying to figure out where the IODEF expert will be listed so we can=20
point to it, but we can add the pointer later.

5) s7.1:

The reference for 5226 is probably now informative?

Update the reference to 6545.

Drop reference to 3688.

6) Appendix A: I'm mildly concerned that somebody will read this and say=20
"well hold on there you might be conflicting with the RFC editor's=20
requirements."  I think you probably need to add some text in the intro=20
that says that any rules, as specified by the RFC editor, obviously take=20
precedent to anything in this draft and that the latest version of the=20
RFC editor's style guide should be consulted=20
(http://www.rfc-editor.org/styleguide.html) for additional instructions.=20
  Might also be worth mentioning that you're not going to talk about the=20
abstract, status of this memo, copy right, and author addresses sections.

7) A.4.1: Can the types be extended/updated?  If so, then should that be=20
mentioned here?

8) In A.5 it's worth noting that this section is required by the RFC=20
editor.  You might also be worth an informative reference to RFC 3552 -=20
though some people dislike this RFC (adding this reference is up to you).

9) A.6: Isn't the point of an extension document is that something is=20
*always* registered?  If it is, then isn't this section always required?

10) A.7: Worth pointing out that this is required by the RFC editor.

11) A.8: r/should/will in the following:

  Each of the examples in section
  Appendix A.9 should be verified to validate against this schema by
  automated tools.

Under what circumstance would they not be?

12) A.8 and A.9 and I guess all appendices in this draft, should we=20
require that they explicitly be marked as normative parts of the document?

13) Appendix B: Should we make up something to register as opposed to=20
using something real? Maybe something like lottery #?
_______________________________________________
mile mailing list
mile@ietf.org
https://www.ietf.org/mailman/listinfo/mile


From turners@ieca.com  Thu Apr 26 12:36:26 2012
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 60B4D21E8179 for ; Thu, 26 Apr 2012 12:36:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.277
X-Spam-Level: 
X-Spam-Status: No, score=-102.277 tagged_above=-999 required=5 tests=[AWL=-0.012, 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 ZGlJIMADnR0p for ; Thu, 26 Apr 2012 12:36:25 -0700 (PDT)
Received: from gateway01.websitewelcome.com (gateway01.websitewelcome.com [69.56.212.19]) by ietfa.amsl.com (Postfix) with ESMTP id ADE7121E8151 for ; Thu, 26 Apr 2012 12:36:25 -0700 (PDT)
Received: by gateway01.websitewelcome.com (Postfix, from userid 5007) id 1CA0A461A6316; Thu, 26 Apr 2012 14:36:25 -0500 (CDT)
Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway01.websitewelcome.com (Postfix) with ESMTP id 11B18461A62F6 for ; Thu, 26 Apr 2012 14:36:25 -0500 (CDT)
Received: from [71.191.6.129] (port=44255 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1SNUUK-0005Bi-HX; Thu, 26 Apr 2012 14:36:24 -0500
Message-ID: <4F99A3B7.3070904@ieca.com>
Date: Thu, 26 Apr 2012 15:36:23 -0400
From: Sean Turner 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: kathleen.moriarty@emc.com
References: <4F999FB4.5070403@ieca.com> 
In-Reply-To: 
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: pool-71-191-6-129.washdc.east.verizon.net (thunderfish.local) [71.191.6.129]:44255
X-Source-Auth: sean.turner@ieca.com
X-Email-Count: 9
X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20=
Cc: mile@ietf.org
Subject: Re: [mile] early AD-review of draft-ietf-mile-template
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, 26 Apr 2012 19:36:26 -0000

Sure or you could point to both or neither ;)

spt

On 4/26/12 3:31 PM, kathleen.moriarty@emc.com wrote:
> Thanks, Sean!
>
> In an attempt to help at #2, we could also consider the following definition of an incident (section 2.2.7) from early work setting the initial IODE requirements.  The definition covers a security incident and an IT incident.
>
> http://tools.ietf.org/html/rfc3067
>
> Thanks,
> Kathleen
>
> -----Original Message-----
> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Sean Turner
> Sent: Thursday, April 26, 2012 3:19 PM
> To: mile@ietf.org
> Subject: [mile] early AD-review of draft-ietf-mile-template
>
> Here's my early AD-review.
>
> spt
>
> --------------
>
> 1) s1: r/a section Appendix A/a section (Appendix A)
>
> 2) s1: r/of an Internet-Draft/for an Internet-Draft
>
> 3) s2, bullet 1: Definition of "incident": Not sure if you want to do
> this, but there's a definition in RFC 4949 (the internet security
> glossary) for incident and that points to security incident:
>
>    $ security incident
>       1. (I) A security event that involves a security violation. (See:
>       CERT, security event, security intrusion, security violation.)
>
> I think this is also pretty vague, but it might give those who need a
> clue maybe some more clue.  Basically just add an informative reference
> to RFC 4949.  Up to you.
>
> 4) s2, bullet 2: Contains the following statement:
>
>      If, after detailed examination of the problem area and
>      the IODEF specification, ...
>
> How about we add the concept of examination *and consultation* to not so
> subtly suggest that people openly talk about their idea with this
> community (or at least somebody in the know) before embarking on doing
> an internet-draft.  So maybe:
>
>      If, after detailed examination and consultation (possibly with the
>      IODEF Expert reviewer) of the problem area and the IODEF
>      specification, ...
>
> * Trying to figure out where the IODEF expert will be listed so we can
> point to it, but we can add the pointer later.
>
> 5) s7.1:
>
> The reference for 5226 is probably now informative?
>
> Update the reference to 6545.
>
> Drop reference to 3688.
>
> 6) Appendix A: I'm mildly concerned that somebody will read this and say
> "well hold on there you might be conflicting with the RFC editor's
> requirements."  I think you probably need to add some text in the intro
> that says that any rules, as specified by the RFC editor, obviously take
> precedent to anything in this draft and that the latest version of the
> RFC editor's style guide should be consulted
> (http://www.rfc-editor.org/styleguide.html) for additional instructions.
>    Might also be worth mentioning that you're not going to talk about the
> abstract, status of this memo, copy right, and author addresses sections.
>
> 7) A.4.1: Can the types be extended/updated?  If so, then should that be
> mentioned here?
>
> 8) In A.5 it's worth noting that this section is required by the RFC
> editor.  You might also be worth an informative reference to RFC 3552 -
> though some people dislike this RFC (adding this reference is up to you).
>
> 9) A.6: Isn't the point of an extension document is that something is
> *always* registered?  If it is, then isn't this section always required?
>
> 10) A.7: Worth pointing out that this is required by the RFC editor.
>
> 11) A.8: r/should/will in the following:
>
>    Each of the examples in section
>    Appendix A.9 should be verified to validate against this schema by
>    automated tools.
>
> Under what circumstance would they not be?
>
> 12) A.8 and A.9 and I guess all appendices in this draft, should we
> require that they explicitly be marked as normative parts of the document?
>
> 13) Appendix B: Should we make up something to register as opposed to
> using something real? Maybe something like lottery #?
> _______________________________________________
> mile mailing list
> mile@ietf.org
> https://www.ietf.org/mailman/listinfo/mile
>
>

From takeshi_takahashi@nict.go.jp  Thu Apr 26 15:32:10 2012
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 0943A21F87AD for ; Thu, 26 Apr 2012 15:32:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.027
X-Spam-Level: 
X-Spam-Status: No, score=-1.027 tagged_above=-999 required=5 tests=[AWL=0.328,  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 uriQZ7iktKGO for ; Thu, 26 Apr 2012 15:32:08 -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 65C7621F87AA for ; Thu, 26 Apr 2012 15:32:08 -0700 (PDT)
Received: from gw2.nict.go.jp (gw2 [133.243.18.251]) by ns2.nict.go.jp  with ESMTP id q3QMW3Z8028542; Fri, 27 Apr 2012 07:32:03 +0900 (JST)
Received: from gw2.nict.go.jp (localhost [127.0.0.1]) by gw2.nict.go.jp  with ESMTP id q3QMW2jR000028; Fri, 27 Apr 2012 07:32:02 +0900 (JST)
Received: from takeVAIO2 (ssh.nict.go.jp [133.243.3.49]) by gw2.nict.go.jp  with ESMTP id q3QMVxRm000025; Fri, 27 Apr 2012 07:32:00 +0900 (JST)
From: "Takeshi Takahashi" 
To: , , 
References: <001701cd1bad$5608c580$021a5080$@nict.go.jp>  <009701cd21b5$94967d20$bdc37760$@nict.go.jp> 
In-Reply-To: 
Date: Fri, 27 Apr 2012 07:31:55 +0900
Message-ID: <007801cd23fc$6408c700$2c1a5500$@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: AQJqn32zOrRFJnR8j7J0GMvAnatt3wH7qlpEAfiWW3oBNw/zdpVJWvDQ
Content-Language: ja
Subject: Re: [mile] IODEF Reference Format for Enumerations
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, 26 Apr 2012 22:32:10 -0000

Hi Kathleen

> Can you explain more on how you see merging the two into one document?

Yes, I think it would be fine.
I do not see the benefit of having two drafts for describing enumeration/id
values (e.g., CVE-IDs).

> The only concern I have is that specifying the enumerations could be done
> without including the MITRE specifications right into the document, so
> we *MAY* not have to worry about the normative references (but I would
> need to confirm that).
> 
> One advantage of one document over two would be one registry page for
> the two IANA tables.

I would be happy to hear people's opinion, but I think the option 2/3 and
SCI draft has some overlap, as mentioned above, and I do not see any point
to have similar but different drafts.
It would simply cause some confusion, I think.

On the other hand, if it is still better to have two distinct drafts, that
is also one option.
In that case, we need to clarify the distinction between the two drafts.

Both drafts describe enumerations (ids) in a similar manner, but one is
using SCI classes while the other is using Reference class.
If we cannot define any clear distinction, I think merging them into one
would be better.
The option 3 could be extended so that it could include the essence of the
current SCI draft, for instance.

I might be still behind discussion, so I would appreciate to hear comments
from the list.

Kind regards,

Take



> -----Original Message-----
> From: kathleen.moriarty@emc.com [mailto:kathleen.moriarty@emc.com]
> Sent: Thursday, April 26, 2012 9:48 PM
> To: takeshi_takahashi@nict.go.jp; amontville@tripwire.com;
> mile@ietf.org
> Subject: RE: [mile] IODEF Reference Format for Enumerations
> 
> Hi Take,
> 
> Can you explain more on how you see merging the two into one document?
> The only concern I have is that specifying the enumerations could be done
> without including the MITRE specifications right into the document, so
> we *MAY* not have to worry about the normative references (but I would
> need to confirm that).
> 
> One advantage of one document over two would be one registry page for
> the two IANA tables.
> 
> This approach would mean that we would plan on an IODEF revision for at
> least a few small things.
> 
> How do you see the approach working and what are the thoughts of others
> on the list?
> 
> Thank you,
> Kathleen
> 
> -----Original Message-----
> From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp]
> Sent: Monday, April 23, 2012 9:00 PM
> To: 'Adam Montville'; Moriarty, Kathleen; mile@ietf.org
> Subject: RE: [mile] IODEF Reference Format for Enumerations
> 
> Let me rewrite the sentence:
> 
> > If Option 3 could cover the rest of the classes including the ones
> > that do not have any ID yet, I think it is reasonable to merge the
> > works into one.
> 
> If Option 3 could cover all the classes (not only the vulnerability class
> but also the other classes), some of which supports XML without any IDs,
> I think it is reasonable to merge the works into one.
> I believe the Reference class can support them with proper extension.
> 
> Sincerely,
> Take
> 
> 
> 
> > -----Original Message-----
> > From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp]
> > Sent: Tuesday, April 24, 2012 9:56 AM
> > To: 'Adam Montville'; 'kathleen.moriarty@emc.com'; 'mile@ietf.org'
> > Subject: RE: [mile] IODEF Reference Format for Enumerations
> >
> > Adam,
> >
> > If modifying IODEF is allowed, I do not see any point to define
> > classes under AdditionalData class (as SCI draft does) since it makes
> > the XML longer.
> >
> > Since the new Option 3 and the sci draft are not that different, it
> > would be fine for me to combine them into one.
> > Sci draft defines several containers for each semantics, and
> > positioned them under AdditionalData class, while new Option 3 defines
> > one container with semantic information that requires no additionalData
> class.
> > (I wonder whether we really need the semantics or not if we use the
> > option
> > 3 approach, since the location of the Reference class inside IODEF
> > document indicates the semantics.)
> >
> > If Option 3 could cover the rest of the classes including the ones
> > that do not have any ID yet, I think it is reasonable to merge the
> > works into one.
> > I do not see any point to have two drafts for similar issues.
> > That will just confuse users.
> >
> > The remaining issues for the SCI draft were as follows in my
> > understanding 1. "namespace identifying specification" needs to be
> confirmed 2.
> > copyright issues needs to be clarified 3. schema needs to be reviewed
> >
> > The merged work will inherit the above issues, and I am happy if you
> > could lead the work.
> > How does that sound to everybody?
> >
> > Sincerey,
> > Take
> >
> >
> > > -----Original Message-----
> > > From: Adam Montville [mailto:amontville@tripwire.com]
> > > Sent: Tuesday, April 24, 2012 7:44 AM
> > > To: Takeshi Takahashi; kathleen.moriarty@emc.com; mile@ietf.org
> > > Subject: Re: [mile] IODEF Reference Format for Enumerations
> > >
> > > Take,
> > >
> > > Do you think it would make any sense to combine the two approaches?
> > > Option 3 could be rewritten to be more aligned with the
> > >  example you provided.
> > >
> > > 
> > >   id
> > >   http://www.example.com/path
> > >   http://www.otherexample.com/path
> > >   Description
> > > 
> > >
> > >
> > > Or, perhaps the class information could be referenced in an IANA
> > > table in a manner consistent with Options 1 and 2...  So, if there's
> > > a registryId, then some semantic information about the types of
> > > classes accepted by that registryId could be discovered.
> > >
> > > Any thoughts from the list about this general approach?
> > >
> > > Adam
> > >
> > > On 4/16/12 1:45 AM, "Takeshi Takahashi"
> > > 
> > > wrote:
> > >
> > > >Hi all,
> > > >
> > > >If we are going to update option 3, that would be one direction.
> > > >
> > > >IMHO, the option 3 is very close to the expected use of the
> > > >Vulnerability class of SCI draft. (and some other classes as well)
> > > >The expected usage of the Vulnerability class of current SCI draft,
> > > >with CVE identifier, is as follows.
> > > >
> > > > > > SpecID="http://cve.mitre.org/cve/downloads/1.0"
> > > >VulnerabilityID="CVE-2010-3654"/>
> > > >
> > > >The slight difference between the SCI draft and the option 3 is
> > > >that the SCI draft took a semantic approach (vulnerability,
> > > >attackpattern, etc.), while the option three takes general container
> approach.
> > > >The URLs to the information of the specification (in this case CVE
> > > >1.0) are described in the IANA table in case of the SCI draft
approach.
> > > >
> > > >I think both approach is viable, but proper description on how to
> > > >choose either of the approaches could be helpful for readers.
> > > >
> > > >Thank you.
> > > >Take
> > > >
> > > >> -----Original Message-----
> > > >> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On
> > > >> Behalf Of kathleen.moriarty@emc.com
> > > >> Sent: Friday, April 13, 2012 3:56 AM
> > > >> To: amontville@tripwire.com; mile@ietf.org
> > > >> Subject: Re: [mile] IODEF Reference Format for Enumerations
> > > >>
> > > >> Hi Adam,
> > > >>
> > > >> Thank you for running the list of options by the WG and to those
> > > >> participating in the decision process!
> > > >>
> > > >> We have had a couple of reasons discussed to 'open' up IODEF.  If
> > > >>we get  a volunteer to help with the editing of an RFC5070 soon,
> > > >>then option 3  may be worth considering.  I would expect that a
> > > >>revision
> > > to
> > > >>RFC5070 would  take some time as the list works through issues and
> > > >>options.
> > > >>
> > > >> What do others think about this and Adam's other questions?
> > > >>
> > > >> Thanks,
> > > >> Kathleen
> > > >>
> > > >> -----Original Message-----
> > > >> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On
> > > >> Behalf Of Adam Montville
> > > >> Sent: Thursday, April 12, 2012 2:28 PM
> > > >> To: Adam Montville; mile@ietf.org
> > > >> Subject: Re: [mile] IODEF Reference Format for Enumerations
> > > >>
> > > >> All:
> > > >>
> > > >> So far, it seems as though more people are speaking up in favor
> > > >>of Option  2.  There are also several comments expressing a desire
> > > >>to choose either  Option 1 or Option 2, but then move to Option
> 3
> > > >>at some point in the
> > > >future.
> > > >> I'd like to understand more about what that really means -
> > > >> choosing one option and then moving to another.
> > > >>
> > > >> Would it make more sense to wait until IODEF is "opened" for an
> > > >> update to address this issue?
> > > >>
> > > >> For those of you who prefer Option 1 or Option 2, but have not
> > > >> indicated a preference with respect to later moving to Option 3,
> > do
> > > >> you have an opinion about such a move?
> > > >>
> > > >> David Black has put forward some additional insight where, "if
> > > >> Option
> > > >> 1 is chosen, the result is a common means of referencing
> > > >> specifications between the SCI draft and the new draft on use of
> > > >> the IODEF reference format."
> > > >> This statement references the notion of requiring the first URL
> > > >> of
> > > on
> > > >> IODEF  element (associated with the )
> > > >> to
> > > be
> > > >> a reference URI from the IANA registry established by the SCI
draft.
> > > >>
> > > >> It would seem, then, that we have deterministic methods of
> > > >> understanding what a  is, and thus how to parse
> > > >> it, but that we have several different mechanisms by which to
> > > >> accomplish
> > > this.
> > > >>
> > > >> Comments? Opinions?
> > > >>
> > > >> Regards,
> > > >>
> > > >> Adam
> > > >>
> > > >> On 4/9/12 11:38 AM, "Adam Montville" 
> > wrote:
> > > >>
> > > >> >All:
> > > >> >
> > > >> >There is an identified need to specify a format to include
> > > >> >relevant enumeration values in an IODEF document.  The initial
> > > >> >idea is to place enumeration values and their references in
> > > >> >IODEF's Reference
> > > class.
> > > >> >There are several ways to accomplish this goal.  I'll do my best
> > > >> >to enumerate some options here, then I hope to hear some
> > > >> >feedback/opinions about the different approaches from the list.
> > > >> >
> > > >> >From the Structured Cybersecurity Information draft
> > > >> >(draft-takahashi-mile-sci-02), we may be interested to include
> > > >> >the following (not an inclusive list) enumerations in an IODEF
> document:
> > > >> >CAPEC, CCE, CPE, CVE, CWE, IEC 19770-2.
> > > >> >
> > > >> >The IODEF Reference class is described in 3.9.1 of RFC 5070,
> > > >> >where
> > > a
> > > >> >Reference must have a ReferenceName and zero or more of URL or
> > > >> >Description respectively.
> > > >> >
> > > >> >For each option described below, we can consider use of the IANA
> > > >registry.
> > > >> >The registry may be used to identify the identifier category and
> > > >> >potentially the appropriate identification format for that
> > category.
> > > >> >
> > > >> >
> > > >> >Option 1: Simple ID
> > > >> >===================
> > > >> >The first option would simply embed the relevant identifier in
> > > >> >the ReferenceName element of the Reference class.  This may look
> > > >> >like the
> > > >> >following:
> > > >> >
> > > >> >    
> > > >> >        id
> > > >> >        http://www.example.com/path
> > > >> >        http://www.otherexample.com/path
> > > >> >        Description
> > > >> >    
> > > >> >
> > > >> >Using this option, a variety of specific identifier formats
> > > >> >could
> > > be
> > > >> >specified.  CVE, for example, would start with "CVE-" and this
> > > >> >convention may be registered in an IANA table.
> > > >> >
> > > >> >No changes to IODEF are required for this option.
> > > >> >
> > > >> >
> > > >> >
> > > >> >Option 2: ID with coupled ID type
> > > >> >=================================
> > > >> >The second option would prepend the identifier with it's type,
> > > >> >which may look something like the following.
> > > >> >
> > > >> >    
> > > >> >        id_type:id
> > > >> >        http://www.example.com/path
> > > >> >        http://www.otherexample.com/path
> > > >> >        Description
> > > >> >    
> > > >> >
> > > >> >Using this option, a variety of specific identifier types could
> > be
> > > >> >specified, such that the identifier itself would not necessarily
> > > >> >be constrained, nor would new identifier formats necessarily
> > > >> >need to
> > > be
> > > >> >specified in the future.  An IANA table may be used for this
> > > >> >solution as well.
> > > >> >
> > > >> >No changes to IODEF would be required for this option.
> > > >> >
> > > >> >
> > > >> >
> > > >> >Option 3: ID with type expressed in Reference attribute
> > > >> >=======================================================
> > > >> >The third option would require opening IODEF to update the
> > > >> >Reference class with an attribute, which may look something like
> > the following.
> > > >> >
> > > >> >    
> > > >> >        id
> > > >> >        http://www.example.com/path
> > > >> >        http://www.otherexample.com/path
> > > >> >        Description
> > > >> >    
> > > >> >
> > > >> >
> > > >> >
> > > >> >Changes to IODEF are required for this option.
> > > >> >
> > > >> >
> > > >> >----
> > > >> >
> > > >> >I look forward to fielding responses to these options, including
> > > >> >any additional options you may see, but which are not listed.
> > > >> >
> > > >> >What is your solution preference?
> > > >> >
> > > >> >
> > > >> >Regards,
> > > >> >
> > > >> >Adam W. Montville | Security and Compliance Architect
> > > >> >
> > > >> >Direct: 503 276-7661
> > > >> >Mobile: 360 471-7815
> > > >> >
> > > >> >TRIPWIRE | Take CONTROL
> > > >> >http://www.tripwire.com
> > > >> >
> > > >> >
> > > >> >
> > > >> >
> > > >> >
> > > >> >
> > > >> >_______________________________________________
> > > >> >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  Thu Apr 26 15:50:42 2012
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 D3E4C21F8804 for ; Thu, 26 Apr 2012 15:50:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.543
X-Spam-Level: 
X-Spam-Status: No, score=-10.543 tagged_above=-999 required=5 tests=[AWL=0.056, 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 U+OaZO2J2Kri for ; Thu, 26 Apr 2012 15:50:38 -0700 (PDT)
Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id BFB4521F8802 for ; Thu, 26 Apr 2012 15:50:37 -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 q3QMoaLZ003069 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Apr 2012 18:50:36 -0400
Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.129]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Thu, 26 Apr 2012 18:50:17 -0400
Received: from mxhub23.corp.emc.com (mxhub23.corp.emc.com [128.222.70.135]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q3QMoG8R017154; Thu, 26 Apr 2012 18:50:16 -0400
Received: from mxhub39.corp.emc.com (128.222.70.106) by mxhub23.corp.emc.com (128.222.70.135) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 26 Apr 2012 18:50:16 -0400
Received: from mx06a.corp.emc.com ([169.254.1.106]) by mxhub39.corp.emc.com ([128.222.70.106]) with mapi; Thu, 26 Apr 2012 18:50:10 -0400
From: 
To: , , 
Date: Thu, 26 Apr 2012 18:50:13 -0400
Thread-Topic: [mile] IODEF Reference Format for Enumerations
Thread-Index: AQJqn32zOrRFJnR8j7J0GMvAnatt3wH7qlpEAfiWW3oBNw/zdpVJWvDQgAAIf7A=
Message-ID: 
References: <001701cd1bad$5608c580$021a5080$@nict.go.jp>  <009701cd21b5$94967d20$bdc37760$@nict.go.jp>  <007801cd23fc$6408c700$2c1a5500$@nict.go.jp>
In-Reply-To: <007801cd23fc$6408c700$2c1a5500$@nict.go.jp>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EMM-MHVC: 1
Subject: Re: [mile] IODEF Reference Format for Enumerations
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, 26 Apr 2012 22:50:42 -0000

Hi Take,

Thank you!  I thought the difference was that the SCI draft specified where=
 other schemas would be incorporated into an IODEF document to extend the d=
ata model.  The enumerations would be specific to allow references only to =
be included directly in IODEF where enumerations are used to point to insta=
nces of the schema (CVE#1234).

Can you explain your thoughts behind the equivalence so that we can see if =
there is another option for consideration?

Thank you,
Kathleen

-----Original Message-----
From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp]
Sent: Thursday, April 26, 2012 6:32 PM
To: Moriarty, Kathleen; amontville@tripwire.com; mile@ietf.org
Subject: RE: [mile] IODEF Reference Format for Enumerations

Hi Kathleen

> Can you explain more on how you see merging the two into one document?

Yes, I think it would be fine.
I do not see the benefit of having two drafts for describing enumeration/id
values (e.g., CVE-IDs).

> The only concern I have is that specifying the enumerations could be done
> without including the MITRE specifications right into the document, so
> we *MAY* not have to worry about the normative references (but I would
> need to confirm that).
>
> One advantage of one document over two would be one registry page for
> the two IANA tables.

I would be happy to hear people's opinion, but I think the option 2/3 and
SCI draft has some overlap, as mentioned above, and I do not see any point
to have similar but different drafts.
It would simply cause some confusion, I think.

On the other hand, if it is still better to have two distinct drafts, that
is also one option.
In that case, we need to clarify the distinction between the two drafts.

Both drafts describe enumerations (ids) in a similar manner, but one is
using SCI classes while the other is using Reference class.
If we cannot define any clear distinction, I think merging them into one
would be better.
The option 3 could be extended so that it could include the essence of the
current SCI draft, for instance.

I might be still behind discussion, so I would appreciate to hear comments
from the list.

Kind regards,

Take



> -----Original Message-----
> From: kathleen.moriarty@emc.com [mailto:kathleen.moriarty@emc.com]
> Sent: Thursday, April 26, 2012 9:48 PM
> To: takeshi_takahashi@nict.go.jp; amontville@tripwire.com;
> mile@ietf.org
> Subject: RE: [mile] IODEF Reference Format for Enumerations
>
> Hi Take,
>
> Can you explain more on how you see merging the two into one document?
> The only concern I have is that specifying the enumerations could be done
> without including the MITRE specifications right into the document, so
> we *MAY* not have to worry about the normative references (but I would
> need to confirm that).
>
> One advantage of one document over two would be one registry page for
> the two IANA tables.
>
> This approach would mean that we would plan on an IODEF revision for at
> least a few small things.
>
> How do you see the approach working and what are the thoughts of others
> on the list?
>
> Thank you,
> Kathleen
>
> -----Original Message-----
> From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp]
> Sent: Monday, April 23, 2012 9:00 PM
> To: 'Adam Montville'; Moriarty, Kathleen; mile@ietf.org
> Subject: RE: [mile] IODEF Reference Format for Enumerations
>
> Let me rewrite the sentence:
>
> > If Option 3 could cover the rest of the classes including the ones
> > that do not have any ID yet, I think it is reasonable to merge the
> > works into one.
>
> If Option 3 could cover all the classes (not only the vulnerability class
> but also the other classes), some of which supports XML without any IDs,
> I think it is reasonable to merge the works into one.
> I believe the Reference class can support them with proper extension.
>
> Sincerely,
> Take
>
>
>
> > -----Original Message-----
> > From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp]
> > Sent: Tuesday, April 24, 2012 9:56 AM
> > To: 'Adam Montville'; 'kathleen.moriarty@emc.com'; 'mile@ietf.org'
> > Subject: RE: [mile] IODEF Reference Format for Enumerations
> >
> > Adam,
> >
> > If modifying IODEF is allowed, I do not see any point to define
> > classes under AdditionalData class (as SCI draft does) since it makes
> > the XML longer.
> >
> > Since the new Option 3 and the sci draft are not that different, it
> > would be fine for me to combine them into one.
> > Sci draft defines several containers for each semantics, and
> > positioned them under AdditionalData class, while new Option 3 defines
> > one container with semantic information that requires no additionalData
> class.
> > (I wonder whether we really need the semantics or not if we use the
> > option
> > 3 approach, since the location of the Reference class inside IODEF
> > document indicates the semantics.)
> >
> > If Option 3 could cover the rest of the classes including the ones
> > that do not have any ID yet, I think it is reasonable to merge the
> > works into one.
> > I do not see any point to have two drafts for similar issues.
> > That will just confuse users.
> >
> > The remaining issues for the SCI draft were as follows in my
> > understanding 1. "namespace identifying specification" needs to be
> confirmed 2.
> > copyright issues needs to be clarified 3. schema needs to be reviewed
> >
> > The merged work will inherit the above issues, and I am happy if you
> > could lead the work.
> > How does that sound to everybody?
> >
> > Sincerey,
> > Take
> >
> >
> > > -----Original Message-----
> > > From: Adam Montville [mailto:amontville@tripwire.com]
> > > Sent: Tuesday, April 24, 2012 7:44 AM
> > > To: Takeshi Takahashi; kathleen.moriarty@emc.com; mile@ietf.org
> > > Subject: Re: [mile] IODEF Reference Format for Enumerations
> > >
> > > Take,
> > >
> > > Do you think it would make any sense to combine the two approaches?
> > > Option 3 could be rewritten to be more aligned with the
> > >  example you provided.
> > >
> > > 
> > >   id
> > >   http://www.example.com/path
> > >   http://www.otherexample.com/path
> > >   Description
> > > 
> > >
> > >
> > > Or, perhaps the class information could be referenced in an IANA
> > > table in a manner consistent with Options 1 and 2...  So, if there's
> > > a registryId, then some semantic information about the types of
> > > classes accepted by that registryId could be discovered.
> > >
> > > Any thoughts from the list about this general approach?
> > >
> > > Adam
> > >
> > > On 4/16/12 1:45 AM, "Takeshi Takahashi"
> > > 
> > > wrote:
> > >
> > > >Hi all,
> > > >
> > > >If we are going to update option 3, that would be one direction.
> > > >
> > > >IMHO, the option 3 is very close to the expected use of the
> > > >Vulnerability class of SCI draft. (and some other classes as well)
> > > >The expected usage of the Vulnerability class of current SCI draft,
> > > >with CVE identifier, is as follows.
> > > >
> > > > > > SpecID=3D"http://cve.mitre.org/cve/downloads/1.0"
> > > >VulnerabilityID=3D"CVE-2010-3654"/>
> > > >
> > > >The slight difference between the SCI draft and the option 3 is
> > > >that the SCI draft took a semantic approach (vulnerability,
> > > >attackpattern, etc.), while the option three takes general container
> approach.
> > > >The URLs to the information of the specification (in this case CVE
> > > >1.0) are described in the IANA table in case of the SCI draft
approach.
> > > >
> > > >I think both approach is viable, but proper description on how to
> > > >choose either of the approaches could be helpful for readers.
> > > >
> > > >Thank you.
> > > >Take
> > > >
> > > >> -----Original Message-----
> > > >> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On
> > > >> Behalf Of kathleen.moriarty@emc.com
> > > >> Sent: Friday, April 13, 2012 3:56 AM
> > > >> To: amontville@tripwire.com; mile@ietf.org
> > > >> Subject: Re: [mile] IODEF Reference Format for Enumerations
> > > >>
> > > >> Hi Adam,
> > > >>
> > > >> Thank you for running the list of options by the WG and to those
> > > >> participating in the decision process!
> > > >>
> > > >> We have had a couple of reasons discussed to 'open' up IODEF.  If
> > > >>we get  a volunteer to help with the editing of an RFC5070 soon,
> > > >>then option 3  may be worth considering.  I would expect that a
> > > >>revision
> > > to
> > > >>RFC5070 would  take some time as the list works through issues and
> > > >>options.
> > > >>
> > > >> What do others think about this and Adam's other questions?
> > > >>
> > > >> Thanks,
> > > >> Kathleen
> > > >>
> > > >> -----Original Message-----
> > > >> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On
> > > >> Behalf Of Adam Montville
> > > >> Sent: Thursday, April 12, 2012 2:28 PM
> > > >> To: Adam Montville; mile@ietf.org
> > > >> Subject: Re: [mile] IODEF Reference Format for Enumerations
> > > >>
> > > >> All:
> > > >>
> > > >> So far, it seems as though more people are speaking up in favor
> > > >>of Option  2.  There are also several comments expressing a desire
> > > >>to choose either  Option 1 or Option 2, but then move to Option
> 3
> > > >>at some point in the
> > > >future.
> > > >> I'd like to understand more about what that really means -
> > > >> choosing one option and then moving to another.
> > > >>
> > > >> Would it make more sense to wait until IODEF is "opened" for an
> > > >> update to address this issue?
> > > >>
> > > >> For those of you who prefer Option 1 or Option 2, but have not
> > > >> indicated a preference with respect to later moving to Option 3,
> > do
> > > >> you have an opinion about such a move?
> > > >>
> > > >> David Black has put forward some additional insight where, "if
> > > >> Option
> > > >> 1 is chosen, the result is a common means of referencing
> > > >> specifications between the SCI draft and the new draft on use of
> > > >> the IODEF reference format."
> > > >> This statement references the notion of requiring the first URL
> > > >> of
> > > on
> > > >> IODEF  element (associated with the )
> > > >> to
> > > be
> > > >> a reference URI from the IANA registry established by the SCI
draft.
> > > >>
> > > >> It would seem, then, that we have deterministic methods of
> > > >> understanding what a  is, and thus how to parse
> > > >> it, but that we have several different mechanisms by which to
> > > >> accomplish
> > > this.
> > > >>
> > > >> Comments? Opinions?
> > > >>
> > > >> Regards,
> > > >>
> > > >> Adam
> > > >>
> > > >> On 4/9/12 11:38 AM, "Adam Montville" 
> > wrote:
> > > >>
> > > >> >All:
> > > >> >
> > > >> >There is an identified need to specify a format to include
> > > >> >relevant enumeration values in an IODEF document.  The initial
> > > >> >idea is to place enumeration values and their references in
> > > >> >IODEF's Reference
> > > class.
> > > >> >There are several ways to accomplish this goal.  I'll do my best
> > > >> >to enumerate some options here, then I hope to hear some
> > > >> >feedback/opinions about the different approaches from the list.
> > > >> >
> > > >> >From the Structured Cybersecurity Information draft
> > > >> >(draft-takahashi-mile-sci-02), we may be interested to include
> > > >> >the following (not an inclusive list) enumerations in an IODEF
> document:
> > > >> >CAPEC, CCE, CPE, CVE, CWE, IEC 19770-2.
> > > >> >
> > > >> >The IODEF Reference class is described in 3.9.1 of RFC 5070,
> > > >> >where
> > > a
> > > >> >Reference must have a ReferenceName and zero or more of URL or
> > > >> >Description respectively.
> > > >> >
> > > >> >For each option described below, we can consider use of the IANA
> > > >registry.
> > > >> >The registry may be used to identify the identifier category and
> > > >> >potentially the appropriate identification format for that
> > category.
> > > >> >
> > > >> >
> > > >> >Option 1: Simple ID
> > > >> >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > > >> >The first option would simply embed the relevant identifier in
> > > >> >the ReferenceName element of the Reference class.  This may look
> > > >> >like the
> > > >> >following:
> > > >> >
> > > >> >    
> > > >> >        id
> > > >> >        http://www.example.com/path
> > > >> >        http://www.otherexample.com/path
> > > >> >        Description
> > > >> >    
> > > >> >
> > > >> >Using this option, a variety of specific identifier formats
> > > >> >could
> > > be
> > > >> >specified.  CVE, for example, would start with "CVE-" and this
> > > >> >convention may be registered in an IANA table.
> > > >> >
> > > >> >No changes to IODEF are required for this option.
> > > >> >
> > > >> >
> > > >> >
> > > >> >Option 2: ID with coupled ID type
> > > >> >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > > >> >The second option would prepend the identifier with it's type,
> > > >> >which may look something like the following.
> > > >> >
> > > >> >    
> > > >> >        id_type:id
> > > >> >        http://www.example.com/path
> > > >> >        http://www.otherexample.com/path
> > > >> >        Description
> > > >> >    
> > > >> >
> > > >> >Using this option, a variety of specific identifier types could
> > be
> > > >> >specified, such that the identifier itself would not necessarily
> > > >> >be constrained, nor would new identifier formats necessarily
> > > >> >need to
> > > be
> > > >> >specified in the future.  An IANA table may be used for this
> > > >> >solution as well.
> > > >> >
> > > >> >No changes to IODEF would be required for this option.
> > > >> >
> > > >> >
> > > >> >
> > > >> >Option 3: ID with type expressed in Reference attribute
> > > >> >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > > >> >The third option would require opening IODEF to update the
> > > >> >Reference class with an attribute, which may look something like
> > the following.
> > > >> >
> > > >> >    
> > > >> >        id
> > > >> >        http://www.example.com/path
> > > >> >        http://www.otherexample.com/path
> > > >> >        Description
> > > >> >    
> > > >> >
> > > >> >
> > > >> >
> > > >> >Changes to IODEF are required for this option.
> > > >> >
> > > >> >
> > > >> >----
> > > >> >
> > > >> >I look forward to fielding responses to these options, including
> > > >> >any additional options you may see, but which are not listed.
> > > >> >
> > > >> >What is your solution preference?
> > > >> >
> > > >> >
> > > >> >Regards,
> > > >> >
> > > >> >Adam W. Montville | Security and Compliance Architect
> > > >> >
> > > >> >Direct: 503 276-7661
> > > >> >Mobile: 360 471-7815
> > > >> >
> > > >> >TRIPWIRE | Take CONTROL
> > > >> >http://www.tripwire.com
> > > >> >
> > > >> >
> > > >> >
> > > >> >
> > > >> >
> > > >> >
> > > >> >_______________________________________________
> > > >> >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 takeshi_takahashi@nict.go.jp  Fri Apr 27 01:08:51 2012
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 315CA21F8610 for ; Fri, 27 Apr 2012 01:08:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.074
X-Spam-Level: 
X-Spam-Status: No, score=-1.074 tagged_above=-999 required=5 tests=[AWL=0.281,  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 UjMBId1ilAiH for ; Fri, 27 Apr 2012 01:08:49 -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 349E921F860F for ; Fri, 27 Apr 2012 01:08:48 -0700 (PDT)
Received: from gw2.nict.go.jp (gw2 [133.243.18.251]) by ns2.nict.go.jp  with ESMTP id q3R88ioM029289; Fri, 27 Apr 2012 17:08:44 +0900 (JST)
Received: from gw2.nict.go.jp (localhost [127.0.0.1]) by gw2.nict.go.jp  with ESMTP id q3R88ika000743; Fri, 27 Apr 2012 17:08:44 +0900 (JST)
Received: from takeVAIO2 (ssh.nict.go.jp [133.243.3.49]) by gw2.nict.go.jp  with ESMTP id q3R88MHP000643; Fri, 27 Apr 2012 17:08:25 +0900 (JST)
From: "Takeshi Takahashi" 
To: , , 
References: <001701cd1bad$5608c580$021a5080$@nict.go.jp>  <009701cd21b5$94967d20$bdc37760$@nict.go.jp>  <007801cd23fc$6408c700$2c1a5500$@nict.go.jp> 
In-Reply-To: 
Date: Fri, 27 Apr 2012 17:08:18 +0900
Message-ID: <001c01cd244c$f1e31d00$d5a95700$@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: AQJqn32zOrRFJnR8j7J0GMvAnatt3wH7qlpEAfiWW3oBNw/zdgKGFwCgAlbI8l6VIw41MA==
Content-Language: ja
Subject: Re: [mile] IODEF Reference Format for Enumerations
X-BeenThere: mile@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Apr 2012 08:08:51 -0000

Hi Kathleen,

Thank you for your email.
I would like to know why you propose to have new draft to describe CVE-ID
regardless of the existence of the ongoing SCI work.
I am confused.

The benefit of using enumeration values (identifiers, such as CVE-ID) was
discussed on this mailing list last September (see the discussion around
Sept. 2011).
Thus the SCI draft is changed to reflect the discussion since then.
Regarding the CVE, the SCI draft is recommending to embed CVE-ID and not to
embed the raw XML if no special reason exists.

> Can you explain your thoughts behind the equivalence so that we can see
> if there is another option for consideration?

So, if a sender wants to embed CVE-ID, what would be the suggested way?
If the sender follows the SCI draft, he could write the following XML.



If the sender follows the option 3, he could write the following XML or the
likes.


    CVE-2010-3654
   http://www.example.com/path
   http://www.otherexample.com/path
   Description


For me, both could be fine, but having two similar ways to convey CVE-ID
should be avoided since both sender and receiver of the IODEF will be
confused.
At least, some navigation should be clearly described in both drafts.
So, I would like to hear why you propose to have new draft for conveying
CVE-ID in addition to the SCI draft.

I have no intention to insist that SCI draft has the right way, and if
community finds better way to convey the CVE-ID, we could simply forget
about the sci draft and work for the new direction. I just think having two
similar but different draft should be avoided since it causes confusion to
receivers/senders of IODEF documents.

Thank you.
Take



> -----Original Message-----
> From: kathleen.moriarty@emc.com [mailto:kathleen.moriarty@emc.com]
> Sent: Friday, April 27, 2012 7:50 AM
> To: takeshi_takahashi@nict.go.jp; amontville@tripwire.com;
> mile@ietf.org
> Subject: RE: [mile] IODEF Reference Format for Enumerations
> 
> Hi Take,
> 
> Thank you!  I thought the difference was that the SCI draft specified
> where other schemas would be incorporated into an IODEF document to extend
> the data model.  The enumerations would be specific to allow references
> only to be included directly in IODEF where enumerations are used to point
> to instances of the schema (CVE#1234).
> 
> Can you explain your thoughts behind the equivalence so that we can see
> if there is another option for consideration?
> 
> Thank you,
> Kathleen
> 
> -----Original Message-----
> From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp]
> Sent: Thursday, April 26, 2012 6:32 PM
> To: Moriarty, Kathleen; amontville@tripwire.com; mile@ietf.org
> Subject: RE: [mile] IODEF Reference Format for Enumerations
> 
> Hi Kathleen
> 
> > Can you explain more on how you see merging the two into one document?
> 
> Yes, I think it would be fine.
> I do not see the benefit of having two drafts for describing
enumeration/id
> values (e.g., CVE-IDs).
> 
> > The only concern I have is that specifying the enumerations could be
> > done without including the MITRE specifications right into the
> > document, so we *MAY* not have to worry about the normative references
> > (but I would need to confirm that).
> >
> > One advantage of one document over two would be one registry page for
> > the two IANA tables.
> 
> I would be happy to hear people's opinion, but I think the option 2/3
> and SCI draft has some overlap, as mentioned above, and I do not see any
> point to have similar but different drafts.
> It would simply cause some confusion, I think.
> 
> On the other hand, if it is still better to have two distinct drafts,
> that is also one option.
> In that case, we need to clarify the distinction between the two drafts.
> 
> Both drafts describe enumerations (ids) in a similar manner, but one is
> using SCI classes while the other is using Reference class.
> If we cannot define any clear distinction, I think merging them into one
> would be better.
> The option 3 could be extended so that it could include the essence of
> the current SCI draft, for instance.
> 
> I might be still behind discussion, so I would appreciate to hear comments
> from the list.
> 
> Kind regards,
> 
> Take
> 
> 
> 
> > -----Original Message-----
> > From: kathleen.moriarty@emc.com [mailto:kathleen.moriarty@emc.com]
> > Sent: Thursday, April 26, 2012 9:48 PM
> > To: takeshi_takahashi@nict.go.jp; amontville@tripwire.com;
> > mile@ietf.org
> > Subject: RE: [mile] IODEF Reference Format for Enumerations
> >
> > Hi Take,
> >
> > Can you explain more on how you see merging the two into one document?
> > The only concern I have is that specifying the enumerations could be
> > done without including the MITRE specifications right into the
> > document, so we *MAY* not have to worry about the normative references
> > (but I would need to confirm that).
> >
> > One advantage of one document over two would be one registry page for
> > the two IANA tables.
> >
> > This approach would mean that we would plan on an IODEF revision for
> > at least a few small things.
> >
> > How do you see the approach working and what are the thoughts of
> > others on the list?
> >
> > Thank you,
> > Kathleen
> >
> > -----Original Message-----
> > From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp]
> > Sent: Monday, April 23, 2012 9:00 PM
> > To: 'Adam Montville'; Moriarty, Kathleen; mile@ietf.org
> > Subject: RE: [mile] IODEF Reference Format for Enumerations
> >
> > Let me rewrite the sentence:
> >
> > > If Option 3 could cover the rest of the classes including the ones
> > > that do not have any ID yet, I think it is reasonable to merge the
> > > works into one.
> >
> > If Option 3 could cover all the classes (not only the vulnerability
> > class but also the other classes), some of which supports XML without
> > any IDs, I think it is reasonable to merge the works into one.
> > I believe the Reference class can support them with proper extension.
> >
> > Sincerely,
> > Take
> >
> >
> >
> > > -----Original Message-----
> > > From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp]
> > > Sent: Tuesday, April 24, 2012 9:56 AM
> > > To: 'Adam Montville'; 'kathleen.moriarty@emc.com'; 'mile@ietf.org'
> > > Subject: RE: [mile] IODEF Reference Format for Enumerations
> > >
> > > Adam,
> > >
> > > If modifying IODEF is allowed, I do not see any point to define
> > > classes under AdditionalData class (as SCI draft does) since it
> > > makes the XML longer.
> > >
> > > Since the new Option 3 and the sci draft are not that different, it
> > > would be fine for me to combine them into one.
> > > Sci draft defines several containers for each semantics, and
> > > positioned them under AdditionalData class, while new Option 3
> > > defines one container with semantic information that requires no
> > > additionalData
> > class.
> > > (I wonder whether we really need the semantics or not if we use the
> > > option
> > > 3 approach, since the location of the Reference class inside IODEF
> > > document indicates the semantics.)
> > >
> > > If Option 3 could cover the rest of the classes including the ones
> > > that do not have any ID yet, I think it is reasonable to merge the
> > > works into one.
> > > I do not see any point to have two drafts for similar issues.
> > > That will just confuse users.
> > >
> > > The remaining issues for the SCI draft were as follows in my
> > > understanding 1. "namespace identifying specification" needs to be
> > confirmed 2.
> > > copyright issues needs to be clarified 3. schema needs to be
> > > reviewed
> > >
> > > The merged work will inherit the above issues, and I am happy if you
> > > could lead the work.
> > > How does that sound to everybody?
> > >
> > > Sincerey,
> > > Take
> > >
> > >
> > > > -----Original Message-----
> > > > From: Adam Montville [mailto:amontville@tripwire.com]
> > > > Sent: Tuesday, April 24, 2012 7:44 AM
> > > > To: Takeshi Takahashi; kathleen.moriarty@emc.com; mile@ietf.org
> > > > Subject: Re: [mile] IODEF Reference Format for Enumerations
> > > >
> > > > Take,
> > > >
> > > > Do you think it would make any sense to combine the two approaches?
> > > > Option 3 could be rewritten to be more aligned with the
> > > >  example you provided.
> > > >
> > > > 
> > > >   id
> > > >   http://www.example.com/path
> > > >   http://www.otherexample.com/path
> > > >   Description
> > > > 
> > > >
> > > >
> > > > Or, perhaps the class information could be referenced in an IANA
> > > > table in a manner consistent with Options 1 and 2...  So, if
> > > > there's a registryId, then some semantic information about the
> > > > types of classes accepted by that registryId could be discovered.
> > > >
> > > > Any thoughts from the list about this general approach?
> > > >
> > > > Adam
> > > >
> > > > On 4/16/12 1:45 AM, "Takeshi Takahashi"
> > > > 
> > > > wrote:
> > > >
> > > > >Hi all,
> > > > >
> > > > >If we are going to update option 3, that would be one direction.
> > > > >
> > > > >IMHO, the option 3 is very close to the expected use of the
> > > > >Vulnerability class of SCI draft. (and some other classes as
> > > > >well) The expected usage of the Vulnerability class of current
> > > > >SCI draft, with CVE identifier, is as follows.
> > > > >
> > > > > > > > SpecID="http://cve.mitre.org/cve/downloads/1.0"
> > > > >VulnerabilityID="CVE-2010-3654"/>
> > > > >
> > > > >The slight difference between the SCI draft and the option 3 is
> > > > >that the SCI draft took a semantic approach (vulnerability,
> > > > >attackpattern, etc.), while the option three takes general
> > > > >container
> > approach.
> > > > >The URLs to the information of the specification (in this case
> > > > >CVE
> > > > >1.0) are described in the IANA table in case of the SCI draft
> approach.
> > > > >
> > > > >I think both approach is viable, but proper description on how
> to
> > > > >choose either of the approaches could be helpful for readers.
> > > > >
> > > > >Thank you.
> > > > >Take
> > > > >
> > > > >> -----Original Message-----
> > > > >> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On
> > > > >> Behalf Of kathleen.moriarty@emc.com
> > > > >> Sent: Friday, April 13, 2012 3:56 AM
> > > > >> To: amontville@tripwire.com; mile@ietf.org
> > > > >> Subject: Re: [mile] IODEF Reference Format for Enumerations
> > > > >>
> > > > >> Hi Adam,
> > > > >>
> > > > >> Thank you for running the list of options by the WG and to
> > > > >> those participating in the decision process!
> > > > >>
> > > > >> We have had a couple of reasons discussed to 'open' up IODEF.
> > > > >>If we get  a volunteer to help with the editing of an RFC5070
> > > > >>soon, then option 3  may be worth considering.  I would expect
> > > > >>that a revision
> > > > to
> > > > >>RFC5070 would  take some time as the list works through issues
> > > > >>and options.
> > > > >>
> > > > >> What do others think about this and Adam's other questions?
> > > > >>
> > > > >> Thanks,
> > > > >> Kathleen
> > > > >>
> > > > >> -----Original Message-----
> > > > >> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On
> > > > >> Behalf Of Adam Montville
> > > > >> Sent: Thursday, April 12, 2012 2:28 PM
> > > > >> To: Adam Montville; mile@ietf.org
> > > > >> Subject: Re: [mile] IODEF Reference Format for Enumerations
> > > > >>
> > > > >> All:
> > > > >>
> > > > >> So far, it seems as though more people are speaking up in favor
> > > > >>of Option  2.  There are also several comments expressing a
> > > > >>desire to choose either  Option 1 or Option 2, but then move to
> > > > >>Option
> > 3
> > > > >>at some point in the
> > > > >future.
> > > > >> I'd like to understand more about what that really means -
> > > > >> choosing one option and then moving to another.
> > > > >>
> > > > >> Would it make more sense to wait until IODEF is "opened" for
> an
> > > > >> update to address this issue?
> > > > >>
> > > > >> For those of you who prefer Option 1 or Option 2, but have not
> > > > >> indicated a preference with respect to later moving to Option
> > > > >> 3,
> > > do
> > > > >> you have an opinion about such a move?
> > > > >>
> > > > >> David Black has put forward some additional insight where, "if
> > > > >> Option
> > > > >> 1 is chosen, the result is a common means of referencing
> > > > >> specifications between the SCI draft and the new draft on use
> > > > >> of the IODEF reference format."
> > > > >> This statement references the notion of requiring the first URL
> > > > >> of
> > > > on
> > > > >> IODEF  element (associated with the )
> > > > >> to
> > > > be
> > > > >> a reference URI from the IANA registry established by the SCI
> draft.
> > > > >>
> > > > >> It would seem, then, that we have deterministic methods of
> > > > >> understanding what a  is, and thus how to parse
> > > > >> it, but that we have several different mechanisms by which to
> > > > >> accomplish
> > > > this.
> > > > >>
> > > > >> Comments? Opinions?
> > > > >>
> > > > >> Regards,
> > > > >>
> > > > >> Adam
> > > > >>
> > > > >> On 4/9/12 11:38 AM, "Adam Montville" 
> > > wrote:
> > > > >>
> > > > >> >All:
> > > > >> >
> > > > >> >There is an identified need to specify a format to include
> > > > >> >relevant enumeration values in an IODEF document.  The initial
> > > > >> >idea is to place enumeration values and their references in
> > > > >> >IODEF's Reference
> > > > class.
> > > > >> >There are several ways to accomplish this goal.  I'll do my
> > > > >> >best to enumerate some options here, then I hope to hear some
> > > > >> >feedback/opinions about the different approaches from the list.
> > > > >> >
> > > > >> >From the Structured Cybersecurity Information draft
> > > > >> >(draft-takahashi-mile-sci-02), we may be interested to include
> > > > >> >the following (not an inclusive list) enumerations in an IODEF
> > document:
> > > > >> >CAPEC, CCE, CPE, CVE, CWE, IEC 19770-2.
> > > > >> >
> > > > >> >The IODEF Reference class is described in 3.9.1 of RFC 5070,
> > > > >> >where
> > > > a
> > > > >> >Reference must have a ReferenceName and zero or more of URL
> or
> > > > >> >Description respectively.
> > > > >> >
> > > > >> >For each option described below, we can consider use of the
> > > > >> >IANA
> > > > >registry.
> > > > >> >The registry may be used to identify the identifier category
> > > > >> >and potentially the appropriate identification format for that
> > > category.
> > > > >> >
> > > > >> >
> > > > >> >Option 1: Simple ID
> > > > >> >===================
> > > > >> >The first option would simply embed the relevant identifier
> in
> > > > >> >the ReferenceName element of the Reference class.  This may
> > > > >> >look like the
> > > > >> >following:
> > > > >> >
> > > > >> >    
> > > > >> >        id
> > > > >> >        http://www.example.com/path
> > > > >> >        http://www.otherexample.com/path
> > > > >> >        Description
> > > > >> >    
> > > > >> >
> > > > >> >Using this option, a variety of specific identifier formats
> > > > >> >could
> > > > be
> > > > >> >specified.  CVE, for example, would start with "CVE-" and this
> > > > >> >convention may be registered in an IANA table.
> > > > >> >
> > > > >> >No changes to IODEF are required for this option.
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> >Option 2: ID with coupled ID type
> > > > >> >=================================
> > > > >> >The second option would prepend the identifier with it's type,
> > > > >> >which may look something like the following.
> > > > >> >
> > > > >> >    
> > > > >> >        id_type:id
> > > > >> >        http://www.example.com/path
> > > > >> >        http://www.otherexample.com/path
> > > > >> >        Description
> > > > >> >    
> > > > >> >
> > > > >> >Using this option, a variety of specific identifier types
> > > > >> >could
> > > be
> > > > >> >specified, such that the identifier itself would not
> > > > >> >necessarily be constrained, nor would new identifier formats
> > > > >> >necessarily need to
> > > > be
> > > > >> >specified in the future.  An IANA table may be used for this
> > > > >> >solution as well.
> > > > >> >
> > > > >> >No changes to IODEF would be required for this option.
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> >Option 3: ID with type expressed in Reference attribute
> > > > >> >=======================================================
> > > > >> >The third option would require opening IODEF to update the
> > > > >> >Reference class with an attribute, which may look something
> > > > >> >like
> > > the following.
> > > > >> >
> > > > >> >    
> > > > >> >        id
> > > > >> >        http://www.example.com/path
> > > > >> >        http://www.otherexample.com/path
> > > > >> >        Description
> > > > >> >    
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> >Changes to IODEF are required for this option.
> > > > >> >
> > > > >> >
> > > > >> >----
> > > > >> >
> > > > >> >I look forward to fielding responses to these options,
> > > > >> >including any additional options you may see, but which are
> not listed.
> > > > >> >
> > > > >> >What is your solution preference?
> > > > >> >
> > > > >> >
> > > > >> >Regards,
> > > > >> >
> > > > >> >Adam W. Montville | Security and Compliance Architect
> > > > >> >
> > > > >> >Direct: 503 276-7661
> > > > >> >Mobile: 360 471-7815
> > > > >> >
> > > > >> >TRIPWIRE | Take CONTROL
> > > > >> >http://www.tripwire.com
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> >_______________________________________________
> > > > >> >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 trammell@tik.ee.ethz.ch  Fri Apr 27 02:55:14 2012
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 21C2721F8869 for ; Fri, 27 Apr 2012 02:55:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.089
X-Spam-Level: 
X-Spam-Status: No, score=-6.089 tagged_above=-999 required=5 tests=[AWL=0.510,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id knSr1BUyxZqv for ; Fri, 27 Apr 2012 02:55:13 -0700 (PDT)
Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 0471521F863B for ; Fri, 27 Apr 2012 02:55:12 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id AB6B6D9309; Fri, 27 Apr 2012 11:55:11 +0200 (MEST)
X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch
Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 3xPcEmwU2WHz; Fri, 27 Apr 2012 11:55:11 +0200 (MEST)
Received: from [10.0.1.2] (cust-integra-121-161.antanet.ch [80.75.121.161]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 631D9D9307; Fri, 27 Apr 2012 11:55:11 +0200 (MEST)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=us-ascii
From: Brian Trammell 
In-Reply-To: <4F998229.9000307@ieca.com>
Date: Fri, 27 Apr 2012 11:55:10 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <9AEC90B2-E65C-4101-B25B-71342BB08FE8@tik.ee.ethz.ch>
References: <4F996930.1000400@ieca.com> <4F998229.9000307@ieca.com>
To: Sean Turner 
X-Mailer: Apple Mail (2.1257)
Cc: mile@ietf.org
Subject: Re: [mile] early AD review of mile-iodef-xmlreg
X-BeenThere: mile@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Apr 2012 09:55:14 -0000

Hi, Sean,

Thanks for the review! A couple of replies, inline...

Cheers,

Brian (author hat)

On Apr 26, 2012, at 7:13 PM, Sean Turner wrote:

> It's also just dawned on me that adding a second expert reviewer will =
cause some interesting issues with the registry.  I've cued the IANA =
folks about this so they'll be looking for it.  Here's the issue:
>=20
> Right now you get to the XML namespaces/schemas through this page:
> https://www.iana.org/protocols
> Jari Urpalainen is listed as the XML schema expert reviewer
> to get to the iodef schema use the schema link:
> https://www.iana.org/assignments/xml-registry/schema.html
> so now we'll have to add the IODEF Expert Reviewer somewhere in the =
iodef row and it'll need to be clear that the reviewer is not in lieu of =
Jari it's in addition to Jari.  It'll also needs to be clear that the =
IODEF expert reviewer is only reviewing for IODEF-correctness and that =
Jari gets the last word on the XML.  Not sure if we need conflict =
resolution text.

Good point. I already talked to Michelle Cotton at IANA about _how_ the =
check should be implemented. This is the origin of the text in this =
document (which was _not_ in the mile-template revision of the =
language): "...to be noted in the most appropriate way" as opposed to =
inserting a note in a specific place at the top of the registry (where =
there is no present annotation of any expert). We suspect the note would =
be put next to the note designating the schema expert.=20

The document (section 2) also says changes for IODEF are subject to an =
"additional" review, though indeed it should be made explicit that this =
review is only for IODEF-correctness, as well.

> Again, this is just a heads up - nothing to do now.  I'm sure some =
wording will be needed in the IANA considerations section, but they'll =
help write it.
>=20
> spt
>=20
> PS - Sorry to expose all this process gunk to the WG, but I don't want =
anybody to be surprised later on.
>=20
> On 4/26/12 11:26 AM, Sean Turner wrote:
>> Just some nits that will undoubtedly result in some extended process
>> discussion with IESGers:
>>=20
>> 1) Please add "Updates: 5070" to the header. I think that somebody =
will
>> claim we're changing the registry in RFC 5070 hence it's updating =
5070.
>> If for some reason it goes the other way and somebody argues it's not
>> updating 5070, having LCed something with an updates header and then
>> removing it will probably avoid the question about whether another =
IETF
>> LC is needed.

Done in working copy of -01 rev...

>> 2) Add some text to the IANA consideration section that instructs =
them
>> to point to this document in the reference column for the
>> urn:ietf:params:xml:schema:iodef-1.0 row. I'm sure IANA do this
>> regardless, but recently some IESGers have had IANA considerations on
>> the brain and it's better to be explicit about it.

Done in working copy of -01 rev...

I'll wait for the end of LC (next Wednesday) before posting a new =
revision.=

From kathleen.moriarty@emc.com  Fri Apr 27 06:19:44 2012
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 59B0021F85F2 for ; Fri, 27 Apr 2012 06:19:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.547
X-Spam-Level: 
X-Spam-Status: No, score=-10.547 tagged_above=-999 required=5 tests=[AWL=0.052, 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 qjpbh2D5a3gU for ; Fri, 27 Apr 2012 06:19:42 -0700 (PDT)
Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 5635221F85EF for ; Fri, 27 Apr 2012 06:19:41 -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 q3RDJeEE012485 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Apr 2012 09:19:40 -0400
Received: from mailhub.lss.emc.com (mailhubhoprd02.lss.emc.com [10.254.221.253]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Fri, 27 Apr 2012 09:19:23 -0400
Received: from mxhub23.corp.emc.com (mxhub23.corp.emc.com [128.222.70.135]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q3RDJKBV030987; Fri, 27 Apr 2012 09:19:22 -0400
Received: from mx06a.corp.emc.com ([169.254.1.106]) by mxhub23.corp.emc.com ([128.222.70.135]) with mapi; Fri, 27 Apr 2012 09:19:20 -0400
From: 
To: , , 
Date: Fri, 27 Apr 2012 09:19:17 -0400
Thread-Topic: [mile] IODEF Reference Format for Enumerations
Thread-Index: AQJqn32zOrRFJnR8j7J0GMvAnatt3wH7qlpEAfiWW3oBNw/zdgKGFwCgAlbI8l6VIw41MIAAXwog
Message-ID: 
References: <001701cd1bad$5608c580$021a5080$@nict.go.jp>  <009701cd21b5$94967d20$bdc37760$@nict.go.jp>  <007801cd23fc$6408c700$2c1a5500$@nict.go.jp>  <001c01cd244c$f1e31d00$d5a95700$@nict.go.jp>
In-Reply-To: <001c01cd244c$f1e31d00$d5a95700$@nict.go.jp>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EMM-MHVC: 1
Subject: Re: [mile] IODEF Reference Format for Enumerations
X-BeenThere: mile@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Apr 2012 13:19:44 -0000

Hi Take,

I think there is a misunderstanding and hopefully we can clear that up.  I =
was not aware that you had changed the most recent version of the SCI draft=
 to include a standard way to represent enumerated values.  I will read thr=
ough the updated SCI draft and ask that others on the list do so as well.  =
Your description of options below is helpful as well, thank you!

As a WG we will need to come to a consensus on how to handle the two types =
of representations now covered, specifically, schemas where data is not rep=
resented in the base data model and the method of representing enumerated v=
alues so that we will be able to send and receive them in a standard way.

My opinion: I think that we should use the base IODEF data model when possi=
ble and extend when needed (others, please chime in on your thoughts of how=
 this should be approached to assist with a decision on the representation)=
.  For this discussion, that would mean using the reference class for enume=
rations with one of the examples Adam proposed (Take, this would just mean =
updating the draft to use the option preferred by the WG) and then guidance=
 on when to extend IODEF to include other schemas.

I thought this was not covered and was hoping we could avoid the problems w=
ith the lack of normative references depending on how the enumeration draft=
 was written.  I am fine to go forward in one draft if that is the preferen=
ce.

Thank you very much for all of your hard work on the SCI draft and I am sor=
ry there was confusion I may have caused.

Best regards,
Kathleen

-----Original Message-----
From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp]
Sent: Friday, April 27, 2012 4:08 AM
To: Moriarty, Kathleen; amontville@tripwire.com; mile@ietf.org
Subject: RE: [mile] IODEF Reference Format for Enumerations

Hi Kathleen,

Thank you for your email.
I would like to know why you propose to have new draft to describe CVE-ID
regardless of the existence of the ongoing SCI work.
I am confused.

The benefit of using enumeration values (identifiers, such as CVE-ID) was
discussed on this mailing list last September (see the discussion around
Sept. 2011).
Thus the SCI draft is changed to reflect the discussion since then.
Regarding the CVE, the SCI draft is recommending to embed CVE-ID and not to
embed the raw XML if no special reason exists.

> Can you explain your thoughts behind the equivalence so that we can see
> if there is another option for consideration?

So, if a sender wants to embed CVE-ID, what would be the suggested way?
If the sender follows the SCI draft, he could write the following XML.



If the sender follows the option 3, he could write the following XML or the
likes.


    CVE-2010-3654
   http://www.example.com/path
   http://www.otherexample.com/path
   Description


For me, both could be fine, but having two similar ways to convey CVE-ID
should be avoided since both sender and receiver of the IODEF will be
confused.
At least, some navigation should be clearly described in both drafts.
So, I would like to hear why you propose to have new draft for conveying
CVE-ID in addition to the SCI draft.

I have no intention to insist that SCI draft has the right way, and if
community finds better way to convey the CVE-ID, we could simply forget
about the sci draft and work for the new direction. I just think having two
similar but different draft should be avoided since it causes confusion to
receivers/senders of IODEF documents.

Thank you.
Take



> -----Original Message-----
> From: kathleen.moriarty@emc.com [mailto:kathleen.moriarty@emc.com]
> Sent: Friday, April 27, 2012 7:50 AM
> To: takeshi_takahashi@nict.go.jp; amontville@tripwire.com;
> mile@ietf.org
> Subject: RE: [mile] IODEF Reference Format for Enumerations
>
> Hi Take,
>
> Thank you!  I thought the difference was that the SCI draft specified
> where other schemas would be incorporated into an IODEF document to exten=
d
> the data model.  The enumerations would be specific to allow references
> only to be included directly in IODEF where enumerations are used to poin=
t
> to instances of the schema (CVE#1234).
>
> Can you explain your thoughts behind the equivalence so that we can see
> if there is another option for consideration?
>
> Thank you,
> Kathleen
>
> -----Original Message-----
> From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp]
> Sent: Thursday, April 26, 2012 6:32 PM
> To: Moriarty, Kathleen; amontville@tripwire.com; mile@ietf.org
> Subject: RE: [mile] IODEF Reference Format for Enumerations
>
> Hi Kathleen
>
> > Can you explain more on how you see merging the two into one document?
>
> Yes, I think it would be fine.
> I do not see the benefit of having two drafts for describing
enumeration/id
> values (e.g., CVE-IDs).
>
> > The only concern I have is that specifying the enumerations could be
> > done without including the MITRE specifications right into the
> > document, so we *MAY* not have to worry about the normative references
> > (but I would need to confirm that).
> >
> > One advantage of one document over two would be one registry page for
> > the two IANA tables.
>
> I would be happy to hear people's opinion, but I think the option 2/3
> and SCI draft has some overlap, as mentioned above, and I do not see any
> point to have similar but different drafts.
> It would simply cause some confusion, I think.
>
> On the other hand, if it is still better to have two distinct drafts,
> that is also one option.
> In that case, we need to clarify the distinction between the two drafts.
>
> Both drafts describe enumerations (ids) in a similar manner, but one is
> using SCI classes while the other is using Reference class.
> If we cannot define any clear distinction, I think merging them into one
> would be better.
> The option 3 could be extended so that it could include the essence of
> the current SCI draft, for instance.
>
> I might be still behind discussion, so I would appreciate to hear comment=
s
> from the list.
>
> Kind regards,
>
> Take
>
>
>
> > -----Original Message-----
> > From: kathleen.moriarty@emc.com [mailto:kathleen.moriarty@emc.com]
> > Sent: Thursday, April 26, 2012 9:48 PM
> > To: takeshi_takahashi@nict.go.jp; amontville@tripwire.com;
> > mile@ietf.org
> > Subject: RE: [mile] IODEF Reference Format for Enumerations
> >
> > Hi Take,
> >
> > Can you explain more on how you see merging the two into one document?
> > The only concern I have is that specifying the enumerations could be
> > done without including the MITRE specifications right into the
> > document, so we *MAY* not have to worry about the normative references
> > (but I would need to confirm that).
> >
> > One advantage of one document over two would be one registry page for
> > the two IANA tables.
> >
> > This approach would mean that we would plan on an IODEF revision for
> > at least a few small things.
> >
> > How do you see the approach working and what are the thoughts of
> > others on the list?
> >
> > Thank you,
> > Kathleen
> >
> > -----Original Message-----
> > From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp]
> > Sent: Monday, April 23, 2012 9:00 PM
> > To: 'Adam Montville'; Moriarty, Kathleen; mile@ietf.org
> > Subject: RE: [mile] IODEF Reference Format for Enumerations
> >
> > Let me rewrite the sentence:
> >
> > > If Option 3 could cover the rest of the classes including the ones
> > > that do not have any ID yet, I think it is reasonable to merge the
> > > works into one.
> >
> > If Option 3 could cover all the classes (not only the vulnerability
> > class but also the other classes), some of which supports XML without
> > any IDs, I think it is reasonable to merge the works into one.
> > I believe the Reference class can support them with proper extension.
> >
> > Sincerely,
> > Take
> >
> >
> >
> > > -----Original Message-----
> > > From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp]
> > > Sent: Tuesday, April 24, 2012 9:56 AM
> > > To: 'Adam Montville'; 'kathleen.moriarty@emc.com'; 'mile@ietf.org'
> > > Subject: RE: [mile] IODEF Reference Format for Enumerations
> > >
> > > Adam,
> > >
> > > If modifying IODEF is allowed, I do not see any point to define
> > > classes under AdditionalData class (as SCI draft does) since it
> > > makes the XML longer.
> > >
> > > Since the new Option 3 and the sci draft are not that different, it
> > > would be fine for me to combine them into one.
> > > Sci draft defines several containers for each semantics, and
> > > positioned them under AdditionalData class, while new Option 3
> > > defines one container with semantic information that requires no
> > > additionalData
> > class.
> > > (I wonder whether we really need the semantics or not if we use the
> > > option
> > > 3 approach, since the location of the Reference class inside IODEF
> > > document indicates the semantics.)
> > >
> > > If Option 3 could cover the rest of the classes including the ones
> > > that do not have any ID yet, I think it is reasonable to merge the
> > > works into one.
> > > I do not see any point to have two drafts for similar issues.
> > > That will just confuse users.
> > >
> > > The remaining issues for the SCI draft were as follows in my
> > > understanding 1. "namespace identifying specification" needs to be
> > confirmed 2.
> > > copyright issues needs to be clarified 3. schema needs to be
> > > reviewed
> > >
> > > The merged work will inherit the above issues, and I am happy if you
> > > could lead the work.
> > > How does that sound to everybody?
> > >
> > > Sincerey,
> > > Take
> > >
> > >
> > > > -----Original Message-----
> > > > From: Adam Montville [mailto:amontville@tripwire.com]
> > > > Sent: Tuesday, April 24, 2012 7:44 AM
> > > > To: Takeshi Takahashi; kathleen.moriarty@emc.com; mile@ietf.org
> > > > Subject: Re: [mile] IODEF Reference Format for Enumerations
> > > >
> > > > Take,
> > > >
> > > > Do you think it would make any sense to combine the two approaches?
> > > > Option 3 could be rewritten to be more aligned with the
> > > >  example you provided.
> > > >
> > > > 
> > > >   id
> > > >   http://www.example.com/path
> > > >   http://www.otherexample.com/path
> > > >   Description
> > > > 
> > > >
> > > >
> > > > Or, perhaps the class information could be referenced in an IANA
> > > > table in a manner consistent with Options 1 and 2...  So, if
> > > > there's a registryId, then some semantic information about the
> > > > types of classes accepted by that registryId could be discovered.
> > > >
> > > > Any thoughts from the list about this general approach?
> > > >
> > > > Adam
> > > >
> > > > On 4/16/12 1:45 AM, "Takeshi Takahashi"
> > > > 
> > > > wrote:
> > > >
> > > > >Hi all,
> > > > >
> > > > >If we are going to update option 3, that would be one direction.
> > > > >
> > > > >IMHO, the option 3 is very close to the expected use of the
> > > > >Vulnerability class of SCI draft. (and some other classes as
> > > > >well) The expected usage of the Vulnerability class of current
> > > > >SCI draft, with CVE identifier, is as follows.
> > > > >
> > > > > > > > SpecID=3D"http://cve.mitre.org/cve/downloads/1.0"
> > > > >VulnerabilityID=3D"CVE-2010-3654"/>
> > > > >
> > > > >The slight difference between the SCI draft and the option 3 is
> > > > >that the SCI draft took a semantic approach (vulnerability,
> > > > >attackpattern, etc.), while the option three takes general
> > > > >container
> > approach.
> > > > >The URLs to the information of the specification (in this case
> > > > >CVE
> > > > >1.0) are described in the IANA table in case of the SCI draft
> approach.
> > > > >
> > > > >I think both approach is viable, but proper description on how
> to
> > > > >choose either of the approaches could be helpful for readers.
> > > > >
> > > > >Thank you.
> > > > >Take
> > > > >
> > > > >> -----Original Message-----
> > > > >> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On
> > > > >> Behalf Of kathleen.moriarty@emc.com
> > > > >> Sent: Friday, April 13, 2012 3:56 AM
> > > > >> To: amontville@tripwire.com; mile@ietf.org
> > > > >> Subject: Re: [mile] IODEF Reference Format for Enumerations
> > > > >>
> > > > >> Hi Adam,
> > > > >>
> > > > >> Thank you for running the list of options by the WG and to
> > > > >> those participating in the decision process!
> > > > >>
> > > > >> We have had a couple of reasons discussed to 'open' up IODEF.
> > > > >>If we get  a volunteer to help with the editing of an RFC5070
> > > > >>soon, then option 3  may be worth considering.  I would expect
> > > > >>that a revision
> > > > to
> > > > >>RFC5070 would  take some time as the list works through issues
> > > > >>and options.
> > > > >>
> > > > >> What do others think about this and Adam's other questions?
> > > > >>
> > > > >> Thanks,
> > > > >> Kathleen
> > > > >>
> > > > >> -----Original Message-----
> > > > >> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On
> > > > >> Behalf Of Adam Montville
> > > > >> Sent: Thursday, April 12, 2012 2:28 PM
> > > > >> To: Adam Montville; mile@ietf.org
> > > > >> Subject: Re: [mile] IODEF Reference Format for Enumerations
> > > > >>
> > > > >> All:
> > > > >>
> > > > >> So far, it seems as though more people are speaking up in favor
> > > > >>of Option  2.  There are also several comments expressing a
> > > > >>desire to choose either  Option 1 or Option 2, but then move to
> > > > >>Option
> > 3
> > > > >>at some point in the
> > > > >future.
> > > > >> I'd like to understand more about what that really means -
> > > > >> choosing one option and then moving to another.
> > > > >>
> > > > >> Would it make more sense to wait until IODEF is "opened" for
> an
> > > > >> update to address this issue?
> > > > >>
> > > > >> For those of you who prefer Option 1 or Option 2, but have not
> > > > >> indicated a preference with respect to later moving to Option
> > > > >> 3,
> > > do
> > > > >> you have an opinion about such a move?
> > > > >>
> > > > >> David Black has put forward some additional insight where, "if
> > > > >> Option
> > > > >> 1 is chosen, the result is a common means of referencing
> > > > >> specifications between the SCI draft and the new draft on use
> > > > >> of the IODEF reference format."
> > > > >> This statement references the notion of requiring the first URL
> > > > >> of
> > > > on
> > > > >> IODEF  element (associated with the )
> > > > >> to
> > > > be
> > > > >> a reference URI from the IANA registry established by the SCI
> draft.
> > > > >>
> > > > >> It would seem, then, that we have deterministic methods of
> > > > >> understanding what a  is, and thus how to parse
> > > > >> it, but that we have several different mechanisms by which to
> > > > >> accomplish
> > > > this.
> > > > >>
> > > > >> Comments? Opinions?
> > > > >>
> > > > >> Regards,
> > > > >>
> > > > >> Adam
> > > > >>
> > > > >> On 4/9/12 11:38 AM, "Adam Montville" 
> > > wrote:
> > > > >>
> > > > >> >All:
> > > > >> >
> > > > >> >There is an identified need to specify a format to include
> > > > >> >relevant enumeration values in an IODEF document.  The initial
> > > > >> >idea is to place enumeration values and their references in
> > > > >> >IODEF's Reference
> > > > class.
> > > > >> >There are several ways to accomplish this goal.  I'll do my
> > > > >> >best to enumerate some options here, then I hope to hear some
> > > > >> >feedback/opinions about the different approaches from the list.
> > > > >> >
> > > > >> >From the Structured Cybersecurity Information draft
> > > > >> >(draft-takahashi-mile-sci-02), we may be interested to include
> > > > >> >the following (not an inclusive list) enumerations in an IODEF
> > document:
> > > > >> >CAPEC, CCE, CPE, CVE, CWE, IEC 19770-2.
> > > > >> >
> > > > >> >The IODEF Reference class is described in 3.9.1 of RFC 5070,
> > > > >> >where
> > > > a
> > > > >> >Reference must have a ReferenceName and zero or more of URL
> or
> > > > >> >Description respectively.
> > > > >> >
> > > > >> >For each option described below, we can consider use of the
> > > > >> >IANA
> > > > >registry.
> > > > >> >The registry may be used to identify the identifier category
> > > > >> >and potentially the appropriate identification format for that
> > > category.
> > > > >> >
> > > > >> >
> > > > >> >Option 1: Simple ID
> > > > >> >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > > > >> >The first option would simply embed the relevant identifier
> in
> > > > >> >the ReferenceName element of the Reference class.  This may
> > > > >> >look like the
> > > > >> >following:
> > > > >> >
> > > > >> >    
> > > > >> >        id
> > > > >> >        http://www.example.com/path
> > > > >> >        http://www.otherexample.com/path
> > > > >> >        Description
> > > > >> >    
> > > > >> >
> > > > >> >Using this option, a variety of specific identifier formats
> > > > >> >could
> > > > be
> > > > >> >specified.  CVE, for example, would start with "CVE-" and this
> > > > >> >convention may be registered in an IANA table.
> > > > >> >
> > > > >> >No changes to IODEF are required for this option.
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> >Option 2: ID with coupled ID type
> > > > >> >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > > > >> >The second option would prepend the identifier with it's type,
> > > > >> >which may look something like the following.
> > > > >> >
> > > > >> >    
> > > > >> >        id_type:id
> > > > >> >        http://www.example.com/path
> > > > >> >        http://www.otherexample.com/path
> > > > >> >        Description
> > > > >> >    
> > > > >> >
> > > > >> >Using this option, a variety of specific identifier types
> > > > >> >could
> > > be
> > > > >> >specified, such that the identifier itself would not
> > > > >> >necessarily be constrained, nor would new identifier formats
> > > > >> >necessarily need to
> > > > be
> > > > >> >specified in the future.  An IANA table may be used for this
> > > > >> >solution as well.
> > > > >> >
> > > > >> >No changes to IODEF would be required for this option.
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> >Option 3: ID with type expressed in Reference attribute
> > > > >> >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > > > >> >The third option would require opening IODEF to update the
> > > > >> >Reference class with an attribute, which may look something
> > > > >> >like
> > > the following.
> > > > >> >
> > > > >> >    
> > > > >> >        id
> > > > >> >        http://www.example.com/path
> > > > >> >        http://www.otherexample.com/path
> > > > >> >        Description
> > > > >> >    
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> >Changes to IODEF are required for this option.
> > > > >> >
> > > > >> >
> > > > >> >----
> > > > >> >
> > > > >> >I look forward to fielding responses to these options,
> > > > >> >including any additional options you may see, but which are
> not listed.
> > > > >> >
> > > > >> >What is your solution preference?
> > > > >> >
> > > > >> >
> > > > >> >Regards,
> > > > >> >
> > > > >> >Adam W. Montville | Security and Compliance Architect
> > > > >> >
> > > > >> >Direct: 503 276-7661
> > > > >> >Mobile: 360 471-7815
> > > > >> >
> > > > >> >TRIPWIRE | Take CONTROL
> > > > >> >http://www.tripwire.com
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> >_______________________________________________
> > > > >> >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
> > > > >
> > > > >
> >
>