From nobody Fri Apr 11 14:11:06 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 958171A03CE for ; Fri, 11 Apr 2014 14:11:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.072 X-Spam-Level: X-Spam-Status: No, score=-12.072 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZJjqhF4VTaM7 for ; Fri, 11 Apr 2014 14:10:51 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id CD2F71A0766 for ; Fri, 11 Apr 2014 14:10:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10059; q=dns/txt; s=iport; t=1397250646; x=1398460246; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=viaISUnR9XYe0el59qQjj+6OZSwEA9COKBn5B+kID6k=; b=cp/vfHOppE9/jQOttgCgqhrwKypmqxbPINvVvmDZx6QLBDg3lplsBjO5 Y4xKmvysA1CbT/ZfRIS1cVQozr4r8/9uAvnHo5Uzvssf+fH356PFgy/Pf dX7n0Tn7H0mbWX+/rY/pfTaLd82N/0hYrJcKtPysW1DzS8U3egLifEO9u c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkIFAEVZSFOtJA2D/2dsb2JhbABPCoJCRDtXuiuIdIEeFnSCJQEBAQQtTBACAQgRBAEBCx0HMhQJCAEBBA4FCBOHYQ3LXxeJRYRFBgsBCRYxBgEGgx6BFASBVZhAkQ2DMYFyOQ X-IronPort-AV: E=Sophos;i="4.97,844,1389744000"; d="scan'208,217";a="314057185" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-9.cisco.com with ESMTP; 11 Apr 2014 21:10:45 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s3BLAjwP020233 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 11 Apr 2014 21:10:45 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.98]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0123.003; Fri, 11 Apr 2014 16:10:45 -0500 From: "Panos Kampanakis (pkampana)" To: Trevor Freeman Thread-Topic: IODEF Future Use Cases Thread-Index: Ac9FQwh8b9+2zKmER8i/7ag4qXoXbgQh2dJg Date: Fri, 11 Apr 2014 21:10:45 +0000 Message-ID: <1C9F17D1873AFA47A969C4DD98F98A750FBB139B@xmb-rcd-x10.cisco.com> References: <3704d32cb076476898cd54787a09d599@DFM-TK5MBX15-05.exchange.corp.microsoft.com> In-Reply-To: <3704d32cb076476898cd54787a09d599@DFM-TK5MBX15-05.exchange.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.150.28.155] Content-Type: multipart/alternative; boundary="_000_1C9F17D1873AFA47A969C4DD98F98A750FBB139Bxmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mile/R76vCTnzU3Tb9jQYfJsfmudJriM Cc: "mile@ietf.org" Subject: Re: [mile] IODEF Future Use Cases X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 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, 11 Apr 2014 21:11:02 -0000 --_000_1C9F17D1873AFA47A969C4DD98F98A750FBB139Bxmbrcdx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thank you Trevor. I incorporated them. They will be in the -03 version coming soon. Panos From: Trevor Freeman [mailto:trevorf@exchange.microsoft.com] Sent: Friday, March 21, 2014 4:44 PM To: Panos Kampanakis (pkampana) Cc: mile@ietf.org Subject: IODEF Future Use Cases Hi Panos, Kathleen said you were considering adding future use cases for MILE to the = guidance document. Here are some suggestions for such use cases. Fake Hosting Companies See http://blog.dynamoo.com/2014/02/on-trail-of-3nt-solutions-llc.html Seems that it pays for criminals to set up foreign hosting companies to fro= nt their activates - maybe not a real surprise. The WHOS statement cannot b= e acceptable in today's environment. Service providers should be required t= o be proactive not reactive to cybersecurity issues. Given the modern monit= oring tool set it is pretty trivial to identify bad content for yourself. Y= ou just have to look. Since we have independent data on servers hosting mal= ware, national CERTS could monitor how effective the service provider are a= t policing their customers. MILE\IODEF could be used to notify a national C= ERT when ISP identifies and takes action to clean up an incident as well as= CERTS notifying ISP when they are aware of incidents. This would help iden= tify bad ISPs i.e. those who deliberately or consistently do a bad job dete= cting and addressing malware on server they host (cos they are the ones hos= ting the malware) Suspicious Certificates A third party may become aware of some suspicious\questionable uses for a c= ertificate. The third party may be a web crawler or an isp or network appli= ance. Yes they could perform the revocation check on the certificate themse= lves but that is not definitive. A better check would be to forward an IODE= F message to the CA with the full context of bot the certificate and its us= e. That exchange can be automated i.e. the IODEF message has the full conte= xt and allows the CA to confirmed if they did indeed issue the certificate.= If that checked out a IODEF message could be sent to the subject, in case = the certificate was legitimately issued but the keys stolen. Phishing\Spearfishing attacks Spearfishing attacks in particular are a great attack vector and their exis= tence are of great interest to cybersecurity analysts. When an email inspec= tion has its suspicion raised about a message, generating an IODEF message = to the subjects organization and or an ISAC about the incident would help a= lert the analysts. Again some of the response could be automated e.g. if t= he message requires visiting a site with malware, the tolls could check out= any URLs in the message to establish if malware is preset. The site could = be up for a short duration so may not have been identified or has tools to = shield it from unintended browsing. Hope this helps Trevor --_000_1C9F17D1873AFA47A969C4DD98F98A750FBB139Bxmbrcdx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thank you Trevor.=

I incorporated them. T= hey will be in the -03 version coming soon.

Panos

 

 

From: Trevor F= reeman [mailto:trevorf@exchange.microsoft.com]
Sent: Friday, March 21, 2014 4:44 PM
To: Panos Kampanakis (pkampana)
Cc: mile@ietf.org
Subject: IODEF Future Use Cases

 

Hi Panos,

 

Kathleen said you were considering adding future use= cases for MILE to the guidance document.

 

Here are some suggestions for such use cases.

 

Fake Hosting Companies

 

See http://blog.dynamoo.com/2014/02/on-trail-of-3nt-solutions-llc.html=

 

Seems that it pays for= criminals to set up foreign hosting companies to front their activates = 211; maybe not a real surprise. The WHOS statement cannot be acceptable in = today’s environment. Service providers should be required to be proactive not reactive to cybersecurity issues. Given th= e modern monitoring tool set it is pretty trivial to identify bad content f= or yourself. You just have to look. Since we have independent data on serve= rs hosting malware, national CERTS could monitor how effective the service provider are at policing their cus= tomers. MILE\IODEF could be used to notify a national CERT when ISP identif= ies and takes action to clean up an incident as well as CERTS notifying ISP= when they are aware of incidents. This would help identify bad ISPs i.e. those who deliberately or consisten= tly do a bad job detecting and addressing malware on server they host (cos = they are the ones hosting the malware)

 

Suspicious Certific= ates

 

A third party may become aware of some suspicious\qu= estionable uses for a certificate. The third party may be a web crawler or = an isp or network appliance. Yes they could perform the revocation check on= the certificate themselves but that is not definitive. A better check would be to forward an IODEF message to = the CA with the full context of bot the certificate and its use. That excha= nge can be automated i.e. the IODEF message has the full context and allows= the CA to confirmed if they did indeed issue the certificate. If that checked out a IODEF message could be= sent to the subject, in case the certificate was legitimately issued but t= he keys stolen.

 

Phishing\Spearfishing attacks

 

Spearfishing attacks in particular are a great attac= k vector and their existence are of great interest to cybersecurity analyst= s. When an email inspection has its suspicion raised about a message, gener= ating an IODEF message to the subjects organization and or an ISAC about the incident would help alert the analys= ts.  Again some of the response could be automated e.g. if the message= requires visiting a site with malware, the tolls could check out any URLs = in the message to establish if malware is preset. The site could be up for a short duration so may not have been = identified or has tools to shield it from unintended browsing.

 

Hope this helps

 

Trevor

--_000_1C9F17D1873AFA47A969C4DD98F98A750FBB139Bxmbrcdx10ciscoc_-- From nobody Fri Apr 11 14:13:12 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2968C1A030A for ; Fri, 11 Apr 2014 14:13:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.062 X-Spam-Level: X-Spam-Status: No, score=-12.062 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2DiIwyDiU4xo for ; Fri, 11 Apr 2014 14:13:05 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 5CB791A0306 for ; Fri, 11 Apr 2014 14:13:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=67684; q=dns/txt; s=iport; t=1397250783; x=1398460383; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=JT7OsyL0NCqluYr9J2NOz1vLyWD6q9fH9nwADS48lj0=; b=j54fVW/TQtwmF4icDD0OsCqatBVQeJtGnJvrqjSrOADVttdwzZNXruTL 7LIhGL+DQ6Fj951jL/X2DR1QqeffWbujVqj3C7x2VxB7izv+BtWEeUH85 d9fD9JgthpH1tQRb1qHVpr391wdTaUDM0BSfkTaR4i9BLvKundSYQHwGi U=; X-Files: image001.png, image002.png, image003.png, image004.png : 19522, 3172, 2971, 3305 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFAHVZSFOtJA2E/2dsb2JhbABZgkJEO1fDH4EeFnSCJQEBAQMBBQEfAgYBGzUJAgIBCBEEAQEGAQEBAhYHBwIFDwEPDBQJCAEBBAEJCAEIBg2HWQgNy18XBI4GEQEWCRYWAQEJAQaDHoEUAQOSFwGZCoMxgXI5 X-IronPort-AV: E=Sophos;i="4.97,844,1389744000"; d="png'150?scan'150,208,217,150";a="317110201" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-8.cisco.com with ESMTP; 11 Apr 2014 21:13:01 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s3BLD1nx024085 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 11 Apr 2014 21:13:01 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.98]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0123.003; Fri, 11 Apr 2014 16:13:01 -0500 From: "Panos Kampanakis (pkampana)" To: Tim Freestone , "mile@ietf.org" Thread-Topic: Document reviews Thread-Index: Ac8IpBtrPHYWJK+YSRuUsmxBbiV/ZRNJmqBg Date: Fri, 11 Apr 2014 21:13:01 +0000 Message-ID: <1C9F17D1873AFA47A969C4DD98F98A750FBB13CB@xmb-rcd-x10.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.150.28.155] Content-Type: multipart/related; boundary="_007_1C9F17D1873AFA47A969C4DD98F98A750FBB13CBxmbrcdx10ciscoc_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mile/OHssFCEVyFCmtHgF8ab2pxVjnm0 Subject: Re: [mile] Document reviews X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 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, 11 Apr 2014 21:13:09 -0000 --_007_1C9F17D1873AFA47A969C4DD98F98A750FBB13CBxmbrcdx10ciscoc_ Content-Type: multipart/alternative; boundary="_000_1C9F17D1873AFA47A969C4DD98F98A750FBB13CBxmbrcdx10ciscoc_" --_000_1C9F17D1873AFA47A969C4DD98F98A750FBB13CBxmbrcdx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Tim. I am just following up on this. > draft-ietf-mile-iodef-guidance-02: > Sections 3 and 4 look like they will be useful once complete. I am quite = interested in the Restrictions section (section 4.6) Working on it. First need to address some low hanging fruit for -03. > Are there any reports of the interworking done in section 5.2 that can be= referenced? Unfortunately no. > It would be useful to list the modules in section 5.4 that are available = and whether they are open source Fixed. It will be in the -03 version. > Having example IODEF data in Appendix A is good Thank you. Panos From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Tim Freestone Sent: Friday, January 03, 2014 11:57 AM To: mile@ietf.org Subject: [mile] Document reviews Hi, I have reviewed the following 2 documents: - The Incident Object Description Exchange Format v2 (draft-ietf-m= ile-rfc5070-bis-02) - IODEF Usage Guidance (draft-ietf-mile-iodef-guidance-02) - See my comments below. Note that I don't have any CSIRT experience or backg= round and am looking at IODEF more from a security point of view in terms o= f how we can help to ensure the data transmitted is valid and so not leakin= g sensitive information or letting in malicious data which could compromise= the CSIRT. draft-ietf-mile-rfc5070-bis-02: Section 1.4: 5th bullet typo - complementary Section 2.6: Should this be "A hexadecimal byte is encoded..."? Section 3.2: Incident Class. The Indicator-set-id attribute does not appea= r in the diagram Section 3.8: For the Additional Data Class which allows any data to be tran= sferred - may want some mechanism to prevent the contents of the data from = being executed automatically? Section 3.11.1: Reference Class. The diagram does not show the 4 attributes= for this Class Section 3.12: Assessment Class. The diagram only shows 2 of the 4 attribute= s for this class Section 3.13.1: History Item Class. The diagram does not show the indicator= -set-id or indicator-uid attributes Section 3.14: EventData Class. The diagram does not show the indicator-set-= id attribute Section 3.14.2: typo "related" -> "relate" Section 3.15: Expectation Class. The diagram does not show the indicator-ui= d or indicator-set-id attributes Section 3.18.1: Counter Class. The diagram shows 5 attributes, but the word= s indicate there are 3 attributes and then describe 4 (leaving out "meaning= ") Section 3.18.2: Address Class. The diagram does not show the indicator-uid = attribute Section 3.19: Service Class - typo "a a" Section 3.19: Service Class. The diagram does not show the indicator-uid or= indicator-set-id attributes Section 3.21.1: RecordData Class. The diagram does not show the indicator-u= id or indicator-set-id attributes Section 3.21.2: RecordPattern Class. The text indicates 4 attributes, but d= escribes 6 Section 7: Examples have the IODEF-Document Version as 1.0 not 2.0 Section 7: Is it worth including an example with some of the new fields for= this version? Section 8: The IODEF Schema indicates that Service Class has been extended = by email address, email subject and x-mailer, but these are not described i= n the text (section 3.19) Section 8: The Service Class schema shows elements for Email Subject and X-= Mailer as well as EmailDetails which is the same set of elements? Section 12.2: Reference [18] could be RFC 6545 and Reference [19] could be = RFC 6546 now? General: The extensibility in the data model increases the risk of data lea= kage or inbound malicious data through the extensions mechanism. Is it poss= ible that over time, profiles defining what can and can't be sent will be d= efined for use between CSIRTS to ensure that only the expected data is tran= sferred? draft-ietf-mile-iodef-guidance-02: Sections 3 and 4 look like they will be useful once complete. I am quite in= terested in the Restrictions section (section 4.6) Are there any reports of the interworking done in section 5.2 that can be r= eferenced? It would be useful to list the modules in section 5.4 that are available an= d whether they are open source Having example IODEF data in Appendix A is good Kind Regards, Tim Freestone, Solutions Architect Deep-Secure Ltd. Direct +44 (0)1684 212 703 Mobile +44 (0)7884 588 757 Office +44 (0)1684 217070 Email tim.freestone@deep-secure.com Address 1 Nimrod House, Sandy's Road, Malvern, WR14 1JJ www.Deep-Secure.com [Description: cid:image002.png@01CB4F5A.42BCEE00] [Description: Description: twitter_32] = [Description: Description: linkedin_32] [Description: Description: youtube_32] The information contained in this e-mail message, and any attachment theret= o, is confidential and may not be disclosed without our express permission.= If you are not the intended recipient or an employee or agent responsible = for delivering this message to the intended recipient, you are hereby notif= ied that you have received this message in error and that any review, disse= mination, distribution or copying of this message, or any attachment theret= o, in whole or in part, is strictly prohibited. If you have received this m= essage in error, please immediately notify us by telephone, fax or e-mail a= nd delete the message and all of its attachments. Thank you. --_000_1C9F17D1873AFA47A969C4DD98F98A750FBB13CBxmbrcdx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks Tim.=

 

I am just following up= on this.

 

> draft-ietf-mile-iode= f-guidance-02:

> Sections 3 and 4 look like= they will be useful once complete. I am quite interested in the Restrictio= ns section (section 4.6)

Working on it. First n= eed to address some low hanging fruit for -03.

 

> Are there any reports of t= he interworking done in section 5.2 that can be referenced?

Unfortunately no.=

 

> It would be useful to list= the modules in section 5.4 that are available and whether they are open so= urce

Fixed. It will be in t= he -03 version.

 

> Having example IODEF data = in Appendix A is good

Thank you.<= /span>

 

Panos

&n= bsp;

 

 

From: mile [ma= ilto:mile-bounces@ietf.org] On Behalf Of Tim Freestone
Sent: Friday, January 03, 2014 11:57 AM
To: mile@ietf.org
Subject: [mile] Document reviews

 

Hi,

 

I have reviewed the following 2= documents:

-  =         The Incident Object Des= cription Exchange Format v2 (draft-ietf-mile-rfc5070-bis-02)

-  =         IODEF Usage Guidance (d= raft-ietf-mile-iodef-guidance-02)

-  =          

See my comments below. Note tha= t I don’t have any CSIRT experience or background and am looking at I= ODEF more from a security point of view in terms of how we can help to ensu= re the data transmitted is valid and so not leaking sensitive information or letting in malicious data which could com= promise the CSIRT.

 

draft-ietf-mile-rfc5070-b= is-02:

Section 1.4: 5th bullet typo &#= 8211; complementary

Section 2.6: Should this be = 220;A hexadecimal byte is encoded…”?

Section 3.2: Incident Class. Th= e  Indicator-set-id attribute does not appear in the diagram

Section 3.8: For the Additional= Data Class which allows any data to be transferred – may want some m= echanism to prevent the contents of the data from being executed automatica= lly?

Section 3.11.1: Reference Class= . The diagram does not show the 4 attributes for this Class

Section 3.12: Assessment Class.= The diagram only shows 2 of the 4 attributes for this class

Section 3.13.1: History Item Cl= ass. The diagram does not show the indicator-set-id or indicator-uid attrib= utes

Section 3.14: EventData Class. = The diagram does not show the indicator-set-id attribute<= /p>

Section 3.14.2:  typo R= 20;related” -> “relate”

Section 3.15: Expectation Class= . The diagram does not show the indicator-uid or indicator-set-id attribute= s

Section 3.18.1: Counter Class. = The diagram shows 5 attributes, but the words indicate there are 3 attribut= es and then describe 4 (leaving out “meaning”)

Section 3.18.2: Address Class. = The diagram does not show the indicator-uid attribute

Section 3.19: Service Class = 211; typo “a a”

Section 3.19: Service Class. Th= e diagram does not show the indicator-uid or indicator-set-id attributes

Section 3.21.1: RecordData Clas= s. The diagram does not show the indicator-uid or indicator-set-id attribut= es

Section 3.21.2: RecordPattern C= lass. The text indicates 4 attributes, but describes 6

Section 7: Examples have the IO= DEF-Document Version as 1.0 not 2.0

Section 7: Is it worth includin= g an example with some of the new fields for this version?

Section 8: The IODEF Schema ind= icates that Service Class has been extended by email address, email subject= and x-mailer, but these are not described in the text (section 3.19)<= /o:p>

Section 8: The Service Class sc= hema shows elements for Email Subject and X-Mailer as well as EmailDetails = which is the same set of elements?

Section 12.2: Reference [18] co= uld be RFC 6545 and Reference [19] could be RFC 6546 now?=

General: The extensibility in t= he data model increases the risk of data leakage or inbound malicious data = through the extensions mechanism. Is it possible that over time, profiles d= efining what can and can’t be sent will be defined for use between CSIRTS to ensure that only the expected data is= transferred?

 

draft-ietf-mile-iodef-gui= dance-02:

Sections 3 and 4 look like they= will be useful once complete. I am quite interested in the Restrictions se= ction (section 4.6)

Are there any reports of the in= terworking done in section 5.2 that can be referenced?

It would be useful to list the = modules in section 5.4 that are available and whether they are open source<= o:p>

Having example IODEF data in Ap= pendix A is good

 

 

Kind Regards,=

Tim Freestone, Solutions Architect

Deep-Secure Ltd.

Direct    +44 (0)1684 212 703

Mobile  +44 (0)7884 588 757

Office    +44 (0)1684 217070

Email      tim.= freestone@deep-secure.com
Address  1 Nimrod House, Sa= ndy’s Road, Malvern, WR14 1JJ
www.Deep-= Secure.com


3D"Description:

 

 

3D"Description:  3D"Description:   3D"Description: 

The information contained in this e-mail message, and any a= ttachment thereto, is confidential and may not be disclosed without our express permission. If you are not the intended recipient or a= n employee or agent responsible for delivering this message to the intended= recipient, you are hereby notified that you have received this message in = error and that any review, dissemination, distribution or copying of this message, or any attachment thereto, in who= le or in part, is strictly prohibited. If you have received this message in= error, please immediately notify us by telephone, fax or e-mail and delete= the message and all of its attachments. Thank you.

 

--_000_1C9F17D1873AFA47A969C4DD98F98A750FBB13CBxmbrcdx10ciscoc_-- --_007_1C9F17D1873AFA47A969C4DD98F98A750FBB13CBxmbrcdx10ciscoc_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=19522; creation-date="Fri, 11 Apr 2014 21:13:00 GMT"; modification-date="Fri, 11 Apr 2014 21:13:00 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAANsAAABNCAYAAAAvvBEeAAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAEvCSURBVHja 7X13XFTXtr/35r77bnv33fJyUzSJsUZjLDF2Y8VeUbGg2HtLjDFoNLHEgooFFRURQURAOgwwjAMM jIBDryMMMHRGGZgzjWEggPu31pnCYRhkLDe/JNc/vp+Bmb3Xbuu711r77LN3t6NHj3YjhPQGDP2p 0NwFXkDmMMA/sC1MwHd/6yT930zTdgZI+yepVDpULJE8ExJARUXFJ5D+DUtlm0KtVg+USLouqzNU SCTDJBLqo07a8dsKqfQTyQvKNshvbm7uC7J+Y0b+/0E/DbNEDtYB0mJf/e5F++qXCOykXhqKqlWn Z7RWnLvQWnH+YqeoAkjOXzCLJ4CaLiDVo/bcs2FI15U8LLPa8XwrFcZq1dbX+zIVHRXix5YWd0Vi UmsFpKHbAJ9KQXJrS2vrTXMKY0aB/h4Sygq/4erWeu36jWfiuosrfjadOHk66crV6zw//8BQTgxv M8h425KBiIvj777lflvbVTld1QHqqvby9t1k0o7/8gsIvAm/N+vr+cLyPW571rFYrBFM+WKxuI+X l0/WDdebFsuBzx8dHM4KoL5cqO/XQL5B/wlkGyqNjiXlW3eQ1DffIendP+iANEAWQNj9ffLIBPmA IoDYDEoApYDyd98nFYBKPaoYf5uC+Rvmwbylelnmyih6611SPnockZWWJaFSMWdyRW1dTPFSW2O7 0uBTbLeGqOWK+/h7V50jFlcMdrvl8fTwkWPkyNHjXeAHcvTYcXLK4SxxOO1ITp9xJBedLhPXm+7l bDbnGyjvv59B6jeA1PyTp87Qcrouq/M6nHI4Q5yv3YhgyheJRP998dLlnOMnTr2UfGwfnf/48RlM +Xw+fwW21XLZhr46A311ljieu0Cgn1UxMbwvfu1kG1wRGNxSuGotSQGFTO3ZpwMyALk9e5M8PQx/ 5wMKAUV6GP4uBpR+0JuUAcrNoAJQ2QkqOsmDsko+0MlmllX0Xk9SMXIMeVxQECcyIVtNRSW7cMEi Y7vws2DRUiJ7/DjcIrJVVAxy97itQSU9cdLhuYB5EKhQTpeukMDgEC6U2b8zsoWGht0/c/bcc5dj CpRx2flqsCnZLl2+koyK/TKyT546jW1qPnLkmBVTPpcbY3Ph4qUXk3tCB5R9+crVp9yYmJ2/WrJB jDS4LCCwpdBuHUnp0ZOkfti3DaCgWe9/SPJM8AggAhSZQAwofe9DUs5ABaASUAWoBkj0eMz429x3 1fo8lXoZTJlYhthQLlrO4SNIWU5uB7JVl5SyS+Zbk8z3dO1K6QH1XmRDaiurLCabh+cdzUkgzClQ VCMM/zu0ByozWrRTJukx/xXn6yQ8kp2n1Wr/ZY5sLFYEx/H8xfbl6IGKjIS9aAGuXr9BbnncZpmS DVzb5DOO5zvUC8l50ULZTpeddXByntmObDExNli/DnUH+WcdL7SvO1hAB+wjZj/qgf132/NOM7il n/8qyaYFspV4+7YU2q5qTzYgWnYPsAQffUzEg4aS4kFDaJQCKgFV+k/D348BNR+3QQqoBcgAVCeQ g1wmOksn08uSfty+DCyzesAgIgXrVZybl2pKttICEbt4/kKSB2TL+rAPTbaChYuJpKTMIrJVANnu ePloUCHPgqIi8G9Ufk+vu/U+vvfUTHjeuau+fOVak/M1F2N6Zr6r8H10bOwVc2SLiGRzUBGZedC9 cr15S+t0+QoL8t8B3O0KTleu3mWx2QtNyXbthmvy+QtO7epz6cpVcuOmW+kZx3NelsiGicT75i2P OwkJCe3iq5i4OJsrztc6tPnK1WvgHrrnGOoO+b0cLzjdu3PXR3rj5q2nmKdd3wKwj8DtdvpVkk0K ZCu6c7dFtHxlG9nQovXuR/K/P0oKwljKRz6+eUJvXyHikRnkm4HIBP+2NHe9hUW8uPzKyuqjTALh 30V5eezieTqy5QHZ0MLlAzHLC4stJttdH18NKv05sDoIVFhvb59CiqI+JkT7YXNzcy8DJBJJTy6X OxziL9Ald2MeA1DOnTt3mysqJCNMyQZc41wCq8FMD4r3Y1pGxtqXHWQk2w1Xt2QkM7MdXt6+VbjS +rLy4+L4NkgSZt0vOoHrHBTC7mSV+N3sbOFkzzte4eA6dugn/4AgMaT5y6+ObBVAtnwPz5aCZbYk VU+2rPd7kYLPJ5FHucICNSGjoOV/eBa4/5+RRsgfzS11CzOy2IVzFxjJhp+F4FYWP8q3mGy+9/w0 aMlQURFXr14nYLnOd5VXkJa20f2251NDPgTKQaVkRUScNCUbh3Of4wyyDWkv0y7bFXFaWtofXwXZ brq5J6NiG+XD375+AYJXoURxfL6Ny42bhNnWS5evkmvX3NY/K59QKPzXTTePEie9e4lwAtxyvy2F dv/tV0m2XLdbLY+WriApEAtloFJCLFRoNYNkCZJjf6kNQzJlJaewi+bMb082sHT5ObkWk83PP1CD inkZXB6Ei6sbul9nLKlDbGzc+Ruutwgz/9XrLuSOl7cAyv8zk2z3uTGc6y43Gelu4EJHob29/Ssh m4eHZ7JOZpt8P/8gmKfIH16abEl8G3AvjbJp+TCpwGeXVvmeX0AA9qkhH044gMcuLi7/+6sjG1im wVkuN1uENstJOpAtV0+2ginTSEp8Ap+5nP5LI1tKQhJbPHseETHIJgJLl5uWaTHZAgKDNag4znq4 unkQZ+drjpbUAVzN7t4+vjJmfvz79p272gSBYASTbNyYWA7EZ8Z0111cwTK4vDLLdvv23eTrYH0M 8tESBQaHvBLLxk9Ksrnlcdsom64/XZbr+q7yhrLC/cHqtmv3r5ZsIiBbxvUbLY+WLCO5BqXUk03A i/9Fk+0h/wG7GMhWDO0q0JOtYO58kpWaajHZgoJDNKgABtzy8CTXXFwdLazDbyBuoZXJkB+V/CZ4 EkFBrOlMsoEV5Li5exBmWe7ut5sSEpLWwO/dAR9YgH90RjbPu97JSGZmPfz8AirFYvF4yNfDQvl/ 7YxsHrfvtKs7lnXtmmuXli04NCzS7VZbuyG2hM+bv17LlnPjZkshWLY8BtlEQLa0B4kdyCaRUqPz q6quPyor9xSWlFmAkleAzuVjPfIqK29WSKXjmbtCkEypSQ9py4bP4oqgXY/0lk2YnmUx2ULCwjQ3 QHEM8Lxzl7i63nK0tINDWRH773r70kpEy4BP/F8gSLnAJFtcHJ/j4ellLAfTocLeueP9YxgrQsUK Z6ufhUh2lDqKE12QkZG7wBzZvH3uJeNEwZSPSu4fENjMCo/sUj476r6aGx2TIZVK+5jKT0oS2Hje 8SbMfoK4i3h4eD3TspWVVU0GN13rysjnChMT1BViNvGvk2yP3DxaiiBmM5ANn6MVT51OspNT+Ka7 MoQ5wsia805EuvMLUvvFV6SuC8j27H0+fGn+u07L2PUloU47krysbL7p0n92aiq7BMhlIFshfs6z JiKLYzbpIFB0jRsojgFeQBRQUovJlpKW8b1fQBDBmMYgw+eeP4mOjXNmki2en8C5c9eHMMtCIEFM v+sM/oHBJCw88oQ5svn4BSaD+2qxLFPcBAQFhxJxaWmHXR5JAoHNXZ977dLfvuMFdYkIAcvZHdzp tyUSyTsIw98pKWkroW9LcIIxbW9EZFQZ1YkV/cUvkIhu32kpXmZL8np8QJMNY5xSq+nkUXpWO7L5 gYLmJD2MlI4cS2r++Tape7sHkZniLf3nO+8RWff3CQUy26MnoSA2pN7vBPgbpjHJh7JomXQZ3dvK e/Mdohj8Kcl5kNCBbPnZ2exyIFtxDx3ZkHSl862JOD/fYrKxIiI17uAiGeDt64cKYTHZcoXC7wNB SVGJDDLu+QcSbgzvMpNsfH4iBxWWWdbzAkkcFBrxnTmy+QUGJSOZX0Y+ThoiUdEeMyuvNli2aXok NxBUGcKKUISEsZQ6hCv9g0KU2AdYH2a/3PK4gyukJCY27pIle1d/kc/Zir28W8TLV5FcUOp8g1Ja zSDFOXkdyCZKSw+vmzCF1L7fi9R+2Lc9euo+6/r0J3V9P2qP/gMBH5O6jxCDugam7TewoxyQ3a7M D3oT+cgxpCA5pcMOkmJhPrt63kJSyiBb2UJ8zia2jGxS6aAIdpQGlcYAVAYPT+/nIFv+9yGhLIIz uEEGWqAYHr8d2RISkziosMyyEGhJ7/kH0Yr+LGAaVgSbhEdFHTdHNv+g4GQks6l8/K4r2QagfLBs W8yRDcljKtvTy5smVAdAm/A30/T4G5ARCC2e8qt8qA3menCpj29Lie0q2rIV6pWyfNpMUl4g6kC2 kpyccMUkq45kA4tU2/0DUgd568BC6dCL1PXsQ+qQgAb06k9kvQF9PjKLOvitrle/9nmAULQsg1y6 rPdJ7bsAsHLyIcNJSXpGB7JViIrYNfgQu3tPUmJo1/PsIAGysaM4Gi9QAgP8QemAABaTTQhkA3eJ MGWgpePFtydbYqKAA/FLu3Q+YEXv+QVQUB7fy9vnmQBFfRDGCuelpKRMMke24OCQZF8gs0H2Xb18 sDxPupKNuOvt84AbHcsGt/BNU/lpaRk2ATCBMOv+vMCJBmXw+Ql7fo1Eo8mGeyMr7vm3lK5cTR4B 2QwWoHrGbPJYXNIhZqvKF4UrJ09rTzZ0/YZ+RrRgRRoRc/HTmjSAYjcsXNIG66WkYdEy0rC4Cyxa qkvLyK8F0rTJxs8FRDsbMGMOaYHY7XFJaYppXR+XlrGlIKMcJoFyIH0RtK960RJSW2XZ3kh87SPq frQGXUcDkCjevvcsJltCQtK3EEcRpgwkX3pGxnUm2ZIEyZyAoBBjGiRCcCirVZifv93Pz++3lqAz 1wvJBi5cMlong3wgMViqqEKxWDLkZeVnZOTaBNH94tcOSKBnAfsS86HFZEfd1wLRvvm1Eo0mG+76 rw4IailftZqIGGSTANlqyys6kO2JuCRcNWV6G9mAaLKJU0ndg0S5rLJKQJVVPJSVlgkQdaUVgroy E8B3tfBbZ6hDlJnPZ5BrCmWdLEWj1dibbteqraxmy4BsFXqylUD7nixeSuSPn1hMNk50jMYHFNOA oNAwAhbCYrJFcO47AWmM+dENBSVrEQgE60zJFhgSZkxHu4YBgaVgSf7nVTxng7gpGWIlo3x0Ze/H xCW/CiWiycaou4FM+F0oTCymwMknPILdGhgUmnU/OvYBL45/qKKi4tNfM9GMlq3KP7ClEshWxCDb 4+mzibS0vAPZHhcWhyunMCwbuHLKffaEevo0Ct/Zwrdv/3/A3HM2fMUGyValJ1sZfD5ZZEMoyWOL yRYdE6dhxi2oLBCfWPqc7U/sKK4ILRZTRlh4RGtaWtooJtmSk9M4GK8Y0uCsD25lkYuLy59eBdlA uZNR+Znyo2N5r2QHCZIN+4XZRmwzxLvnsrOFU+H3aUzk5uZPKysrm4ITycu82f6LIxvu+q/0C2ip XGlnJFsJkO3J9FlEUizu0o3EGE2x/1siU9VH/tweaj8uLWXXLYAYDUhWAWRDd1L6nG5kbBxfEwiK Y0B4RBRaBYvIlp2duwpcxlZm/mBQ+OhoXgml1b7HJFtqWjqHBTO+IR0uqsBnMbhvf3kVZAPFTw4F MhvrERpOeDz+KyFbbm6uTXhEW93RNcT6+wUE2P6nEMlispX53GupsG0jW1kPHdkqRYUdFkjKcoVt CyS9+9ELFopv9pNapZL9c5qlkEyVxcXsWoj1JN17kio92Wqsl5An5eUWky0unq8J0scWiMio+0C2 oBNd5RWLy6yAqNWo4O3yszlEkJLmblJXmmxgfYzpMK6DT1G3bt1++yrIBjFRsl6mTj4QOz4+IeVV jFmuUGgTEdlWd5xQsN2hoaHrX5PMdDXS26elYsUqmmzFqJRItmmzSPmjgg5kE2fhauRUmmz0Ujyu Du7dRx7LZD87spUVFIFlA7JBe6oZZHts4Wokko3/IEGD7p0B4ZFRhBcXf99cW7Vabfcisdg2PT3L CxdWIoBYGK8x80OM0gDu02emZIM8HCSyIR26ZZCfEonFk1+abODec+7HJGPdDfJxUSKWF5dHUdTf XgXZTOuO8kMj2K/JZvqcreSud0v5ipU02Ur1ZHs8bSYpyRN2IFthema4HBdEwAIi2WRAtid79pJq qbQd2Yif3xtlT6SbS4uKggsys4ILshjI1CMrpz2M35tLa/I/jcxgUXpmcGlpafATqXSjKdlK8gvY MiDbY2iPBNqFsZsE3MrK4hILyUYNepCQpEErwASbw30az0+ISEpKDkpMEgQnJDwM4nCjQ4CEFfEP EkgcP4EmpWExAIF/xz1IJOkZWb5mJoY3MjOzOEBQ03JIDC9eCnFjcHQML4gbzQvuCpAuWJCS6iuW SHoyLdv9mNhkJARTPhCiFRcouDFxgZbIRvDi+SFZOTmnmO6nEMjGrDsSDSeaCPZrsnUgG748Wr58 JSkGspUZLdtMUpyd04Fs+cmp4XKwbHW9+urI9kFvUrPna1JZU9OObNLm5uFlaemN2m27iHblGqJd v0mPzUS7cSvRbtlO6N+Y2Lxd9xumMWDNBtJgu4Y0rNRjqa3+EcFy3WOBedak6cu9pDAnT2D6nK0o T8ium29NavRkq4bPyvmLSImFL492RjZUJiABATfRCPw/EsiBv5mmR3BjeCRRIMhUq9W9LCUbAgkS wyinK8Tw+CQ5NZ2Iior2M8kWbZ5sdL1in0M+L/4BWMR4PLrg3ddkewGy4XatMiCbuIdu1a4ClLLG aiYRZWV3IJswKTlcPplBtp59wbJ9TSoeP25HtgqtdkJpWHgLNWo8kY8cS+Sj4XPM50Q+YQqRQ8wn nzSNyCebAL/D3z6frEuLeQDU8FGEGvKZDoOHE6r/IEL1+5hQfQbQZFd8NprkJiTGm5KtIDuHJpvU hGzifJHFZEt4KNDoFKc90HKZwtzv+HfiwxSSkCTIBgX9oBOX943MnBwOKr4l5TwLLAA/IYmAO3uS SbaY2PhkKOCl5UcAYe9zY5UJaWkMsolswEIaZSKpkXxsNuc12Zhkw43I+e63W0qWrjCSrRJjnKkz SF5aegeyZfETw6nJVjqy9QNl79WPSL78ipRWV7cjm1itHl8cGt5EgRwKyEOB60kBganpswk1Yw6h Zs0j1NwFhJozXwf8e/Y83W+YBtMCMQ2QjRpHZCPG6jBsJJENGkajDkgnHzeJZMY/iHMyIVteRga7 dt5C+lngY2iXhCabNSkUPrKIbBDPDE4SJP9ojmydAV0/VGpE/IMkUPxEkpaW6QXxX+9nxJdvZOXm 8qJj48jzlGV2EgAAsUmxWHy6TT5YNl5cqjmyPS/QeoPbqUxISOhukF9UJF6BVs+UbBEc7sbXJDMh 26Nb7jTZcA8hkg1PtaqaMp1kC5I7kC2NF0+TTYZk6z+QJlv1ri9JcUVlO7KVqtWTRMGhRDFuIm15 FOMnEQWQBhdXFFYziALcVMX0WUQJ5ELg3/R3+NtEK11azAtWUTFiDFGAdZMDueRg2WTDRxvJJvvo E0JButQYXgey4a7/2rk6sj2BdmHsVvUcb2prtdoPUtMyqtMysmjX7JlIyyCYTufKxTUmPkym0jMy I6uqqlZbsJjzm/z8glsZWTldl2NhPUorKrYyyZaSmpb5KuSnpmcSiAl/xJ37Ri+momIi/0FiC/6G aVL0dUhIaHtw/xp6suXedGspsVluJFu1nmzpiUkdyJYcHRsuA8LoyPaxjmy79xBRaVl7N7K5uXfe Q8Hj2lNniPTb74j08DEdjp0gdSdOARyIzOEsoRwcCXX6HPx9Rv/9KVJ77GRb+oOHdfkBNfYHiWSF HZF9NobIkHRItgGDabIl3+d2IFvGw2S2FCwm7qWs+bAvTbZKIJ8w07L32XSzdukkYX7+2czs3Gci O1d4tqSswjFXKFwpEAiGUmr1wOcZCLCib+U9KjjWVTldIVeY75ifX7QLXUemfCD9gnyRyPFl5UNf OFZJJJtNNxLk54uWCfPb5D8qKPyB0mrffk2yDmS7RZOt7BWSDVEmkcwpqKyKLCivjM4vK+caICqr YKCcAd13zLT5+H+5Do+qqrhZKWk1VavXE+qTT3VkGzjkBciWYzHZXuM1Xq0bCTFbGbiRuDueJlsP IJuZl0eRbOnxfJ0biQ+0PxpEqN79IWb7mpRUVv4kz9nEUmmA5MgPhBrURjb5+MkkPTa+A9ly0tPp mI1JNnQjRbnC12R7jZ+ebPTLox6eLWXLbI2743EhQWo1kzxKz+j48mhiUrgcF0j0ZMPXZZ7s/YaA FftJyFb+uMb/CU22Ye3IlvMgscMrNsKsLHadnmxSPdkkeJSdhS+PvsZr/Bues3m1lC9b2Z5s02aS QnPP2VLTwuVTp7UjW803B0iVVBr+U1S4UloXUHP0OP0IQIauJMRsigmTSf7D5Dizz9kWLDKSjW7X gsWkvLDwNdle46cnG27XEt/1bqlY3pFspcJHHchWnJkZrgQXs41sH5G6nV+QSoXyIRB3HGD084DS w8z3Y6HsDi8qPpbLA6jjp9pWI2myTSFFqelxHY8f1+0gMZIN3ORa68WkSix+KbJRFPWuWCwem5Ag GM3l8owQCNJGSySS0XjV1C9h8PHU4YqKilGCtLQxXF5bO7Bd8P1YXI19AZm/eUV1+82vkmzlPvda qm3t6FdQyvUPf2unzSIVZt/Uzg1XWs1oI1v/QaRu7ARS7er2tCo6tqU6Ora5Oia2RRLLA8S1SHh6 xPNbJPwHOjxIaKlOSNQhUQ/9//ibJD6+pTYzq6W2tjYBj1ljVliqUgUoT50xIdtUUpqZ3fFN7aIi NqUnWw1Ntg9IHe6NLC97brLh60OlpaVrMjKzI/kJiaIHCUkt3BheS9T9aCOiob0PEh82PxSkZmfn 5jpKpNL+XcnNzhZ+mit8FJEnfBSdmyvkvgjyhPkx+fkF/kD0fpa0paysbHLeo0feiUkPUxKTBE2x vPgWDjfG2A5sV0Liwxb4rUwgSL1TWlZm19Vx4HjMnUhU6JKWnhmbkprOBUQLH+Xfl0qlcy2pE5B7 FbYlOSU1GvOnZ2bFFonFF0Qi0e9NynkjVyjc+uiRKDonL6/LPsvJE0bnwGdCUsqhbGH+xidPnkzH V5+6qg9MNG8WFhYfe5lxQYhERZEwMfc3kk3i599Ss3K1kWxVSLZOXrGpfPRIRzb9aiRNOFx+x9hp zAQi/3wKUQCUU2YQ5fTZgDlEOXchUc5fRJSLbIjSZjlRgRVVrVpHVHbriXLNBhqq1Rvo/1XLVxHl 4qVECfWRpWcQJSGzmZ0gU6t1ZPt4qJFsqolTSUWu0OwtNtTCxR3IJq2sfC6ywYD3BpIlJT4U0A+M ccsS7vbAh9CmwO/j+Ikk8WEyESSnyoRFRbs6U1RcPk9Nz+AKUtIJkPQlICBp6VkkX1R0+1ntwHP9 s3PyQuIfJLRi/eIfJNL1NdeW+/ptXChfkJJKsrNzcAfMiM5kJwgE/XmQHuUa6oXP9VLTM10s6WPo qxB8TmfIq5fTCBNIOy+hQiIZCOOgZZZjCXBXTZIghd63mpGVnQ9E3gf9/1Zn9RGKROOSoAwc75cZ G+yDzMxsV5ps+IpNTUBQS43dGlLCIFsd/fJoqdmXR1XTTMgGRKOByv/pKB2GjybU2In0sjy9ewR3 koC1pHeJAOTzFhGF9VKiWLRMB2sb+M4afptPqFlziXzmHFILlhLI1u7iPXlDQ4DK4SxNMsNDbdXE KUSSb/5+NsXCJaS2RxvZZPjyqIX3s+kVtFdCYlIGdhy9BYnDNX4icJsS7swwfM9Mg0r7MDmVPCoo vNYJ2f5LkJLGx3QGeS8KHigRWDi/TpVHKBqSKEiuSIL6GOrLrHNXoCeQJEF1VZVkmzn5XG5cX0in ZspGxY7nJ1y2pJ/j4h/cQ3Ib8qKcGF48JRQK/95+4hMPhcmiiTkGlsDQDlpunG7/KJAuHcb3Q7Pk FwjGRMfEPXc5psB+A8v6kCYbvqldGxTSIrVbayQbbteqmzGbyCorO5BNVlIWrjZatoFtZEPFxwUL fOCs31ZFjZvUtuXKsFVr5lzd1qx5Cwk137o98Dv8bcYcINtcIgP3RmNCNnVTU4Dm7Dki6/dxO7LV Fhd3IBslecxWg5WsxY3VGItC+yi0mlKpRWSjjzBPS2PhrIhbkJiIjXtAHsCsh2RDJeE/SKI71zRd 1P0YnFWbREVFNubJlspDy2Kaz0BkS8FPeEjy8h4FdeKifRb/IKkkJi6+QzmGrVVIeGyngfjm0mE7 YaaXgbxh5sgG+dQoy5AePQBwuS9ZQjYgpS+9mZtRJ6ivzAzZhgCJG8z2NRDpfjSvQ98gwcy1B+sH k12OuYNnkWwwLo3myuF0Uo45oNeRmZX9oAPZxN3bNiIj2aiKjmSrK6+Iapg6nVD//Beh3u5OqHff J/LuPYni/T469P6IKD4arAOQUDlsBFF+OpIoPxtNlGM+J0qwdkogoRIIqJw0lSgnW+mAfwNplOMn 6dJNmU5UySkEyDaP2QkqIFvDaUci6zvQuDeSJluRObJJ2PWLl9Fkw72R1WjZnoNs4DbNAgVoYXY4 7v1DpUxIeijIyslzZ3NjrFPSMr6EWTIKFOspKitzYCKiOLQCgwuTaRordEY2LE+n9Pfr4X+LAJah vqio+ISZ2OOfqWnpRbGgWIZ9i4Z2oNKgmwTuZBOgMDKK6xvPTyyEeI1WRGZ6Qx6dgqbeN13A6JRs /ASLyMaL53cgW3SsZWTDeqFi01Yo6r7atG8gbTOQihj2hjLzYftz8/J8zbjFY7jRsY3myqGtlply zIGf+FADAfz3HdzIYj3ZyumYbTaprehw4M9vFArlvUZolNLxPFFeuEiUFy/pcMlZh8tXifKqixGq GzeJytVNh5vuRHXrNlG5G+BJVB4MGL6/5UE0IWFEVi0pgMmgL7MTFEA29cnTOrJB3FbXdwBNticF RR3IVltdzVaB22jc9Q/tq30ONxJIdMrwbpoBsaAQ4K6FQf4Ox2NXSSRzUlLTRDioprvl0SpIJE8W mZINOMtjpscBhUFuAj//CDcuri+Xy7UIMBP3pSjqjx0XYHL3mbYBQceW8Ql1EMRfqqiQDNNqdSu/ BMhZVlZmnZ6RmYT56LMoTd5swIUgiGnane3IgjqEszmogMa0SJ44C8kG/eqLdTLkRTncmFgzZBMN gb5sYL6xoLe6lSkZGbPZbF4vZr+w2ezeeN4L9idMIk+YZejag5MCv47Sat81JRuMS2O7coBkEMeV pGVnTzct5xnj0s8wyerJFkiTrYjxPlsNkK3GJGbTK8iHdYQsBdj8OwGx2jK1CdGMMRsu/QPZ6gZ8 oiPb55OJpCDfbMwmh5ithvHyqBTIJrPwwJ/wSPZZHBxUOJ3ScYBs/DK86KKzPGq1uh/EFBU4y7bl i9LFPXF8W1OygYXkMdNG6l5hyX8VGwSAQO/yHySIUWEM8g1l8OL4xUCyT5/hQv/r0aP8OFxEMbyj ZnhXD/sEYp7rTOvGYnH7siKj1Myy0DoDCSwkG88XrYYhr86KxMgSEjqSDUjcQL9OpE+rfzWpy2u8 YDKaCHFnnWl/YLmlpWV27ciWIBgD49LILAcnzIzs7MMvvPSPZHviH9jyZNUaUsh4UxvPIKkpKfnZ 3WIj02h0ZMMDXfHkZCTbuAmk6tGjDmR7XFHBpoBshje1K4xkk3RJNvj9jzCL5dKv9+uPYEMlZUWy Y7pcvSwqWoVuHV4CpHvJNJ5e+UvPzDxvcvnHfyUkJPFQrqEMHNz73BghzMYvfapWfr5oOQdiRtNj 5KJjec1FpaUzLIhZ3waXMYHNiW53tAP2SXxCIrrF/91GNlbfUFakmtlf+njWIrJxo3m+OOkY8qIc sCxmLRuQuMHw9jsCPYOQsIhTlpQDbuMxJFsoIz+Wm52b2+7duzggG4xLI7McHMu0jOzvXopseEir 4XQtMYNspkv/PxOy+SvxzQE82QvJ1rs/xIATSKWZpX9JaSl9lB0+zJa0O12r0hKy/Q7cmHuo/HiO iAGc+9E/FpeUHLfgudEIYX7+6tzc3JUZgNz8fDuJRDLTlGxgeXjMMnBwo6K4QtNd+y+ClLQ0d4wv mPWPgLIEyWkhlj40hnYMhli0xricDfHqQ3pFM7aEeXcckg3kq1EpDWWhEkMfWkQ2kOeLk44hL8qB upslG57jgqQ3pKXbGMw6bUk5QaERiwyThjE/lJudnb2uHdniEsbAuDQy00WDBQWyHXopspX7+rVU mjldq7qw+GdHNqqpyVcJlo0mG94F0KsvTbaKnFwzz9lKdAf+mJyuZelztvvR0SeiYCDp49kYR9HF gHuUnJx6TSwWD34Zd48mGz+Bx8JTr/Rl4BFw4RFReGf3Sx1hh/WKiuIE0yd26WXjyVdsNuepWFy6 9nlkAeE+EYmKThQUFJx59KjgTEFh4VmYPL5gvmYTFMTqC2WoQ6B/DOVF6hZhLCIb9LNvBKOuKAcm BnAjEzqQDSa8hmA8yYtRDnxaZNmSU1Nv4pGBQfr8OKZIttLS0g3tyRY3BsalkVkOTIK40HXq5cjm c68d2QznRpoeZacfxHefEDKt7KeHVQUhix8rVcWyHbt1ZAMXEu8FUI79nJRm53QgG/Mou4oXOMoO 3LA9EDfQ5/vjOfRM6FapOI0wc8clPnx4FQLqBXifm7kDY59FNojjeHjsm1E2DmxIWCu4LPfBitwE q+L+LICr6wEKcNB0cQSsaE+oGoXyDLIDg0IJKLVKq6X+9aonQSQblKFGJTaUh2dssi0kG66EIgmM dQ0Ow1OTO5ANTP4Q6PuGQEa76AklJMyhqzIkUulocNGr8LBaZn+jPHwr35RsMC6Nge36D4kdVfcg McmTn5h4q6uxARf8FkzIf2u3XYt5lB2SDW/qfGxmuxa6HjXSuttSmAkkjudJ9fmLOlxwItUXL+ng dNkIyaUrRHLZ2QRXieSqC5FcQ9xoD/z+6nVdGtN8TlfI46vXiPS7w6R2yPC2m3KAbIrR40lxhvmL NZBs1fr39JBs1RjDlZVZ+qb226CwZTjweEuLKfAIb727Q5/zCMpSy43lPUx8KHAE93FSV3sksW+j eXE8HHxT2RizWPJA1fCMDNybdkcQgIvXGyxDve6GG51M/JsXx5eYW0l9ebIF9YUy1NgnhvLoOJfN sYhsrMgoX3TZ2uqKd81FdCSbUDQkPJLTcI/RLnocwiKKhcL8vXh/HFjudgCr/IUgJeUCxK9SdAcN +fAoeHTbkwTJ8aZuNQ/IBuPSyOw/Q1mRFj7QxlgSQolD7chWAmQrBbIVMo4fr8KNyObOjczJ46in ziDyN98h8nfe0+Hd94gC8irwdOT3PiQKPIQHlFvRsy9R9IKYqvcAouwzsA19PybK/oOI8qPB7dEP vuvLSNdnAA3Fh/1oWXKQi0fn0fsyDVdIQX3lo8aSYjO32JQViNi18xfRzw2RbPgmehkeR15SYvEO EnGReH3UfW4LdvqzLonw9dMNRBAMJh66Exgc+hSsXm1ycoqrVCod0inZYuN4OLt2dQnFsxAWzsab TA+2UxYerxcoi8rX5Ox9/8Ag13/HJl8kG5ShRoU0lIeKHR7JtoxsEZG+9H0Bxv4MIMFh4WbJBpNa A/NOAQTeY2DYIWIOOHkhgQ3pvXUXl+ACjqKq6snUDs/9eHFjAoNDGn1NynkeYBmZ2bnO7cgmvuvT Igay5TPIVgpkEwvNnBuZlh4unzBZd0UUKLARhnvZDOg3QLedi4Zu/yS9n9FiDIE8n7Td1Ubf1wYy +7bd/YYnMtP3swHZCs3s+i8pKGDXANlwwQcfaRT30N3PZum5kQYUFRXtiuHF1eNMja4EPQDQkXi3 mXcnwOuZ8KYYdKVieXFSiHHmmiVbNI+HbmoHGSDfV38RR1dgAdlwo60p2aCuKqynQSZ9A4+376VX TTSEN5ANylBjuw3loUsZHh5pUXngGfhi3xry6q6zCjNDNuEQSNtgrs/vPgOm6YDYT+/H8O7nFxVN MvuQnccbExAU1MjsP2Pd9JNBl4B0mZmZV41kM16GuGIlEbYj2wxSnGfmMsRUINu4ifSujNr3ezPQ S3ePGm7j6m0AWCBcosfYCp+L9dMB3xTAbVZIpnbA7/A340WIA/T4SCfLIBPLQILjEeg9PiTyT0eS /E4uQ3wy35omm9hwGSLe11b8/K/YqNXqQSlpaVcjI6NSQCnU/m2XbNADcKeTe8fueHnrCBERqYJZ eaQp2cBq8pCU7fJ5++KlGuYvEjQDiFme5otEG0zJBnVU4f3dBrlonSH91X8L2byD+t719lFjXxjK wzgnLCzcIrIFh7F8sX7G++Og3oGBwR3IlpYmHBISEtZgtq87gbl0IaGslqycPBcYgz93RjYYg0Zm /2E+wyQI/z/talxwXNOys1e1I1uRp1eLePlK+jJE5s2jhVkdXx4tyMiOkc9ZQJ/XSF9qyIT+okMK CEIBWWj0R3xMqAGDAJ+0YeDgjsC3B5hp8NgFzIsy+g3QAWQzy5KhuzplOslPTU8xJZsoL49dZXrz 6AI8pPXFXx6FfL/PzhZ9FsPjrWRzOC6hrMh0cANVwbjIATMzEsX0Rk0Ezoac6JhYyP9PJtnYUfd5 OIDMtDDIrXx+gqunt98UT0/vKZ7encPDy2sqn5+E8eEfTQL8XuDWqpk3fKICALnzu3pd5sXI5t0X ylJjGYbycCIKsZBsgSGhPj73AtrdWgrkM0s2sNANnfVxZ+6caVq8CRYfuTxMTvEw69ayeWOgPo3M /sO/2VHcWh6Pv9Hd03PSs8YFERAaasU8OZomWyGDbG13as8gBSaHtIJ2/Ka0rGxvWTy/uRw6ptTP DOD7MoQfIpCU+TMRZERpJyhrB0ZelOWnk13KKLscOrMsNu4pBMbfmd7PVpCd1+FObZpsolf3pjYq eVpa2gcQM22HuOBKaFi4FGOP2553290XTd9JDe0A5RnJJFskO4qHBGXeQw3pCi155+qZD9ZFFb2g LmrTe65DWeFKiqL+51WTzQ3Iduv2HTXWn3nHt+89y67Xuut9z8fLu+1OcSSDj5+/WbJBfNbAbBP2 M7qGURxuJi8uPtWI+Aep3BheSnAI6xHG0yiz/R3enkjopmxh9gRzZLvr69eIeZh3ocMkePKFl/7N kU0ISllihmzGJVRCJlUQMgsw82eAWU8ImWqGBDTZSuctoEmGZCvEdr1isplxNwcmJCSdBzdDfcv9 Nrl5y8MIdEUEKSlfM8kWHs7moYIa0njAoMJMLBSLxX942UnAx9c/+jYoi0G2G9QHZucGgUAw6Hmt uZ+f319dXFz+R4+/mt4bh2Rzu3VbjQpsKA/LDg4NY3X1OESr1f4rNDRMfMu9LS/2HRBIxupAtrQh oPQNzH7VTSIRqKt/wT41g79n5Obu8AsIrm83Jm7utEuYmPiwwwNxFos9Bqx0oxsjPbqFELsfeimy FXvdpWM2A9nyUDkhZis0ucD+lwT6DBKhEMi20Ei2fPgspmO2rs/6xxdGg0NDfwgICDrlh/ALOMXh xpyCuGuiZTsiuN973vF+esPVjdC4cZOO7Zi74LFvw8IieahkhnSoAGDpHgHZ/vyyfRDGYnuiwhvr AEAy8x8k3rJUhlZL9eTx4lJdb96qdLlxsxyBf3t43Aln7nLBvZFQlhp+a1deUFCIHNr5TEsKfTrM 3z/wR2Y+lAOTjjzBZAcJks33nn8DMy220cXVrctrvGLj+Ec979x9ysxLx9RmbpJlsVhjoK8ame3B 8YuJ4b3c3kixt09L0YpVJKcd2XDpPz/+l3wwTqlIFFk235omWwG0KxcXSugL7LtejeRyuW+53fLQ +IH76qO/4xrdwODg0DqJRDK266Vwdi8gjgaUk1x3cSXXrt+gLduDhKQrTLKBi8NDgmEaBA4qWJ+8 V7FdKy6OvwsV0SAbgfXBh88VUuknlsjg8/l3vLx86EnADa2j3vr6BwQXUYw4USQSfwT904TtZJZ3 082jmcOJmfesMh4+TL6GMk3zBgeHSU2vtBIA2UDpG5jp3MGaXr9+o8uH2n4s1idAHq1hTNryupwx Rzawgo3MtDh+QLbvX4psZb73Wops7UgaKGOunmzFuIOktDz+l0o0RFV5ZUQ5kAtjUHoSgcmkBP63 ZAcJDPKfvX38ypyvuZArV6/TuOx8jXZvQsMj8GyUvz4rP5vLXQQK+iPmpwH54f8WLjdmHZNsQcEh PJiViSEdKpznXe/iV/HgGaxjH6+73jVXQSazHjhbh0dGxZs7UImJCA5nKS54YB5j/mvX6QkhJJTl xXQP4e9/hISxcq+BUjLLwv/9AoNFuJprdiuYRDIeXDlFuzKwr4DUAUFBd0yfCQoEaUPu3PVuaKuP C53W2flal3sj/YKCBrm6uTcw+8PVzQPH9oyZHTFjIG0jM63HbS98u+DF3Uh8ebTcP6ClaNUakgJk y0Sl/OBDkv/pCFIlSK5VEBKoIsRfDVBZAMVPBAvqESDJzn5cNG4CyXv/QyPZSnFvpAXX/OLewqDQ UH8kwqUrV41wuuxMz/KBwSERppcaGpCdLezn5e1DK54hHxIVlFzD4nI/ZpLNPyCIhwPKLAPktwIp vf38ghZBrGQZAgKW4AlZpsoZHMo6d8OkDZegDTijgyWKY7N5Y0xXMmEC/geXG30GLTPWu33eqxD7 eRJuTIy1absfJCY6YvyE8pn9hXEPO4pTLJVKB5tsvZoQFh4pMW0/AurcyuPxFpmWAfHmkNt3vBqY aa/fcMNyuiQbm80eDJa54XK7vDfxswPZoO/HwNg3MtuPE66np5eQzebs8vUNWGjZ2ATZ8Ph8XC3+ LQ744Mrg0JaiNetpsqV+2FdHOFDQoumzSd2x40R24hQNhQlUAPXxNtQDNCZogDRaQOMLAvOiDFO5 9cfbl600qZv8hxOkdO4Cktezt45oBsu2ZCmhnjyxaIEkKSllKbo35y84kQsXL7WD3gVR+fsHeHA4 3EMpaWmHYBAOhYSE+ru735ZegUFipscBBvcnWQwWk0k2P/8AHv5mKt/gUuGnJUB356bbLSkM8Psm seeHGPs4XbrSTv75C5fIVZitQdHrwYLngRJd8/D0OgiuErp0RTRBgSim9cLvYIZPE1MdY0pwrwdC DFTJLOsiXZYTXRa4tDW379y9DG7yQfj7Big+bdFMy8C+u+vtEydid3SlkWzQ7w3M9LSMC05dkg3y DjaX9/zFS2bI5jcG6tx40ekyMU2PfWPpuOjjZG1CQsJHNNmqQ1ktxWs3GMmGyEblfPc9kvN/b5Gc f/6L5P7zLZIPKGSgCFACKPvHW6RcjwpAFUDCwGNI8wRQo4f0n2+T2mfAkA7zPDaRhbIrGeVh2SX6 urTV7V90XfPe6dFGNEAWkK1w6QqiksksPYPkD34BgWE4qzmeu0DOIc5fpD/xf4MSoZXwvONFcKHj irNOeRwNaQFnHc/TZEgSCDaYPtT28fXnoXIa0iIc9fKZ33UFrAuU0+jg5NThhVuweEuh/NZ29dKX QRMCFIpWInAvsT34v7k64P8YA/L5Cas6jRP5/NU4QRnSM/NiHVEBXfXl4P+mafATiE9y83PnmI9D BUPQOjHrdfmKM+btkmwssGwwuZjkhbE9f7ED2cCtGAOkbzTt5xcZF5w8wMJ9SpPtMSuiRbxuYzuy IXIYimoAPvQuxGdWDBTjazm40ZeBSnwzGg/ZMYPHXcBcniq9TGYZ+KKr2KQuRfo6mtYbJw9sX+Ey W1JPURYv/eNO/uDg0Cc4o585e84sTp9xJA4A/DT9DYmGcV5cHD/Y3Hatu96+8Tggncm2FFjO6bPn 1MePH+/TSQz5FRCq4SIQ+3lln0b5oGQ4qQiSU91M3U7TVWCIB4+ie4bKZq5POutD7Acg0tOkpKQv OpPP4yUMBWuhZebFyQH6v0uyeXp6D4b2N2BfMfOePuvYgWye3t5jIG3jqxgXmExbwVIOxc4Z8oQV /rQYYjbBm++Q5O4fGJECyOj+PsllIAcgBIgAhSYofvd9UgooY6AcUAGoBFQBqi1AlR6V+rzlJjJL AMVmyhfp65ZrgiwAtgXbJ1q4hGiVSvbzrLJCrDEMgvIwnJVxZjvlcIacPHWanDp91vg3/T/8bfjf AX7Dgbx23UUb/+CBm7kFDyQbuG0JqJSY/uVAk73Vydm504NhuTFx1u4ed3IwjkIl6LQdjP9R9mVn Ooaq5cXF7bH0/T0eL+4bsKZS9AqM5TD6p93fUAZ6BDAplaelpW3uyhWEcXjKbPsF6GfoQ6cu68Tl fYquebu8YNnByl8y85xtAlr7Uy89Lmdp1zuIxfoMB3ygpqiINIBpLxo/iRRPntYBZYDqyVZGVOk/ nwBqGZDqP+sAeNONYlJHKBlQAdQMMH8zl5fSy2aWZUCNSd0MKAeI9e3A9qlBsVuam0Ofd+c7HgHA 4XDWQCyRDG5LM7oGSDxUWiYMMQe4STIfH19fCPLHPnubk5/1bc875Tfd3KWAJy+KWx63a0NDwx6A sv7fs8qDuOqfXl5+O8HVy4HJ4Gn7dlzQ4zytwLoV1FtPwLLfzM7O/uR5V98EgrQRkZHsCFBwNZZj cKkNMLhYrjfdqCgONyA7WzSgK5kURf3Jx+eek7vHbamrm3sN4p5fgCQmLs7OgrxvBQWH3gPrWWPM e89fwuVyV5tZyX3Pz88/CMcF073ouEBZspBQVrZYLHmXXnUDOJGWltjmOor3Y11dBzSa+c6AZhM8 67eXxbPkdla/xnb5KB5pbuZBe2e9xMPy34lE4lFcbszWM2ccN2GgHxwSyg8MCo5xdr72naur2yaB IGWdREK9+xwycefD/74k/vY8GxBw8sAH9BFszjZwwTZ5+9y7ExIaFh8YHMI9f97paw8Pz825ubmr mHs5XxTgiveNi0vY4OR0eYuPj793cCjrAVh098vO1+i+0mq1PV5gHJht/+u/K6++X194XLSE/N1w VgtT6G/+U/Dv2K3yS34e+VO34z/1BqH/uAa/xmu8JttrvMZrsr3Ga7zGa7K9xmv8UslG2du/r3Zw GvRT3fpI+vX7L8ra5iutk/OIn0NnUDOte0onzez/k7WfkN8qV67fQW3cOelVyVRu3DybWrN2ndbT 81219YrPiMl7ZxbU6Q2t/eFP1NY2/X5OikrNtflAOnB4n1fa/2lp/1Tv2fcdNXBc9y7TQj9Cn4zQ Ojl1f2myEYr6q3LZqkJq6szHFJf7vz9VJ9YNH12pPnhk589hQJULlx5TzFsU8CrO2bdYiSbPyJPN sT76quQpZi9wlk2cFqN1c/9KaWNb2OziOcCSfGo3z/HS9dtpZVZ/+z1fPtf61s/pql3qc6vDtUNG 4vHtv9WcOb/gVchsFgj6KZavbpX+5c1RnaXRHDk+j3Jw+JPW3v4d1ZLlRU3evvteimyoXE1uHnPk cxcR1ZQZRH3k5CY98/+oOXnmqx+P/HBJGxQ0mkpL+6tm74E96q++Oa51cOjexOZ82cTm0vvktEGh y5uuuc7SOrm838Ri2zcdPLxb6+1n3czi9m04fPyC9uCRQyQh7R06LYs1qvnwsbPqfQf21w0dWaS2 /26DoR7NHO7GZm/fLfXfHTmrdb62t9nPb3j9V984aJycNhmWjLVe3tath487aY8cW43PvfDQFs2e fRvr9x+6CNa5B+Gm/a/m6InjDUdPXGxms3vDbDTux+9/uKg9dvxUc0JCb1oGl/tWw0mH0/XfHz3Z HBCwtYmfNBfK3QhW9gvtEYe3m/yC9mkdHL+o37ffsdk7aLC+fn/TfHdsu+rr/Wea3D13alzcjO9p EQe/P2vPX/6m2f7bixpXt/W0heBw1je5udsqd+7ZpTl09AjRv3UMZb+j2WO/HyaZo/LPp+ZR0+ca B1C7e/ebmlOnT6p2fXVOe9xxGLaviRuzQ+vmYY2zsPa7I/ZEq/0/bULCe81szjdNLu7bmg8edtK6 uCyhyTZlhgP1+ZSIZk/Pfprrbu5ELKY3Jqt371vean/oEpBwI1iu96D8A43fHbkA6Qa1pmTM0m7Y +kRjuyZT6+i0SuPkvEnr6k6/JAm/D2k8DH1nf/AbGL838a1nULjdTSdPzlZ9se+8+tjJ+SaW8R9N x05uaQGdaQoIoO8TgDLXNh847KQ+cMS4i1/j7DL7R/hOuffAl9Thw+9pff3siUTyJtS3j9bDcx/l 4vIXGOcNTW6eW4Fch5o8vL/Sunt+03Dr9lXF3EWtqv2H7jQHBJ1pCgqit3ZBvv+BfAe0Dk7Gjdha p8urWmHc1ddc6LvxtN7eI0BHzoNuHNGKxT2aRaJeisUraiTd/jBM6+m7uMnTm26L2slpNOj2do3z NXvVHOsfG789Et7M56/Turi5wOSFt9K8oT52fHnzd0ectOed1qBeNvN4o5p8/b6Cuu5vRN3lcunj C0GH95FDRy+BLg3RVSoh4RNQoDtKaxuWYv3mYOW6zQ9wVqNW2B1WLLSpaVy/hdXs5b1dteOLgHrb NbUwG/irjx+foP7KXqb+5lv6ojflpm0c2YhxruC6TCBLbIlm49ZmzR1vV8US29SGLTt4Grt1ecqN 29hQqalq2zV1DRu3S6EcSjN6IlEfOLhGP1C/V3+9X9hivYwo127OV82YRxTLVymVK1bnaRfaEFQE 7Xlna7nNysqG7bvDlEttpZrjJ7+rP/zDPZXtGlX96k0szcHDU5WLlrmrFi8vbti4LayJw1mgOXvu euPOPZx6u3U1qi0744lQ2FO+eDm/fsnyKtWm7UVk6UqiOefkVv+V/U2Fja2veuKkT5tmLSBg6UXK WQvKlLZrq4lI9KF6/8EA1VxrpdJuQ1LrvMVEPn2Oh3HmdXQeqtq2m6XZtOO+2nY10bq6rVTt+PJ6 0+wFRLFuc44ab1ldsPgaDMI/lCvXCuttVtYoFi9PUQ4d2ULNnLvHqIT7DsxVrdkQpl63OUm+xLau NSN3tmrvN8XYfqXdOgH0SU39nn0CIPSs1hVrCLSnVWWzUlAPfaY547RKYTXrODVpWrj6D3/pBfVW NsfFDQcrdUU+0aqkwXZNvHrrjhNaT6/j2p17YuptbOPlNsuzYFL8tt5qlkI1fmq1epndvrrBn51Q rtnIB8UdLJ82p7B+9YYs+F6qsFubjRMFNXJ8ptrGVqZcu6mUmjpLq16/eXybG7v1gHqJraphzcYw zYGDdmqny7sUS1ZUNuz4Mky+1Fap3L3HFhR1e8PyVUSzal2Kym69X92IMVMVq9b9CBPhoKaIiLny BUsaKCurd+TL7fIItnH3V7Ea+4MByvWbOfXfHwunhoxolc9ZmFj/zbfRigU2Wpjg3wSltn66dhPo iPMYWqcPHrYGUmq1azdGgaU+pvHzm6tYtkqjWrdJqF68vFK1eZuwOUEwhlq8QiL93d+HyBcuC1NY L/Wmva2Bw+xV+w6Uqr7a5yofNqpZZb0sr+Guz1ml7Rqp9M33+tTvtT+tWr6qVb1h60PVgsUNyrXr d6oPH99NbFYR0IFa9YIldcpV6x6Bro+AsjQtazeFKPfY2+oG+PDxr4FUpap1mxPV+w/xqWlzGsDE 9pcvWHRJNXGaGGZmvPT79/IVqxNh0Ms1l6/NwV0PoESlqm27wukZdfHye7U9+15Qz5w7Tj5haj0o +TQgzEblpGmNQCAn1frNoXKr2Y1QmTDF7IWl4Lb2UDu7DFeOmfQEyLbeQDbVxm3JSuxkQv5Q99nY O4pZCzj4t2L+EoFi8bIzCutlfqqZc4tV337voFpuVwTkyK7/9vvM+qUrldrLzstwk6x89sIYaqLV Q7W9PX24Tmtu7kLVXvtT8mmzY2SfTylVbt1tp5g1XwtWcyjRkneVNitbNQe+v6TetN1ZPnXWbcrK eqh84nSZevveAc0OjgPw70a/oDOKqbNq1d8d3oEy5fMXhcsmzXBlzOh/BWu3W7581Xn1qM8pmLgO Srv9drZ8/pJKtIj1R0+cqR04NFZ95NgO+cx5zeApjCNOTr+TfTo6i5o+/xuGO99d63DGXjFnobNs 1PgGzTXXbTAppUOfcegZdf3mebLREyj11p0LZaMnqqDvFtP9b7smVjFzvg/0l4N80nSWtNvv+ihm LijTenp/D+W1aLbvnmYsQyL5WHPgu33yqTPcZIM/U1OTJvVUrFzLrpu1gD5aoPa93scUi5ZFyRct uySfbZ2NM7fWz28iZTW7RW1/cLO0Z7/7YHkdcIeE0na1XLnjSy+DbPns+T9ops6mlDv3LqbHbcmK TKhXhurQEQfV0pW18sUruAoMV6xmGd+slnT7XX/5HGtpMzdhAFiq6dTnUyupuXPfUiyAMV+0zBd3 xqjXbLxKTZlxV33ccaAcDAA13KoHxlHU9DkSzbGTJ5TbdvrK5y2KMxyUpNy9d3P91Fmk4fS5C2ht les3hUJ7clE/qMNHhsmnz23WOF0+Il+yvBzJRk2w8gLQ1zE/+etb21EPMaajZi2oUNofntqM99/N Xiipm289U77ARqmyP0if+a9Ys+GkfOb8Us0Jh0vyz8ZVgCc1QLl991TQNUrj6DhXO2/Rj+rjJzej 8aJ3jshX2PHB9WiATHGK+YvjFZ9Pfao8eHgXcXD4I8w8Lqq5i+rVazd/Ay7av1QzF1wHt0eudbq2 X7V1d6Vq+276aln5yrWBtb36X6AmWX2uXGIrwe+kHw3aogLi1h8/GV1/6AhLfejoFcXcxb51oyeE 0tYA3D/ZqAklDDfy96qtO1JU278Q0L/PmHtZvWaDj06Z1kZBw09QI8b7aFZvrKr/4WRE47eHA8Gt 20fShH3Uazf5qGbOq1d/f/SY9vCRtxQr1rAVM+YrNMeOf6Ncu0Go3LAlFWbDS7LJM4V1o8atAVKV G+Oc9Vsa1QcOX1Zv2ekMgwBkmzkUSPxE6+TZvVu3br8Bi53Z6B8UAiR+2sri6Ny1NRu9ZdNm3zTG PHvtv4K+qwGlPSWfNDNHOX2uvfS3f5oLFr+QnmldXA/IBg2PQBccLE+RIR6qm2D1EPrTXt/+38jt 1l+B2bpEuWrtEZgwqtClU27ank5NmUmfeNzM5Y2lxk9+DMpnLRszUSLu1o0+GEixcvUZ2eTpAYoZ 83Rk+91f+gDxihs8fUJUYBVJhdT4prR6xxeJ0L4CsLSn6oaMrJH06tUTvBUOkIm+Dqn2/T5HFSvX xytW2MXI12+O19ftj9TYSaXq/d8eqxs0nKN196APLlJt3ikBsoUxiNyjfs2m84rpc2Sqg997UhOn Z6vXbCqEySay6dvv7mkcHPfLrZfKKZtlyw15Krp16wPkk2rT0no0s3ljZOOnlpO///1viqUrU6Dd W+g6b9h6XTF99l1w8T8BUj2hBg6kL59Xbd3lhpYT+qwW3Oy17eLQnXsO1S9ZoVSt3xIE+pMJdXKh x4Ki3oN4ljRcvxmiXLRcTJNt4nQfatb8G7TeTZ97UrltVwq4/W/CmFdQB4+MA7L1gnKrlYttluBE DbIn6VxV56+AN5Tm1NnbtX0+5tHlHjk+AnVBa2X1lmbft25PV6wmIH9bNwygWxYvJ6rV66sMe7iU C23uw2wq1Li4Lmg6c95KuW5jtXLpqvvNrIjt4JNaUROn5avtvw1Sbv8iUjFzXhn4o182LLRpkb7T 8yK4RJOUS1fWEy73T9prLrbgqhCYRQ+AWR/bymLN0pxxPNQw17pVbbdmg2LdlrNkyiyitP9uUxvZ dgqhA4X4v2zG3FtQLxZdp+V2idSCxWfR1VPZ2FKa7Tung9+/QMvljQI3yK7J02sRzHjF6u1fpGmv uS5tgngKOlSrBLdOPn/xUyj/a+jYH2TjJku0zi6LFHOtm9WbdtxTfX3grGrs5Fb1Dyev1m/e5Saf Mc9PajVzOFhqDbhRH6Iyy8ZOqmwKitgL7lgmzJCi+pOnz9VPm6Ogxk0yniciX2bnpZg1T6zdaz9O Pm5yFfTD93W//7u1cv2Wx2gZ1Jedj4MVSdBcdp6nnr2QaPbtd1FDvzROmIZ3je83km3qzBQgEhf8 /wNqcKM1Due3gmuWJp84rUK5cs109bZdfOWipY+bHBxnUeOmNKmWr7yh2bx9gWreYiW4uddgQrkA aWOAbP1AORQQC60GEinrt+3iKLfumdXk7bdLu2odUS5Y4qTevnu7bMjIFunwcb0VazdHK61mPaB2 7+5e16u/g9x6GU+5Z++X9fOXEO0Zx13K+Tbfy6fPa2jy8Jou++QzAcQv32O7VJt2qMHKsQ3111y+ PAPjMeWSFUmKtZtyYOb3A1lidDW1rq7LmoXCUeii1s9dVKXevXeZBkIDyv7gRLAqP0L7DsFEe5sa PvZpUwTHCsYgSzlTZ/XrN27zkE+bFaT1CxoC7SLK2dY7wNX8E7hvA6lxk38EUiggbuveFq85jWy9 5jpXtefrCJh8SpVf7XeST5kl16xZP0f9tb2/YvZ8rdY3YBUQVSH9w9+HgQW9ql66SqM+fmaXYra1 TGG3PgfjevmMudB3X5xpjomZLMc+nmvzuWL1xiKwbvFN9gdnwaT4GPQuEHT8UN2AYTl6so2HtPXq g4fHEAfHsfUr12bVDRvl2U06aVJ/UOgg5cGDO4wzwr6DC1RbdgQpN2w+rhw+OgLcADYOGliRYGrw yAjFwqVRWjfv0dRxh6HKCdM48vFTYhs374itGzdpLWVnN0i5bbcP8fP7M7oRDUeOn5V/OoYr7z84 VLlm/SE06Zovvr4hGzgsWrlwCad+/SaO5uQZK/1g/Q7860sImmB2a3bCbPUtPYPt3nOKsltvB27W ++oNWwLren3EAqsYCW6UtfrA99cVI8dHySZMDYKGjlYutbugHDqaBRNERBMnZibMUlcUw0ZHqFfY 3ZcvXOKBFlXj7rFFNXtBuGrTtpj6eYtbQfEOQudsV9qt/VptZ9dbuWWnL/H0/JeoW7ffw6C7AanH Nnt6DlAsWuqvWLkuqmHdJjm4Z0Y3Esg9Uzlj3n2IjVgNazbw1CvtFkn7DRwNZKZX9bQeHrbUzPln 0BVU/XDqvGLUhCRw0WIbt+yIVq9dv9DY9/YH1ik+nxINgx8LVpIDrsgs1ebtKWApC6kR48JUVnN4 oKCz1Q6Oo2XjpzSAu5kkGzgkSr1hWwChtD2gjWuh3ceoXsPfVa7f6gPx6fvqPXsXqSZN49X2/jiy /sy5CPUl5+uyoSMilYuXcaj5S0IkVlb/h0pfP+pzHliSXTAL2yk2bj+Fp2KBa31ZMWZijHL81Cj1 xu3W9LjMXniuydt3KbZLaX/IR3342HeGyVJz9vxNasSYKOW0OVFad/f1JDu7HxDuft17fULUU2fd bwoK3QFWYmz96vWxsgGDueBms7Rs9ifqr/ZdUgwZwQPSBIB++TXx+EsUm7afpcCC02XuO7gbYt39 6JLD9zepoSM5MKHhAtJ/Q9hTpfry60Dm6qly524b5bjJHOX4yVGa747QrwYp5i0+pRg5jqOymh2n PHgEF9feBN3wpd555wOtp+enYPnug9fAa9i6I0a5Zdc5lA3hy0n18LExEOfuBT54aHsNfFvr5jYW ygylPh0VpVi6it0cxOqrPuawELyli/QYOjoOgL73AiM0vnHk+HD1uIlByr3207pcrvTr1u2NZ/1P dzK4Ws+UATMgu1u335nk+e3LLC1jPVCGpfVklof1hZhiNSjM4YZvD58Bd1WjtrEb0+XyuN3aSWAV D2tveZyEIF6jtNv4ZYd62dhY/NjAkvZjDAJuZEldz37bYAIzthdiv0lgcRuo4cPfZfaDpWPp10n/ EzP1x7TdLBwrerO3mfrAd2+Ylkn/z9AdPwvbYRxPF5e/qTZs9VQuX4Ux8Giz9TbRTWJGf7vSZbqe jL5/FhdM4dSt23/9R+8gISLRf6v37fdSL1yaplq8PBUs9tddPVujXaQjxw+rl6zIUFovTVPvP+QN 8cnff4IH378Ha+SmnG49k/m91sVzsGLLziBquNXf/lN3ZGgdHceoFy1P0ri47PjF7SB5jdf4RU2a P6OH7pbg/wEbUqLbHTnAxwAAAABJRU5ErkJggg== --_007_1C9F17D1873AFA47A969C4DD98F98A750FBB13CBxmbrcdx10ciscoc_ Content-Type: image/png; name="image002.png" Content-Description: image002.png Content-Disposition: inline; filename="image002.png"; size=3172; creation-date="Fri, 11 Apr 2014 21:13:00 GMT"; modification-date="Fri, 11 Apr 2014 21:13:00 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAACsAAAArCAYAAADhXXHAAAAAAXNSR0IArs4c6QAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAAvkSURBVFhH xVlLkFVHGf7v+zVzufOCy8yQYniMhCghMYXEpCpQYrSClAvdWO5dZGO5sSw3yC4LXagrl7rRcpOF VbEiEglWUYBICiFIGAZmeAzzYB73fe+55+H3/X36cmccYChi2VPNOff06e6vv/7+Rx/iJ06cEFuO Hz8e+/57P3/7raPvfHd8+9jBhO9tiQRB3BcJgs5bj7+JbOCdx42DvhH2j8RizZVa7e7E7amP3v/9 H/54+le/uASM2i1ux79afHHo1xcuHh3fNvqdLfnePVGJDPoSzfiBj9vIRrBuAOrjXwmCQMHGIpLs yWXHBl/a887YT348+va3j/32p187dBqAHQULRrPvnTx9eMfoCz/cXhza34Nn5YYjbTaa9T52Ftvy 3KshtZglKpJIpVKZvkRsIJHJvVSvVtPv/uZ3VZm9fVbBvvGDd8e3DvYfGx0a3J/E74VKXZo+Nv// VOpeU1peUnoSicjwQP+RA29+5bMfHfvZZQV75OjRlwu9va9k4hGptVxptF3xw5Wuh9eyiK0zzWD/ yfw/26pJU63ZlCjG39JXyJertX07Xv7yl+KQQPKXfzuzPRmPb3WabQXq4iVO3r21drs9PPfDdugL 70X0N/uwxAAcW7mq77NBNX3b2Nl6uy2DmaQkAn8g25PbQ2bT4rR6fN9P8wUXFUalILoLsRhhBJKN xSQXj0k6GgG4qLTxft3zpYbaRuWC0PTchXhaGMV13FgiFe8n2ETbdWMeQJAdXr2Que7Z7LPeeFyK 6ZQMJuOSiZFDMIs+5bYnS9iV+ZYjdRcyCrDc5wTM7i6q43lRsIiZQYILZlyygpV4ZBY10jUTGSWz vYm4jGRSsjmVlHhXO3ybFNCWAeMxAL/neVJFXU8Sz4KfWFzM2/bdiA9lqoEFgK9gMYG+QL66wgCl QSADyQQYTSjQMl662RBZwXUkJbIrI5LC3m9JpaQKlitg18EMa+VAEjYKOED/NpjyPCBGJwVLcB4a CIpgWe2AZJXPydwAtj4ZjUoVHS5VRM6sCLZeZDeAtvtE9uRgAJBGP95baEWk5EK9GCAW6omGA3Wo BUUBmgb6pBJESCDlqWZtwPoEigfUpYIFw1YGBEtrj4Mio1GRO02Rf5REJupYCCauY6wsEA2nRWgF 1DUZjoij8rGSUbug0aCq5PCboB+HOYhSBqwBxgEGTu75cFccgJasA0EgYYQlGwRLNuKwfJYSmH0I RrkQslMDWP7mlWDpKcZ6slLMpNUNGTM07zsYf7HVkpl6U1YcdEIDtb1eiYWYKFG+aJjFn4cHLjWr gHXDtL8Ba9i3hZvCan0x79mKmKKFu5KGxlnXK3kaYzQmE5WqLAMw2aMLXOudKQOLiSs1msVshlHj CTyf03cBVXmYrbCF2Fs2gOEhWZ2CwblM0dYg1KXjnwTwkHka67ZcVl3e9ZWKMp2IGiNalTIpJk+N n9yGMvB1e1w0MCB4qBYsAaqW9VnINt0JqoNKGXCQGXjvD5egV5Bpd8NiJlAadAYv7ocRvpIXKWAb CHi+0ZSlVhPze/+l3wCYiItBhwszzOLFJiTQhLthPPaxEssO71zQaNg2T9VDECy3Bmxxs5eo46p5 pWP1IVp17gSM62cwSgfXI/Ae9CyURALXCkJrDNTS4DqLRI8WAk1LvUroDTgIfWwDYOOcCWCNHsOI pmAf7S+ZUmetFOIegHnfpE+0q+yyGd7yOb3GApDuzIq8WYAhoiEN7XLONgAxo6Wx6WLx5zDnAKYW HACLSb5DzTrowEmjYNF0Asu6hdTyIyXqerjA8BHlpsyh2sRy7dGCWqYJFRIiA5jVroUktQCIhsQI 4sPQuJucz9eBsYiQgdDPukJ96Au4Bh4Ypv8LV0njom4tXF5VBhZcKIc+AEkAhWFmdWmF77yOzP4N aDarXjCQZRhXqe3o+LpSeAATmOCDYyQLeLQtlIELngjSeAJe8VvzLrN+DkT30gHLBWNgMstFu3ht N0LuN6DDEQQGFi6mu3BjUgC4He0MzywEOttoSMVxoNeoMUyyymXgB6OdDVI+AoSRAVqVVV0FKpmk CNiBzfQGdMwhAA5mZcDl0N30YaSDYIx6NJytLt1u38HOTVcbMlkuyUylBr1SI9y9MByHXQOcAJRE 9QZWs8TRkYHRi66BnoE7EG6FnZCDklWe0SxY3pA5W54U9udqDfnn/IJMrJTghcAYvAEZJDnd2R5Z UPK4dBsUiFuBETAdMC0/ZId6sRJ5pFoT1cJkSK9VUM3A8PQCK6fngauq8fiE8W041jm7LRM2Y5ml eZoU0VJNusNqJ9UjC50zJqCDpiRzcKxMXMg/U0ACn0JycxGZWBF63NQ54K8HPSLFnpy8VtysTN4q V9QbJMMkaVUPiFYjJzOvjoGpa1pd14KtOa6UW23JJ1MwkIhsBahWDVEJYHtBzQI08f4ikhywO46U MclF2N2hpFCzeLYDbcVUQr7Q36eJEQPRZKmMNJXnPsbb1Qd/2oqRpTUwyoBGxYawdouPKWMZlrsI yx0GK8PpiOxD2PxrySTf2ZDJT5EbMOxugQvLYAHWhfFKN0d39VUY4Tf7jSGObcrLZG+P3AO7TfhT pqHdCaPxWEiu1O+GBqbBqSMBkx90inbwpQKwD6o12dlXkJ5kUg5g0kMIrx8uwwWBzT7Igj52keki qhoYUYZMMTQzDt2EXPjeNoBNAlx/Oik5hFy6L9Vl6NuN0SAw0b8zE0TnkJNHzlcbVeSPnA8HqMJx T8J6dxQ2yTi2cCf2/3ubEUIxyKmyyBxkQOYY2rnUruWaozmeMxzfBvPTwMXjShLuKokMLAHQ9AZM igLc25mDAL63k+11ZGB4VNrDRKY7fWeiwmTiTqkin8zOS186LUPImA5sMn2GoN8LAMxkRkOw1V3o v3jh8yRQv4B394JVk/tG8G3AfFThQCrFbgtDNFPiQvSdoKDPyGqYtHT7O/WlqHQ3VxceKtiDo1sl j6PL6wUAgNG8Bg1fh2aXMS9ZXXtQdICC+eyrCLeH0Qc2qhY+V6vJCtJEIxujTasg9bOh8pn0dU4K JnKFHoHBVk92jwonR6iWErR7/t59cdy2vDpcVIMbQTT41pDI19FOXaqK1kQFPuMY9AgMHtzBO6WS 3IVxVXFaSNF1qRs0NNoAoTutIRj5irbY1VgjY4q4zrlIH4H5WbBx9u6MzNcb8sXBQdle6JXNuTT0 BzewgVLBd6zJ5ZJcnpuDJ4B+CADkdGd2CouEhcZO3SvYaERTXuVCsy76tTXMKAbmm+HaFrF1lQdz Mluuyki+B2CzkseXmsR6zj0kmpw18E1hoVaXabA6gzNYC26R/taGVDOPkaQhrJOQm48cNNcI4jPB EKiGwG4XYtniALjn4Y7pGzU3pVtZljSO37Tsp33jYvZGwDzvcQ6eEsINsziVTILleRNEYi7muIZZ 32m2cMwJ2rFYNMPVa1LxhO3k4CbU4njM+I17ft/iV7+nFet/owDJY4w943X3U1Z1I7EQkgj+XKfR JNj2woP7S4XhYqlQLObjibY0oSl24IDrle6FEDDf4m48aYF2HI1RxpZ0yd15S/hEP7LEQWsSwYem 1Ww0Ggt37swRbOvmhXOTfcPD00NjO7fl4fR5UqghtPL80wlDT6Nsg+1PXpBZMIH29PZKDuF4eX6+ /eD21N3lGzduKbNTH398ozg2/kl+c/HF0R07Bzb190scFu9gW226uEEsz/1aFAfINL7kZDIZqZXL /vSVKxM3z527BObux/G/ID6+fs9cO/mXM77XLrYPHX5rZNeuzblcTtKa3yKNWLtXzw1p/QGozyhY 5XVpdja4e+3a1KenTp6a+vvZ8+ixYjPPUvn+9OWrH/w5W15crI3u3btvcGR0MJFOp9TVrckV/hdY TXpIY/KCRqVWn5+emrl/5V8Xpy5e+Miv12/Shi1YmvFMfXHu7PUP/rRw6/y5K1t3j49m8oUs3AYi NEt3avL5wwWnOmjbdfzq/PzK3OTEbb9a/TceTaIuUQEKNvwfvBrlgJ8NZ3HhwfTiQh/uEfXDUT5/ fI8bkbkMv+08DOsK8KlP/A/+yzuZaNBbhgAAAABJRU5ErkJggg== --_007_1C9F17D1873AFA47A969C4DD98F98A750FBB13CBxmbrcdx10ciscoc_ Content-Type: image/png; name="image003.png" Content-Description: image003.png Content-Disposition: inline; filename="image003.png"; size=2971; creation-date="Fri, 11 Apr 2014 21:13:00 GMT"; modification-date="Fri, 11 Apr 2014 21:13:00 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAACsAAAArCAYAAADhXXHAAAAAAXNSR0IArs4c6QAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAAsbSURBVFhH vVlJbBxZGf6rV3fb7aXdjuPEzuIsThhNyIxA5DBAIiE0DHACxIEDV8RlxIWrlRtHpLkjDUgcQMyF IyKKgpRMklEWEiZO7NhZ8L52271VdVXxfa/eq65ut5MoY/GSUlV1vXrv+7/3/csrJy5fviymTU5O xuWbv/h+9juXfjo+cerCWC45nLUk4Xu+76GT5Yddwwvf2v1b9JcYbsxr7MprHu1jxSzL8mOWlDyr Nr22+fL51MwVufq3v8iXV+8AoxoiEQL99OFQ7Fef/PDCudM/OTU2cmYgLYWE52d8141ZvuWrCTrg 6oC/pdde77T/7otvWQDrxWOpM4Pdx5dHCx/dPXlsdObhR59OTv72KgDbCiwYzQ798neXDk2Mf/zu qePnT+Z7xN8uiu00pLEHyFfz+ZZPYUEsFktmspnMgfzAoBtLvuOXq11PP/z1Dka8HjA7fvH08LHD Pz53Yuz8kZ6UVFZXZXOnFlL5mpV+S2QdJKUlksTcuVxWzhd6rPLRke9tVC88nvz9x/cDsN+6+PVc of+9Q30ZqZXLsl2uiu35WHb8+38h1dipN6fRwMpWJIe5Rw8N925ul87d6hp/NwEJpAZ+88mxbFdq RBqOlGBVzXbFimnXwMtRXb6Nbt+UejM2/FkqNgADS2agR/KZ5KD05c6Q2a5MQnos3+uq1B1xHBeW gdW41xGki4Ec1xcOGIdDJGEUTi193xTcXv1IDsf3ARiOI3DyuCQSeYJN+g0n7rieYtR1XUgAzEZ8 P7QYkFwADR5Z0sC1i/cScdxBLypk7FNzCbgREx9ODkfHMnsJgo25nocfABKWcHIb91GwFIQLDRNM Tyoh1DbP6+W6LGxXpeJ4koyz1/4wHJID4lyArdkNxglLORikqpa/BmGDLvxHCvCa6iRIGjTUk5YP jg/L+dG8dIHO1XJNrs0sy/3FTSnD0AT0EDXyq5DM2T0BFoAlNrYALEAasBbB4mAYMBmnivsMwI0j /l46dVCODubUyxOQRaPhyXyxLI9WipJJJiRBOXwVlPpdzs21chz6EaO9Buv7cCpQXocFFqnHEQW7 A5Gnscz5TFr6MqkQCs3Jd6cknYhJFQMiZYoHdvcLLMOmcnjiwWIrZj2wY0N3BqzHhxEHowR2ECmW oc8Szv3ZtAJMp5xb25bFYlU5m433fMhH1RFt7LYb8Lrwzec86EsOsAkwBGBx7biNACwiAZ0s2vgS 2b09vy7dd+bka8O9yqGWSjW5MrMoc5s7ik0a5NER9UQMbal4XN3TH2yMi8cSB2UpvJ9OxtV1EEVa zTEyYMp36FSgQIF1ANDIANTsAss4yonmNnakWH4ut3JpOFhM1sq2zCNwO5iNMiFQNqV1XDZwX4Xm GDMz6F+AjJI42/CBYq0h65W6As2DoS+KV4FFSWfHtAwg4MDBAJCsVnDEYUEgg2ZjIqDj5KHXw70Z 6UbYoj5H+nGOW/Jsq6IAnYLjjeQyKEYsqQPQZtWWaciEYL4xOigTQ71K8xuVmjxcLsq/l7ZgcA3g LegewTpCrpIJ7mtWsOJ0t6A2wBIxexVrdelOwG2gC05uGo3IpWJytjAoP3t/XA4jBbKR7StTL+UP t2eQnhPy4dnD8u0TI5ICezv1hjxe3JAbz1bkCKLID945InlonfKhIUs7VfnX9KL89f4zebxaUqtC AoxWeU2Stry68pNQBhRtHcu1BbAuLEzHWMQEjZjLeJYCmL5MUt4bG5QCKiLTniyuQ0ZIIpjsGIyY ONgfPjvY0yWnh/thXLcM9mRaVutAb1YOdmeUA/357qzMbZUhpTjSdwCYXlMGoSWAduAvjGNh8U3L WDy4sDqLFUlieY3465BFzQUjYJIsm1ZndsE9Y20s5kkV73PyFByHS1gAoKG+LPo0ZAmxuDudlFxX M/QdwLMfgfHp1aJMr5dgtK98wQdDnKuM8Ori3uTxAKxyfoxOhtHJdXxJYkJqjc5F53M8qBnPo/mf QlFpmEmE8VU91PLBe2RoBaXetcfzMoUsd7TQKxcnRmUUTCuHQhsb7JET0DIddBPSaXgxNabNMpEj JLRxJs4GGyM9ETo2GL7gdDYqKhAsLhjzYKGndmLNxldogMfCB8YwVBkQ7FWCg312Z1b+eGNKXixv SR+0WwHLP3//pPRDImxdqaT0I0qQNafmiIsJFRJGFov1S8hmUwbtKHyUia4FlskASzUw7bPiaouH NAAlHA70JfORgZZLFfkHWL0xuyTQmMyD5eszC/LB+HAIlt0ZPVRshyEeaxJdFEVoUfMGMlBbTXRW zPHQUxrGORCPDjWgCq3QrIcQQ73Sg00rVuuygjClGpyToIqIrZs4oo2Rx8XqwGIc0HtossET9A7A EiQnMUd7dmchzKND1udEHjMTwFLbgW51M8ZyfKyKBZfGYqFPh2Qc6l3jCIAF2HSyCaNBqNsQcNR2 TtQMZ1EsZJK6xXa9ha1mn8Bxzfh0WB57dI4QZsASMK4hjyZYLr+yYLcuA+ZZkEcVGQwWRAguF1hr ex7Y3cZUx/E5VHRuM4/+Ta+WBmt0GpVCxHY14WvY6NBBySaUlwbUFlGCUbFqURmGUjKGBviacdaw 2gmYHkilwsjenNdqSfU7fBR9zmdNEEE/VaC07e+DW2OYXtyo1tS1rrpCzlqcLMIklhp5RcVRHqYl EIeZ6xmLmW6TSJf8zTRWWAGwJhD1DuqPaGMZGeCl3JoZq305I5qNWrR7zen12LihRKzJIII4e5Tr NlIsSsCALvVxYhuhKou0yn0c+7IcjLaybcsaivgiQ5pSly+b6NegE6oW9ZnWJBQBq61V7LbV+qyU wNyjpU357IsnKA271ZCsBW4i4JeZcjHZtZl5tYnMICuxaH6KnL9cxGcqss1yFaenayX5+71ZmUZG CwjHexiD26IwTISa1ZiYydACsLw2tZn2/JaNCSqxKsDcfrEiDxfW8Z1Ap0RMxnKviqSwg/Ofbj1R slDfcvCM2x5V+OiMxBWYWd+W/34+BSno4M8V4zcL1tDhVyCzsq1y0czS8hCtDiORjmQFg9ax7PUd bt70YHyHVRF2tWRpGxkryHTaeE7OZ5H0Sak4NYwR3TpBs6iaAgyhAnEReLTGZhyMLmyBLtM5CJvN ZpaFk0YcSHUwNvFMYMkWiWoAER+gg2Kn0dLCsNoWX4mcEkAtHX7kUDMqXRlPjIq8ffK2+9ApIsA7 Iun0nv4tXMQIWEMQcWmCCNnT20cHH7+wgcKb0OCeSeAVc+7bI+PglAcPYrQrNVVGytbChuQLRek/ 0CsOdFevqsJj15LvG5pXDERGWYHxM1waNS9Zt6tVWVtaJti6PHvwVAaGn8vQ2Jjk8kHnKkIOz6G3 RCfYK/d2AtHq0UGPTt6uvZKnOITf0y+S7RMprjqy8uKllOZnA2afP3wihbG70ls4KyPj+HBbgKPg q4tj65jbDq4TgL3Y6mSYeT/yjFWb8nxoNNMNVrEprZQ8eflkWmYf3MHo8wn8FcTD1+8F+c+ta4hP BwHwuzJy/IB0wzIyq4ri1kwShoD2OTuS+IZgud4EG4NG6TdbKz6AYp9+85/y4t5NgN0yMaQotfX7 8uX1rGxjTzx68pzkDxUkmQo+aoWp0LBnMou+7xzD9Yq/IVgTT1Ve36nI2ssFWZj5Ql5MXRHPnsFg FQOWXxEWpFa6LtOfr8rcvQcyfHxUsthL849Twa5td2sH+Spcr3VOHdhdfIUrbWzJ6rM5zPsIrz3F sUEFKLD6L3hlJQe4ljRqizL/aADX/DIRTQ+vnXIfOtCr4d2ypo8t4COZ8j+FwS4ugdbilwAAAABJ RU5ErkJggg== --_007_1C9F17D1873AFA47A969C4DD98F98A750FBB13CBxmbrcdx10ciscoc_ Content-Type: image/png; name="image004.png" Content-Description: image004.png Content-Disposition: inline; filename="image004.png"; size=3305; creation-date="Fri, 11 Apr 2014 21:13:00 GMT"; modification-date="Fri, 11 Apr 2014 21:13:00 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAACsAAAArCAYAAADhXXHAAAAAAXNSR0IArs4c6QAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAAxpSURBVFhH vVlZcxTnFT29zIz20Y4kJNkSmwBjcKVCmcQp4zhOxaF4Sp78J/gBfnD5B/jZz3nwS54cHnAlTiiX KzY2OMYQBEYLSEIrEtpmV285937dw6AFuyqWG7pm1DP9fec737nn3tvjvv/++0iO9957z/nwww9/ f+HChT8PDAy8yusHeLo8o+qX9u+NFQ9d5vGIx9WPPvror8T3LU+dX4Do8eabb3a98847F1pbW//U 1NQ0wkudPOt52j8z2DSPIZL1x0uXLvW/9dZbf3nttdc+I+AtBUtGG3jxja6urkvZbPbM/pH3o0ZO 2bZdX1dX18Hz5PDwcN0nn3ySv379+pcK9t133z1KRi/WAo2in2PndwdvgYoworDa29t/d/r06fsf fPDBLQX79ttvnybYV5JbgyDYkwLLMqPULma3az+Kw+d8ScYkw8hkMi2u6748ODh4yqUE0hcvXnwx k0n3JvdGu8UTiU4GSMCGYQjHcapT+r6fMPL/YlUybA0XwPM8kcSIMFu3tbXVxInrEhC7SUC2Rhgv lUoKmjfrKwcC79dBGRh67aeSkIwj43Feh+y2C9gUGXESicoXonCnXm3HhjA3OzuLYrGIvr4+dHR0 YGFhASsrK6C20N/fD9dxIYzLOLI4maxWJsl7+c4PHZFtwPK7Nk9XwMqbKhsKdpfgsqgfOXK5TUyM TyjDqVQKY2P3sbq6BgaBamz7odLhQoUA3Vp+Z685tt8ruOIxLb63NMDC0OcAAvjpuePGwNdJhUE5 5ufn0djYoK/NLS1oa2vF+voa5ubmVRoHyXxbRxvyhTzyuRxcN6UykUXa1Hk22wLXdhAqMbs7TxSZ xcunAjwGa/6oPbeD9XyPq3TR29OLgf4BjN67ixs3bug9J06e5EKBO3fuqCREwwLw8JHD2NjYwMzM IzQ0NIA+jpnpGTRwkadePgU34xCIyG53Sdh2fD3eaQUr2xLKNsVbFYiwt6MNZH2Bbn33gW58+91N SmAMZ86cQXtbOwHNEOwohg8dQn19AKbLKiNLS0u8Vi82pNeF1RMnjiPKGGkYdncegkmPeDExszWs BpSCnDvu5QJ4MXQttLRm0djUqNstshBneLz8GGtra2jNZlVnIofFxUUwdSNkoG1VKvDIeKlcRqYu o8GnO8m59gq20DLMBvGuV2sD0WsQmgH22pYgYrJgwKTJbrYlS4ayaG5u1gHFIcQtRJfCvjAm14zF 2eB/LoKerNFNAAJSSHnOfMkihPmqZmUSodyce69UbYiMqLXFriH3JjZVKBRQyOcIzIa8lwUJozle S6VcBlsOOWo4RRP6oRgRAmgBhlkuSo4dMhDK5dztkO21CNKX5MDtzBNQmWBo2AygRr0+8XBKGS4y 6gcGB9Un19bXGXQV0Nmx8uQJGpspDSFFvPh55MQ4ZNerYCNubxB4CIThmPJd0UogSEbhmeH2t3Z2 wsmk4XKrh44cwdTcHEbHx1EplXHs6FEcHhlRq7o/+QCPn6ygkUDr6QSt1HlkMtNzdzKkLANappw1 zIJsBGSGFxUsMw8/fRqkBElWQyelrxE1eYRA2js70NXRqex08v2vzr2KngcPldnh4SF0d3WSUQ/n zv4Sa6vDaKAjiMe2tbXp5FtkTHYq4nxJRMd1kkqLAtOxngFr3IHbLysVsHGarIKNR7Bo8M7SIjJr qzjED0e4In99Ff7490i7Dk5wMaeaWK9LsC7OYmt2mvJowlkmDWvoBTDDw2Jy2CK4yuoTBLQymi5Y DRGAVHqSms2eapGkehV2awLMiN0EmGqWLGsOT8w2xQKlVEF6Ygx1N67BfTRD8QewCapOFiZplN9l Kjd9BcfwPZ8YXDitbbC6uhG1d8BtaQW9DA6ti7BR4eIq3QcQtPK6gVhl2KR8cY7Yi5MMpm5QY10i g+oh288/MovzyNz8D1z6acAo98mYgHT8LTTMz8BeWhDhmAnq6cFZ6pIO4K4swVlfQdjJCrSDLV1H OxwCT1PrqaACn6RsSU0hFiiBVBPccRGjgEWTTzOYSEBtycjBHKQr4uTCHrc/NTUJR1g6ew7uCy8i InuYm0XwzytwpidhpbhxlRKi3j5Yv36dbPP+v18GJidhlyvA5gaChQzL/07YZDTT2AxXiGpqRkTG IVmylqi4LJXaRY6n1hWbdJJVDFajg1C8lBblFDYheFjPAH0HOfk6wtHvGCll+K0dynIoLHHr3YFB RM0t8L8fRcjdcDfWERXz8Du7EWbq4M6y1kin4Pb1w+7tZbAZoFbsqYYqcYs4UT0DVnO0eJ859RD2 tdCgvxKhWy7CmbiDkAVJ2N3HrZ+H/cVnOnlw7jzCuUcIuZ02t9nOF+CTYf+3f4Dd2IJo/B43idH9 ylkE/UOIJseQGrunnYZ1dEQjX2JAYiEhyZJd1fLVJCqTbuOUt6PqEhXIguPPddXM71a5xPxaAApF jUF75ASiE6cR3WZqpTxAeYTSUfCfOzxMy/AQsp5g9gBePAxn8AWyyvcLc4hyBURMLlrMKFjOkbiP KbyNZhk5RgaKd5cSUVoU/tMcrh7ML6YbENU1UAvGhtCUVQ0i24qosQk2X0HJRI+5C6srek9Iq4iO HGNPkub9GTLdAHdoCDZLTXtxyYAVkAS1A2wszxrN0stqKiABZzQbl49xX6UtMr3JtMqxtcmqJXhY tIApGCW+xhqy2EFELMhZDADdPWQ2ZbqGfB4Rvdpi1SbDmNrCVHu2zJ0wK6qVLKa6jQPMaCK5aKov A1aYld0xeZwSioVs3sspujJ/yDbKfSYl64Ik2KjJiCWXWrBeZ9AvLsBjLWyxnwtYpUl3JY4jAabZ LAaru6qafSYpCCBTfD9TdcVg1eT5WZlScL0ygXsys9YIEd/bjNqI2cijDFLS4VKzkaRl1gyhz6KF bpJ0vSFrXJ9FjU2AHj8XF/DiGkEkoOVpDbNPe7eqdRn2ks42Er+LWTT9T4QKrxUINuVzIg7uEGIk 9QRTsOux8qJvRkeOw3eZROi9wnTqQA+s/hTCqYcIpqdU4053N1wWPRGLnvL9URS3fKZf09rIPJbM HfedUnyL54s8qpqVEJPeQG1LS8Q43cbqC50IW8z9RSeNDAe3Z6Zh3fwGoH/63FJ3YhypQfop3SGg 9wYEJ+SkWbg4rLA8JhPvxtda56Z+cx4u25pg7C7KtK7SwBCzYaMC0uSjWcwEthCmmGI51HQKSS9m ACf9fey08JllSl29iKbHEd25hXBhCTa3W4qbci4P3PveOAZLTbE3malw/RofodTzOyzInyyppgv0 YjZkzIgL3JkQHn03ZMdh7iWLqn11dyMdiQK1z5pHnvqFRLPid0kVI9UbJ/eZlcpnfoGA2cp5NIWI DmBxAouMs/xHuLJIbcoiObr4qcwgQcOO2KIb2JRH5KYRbW4i2uBJ+wtfOg5v5CQCgpc5kiI73tCa 5wumI1RmuQI9kqh7lll+gQNJ1JaOjcBjuedw+9WiqNXIY5LQVxq/gBUmYr1Lgyn9F3saebaESDxW amI6RCipuPcgMyFrDVnU9udkqoLYZXS8+CFHYlN6KfbbZ56uiI5Y//nSlR4+DPbbhjU1cqFeonj3 x07KtFiYdoycXppGqV8lUQgYASlZMXbF5EUCTtsosTup/OJ0G1YqFY9B5Vm2JZWzySbbDwEXN4m6 11rAynZLx/r0y6ZINIfZvOQPc9WwrqyYUyJdNRofcZLQ+JLFyVwMo0KhVBYZeHzwsMonLRu9PT0t 2tuzhzLPpWTkGiTCQrV63PbZNsBVjDveCOIEmgRTnAmTNWnc0BrJvkv5iJ2V2cjxgeCSgK1cu3Zt 8mDfwWn2TQMtUljH3Wno1/K0g+t9usCCnlKRhyPyTIJPc7zJBw8e8enPA2X26tWrY8eOHbvZ29tz /NChQx3S0EklL63JXo929gkpgdr6YKSuvg65zc3w9u1b4yTzW/6CM+fyV5CQT7/nr1y58jkZ7Xnj /PnX+UCtW54QJuXZT/Vw+IcWKPoUsFLs8NFTdHf07tSnn/7jX59//u+vee96khQ2pqenb12+fLlh eflx4aWTJ18+2N/XmcnUs/00yWK/Dy19TEka5XK54vT01Pzt725/89VXX13NF4sTnL+YgGXawTz1 8eXHH/9t+doXX/736MjRfv4o0mBZjsTnttDeB+hx8cLdDZeWltfv37/3MJ/P3+NMkzxXRQEKNv4F ryBy4J+lpeXlBZ5tfJ/8aLcP6PYcUvyG+Rus3PVcJz4hE/8DoDIPqE3mn50AAAAASUVORK5CYII= --_007_1C9F17D1873AFA47A969C4DD98F98A750FBB13CBxmbrcdx10ciscoc_-- From nobody Thu Apr 17 10:23:20 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 672811A014B for ; Thu, 17 Apr 2014 10:23:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.773 X-Spam-Level: X-Spam-Status: No, score=-14.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tWk0ECZ7Mh6O for ; Thu, 17 Apr 2014 10:23:13 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 5A8DC1A00FE for ; Thu, 17 Apr 2014 10:23:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7431; q=dns/txt; s=iport; t=1397755390; x=1398964990; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=X6Y+H5E8RNOylaG1UZC+utdLihpxFLFiAe+gvCZ0i7c=; b=OXK/ljO3jFljFFOFW/7KVV3Pz20tISu5E3esiQxU8yRfpce4yM2eft5V Id5ER9CduDhNni/IWbyzQZj54rkiznQCPTNHHXG7MVk1asM6ohMm+W/o0 sRof2PwfJFtdAc5t7cUSnC0MKsnhF2hC1NQY+CKC/B7gy/mZ4ur16FlsI o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArsFAIkNUFOtJV2Z/2dsb2JhbABZgwY7UQa8KIc4gSUWdIIlAQEBBAEBATc0FwQCAQgRBAEBCxQJBycLFAkIAQEEARIIAYdzCAXLLBeOABEBHw8pBoMegRQEmiWRFoMxgXI5 X-IronPort-AV: E=Sophos;i="4.97,880,1389744000"; d="scan'208";a="318474660" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP; 17 Apr 2014 17:23:09 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s3HHN9Ns020822 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 17 Apr 2014 17:23:09 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.104]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0123.003; Thu, 17 Apr 2014 12:23:09 -0500 From: "Panos Kampanakis (pkampana)" To: "Moriarty, Kathleen" , "mile@ietf.org" Thread-Topic: comments/review on draft-ietf-mile-iodef-guidance-02.txt Thread-Index: Ac709IO4yNZG2zJPQSanFWkPwBnnXxlbL6FA Date: Thu, 17 Apr 2014 17:23:08 +0000 Message-ID: <1C9F17D1873AFA47A969C4DD98F98A750FBBC9CB@xmb-rcd-x10.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.216.48] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mile/5j0LUgBHXVKhr7e3vKpSVP8yowM Subject: Re: [mile] comments/review on draft-ietf-mile-iodef-guidance-02.txt X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 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, 17 Apr 2014 17:23:17 -0000 Hi Kathleen, As I am refreshing my memory trying to fix this in the draft I read in your= email " To keep the pattern consistent, I think it would make sense to hav= e the different Keys provided have the tags at the higher level (WindowsReg= istryKeyModified tag included), but have them all represented within the sa= me EventData instance. " What tags in WindowsRegistryKeyModified are you referring to? You mean havi= ng WindowsRegistryKeyModified in the same EventData and each WindowsRegistr= yKeyModified could have Keys that have a tag that ties them to the same Win= dowsRegistryKeyModified. But what tag is that? Is it the indicator-uid? Rgs, Panos -----Original Message----- From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Moriarty, Kathleen Sent: Monday, December 09, 2013 11:04 AM To: mile@ietf.org Subject: [mile] comments/review on draft-ietf-mile-iodef-guidance-02.txt Hello Panos, Thank you for taking the time to update the IODEF-Guidance document. I hav= e a few comments and suggestions and encourage others to review and comment= so that we can progress the draft. It looks like several sections need co= ntent, if implementers would like to contribute content especially in secti= ons 3 & 4, that could be helpful. Also, if implementers have worked throug= h use cases and have guidance from lessons learned, that would be very usef= ul to incorporate as well in addition to the use cases Panos has outlined i= n the draft already. Section 4.4 Logic for watchlist of indicators I think adding in examples will be very helpful in this section to clearly = depict what is meant by each of the ways to represent the AND/OR logic. I'm still having trouble reading and understanding this section. We implem= ented the predicate logic based on initial discussions in our open source c= ode and follow different rules. The description we followed is included as= you can see it is different from the current draft and provides more consi= stency across each of the classes as was originally intended: For Node information, a watchlist of Systems means that the information is = ORed with the other information in the Flow section and an AND with rest of= the content in the EventData grouping. As such, we need to replicate this= pattern elsewhere, which is easy to do in the current format. For HashInf= ormation type, a watchlist type was added for each value to accommodate the= same pattern. In the Key class, a type was added with watchlist as an opt= ion as well. If the watchlist is used, the data provided is just that, a = watchlist of separate values. I think the current description that talks a= bout the watchlist-source and watchlist-destination confuse the logic and i= t could be stated more simply and consistently across the schema in terms o= f how the watchlist attribute effects the logic. Instead of the OR being w= ith the full Flow class, the initial intent was for it to be within the wat= chlist with an AND to the other items unless another watchlist was included= leaving you with a mes h of possibilities for the possible combinations one may detect. In the 5th paragraph, I think this explanations introduces inconsistency in= the logic, I'll explain what I expected... In the Node class, if information is grouped together, it represents the sa= me thing (a single host, but the Node class could include all the informati= on about it - hostname, IP, AS number, etc.). With this pattern, if you se= t the type value for HashInformation to file_hash, the list provided are ju= st alternate representations for the same hash (sha256, sha1, md5, etc.). = For the Key information, it's a little different as the grouping without i= t would just be part of a joined event as opposed to alternate ways to repr= esent the same value. To keep the pattern consistent, I think it would mak= e sense to have the different Keys provided have the tags at the higher lev= el (WindowsRegistryKeyModified tag included), but have them all represented= within the same EventData instance. The included examples are following t= his logic pattern if examples are helpful to weigh in on this Alternatively, we could use separate EventData instances for each value, it= just adds a few more tags around each value, but accomplishes the same log= ic. =20 Once we get this adjusted, examples of each usage with an explanation would= be really helpful to ensure consistency in implementations. For the Appendix, the examples are good, but could you add a text descripti= on to explain the examples providing guidance as to decisions made in the r= epresentation for those use cases to help developers with consistent repres= entation of use cases as it made help reduce coding efforts.=20 If others would like to contribute examples with guidance to increase inte= roperability between implementations for specific use cases, PLEASE DO! Thank you, Kathleen -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of int= ernet-drafts@ietf.org Sent: Friday, October 18, 2013 2:50 PM To: i-d-announce@ietf.org Cc: mile@ietf.org Subject: [mile] I-D Action: draft-ietf-mile-iodef-guidance-02.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Managed Incident Lightweight Exchange Wor= king Group of the IETF. Title : IODEF Usage Guidance Author(s) : Panos Kampanakis Filename : draft-ietf-mile-iodef-guidance-02.txt Pages : 19 Date : 2013-10-18 Abstract: The Incident Object Description Exchange Format [RFC5070] defines a data representation that provides a framework for sharing information commonly exchanged by Computer Security Incident Response Teams (CSIRTs) about computer security incidents. Since the IODEF model includes a wealth of available options that can be used to describe a security incident or issue, it can be challenging for implementers to develop tools that can Leverage IODEF for incident sharing. This document provides guidelines for IODEF implementers. It will also address how common security indicators can be represented in IODEF. The goal of this document is to make IODEF's adoption by vendors easier and encourage faster and wider adoption of the model by Computer Security Incident Response Teams (CSIRTs) around the world. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mile-iodef-guidance There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mile-iodef-guidance-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mile-iodef-guidance-02 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile From nobody Thu Apr 17 12:08:37 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DA5C1A0137 for ; Thu, 17 Apr 2014 12:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.773 X-Spam-Level: X-Spam-Status: No, score=-9.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PtdG9pdQZJT6 for ; Thu, 17 Apr 2014 12:08:30 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id 016541A0196 for ; Thu, 17 Apr 2014 12:08:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8221; q=dns/txt; s=iport; t=1397761706; x=1398971306; h=from:to:subject:date:message-id:references: content-transfer-encoding:mime-version; bh=5mljG3n53wpAFQMR+4g6FLB7VHmGNsZr7l2a8CllGjo=; b=FOV+Y2VqU6nJ1cAE3UELQTUlnsihNQIbIBuQq1vDC/B2vifrPO9nMkLw IMSAmoOCCeTj9nS0HJKSUkRxC/aEoobgQnjihHu65JgOE6IXtrmoSEw/W nWs+MbnzYLMXNoCPDV8wSgylsIMpJvTR32DXzdHmLQgyMNaam3L2COqZu Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArsFAOUlUFOtJV2b/2dsb2JhbABZgwY7UQa8KYc4gSYWdIIlAQEBBAEBATc0FwQCAQgRBAEBCxQJBycLFAMBBQgBAQQTCAGHcwgFy1AXjgARAR8PL4MegRQElQCFJZEWgzGBcjk X-IronPort-AV: E=Sophos;i="4.97,880,1389744000"; d="scan'208";a="36700043" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-3.cisco.com with ESMTP; 17 Apr 2014 19:08:25 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s3HJ8PYX000407 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 17 Apr 2014 19:08:25 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.104]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Thu, 17 Apr 2014 14:08:25 -0500 From: "Panos Kampanakis (pkampana)" To: "mile@ietf.org" Thread-Topic: comments/review on draft-ietf-mile-iodef-guidance-02.txt Thread-Index: Ac709IO4yNZG2zJPQSanFWkPwBnnXxlbL6FAAAOa1PA= Date: Thu, 17 Apr 2014 19:08:25 +0000 Message-ID: <1C9F17D1873AFA47A969C4DD98F98A750FBBCF0A@xmb-rcd-x10.cisco.com> References: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.216.69] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mile/SwZ4ys7NcdfyNrlJZDdual4Ffp8 Subject: Re: [mile] comments/review on draft-ietf-mile-iodef-guidance-02.txt X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 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, 17 Apr 2014 19:08:35 -0000 Closing the loop. What the draft will include will be "Multiple, Key classe= s in a WindowsRegistryKeysModified class represent necessary Windows Regist= ry Keys that comprise and indicator. All need to be present in order for th= e indicator to be present. Multiple WindowsRegistryKeysModified classes gro= uped in the same RecordData class represent alternatives for the same indic= ator. For example, if a RecordData class included two WindowsRegistryKeysMo= dified classes, if either of the classes was true the RecordData class woul= d be true." Panos -----Original Message----- From: Panos Kampanakis (pkampana)=20 Sent: Thursday, April 17, 2014 1:23 PM To: Moriarty, Kathleen; mile@ietf.org Subject: RE: comments/review on draft-ietf-mile-iodef-guidance-02.txt Hi Kathleen, As I am refreshing my memory trying to fix this in the draft I read in your= email " To keep the pattern consistent, I think it would make sense to hav= e the different Keys provided have the tags at the higher level (WindowsReg= istryKeyModified tag included), but have them all represented within the sa= me EventData instance. " What tags in WindowsRegistryKeyModified are you referring to? You mean havi= ng WindowsRegistryKeyModified in the same EventData and each WindowsRegistr= yKeyModified could have Keys that have a tag that ties them to the same Win= dowsRegistryKeyModified. But what tag is that? Is it the indicator-uid? Rgs, Panos -----Original Message----- From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Moriarty, Kathleen Sent: Monday, December 09, 2013 11:04 AM To: mile@ietf.org Subject: [mile] comments/review on draft-ietf-mile-iodef-guidance-02.txt Hello Panos, Thank you for taking the time to update the IODEF-Guidance document. I hav= e a few comments and suggestions and encourage others to review and comment= so that we can progress the draft. It looks like several sections need co= ntent, if implementers would like to contribute content especially in secti= ons 3 & 4, that could be helpful. Also, if implementers have worked throug= h use cases and have guidance from lessons learned, that would be very usef= ul to incorporate as well in addition to the use cases Panos has outlined i= n the draft already. Section 4.4 Logic for watchlist of indicators I think adding in examples will be very helpful in this section to clearly = depict what is meant by each of the ways to represent the AND/OR logic. I'm still having trouble reading and understanding this section. We implem= ented the predicate logic based on initial discussions in our open source c= ode and follow different rules. The description we followed is included as= you can see it is different from the current draft and provides more consi= stency across each of the classes as was originally intended: For Node information, a watchlist of Systems means that the information is = ORed with the other information in the Flow section and an AND with rest of= the content in the EventData grouping. As such, we need to replicate this= pattern elsewhere, which is easy to do in the current format. For HashInf= ormation type, a watchlist type was added for each value to accommodate the= same pattern. In the Key class, a type was added with watchlist as an opt= ion as well. If the watchlist is used, the data provided is just that, a = watchlist of separate values. I think the current description that talks a= bout the watchlist-source and watchlist-destination confuse the logic and i= t could be stated more simply and consistently across the schema in terms o= f how the watchlist attribute effects the logic. Instead of the OR being w= ith the full Flow class, the initial intent was for it to be within the wat= chlist with an AND to the other items unless another watchlist was included= leaving you with a mes h of possibilities for the possible combinations one may detect. In the 5th paragraph, I think this explanations introduces inconsistency in= the logic, I'll explain what I expected... In the Node class, if information is grouped together, it represents the sa= me thing (a single host, but the Node class could include all the informati= on about it - hostname, IP, AS number, etc.). With this pattern, if you se= t the type value for HashInformation to file_hash, the list provided are ju= st alternate representations for the same hash (sha256, sha1, md5, etc.). = For the Key information, it's a little different as the grouping without i= t would just be part of a joined event as opposed to alternate ways to repr= esent the same value. To keep the pattern consistent, I think it would mak= e sense to have the different Keys provided have the tags at the higher lev= el (WindowsRegistryKeyModified tag included), but have them all represented= within the same EventData instance. The included examples are following t= his logic pattern if examples are helpful to weigh in on this Alternatively, we could use separate EventData instances for each value, it= just adds a few more tags around each value, but accomplishes the same log= ic. =20 Once we get this adjusted, examples of each usage with an explanation would= be really helpful to ensure consistency in implementations. For the Appendix, the examples are good, but could you add a text descripti= on to explain the examples providing guidance as to decisions made in the r= epresentation for those use cases to help developers with consistent repres= entation of use cases as it made help reduce coding efforts.=20 If others would like to contribute examples with guidance to increase inte= roperability between implementations for specific use cases, PLEASE DO! Thank you, Kathleen -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of int= ernet-drafts@ietf.org Sent: Friday, October 18, 2013 2:50 PM To: i-d-announce@ietf.org Cc: mile@ietf.org Subject: [mile] I-D Action: draft-ietf-mile-iodef-guidance-02.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Managed Incident Lightweight Exchange Wor= king Group of the IETF. Title : IODEF Usage Guidance Author(s) : Panos Kampanakis Filename : draft-ietf-mile-iodef-guidance-02.txt Pages : 19 Date : 2013-10-18 Abstract: The Incident Object Description Exchange Format [RFC5070] defines a data representation that provides a framework for sharing information commonly exchanged by Computer Security Incident Response Teams (CSIRTs) about computer security incidents. Since the IODEF model includes a wealth of available options that can be used to describe a security incident or issue, it can be challenging for implementers to develop tools that can Leverage IODEF for incident sharing. This document provides guidelines for IODEF implementers. It will also address how common security indicators can be represented in IODEF. The goal of this document is to make IODEF's adoption by vendors easier and encourage faster and wider adoption of the model by Computer Security Incident Response Teams (CSIRTs) around the world. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mile-iodef-guidance There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mile-iodef-guidance-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mile-iodef-guidance-02 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile From nobody Fri Apr 18 13:10:20 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF0D1A01C4 for ; Fri, 18 Apr 2014 13:10:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.773 X-Spam-Level: X-Spam-Status: No, score=-9.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MjROUjltFWdH for ; Fri, 18 Apr 2014 13:10:14 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) by ietfa.amsl.com (Postfix) with ESMTP id D89D91A002E for ; Fri, 18 Apr 2014 13:10:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7372; q=dns/txt; s=iport; t=1397851810; x=1399061410; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=WQdNKwD9NDsMa8beFSPi+SxEvZgAAn8hmr1OyvImLUc=; b=AgeSqmGviZ2p/6+lZclhuJUhSY542+VvSd6lluOzTyEHfWmcO0UCfLuH wk3LkxwyEGzK7FE+5eNEtzaoKHPDMxXqRcJZSK05LKNbMYpHLicoEPvxP 2vPPxdrTXVxCSMHEkkxjw5bjpS7ld6oWxiFfvggPX1g31C5DN4eLvujhA M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqMFACiGUVOtJA2I/2dsb2JhbABagwZPUQa8Ooc8gR0WdIIlAQEBAwEBAQE3NBAHBAIBCBEEAQELFAkHJwsUCQgBAQQBEggBiDAICAXNGBeOMQ8pBoMegRQEmiWRGIMxgis X-IronPort-AV: E=Sophos;i="4.97,885,1389744000"; d="scan'208";a="36984924" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-5.cisco.com with ESMTP; 18 Apr 2014 20:10:09 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s3IKA9ff030524 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 18 Apr 2014 20:10:09 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.104]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Fri, 18 Apr 2014 15:10:09 -0500 From: "Panos Kampanakis (pkampana)" To: "Moriarty, Kathleen" , "mile@ietf.org" Thread-Topic: comments/review on draft-ietf-mile-iodef-guidance-02.txt Thread-Index: Ac709IO4yNZG2zJPQSanFWkPwBnnXxmSwTNA Date: Fri, 18 Apr 2014 20:10:08 +0000 Message-ID: <1C9F17D1873AFA47A969C4DD98F98A750FBBEF04@xmb-rcd-x10.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.89.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mile/zTc6Z20YUMrMckSfQeymCghlYRA Subject: Re: [mile] comments/review on draft-ietf-mile-iodef-guidance-02.txt X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2014 20:10:18 -0000 Closing the loop on this: Thanks Kathleen. > Section 4.4 Logic for watchlist of indicators I updated the content to simplify the logic. I also added one more section = that only explains the predicate logic in IODEF (excluding watchlist logic)= . They will both be in the -03 draft. > For the Appendix, the examples are good, but could you add a text descrip= tion to explain the examples Done. I also added an extra section with future usecases from David Missel.= -03 version will include them. I will now work on section 3 & 4 to have more complete draft for the -03 it= eration. Panos -----Original Message----- From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Moriarty, Kathleen Sent: Monday, December 09, 2013 11:04 AM To: mile@ietf.org Subject: [mile] comments/review on draft-ietf-mile-iodef-guidance-02.txt Hello Panos, Thank you for taking the time to update the IODEF-Guidance document. I hav= e a few comments and suggestions and encourage others to review and comment= so that we can progress the draft. It looks like several sections need co= ntent, if implementers would like to contribute content especially in secti= ons 3 & 4, that could be helpful. Also, if implementers have worked throug= h use cases and have guidance from lessons learned, that would be very usef= ul to incorporate as well in addition to the use cases Panos has outlined i= n the draft already. Section 4.4 Logic for watchlist of indicators I think adding in examples will be very helpful in this section to clearly = depict what is meant by each of the ways to represent the AND/OR logic. I'm still having trouble reading and understanding this section. We implem= ented the predicate logic based on initial discussions in our open source c= ode and follow different rules. The description we followed is included as= you can see it is different from the current draft and provides more consi= stency across each of the classes as was originally intended: For Node information, a watchlist of Systems means that the information is = ORed with the other information in the Flow section and an AND with rest of= the content in the EventData grouping. As such, we need to replicate this= pattern elsewhere, which is easy to do in the current format. For HashInf= ormation type, a watchlist type was added for each value to accommodate the= same pattern. In the Key class, a type was added with watchlist as an opt= ion as well. If the watchlist is used, the data provided is just that, a = watchlist of separate values. I think the current description that talks a= bout the watchlist-source and watchlist-destination confuse the logic and i= t could be stated more simply and consistently across the schema in terms o= f how the watchlist attribute effects the logic. Instead of the OR being w= ith the full Flow class, the initial intent was for it to be within the wat= chlist with an AND to the other items unless another watchlist was included= leaving you with a mes h of possibilities for the possible combinations one may detect. In the 5th paragraph, I think this explanations introduces inconsistency in= the logic, I'll explain what I expected... In the Node class, if information is grouped together, it represents the sa= me thing (a single host, but the Node class could include all the informati= on about it - hostname, IP, AS number, etc.). With this pattern, if you se= t the type value for HashInformation to file_hash, the list provided are ju= st alternate representations for the same hash (sha256, sha1, md5, etc.). = For the Key information, it's a little different as the grouping without i= t would just be part of a joined event as opposed to alternate ways to repr= esent the same value. To keep the pattern consistent, I think it would mak= e sense to have the different Keys provided have the tags at the higher lev= el (WindowsRegistryKeyModified tag included), but have them all represented= within the same EventData instance. The included examples are following t= his logic pattern if examples are helpful to weigh in on this Alternatively, we could use separate EventData instances for each value, it= just adds a few more tags around each value, but accomplishes the same log= ic. =20 Once we get this adjusted, examples of each usage with an explanation would= be really helpful to ensure consistency in implementations. For the Appendix, the examples are good, but could you add a text descripti= on to explain the examples providing guidance as to decisions made in the r= epresentation for those use cases to help developers with consistent repres= entation of use cases as it made help reduce coding efforts.=20 If others would like to contribute examples with guidance to increase inte= roperability between implementations for specific use cases, PLEASE DO! Thank you, Kathleen -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of int= ernet-drafts@ietf.org Sent: Friday, October 18, 2013 2:50 PM To: i-d-announce@ietf.org Cc: mile@ietf.org Subject: [mile] I-D Action: draft-ietf-mile-iodef-guidance-02.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Managed Incident Lightweight Exchange Wor= king Group of the IETF. Title : IODEF Usage Guidance Author(s) : Panos Kampanakis Filename : draft-ietf-mile-iodef-guidance-02.txt Pages : 19 Date : 2013-10-18 Abstract: The Incident Object Description Exchange Format [RFC5070] defines a data representation that provides a framework for sharing information commonly exchanged by Computer Security Incident Response Teams (CSIRTs) about computer security incidents. Since the IODEF model includes a wealth of available options that can be used to describe a security incident or issue, it can be challenging for implementers to develop tools that can Leverage IODEF for incident sharing. This document provides guidelines for IODEF implementers. It will also address how common security indicators can be represented in IODEF. The goal of this document is to make IODEF's adoption by vendors easier and encourage faster and wider adoption of the model by Computer Security Incident Response Teams (CSIRTs) around the world. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mile-iodef-guidance There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mile-iodef-guidance-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mile-iodef-guidance-02 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile From nobody Fri Apr 18 16:47:53 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06A691A052E for ; Fri, 18 Apr 2014 16:47:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UpwTV9D9SkRv for ; Fri, 18 Apr 2014 16:47:47 -0700 (PDT) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) by ietfa.amsl.com (Postfix) with ESMTP id 90F3A1A050E for ; Fri, 18 Apr 2014 16:47:47 -0700 (PDT) Received: by mail-qg0-f49.google.com with SMTP id j5so1421883qga.22 for ; Fri, 18 Apr 2014 16:47:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=d+97t+27WhuTTrdbpKmivJvTVB89y5hwUknDUkuU1W0=; b=F1gaLjAosPEuPm8TjrA12lnRBoLqd8PVdHBzBw07bHGlj0g16lsSyUGf6UMBMTi9ib J+ydYYDzJi0Z+jYqUuG0lYiSzLJ9mdf0yLoNS+6SmVGfCz9b3rug1CuGFeK/RcKoLIWG /BDo1U/cPU4RzRBhjv+MiOSm9TRJcwcY8zt1muvKYI5/JnYdSA1+S+T6SSi+Ehx7KcL0 QIyCRUN9bbRexXykinEkTX0YFxCetuf+fe0n7OJDTnUys78E9FQjzKhhfMals2oGkw1X 7CLTC8jYr+P8hQ/T0iEbBlhNshL+2kl9vt66sZsFlWhCljXAc7hcdFQNKUrGhrIQpS/Z GXDA== X-Received: by 10.140.106.66 with SMTP id d60mr14575554qgf.44.1397864863344; Fri, 18 Apr 2014 16:47:43 -0700 (PDT) Received: from [192.168.1.4] (209-6-114-252.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.114.252]) by mx.google.com with ESMTPSA id m1sm57467477qax.1.2014.04.18.16.47.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 18 Apr 2014 16:47:41 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Kathleen Moriarty X-Mailer: iPhone Mail (11D167) In-Reply-To: <1C9F17D1873AFA47A969C4DD98F98A750FBBEF04@xmb-rcd-x10.cisco.com> Date: Fri, 18 Apr 2014 19:47:42 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1C9F17D1873AFA47A969C4DD98F98A750FBBEF04@xmb-rcd-x10.cisco.com> To: "Panos Kampanakis (pkampana)" Archived-At: http://mailarchive.ietf.org/arch/msg/mile/Q89WG6FEsfJN9JrV_CbI-pI-VhM Cc: "mile@ietf.org" , "Moriarty, Kathleen" Subject: Re: [mile] comments/review on draft-ietf-mile-iodef-guidance-02.txt X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2014 23:47:50 -0000 Thank you, Panos! Did you add in the use cases from Trevor as well? They need to be fleshed o= ut with examples, but provide a good start. Best regards, Kathleen=20 Sent from my iPhone > On Apr 18, 2014, at 4:10 PM, "Panos Kampanakis (pkampana)" wrote: >=20 > Closing the loop on this: >=20 > Thanks Kathleen. >=20 >> Section 4.4 Logic for watchlist of indicators >=20 > I updated the content to simplify the logic. I also added one more section= that only explains the predicate logic in IODEF (excluding watchlist logic)= . They will both be in the -03 draft. >=20 >> For the Appendix, the examples are good, but could you add a text descrip= tion to explain the examples >=20 > Done. I also added an extra section with future usecases from David Missel= . -03 version will include them. >=20 > I will now work on section 3 & 4 to have more complete draft for the -03 i= teration. >=20 > Panos >=20 >=20 >=20 > -----Original Message----- > From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Moriarty, Kathleen > Sent: Monday, December 09, 2013 11:04 AM > To: mile@ietf.org > Subject: [mile] comments/review on draft-ietf-mile-iodef-guidance-02.txt >=20 > Hello Panos, >=20 > Thank you for taking the time to update the IODEF-Guidance document. I ha= ve a few comments and suggestions and encourage others to review and comment= so that we can progress the draft. It looks like several sections need con= tent, if implementers would like to contribute content especially in section= s 3 & 4, that could be helpful. Also, if implementers have worked through u= se cases and have guidance from lessons learned, that would be very useful t= o incorporate as well in addition to the use cases Panos has outlined in the= draft already. >=20 > Section 4.4 Logic for watchlist of indicators >=20 > I think adding in examples will be very helpful in this section to clearly= depict what is meant by each of the ways to represent the AND/OR logic. >=20 > I'm still having trouble reading and understanding this section. We imple= mented the predicate logic based on initial discussions in our open source c= ode and follow different rules. The description we followed is included as y= ou can see it is different from the current draft and provides more consiste= ncy across each of the classes as was originally intended: >=20 > For Node information, a watchlist of Systems means that the information is= ORed with the other information in the Flow section and an AND with rest of= the content in the EventData grouping. As such, we need to replicate this p= attern elsewhere, which is easy to do in the current format. For HashInform= ation type, a watchlist type was added for each value to accommodate the sam= e pattern. In the Key class, a type was added with watchlist as an option a= s well. If the watchlist is used, the data provided is just that, a watchl= ist of separate values. I think the current description that talks about th= e watchlist-source and watchlist-destination confuse the logic and it could b= e stated more simply and consistently across the schema in terms of how the w= atchlist attribute effects the logic. Instead of the OR being with the full= Flow class, the initial intent was for it to be within the watchlist with a= n AND to the other items unless another watchlist was included leaving you w= ith a mes > h of possibilities for the possible combinations one may detect. >=20 > In the 5th paragraph, I think this explanations introduces inconsistency i= n the logic, I'll explain what I expected... >=20 > In the Node class, if information is grouped together, it represents the s= ame thing (a single host, but the Node class could include all the informati= on about it - hostname, IP, AS number, etc.). With this pattern, if you set= the type value for HashInformation to file_hash, the list provided are just= alternate representations for the same hash (sha256, sha1, md5, etc.). Fo= r the Key information, it's a little different as the grouping without it wo= uld just be part of a joined event as opposed to alternate ways to represent= the same value. To keep the pattern consistent, I think it would make sens= e to have the different Keys provided have the tags at the higher level (Win= dowsRegistryKeyModified tag included), but have them all represented within t= he same EventData instance. The included examples are following this logic p= attern if examples are helpful to weigh in on this >=20 > Alternatively, we could use separate EventData instances for each value, i= t just adds a few more tags around each value, but accomplishes the same log= ic. =20 >=20 > Once we get this adjusted, examples of each usage with an explanation woul= d be really helpful to ensure consistency in implementations. >=20 >=20 > For the Appendix, the examples are good, but could you add a text descript= ion to explain the examples providing guidance as to decisions made in the r= epresentation for those use cases to help developers with consistent represe= ntation of use cases as it made help reduce coding efforts.=20 >=20 > If others would like to contribute examples with guidance to increase inte= roperability between implementations for specific use cases, PLEASE DO! >=20 > Thank you, > Kathleen >=20 >=20 > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of in= ternet-drafts@ietf.org > Sent: Friday, October 18, 2013 2:50 PM > To: i-d-announce@ietf.org > Cc: mile@ietf.org > Subject: [mile] I-D Action: draft-ietf-mile-iodef-guidance-02.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts directo= ries. > This draft is a work item of the Managed Incident Lightweight Exchange Wor= king Group of the IETF. >=20 > Title : IODEF Usage Guidance > Author(s) : Panos Kampanakis > Filename : draft-ietf-mile-iodef-guidance-02.txt > Pages : 19 > Date : 2013-10-18 >=20 > Abstract: > The Incident Object Description Exchange Format [RFC5070] defines a > data representation that provides a framework for sharing information > commonly exchanged by Computer Security Incident Response Teams > (CSIRTs) about computer security incidents. Since the IODEF model > includes a wealth of available options that can be used to describe a > security incident or issue, it can be challenging for implementers to > develop tools that can Leverage IODEF for incident sharing. This > document provides guidelines for IODEF implementers. It will also > address how common security indicators can be represented in IODEF. > The goal of this document is to make IODEF's adoption by vendors > easier and encourage faster and wider adoption of the model by > Computer Security Incident Response Teams (CSIRTs) around the world. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mile-iodef-guidance >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-mile-iodef-guidance-02 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mile-iodef-guidance-02 >=20 >=20 > Please note that it may take a couple of minutes from the time of submissi= on until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile >=20 > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile >=20 > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From nobody Fri Apr 18 20:44:10 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5458B1A022F for ; Fri, 18 Apr 2014 20:44:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.773 X-Spam-Level: X-Spam-Status: No, score=-9.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2lDRSTFD5Q4d for ; Fri, 18 Apr 2014 20:44:07 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id 40F331A0039 for ; Fri, 18 Apr 2014 20:44:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8493; q=dns/txt; s=iport; t=1397879043; x=1399088643; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Xs8CUCbaosfkqsVe47WTv4TPe6+D+M9jeZV2FwCZGHQ=; b=LSlQ9yfHrVyzIlLXQI6h48I7ma7zw5LfZaaB8lYkhhZXhze/OWf2dSDQ KCupFjhy3S+TTZv5ZRn3MDKlpglnxpwHfxsyiPxKB20lFcaOrEzX4bm+H Fjl+cPOytMeKF4AfKEn6vsh+ScTQZdT/+JiYgDAE/9zTntkkrwkHuNfR4 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAOPvUVOtJV2c/2dsb2JhbABagwZPUQa8Poc8gRoWdIIlAQEBAwEBAQE3NAsFBwQCAQgRBAEBAQoUCQchBgsUCQgCBA4FCAGIJAMJCAgFxkUNhmsXjEmBaDEHBoMegRQElwCDJYtHhVGDMYIr X-IronPort-AV: E=Sophos;i="4.97,887,1389744000"; d="scan'208";a="37081628" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-2.cisco.com with ESMTP; 19 Apr 2014 03:44:02 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s3J3i2ah002984 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 19 Apr 2014 03:44:02 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.104]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Fri, 18 Apr 2014 22:44:01 -0500 From: "Panos Kampanakis (pkampana)" To: Kathleen Moriarty Thread-Topic: [mile] comments/review on draft-ietf-mile-iodef-guidance-02.txt Thread-Index: AQHPW2CZ2pG78lKFTkSPK3xrUDAFTJsYTFVA Date: Sat, 19 Apr 2014 03:44:01 +0000 Message-ID: <1C9F17D1873AFA47A969C4DD98F98A750FBBF46E@xmb-rcd-x10.cisco.com> References: <1C9F17D1873AFA47A969C4DD98F98A750FBBEF04@xmb-rcd-x10.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.108.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mile/su4Y5Cbj-mC2gx23VJ_nXKeBVjA Cc: "mile@ietf.org" , "Moriarty, Kathleen" Subject: Re: [mile] comments/review on draft-ietf-mile-iodef-guidance-02.txt X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 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, 19 Apr 2014 03:44:09 -0000 Yes. I rephrased the text to make it shorter without compromising the conte= xt though. Panos -----Original Message----- From: Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail.com]=20 Sent: Friday, April 18, 2014 7:48 PM To: Panos Kampanakis (pkampana) Cc: Moriarty, Kathleen; mile@ietf.org Subject: Re: [mile] comments/review on draft-ietf-mile-iodef-guidance-02.tx= t Thank you, Panos! Did you add in the use cases from Trevor as well? They need to be fleshed = out with examples, but provide a good start. Best regards, Kathleen=20 Sent from my iPhone > On Apr 18, 2014, at 4:10 PM, "Panos Kampanakis (pkampana)" wrote: >=20 > Closing the loop on this: >=20 > Thanks Kathleen. >=20 >> Section 4.4 Logic for watchlist of indicators >=20 > I updated the content to simplify the logic. I also added one more sectio= n that only explains the predicate logic in IODEF (excluding watchlist logi= c). They will both be in the -03 draft. >=20 >> For the Appendix, the examples are good, but could you add a text descri= ption to explain the examples >=20 > Done. I also added an extra section with future usecases from David Misse= l. -03 version will include them. >=20 > I will now work on section 3 & 4 to have more complete draft for the -03 = iteration. >=20 > Panos >=20 >=20 >=20 > -----Original Message----- > From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Moriarty, Kathleen > Sent: Monday, December 09, 2013 11:04 AM > To: mile@ietf.org > Subject: [mile] comments/review on draft-ietf-mile-iodef-guidance-02.txt >=20 > Hello Panos, >=20 > Thank you for taking the time to update the IODEF-Guidance document. I h= ave a few comments and suggestions and encourage others to review and comme= nt so that we can progress the draft. It looks like several sections need = content, if implementers would like to contribute content especially in sec= tions 3 & 4, that could be helpful. Also, if implementers have worked thro= ugh use cases and have guidance from lessons learned, that would be very us= eful to incorporate as well in addition to the use cases Panos has outlined= in the draft already. >=20 > Section 4.4 Logic for watchlist of indicators >=20 > I think adding in examples will be very helpful in this section to clearl= y depict what is meant by each of the ways to represent the AND/OR logic. >=20 > I'm still having trouble reading and understanding this section. We impl= emented the predicate logic based on initial discussions in our open source= code and follow different rules. The description we followed is included = as you can see it is different from the current draft and provides more con= sistency across each of the classes as was originally intended: >=20 > For Node information, a watchlist of Systems means that the information i= s ORed with the other information in the Flow section and an AND with rest = of the content in the EventData grouping. As such, we need to replicate th= is pattern elsewhere, which is easy to do in the current format. For HashI= nformation type, a watchlist type was added for each value to accommodate t= he same pattern. In the Key class, a type was added with watchlist as an o= ption as well. If the watchlist is used, the data provided is just that, = a watchlist of separate values. I think the current description that talks= about the watchlist-source and watchlist-destination confuse the logic and= it could be stated more simply and consistently across the schema in terms= of how the watchlist attribute effects the logic. Instead of the OR being= with the full Flow class, the initial intent was for it to be within the w= atchlist with an AND to the other items unless another watchlist was includ= ed leaving you with a mes > h of possibilities for the possible combinations one may detect. >=20 > In the 5th paragraph, I think this explanations introduces inconsistency = in the logic, I'll explain what I expected... >=20 > In the Node class, if information is grouped together, it represents the = same thing (a single host, but the Node class could include all the informa= tion about it - hostname, IP, AS number, etc.). With this pattern, if you = set the type value for HashInformation to file_hash, the list provided are = just alternate representations for the same hash (sha256, sha1, md5, etc.).= For the Key information, it's a little different as the grouping without= it would just be part of a joined event as opposed to alternate ways to re= present the same value. To keep the pattern consistent, I think it would m= ake sense to have the different Keys provided have the tags at the higher l= evel (WindowsRegistryKeyModified tag included), but have them all represent= ed within the same EventData instance. The included examples are following= this logic pattern if examples are helpful to weigh in on this >=20 > Alternatively, we could use separate EventData instances for each value, = it just adds a few more tags around each value, but accomplishes the same l= ogic. =20 >=20 > Once we get this adjusted, examples of each usage with an explanation wou= ld be really helpful to ensure consistency in implementations. >=20 >=20 > For the Appendix, the examples are good, but could you add a text descrip= tion to explain the examples providing guidance as to decisions made in the= representation for those use cases to help developers with consistent repr= esentation of use cases as it made help reduce coding efforts.=20 >=20 > If others would like to contribute examples with guidance to increase int= eroperability between implementations for specific use cases, PLEASE DO! >=20 > Thank you, > Kathleen >=20 >=20 > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of i= nternet-drafts@ietf.org > Sent: Friday, October 18, 2013 2:50 PM > To: i-d-announce@ietf.org > Cc: mile@ietf.org > Subject: [mile] I-D Action: draft-ietf-mile-iodef-guidance-02.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Managed Incident Lightweight Exchange Wo= rking Group of the IETF. >=20 > Title : IODEF Usage Guidance > Author(s) : Panos Kampanakis > Filename : draft-ietf-mile-iodef-guidance-02.txt > Pages : 19 > Date : 2013-10-18 >=20 > Abstract: > The Incident Object Description Exchange Format [RFC5070] defines a > data representation that provides a framework for sharing information > commonly exchanged by Computer Security Incident Response Teams > (CSIRTs) about computer security incidents. Since the IODEF model > includes a wealth of available options that can be used to describe a > security incident or issue, it can be challenging for implementers to > develop tools that can Leverage IODEF for incident sharing. This > document provides guidelines for IODEF implementers. It will also > address how common security indicators can be represented in IODEF. > The goal of this document is to make IODEF's adoption by vendors > easier and encourage faster and wider adoption of the model by > Computer Security Incident Response Teams (CSIRTs) around the world. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mile-iodef-guidance >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-mile-iodef-guidance-02 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mile-iodef-guidance-02 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile >=20 > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile >=20 > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From nobody Mon Apr 21 15:28:22 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29C2D1A02E6; Mon, 21 Apr 2014 15:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.474 X-Spam-Level: X-Spam-Status: No, score=-99.474 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id irhsFTQDoAdA; Mon, 21 Apr 2014 15:28:16 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 61C0E1A0067; Mon, 21 Apr 2014 15:28:16 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 4ED4718000C; Mon, 21 Apr 2014 15:27:29 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 6000:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20140421222729.4ED4718000C@rfc-editor.org> Date: Mon, 21 Apr 2014 15:27:29 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/mile/tKEVD4Au5HQkFT-xZWD7T_8nSd8 Cc: mile@ietf.org, drafts-update-ref@iana.org, rfc-editor@rfc-editor.org Subject: [mile] RFC 7203 on An Incident Object Description Exchange Format (IODEF) Extension for Structured Cybersecurity Information X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 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, 21 Apr 2014 22:28:21 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7203 Title: An Incident Object Description Exchange Format (IODEF) Extension for Structured Cybersecurity Information Author: T. Takahashi, K. Landfield, Y. Kadobayashi Status: Standards Track Stream: IETF Date: April 2014 Mailbox: takeshi_takahashi@nict.go.jp, kent_landfield@mcafee.com, youki-k@is.aist-nara.ac.jp Pages: 28 Characters: 57694 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mile-sci-13.txt URL: http://www.rfc-editor.org/rfc/rfc7203.txt This document extends the Incident Object Description Exchange Format (IODEF) defined in RFC 5070 to exchange enriched cybersecurity information among security experts at organizations and facilitate their operations. It provides a well-defined pattern to consistently embed structured information, such as identifier- and XML-based information. This document is a product of the Managed Incident Lightweight Exchange Working Group of the IETF. This is now a Proposed Standard. 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/search 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 nobody Tue Apr 22 14:15:12 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC3551A025C for ; Tue, 22 Apr 2014 14:15:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.073 X-Spam-Level: X-Spam-Status: No, score=-12.073 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9yqZUjoID2WR for ; Tue, 22 Apr 2014 14:15:06 -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 E9A3E1A025D for ; Tue, 22 Apr 2014 14:15:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13127; q=dns/txt; s=iport; t=1398201301; x=1399410901; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=INcoq3vy06ME6o85ZCNq3KzKj3+zoEi6JuhsxMyHkc0=; b=DXoYxuGqj2KpSVNF7y/olVWQU1QBTLhBCxVb8Xu1JmBsdiTcpXH5sxfH Onp/3LZKlVEkRNE0yKLdAcm+0utjcxjW/VPiN1Uk7BbR/DUi7Y6ruAfOF 5iqPp0onShfmbX7DFzb3CVMwhdSpWk6ydQ9aA9iEuyxh78nObL1tyDnM7 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah0FAHPbVlOtJA2I/2dsb2JhbABZgwZPV7xkhzqBFhZ0giUBAQEDAQEBATc0EAcEAgEIEQQBAQsUCQcnCxQJCAEBBAESCIgxCA3NaheNdBEBHwYyAgSDHoEUBJUChSWRG4MxgXI5 X-IronPort-AV: E=Sophos;i="4.97,906,1389744000"; d="scan'208";a="319557264" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-7.cisco.com with ESMTP; 22 Apr 2014 21:14:55 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s3MLEsvm014408 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 22 Apr 2014 21:14:54 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.104]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0123.003; Tue, 22 Apr 2014 16:14:54 -0500 From: "Panos Kampanakis (pkampana)" To: "Roman D. Danyliw" , "mile@ietf.org" Thread-Topic: IODEF predicate logic Thread-Index: Ac6BljICQSOPLvR4RuCRb/L6J7DnMgKmeGjAAKx8x3AAKgYtIBlb+GdwGl1L5nA= Date: Tue, 22 Apr 2014 21:14:53 +0000 Message-ID: <1C9F17D1873AFA47A969C4DD98F98A750FBC4FE9@xmb-rcd-x10.cisco.com> References: <1C9F17D1873AFA47A969C4DD98F98A753E59AE@xmb-rcd-x10.cisco.com> <359EC4B99E040048A7131E0F4E113AFC13C56E47@marathon> <1C9F17D1873AFA47A969C4DD98F98A750484C404@xmb-rcd-x10.cisco.com> <359EC4B99E040048A7131E0F4E113AFC13C5A1FB@marathon> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.89.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mile/ocoa3_rAdVF8ev-k5XlqxjR_BxQ Subject: Re: [mile] IODEF predicate logic X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 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, 22 Apr 2014 21:15:11 -0000 Hi Roman, As I am making the updates for version -03, I thought to answer your questi= ons in "**" using "pk>" below: ** What's the semantics of multiple EventData classes into a parent EventDa= ta? pk> To answer it I added=20 "An EventData class that contains multiple EventData classes depicts an Event that consists of smaller events. For the parent=20 event to take place, or the the children EventData events SHOULD take place." ** What is the difference between annotating a System to be a watchlist-sou= rce or watchlist-destination? In the example XML snippet below, an express= ion of "(IP1 OR IP2 or IP3) AND (IP4 OR IP5 OR IP6)" was created. How woul= d have using "watchlist-destination" have changed the expression? Is it th= at things marked as source warns of inbound connections to a network? pk> Source and Target mean checking the source or destination of that host.= So, they are not just addresses, but they are distinguishing between IP.sr= c and IP.dst. ** Can one create a Flow with a System@category=3D"source" and System@categ= ory=3D"watchlist-source"? If so, what would that mean? pk> No. To explain it I added=20 "There SHOULD NOT be more than=20 one "source" or "watchlist-source" and one "target"=20 or "watchlist-target" System Nodes per Flow." ** Can one create an EventData with two Flows, one Flow has several System@= category=3D"watchlist-source" and another exclusively of several System@cat= egory=3D"source"? If so, what would that mean? pk> I added the text=20 "An EventData class with multiple=20 Flows means that all the information defined in the=20 flows need to exist for the event described to take place." So, both Flow would need to be seen for the event to take place. That is y= ou would need to see a Flow with the "source" and a Flow with either of the= "watchlist-sources". ** Do these expressions only apply to the IP address, or other things that = can be indicators too? For example, say I had:
IP1
80
IP2
... =20 Would the expression be "(IP1 OR 80 OR IP2)"? "(IP1 AND 80 AND IP2)"? "((IP= 1 OR 80) OR IP2)"? "((IP1 AND 80) OR IP2)? What I'm asking is what is the= parsing rule of multiple indicators in a given Node? pk> They apply to the whole node. Thus your XML would mean ((IP.src=3D=3DIP1) && (src_port=3D80)) || (IP.src=3D=3DIP2) > Different Flow > classes > that consist of different System classes (with watchlist-source > or destination as attributes) follow AND logic in their parent > EventData Class. " > in order to make it clearer. Makes more sense? ** The double use of different confuses me also. Do you mean "Distinct Flo= w classes with the same parent EventData classes are ANDed together", aka p= arsing rule (b) from above? pk> I re-wrote the whole logic to simplify it. The -03 version will be out = soon and I encourage you to check it to make sure it makes sense. Panos -----Original Message----- From: Moriarty, Kathleen [mailto:kathleen.moriarty@emc.com]=20 Sent: Monday, December 09, 2013 11:19 AM To: Roman D. Danyliw; Panos Kampanakis (pkampana); mile@ietf.org Subject: RE: IODEF predicate logic Panos, I am re-sending this summary of previous questions to the list on the logic= included in the IODEF-Guidance so you and others don't have to dig it up. = I think when you include examples, it would be helpful to make sure these = questions are addressed with the updated description and logic. An explana= tion around each example would be helpful in this section to help implement= ers with consistency between implementations. Thanks! Kathleen -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Rom= an D. Danyliw Sent: Monday, August 05, 2013 8:02 AM To: Panos Kampanakis (pkampana); mile@ietf.org Subject: Re: [mile] IODEF predicate logic Hi Panos, Response inline ... > -----Original Message----- > From: Panos Kampanakis (pkampana) [mailto:pkampana@cisco.com] > Sent: Thursday, August 01, 2013 2:56 PM > To: Roman D. Danyliw; mile@ietf.org > Subject: RE: IODEF predicate logic >=20 > Hi Roman, >=20 > Thank you for the comments. I answer them below. ">>>" is in front of=20 > your questions. >=20 > >>> In your email below you used the terminology "multiple=20 > >>> indicators on > one folder" which I hadn't read before. Did you mean multiple=20 > indicators in a single IODEF document? >=20 > Yes >=20 > >>> Isn't that reversed, "When an IODEF **System** consists of two or=20 > >>> more > **Node** classes with the category attribute set to watchlist-source=20 > or watchlist-destination ...", since Node sub-element of System? > However, this isn't consistent with the -00 draft since System can=20 > only contain exactly 1 node. >=20 > You are right, it wasnot clear. I will rephrase it to something like "=20 > When a Flow Class that consists of multiple Systems with > watchlist-source and watchlist-destination attributes (watchlist of > Systems) the System information should be ORed for the Flow Class > described... " > Looks better? I'm still having a little bit of trouble. To reason about it, I listed the= interpretation of the example below into a series of parsing rules: (a) Multiple Systems in a given Flow are combined together into single expr= ession where each IP is OR-ed (b) Multiple Flow classes in a given EventData are combined into a series o= f expressions each AND-ed together Is that right? This leads me to ask the following questions: ** What's the semantics of multiple EventData classes into a parent EventDa= ta? ** What is the difference between annotating a System to be a watchlist-sou= rce or watchlist-destination? In the example XML snippet below, an express= ion of "(IP1 OR IP2 or IP3) AND (IP4 OR IP5 OR IP6)" was created. How woul= d have using "watchlist-destination" have changed the expression? Is it th= at things marked as source warns of inbound connections to a network? ** Can one create a Flow with a System@category=3D"source" and System@categ= ory=3D"watchlist-source"? If so, what would that mean? ** Can one create an EventData with two Flows, one Flow has several System@= category=3D"watchlist-source" and another exclusively of several System@cat= egory=3D"source"? If so, what would that mean? ** Do these expressions only apply to the IP address, or other things that = can be indicators too? For example, say I had:
IP1
80
IP2
... =20 Would the expression be "(IP1 OR 80 OR IP2)"? "(IP1 AND 80 AND IP2)"? "((IP= 1 OR 80) OR IP2)"? "((IP1 AND 80) OR IP2)? What I'm asking is what is the= parsing rule of multiple indicators in a given Node? > >>> ... > >
IP1
... > >
IP2
... > >
IP3
... > >
IP4
... > >
IP5
... > >
IP6
... > > Is the watchlist defined as "(IP1 OR IP2 or IP3) AND (IP4 OR IP5 OR IP6)"= ? >=20 > Yes. If an company saw IP1 or 2 or 3 only they should not think they=20 > are seeing the indicator. > > >>> Is this AND logic applied across different Flow classes or any=20 > >>> other > indicator in the EventData class parent outside of the Flow parent of=20 > the given System class of interest? >=20 > Yes, I will rephrase it to " The content in > the EventData Class the Node belongs to should be combined with > the watchlist of Systems using AND logic.=20 It's the use of Node here that still confuses me since a Node is inside a S= ystem. Could you express this sentence as a parsing statement like above? > Different Flow > classes > that consist of different System classes (with watchlist-source > or destination as attributes) follow AND logic in their parent > EventData Class. " > in order to make it clearer. Makes more sense? The double use of different confuses me also. Do you mean "Distinct Flow c= lasses with the same parent EventData classes are ANDed together", aka pars= ing rule (b) from above? Roman =20 > Panos >=20 >=20 >=20 > -----Original Message----- > From: Roman D. Danyliw [mailto:rdd@cert.org] > Sent: Tuesday, July 30, 2013 5:54 AM > To: Panos Kampanakis (pkampana); mile@ietf.org > Subject: RE: IODEF predicate logic >=20 > Hi Panos! >=20 > Could you describe a little more about what you had in mind with the=20 > predicate logic? In your email below you used the terminology=20 > "multiple indicators on one folder" which I hadn't read before. Did=20 > you mean multiple indicators in a single IODEF document? >=20 > In seeking clarity in Section 4.4 of draft-ietf-mile-iodef-guidance-01=20 > I had a few questions. Citing this section ... >=20 > > [I-D.ietf-mile-rfc5070-bis] defines two new category attributes in=20 > > the System Class. These are watchlist-source and watchlist-=20 > > destination and they serve for watchlist indicator groupings. When=20 > > an IODEF Node consists of two or more System Classes with various=20 > > watchlist-source and watchlist-destination attributes (watchlist of > > Systems) >=20 > Isn't that reversed, "When an IODEF **System** consists of two or=20 > more > **Node** classes with the category attribute set to watchlist-source=20 > or watchlist-destination ...", since Node sub-element of System? > However, this isn't consistent with the -00 draft since System can=20 > only contain exactly 1 node. >=20 > [snip] > > > > ... >=20 > > the System information should be ORed with the information in the=20 > > Flow Class. >=20 > Could you clarify what it means to be OR multiple Systems in the flow cla= ss? > For example, with a snippet as follows, >=20 > ... > >
IP1
... > >
IP2
... > >
IP3
... > >
IP4
... > >
IP5
... > >
IP6
... > >=20 > Is the watchlist defined as "(IP1 OR IP2 or IP3) AND (IP4 OR IP5 OR IP6)"= ? >=20 > > In other words, either System description should be considered as a=20 > > watchlist indicator. The rest of the content in the EventData Class=20 > > the Node belongs to should be combined with the watchlist of Systems=20 > > using AND logic. >=20 > Is this AND logic applied across different Flow classes or any other=20 > indicator in the EventData class parent outside of the Flow parent of=20 > the given System class of interest? >=20 > Roman >=20 > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf=20 > Of Panos Kampanakis (pkampana) > Sent: Monday, July 15, 2013 4:02 PM > To: mile@ietf.org > Subject: [mile] IODEF predicate logic >=20 > Hello everyone, >=20 > In the past people have asked how IODEF can combine multiple=20 > indicators in one IODEF definition. For example a question can be, if=20 > there are more than two malicious addresses, how they can be added in=20 > one definition and what is the logic behind how they are combined? >=20 > draft-ietf-mile-rfc5070-bis-00 introduces some watchlist fields that=20 > allow for multiple indicators on one folder. In > draft-ietf-mile-iodef-guidance-01 I have added section > http://tools.ietf.org/html/draft-ietf-mile-iodef-guidance- > 01#section-4.4 that describes how the predicate logic works. >=20 > Comments and thoughts are welcome. >=20 > Rgs, > Panos _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile From nobody Wed Apr 23 06:43:46 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA6581A03A8; Wed, 23 Apr 2014 06:43:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.073 X-Spam-Level: X-Spam-Status: No, score=-7.073 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fs4hOs7armC7; Wed, 23 Apr 2014 06:43:42 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id 7E2F81A03A7; Wed, 23 Apr 2014 06:43:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4927; q=dns/txt; s=iport; t=1398260617; x=1399470217; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=uNz3VONHNZ0uMfaFgYg8e+6aAi/wNRestHsh918oUzM=; b=iPThMa30kdg43ty25ggVCviK/0f6SZVasuKEfaWxUa5m+Wtbj+Cfaqga Oq4AI2cArmFNZr3gTXjHQLQbWYcTPKIYEYBa46lyeu5x/vSFQrxtgHSip EY+sUzXWsirCK+lLlHY7U8Tg6oOZLvGu8mzjFmjBIe1DWjZT2Hbzmo7YK A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmQFAGXCV1OtJA2G/2dsb2JhbABZgwZPV4MPwSSBGRZ0giUBAQEEHQQBRgMgAQgZAwYFGgM0GwEGBAEEARIIiDkNj32cFgGjJBMEgSaIEIRKJ4MkOIEVBKNwh1qDMYFpQg X-IronPort-AV: E=Sophos;i="4.97,912,1389744000"; d="scan'208";a="38067909" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-2.cisco.com with ESMTP; 23 Apr 2014 13:43:36 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s3NDha9Q025123 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 23 Apr 2014 13:43:36 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.104]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0123.003; Wed, 23 Apr 2014 08:43:36 -0500 From: "Panos Kampanakis (pkampana)" To: "sacm@ietf.org" , "mile@ietf.org" Thread-Topic: ACM Workshop on Information Sharing and Collaborative Security (WISCS 2014) Thread-Index: Ac9e+gJflo6S7CC8TFOKyLWrJmF5Xw== Date: Wed, 23 Apr 2014 13:43:35 +0000 Message-ID: <1C9F17D1873AFA47A969C4DD98F98A750FBC6AA5@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.89.121] Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mile/TeJRow8CTEnS6bv1BGHqjKDKqxo Subject: [mile] FW: ACM Workshop on Information Sharing and Collaborative Security (WISCS 2014) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 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, 23 Apr 2014 13:43:44 -0000 I apologize for the wide distribution. Panos ------------ CALL FOR PAPERS FIRST ACM WORKSHOP ON INFORMATION SHARING AND COLLABORATIVE SECURITY (WISCS= 2014) =20 https://sites.google.com/site/wiscs2014/ Held in conjunction with 21st ACM Conference on Computer and Communications= Security (CCS), Scottsdale, Arizona, USA.=20 Nov. 3, 2014 Sharing of security related information is believed to greatly enhance the = ability of organizations to defend themselves against sophisticated attacks= . If one organization detects a breach the automated sharing of observed se= curity indicators (such as IP addresses, domain names etc.) provide valuabl= e, actionable information to others. Through analyzing shared data it seems= possible to get much better insights into emerging attacks. Sharing higher= level intelligence about campaigns, threat actors and mitigations is also = of great interest. Both in the US and the EU there are major efforts underw= ay to strengthen information sharing. Yet there are a number of technical and policy challenges to realizing this= vision. Which information exactly should be shared? How can privacy and co= nfidentiality be protected? How can we create high-fidelity intelligence fr= om shared data without getting overwhelmed by false positives? The first Workshop on Information Sharing and Collaborative Security (WISCS= 2014) aims to bring together experts and practitioners from academia, indu= stry and government to present innovative research, case studies, and legal= and policy issues. Topics of interest for the workshop include, but are no= t limited to: Collaborative intrusion detection Case studies for information sharing Domain name and IP address blacklisting=20 Collaborative approaches to spear=1B$B!>=1B(Bphishing and DDoS attacks Data deidentification Privacy and confidentiality Cryptographic protocols for collaborative security Scalability of security analysis on shared data Ontologies and standards for sharing security data=20 Human factors in collaboration Policy and legal issues Surveillance issues=20 Trust models=20 Attacks on information sharing Economics of security collaboration IMPORTANT DATES Paper submission due: July 1, 2014 Author notification: August 10, 2014 Camera read copies due: August 24, 2014=20 Workshop: Nov 3, 2014.=20 STEERING COMMITTEE Tomas Sander, HP Richard Struse, DHS Moti Yung, Columbia University and Google=20 PROGRAM CHAIR Tomas Sander, HP PROGRAM COMMITTEE Matt Bishop, UC Davis Travis Breaux, Carnegie Mellon University =20 Sarah Brown, Fox-IT =20 Jerry Bryant, Microsoft Eric Burger, Georgetown University Scott Coull, Redjack Marc Dacier Freddy Dezeure, CERT-EU Carol Fung, Virginia Commonwealth University =20 Panos Kampanikis, CISCO =20 Florian Kerschbaum, SAP =20 Susan Landau, Worcester Polytechnic Institute =20 Tom Millar, US CERT =20 Kathleen Moriarty, EMC Eric Osterweil, Verisign Christos Papadopoulos, Colorado State University =20 Vern Paxson, UC Berkeley and ICSI Benny Pinkas, Bar Ilan University =20 Phillip Porras, SRI =20 Ravi Sandhu, UT San Antonio =20 Stuart Shapiro, MITRE =20 Johannes Ullrich, SANS =20 Paul Vixie, Farsight Security =20 Bulent Yener, Rensselaer Polytechnic Institute PAPER SUBMISSIONS Submitted papers must not substantially overlap with papers that have been = published or that are simultaneously submitted to a journal or a conference= with proceedings. Regular submissions should be at most 10 pages in the AC= M double-column format including bibliography, but excluding well-marked ap= pendices, and at most 12 pages total. Committee members are not required to= read the appendices, and so the paper should be intelligible without them.= Submissions should not be anonymized.=20 Submissions are to be made to the EasyChair submission web site at https://= www.easychair.org/conferences/?conf=3Dwiscs2014 . You will be requested to= upload the file of your paper (in PDF format only). Submissions not meetin= g these guidelines risk rejection without consideration of their merits. Pa= pers must be received by the deadline of July 1, 2013 to be considered. Not= ification of acceptance or rejection will be sent to authors by August 10, = 2013. The camera ready versions must be prepared by August 24, 2014 (firm).= Proceedings of the workshop will be published by ACM on a CD, available to= the workshop attendees. Papers will be included in the ACM Digital Library= , with a specific ISBN. Each accepted paper must be presented by an author,= who will have to be registered by the early-bird registration deadline. CONTACT Please contact the program chair Tomas Sander (wiscs2014@easychair.org) wit= h any questions. From nobody Fri Apr 25 08:41:26 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CCC91A0342 for ; Fri, 25 Apr 2014 08:41:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.628 X-Spam-Level: * X-Spam-Status: No, score=1.628 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_56=0.6, J_CHICKENPOX_57=0.6, RP_MATCHES_RCVD=-0.272] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YxVgn9wVJGpf for ; Fri, 25 Apr 2014 08:41:19 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 281121A0572 for ; Fri, 25 Apr 2014 08:41:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1398440472; d=isode.com; s=selector; i=@isode.com; bh=UqJVz0iMGjE4h6qTwwe18rikjYuOwqOIBqMQu75ieYo=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=qRAKWIKAjdEa0jSaP/0TB0a04ItcWxPErglbJR7OtVENFsqAkkDhGdaKPYpsEi7VZQAfpf ACEs43gpq8wydXhY2cK/zuotdsHzSOBBDJ4jF9YqE9u8gISteIGc0YxPJpiOYX+PQVXkuZ EFHFz/J+iSpBRWC+2L+nmT9TC+sIdC8=; Received: from [172.17.128.46] (richard.isode.com [62.3.217.249]) by waldorf.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 25 Apr 2014 16:41:10 +0100 Message-ID: <535A8229.8000905@isode.com> Date: Fri, 25 Apr 2014 16:41:29 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 To: mile@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mile/KAygPOdBLdKm_iqaMNc5Gxo3AVM Subject: [mile] Fwd: New Version Notification for draft-murillo-mile-cps-00.txt X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 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, 25 Apr 2014 15:41:22 -0000 Takeshi has troubles posting to the mailing list, so he asked to forward his email. -------- Original Message -------- > -----Original Message----- > From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp] > Sent: Wednesday, April 23, 2014 2:29 PM > To: murillo@ieee.org; 'mile@ietf.org' > Subject: RE: [mile] Fwd: New Version Notification for > draft-murillo-mile-cps-00.txt > > Hi Martin, > > I've read through the drafts. Thank you very much for sharing your expertise > here. > It was a new use case for me, and was really interesting. > > I am wondering if we can minimize the number of extension fields by using > the existing IODEF fields. > By minimizing the number of similar fields, I hope we can simplify the draft > and minimize the burden of implementations. > > From this viewpoint, let me ask several checking questions. > > 1. IncidentType element and IncdntType Attribute > What are the difference between them? I think your current draft has > them as place holders. I would like to hear a bit further. > > 2. The IncidentTitle element > Can we use the Description element inside the IODEF:Incident class for > this purpose, instead of having new field here? > It would be useful to have title or such information that can hint the > content of the IODEF document, but I feel like that it would be helpful > to have this type of information at the shallower level of IODEF document > rather than having it in the deeper level of IODEF document (inside > additionalData) > > 3. The ReportingParty element > Can we use the IODEF:contact class instead of having new field? We could > extend it further if needed. > > 4. The ReportReliability element > Can we use the IODEF:confidence class instead of having new field? We > could extend it further if needed. > > 5. The TargetSystems element > Can we extend the IODEF:system class instead of having new field? We > could extend it further if needed. > > 6. type attribute of the IODEF:Impact class > When we use this extension, what value should be set for the type > attribute of the IODEF:Impact class? > > By the way, here are small questions. > > 1. should [SFC] be [SFK], since the acronym seems to come from the initials > of the authors of the reference (Stouffer, K., Falco, J., and K. Scarfonw) ? > > I might have misunderstood your draft, so please correct me if I am wrong. > > Kind regards, > Take > > > > -----Original Message----- > > From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Martin Murillo > > Sent: Wednesday, January 29, 2014 10:11 AM > > To: Johnson, Blake; Jerome Athias > > Cc: mile@ietf.org > > Subject: Re: [mile] Fwd: New Version Notification for > > draft-murillo-mile-cps-00.txt > > > > Have read the links posted by Jerome and info on the Experience > > Sharing Tool (EST). It is my impression that a revision under the > > light of the EST would be very appropriate, and one of the first uses > > of the extension, given its report-based nature. Look forward to seeing > the reviews in this light. > > > > As Jerome mentioned, focusing on referencing already existing > > taxonomies (and when necessary reusing them and referencing their xml > > implementations, if publicly available) would be the best approach; > > given the early stages in the field, I tend to think that atomic data > will need to be used. > > > > Regarding the term "Asset" vs "System", I believe system provides a > > more general connotation, while asset, seem to focus more on > > mainstream infrastructure; because the inclusion of IoT-related > > infrastructure (anywhere from centralized home control to self-driving > > cars), I wonder whether "Asset" is too an specific term. > > > > Martin > > > > Martin > > > > On 1/24/2014 2:09 PM, Johnson, Blake wrote: > > > This is an interesting application of IODEF that I had not considered. > > Most industry sharing that takes place in this space, from my > > perspective, is in the form of in person and telephone threat > > briefings. These are facilitated by the FBI, DHS, and the ISAC's. > > > > > > At least a handful of the ISAC's have started sharing structured > > > threat > > indicator data, and the taxonomy for this extension could cover what > > the Electric Sector ISAC currently refers to as 'Experience Sharing.' > > I can review this proposal as it relates to information captured by > > the ES-ISAC's Experience Sharing tool, using IEC/ANSI 62443 (ISA99) as > > an informative reference. > > > > > > Blake Johnson > > > Threat Intelligence Analyst > > > Alliant Energy | Infrastructure Secruity > > > Office: 608-458-6320 | Cell: 608-843-2790 > > > > > > > > > -----Original Message----- > > > From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Jerome Athias > > > Sent: Friday, January 24, 2014 3:18 AM > > > To: murillo@ieee.org > > > Cc: mile@ietf.org > > > Subject: Re: [mile] Fwd: New Version Notification for > > > draft-murillo-mile-cps-00.txt > > > > > > Hi, > > > > > > from what I know (which is limited), and as you mention, this ICS > > > area is often also called Critical Infrastructures (CIs), or SCADA > > > > > > for a little bit of background, we could explore the Cybersecurity > > > Framework Example references > > > http://www.nerc.com/pa/Stand/Pages/CIPStandards.aspx > > > > > > http://www.ictqatar.qa/en/documents/download/National%20Industrial%20C > > > ontrol%20Systems%20Security%20Standard-English.pdf > > > ANSI/ISA-99.02.01-2009 > > > > > > I don't have enough knowledge about the status and adoption of the > > > different efforts in term of XML representation/format/standards > > > http://xml.coverpages.org/emergencyManagement.html > > > and resilience > > > > > > It would maybe be possible to obtain information from there > > > http://ics-cert.us-cert.gov http://ics-isac.org/ > > > > > > My first feedback is that it looks like an interesting extension. > > > > > > I would suggest to focus on the reuse of existing Taxonomies, or > > > references to them. > > > > > > As such, for [Industry], maybe > > > http://www.census.gov/cgi-bin/sssd/naics/naicsrch?chart=2012 > > > ISO 3166 (Country Codes) > > > > > > > > > [TargetSystems], I (personally) don't like the word "system" and > > > prefer > > "asset" > > > > > > [CompromisedPhysicalInfrastrucute] (with a typo ;p) seems to be a > > > category of "Infrastructure" (or group of assets) > > > > > > > > > [EntryPoint] could be ok since it could be a little bit different > > > from "endpoint" > > > > > > [PerpetratingParty] seems to reference "Threat Actor" or "Threat > > > Agent" or "Attacker" > > > > > > [RecurrencePreventionMeasures] is this Security Controls? (and > > > Mitigations/Remediations) > > > Reference: > > > > https://web.nvd.nist.gov/view/800-53/control?controlName=AC-3&type=1 > > > > > > > > > Describing an [Exploit] is not so easy (depending on the level of > > > details wanted/needed) > > > > > > Figure 1 (or "Diagram 1") is interesting, (of course it is different > > > from, i.e. CAESARS), it MAYBE could be more layered > > > > > > http://www.isa.org/InTechTemplate.cfm?template=/ContentManagement/Cont > > > entDisplay.cfm&ContentID=94401 > > > > > > (To follow: ENISA CDXI) > > > > > > > > > Some typos > > > > > > > > > > > > Next step: more XML focused ;) > > > > > > > > > My 2 bitcents > > > > > > 2014/1/24 Martin Murillo : > > >> Dear all, > > >> > > >> Please find below a link to a proposed draft for extending IODEF > > >> for the reporting of cyber-physical system incidents. These systems > > >> are often referred as Operational Technology Systems, Industrial > > >> Control Systems, Automatic Control Systems, or simply Control > Systems. > > >> > > >> Cyber-Physical systems have been around for decades. However, they > > >> are now at a higher risk to be the target of attacks by individual > > >> highly-skilled attackers, organized groups, nation-states, or > > >> simply suffer repercussions of mainstream IT cyber-attacks. While > > >> over 90% of critical control system infrastructure is currently > > >> owned by private enterprises, these can have direct repercussions > > >> on national security of world nations. Indeed, various of these > > >> systems are key parts of nuclear reactor facilities, transportation > > >> systems, electric power distribution, oil and natural gas > > >> distribution, health care, water > > and waste-water treatment, dam infrastructure, missile > > >> and defense systems, and others. The disruption of these control > > systems > > >> could have a significant impact on public health, safety, and lead > > >> to large economic losses. > > >> > > >> Among the issues that catalyze this higher risk are: > > >> > > >> i) these systems are gradually becoming more interconnected, ii) > > >> legacy systems do not have proper cybersecurity protection, iii) > > >> the existence of highly-skilled individuals and motivations, iv) > > >> some these systems are generally considered critical, v) these are > > >> a natural extension of IT cyber-attacks, vi) the emergence of the > > >> Internet of Things (IOT), and vi) these attacks can be carried out > > remotely and quite inexpensively. > > >> > > >> While there might exist national approaches to deal with incidents, > > >> there's the need of a global international approach that will > > >> engulf governments, private organizations and other stakeholders. > > >> IETF, as a leading global Internet standards organization, seeks to > > >> satisfy this need through open standards that seek to encompass > > >> issues that are critical for the global community. > > >> > > >> Feedback at two levels are welcome: > > >> > > >> 1. On the existence and inclusion either by utilizing any already > existing > > >> industry formats (XML- encoded) and/or by utilizing atomic data > > >> 2. Contributions on making the extension (and background > > >> information) more comprehensive, accurate and principally useful > > >> for the community > > >> > > >> Look forward to feedback and other input! > > >> > > >> Martin Murillo > > >> > > >> A new version of I-D, draft-murillo-mile-cps-00.txt has been > > >> successfully submitted by Martin Murillo and posted to the IETF > > >> repository. > > >> > > >> Name: draft-murillo-mile-cps > > >> Revision: 00 > > >> Title: IODEF extension for Reporting Cyber-Physical System > > >> Incidents > > >> Document date: 2014-01-21 > > >> Group: Individual Submission > > >> Pages: 24 > > >> URL: > > >> http://www.ietf.org/internet-drafts/draft-murillo-mile-cps-00.txt > > >> Status: > > https://datatracker.ietf.org/doc/draft-murillo-mile-cps/ > > >> Htmlized: > http://tools.ietf.org/html/draft-murillo-mile-cps-00 > > >> > > >> > > >> Abstract: > > >> This draft document will extend the Incident Object Description > > >> Exchange Format (IODEF) defined in [RFC5070] to support the > > reporting > > >> of incidents dealing with attacks to physical infrastructure > through > > >> the utilization of IT means as a vehicle or as a tool. These > systems > > >> might also be referred as Cyber-Physical Systems (CPS), > Operational > > >> Technology Systems, Industrial Control Systems, Automatic Control > > >> Systems, or simply Control Systems. These names are used > > >> interchangeably in this document. In this context, an incident > is > > >> generally the result of a cybersecurity issue whose main goal > > >> is > > to > > >> affect the operation of a CPS. It is considered that any > > >> unauthorized alteration of the operation is always malign. This > > >> extension will provide the capability of embedding structured > > >> information, such as identifier- and XML-based information. In > its > > >> current state, this document provides important considerations > for > > >> further work in implementing Cyber-Physical System incident > > reports, > > >> either by utilizing any already existing industry formats (XML- > > >> encoded) and/or by utilizing atomic data. > > >> > > >> In addition, this document should provide appropriate material > for > > >> helping making due considerations in making an appropriate > decision > > >> on how a CPS reporting is done: 1) through a data format > > >> extension > > to > > >> the Incident Object Description Exchange Format [RFC5070], 2) > > forming > > >> part of an already existing IODEF-extension for structured > > >> cybersecurity information (currently draft > > >> draft-ietf-mile-sci-11.txt), or others. While the format and > > >> contents of the present document fit more the earlier option, these > > >> can also be incorporated to the later. > > >> > > >> > > >> > > >> Please note that it may take a couple of minutes from the time of > > >> submission until the htmlized version and diff are available at > > tools.ietf.org. > > >> > > >> The IETF Secretariat